第一部分: 总体概述
一、流媒体概念
流媒体包含广义和狭义两种内涵：广义上的流媒体指的是使音频和视频形成稳定和连续的传输流和回放流的一系列技术、方法和协议的总称，即流媒体技术；狭义上的流媒体是相对于传统的下载-回放方式而言的，指的是一种从Internet 上获取音频和视频等多媒体数据的新方法，它能够支持多媒体数据流的实时传输和实时播放。通过运用流媒体技术，服务器能够向客户机发送稳定和连续的多媒体数据流，客户机在接收数据的同时以一个稳定的速率回放，而不用等数据全部下载完之后再进行回放。
二、流媒体协议
实时传输协议（Real- time Transport Protocol，RTP）是在Internet 上处理多媒体数据流的一种网络协议，利用它能够在一对一（unicast，单播）或者一对多（multicast，多播）的网络环境中实现传流媒体数据的实时传输。RTP 通常使用UDP来进行多媒体数据的传输，但如果需要的话可以使用TCP或者ATM等其它协议，整个RTP协议由两个密切相关的部分组成：RTP数据协议和RTP控制协议。实时流协议（Real Time Streaming Protocol，RTSP）最早由Real Networks和Netscape公司共同提出，它位于RTP和RTCP之上，其目的是希望通过IP 网络有效地传输多媒体数据。
实时流传输协议RTSP（Real-time Streaming Protocol, RFC 2326）、
实时传输协议（RTP Real-time Transfer Protocol，RFC 3550）、
实时传输控制协议（RTCP Real-time Transport Control Protocol，RFC 1889）、
会话描述协议（SDP Session Description Protocol，RFC 2327）。
目前在流媒体传输技术中使用最多的就是基于RTSP/RTP的流媒体传输。RTSP对应ISO网络七层参考模型的应用层，和HTTP 有点类似，也是一种文本协议，主要是实现对流的控制。有关RTSP/RTP以及RTCP之间的关系可以参考下图：
通过上图可以看出三者之间的关系，RTSP协议基于TCP 完成RTSP请求报文和响应报文的传输，RTP协议基于UDP协议完成流媒体数据的实时传输，RTCP协议基于UDP协议提供客户端和服务器有关当前网络拥塞和以及实时流传输质量等信息。
在智能网络相机上也需要实现基于RTSP/RTP的H.264实时流的传输。RTCP暂时还未实现，这在流媒体技术中是比较高级的应用。
第二部分:RTP协议
RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据
报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含
义是固定的，而负载则可以是音频或者视频数据。RTP数据报的头部格式如图1所示：
图1 RTP头部格式
其中比较重要的几个域及其意义如下：
1、Version（V）: RFC 1889 Version(2)
2、Padding填充标志（P）：False
3、Extension扩展标志（X）：False
4、CSRC(Contributing source identifiers count)记数（CC）: 表示CSRC标识的数目。CSRC标识紧跟在RTP固定头部之后，用来表示RTP数据报的来源，RTP协议允许在同一个会话中存在多个数据源，它们可以通过RTP混合器合并为一个数据源。例如，可以产生一个CSRC列表来表示一个电话会议，该会议通过一个RTP混合器将所有讲话者的语音数据组合为一个RTP数据源。
5、M：标志位。标志位的具体解释可由具体协议规定。如可用于帧边界标志。
6、负载类型(Payload type)（PT）：标明RTP负载的格式，包括所采用的编码算法、采样频率、承载通道等。例如，类型2表明该RTP数据包中承载的是用ITU G.721算法编码的语音数据，采样频率为8000Hz，并且采用单声道。对于H.264来说，该值为105。
7、序列号(sequence number)：用来为接收方提供探测数据丢失的方法，但如何处理丢失的数据则是应用程序自己的事情，RTP协议本身并不负责数据的重传。序列号用于对RTP包进行计数。每发送一个RTP包，序列号加1。序列号的初始值可以置为零，也可用随机数开始。为了更加安全，应从一个随机初始化值开始。
8、时间戳(Timestamp)：记录了负载中第一个字节的采样时间，时间戳的增量为采样频率/帧率。接收方根据时间戳能够确定数据的到达是否受到了延迟抖动的影响，但具体如何来补偿延迟抖动则是应用程序自己的事情。按RFC3984规定，采用90000HZ的时钟，所以如果帧率为15，则时间戳增量为6000。RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位。
由上图可知，如果只有系列号，并不能完整按照顺序的将data播放出来，因为如果data中间有一段是没有资料的，只有系列号的话会造成错误，需搭配上让它知道在哪个时间将data正确播放出来，如此我们才能播放出正确无误的信息。
9、SSRC：同步源识别符。若只使用下个同步源，则SSRC应该一样。
10、CSRC：可无。
从RTP 数据报的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息，这些都为实时的流媒体传输提供了相应的基础。RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。RTP协议的目的是提供实时数据（如交互式的音频和视频）的端到端传输服务，因此在RTP中没有连接的概念，它可以建立在底层的面向连接或面向非连接的传输协议之上；RTP也不依赖于特别的网络地址格式，而仅仅只需要底层传输协议支持组帧（Framing）和分段（Segmentation）就足够了；另外RTP 本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下，RTP一般是在传输协议之上作为应用程序的一部分加以实现的，如图2所示：
RTP 是目前解决流媒体实时传输问题的最好办法，要在 Linux 平台上进行实时传送编程，可以考虑使用一些开放源代码的 RTP 库，如 LIBRTP、JRTPLIB 等。JRTPLIB 是一个面向对象的 RTP 库，它完全遵循 RFC 1889 设计，在很多场合下是一个非常不错的选择。JRTPLIB 是一个用 C++ 语言实现的 RTP 库，这个库使用socket 机制实现网络通讯因此可以运行在 Windows、Linux、FreeBSD、Solaris、Unix和VxWorks 等多种操作系统上。
第三部分:RTCP协议
RTCP 控制协议需要与RTP数据协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。RTP本身并不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。RTCP的一个关键作用就是能让接收方同步多个RTP流，比如音频和视频流。通常RTCP 会采用与RTP相同的分发机制，向会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状况进行诊断。
RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型：
SR 发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。
RR 接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。
SDES 源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。
BYE 通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。
APP由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。
RTCP数据报携带有服务质量监控的必要信息，能够对服务质量进行动态的调整，并能够对网络拥塞进行有效的控制。由于RTCP数据报采用的是多播方式，因此会话中的所有成员都可以通过RTCP数据报返回的控制信息，来了解其他参与者的当前情况。
在一个典型的应用场合下，发送媒体流的应用程序将周期性地产生发送端报告SR，该RTCP数据报含有不同媒体流间的同步信息，以及已经发送的数据报和字节的计数，接收端根据这些信息可以估计出实际的数据传输速率。
另一方面，接收端会向所有已知的发送端发送接收端报告RR，该RTCP数据报含有已接收数据报的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信息，发送端应用根据这些信息可以估计出往返时延，并且可以根据数据报丢失概率和时延抖动情况动态调整发送速率，以改善网络拥塞状况，或者根据网络状况平滑地调整应用程序的服务质量。
第四部分:SRTP和SRTCP协议
RTSP安全实时传输协议（Secure Real-time Transport Protocol或SRTP）是在实时传输协议（Real-time Transport Protocol或RTP）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由David Oran（思科）和Rolf Blom（爱立信）开发的，并最早由IETF于2004年3月作为RFC 3711发布。
由于实时传输协议和可以被用来控制实时传输协议的会话的实时传输控制协议（RTP Control Protocol或RTCP）有着紧密的联系，安全实时传输协议同样也有一个伴生协议，它被称为安全实时传输控制协议（Secure RTCP或SRTCP）；安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性，就像安全实时传输协议为实时传输协议提供的那些一样。
在使用实时传输协议或实时传输控制协议时，使不使用安全实时传输协议或安全实时传输控制协议是可选的；但即使使用了安全实时传输协议或安全实时传输控制协议，所有它们提供的特性（如加密和认证）也都是可选的，这些特性可以被独立地使用或禁用。唯一的例外是在使用安全实时传输控制协议时，必须要用到其消息认证特性。
第五部分: RTSP协议
一、RTSP协议概述
RTSP(Real-Time Stream Protocol )作为一个应用层协议，提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来，RTSP是一个流媒体表示协议，主要用来控制具有实时特性的数据发送，但它本身并不传输数据，而是必须依赖于下层传输协议所提供的某些服务。RTSP可以对流媒体提供诸如播放、暂停、快进等操作，它负责定义具体的控制消息、操作方法、状态码等，此外还描述了与RTP间的交互操作。
RTSP 和RTP的关系
RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP 控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。
一次基本的RTSP操作过程是:首先，客户端连接到流服务器并发送一个RTSP描述命令（DESCRIBE）。流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。客户端再分析该SDP描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，RTSP建立命令告诉服务器客户端用于接收媒体数据的端口。流媒体连接建立完成后，客户端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到客户端。在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话
二、RTSP协议与HTTP协议区别
RTSP在制定时较多地参考了HTTP/1.1协议，甚至许多描述与HTTP/1.1完全相同。RTSP之所以特意使用与HTTP/1.1类似的语法和操作，在很大程度上是为了兼容现有的Web基础结构，正因如此，HTTP/1.1的扩展机制大都可以直接引入到RTSP中。
1.RTSP引入了几种新的方法，比如DESCRIBE、PLAY、SETUP 等，并且有不同的协议标识符，RTSP为rtsp
1.0,HTTP为http 1.1；
2.HTTP是无状态的协议，而RTSP为每个会话保持状态；
3.RTSP协议的客户端和服务器端都可以发送Request请求，而在HTTPF 协议中，只有客户端能发送Request
请求。
4.在RTSP协议中，载荷数据一般是通过带外方式来传送的(除了交织的情况)，及通过RTP协议在不同的通
道中来传送载荷数据。而HTTP协议的载荷数据都是通过带内方式传送的，比如请求的网页数据是在回应的消息体中携带的。
5.使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化；
6.RTSP使用URI请求时包含绝对URI。而由于历史原因造成的向后兼容性问题，HTTP/1.1只在请求中包含绝
对路径，把主机名放入单独的标题域中；
三、RTSP重要术语
1、集合控制(Aggregate control ):
对多个流的同时控制。对音频/视频来讲，客户端仅需发送一条播放或者暂停消息就可同时控制音频流和视频流。
2、实体(Entity)：
作为请求或者回应的有效负荷传输的信息。由以实体标题域（entity-header field）形式存在的元信息和以实体主体（entity body）形式存在的内容组成
3、容器文件（Container file）：
可以容纳多个媒体流的文件。RTSP服务器可以为这些容器文件提供集合控制。
4、RTSP会话(RTSP session )：
RTSP交互的全过程。对一个电影的观看过程,会话(session)包括由客户端建立媒体流传输机制(SETUP)，使用播放(PLAY)或录制(RECORD)开始传送流，用停止(TEARDOWN)关闭流。
四、RTSP请求消息
1.消息格式：
方法 URI RTSP版本CR LF
消息头 CR LF CR LF
消息体 CR LF
其中方法包括OPIONS、DESCRIBE、SETUP、PLAY、TEARDOWN等,URI是接受方的地址,例
如:rtsp://192.168.0.1/video1.3gp。
RTSP版本一般都是 RTSP/1.0。每行后面的CR LF表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个CR LF
消息体是可选的，有的Request消息并不带消息体。
五、RTSP回应消息
1.消息格式：
RTSP版本状态码解释CR LF
消息头 CR LF CR LF
消息体 CR LF
其中RTSP版本一般都是RTSP/1.0,状态码是一个数值，用于表示Request消息的执行结果,比如200表示成功,解释是与状态码对应的文本解释.
六、RTSP 重要方法
1.OPTIONS:
用于得到服务器提供的可用方法；
OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0
CSeq: 1 //每个消息都有序号来标记，第一个包通常是option请求消息
服务器的回应信息会在Public字段列出提供的方法。如:
RTSP/1.0 200 OK
CSeq: 1 //每个回应消息的cseq数值和请求消息的cseq相对应
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
2.DESCRIBE：
客户端向服务器端发送DESCRIBE，用于得到URI所指定的媒体描述信息，一般是SDP信息。客户端通过Accept 头指定客户端可以接受的媒体述信息类型。
C->S:
DESCRIBE rtsp://https://www.doczj.com/doc/735911367.html,/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl, application/mheg)
服务器回应URI指定媒体的描述信息:如:
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp //表示回应为SDP信息
Content-Length: 376
//这里为一个空行
//以下为具体的SDP信息
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=https://www.doczj.com/doc/735911367.html,/staff/M.Handley/sdp.03.ps
e=mjh@https://www.doczj.com/doc/735911367.html, (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portrait
媒体初始化是任何基于RTSP系统的必要条件，但RTSP规范并没有规定它必须通过DESCRIBE方法完成。RTSP 客户端可以通过以下方法来接收媒体描述信息：
a)通过DESCRIBE方法；
b)其它一些协议（HTTP，email附件，等）；
c)通过命令行或标准输入设备
3.SETUP：
用于确定转输机制，建立RTSP会话。客户端能够发出一个SETUP请求为正在播放的媒体流改变传输参数，服务器可能同意这些参数的改变。若是不同意，它必须响应错误"455 Method Not Valid In This State"。
Request 中的Transport头字段指定了客户端可接受的数据传输参数；Response中的Transport 头字段包含了由服务器选出的传输参数。
如:
C->S: SETUP rtsp://https://www.doczj.com/doc/735911367.html,/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589
服务器端对SETUP Request产生一个Session Identifiers。如:
S->C: RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344 //产生一个Session ID
Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257
4.PLAY：
PLAY方法告知服务器通过SETUP中指定的机制开始发送数据。在尚未收到SETUP请求的成功应答之前，客户端不可以发出PLAY请求。
PLAY请求将正常播放时间（normal play time）定位到指定范围的起始处，并且传输数据流直到播放范围结束。PLAY请求可能被管道化（pipelined），即放入队列中（queued）；服务器必须将PLAY请求放到队列中有序执行。也就是说，后一个PLAY请求需要等待前一个PLAY请求完成才能得到执行。
比如，在下例中，不管到达的两个PLAY请求之间有多紧凑，服务器首先play第10到15秒，然后立即第20到25秒，最后是第30秒直到结束。
C->S: PLAY rtsp://https://www.doczj.com/doc/735911367.html,/audio RTSP/1.0
CSeq: 835
Session: 12345678
Range: npt=10-15 //设置播放时间的范围
C->S: PLAY rtsp://https://www.doczj.com/doc/735911367.html,/audio RTSP/1.0
CSeq: 836
Session: 12345678
Range: npt=20-25
C->S: PLAY rtsp://https://www.doczj.com/doc/735911367.html,/audio RTSP/1.0
CSeq: 837
Session: 12345678
Range: npt=30-
Range头可能包含一个时间参数。该参数以UTC格式指定了播放开始的时间。如果在这个指定时间后收到消息，那么播放立即开始。时间参数可能用来帮助同步从不同数据源获取的数据流。
不含Range头的PLAY请求也是合法的。它从媒体流开头开始播放，直到媒体流被暂停。如果媒体流通过PAUSE 暂停，媒体流传输将在暂停点（the pause point）重新开始。
如果媒体流正在播放，那么这样一个PLAY请求将不起更多的作用，只是客户端可以用此来测试服务器是否存活。
5.PAUSE：
PAUSE请求引起媒体流传输的暂时中断。如果请求URL中指定了具体的媒体流，那么只有该媒体流的播放和记录被暂停（halt）。比如，指定暂停音频，播放将会无声。如果请求URL指定了一组流，那么在该组中的所有流的传输将被暂停。如：
C->S: PAUSE rtsp://https://www.doczj.com/doc/735911367.html,/fizzle/foo RTSP/1.0
CSeq: 834
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT
PAUSE请求中可能包含一个Range头用来指定何时媒体流暂停，我们称这个时刻为暂停点（pause point）。该头必须包含一个精确的值，而不是一个时间范围。媒体流的正常播放时间设置成暂停点。当服务器遇到在任何当前挂起（pending）的PLAY请求中指定的时间点后，暂停请求生效。如果Range头指定了一个时间超出了任何一个当前挂起的PLAY请求，将返回错误"457 Invalid Range" 。如果一个媒体单元（比如一个音频或视频禎）正好在一个暂停点开始，那么表示将不会被播放或记录。如果Range头缺失，那么在收到暂停消息后媒体流传输立即中断，并且暂停点设置成当前正常播放时间。
6.TEARDOWN：
TEARDOWN请求终止了给定URI的媒体流传输，并释放了与该媒体流相关的资源。如：
C->S: TEARDOWN rtsp://https://www.doczj.com/doc/735911367.html,/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 892
七、RTSP重要头字段参数
1.Accept:
用于指定客户端可以接受的媒体描述信息类型。比如:
Accept: application/rtsl, application/sdp;level=2
2.Bandwidth:
用于描述客户端可用的带宽值。
3.CSeq：
指定了RTSP请求回应对的序列号，在每个请求或回应中都必须包括这个头字段。对每个包含一个给定序列号的请求消息，都会有一个相同序列号的回应消息。
4.Rang：
用于指定一个时间范围，可以使用SMPTE、NTP或clock时间单元。
5.Session:
Session头字段标识了一个RTSP会话。Session ID 是由服务器在SETUP的回应中选择的，客户端一当得到Session ID后，在以后的对Session 的操作请求消息中都要包含Session ID.
6.Transport:
Transport头字段包含客户端可以接受的转输选项列表，包括传输协议，地址端口，TTL等。服务器端也通过这个头字段返回实际选择的具体选项。如:
Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",
RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
八、简单的RTSP消息交互过程
C表示RTSP客户端,S表示RTSP服务端
第一步：查询服务器端可用方法
C->S:OPTION request //询问S有哪些方法可用
S->C:OPTION response //S回应信息的public头字段中包括提供的所有可用方法
第二步：得到媒体描述信息
C->S:DESCRIBE request //要求得到S提供的媒体描述信息
S->C:DESCRIBE response //S回应媒体描述信息，一般是sdp信息
第三步：建立RTSP会话
C->S:SETUP request //通过Transport头字段列出可接受的传输选项，请求S建立会话
S->C:SETUP response //S建立会话，通过Transport头字段返回选择的具体转输选项，并返回建立的Session ID;
第四步：请求开始传送数据
C->S:PLAY request //C请求S开始发送数据
S->C:PLAY response //S回应该请求的信息
第五步：数据传送播放中
S->C:发送流媒体数据 //通过RTP协议传送数据
第六步：关闭会话，退出
C->S:TEARDOWN request //C请求关闭会话
S->C:TEARDOWN response //S回应该请求
上述的过程只是标准的、友好的rtsp流程，但实际的需求中并不一定按此过程。
其中第三和第四步是必需的！第一步，只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。第二步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。
第四部分:SDP协议
RTSP需要一个表示描述（Presentation Description），以便说明一个流媒体会话的基本属性，包括媒体类型和格式、所需要的传输带宽、播放的时间范围、所需Buffer信息等。The Session Description Protocol (SDP, RFC 2327 [6]) may be used to describe streams or presentations in RTSP.
一、SDP协议概述
SDP(Session Description Protocol )会话描述协议，用于描述多媒体会话，它为会话通知、会话初始和其它形式的多媒体会话初始等操作提供服务。
SDP 的设计宗旨是通用性协议，所有它可以应用于很大范围的网络环境和应用程序，但 SDP 不支持会话内容或媒体编码的协商操作。
SDP信息包括：
?会话名称和目标；
?会话活动时间；
?构成会话的媒体；
?有关接收媒体的信息、地址等。
二、SDP格式
SDP 信息是文本信息，UTF-8 编码采用 ISO 10646 字符设置。SDP 会话描述如下（标注*符号的表示可选字段）：
?v= （协议版本）
?o= （所有者/创建者和会话标识符）
?s= （会话名称）
?i=* （会话信息）
?u=* （URI 描述）
?e=* （Email 地址）
?p=* （电话号码）
?c=* （连接信息― 如果包含在所有媒体中，则不需要该字段）
?b=* （带宽信息）
一个或更多时间描述（如下所示）：
?z=* （时间区域调整）
?k=* （加密密钥）
?a=* （0个或多个会话属性线路）
?0个或多个媒体描述（如下所示）
时间描述
?t= （会话活动时间）
?r=* （0或多次重复次数）
媒体描述
?m= （媒体名称和传输地址）
?i=* （媒体标题）
?c=* （连接信息—如果包含在会话层则该字段可选）
?b=* （带宽信息）
?k=* （加密密钥）
?a=* （0个或多个会话属性线路）
一、SDP示例
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=https://www.doczj.com/doc/735911367.html,/staff/M.Handley/sdp.03.ps
e=mjh@https://www.doczj.com/doc/735911367.html, (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb
a=orient:portrait
//字段解释
V=0 ;V ersion 给定了SDP协议的版本
o=
s=
i=
u=
e=
c=
t=
a=
a=
m=
第五部分:MMS协议
三、MMS协议概述
Microsoft Media Services(MMS) was Microsoft's proprietary network streaming protocol used to transfer unicast data in Windows Media Services (previously called NetShow Services). MMS can be transported via UDP or TCP. The MMS default port is UDP/TCP 1755.
Microsoft deprecated MMS in favor of RTSP in 2003 with the release of the Windows Media Services 9 Series, but continued to support the MMS for some time in the interest of backwards compatibility. Support for the protocol was finally dropped in Windows Media Services 2008[1].
Note however that Microsoft still recommends[2] using "mms://" as a "protocol rollover[3]URL". As part of protocol rollover a Windows Media Player 11 client opening an "mms://" URL will attempt to connect first with RTSP over UDP and if that fails it will attempt RTSP over TCP. Earlier Windows Media Player clients as well as version 11 after having failed RTSP will attempt MMS over UDP, then MMS over TCP. If MMS failed a modified version of a HTTP over TCP connection will be attempted, this modified version is also referred to as MMSH[4].
第六部分:H.264 RTP传输
按照RFC3984协议实现H264视频流媒体
H.264的主要目标：
1．高的视频压缩比
2．良好的网络亲和性
一、H.264 基本流的结构
H.264 的基本流（elementary stream,ES）的结构分为两层，包括视频编码层（VCL，Video Coding Layer）和网络适配层（NAL，Network Abstraction Layer）。VCL 数据即编码处理的输出，它表示被压缩编码后的视频数据，而NAL负责以网络所要求的恰当的方式对数据进行打包和传送，包括编码数据和参数集信息等。VCL设计目标：尽可能地独立于网络的情况下进行高效的编解码。NAL设计目标：根据不同的网络把数据打包成相应的格式，将VCL 产生的比特字符串适配到各种各样的网络和多元环境中。引入NAL并使之与VCL分离带来的好处包括两方面：其一、使信号处理和网络传输分离，VCL 和NAL 可以在不同的处理平台上实现；其二、VCL 和NAL 分离设计，使得在不同的网络环境内，网关不需要因为网络环境不同而对VCL比特流进行重构和重编码。
在VCL数据传输或存储之前，这些编码的 VCL 数据，先被映射或封装进NAL单元（NALU, Network Abstraction Layer Unit）中，不同的NALU数据量各不相同。
NAL单元分为VCL和非VCL两种。VCL NAL单元包含视频图像采样信息，非VCL包含各种有关的附加信息，例如参数集（头部信息，应用到大量的VCL NAL单元）、提高性能的附加信息、定时信息等。
参数集：参数集是很少变化的信息，用于大量VCL NAL单元的解码，分为两种类型：
1．序列参数集，作用于一串连续的视频图像，即视频序列。
两个IDR图像之间为序列参数集。IDR和I帧的区别见下面。
2．图像参数集，作用于视频序列中的一个或多个个别的图像
序列和图像参数集机制，减少了重复参数的传送，每个VCL NAL单元包含一个标识，指向有关的图像参数集，每个图像参数集包含一个标识，指向有关的序列参数集的内容因此，只用少数的指针信息，引用大量的参数，大大减少每个VCL NAL单元重复传送的信息。
序列和图像参数集可以在发送VCL NAL单元以前发送，并且重复传送，大大提高纠错能力。序列和图像参数集可以在“带内”，也可以用更为可靠的其他“带外”通道传送。
1.H.264起始码
分组都有头部，解码器可以很方便的检测出NAL的分界，依次取出NAL进行解码。但为了节省码流，H.264没有另外在NAL的头部设立表示起始位置的句法元素。如果编码数据是存储在介质上的，由于NAL是依次紧密相连的，解码器就无法在数据流中分辨出每个NAL的起始位置和终止位置。解决方案：在每个NAL前添加起始码：0X000001
H.264编码时，在每个NAL前添加起始码 0x000001，解码器在码流中检测到起始码，当前NAL结束。为了防止NAL内部出现0x000001的数据，h.264又提出'防止竞争 emulation prevention"机制，在编码完一个NAL时，如果检测出有连续两个0x00字节，就在后面插入一个0x03。当解码器在NAL内部检测到0x000003的数据，就把0x03抛弃，恢复原始数据。
0x000000 >>>>>> 0x00000300
0x000001 >>>>>> 0x00000301
0x000002 >>>>>> 0x00000302
0x000003 >>>>>> 0x00000303
为此，我们可以知道：在NAL单元中，下面的三字节序列不应在任何字节对齐的位置出现
0X000000
0X000001
0X000002
2. MPEG4起始码
MPEG4的特色是VOP，没有NALU的概念，仍使用startcode对每帧进行分界。MPEG4的起始码是0x000001. 另
外MPEG4中很多起始码也很有用，比如video_object_sequence_start_code 0x000001B0 表示一个视频对象序列的开始,VO_start_code 0x000001B6 表示一个VOP的开始. 0x000001B6之后的两位，是00表示 I frame， 01 表示 P frame， 10 表示 B frame.
当数据流是储存在介质上时，在每个NALU 前添加起始码：0x000001，用来指示一个 NALU的起始和终止位置。在这样的机制下，解码器在码流中检测起始码，作为一个NALU得起始标识，当检测到下一个起始码时，当前NALU 结束。每个 NALU单元由一个字节的 NALU头（NALU Header）和若干个字节的载荷数据（RBSP, Raw Byte Sequence Payload）组成。
图 1 NAL 单元序列
其中NALU 头的格式如图2 所示：
F：forbidden_zero_bit.1 位：如果有语法冲突，则为 1。当网络识别此单元存在比特错误时，可将其设为 1，以便接收方丢掉该单元。
NRI：nal_ref_idc.2 位：用来指示该NALU 的重要性等级。值越大，表示当前NALU越重要，需要优先受到保护。如果当前NAL是属于参考帧的片，或是序列参数集，或是图像参数集这些重要的单位时，本句法元素必需大于0。
Type：5 位：指出NALU 的类型，0到23的值。具体如表1 所示：
需要特别指出的是，NRI 值为 7 和 8 的NALU 分别为序列参数集（sps）和图像参数集（pps）。参数集是一组很少改变的，为大量VCL NALU 提供解码信息的数据。其中序列参数集作用于一系列连续的编码图像，而图像参数集作用于编码视频序列中一个或多个独立的图像。如果解码器没能正确接收到这两个参数集，那么其他NALU也是无法解码的。因此它们一般在发送其它 NALU之前发送，并且使用不同的信道或者更加可靠的传输协议（如TCP）进行传输，也可以重复传输。
H.264 中定义的sequence parameter sets中包括了一个图像序列的所有信息.它是H.264的基础之一,是编码前进行初始化的关键的一环。
H.264中定义的picture parameter sets中包括了一个图像的所有切片信息.它也是H.264的基础之一,是编码前进行初始化的关键的一环。
三种不同的数据形式：
SODB 数据比特串－－＞最原始的编码数据
RBSP的基本结构是：在原始编码数据(String of data bits, SODB)的后面填加了结尾比特。一个 bit“1”若干比特“0”，以便字节对齐。典型的RBSP单元序列如果2所示，
图像的相关信息存储在网络提取层（NAL）的RBSP结构中，序列参数集（SPS）、图像参数集（PPS）、增强信息（SEI）。SPS和PPS属于参数集，两标准采用参数集机制是为了将一些主要的序列、图像参数（解码图像尺寸、片组数、参考帧数、量化和滤波参数标记等）与其他参数分离，通过解码器先解码出来。
EBSP扩展字节序列载荷-->在RBSP基础上填加了仿校验字节（0X03）它的原因是：在NALU加到Annexb上时，需要添加每组NALU之前的开始码StartCodePrefix,如果该NALU对应的slice为一帧的开始则用4位字节表示，ox00000001,否则用3位字节表示ox000001.为了使NALU主体中不包括与开始码相冲突的，在编码时，每遇到两个字节连续为0，就插入一个字节的0x03。解码时将0x03去掉。也称为脱壳操作。
处理过程：
1．将VCL层输出的SODB封装成nal_unit， Nal_unit是一个通用封装格式，可以适用于有序字节流方式和IP 包交换方式。
2．针对不同的传送网络（电路交换|包交换），将nal_unit 封装成针对不同网络的封装格式。
第一步的具体过程：
VCL层输出的比特流SODB（String Of Data Bits），到nal_unit之间，经过了以下三步处理：
1.SODB字节对齐处理后封装成RBSP（Raw Byte Sequence Payload）。
2.为防止RBSP的字节流与有序字节流传送方式下的SCP（start_code_prefix_one_3bytes，0x000001）出现字节竞争情形，循环检测RBSP前三个字节，在出现字节竞争时在第三字节前加入emulation_prevention_three_byte （0x03），
3. 防字节竞争处理后的RBSP再加一个字节的header(forbidden_zero_bit+ nal_ref_idc+ nal_unit_type)，封装成nal_unit.
第二步的具体过程：
case1：有序字节流的封装
byte_stream_nal_unit( NumBytesInNALunit ) {
while( next_bits( 24 ) != 0x000001 )
zero_byte /* equal to 0x00 */
if( more_data_in_byte_stream( ) ) {
start_code_prefix_one_3bytes /* equal to 0x000001 */ nal_unit( NumBytesInNALunit )
}
类似H.320和MPEG-2/H.222.0等传输系统，传输NAL作为有序连续字节或比特流，同时要依靠数据本身识别NAL单元边界。在这样的应用系统中，H.264/AVC规范定义了字节流格式，每个NAL单元前面增加3个字节的前缀，即同步字节。在比特流应用中，每个图像需要增加一个附加字节作为边界定位。还有一种可选特性，在字节流中增加附加数据，用做扩充发送数据量，能实现快速边界定位，恢复同步
Case2：IP网络的RTP打包封装
一个RTP分组里放入一个NALU，将NALU(包括同时作为载荷头标的NALU头)放入RTP的载荷中，设置RTP头标值。为了避免IP层对大分组的再一次分割，片分组的大小一般都要小于MTU尺寸。由于包传送的路径不同，解码端要重新对片分组排序，RTP包含的次序信息可以用来解决这一问题。
二、H.264的RTP封装
一个frame是可以分割成多个Slice来编码的，而一个Slice编码之后被打包进一个NAL单元，不过NAL单元除了容纳Slice编码的码流外，还可以容纳其他数据，比如序列参数集SPS。
如何使用RTP协议来传输H.264视频了?一个有效的办法就是从H.264视频中剥离出每个NALU，在每个 NALU 前添加相应的RTP包头，然后将包含RTP 包头和NALU 的数据包发送出去。下面就从RTP包头和NALU两方面分别阐述。完整的 RTP固定包头的格式在前面图 1 中已经指出，根据RFC3984[3]，这里详细给出各个位的具体设置。 V：版本号，2 位。根据RFC3984，目前使用的RTP 版本号应设为0x10。
P：填充位，1 位。当前不使用特殊的加密算法，因此该位设为 0。
X：扩展位，1 位。当前固定头后面不跟随头扩展，因此该位也为 0。
CC：CSRC 计数，4 位。表示跟在 RTP 固定包头后面CSRC 的数目，对于本文所要实现的基本的流媒体服务器来说，没有用到混合器，该位也设为 0x0。
M：标示位，1 位。如果当前 NALU为一个接入单元最后的那个NALU，那么将M位置 1；或者当前RTP 数据包为一个NALU 的最后的那个分片时（NALU 的分片在后面讲述），M位置 1。其余情况下M 位保持为 0。
PT：载荷类型，7 位。对于H.264 视频格式，当前并没有规定一个默认的PT 值。因此选用大于 95 的值可以。此处设为0x60（十进制96）。
SQ：序号，16 位。序号的起始值为随机值，此处设为 0，每发送一个RTP 数据包，序号值加 1。
TS：时间戳，32 位。同序号一样，时间戳的起始值也为随机值，此处设为0。根据RFC3984，与时间戳相应的时钟频率必须为90000HZ。
SSRC：同步源标示，32 位。SSRC应该被随机生成，以使在同一个RTP会话期中没有任何两个同步源具有相同的SSRC 识别符。此处仅有一个同步源，因此将其设为0x12345678。
RTP结构包括8个字节的前缀，即四个字节的RTP大小和四个字节的识别符。如图3所示。RTP大小包括12个字节的RTP头+ RTP数据。
图3 示例：RTP起始码
通过上面的论述可知，对于H264码流，其RTP封装就是将原始的NALU起始码前缀替换成RTP起始码+RTP 头部。注意，如果进行组合封装或拆包封装，RTP固定头部后面还会有一些指示组合或拆包的字节。
起始码：如果 NALU 对应的 Slice 为一帧的开始，则用 4 字节表示，即 0x00000001；否则用 3 字节表示，
0x000001。
NAL Header：F，NRI（优先级），TYPE（类型）。
脱壳操作：为了使 NALU 主体不包括起始码，在编码时每遇到两个字节（连续）的 0，就插入一字节 0x03，以和起始码相区别。解码时，则将相应的 0x03 删除掉。
2.2 RTP封装方法
对于每一个NALU，根据其包含的数据量的不同，其大小也有差异。在IP网络中，当要传输的IP 报文大小超过最大传输单元MTU（Maximum Transmission Unit ）时就会产生IP分片情况。在以太网环境中可传输的最大 IP 报文（MTU）的大小为 1500 字节。如果发送的IP数据包大于MTU，数据包就会被拆开来传送，这样就会产生很多数据包碎片，增加丢包率，降低网络速度。对于视频传输而言，若RTP 包大于MTU 而由底层协议任意拆包，可能会导致接收端播放器的延时播放甚至无法正常播放。因此对于大于MTU 的NALU 单元，必须进行拆包处理。
RFC3984 给出了3 中不同的RTP 打包方案：即单包封装、组合封装和拆包封装。RTP包的接收端只需要检测RTP头部12个字节之后的第一个字节便可知道该包是单包封装、组合封装还是拆分封装。当使用单包封装时，该字节只低五位为1-23的数值；当进行组合封装时，该五位为24-27的数值；当进行拆包封装时，为28或29。
（1）单包封装（Single NALU Packet）
当数据包大小小于MTU时，一般采用单包封装,即一个RTP包仅由一个完整的NALU组成。
对于一个原始的H.264 NALU单元常由[Start Code][NALU Header][NALU Payload]三部分组成,其中 Start Code 用于标示这是一个 NALU 单元的开始,必须是 "00 00 00 01" 或 "00 00 01",NALU 头仅一个字节,其后都是 NALU 单元内容。打包时去除 "00 00 01" 或 "00 00 00 01" 的开始码,把其他数据封包的 RTP 包即可。
如有一个 H.264 的 NALU 是这样的:
[00 00 00 01 67 42 A0 1E 23 56 0E 2F ... ]
这是一个序列参数集 NAL 单元. [00 00 00 01] 是四个字节的开始码, 67 是 NALU 头, 42 开始的数据是 NALU 内容.
封装成 RTP 包将如下:
[ RTP Header ] [ 67 42 A0 1E 23 56 0E 2F ]
即只要去掉 4 个字节的开始码就可以了.
（2）拆包封装（Fragmentation Unit）
而当 NALU 的长度超过 MTU 时, 就必须对 NALU 单元进行分片封包.拆包封装有两种拆包方法，即FU-A和FU-B。本人采用FU-A方法进行拆包封装。FU-A封装结构如图4所示。
图4 FU-A结构
FU indicator:为FU-A封装指示字节。
图5 FU indicator
FU indicator位用于标识该RTP包为拆包封装。由图5可见，其结构和NALU的头部结构相同。其中F为0，NRI和该包所荷载NALU头部中NRI相同，TYPE为28（若采用FU-B，则TYPE值为29）。
FU header: FU header为FU头部。
图6 FU header
S位，指示该RTP包是否是原NALU中的第一个分片，若是第一个分片，则置1；
E位，若该分片是本次拆包的最后一个分片，则该位置1；
R位，保留，置0；
TYPE和FU indicator中的TYPE相同。
拆包：编码时需要将原由的一个NAL按照FU-A进行分片，原始的NAL头的前三位为FU indicator的前三位（F，NRI不变），原始的NAL头的后五位为FU header的后五位（Type不变），FU indicator与FU header的剩余位数根据实际情况决定。
解析：当接收端收到FU-A的分片数据，需要将所有的分片包组合还原成原始的NAI包时，RTP包含的次序信息可以用来解决这一问题。还原后的NAI头的八位是由FU indicator 的前三位加FU header的后五位组成，即
Nal_uint_type= (fu_indicator&0xe0) | (fu_header&0x1f)
（3）组合封装（Aggregation Packet）:
当 NALU 的长度特别小时, 可以把几个 NALU 单元封在一个 RTP 包中，从而提高传输效率。组合封装有四种组合方式，分别为: STAP-A, STAP-B, MTAP16, MTAP24。这里只介绍STAP-A模式：
例：
如有一个 H.264 的 NALU 是这样的:
[00 00 00 01 67 42 A0 1E 23 56 0E 2F ... ]
[00 00 00 01 68 42 B0 12 58 6A D4 FF ... ]
封装成 RTP 包将如下:
[ RTP Header ] [78 (STAP-A头，占用1个字节)] [第一个NALU长度 (占用两个字节)] [ 67 42 A0 1E 23 56 0E 2F ] [第二个NALU长度 (占用两个字节)] [68 42 B0 12 58 6A D4 FF ... ]
4. H.264 流媒体传输系统的实现
一个完整的流媒体传输系统包含服务器端和客户端两个部分[5][6]。对于服务器端，其主要任务是读取H.264 视频，从码流中分离出每个NALU 单元，分析NALU 的类型，设置相应的 RTP 包头，封装 RTP 数据包并发送。而对于客户端来说，其主要任务则是接收 RTP数据包，从RTP 包中解析出NALU 单元，然后送至解码器进行解码播放。该流媒体传输系统的框架如图3 所示。
rtsp简介(ZT) Real Time Streaming Protocol或者RTSP（实时流媒体协议），是由Real network 和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。RTSP提供一种可扩展的框架，使能够提供能控制的，按需传输实时数据，比如音频和视频文件。源数据可以包括现场数据的反馈和存贮的文件。rtsp对流媒体提供了诸如暂停，快进等控制，而它本身并不传输数据，rtsp作用相当于流媒体服务器的远程控制。传输数据可以通过传输层的tcp，udp协议，rtsp也提供了基于rtp传输机制的一些有效的方法。RTSP消息格式: RTSP的消息有两大类,一是请求消息(request),一是回应消息(response),两种 消息的格式不同. 请求消息: 方法URI RTSP版本CR LF 消息头CR LF CR LF 消息体CR LF 其中方法包括OPTION回应中所有的命令,URI是接受方的地址,例如 :rtsp://192.168.20.136 RTSP版本一般都是RTSP/1.0.每行后面的CR LF表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个CR LF 回应消息: RTSP版本状态码解释CR LF 消息头CR LF CR LF 消息体CR LF 其中RTSP版本一般都是RTSP/1.0,状态码是一个数值,200表示成功,解释是与状态码对应的文本解释. 简单的rtsp交互过程: C表示rtsp客户端,S表示rtsp服务端 1.C->S:OPTION request //询问S有哪些方法可用 1.S->C:OPTION response //S回应信息中包括提供的所有可用方法 2.C->S:DESCRIBE request //要求得到S提供的媒体初始化描述信息 2.S->C:DESCRIBE response //S回应媒体初始化描述信息，主要是sdp 3.C->S:SETUP request //设置会话的属性，以及传输模式，提醒S建立会 话 3.S->C:SETUP response //S建立会话，返回会话标识符，以及会话相关信息 4.C->S:PLAY request //C请求播放 4.S->C:PLAY response //S回应该请求的信息 S->C:发送流媒体数据 5.C->S:TEARDOWN request //C请求关闭会话 5.S->C:TEARDOWN response //S回应该请求
竭诚为您提供优质文档/双击可除 sdp协议详解 篇一：sdp协议原理及应用 内部公开▲ sdp协议原理及应用 编者：尚森 审核：王高原 中兴通讯固网交换用服部 内部公开▲ 修改记录 内部公开▲ 目录 第1章sdp的协议原理................................................. ................................................... (1) 1.1sdp的概述................................................. ...................................................
(1) 1.2sdp协议字段................................................. ................................................... .. (1) 1.3说明................................................. ................................................... .. (3) 第2章sdp的应用................................................. ................................................... .. (4) 2.1sdp在sip电话中的应用2.2sdp各type的详细解释 2.3sdp在h.248的应用第3章sdp的实例应用. 3.1sdp的举例描述3.2h.248中sdp消息举例描述. 内部公开▲ 第1章sdp的协议原理 1.1sdp的概述 sdp（sdp:sessiondescriptionprotocol会话描述协议）是由ietF（interne工程任务组）作为RFc4566颁布，描述流媒体初始化参数的格式。其目的就是在媒体会话中，传递
RTSP协议学习笔记 目录 RTSP协议学习笔记 (1) 第一部分:RTSP协议 (2) 一、RTSP协议概述 (2) 二、RTSP协议与HTTP协议区别 (2) 三、RTSP重要术语 (3) 1.集合控制(Aggregate control ): (3) 2.实体(Entity)： (3) 3.容器文件（Container file）： (3) 4.RTSP会话(RTSP session )： (3) 四、RTSP请求消息 (3) 1.消息格式： (3) 五、RTSP回应消息 (4) 1.消息格式： (4) 六、RTSP 重要方法 (4) 1. OPTIONS: (4) 2. DESCRIBE： (5) 3. SETUP： (6) 4. PLAY： (7) 5. PAUSE： (8) 6. TEARDOWN： (8) 七、RTSP重要头字段参数 (9) 1.Accept: (9) 2.Bandwidth: (9) 3. CSeq： (9) 4. Rang： (9) 5.Session: (9) 6.Transport: (9) 八、简单的RTSP消息交互过程 (10) 1.第一步：查询服务器端可用方法 (10) 2.第二步：得到媒体描述信息 (10) 3.第三步：建立RTSP会话 (10) 4.第四步：请求开始传送数据 (10) 5.第五步：数据传送播放中 (10) 6.第六步：关闭会话，退出 (10) 第二部分:SDP协议 (11) 一、SDP协议概述 (11) 二、SDP格式 (11) 三、SDP示例 (12) 第三部分:MMS协议 (13) 一、MMS协议概述 (13)
一、 RTP : （Real-time Transport Protocol，实时传输协议）是一个网络传输协议 RTP报文格式 RTP报文由两部分组成：报头和有效载荷。RTP报头格式如图所示，其中： 1.V：RTP协议的版本号，占2位，当前协议版本号为2。 2.P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。 3.X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头。 https://www.doczj.com/doc/735911367.html,：CSRC计数器，占4位，指示CSRC 标识符的个数。 5.M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。 6.同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。 7.特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。 8.PT: 有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM 图像等。 9.序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。接收者通过序列号来检测报文丢失情况，重新排序报文，恢复数据。 10.时戳(Timestamp)：占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。 图 RTP报头格式 二、RTCP：RTP 控制协议（RTCP：RTP Control Protocol）
RTSP协议学习笔记
目录 RTSP协议学习笔记 (1) 第一部分:RTSP协议 (3) 一、RTSP协议概述 (3) 二、RTSP协议与HTTP协议区别 (3) 三、RTSP重要术语 (4) 1.集合控制(Aggregate control): (4) 2.实体(Entity)： (4) 3.容器文件（Container file）： (4) 4.RTSP会话(RTSP session)： (4) 四、RTSP请求消息 (4) 1.消息格式： (4) 五、RTSP回应消息 (5) 1.消息格式： (5) 六、RTSP重要方法 (5) 1.OPTIONS: (6) 2.DESCRIBE： (6) 3.SETUP： (7) 4.PLAY： (8) 5.PAUSE： (9) 6.TEARDOWN： (10) 七、RTSP重要头字段参数 (10) 1.Accept: (10) 2.Bandwidth: (10) 3.CSeq： (11) 4.Rang： (11) 5.Session: (11) 6.Transport: (11) 八、简单的RTSP消息交互过程 (11) 1.第一步：查询服务器端可用方法 (11) 2.第二步：得到媒体描述信息 (11) 3.第三步：建立RTSP会话 (12) 4.第四步：请求开始传送数据 (12) 5.第五步：数据传送播放中 (12) 6.第六步：关闭会话，退出 (12) 第二部分:SDP协议 (12) 一、SDP协议概述 (12) 二、SDP格式 (13) 三、SDP示例 (14) 第三部分:MMS协议 (14) 一、MMS协议概述 (14)
E-mail：bryanj@https://www.doczj.com/doc/735911367.html, 译者：Bryan.Wong（王晶，宁夏固原） 译文版本：alpha 0.80 译文发布时间：2007-7-25 版权：本中文翻译文档之版权归王晶所有。可于非商业用途前提下自由转载，但必须保留此翻译及版权信息。 https://www.doczj.com/doc/735911367.html,/filedownload?user=bryanj&id=611206 网络工作组 H. Schulzrinne 请求注释: 2326 哥伦比亚大学. 类别: 标准跟踪 A. Rao Netscape R. Lanphier RealNetworks 1998年4月 实时流协议(RTSP) 本备忘录状态 本文为Internet社区描述了一种Internet标准跟踪协议，还需要讨论和建议以便进行改善。请查看最新版本的"Internet正式协议标准"（STD 1）了解本协议的标准化进程和状态。本备忘录的传播不受限制。 版权声明： 版权为The Internet Society 所有。所有权利保留。 摘要： 实时流协议（RTSP）是应用层协议，控制实时数据的传送。RTSP提供了一个可扩展框架，使受控、按需传输实时数据（如音频与视频）成为可能。数据源包括现场数据与存储在剪辑中的数据。本协议旨在于控制多个数据发送会话，提供了一种选择传送途径（如UDP、组播UDP与TCP）的方法，并提供了一种选择基于RTP (RFC1889)的传送机制的方法。
目录： 1 介绍 1.1 目的 1.2 要求 1.3 术语 1.4 协议特性 1.5 RTSP扩展 1.6 整体运作 1.7 RTSP状态 1.8 与其他协议的关系 2 符号协定 3 协议参数 3.1 RTSP版本 3.2 RTSP URL 3.3 会议标识 3.4 会话标识 3.5 SMPTE 相对时间戳 3.6正常播放时间 3.7 绝对时间 3.8 选项标签 3.8.1 用IANA注册新的选项标签*4 RTSP消息 4.1 消息类型 4.2 消息头
编号：_______________本资料为word版本，可以直接编辑和打印，感谢您的下载 rtsp协议摄像头 甲方：___________________ 乙方：___________________ 日期：___________________
rtsp协议摄像头 篇一：使用海康摄像头实现实时监控 使用海康摄像头实现实时监控 1. 基于Rtsp协议的windows平台监控。 1.1选取海康网络摄像头（支持Rtsp，标准h.264Rtp 封装的设备）。 1.2. 按照摄像头的使用说明书部署。假设访问ip地址是：http://192.168.0.64 ，登录后设置输出端口为：81, 则完整的取流地址为：主码流 rtsp://admin:12345@192.0.0.64:81/h264/ch1/main/av_s tream rtsp://admin:12345@192.0.0.64:81/mpeg-4/ch1/main/av _stream 子码流： rtsp://admin:12345@192.0.0.64/mpeg4/ch1/sub/av_stre am rtsp://admin:12345@192.0.0.64/h264/ch1/sub/av_strea m
1.3. 使用Vlc (支持标准的Rtsp流媒体)的播放器可以实时播放。 2. 基于active 控件的网页监控。 2.1. 选取海康网络摄像头并进行部署，假设访问地址为：http://192.168.0.64:6666 。 2.2. 访问http://192.168.0.64:6666 , ie 浏览器会提 示需要安装active 控件，将active控件存储到本地(ipcameraactivex.cab.cab )。 2.3. 解压ipcameraactivex.cab ,用记事本打开ipcameraactivex.inf 文件，查看代码段： [netVideoactivex23.ocx] file-win32-x86=thiscab Registerserver=yes clsid={caFcF48d-8e34-4490-8154-026191d73924} destdir=11 FileVersion=2,3,21,1 2.4. 记录上面的“ clsid ”。 2.5. 在网页中注册上述ocx控件，使用js调用控件的 中的方法进行登录，查看等操作(查看其他操作可查找：海
RTSP协议介绍 RTSP协议以客户服务器方式工作，它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制，如：暂停/继续、后退、前进等。因此 RTSP 又称为“因特网录像机遥控协议”。 1.1. RTSP协议简介 要实现 RTSP 的控制功能，不仅要有协议，而且要有专门的媒体播放器(media player)和媒体服务器(media server)。媒体服务器与媒体播放器的关系是服务器与客户的关系。 媒体服务器与普通的万维网服务器的最大区别就是媒体服务器支持流式音频和视频的传送，因而在客户端的媒体播放器可以边下载边播放（需要先缓存一小段时间的节目）。但从普通万维网服务器下载多媒体节目时，是先将整个文件下载完毕，然后再进行播放。 图1 RTSP与RTP和RTCP的关系 RTSP 仅仅是使媒体播放器能控制多媒体流的传送。因此，RTSP 又称为带外协议，而多媒体流是使用 RTP 在带内传送的。 1.2. RTSP的报文结构 RTSP有两类报文：请求报文和响应报文。请求报文是指从客户向服务器发送请求报文，响应报文是指从服务器到客户的回答。 由于 RTSP 是面向正文的(text-oriented)，因此在报文中的每一个字段都是一些 ASC II 码串，因而每个字段的长度都是不确定的。 RTSP报文由三部分组成，即开始行、首部行和实体主体。在请求报文中，开始行就是请求行，RTSP请求报文的结构如图2所示。
图2 RTSP请求报文的结构 RTSP请求报文的方法包括：OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、G ET_PARAMETER和SET_PARAMETER。RTSP请求报文的常用方法及作用如表1所示。 表1 RTSP请求报文的常用方法及作用
RTSPRTP 媒体传输和控制协议 1 前言 本文档主要描述了NewStream Vision 系统中前端视频服务器(DVR, 网络摄像机), 中心转发服务器以及客户端之间的多媒体通信以及控制协议. 本协议主要基于标准的IETE 的RTSP/RTP 以及相关协议, 并针对具体应用定义了部分扩展. 本协议只是当前实现的总结和整理, 具体的协议细节以实际实现为准 2 定义 RTSP实现流协议SDP会话描述协议RTP实时传输协议 H.264H.264 视频编码标准 3 RTSP 命令 3.1 Request 语法 语法: RTSP 的语法和HTTP 的语法基本相同, 具体如下。COMMAND rtsp_URL RTSP/1.0<CRLF> Headerfield1: val1<CRLF> Headerfield2: val2<CRLF> ... <CRLF>
[Body] RTSP 消息行之间用回车换行(CRLF) 分隔. 一个空行表示消息头部分的结束。 3.1.1 RTSP 方法 COMMAND 表示RTSP 命令名称, 是DESCRIBE, SETUP, OPTIONS, PLAY, PAUSE, TEARDOWN 或 SET_PARAMETER 等的任意一个. 3.1.2 RTSP URL 完整语法如下: rtsp_URL = ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [ abs_path ] host = (A legal Internet host domain name of IP address (in dotted decimal form), as defined by Section 2.1 of RFC 1123 \cite{rfc1123}) port = *DIGIT 如: rtsp://<servername>/live.mp4[?<param>=<valu e>[&<param>=<value>...]]
RTSP协议 RTSP协议 RTSP（Real Time Stream Protocol，实时流协议）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。数据 源包括现插数据与存储在剪辑中的数据。该协议目的在于控制多个数据发送连接，为选择发送通道如UDP、多播UDP 与TCP等提供途径，并为选择基于RTP 上发送机制提供方法。 一．简介 1．目的 实时流协议建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交叉是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒 体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可靠传输连接以发出 RTSP请求。此外，可使用无连接传输协议，如UDP。RTSP 流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。实时流协
议在语法和操作上与HTTP 1.1类似，因此HTTP的扩展机制大都可加入RTSP。协议支持的操作如下： (1)从媒体服务器上检索媒体 用户可通过HTTP或其他方法提交一个演示描述。如演示是多播，演示时就包含用于连续媒体的多播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。 (2)媒体服务器邀请进入会议 媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。 (3)将媒体加到现成讲座中 例如，服务器告诉用户可获得附加媒体内容。这对现场讲座显得尤其有用。如HTTP 1.1中类似，RTSP请求可由代理、通道与缓存处理。 2．协议特点 RTSP有如下特性。 (1) 可扩展性：新方法和参数很容易加入RTSP。 (2) 易解析：RTSP可由标准HTTP或MIME解析器解析。 (3) 安全：RTSP使用网页安全机制。 (4) 独立于传输：RTSP可使用不可靠数据报协议(EDP)、可靠数据报协议(RDP)；如要实现应用级可靠，可使用可靠流协议。
一．RTSP协议概述 RTSP(Real-Time Stream Protocol )是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。 RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。 二．一次基本的RTSP协议连接过程 1.客户端与服务器建立TCP三次握手连接。 2.客户端连接到流服务器并发送一个RTSP描述命令（OPTIONS），询问S有哪些方法可用 （包括DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、OPTIONS、ANNOUNCE、RECORD等）。
3.客户端继续发送一个RTSP描述命令（DESCRIBE），要求得到S提供的媒体描述信息，流服务器 通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。
4.客户端再分析该SDP描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，RTSP建 立命令告诉服务器客户端用于接收媒体数据的端口。
5.流媒体连接建立完成后，客户端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流 （RTP包）到客户端。 6.在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。最后，客户端可发 送一个终止命令(TERADOWN)来结束流媒体会话。 三、简单的RTSP消息交互过程 C表示RTSP客户端,S表示RTSP服务端 1.第一步：查询服务器端可用方法 1.C->S:OPTION request //询问S有哪些方法可用 1.S->C:OPTION response //S回应信息的public头字段中包括提供的所有可用方法
音视频—RTSP协议简介 RTSP简介 RTSP协议以客户端/服务器方式工作，如：暂停/继续、后退、前进等。它是一个多媒体播放控制协议，用来控制用户在播放从因特网下载的实时数据,因此RTSP又称为“因特网录像机遥控协议”。 RTSP(Real-Time Stream Protocol)是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学,网景和RealNetworks公司提交的IETF RFC 标准.对应的RFC编号是2326，可以在这里搜索 https://https://www.doczj.com/doc/735911367.html,/search/rfc_search_detail.php RTSP协议定义了一对多的应用程序如何有效地通过IP网络传送多媒体数据.。RTSP在体系结构上位于RTP和RTCP之上,它使用TCP或UDP完成数据传输。 RTSP被用于去控制已建立的媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于传送媒体流数据。媒体数据的传送可通过 RTP/RTCP等协议来完成。 该协议基于C/S模型,是一个基于文本的协议,用于在客户端和服务器端建立和协商实时流会话。. RTSP是类似http的应用层协议，一个典型的流媒体框架网络体系可参考下图：
RTSP协议特点 ●可扩展性:新方法和参数很容易加入RTSP。 ●易解析:RTSP可由标准HTTP或MIME解析器解析。 ●安全:RTSP使用网页安全机制。 ●独立于传输:RTSP可使用不可靠数据报协议(EDP),可靠数据报协议(RDP); 如要实现应用级可靠,可使用可靠流协议。 ●多服务器支持:每个流可放在不同服务器上,用户端自动与不同服务器建立 几个并发控制连接,在传输层执行媒体同步。 ●记录设备控制:协议可控制记录和回放设备。 ●流控与会议开始分离:仅要求会议初始化协议提供,或可用来创建唯一会议 标识号.特殊情况下,可用SIP或H.323来邀请服务器入会。 ●适合专业应用:通过SMPTE时标,RTSP支持帧级精度,允许远程数字编 辑。 ●演示描述中立:协议没强加特殊演示或元文件,可传送所用格式类型;然而, 演示描述至少必须包括一个RTSP URL。 ●代理与防火墙友好:协议可由应用和传输层防火墙处理.防火墙需要理解 SETUP方法,为UDP媒体流打开一个“缺口”。 ●HTTP友好:此处,RTSP明智地采用HTTP观念,使现在结构都可重用.结 构包括Internet内容选择平台(PICS).由于在大多数情况下控制连续媒体需要服务器状态,RTSP不仅仅向HTFP添加方法。 ●适当的服务器控制:如用户启动一个流,必须也可以停止一个流。 ●传输协调:实际处理连续媒体流前,用户可协调传输方法。 ●性能协调:如基本特征无效,必须有一些清理机制让用户决定哪种方法没生 效.这允许用户提出适合的用户界面。 一次基本的RTSP操作过程: ●首先，客户端连接到流服务器并发送一个RTSP描述命令(DESCRIBE)。 ●流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型 等信息。 ●客户端然后分析该SDP描述，并为会话中的每一个流发送一个RTSP建立 命令(SETUP)，RTSP建立命令(SETUP)告诉服务器当前客户端用于接收媒体数据的端口号。 ●流媒体连接建立完成后，客户端发送一个播放命令(PLAY)，服务器就开始使 用UDP或者TCP传送媒体流(RTP包)到客户端。 ●在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。 ●最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话。RTSP协议与HTTP协议区别
RTSP协议与HTTP协议 一。RTSP协议简介 流媒体技术是一系列的网络协议的集合，包括： 1. 实时传输协议RTP(Real-time Transport protocol) 2. 实时传输控制协议RTCP(Real-time Transport Control protocol) 3. 实时流协议RTSP(Real Time Streaming protocol) 4. 资源预留协议RSVP(Resource Reserve Protocol)。 实时流协议RTSP是一个应用层协议，用于控制具有实时特性的数据（例如多媒体流）的传送。为多媒体数据流提供远程控制功能，如播放、停止、快进等。该协议支持以下操作： 1. 从媒体服务器上获取媒体； 2. 邀请媒体服务器加入会议（Conference）； 3. 在一个已存在的演示（Presentation）中加入新的媒体流。 RTSP协议一般与RTP/RTCP和RSVP等底层协议一起协同工作，提供基于Internet的整套的流服务。它可以选择发送通道（例如：UDP、组播UDP和TCP）和基于RTP的发送机制。它可以应用于组播和点播。 二。HTTP协议简介 HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。 HTTP协议的主要特点可概括如下： 1.支持客户/服务器模式。 2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。
RTSP协议转换RTMP直播协议
RTSP协议转换RTMP直播协议 RTSP协议也是广泛使用的直播/点播流媒体协议，最近实现了一个RTSP协议转换RTMP直播协议的程序，为的是可以接收远端设备或服务器的多路RTSP 直播数据，实时转换为RTMP直播协议，推送到FMS、Red5、wowza server等RTMP 服务器，以实现flash观看RTSP直播源的需求。程序同时也具备从FLV文件获取输入数据并转换RTMP直播。实现的思路分享如下。 要点分析 首先，程序的主要目的，是从多路RTSP输入源中提取AAC编码的音频和H.264编码视频数据，并生成RTMP数据包，然后组装RTMP推送协议，并发往RTMP服务器。在发送的过程中，要求可以从RTSP数据源切换到具有相同h.264和aac 编码的FLV文件中，并不影响RTMP直播。因此，本程序的关键点有以下部分： 1.RTSP直播流的读取 2.H.264和AAC编码数据的分析、处理 3.FLV文件数据的提取及与RTSP直接的切换和衔接 4.RTMP数据包封装 5.RTMP推送协议 有了关键点，就可以一项一项的去分析。 设计思路 根据上面分析的要点，首先要选择RTSP直播协议的读取。我们不需要从零做起，网络上有很多和RTSP相关的开源项目可以使用或借鉴，我选择了Live555。 Live555是一个跨平台的流媒体解决方案，主要支持RTSP协议，好像也支持SIP（这个也是我马上研究的重点，之后会写文章研究SIP相关的技术实现）。Live555实现了RTSP包括服务器-客户端的整套结构，是很知名的一个开源项目。
网上有很多关于Live555学习和使用的文章，我就不具体介绍了。 H.264和AAC数据的分析处理，这个对于从没做过相关项目开发的人来说，应该是一个难点，主要是相关概念的理解。好在我一直在做这块，也比较好弄。 第4和第5点，可以参照文章“RTMP协议发送H.264编码及AAC编码的音视频（https://www.doczj.com/doc/735911367.html,/haibindev/archive/2011/12/29/2305712.html），实现摄像头直播”的技术方法，来加以实现。因此，主要需要处理的就是RTSP 直播流数据的获取，以及对其中H.264和AAC编码数据的处理。 于是可以画出大体结构如下： RtmpThread的主要工作就是发送音频数据流的解码信息头和视频数据流的解码信息头，并不断从DataBufferQueue中取出数据，封装为RTMP Packet，发送出去。流程如下列代码所示：（process_buf_queue_，即是上图中的DataBufferQueue）
第一部分:RTSP协议 1. RTSP协议概述 RTSP（Real Time Streaming Protocol），实时流传输协议，是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容。该协议用于C/S模型，是一个基于文本的协议，用于在客户端和服务器端建立和协商实时流会话。 RTSP(Real-Time Stream Protocol )是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。 RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。 一次基本的RTSP操作过程是:首先，客户端连接到流服务器并发送一个RTSP描述命令（DESCRIBE）。流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。客户端在分析该SDP描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，RTSP建立命令告诉服务器客户端用于接收媒体数据的端口。流媒体连接建立完成后，客户端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到客户端。在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话
RTP、RTCP、RTSP协议详解 一、RTP协议 实时传输协议（RTP）为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在UDP 上运行RTP以便使用其多路结点和校验服务；这两种协议都提供了传输层协议的功能。但是RTP可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式，那么RTP可以使用该组播表传输数据到多个目的地。 RTP本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。RTP协议并不保证传送或防止无序传送，也不确定底层网络的可靠性。RTP 实行有序传送，RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。 RTP协议由两个紧密链接部分组成： RTP―传送具有实时属性的数据； RTP控制协议（RTCP）―监控服务质量并传送正在进行的会话参与者的相关信息。RTCP 第二方面的功能对于“松散受控”会话是足够的，也就是说，在没有明确的成员控制和组织的情况下，它并不非得用来支持一个应用程序的所有控制通信请求。 协议结构 1238916bitVPXCSRC CountMPayload TypeSequence numberTimestampSSRCCSRC (variable 0 –15 items 32bits each)V ―版本。识别RTP版本。 P ―间隙（Padding）。设置时，数据包包含一个或多个附加间隙位组，其中这部分不属于有效载荷。 X ―扩展位。设置时，在固定头后面，根据指定格式设置一个扩展头。 CSRC Count ―包含CSRC 标识符（在固定头后）的编号。 M ―标记。标记由Profile 文件定义。允许重要事件如帧边界在数据包流中进行标记。 Payload Type ―识别RTP有效载荷的格式，并通过应用程序决定其解释。Profile 文件规定了从Payload 编码到Payload 格式的缺省静态映射。另外的Payload Type 编码可能通过非RTP方法实现动态定义。 Sequence Number ―每发送一个RTP数据包，序列号增加1。接收方可以依次检测数据包的丢失并恢复数据包序列。 Timestamp ―反映RTP数据包中的第一个八位组的采样时间。采样时间必须通过时钟及时提供线性无变化增量获取，以支持同步和抖动计算。 SSRC ―同步源。该标识符随机选择，旨在确保在同一个RTP协议会话中不存在两个同步源具有相同的SSRC 标识符。 CSRC ―贡献源标识符。识别该数据包中的有效载荷的贡献源。 二、RTCP：RTP 控制协议 RTP 控制协议（RTCP）采用与数据包相同的分发机制，将控制包周期性传输到所有会话参与者中。底层协议必须提供数据和控制包的多路发送，例如使用不同的UDP 端口号。RTCP 主要完成四个功能服务： RTCP 提供数据分发质量反馈信息。这是RTP 作为传输协议的部分功能并且它涉及到了其它传输协议的流控制和拥塞控制。 RTCP 为RTP 源携带一个持久性传输层标识符，称为规范名或CNAME 。由于一旦发现冲突或程序重启时，SSRC 标识符会随之改变，所以接收方需要CNAME 来跟踪每一个
rtsp摘要认证协议(Response计算方法) 1. rtsp摘要认证协议流程 RTSP协议，全称Real Time Streaming Protocol，是应用层的协议，它主要实现的功能是传输并控制具有实时特性的媒体流，如音频（Audio）和视频（Video）。Rtsp认证主要分为两种：基本认证（basic authentication）和摘要认证（digest authentication）。基本认证是http 1.0提出的认证方案，其消息传输不经过加密转换因此存在严重的安全隐患。摘要认证是http 1.1提出的基本认证的替代方案，其消息经过MD5哈希转换因此具有更高的安全性。下面将以一次与网络摄像机握手的全过程来详细介绍RTSP摘要认证的应用： 摘要认证Digest authentication [plain] view plaincopyprint? 客户端第一次发起连接请求：OPTIONS rtsp://192.168.123.158:554/11 RTSP/1.0 CSeq: 1 User-Agent: LibVLC/2.0.5(LIVE555 Streaming Media v2012.09.13) 服务器端返回服务端信息及public方法：RTSP/1.0 200 OK Server: HiIpcam/V100R003 V odServer/1.0.0 Cseq: 1 Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY,GET_PARAMETER 客户端再次发起连接：DESCRIBE rtsp://192.168.123.158:554/11 RTSP/1.0 CSeq: 2
SDP协议原理及应用 编者：尚森 审核：王高原 中兴通讯固网交换用服部
修改记录
目录 第1章SDP的协议原理 (1) 1.1SDP的概述 (1) 1.2SDP协议字段 (1) 1.3说明 (3) 第2章SDP的应用 (4) 2.1SDP在SIP电话中的应用 (4) 2.2SDP各TYPE的详细解释 (5) 2.3SDP在H.248的应用 (7) 第3章SDP的实例应用 (8) 3.1SDP的举例描述 (8) 3.2H.248中SDP消息举例描述 (15)
第1章SDP的协议原理 1.1 SDP的概述 SDP（SDP:SessionDescriptionProtocol会话描述协议）是由IETF（Interne工程任务组）作为RFC4566颁布，描述流媒体初始化参数的格式。其目的就是在媒体会话中，传递媒体流信息，允许会话描述的接收者去参与会话。定义了会话描述的统一格式，但并不定义多播地址的分配和SDP 消息的传输，也不支持媒体编码方案的协商，这些功能均由下层传送协议完成。 会话描述协议（SDP）为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供了多媒体会话描述。 会话目录用于协助多媒体会议的通告，并为会话参与者传送相关设置信息。SDP即用于将这种信息传输到接收端。SDP完全是一种会话描述格式――它不属于传输协议――它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME扩展协议的电子邮件以及超文本传输协议（HTTP）。 SDP的设计宗旨是通用性，它可以应用于大范围的网络环境和应用程序，而不仅仅局限于组播会话目录，但SDP不支持会话内容或媒体编码的协商。 在因特网组播骨干网（Mbone）中，会话目录工具被用于通告多媒体会议，并为参与者传送会议地址和参与者所需的会议特定工具信息，这由SDP完成。SDP连接好会话后，传送足够的信息给会话参与者。SDP信息发送利用了会话通知协议（SAP），它周期性地组播通知数据包到已知组播地址和端口处。这些信息是UDP数据包，其中包含SAP协议头和文本有效载荷（textpayload）。这里文本有效载荷指的是SDP会话描述。此，外信息也可以通过电子邮件或WWW（WorldWideWeb）进行发送。 SDP文本信息包括： ●会话名称和意图； ●会话持续时间； ●构成会话的媒体； ●有关接收媒体的信息（地址等）。 1.2 SDP协议字段 SDP信息是文本信息，采用UTF-8编码中的ISO10646字符集。SDP会话描述如下：(标注*符号的表示可选字段)：
SDP: Session Description Protocol(会话描述协议) (RFC2327) 1.概述 SDP也是MMUSIC工作组的一个产品,在MBONE内容中用得很多。其目的就是在媒体会话中，传递媒体流信息，允许会话描述的接收者去参与会话。SDP基本上在internet上工作。他定义了绘画描述的统一格式,但并不定义多播地址的分配和SDP消息的传输,也不支持媒体编码方案的协商,这些功能均由下层传送协议完成.典型的会话传送协议包括:SAP(Session Announcement Protocol 会话公告协议),SIP,RTSP,HTTP,和使用MIME的E-Mail.(注意:对SAP 只能包含一个会话描述,其它会话传诵协议的SDP可包含多个绘画描述) SDP包括以下一些方面： 1）会话的名称和目的 2）会话存活时间 3）包含在会话中的媒体信息，包括： 媒体类型(video, audio, etc) 传输协议(RTP/UDP/IP, H.320, etc) 媒体格式(H.261 video, MPEG video, etc) 多播或远端（单播）地址和端口 4）为接收媒体而需的信息(addresses, ports, formats and so on) 5）使用的带宽信息 6）可信赖的接洽信息（Contact information） 2.协议 //格式及举例 Session description //v=0 version) v= (protocol o= (owner/creator and session identifier). //o=<用户名><会话id><版本><网络类 //型><地址类型><地址> //o=sname 1234567890 0987654321 IN //IP4 126.15.64.3 //会话名 s= (session name) i=* (session information) //会话信息 u=* (URI of description) //u=https://www.doczj.com/doc/735911367.html,/staff/sdp.ps e=* (email address) //e=zte@https://www.doczj.com/doc/735911367.html,(general text如：王生) //或e=Mr. Wang