随着网络架构的变迁、媒体技术发展、音视频场景迭代，基于流媒体的技术也是推陈出新。WebRTC渐渐的成为了音视频互动场景的主流，而微信在6.5.21版本通过小程序开放了实时音视频能力，开发者们可以使用组件 < live-pusher > 实现基于 RTMP 的直播推流（录制），用于实时音视频通话上行，使用组件 < live-player > 实现基于 RTMP 的直播拉流（播放）。可以看出，微信小程序的音视频是基于 RTMP 协议的，但是微信小程序的音视频只是提供了终端上的能力，并没有实现媒体服务器，腾讯给出了2个方案，1是使用腾讯云的快直播服务，2是开发者自己实现一套媒体网关服务。方案1，需要完全使用腾讯云的服务，很显然不太适合我们这样的开发者；于是留给我们的之后方案2了。
一．什么是RTMP，什么是RTC
1.RTMP
RTMP是Real Time Messaging Protocol实时消息传输协议，是Adobe公司为Flash播放器和服务器之间开发的音视频数据传输的开放协议，一般传输flv或f4v格式的媒体流。RTMP是工作在TCP之上的协议，默认使用端口1935，能够保持长连接，并为用户提供低延时通信。RTMP是目前低延时直播应用最普遍的协议，几乎是全部编码器标准输出协议，是PC机打开浏览器就能播放（通常浏览器默认有Flash），也是全部CDN支持的最好的直播分发协议。
RTMP是基于TCP协议的，且通常只占用TCP一个通道来传输数据和指令，能保证了视频的传输质量。RTMP包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMPT封装在HTTP请求之上，可穿透防火墙；RTMPS类似RTMPT，增加了TLS/SSL的安全功能；RTMPE在RTMP的基础上增加了加密功能。
因为RTMP是基于TCP之上的，所以也存在三次握手的要求，另外RTMP还增加了C0/S0到C2/S2的三次握手。所以播放一个RTMP协议的流媒体需要经过：握手，建立连接，建立流，播放。
RTMP也有不可忽视的缺点，首先，RTMP协议太老，HEVC/H.265/AV1等视频格式都没有官方定义，另外就如刚刚所说，RTMP连接过程较长，存在TCP三次握手和本身的C0/S0到C2/S2的三次握手，再加上connection，createstream，play/publish，总地来说RTMP完成一次建连需要进行9次会话。而且RTMP的拥塞控制完全依赖传输层TCP的拥塞控制算法来进行拥塞管理，无法提供带宽自适应的算法。
2.WebRTC
WebRTC是Web Real-Time Communication网页实时通信，是一个支持网页浏览器进行实时语音对话或视频对话的技术而无需任何插件。由谷歌2010年以6820万美元收购Global IP Solutions公司而获得，如今WebRTC已经不仅仅局限于PC的网页浏览器，Android，iOS平台上很多应用都已经采用了这样技术。
WebRTC使用是RTP分装码流，跟视频监控，IPTV，会议电视一样都是RTP承载媒体流，只不过WebRTC信令遵守ICE框架，走自定义信令，IPTV领域走RTSP信令，视频监控走GB28181或者onvif信令，会议电视走h323或SIP协议。另外，WebRTC的码流采用SRTP进行加密，且WebRTC优先使用VP9、VP8、H.264、AV1，暂不支持H.265。
二．WebRTC如何跟小程序互通
1.如何互通大概分三步走：
A.微信小程序端使用 RTMP 协议，接入边缘媒体网关，即 Xcx网关；
B.Xcx网关支持 RTMP 协议接入和输出，完成微信小程序间的媒体转发；
C.同时Xcx网关将 RTMP 协议转换成 RTP 协议，转发给anyRTC的WebRTC服务器，完成与Native、标准 WebRTC 终端的互联互通。
anyRTC的Xcx网关的主要工作就是对RTMP和WebRTC的音视频格式进行转换。一般RTMP的视频是H264编码，音频是AAC编码；WebRTC的视频是H264编码，音频是Opus编码。所以我们可以看出，视频只需要转换封装格式，而音频则需要进行转码工作。
2.视频格式转换
anyRTC的Xcx网关收到视频帧之后，将帧进行RTP 封装 H.264。
WebRTC 选择了使用 RFC3984 的 Non-Interleaved 封装方案对H.264 进行封装。
Single NAL Unit Packet
Single NAL Unit Packet 是 RTP 最基本的打包方式，其中， forbidden_bit：禁止位，初始为0，当网络发现 NAL 单元有比特错误时可设置该比特为 1，以便接收方纠错或丢掉该单元。
nal_reference_bit：nal 重要性指示，标志该 NAL 单元的重要性，值越大，越重要，解码器在解码处理不过来的时候，可以丢掉重要性为 0 的 NALU。Type：NAL 单元中的 RBSP 数据结构的类型，其中 0 未指，1-19 在 H.264 协议中有定义，20-23 为 264 协议指定的保留位，24-29 在 RFC3984 中进行了指定。Type 后面的数据为 RBSP 的数据，需要注意的是：编码器的每个 slice 或者每帧头一般会有由0x000001 或者 0x00000001 作为起始头，在 RTP 封装中需要去掉。此外在 H.264 裸码流数据后面可能还会带有 padding 的数据由 RTP 头的 padding 位决定。
STAP-A
STAP-A 的作用是可以把多个 nal 单元封装在一个 RTP 包里面进行传输，需要注意：-A 的格式都是不允许跨帧的，也就是 nal 单元的时间戳必须是相同的。常见的场景是 sps 和 pps 两个小包被合并封装。
RTP 头后面仅跟着 STAP-A 的头，由 F、NRI 和 Type 组合而成，占一个字节，这里的 Type 为 24。后面两个字节为第一个 nalu 单元的长度，后面跟第一个 nalu 数据同 Single NAL Unit 的封装一致，第一个数据结束后，跟着第二个 nalu 的长度，占 2 个字节，依次类推。
FU-A
FU-A 的作用是把一个原始大的 nalu 切成多个数据包进行传输，主要使用场景在 slice 比较大的情况下。FU-A 比较特殊，有 FU-A 起始包、FU-A 包（如果只切两个包可能没有）和 FU-A 结束包组成。
FU indicator 占一个字节，由 F、NRI 和 Type 组合而成，这里的 Type 为28。FU header 占一个字节：
S： 占1位如果是1表示当前这个包是 FU-A 的起始包E： 占1位如果是1表示当前这个包是 FU-A 的结束包R： 占1位，保留位，为0Type： 实际包含 nalu 的类型。
音频转码
在Xcx网关中，我们采用了独立的音频转码线程组，减轻逻辑处理线程的压力的目的。每个转码任务将被分配到固定的音频转码线程，线程根据任务数量进行负载均衡。
三．总结
与小程序的互通相对来说还是比较容易实现，开发者可以选择anyRTC的小程序服务，避免过多的踩坑；也可以尝试自己实现一套服务来满足自身的业务诉求。