最近刚好接手了原生webrtc开发项目需求,趁项目第一版落地,有很多技术细节还印象深刻先写文章记录下来,webrtc的前世今生我就不多赘述,读者可以左转百度查询,关于他的使用场景说明文章也是很多。
首先,先科普下webrtc建立一个正常会话的流程:
文字描述流程大概是:
- 主播端创建一个peerconnection实例,添加完音视频轨道之后createOffersdp之后setLocalDescription设置本地offer描述(生成的sdp信息里面包含是否传输音视频流和相关支持的一些编解码参数)
- 主播端通过信令服务器把第一步生成的offersdp信息发送给接受端
- 观众端通过信令服务器接受到主播端offersdp信息通过setRemoteDescription把主播端offersdp设置到本地
- 观众端createAnswer生成对应offer的answersdp信息,并通过setLocalDescription设置answer到本地
- 观众端通过信令服务器发送answer信息给主播端
- 主播端接收观众端发送过来的answer信息并通过setRemoteDescription把answer信息设置到本地,至此,两端都保存了己方和对方的sdp信息
- 主播端把通过监听icecandidate事件产生的candidate信息发送给观众端,观众端接受到之后通过addIceCandidate把对应candidate信息设置到本地
- 观众端同样触发第七步步骤,至此,双方的candidate交换完毕,一个正常的peerconnection链接就建立了,双方可以正常音视频通话了
其中遇到了一些坑,因为项目涉及到多端合作原因,在跨多端出现了主播端连续生成两个不一致内容的sdp信息,而且第二次才是正确的,这时候就会遇到一些问题
坑1:
- 连续发送两个offer信息,第一个offer信息里面只带有audio信息,没有video信息,第二个offer信息里面audio、video都有
- 观众端接受到之后,第一次生成对应answer并且setLocalDescription会报错,因为这时候生成的answer对应的是第一次发送的offer产生的,但是第二次offer也设置成功,所以offer-answer没有对应上,导致报错
- answer设置报错之后通过信令服务器发送对应answer给主播端的话会导致链接失败
解决方案:通过try-catch捕获createAnswer里面的流程,只要触发报错就不通过信令发送给主播端
坑2:
- 连续发送两次offer,第一次是只有video信息,第二次带有audio、video信息,但是相关audio信息排在video前面(默认)
- setRemoteDescription时候报错,因为setRemoteDescription要求前后两次offer里面audio、video描述信息顺序保持一致
解决方案:通过交换第二次sdp信息里面audio、video顺序解决