iOS - webRtc实现单人音视频和多人音视频功能

醉凝眸 2020-04-04 10.48.52 - 01.gif

序一：我看了看Xcode代码，又看了看右上角时间，emmm，想了下就不详细叙述了，走一遍大概逻辑以作提醒！

序二：单人音视频功能实现依赖于GoogleWebRTC和SocketRocket框架；

序三：多人音视频功能分mesh模式、SFU模式、MCU模式，本项目采用的是基于SFU模式的Kurento，框架为KurentoToolbox，相关区别请看链接：

传送门

序四：懒得麻烦········懒······

序五：因为只讲逻辑，不讲具体实现代码，所以主要记录一些踩过的坑

一、踩过的坑

1.因为iOS的代码项目在goole上面是后进的人发offer、先进的人发oanswer，而常规的单人音视频是先进的人打个后进的人，也就是需要先进的人发offer、后进的人发answer；实现逻辑：将peer和newPeer信令的逻辑对调，A进来收到peer信令啥事也不干，然后当b进来后，A收到newPeer信令后，创建本地流、生成peerconnection并添加本地流，发送offer；B进来收到peer信令创建本地流、生成peerconnection并添加本地流；

2.和安卓端互通问题：iPhone和iPhone可以后，和安卓端联调时候，在发送offer和answer时候回报错FingerPrint啥啥啥的，打印查询sdp后发现原因是安卓端底层代码此协议默认关闭（安卓端是有个if-else，默认走得是另外一个协议）导致sdp中fingerPrint不通过，解决方案移动端统一增加属性值DtlsSrtpKeyAgreement为yes；

3.断网重连问题之重连实现：整体断网重连由于webSocket代码心跳不能百分百拉回peerconnection（也就是说RTCIceConnectionState经过断网重连后不能从RTCIceConnectionStateFailed状态切换到RTCIceConnectionStateConnected状态），所以采用的重走流程方案，即收到didFailWithError代理回调时候，判定条件（如果rtcIsFail且非主动挂断且ReachabilityStatus>0），条件成立，重新初始化socket，链接服务器，didOpen后发送reconnect信令给服务器，然后重走peer及后续信令，重新拉回peerconnection链接（因为本地流、peerconnection、iceServer和RTCPeerConnectionFactory都是全局变量，而且都做了判空处理，所以整个流程其实就是相当于重新初始化了下socket服务器，然后信令走了一遍具体信令里面的操作其实相当于没走）；

4.断网重连问题之和安卓端的适配：因为谷歌项目中peerconnection是局部变量，在重连时候重走流程时候，iPhone和iPhone手机是完全没问题的；但是和安卓就有点蛋疼了，因为安卓创建本地流、生成peerconnection耽误时间，所以安卓逻辑是在进入页面时进行这些操作，为了适配安卓手机，iOS端把peerconnection也初始化全局，这样子整个移动端相当于peerconnection都是全局变量，重连时候不需要再重新创建peerconnection，直接恢复已有的peerconnection！

5.断网重连问题之断网提示：手动创建定时器，新建心跳heart信令发送给rtc服务器，哪方网络不好时候，rtc服务器会返回给对面_poor_connection信令用来显示对应的网络提示；

6.大坑之音视频链接音频ok视频却黑屏问题：经测试，在iPhone7以下机型，音视频ok；7以上机型，音频ok视频黑屏问题，尝试过修改分辨率和sdp内容码率等；最终解决方案定位统一视频分辨率！

7.多网络音视频互通：rtc服务器同学在stun打洞服务器的基础上新增turn服务器，移动端创建iceServer时候两个都加上!

8.视频横屏问题：didChangeVideoSize代理回调中，判断宽大于高时候调换一下，然后横竖比按照videoView.bounds.size.height/videoFrame.size.height值对比;

9.单人音视频前后置摄像头切换导致的本地和远程视频流镜像问题：保持前置摄像头镜像（即本地视频预览）ok，修改后置摄像头（即远程视频预览）；创建remoteVideoView设置transform的scale为(-1,1),和安卓端适配时，在点击切换摄像头时候发送change_camera信令，收到change_camera信令时候，判定如果摄像头是back就设置远程预览页为Identity，如果否就设置远程预览页scale为(-1,1)；

10.群聊音视频的镜像问题：因为群聊音视频显示在接听页面上的流都是放在远程预览页remoteVideoView上显示的，所以跟单人音视频一样，将远程预览页的transform的scale设置为(-1,1)即可！

11.emmmmm··················，忘了，想起来了有缘在写，下班了，溜了溜了！

二、代码实现

1.CocoaPods导入GoogleWebRTC和SocketRocket

2.WebRTCHelper单列类引用

3.主页面远程视频预览页和本地视频预览页创建（RTCEAGLVideoView和RTCCameraPreviewView）

4.链接webrtc服务器，代码部分：
[[WebRTCHelper shareInstance] connectServer:@"rtc服务器地址" port:@"rtc服务器端口" room:@"你的房间"];

5.链接服务器，初始化websocket，链接成功，会回调webSocketDidOpen代理方法；链接失败，会回调didFailWithError代理方法，并自动调用didCloseWithCode代理；

6.链接成功后，后续会进行七大常规信令交涉（join、peer、newPeer、iceCandidate、offer、answer、leave七个信令），接收此七大常规信令的方法为didReceiveMessage代理方法

7.链接成功后，发送join信令（表示该用户加入房间），代码：

图片.png

8.用户A join房间成功后，会收到rtc服务器返回的peer信令，此信令代表用户自己进入成功，每一个用户加入房间都会收到peer信令用来表示自己加入成功；

9.加入房间后，如果此时有新用户B进入房间（新用户B加入流程也是5、6、7、8步），之前加入房间的用户A会收到newPeer信令，然后进行创建本地音视频流、生成peerconnection、peerconnection添加本地音视频流、创建并发送offer，大致代码：

图片.png

10.新用户B会收到rtc服务器转发的用户A的offer信令，接到offer信令后生成answer信令并发送，大致代码：

图片.png

11.用户A会收到rtc服务器转发的新用户B的answer信令

图片.png

12.在A、B两用户交涉过程中，会通过打洞iceServer的方式，进行点与点的信令交涉，也就是iceCandidate信令：

图片.png