RFC1889协议中文概要PPT培训课件.ppt

RR包格式： 6.3.3 扩展RR和SR 同RTP包一样，可通过配置文件在特定的应用中发送一些REPORT RTCP 包。由于应用场合是特定的，包的形式可能更短小，更易于处理。 6.3.4 对SR和RR的分析 REPORT RTCP包不仅可以让SENDER调整自己的发包方式，同时对于RECEIVER定位拥塞发生点是局部的还是全局的也有很大作用。对第三方的MONITOR也能提供参考信息。 如Cumulative counts，NTP timestamp可以用来计算丢包率、数据率和数据分配情况interarrival jitter可用来计算网络短期内的拥塞情况。 6.4 源描述信息RTCP包(SDES) 每个SDES包包含一个包头和0或多个SSRC或CSRC信息项，每个信息项中又分别包含多个子项信息，如CNAME、E-MAIL等。 SDES格式如下： version (V), padding (P), length: 与SR包定义相同 (见 6.3.1). packet type (PT): 8 bits 值为常量202 source count (SC): 5 bits 包中描述的SSRC/CSRC的数目 包头后的每一项都是对一个SSRC/CSRC的描述，其中包含一系列子项。每个子项都具有下列格式： 8位子项类型标识 8位该子项的描述文本长度，不包括子项头这2个字节 描述文本，以UTF-8方式编码，最大长度255字节 6.4.1 CNAME: Canonical end-point identifier SDES item 同SSRC一样，在一个RTP会话中，CNAME也是全局唯一的，用来绑定应用程序与该站点的连接，通常具有以下形式：doe@ doe@9 timestamp: 32 bits 该项用于时间同步计算和抖动控制，其精度必须足以满足上述两项要求。时钟频率与负载类型有关，2者同时定义在PAYLOAD FORMAT SPECIFICATION文件中。其初始值随机。 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项。 5.2 RTP会话的多路传输 RTP协议中，多路传输的目标地址由定义RTP会话的网络地址＋端口号确定。 音、视频传输不能定义在同一个RTP会话中，因为负载类型不同而SSRC标识符相同会引起一系列的问题。（详细问题请参考原文档） 5.3 配置文档（profile-specific document） 对于一些常用的功能来说，RTP协议是足够的。但在一些特殊的应用场合，可能需要在RTP包头后面加上一些扩展定义来满足需求。5.1中的MARKER和PAYLOAD TYPE字段就可以与接下来要讨论的配置文档一起提供所需的额外信息。 如果对上述字段的特定值在很多场合都行使同样的功能的话，则可将其加入协议，作为标准确立 5.3.1 RTP头的扩展 扩展定义通常仅用于实验或者个别的场合。 如果RTP头中的X字段置1，则在RTP头部的CSRC列表后（如果有这个列表的话），产生一个16位的DEFINED BY PROFILE字段和一个16位的LENTH字段。前者由特定的配置文件定义，后者的值为LENGTH字段后扩展定义位所需字节数，其长度不包括LENGTH和DEFINED BY PROFILE所占的4个字节。所以长度0也是允许的，虽然这样并没什么意义。 扩展头格式： 6. RTP传输协议之——RTCP RTCP协议基于每隔一段时间给会话的所有参与者发送一些控制包的机制。下层协议必须支持数据和控制包的多路传输。比如通过UDP协议发送数据到多个端口。 RTCP协议的四个主要功能 1.提供数据分布服务质量的反馈。这是RTP作为传输协议必不可少的部分。同时也与别的协议中拥塞和流量控制功能有关。反馈功能主要通过“接受者报告”和“发送者报告”实现（详见6.3）。在某些时候，第三方也可以通过RTCP包实现对网络的监控。 RTCP协议的四个主要功能 2.RTCP包中携带着RTP源的永久标识符信息存放为CNAME（canonical name）项。在会话中的RTP源有可能因为SSRC冲突或者因为程序重启而重新生成一个SSRC，但它的CNAME是不变的，这样就可以追踪会话的每个参与者。