实时传输协议介绍：RTP协议介绍、RTCP协议介绍、RTSP协议介绍
RTP(Real Time Transport Protocol)
RTP是针对Internet上多媒体数据流的一个传输协议, 由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。
RTP工作机制
威胁多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。rtp协议就是提供了时间标签,序列号以及其它的结构用于控制适时数据的流放。在流的概念中”时间标签”是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。但是rtp本身并不负责同步，rtp只是传输层协议，为了简化运输层处理，提高该层的效率。将部分运输层协议功能（比如流量控制）上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保证实时地传输数据，不支持资源预留，也不保证服务质量。rtp报文甚至不包括长度和报文边界的描述。同时rtp协议的数据报文和控制报文的使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。
rtp协议和udp二者共同完成运输层协议功能。udp协议只是传输数据包，不管数据包传输的时间顺序。 rtp的协议数据单元是用udp分组来承载的。在承载rtp数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而udp的多路复用让rtp协议利用支持显式的多点投递，可以满足多媒体会话的需求。
rtp协议虽然是传输层协议但是它没有作为osi体系结构中单独的一层来实现。rtp协议通常根据一个具体的应用来提供服务，rtp只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。
RTP协议的报文结构
RTP头格式：
[](http://blog.chinaunix.net/uid-23215128-id-2521326.html)
开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。各段含义如下：
①版本（V）
version (V): 2 bits 2位，标识RTP版本,协议初始版本为0，RFC3550中规定的版本号为2。。
②填充标识（P）
padding (P): 1 bit 1位，如设置填充位，在包末尾包含了额外的附加信息，它不属于有效载荷。附加信息的最后一个字节表示额外附加信息的长度（包含该字节本身）。该字段之所以存在是因为某些加密算法需要固定大小的填充字，或为在底层协议数据单元中携带几个RTP包。
③扩展（X）
extension (X): 1 bit 1位，如果该位被设置，则在固定的头部后存在一个扩展头部，格式定义在RFC3550 5.3.1节。
④CSRC计数（CC）
CSRC count (CC): 4 bits 4位，CSRC计数包括紧接在固定头后标识CSRC个数。
⑤标记（M）
marker (M): 1 bit 1位，标记解释由设置定义，目的在于允许重要事件在包流中标记出来。设置可定义其他标示位，或通过改变位数量来指定没有标记位，该位的功能依赖于profile的定义。profile可以改变该位的长度，但是要保持marker和payload type总长度不变（一共是8 bit）。。
⑥载荷类型（PT）
payload type (PT): 7 bits 7位，记录后面资料使用哪种 Codec ， receiver 端找出相应的 decoder 解碼出來，该位标记着RTP packet所携带信息的类型，标准类型列出在RFC3551中。如果接收方不能识别该类型，必须忽略该packet。
Payload Type Codec
0 PCM μ -Law
8 PCM-A Law
9 G..722 audio codec
4 G..723 audio codec
15 G..728 audio codec
18 G..729 audio codec
34 G..763 audio codec
31 G..761 audio codec
⑦系列号
sequence number:16 bits 16位，系列号随每个RTP数据包发送后而增加1，接收方可以根据该序列号重新排列数据包顺序，或者探测包损失。系列号初值是随机的，使对加密的文本攻击更加困难。
⑧时标
timestamp: 32 bits 32位，时标反映RTP数据包中第一个八进制数的采样时刻，采样时刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时标可以让receiver端知道在正确的时间将资料播放出来。
由上图可知，如果只有系列号，并不能完整按照顺序的将data播放出来，因为如果data中间有一段是没有资料的，只有系列号的话会造成错误，需搭配上让它知道在哪个时间将data正确播放出来，如此我们才能播放出正确无误的信息。
⑨SSRC
SSRC: 32 bits 32位，SSRC段标识同步源。此标识不是随机选择的，目的在于使同一RTP包连接中没有两个同步源有相同的SSRC标识，也就是在一个RTP Session其间每个数据流都应该有一个不同的SSRC。尽管多个源选择同一个标识的概率很低，所有RTP实现都必须探测并解决冲突。如源改变源传输地址，也必须选择一个新SSRC标识以避免插入成环行源。
⑩CSRC列表
CSRC list: 0 to 15 items bits0到15项，每项32位。CSRC列表表示包内的对载荷起作用的源。标识数量由CC段给出。如超出15个作用源，也仅标识15个。CSRC标识由混合器插入，采用作用源的SSRC标识。只有存在Mixer的时候才有效。如一个将多声道的语音流合并成一个单声道的语音流，在这里就列出原来每个声道的SSRC。
RTCP(Real Time Contorl Protocol)
RTCP负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。
RTCP工作机制
当应用程序开始一个rtp会话时将使用两个端口：一个给rtp，一个给rtcp。
rtp本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠rtcp提供这些服务。在rtp的会话之间周期的发放一些rtcp包以用来传监听服务质量和交换会话用户信息等功能。rtcp包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。rtp和rtcp配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。根据用户间的数据传输反馈信息，可以制定流量控制的策略，而会话用户信息的交互，可以制定会话控制的策略。
RTCP协议将控制包周期发送给所有连接者，应用与数据包相同的分布机制。底层协议提供数据与控制包的复用，如使用单独的UDP端口号。RTCP执行下列四大功能：
主要是提供数据发布的质量反馈。是作为RTP传输协议的一部分，与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用，但IP组播经验表明，从发送者收到反馈对诊断发送错误是致关重要的。给所有参加者发送接收反馈报告允许问题观察者估计那些问题是局部的，还是全局的。诸如IP组播等发布机制使网络服务提供商类团体可能接收反馈信息，充当第三方监控者来诊断网络问题。反馈功能由RTCP发送者和接收者报告执行。
RTCP带有称作规范名字（CNAME）的RTP源持久传输层标识。如发现冲突，或程序重新启动，既然SSRC标识可改变，接收者需要CNAME跟踪参加者。接收者也需要CNAME 与相关RTP连接中给定的几个数据流联系
前两种功能要求所有参加者发送RTCP包，因此，为了RTP扩展到大规模数量，速率必须受到控制。让每个参加者给其它参加者发送控制包，就大独立观察参加者数量。该数量用语计算包发送的速率。
第四个可选功能是传送最小连接控制信息，如参加者辨识。最可能用在"松散控制"连接，那里参加者自由进入或离开，没有成员控制或参数协调，RTCP充当通往所有参加者的方便通道，但不必支持应用的所有控制通讯要求。在IP组播场合应用RTP时，前3个功能是必须的，推荐用于所有情形。RTP应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。
RTCP数据报
在RTCP通信控制中，RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型：
①SR:发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。
②RR:接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。
③SDES:源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。
④BYE:通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。
⑤APP:由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。
SDES: 源描述RTCP包
SDES 包为三层结构，由头与数据块组成，数据块可以没有，也可有多个，组成项描述块所表明的源。项描述如下：
版本（V）、填充（P）、长度： 如SR包中所描述。
包类型（PT）： 8位，包含常数202，识别RTCP SDES包。
源计数（SC）： 5位，包含在SDES包中的SSRC/CSRC块数量，零值有效，但没有意义。
源描述项内容如下：
CNAME: 规范终端标识SDES项 CNAME标识属性如下：
如发生冲突或重启程序，由于随机分配的SSRC标识可能发生变化，需要CNAME项提供从SSRC标识到仍为常量的源标识的绑定。 象SSRC标识，CNAME标识在RTP连接的所有参加者中应是唯一的。 为了提供一套相关RTP连接中某个参加者所采用的跨多媒体工具间的绑定，CNAME应固定为那个参加者。 为方便第三方监控，CNAME应适合程序或人员定位源。
NAME：用户名称SDES项
BYE：断开RTCP包
如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC 标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟很多八进制文本，表示离开原因，如："camera malfunction"或"RTP loop detected"。字符串具有同样的编码，如在SDES 中所描述的。如字符串填充包至下32位边界，字符串就不以空结尾；否则，BYE包以空八进制填充。
APP：定义应用的RTCP包
APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。
RTSP（Real Time Streaming Protocol）
协议特点：
● 可扩展性：新方法和参数很容易加入RTSP。
● 易解析：RTSP可由标准 HTTP或MIME解析器解析。
● 安全：RTSP使用网页安全机制。
● 独立于传输：RTSP传输通道，可使用不可靠数据包协议（UDP）或可靠数据包协议（RDP），如要实现应用级可靠，可使用诸如TCP的可靠流协议。
● 记录设备控制：协议可控制记录和回放设备。
● 适合专业应用：通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑。
● 演示描述中立：协议未强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少需包含一个RTSP URI。
● 代理与防火墙友好：协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个“缺口”。
● 适当的服务器控制：如用户启动一个流，则也可以停止一个流。
● 传输协调：实际处理连续媒体流前，用户可协调传输方法。
● 性能协调：如基本特征无效，则必须有一些清理机制让用户决定那种方法不生效。这允许用户提出适合自己的界面。
同其他协议的关系：
RTSP在功能上与HTTP有重叠，最明显的交叉是在流媒体内容的发布上——----大多是通过网页进行的。目前的协议规范同时允许网页服务器和流媒体服务器支持RTSP实现。例如，演示描述可通过HTTP或RTSP获取，这样减少了基于浏览器情况下的往返传递时间，同时也支持独立的RTSP 服务器与不依赖HTTP的客户端通信。
但是，RTSP与HTTP 的本质差别在于以下五个方面
● RTSP和HTTP是两个不同的协议，它们采用不同的方法和协议标志符。
● RTSP协议的数据发送不占用协议带宽，并且以不同的协议发送。
● HTTP是一个不对称协议，客户端发出请求，服务器应答。在RTSP中，客户端和服务器都可发出请求，且请求是有状态的。
● HTTP是一个无状态协议，而RTSP在任何情况下，必须保持一定状态，以便在请求确认后的很长时间内，仍可设置参数，控制媒体流。
● RTSP使用ISO 10646（UTF-8）定义，而不使用ISO 8859-1定义，保持与当前的HTML一致。
虽然大多数实时媒体采用RTP作为传输协议，但RTSP并不绑定RTP。重用HTTP的功能至少在两个方面有好处:安全和代理。由于要求非常接近，因此在缓存、代理和授权上采用HTTP功能是有价值的。
1. 实时流协议RTSP
RTSP[3]协 议以客户服务器方式工作，它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据（音频和视频流）时能够进行控制，如：暂停/继 续、后退、前进等。因此 RTSP 又称为“因特网录像机遥控协议”。
1.1. RTSP协 议简介
要实现 RTSP 的控制功能，不仅要有协议，而且要有专门的媒体播放器(media player)和 媒体服务器(media server)。媒体服务器与媒体播放器的关系是服务器与客户的关系。媒体服务器与普通的万维网服务器的最大区别就是媒体服务器支持流式音频和视频的传送，因而在客户端的媒体播放器可以边下载边播放（需要先缓存一小段时间的节 目）。但从普通万维网服务器下载多媒体节目时，是先将整个文件下载完毕，然后再进行播放。RTSP 仅仅是使媒体播放器能控制多媒体流的传送。因此，RTSP 又称为带外协议，而多媒体流是使用 RTP 在带内传送的。
1.2. RTSP的 报文结构
RTSP有两类报文：请求报文和响应报文。
请求报文是指从客户向服务器发送请求报文，响应报文是指从服务器到客户的回答。由于RTSP是面向正文的(text-oriented)，因此在报文中的每一个字段都是一些 ASCII 码串，因而每个字段的长度都是不确定的。RTSP报文由三部分组成，即开始行、首部行和实体主体。在请求报文中，开始行就是请求行，RTSP请求报文的结构如图2所 示。
RTSP请求报文的方法包括：OPTIONS（获得服务器提供的可用方法）、DESCRIBE（得到会话描述信息）、SETUP（客户端提醒服务器建立会话，并确定传输模式）、TEARDOWN（客户端发起关闭请求）、ANNOUNCE(更新会话描述）、PLAY（客户端发送播放请求）、PAUSE（临时停止流，而不释放服务器资源）、GET_PARAMETER（取得流控制参数，可能某些服务器不支持）和SET_PARAMETER（设置流控制参数，可能某些服务器不支持）。响应报文的开始行是状态行，RTSP响应报文的结构如图3所示。
1.3. RTSP交互过程
C表 示RTSP客户端，S表示RTSP服务端
① C->S: OPTION request //询问S有 哪些方法可用
S->C: OPTION response //S回 应信息中包括提供的所有可用方法
② C->S: DESCRIBE request //要求得到S提供 的媒体初始化描述信息
S->C: DESCRIBE response //S回 应媒体初始化描述信息，主要是sdp
③ C->S: SETUP request //设置会话属性，以及传输模式，提醒S建 立会话
S->C: SETUP response //S建 立会话，返回会话标识符及会话相关信息
④ C->S: PLAY request //C请求播放
S->C: PLAY response //S回 应请求信息
S->C: 发送流媒体数据
⑤ C->S: TEARDOWN request //C请 求关闭会话
S->C: TEARDOWN response //S回应请求
上述的过程是标准的RTSP流程，其中第3步和第4步是必需的。
参考http：和rtsp在功能上有相似重叠的地方，RTSP采用了HTTP/1.1 大多数的状态码，并且增加了RTSP特定的状态码。
HTTP协议定义了8种可能的请求方法：
————————————
GET 检索URI中标识资源的一个简单请求
HEAD 与GET方法相同，服务器只返回状态行和头标，并不返回请求文档
POST 服务器接受被写入客户端输出流中的数据的请求
PUT 服务器保存请求数据作为指定URI新内容的请求
DELETE 服务器删除URI中命名的资源的请求
OPTIONS 关于服务器支持的请求方法信息的请求
TRACE Web服务器反馈Http请求和其头标的请求
CONNECT 已文档化但当前未实现的一个方法，预留做隧道处理
————————————
rtsp和http的协议规范分别在RFC2326 和 RFC2616有详细描述
mms协议为微软的私有协议，未公开协议。采用私有自定义控制结构体来发送命令，而不是像http，rtsp协议采用发送文本命令控制