通过IP多播方式建立的一个会议,每个参与者通过某些分配机制(不在本协议讨论范围中)得到一个组地址和2个端口号,一个端口号用来传送RTP数据,即音频数据,另一个用来传输RTCP控制数据。如果需要加密,可根据本协议生成密钥。
会议的每个参与者每隔20ms发送一段音频数据,放在RTP包中。RTP包又通过UDP包传输。RTP包头中定义了音频文件的编码方式,以便参与者改变自己的编码方式以适应网络传输(如编码质量低以适应低带宽传输)。
INTERNET会产生丢包和延迟,所以RTP包头中包含了时间信息和一个序号,序号可以用来使接受方预测丢包的情况。
在本例中,由于会议不时有成员加入或离开,所以每个接受方会每隔一段时间报告一次接受情况。这个信息有可能被用来控制编码方式以适应带宽。当某个成员发出BYE的RTCP包时,该成员离开该会议。
音频、视频信息通过不同的RTP会话(session)传输,即二者是分开传输的。同时对于每一个传输,都有2个端口用来传送RTP数据和RTCP控制信息。
这样做的目的是因为接受者可能由于带宽限制,只够接受音频数据,或他只想接受一种数据。
RTP会话 (RTP SESSION):
多个参与者通过RTP协议通信,这就形成了一个RTP会话。对于每个参与者来说,RTP会话被一个地址和一对端口号定义。在多媒体会话中,不同的流建立不同的RTP会话(如:音频的会话,视频的会话)。每种不同的会话都有自己的RTCP包。不同的会话靠不同的传输地址来区分
同步化源(SYNCHRONIZATION SOURCE):
即SSRC,可理解为信号的源头,如一个麦克风输入或一个摄像头输入,在整个会话中有一个独一无二的标识符。从它输出的信号都经过它的同步处理,以使接受方能实现对源的控制,如回放功能。若一个服务器有多个输入,如多个摄像头信号,那么每个摄像头都有一个SSRC。SSRC标识符靠RTCP绑定。
供流源(CONTRIBUTING SOURCE ):
即CSRC,经由混流服务器(MIXER)输出的一个流通常由多个分流汇成,每个分流都有一个供流源。(详见第8章)
,CSRC字段只有当MIXER插入时才产生。
RTP协议中,多路传输的目标地址由定义RTP会话的网络地址+端口号确定。
音视频传输不能定义在同一个RTP会话中,因为负载类型不同而SSRC标识符相同会引起一系列的问题。
SSRC: 32 bits
同步化源标识符,即此RTP包的发出者(个人理解)。因为一个RTP会话中不能有2个相同的SSRC ,所以当发送者传输地址改变时此值需重新生成,以防止形成循环
CSRC list: 0 to 15 items, 32 bits each
字段头中CSRC COUNT项给出了该项中ITEM的数量。
当包通过MIXER时由MIXER将原来包中的SSRC标识符作为CSRC插入,而将MIXER自己的SSRC作为新的SSRC项。
RTCP协议基于每隔一段时间给会话的所有参与者发送一些控制包的机制。下层协议必须支持数据和控制包的多路传输。比如通过UDP协议发送数据到多个端口。
提供数据分布服务质量的反馈。这是RTP作为传输协议必不可少的部分。同时也与别的协议中拥塞和流量控制功能有关。反馈功能主要通过“接受者报告”和“发送者报告”实现。在某些时候,第三方也可以通过RTCP包实现对网络的监控
RTCP包中携带着RTP源的永久标识符信息存放为CNAME(canonical name)项。在会话中的RTP源有可能因为SSRC冲突或者因为程序重启而重新生成一个SSRC,但它的CNAME是不变的,这样就可以追踪会话的每个参与者
前2个功能均要求会议的参与者发送RTCP包。所以,发送速率应该得到控制以适应有大规模参与者的RTP会话。每个参与者必须可以独立地知道会话的参与者数量,来决定发包的速率
第四个,同时也是一个可选功能项,通过RTCP协议传递最少的会话控制信息,比如用户界面上显示的参与者身份。这个功能在参与者可随时加入或离开的会话时非常有用,因为可以传递控制信息到每个参与者。该功能用于IP多播环境
以下是RTCP包的5种类型:
SR: Sender report 会话中频繁发送包的参与者的报告
RR: Receiver report 非频繁发包的参与者发送的接受方统计数据
SDES: Source description items 发送源描述项,包括CNAME信息
BYE: 终止参与会议信息的包
APP: 用于特定进程的包
每个RTCP包都有一个包头,然后根据包的类型的不同,包头后跟着不同长度的结构化的数据项,但这些数据项都有一个32位的包的边界。
RTCP包通过下层协议传输时,相邻的包之间没有分隔符。比如用UDP传输时,并没有给出UDP包中RTCP包的数量,而仅有一个总长度
几个RTCP包在通过下层协议传输时,对包的排列次序和组合方式没有要求,但有以下限制:
接受方数据统计(包含于SR和RR内)必须在带宽允许下尽可能多地发送,以使统计更加精确。因此,每个RTCP包集合必须有一个SR或RR的包。
新的接收者必须尽快得到源的CNAME并联系媒体求得同步。每个RTCP包集合必须包含SDES CNAME。
综上所述,每个RTCP包都必须以混合包的形式传输,每个混合包中必须至少包含2个独立的包,包的形式按下列推荐:
Encryption prefix: 混合包如果需要加密,前面必须有个32位加密前缀。
SR or RR: 混合包的第一个包必须为其中之一。
Additional RRs: 如果接受方数据中的源的数目超过了31,就需在正常的RR或SR后添加发送超出部分的信息
SDES: 每个混合包中必须包含的包类型,除了CNAME项,可视带宽情况在SDES包中加入更多源的信息。
BYE or APP: BYE类型的RTCP包必须是SSRC/CSRC发送的最后一个包,APP包为其他类型的RTCP包。
综上所述,每个RTCP包都必须以混合包的形式传输,每个混合包中必须至少包含2个独立的包,包的形式按下列推荐:
Encryption prefix: 混合包如果需要加密,前面必须有个32位加密前缀。
SR or RR: 混合包的第一个包必须为其中之一。
Additional RRs: 如果接受方数据中的源的数目超过了31,就需在正常的RR或SR后添加发送超出部分的信息
SDES: 每个混合包中必须包含的包类型,除了CNAME项,可视带宽情况在SDES包中加入更多源的信息。
BYE or APP: BYE类型的RTCP包必须是SSRC/CSRC发送的最后一个包,APP包为其他类型的RTCP包。
RTP包的接受者发送REPORT的RTCP包来反馈服务质量。REPORT包分为2种,RR和SR。两者的唯一区别是,发送后者的站点不仅是包的接受者同时也是活跃的包发送者。所以SR比RR要多20字节,用来携带发送者信息
sdes :
包头后的每一项都是对一个SSRC/CSRC的描述,其中包含一系列子项。每个子项都具有下列格式:
8位该子项的描述文本长度,不包括子项头这2个字节
描述文本,以UTF-8方式编码,最大长度255字节
同SSRC一样,在一个RTP会话中,CNAME也是全局唯一的,用来绑定应用程序与该站点的连接,通常具有以下形式:" doe@sleepy.megacorp.com" " doe@192.0.2.89"
-----------------------------------------------------------
高性能商业RTSP流发送库
## 简介 HiPF_RTSP_Server是商业级高性能RTSP流发送服务端,是针对嵌入式环境下高并发、高流量、多码流、低延时实时RTSP发送服务器需求进行设计,在低性能ARM处理下有较高性能同时保持良好的兼容性。
高性能商业RTSP流接收库
HiPF_RTSP_Client是商业级高性能RTSP流接收库,是针对嵌入式环境下接收高并发、高流量RTSP流需求进行设计,在多种平台下有超高接收性能。