WEBRTC开发系列第一篇-sdp交换流程

最近刚好接手了原生webrtc开发项目需求，趁项目第一版落地，有很多技术细节还印象深刻先写文章记录下来，webrtc的前世今生我就不多赘述，读者可以左转百度查询，关于他的使用场景说明文章也是很多。

首先，先科普下webrtc建立一个正常会话的流程：

文字描述流程大概是：

1. 主播端创建一个peerconnection实例，添加完音视频轨道之后createOffersdp之后setLocalDescription设置本地offer描述（生成的sdp信息里面包含是否传输音视频流和相关支持的一些编解码参数）
2. 主播端通过信令服务器把第一步生成的offersdp信息发送给接受端
3. 观众端通过信令服务器接受到主播端offersdp信息通过setRemoteDescription把主播端offersdp设置到本地
4. 观众端createAnswer生成对应offer的answersdp信息，并通过setLocalDescription设置answer到本地
5. 观众端通过信令服务器发送answer信息给主播端
6. 主播端接收观众端发送过来的answer信息并通过setRemoteDescription把answer信息设置到本地，至此，两端都保存了己方和对方的sdp信息
7. 主播端把通过监听icecandidate事件产生的candidate信息发送给观众端，观众端接受到之后通过addIceCandidate把对应candidate信息设置到本地
8. 观众端同样触发第七步步骤，至此，双方的candidate交换完毕，一个正常的peerconnection链接就建立了，双方可以正常音视频通话了

其中遇到了一些坑，因为项目涉及到多端合作原因，在跨多端出现了主播端连续生成两个不一致内容的sdp信息，而且第二次才是正确的，这时候就会遇到一些问题

坑1：

1. 连续发送两个offer信息，第一个offer信息里面只带有audio信息，没有video信息，第二个offer信息里面audio、video都有
2. 观众端接受到之后，第一次生成对应answer并且setLocalDescription会报错，因为这时候生成的answer对应的是第一次发送的offer产生的，但是第二次offer也设置成功，所以offer-answer没有对应上，导致报错
3. answer设置报错之后通过信令服务器发送对应answer给主播端的话会导致链接失败

解决方案：通过try-catch捕获createAnswer里面的流程，只要触发报错就不通过信令发送给主播端

坑2：

1. 连续发送两次offer，第一次是只有video信息，第二次带有audio、video信息，但是相关audio信息排在video前面（默认）
2. setRemoteDescription时候报错，因为setRemoteDescription要求前后两次offer里面audio、video描述信息顺序保持一致

解决方案：通过交换第二次sdp信息里面audio、video顺序解决