解释一下用于WebRTC的SRTP的实时传输协议

作者:VARUN SINGH, ALEXANDREA MELLEN(原文链接

翻译:刘通

原标题:Explaining the Real-time Transport Protocol of SRTP for WebRTC

srtp1

WebRTC使用安全实时传输协议(Secure Real-time Transport Protocol,SRTP)对RTP数据进行加密,消息认证和完整性以及重播攻击保护。它是一个安全框架,通过加密RTP负载和支持原始认证来提供机密性。WebRTC的安全特性是其可靠性的重要组成部分,其基础全部围绕实时传输协议(Real-time Transport Protocol)进行。但什么是实时传输协议?它又是如何工作的?

什么是实时传输协议?

实时传输协议(RTP)是专为多媒体电话(VoIP,视频会议,远程呈现系统),多媒体流(视频点播,直播)和多媒体广播而设计的网络协议。它最初由RFC1889中的IETF指定。RTC最初是为了协助IETF音频-视频传输工作组涉及寄给地理上分散的成员的视频会议而创建的。目前,RFC3550中指定的v2是过去15年中一直在使用的v2。

RTP的设计基于应用层框架和集成层处理的基本原理。它提供源和负载类型标识,流同步,丢包和重新排序以及媒体流监控。

RTP使用RTP控制协议(RTCP)报告媒体流的性能。

在这个过程中,媒体发送端发送封装在RTP中的编码媒体。它还发送RTCP发送端报告,这有助于不同媒体流的额播放同步。接收端维护一个抖动缓冲区,对媒体数据包进行重新排序,并根据数据包中编码的定时信息进行播放。如果数据包丢失,接收端进行数据包恢复或者隐藏错误。最后,在RTCP接收端报告中接收机粗略或详细地对统计数据进行报告,使媒体发送端能够调整其媒体编码速率,变成更好的编解码器或改变前向纠错量。

RTP数据包报头格式

RTP包报头格式分为四个部分:同步源标识符(synchronization source identifier),贡献源标识符(contributing source identifier),时间戳(timestamp),序列号(sequence number),以及负载类型(payload type)。

1.同步源:同步源协助确定源端点。 当端点发送需要同步的多个媒体流时很有用。

2. RTP时间戳:RTP时间戳有助于在适当的时间播放接收到的数据包,并从RTP数据包中重组媒体帧。

3. RTP序列号:RTP序列号帮助识别丢失的数据包并且在数据包不按顺序到达的情况下重新排序数据包。

4.负载类型:负载类型描述了它所携带的媒体数据的编码。每个编解码器必须指定其相应的负载类型。

RTCP报告

RTCP报告有三种:发送端报告,接收端报告和扩展报告。

RTCP发送端报告

发送端使用RTCP发送端报告来帮助同步媒体流。为了实现这一点,它将各个媒体流的RTP时间戳与时钟时间相关联,并通知接收端当前的分组速率和比特率。

RTCP接收端报告

接收端测量输入流并在RTCP接收端报告中报告粗粒度的传输统计。此报告包括当前的丢包比例,接收到的最高序列号,并有助于计算往返时间。

RTCP扩展报告

RTCP扩展报告由端点用来描述复杂的度量标准,而不是RTCP接收端报告中所公开的。这包括相关的性能监控和拥塞控制指标,如抖动缓冲之后表,数据包延时变化,延时指标,丢弃数据包数量,体验质量等。新的度量标准也可以定义,只要它们涉及测量的内容,测量方式以及向其他端点报告的方式。

RTP负载格式是什么样的?

定义负载格式需要识别媒体数据包的编码。这些编码可以是两种方式中的一种:编解码器专用的,例如H.264,H.263,H.261,MPEG-2,JPEG,G.711,G.722或AMR;通用的,例如前向纠错(FEC),NACK或多路复用流。

负载文件通常为媒体编解码器指定一个定义明确的数据包格式,并描述编解码器的两种规则:聚合规则(aggregation rules)和碎片规则(fragmentation rules)。聚合规则是为编解码器定义的,与IP最大传输单元(例如音频)相比,这些编解码器产生几个小帧。碎片规则是为产生大帧的编解码器定义的,例如视频编解码器的I帧。将大型帧分成较小的数据包而不依赖于IP碎片,主要是因为IP碎片数据包通常在网络中被丢弃,尤其是通过NAT或防火墙的时候。

什么是RTP报头扩展?

RTP报头扩展旨在传送独立于媒体的信息。 更具体地说,它们携带的数据通常可以适用于多种负载格式,并且需要比发送RTCP报告更频繁地进行报告。

例如,在为交互媒体发送NACK数据包时,每隔几十毫秒会产生双向媒体流和RTP数据包。在这种情况下,RTP报头扩展可以指示哪些序列号被正确接收或丢失。因此,他们不完全依赖RTCP接收端报告发送NACK或ACK。

使用报头扩展可能非常有用,因为它们向后兼容。不了解它们的端点可能会忽略它们。此外,它们是通用的,因为不需要为每个媒体编解码器重新定义相同的扩展名。

RTP报头扩展有多种用途,包括报告网络发送时间戳和媒体会议中跨多个流均衡客户端的音频级别。

什么是RTCP报告间隔?

使用RTP,通过发送RTP媒体数据包和接收RTCP反馈数据包创建一个闭环。RTCP反馈间隔通常是会话带宽的一小部分,不会影响媒体流量。RTCP报告间隔由会话中的同步源数量和会话带宽决定。

虽然会话带宽预计将在参与者之间进行分配,但实际上通常是预期同时活动的发送端的平均吞吐量的总和。例如,在音频会议中,会话带宽将是一个发送端的带宽。但是,对于视频会议,会话带宽取决于显示的用户数量。为了管理这个,会话带宽由会话管理层给出,因此为每个参与者计算相同的RTCP间隔值。

会话带宽的5%应该分配给控制流量。

在具有大量接收端和少量发送端的场景中,四分之一的报告带宽应由发送端平均分配,其余四分之三专用于接收端。这允许新的参与者快速从发件人报告接收CNAME和同步时间戳。对于新的参与者,RTCP时间间隔减半以快速声明他们的存在。

推荐的RTCP最小值为5秒。这适用于单向链路,或适用于不需要检测接收质量到的会话。

减少的最小值是360除以会话带宽(以秒为单位)。它适用于单播双向多媒体会话的参与者,并适时发送反馈消息来执行拥塞控制或错误修复。

基于RTCP反馈的扩展RTP文件

在端点检测到数据包丢失或者通过报告间隔中途发生拥塞的情况下,RTCP报告不能提前发送,端点必须等待下一个计划的RTCP报告。这会导致媒体比特率不稳定和振荡。为了解决这个问题,端点实现了基于RTCP的反馈的扩展RTP配置文件。这是RTP默认时间规划的扩展,可以实现快速反馈。

通过此文件,只要报告间隔平均保持不变,端点就可以调整RTCP报告间隔,以便早于下一个计划的RTCP报告发送报告。此外,它还定义了一套错误恢复反馈消息,包括否定确认(NACK),图像丢失指示(PLI),切片丢失指示(SLI)和参考图像选择指示(RPSI)。

填写常用邮箱,接收社区更新

WebRTC 中文社区由

运营