网页端WebRTC推流转换为RTMP/GB28181等其他直播流协议

网页端WebRTC推流转换为RTMP/GB28181等其他直播流协议

WebRTC是一个在WEB浏览器端广泛应用的流媒体引擎，通过点对点的方式实现音视频数据的传输，以完成视频会议等功能。但是考虑到WebRTC主要是为有限人数情况下的点对点视频会议服务，在做其他直播应用的时候，或者接入现有流媒体网络的情况下，并不太适合，可以考虑将浏览器端的WebRTC流，转换为RTMP/GB28181等其他流媒体协议。经过一段时间的研究，已经成功实现了这一功能，这里我介绍一下转换原理。

WebRTC工作流程

WebRTC 协议主要由三部分组成：

• 用户接口 (User Interface)：提供了一组 API，使得开发者可以在浏览器和移动应用程序之间进行音视频通信；

• 网络协议栈 (Network Protocol Stack)：负责网络数据的传输和协议处理；

• 音视频引擎 (Audio/Video Engine)：负责音视频数据的处理和编解码。

在建立音视频通信之前，浏览器之间需要通过信令服务器进行一系列交互，以协商会话参数和通信方式。下面是 WebRTC 的信令交互过程：

• 建立房间(Room)：浏览器A和B都需要进入同一个房间，以便进行音视频通信。在进入房间之前，它们需要通过信令服务器进行认证和授权。

• 交换SessionDescriptionProtocol(SDP)：在进入房间之后，浏览器A和B都会生成SDP信息，用于协商音视频通信的参数和格式。它们会将自己的SDP信息通过信令服务器发送给对方。

• 交换ICECandidate：为了穿透NAT和防火墙，WebRTC使用ICE协议来获取NAT类型和外部IP地址。在SDP协商过程中，浏览器A和B会交换彼此的ICECandidate信息，以便进行NAT穿透。

• 建立PeerConnection：在完成SDP和ICE协商之后，浏览器A和B就可以建立PeerConnection，开始进行音视频传输。PeerConnection会在浏览器之间建立一条点对点的连接，并且支持多种传输方式，包括UDP、TCP和SCTP等。

当信令交互完成后，WebRTC双方建立起数据通道，就开始传输数据，WebRTC支持多种数据传输方式，包括实时传输协议(Real-time Transport Protocol，RTP)、用户数据报协议(User Datagram Protocol，UDP)、传输控制协议(Transmission Control Protocol，TCP)和数据通道协议 (Data Channel Protocol)等。

其中，RTP 是WebRTC 最常用的音视频传输协议，用于实时传输音视频数据。它基于 UDP 协议，并且提供了一些额外的功能，比如丢包恢复、流量控制和时钟同步等。WebRTC 还可以使用 RTCP 协议来进行质量控制和反馈，包括网络延迟、抖动和丢包等指标。

UDP 协议适合传输实时音视频数据，因为它具有低延迟和高吞吐量的特点。但是 UDP 协议也存在一些问题，比如丢包和乱序等，需要通过额外的机制来解决。WebRTC 使用了一些优化技术，比如前向纠错、重传和重构等，来提高音视频传输的质量和稳定性。

除了传输音视频数据，WebRTC 还支持数据通道协议，用于在浏览器之间传输任意数据。数据通道协议基于 SCTP 协议，并且支持可靠传输和流控制等功能。它可以用于传输文件、消息和游戏数据等，提供了一种全新的浏览器间通信方式。

协议转换方案

WebRTC的优点虽然很多，但是对直播等领域并不具有特别明显的优点，不过有一个最大的好处是可以在浏览器上进行摄像头采集、编码和推送。所以可以利用这一点，通过网页端获取到编码后的摄像头数据，再进一步接入到现有的其他直播协议或者工作流程中。

当了解清楚WebRTC的整个工作流程后，就可以设定协议转换方案：

1. 首先需要构造一个通信协议，用于和浏览器之间进行信令的通信，并做好数据端口的监听，等待浏览器发送WebRTC报文和数据包。
2. 浏览器页面调用WebRTC接口的时候，首先按照正常流程，创建RTCPeerConnection，之后创建本地offer，当收到浏览器回调后，提取offer中的sdp信息，上传给服务器
3. 服务器当接收到浏览器发送的offer后，解析SDP包，然后生成本地SDP数据，在SDP中填写本地RTP端口和RTCP端口等相关媒体信息，返回给浏览器。
4. 浏览器页面接收到SDP之后，调用WebRTC接口，创建answer，并设置浏览器WebRTC模块，如果SDP正确，那么历览器接下来给就会开始向服务器发送RTP报文，内含音频和视频编码数据，程序对此进行解析和提取，将相关数据，重新进行新协议（RTMP、RTSP、GB28181）等的封装。

遇到的问题和解决办法

1. 需要注意的是，浏览器在和服务器通信的时候，还会发送STUN报文，需要处理好STUN报文的回包，否则会出现连接中断的问题。
2. 必须处理RTCP报文，并做正常流程的RTCP交互。
3. WebRTC编码的H.264数据只会发送一次关键帧，这个如果不做处理直接转换成其他协议的直播流，很可能会导致播放端连接后无法获取到关键帧从而无法解码。这个处理方式就是在需要关键帧的时候，向浏览器发送关键帧重传请求。当然也是通过RTCP发送。

以下是FIR（Full Intra Request）关键帧重传报文的格式。

合作请加作者hbstream（http://haibindev.cnblogs.com），转载请注明作者和出处

---