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 协议，并且支持可靠传输和流控制等功能。它可以用于传输文件、消息和游戏数据等，提供了一种全新的浏览器间通信方式。
领C++音视频资料→音视频开发（资料文档+视频教程+项目源码）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）
协议转换方案
WebRTC的优点虽然很多，但是对直播等领域并不具有特别明显的优点，不过有一个最大的好处是可以在浏览器上进行摄像头采集、编码和推送。所以可以利用这一点，通过网页端获取到编码后的摄像头数据，再进一步接入到现有的其他直播协议或者工作流程中。
当了解清楚WebRTC的整个工作流程后，就可以设定协议转换方案：
- 首先需要构造一个通信协议，用于和浏览器之间进行信令的通信，并做好数据端口的监听，等待浏览器发送WebRTC报文和数据包。
- 浏览器页面调用WebRTC接口的时候，首先按照正常流程，创建RTCPeerConnection，之后创建本地offer，当收到浏览器回调后，提取offer中的sdp信息，上传给服务器
- 服务器当接收到浏览器发送的offer后，解析SDP包，然后生成本地SDP数据，在SDP中填写本地RTP端口和RTCP端口等相关媒体信息，返回给浏览器。
- 浏览器页面接收到SDP之后，调用WebRTC接口，创建answer，并设置浏览器WebRTC模块，如果SDP正确，那么历览器接下来给就会开始向服务器发送RTP报文，内含音频和视频编码数据，程序对此进行解析和提取，将相关数据，重新进行新协议（RTMP、RTSP、GB28181）等的封装。
遇到的问题和解决办法
- 需要注意的是，浏览器在和服务器通信的时候，还会发送STUN报文，需要处理好STUN报文的回包，否则会出现连接中断的问题。
- 必须处理RTCP报文，并做正常流程的RTCP交互。
- WebRTC编码的H.264数据只会发送一次关键帧，这个如果不做处理直接转换成其他协议的直播流，很可能会导致播放端连接后无法获取到关键帧从而无法解码。这个处理方式就是在需要关键帧的时候，向浏览器发送关键帧重传请求。当然也是通过RTCP发送。
以下是FIR（Full Intra Request）关键帧重传报文的格式。