RTSP简介
目录
1概要 (2)
2流媒体基本业务组网图 (2)
3RTSP 介绍 (3)
3.1RTSP是什么？ (3)
3.2RTSP URL的语法结构 (3)
3.3RTSP 消息 (3)
3.3.1消息 (3)
3.3.2请求消息 (3)
3.3.3响应消息 (5)
3.4信令 (6)
3.4.1OPTIONS (6)
3.4.2DESCRIBE (7)
3.4.3SETUP (8)
3.4.4PLAY (8)
3.4.5PAUSE (8)
3.4.6TEARDOWN (9)
3.5Header Field 解析 (9)
3.5.1Accept (11)
3.5.2Cseq (11)
3.5.3Range (11)
3.5.4RTP-Info (11)
3.5.5Session (12)
3.5.6Transport (12)
3.5.7User-Agent (12)
4移动流媒体与RTSP (13)
4.1点播流程 (13)
4.2SDP (15)
4.3数据传送 (16)
4.4消息流程 (16)
表1：信令简要描述 (6)
表2：RTSP头字段简述 (11)
图1 流媒体业务基本组网图 (2)
图2 RTSP消息交互 (14)
图3 协议栈的简单描述 (16)
3GP 3GPP file format
CODEC COder / DECoder
IP Internet Protocol
MP4 MPEG-4 file format
PSS Packet-switched Streaming Service
RFC IETF Request For Comments
RTCP RTP Control Protocol
RTP Real-time Transport Protocol
RTSP Real-Time Streaming Protocol
SDP Session Description Protocol
TCP Transport Control Protocol
UDP User Datagram Protocol
URI Universal Resource Identifier
WAP Wireless Application Protocol
概要
RTSP（Real Time Streaming Protocol）实时流协议：一种流媒体控制协议，可对流媒体进行暂停、快进、快倒等操作。
流媒体就是实时在线点播。而流媒体与普通媒体的差别在于：对于普通媒体，在访问它之前要得到全部的内容；对于流媒体，则在完全接收到全部内容之前就开始访问。
本文主要介绍RTSP的基本消息信令及手机与HMS的RTSP的消息交互过程。
1 流媒体基本业务组网图
图1流媒体业务基本组网图
2 RTSP 介绍
2.1 RTSP是什么？
RTSP（Real Time Streaming Protocol），实时流协议，是一种应用层的协议，用于实时的控制数据的传输。RTSP提供一个可扩展的架构来实现控制实时媒体的在线点播，如音频或是视频内容。数据源可以是直播信号也可以是制作好的媒体文件。RTSP能够同时控制多个数据传输会话过程，
2.2 RTSP URL的语法结构
一个终端用户是通过在播放器中输入URL地址开始进行观看流媒体业务的第一步，而对于使用RTSP 协议的移动流媒体点播而言，URL的一般写法如下：
一个以“rtsp”或是“rtspu”开始的URL链接用于指定当前使用的是RTSP 协议。RTSP URL的语法结构如下：
rtsp_URL = (“rtsp:”| “rtspu:”) “//” host [“:”port”] [abs_path]
host：可以是一个有效的域名或是IP地址。
port：端口号，对于RTSP协议来说，缺省的端口号为554，即如HTTP的缺省端口号是80一样。当我们在确认流媒体服务器提供的端口号为554时，此项可以省略
说明：当HMS服务器使用的端口号为554时，我们在写点播链接时，可以不用写明端口号，但当使用非554端口时，在RTSP URL中一定要指定相应的端口。
注：我们在点播时使用的都是rtsp，而没有使用到rtspu。
2.3 RTSP 消息
2.3.1 消息
RTSP是一种基于文本的协议，用CRLF作为一行的结束符。使用基于文本协议的好处在于我们可以随时在使用过程中的增加自定义的参数。
RTSP有两种消息，请求消息及回应消息。一个消息一般由头和内容组成，不过也有很多的消息是只有消息头而没有消息体（message body）的。
2.3.2 请求消息
一个请求消息（a request message）即可以由客户端向服务端发起也可以由服务端向客户端发起。请求消息的语法结构如下：
Request = Request-Line
*( general-header
| request-header
| entity-header)
CRLF
[message-body]
1. Request Line
请求消息的第一行的语法结构如下：
Request-Line = Method 空格Request-URI 空格RTSP-Version CRLF
其中在消息行中出现的第一个单词即是所使用的信令标志。目前已经有的信息标志如下：
Method = “DESCRIBE”
| “ANNOUNCE”
| “GET_PARAMETER”
| “OPTIONS”
| “PAUSE”
| “PLAY”
| “RECORD”
| “REDIRECT”
| “SETUP”
| “SET_PARAMETER”
| “TEARDOWN”
| extension-method
extension-method = 标志
我们可以使用自己定义的信令标示符
Request-URI = “*” | absolute_URI
请使用请求媒体存放的绝对路径
RTSP-Version = “RTSP”“/” 1*DIGIT “.” 1*DIGIT
RTSP的版本号
例子：
DESCRIBE rtsp://211.94.164.227/3.3gp RTSP/1.0
2. Request Header Fields
在消息头中除了第一行的内容外，还有一些需求提供附加信息。其中有些是一定要的，后续我们会详细介绍经常用到的几个域的含义。
Request-header = Accept
| Accept-Encoding
| Accept-Language
| Authorization
| From
| If-Modified-Since
| Range
| Referer
| User-Agent
2.3.3 响应消息
客户端或是服务端在接收并解释一个请求消息后，会回复一个消息（response message）给请求方。响应消息的语法结构如下：
Response = Status-Line
*( general-header
| response-header
| entity-header)
CRLF
[message-body]
1. Status-Line
响应消息的第一行是状态行（status-line），每个元素之间用空格分开。除了最后的CRLF之外，在此行的中间不得有CR或是LF的出现。它的语法格式如下，
Status-Line = RTSP-Version 空格Status-Code 空格Reason-Phrase CRLF
Status-Code 是一个三位数的整数，用于描述接收方对所收到请求消息的执行结果，而Reason-Phrase是对Status-Code给出一个简短的文字描述，便于我们在收到一个消息后，不用每次都去查看code的解释，而只需要看Reason-Phrase就可以大概了解当前请求的执行状态。
Status-Code的第一位数字指定了这个回复消息的种类，一共有5类：
?1XX: Informational –请求被接收到，继续处理
?2XX: Success –请求被成功的接收，解析并接受
?3XX: Redirection –为完成请求需要更多的操作
?4XX: Client Error –请求消息中包含语法错误或是不能够被有效执行
?5XX: Server Error –服务器响应失败，无法处理正确的有效的请求消息
我们在处理问题时经常会遇到的状态码有如下：
Status-Code = “200”:OK
| “400”:Bad Request
| “404”:Not Found
| “500”Internal Server Error
RTSP的状态码也是可以扩展的。服务器可以根据实际情况定义相应的状态码及描述信息。
2. Response Header Fields
在响应消息的域中存放的是无法放在Status-Line中,而又需要传送给请求者的一些附加信息。
Response-header = Location
| Proxy-Authenticate
| Public
| Retry-After
| Server
| Vary
| WWW-Authenticate
2.4 信令（Mothod）
信令指的是在Request-LINE中指定的需要接收者完成的操作。信令（The method）大小写敏感，不能以字符”$”开始，并且一定要是一个标记符。
概要描述如下：
表1：信令简要描述
C：客户端
S：服务端
下面介绍几个常用的信令
2.4.1 OPTIONS
例子：
C->S: （请求）
OPTIONS * RTSP/1.0
CSeq: 1
Require: implicit-play
Proxy-Require: gzipped-messages
S->C: （响应）
RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
OPTIONS消息可以在任何时间被发起，如MOTO835手机就会每隔60秒左右向服务器端发送一个OPTIONS的消息，而HMS服务器在检查MOTO835是否仍在线时，也是通过来检查服务器端是否定时收到OPTIONS的消息来实现的。但需注意的是，并不是所有的手机和播放器会定时发送OPTIONS消息到服务器端，即使有发送，发送OPTIONS的消息的时间间隔也是不尽相同的。
2.4.2 DESCRIBE
DESCRIBE消息是由客户端发送到服务器端，用于客户端得到请求链接（request URL）中指定的媒体文件的相关描述。DESCRIBE的这一对交互消息完成了RTSP的媒体初始化。
例子：
C->S:
DESCRIBE rtsp://https://www.sodocs.net/doc/781251786.html,/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl, application/mheg
S->C:
RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 376
v=0 （这里就是MESSAGE BODY，它的长度由Content_Length来指定）
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=https://www.sodocs.net/doc/781251786.html,/staff/M.Handley/sdp.03.ps e=mjh@https://www.sodocs.net/doc/781251786.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
DESCRIBE的响应消息必须包含所有的媒体初始化信息。对于基于RTSP的系统，媒体初始化是必须的，但是并不一定要通过DESCRIBE消息来得到，这里是一个RTSP的客户端得到初始化信息的三种方式：
?通过RTSP的DESCRIBE
?一些其它的协议，如HTTP，email attachment等
命令行方式
2.4.3 SETUP
SETUP请求用于指定流媒体使用的传输机置。在请求消息中会指定客户端在数据传输时相关的传送参数，而在响应消息中将包含由服务器端所指定的传输参数。服务器端在回复SETUP消息时将会生成一个session ID.
例子：
C->S:
SETUP rtsp://https://www.sodocs.net/doc/781251786.html,/foo/bar/baz.3gp RTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589
S->C:
RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257
服务器端在回复SETUP消息时将会生成一个session ID.
2.4.4 PLAY
PLAY消息是告诉服务器端可以使用在SETUP消息中所指定的传输机置开始传送数据。需要指出的是，客户端不应该发送任何PLAY请求直到所有的SETUP消息被成功解析。PLAY消息会在range中指定媒体的播放时间，服务器在接到PLAY消息后会由range中指定的开始点开始发送媒体数据直到range中指定的结束点。
所有的PLAY消息都是必须按顺序被处理的，即当一个PLAY的请求到达时，而上一个PLAY请求还未完成，后面的PLAY请求将被延时，直到第一个PLAY处理完成时才会被处理。
例子：
C->S:
PLAY rtsp://https://www.sodocs.net/doc/781251786.html,/audio RTSP/1.0
CSeq: 835
Session: 12345678
Range: npt=10-15
2.4.5 PAUSE
PAUSE消息是用于暂时中断流媒体的传送。当暂停的时间过长（这个值应在SETUP消息中由timeout 参数指定），服务器可以自动断开这个会话，释放所占用的资源。
例子:
C->S:
PAUSE rtsp://https://www.sodocs.net/doc/781251786.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信令的，例如，对于直播的节目，就可以不支持暂停。当一个服务器不支持某一个信令时，必须要返回给客户端以“501 Not Implemented”的响应消息，并且客户端应该不再尝试向服务器端发送这个请求。
2.4.6 TEARDOWN
TEARDOWN消息是用于停止媒体数据的传送，并释放所占用的资源。
例子：
C->S:
TEARDOWN rtsp://https://www.sodocs.net/doc/781251786.html,/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678
S->C:
RTSP/1.0 200 OK
CSeq: 892
2.5 Header Field 解析
在每个消息中都会包含一定的字段用于描述一些信息。
Type ”g”指通用，在请求消息和响应消息中都可能出现
Type “R”指请求消息
Type “r”指响应消息
Type “e”指实体头字段
表2：RTSP头字段简述
下面简要介绍一些在RTSP中常用到的头字段，详细的信息请查看RFC 2326。
2.5.1 Accept
Accept字段可用于指定可被接受的描述类型
例子:
Accept: application/rtsl, application/sdp;level=2
2.5.2 Cseq
Cseq域指定一对RTSP请求-响应消息的序列号。在请求消息及响应消息中一定要指定这个域。对于请求消息，会有一个具有相同Cseq域内容的响应消息与之对应。
例子：
C->S:
SETUP rtsp://https://www.sodocs.net/doc/781251786.html,/foo/bar/baz.3gp RTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589
S->C:
RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257
2.5.3 Range
Range用于在请求消息和响应消息中指定播放的时间段。
例子：:
Range: clock=19960213T143205Z-;time=19970123T143720Z
2.5.4 RTP-Info
这个域用于在回复PLAY消息中指定RTP特殊的参数
url: 与设置的RTP参数对应的流媒体链接
seq: 流媒体第一个包的序列号
rtptime: 用于回复range域对应的RTP时间戳
RTP-Info语法结构：
RTP-Info = "RTP-Info" ":" 1#stream-url 1*parameter
其中：stream-url = "url" "=" url
parameter = ";" "seq" "=" 1*DIGIT
| ";" "rtptime" "=" 1*DIGIT
例子：
RTP-Info:url=rtsp://https://www.sodocs.net/doc/781251786.html,/bar.avi/streamid=0;seq=45102,url=rtsp://https://www.sodocs.net/doc/781251786.html,/bar.avi/streamid=1;se q=30211
2.5.5 Session
Session域在请求与响应消息中用于识别一个RTSP会话（RTSP session即一个完整的RTSP交互过程。例如：在点播流媒体时，一个典型的会话过程包括一个客户建立一个传输通道（SETUP），用PLAY 开始传输流，最后用TEARDOWN来断开这个连接）。一旦客户端接收到Session标识，在这个会话中的任何请求都需要附加这个域。
Session语法结构：
Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]
例子：
Session: 12345678
2.5.6 Transport
这个域在请求消息中是标识哪一种传输协议将被使用，并指定一些在描述说明中没有指定的参数的值。使用的传输协议之间用逗号分隔，参数之间用分号分隔
常用参数：
unicast | multicast: 单播还是组播（缺省值为multicast）.
destination: 指定流将被传送到到哪个地址
port: (RTP协议):指定RTP/RTCP端口号（multicast）。一般为一个范围。e.g.,
port=3456-3457.
Client_port: 客户端选择的用于接收媒体数据及控制信息的单播RTP/RTCP端口号。
e.g., port=3456-3457
Server_port: 服务器端用于接收媒体数据和控制信息的单播RTP/RTCP端口号。e.g.,
port=3456-3457
例子:
Transport:RTP/AVP;multicast;ttl=127;mode="PLAY",
RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
2.5.7 User-Agent
这个域用于用户标识，不同公司或是型号的手机发出的消息中的这个域的内容都不大相同。有时会指
出手机的版本号，播放器的型号等等。在HMS中的terminal.xml文件就是根据这个域中的内容来完成简单的终端适配的功能。
例子：
User-Agent:01056SS68001117616022101802836055;14;41;4578;327;13824;0;1;0x0202;0x00000B;0 x028010
3 移动流媒体与RTSP
移动流媒体技术就是把连续的影像和声音信息经过压缩处理后放到网络服务器上，让移动终端用户能够一边下载一边观看、收听，而不需要等到整个多媒体文件下载完成就可以即时观看的技术。实际上移动流媒体技术是网络音视频技术和移动通讯技术发展到一定阶段的产物，它是融合很多网络技术之后所产生的技术，它会涉及到流媒体数据的采集、压缩、存输以及网络通信等多项技术。它大致分为下面两大类业务类型：
·流媒体点播(VOD)
内容提供商将预先录制好的多媒体内容编码压缩成相应格式，存放在内容服务器上并把内容的描述信息以及链接放置在流媒体的portal上。最终用户就可以通过访问portal，发现感兴趣的内容，有选择的进行播放。
·流媒体直播
流媒体编码服务器将实时信号编码压缩成相应的格式，并经由流媒体服务器分发到用户的终端播放器。根据实时内容信号源的不同，又可以分为电视直播、远程监控等。
对于点播和直播，都是使用的RTSP协议。下面我们介绍在实际应用中RTSP消息是如何交互来完成点播或是直播功能。
3.1 点播流程
一个移动用户使用手机通过访问网页得到URI，在URI中指定了流媒体服务器的地址及想要访问的媒体内容。通过RTSP SETUP消息来建立客户端与流媒体服务器之间的连接，然后客户端通过发送一个RTSP PLAY的消息来通知服务器开始传送一个或多个媒体流。
具体消息交互过程如下：
图2 RTSP 消息交互
每次客户端发送一个请求消息，服务器端都会回一个相应的响应消息。 1. 手机通过上网得到带有流媒体地址的网页，并点播一个节目
2. 手机上发RTSP ：DESCRIBE 的消息给服务器，服务器处理其中的URL 链接，得到相应文件的SDP
信息，附加在响应消息中返回给手机。如果此时服务器找不到手机想要点播的文件，就会回应400的错误给手机，显示文件不存在。
3. 手机根据收到的SDP 的信息向服务器发送RTSP:SETUP 消息，与服务器建立连接。如果媒体文件
包含音频和视频，就会有两次SETUP 的交互消息。一个是音频的信息，一个是视频的信息。如果交互成功，服务器会发送200的OK 消息给手机
4. 手机在SETUP 消息执行成功后，会向服务器发送RTSP ：PLAY 的消息，要求服务器开始发送数
据。服务器在收到PLAY 消息后，即会开始传送UDP/RTP 包。
5. 如果在播放过程中需要暂停，手机会发送RTSP ：PAUSE 的消息给服务器，服务器在收到暂停消
息后，即会停止发数据包，手机停止播放。如果需要继续播放，手机只需要再发送RTSP ：PLAY 的消息给服务器，服务器根据暂停的位置继续开始播放。
6. 当播放完成后，手机会自动向服务器发送RTSP ：TEARDOWN 消息，当服务器收到下线消息后，
就会断开与手机的连接，释放所占用的资源。 7. 点播过程结束。
UE
SGSN
Media
WAP/Web
3.2 SDP
在播放过程中，手机得到内容的相关信息是很重要的，如果这些内容不正确，也会影响播放的正确性，下面简要介绍一下SDP。
SDP文件（Session Description Protocol：会话描述协议）包含了会话的描述，媒体类型，媒体的码率。客户端通过RTSP DESCRIBE来得到SDP文件。
RTSP需要一个内容的描述。而SDP就被用于客户端与服务端的一种内容描述的格式。在传送给客户的SDP内容应该声明了这个对话所要访问的媒体内容的媒体编码类型。对于流媒体服务而言，以下几个域是在SDP中一定要包含的。
“a=control:”
“a=range:”
“a=rtpmap:”
“a=fmtp:”
例子：
v=0
o=ghost 2890844526 2890842807 IN IP4 192.168.10.10
s=3GPP Unicast SDP Example
i=Example of Unicast SDP file
u=https://www.sodocs.net/doc/781251786.html,/ae600
e=ghost@https://www.sodocs.net/doc/781251786.html,
c=IN IP4 0.0.0.0
b=AS:128
t=0 0
a=range:npt=0-45.678
m=video 1024 RTP/AVP 96
b=AS:128
a=rtpmap:96 H263-2000/90000
a=fmtp:96 profile=3;level=10
a=control:rtsp;//https://www.sodocs.net/doc/781251786.html,/movie
a=recvonly
就如我们以前所了解的，对于直播，我们在建立了直播源后，就会将生成的SDP文件broadcast.sdp 放在服务器上，而用户使用rtsp://ip:port/broadcast.sdp就可以进行直播节目的播放，这里的sdp文件里的内容就是上面所提到的这些。它将我们在建立直播源时所设置的音、视频编码，及相应的码率记录下来存在broadcast.sdp文件中，这样手机在进行进播时，得到了相关的SDP信息，然后根据这些信息与服务器建立连接。
3.3 数据传送
控制及媒体数据的传送是通过TCP/IP和UPD/IP上完成的，下图是一个协议栈的简单描述。媒体数据被打包成RTP包进行传送。
图3协议栈的简单描述
3.4 消息流程
下面让我们来看一个具体的消息交互过程。我们可以通过ETHEREAL或是TCPDUMP这些抓包工具来获得这些信息。
c->s【向服务器请求SDP信息】
【DESCRIBE】DESCRIBE rtsp://211.94.164.227/3.3gp RTSP/1.0
【交互标识】CSeq: 1
【请求内容】Accept: application/sdp
【用户标识】User-Agent:01056SS68001117616022101802836055;
14;41;4578;327;13824;0;1;0x0202;0x00000B;0x028010
s->c 【服务端返回SDP信息】
【成功响应】RTSP/1.0 200 OK
【服务器版本号】Server: HMS Mobile V100R001B08D023
【交互标识】CSeq: 1
【SDP长度】Content-Length: 625
【包含内容类型】Content-Type: application/sdp
【包含内容信息】Content-Base: rtsp://211.94.164.227/3.3gp/
【以下为SDP内容】
【SDP版本号】v=0
【服务器信息】o=StreamingServer 3276474929 1067418948000 IN
IP4 10.70.139.108
【文件名】s=3.3gp
【URL】u=rtsp://211.94.164.227/3.3gp
【e-mail】e=admin@
【IPv4】c=IN IP4 0.0.0.0
t=0 0
【控制属性】a=control:rtsp://211.94.164.227/3.3gp
【视频信息】m=video 0 RTP/AVP 96【媒体类型】
【视频带宽】b=AS:16
【视频格式】a=rtpmap:96 MP4V-ES【格式】/90000【采样率】
【视频格式】a=fmtp:96 profile-level-id=8;
config=000001B008000001B50EA020202F000001000000012000C788BA9850584121463F
a=mpeg4-esid:201
【厂家信息】a=x-envivio-verid:00011118
【视频轨道】a=control:trackID=65737
【音频信息】m=audio 0 RTP/AVP 97【媒体类型】
【音频带宽】b=AS:19
【音频格式】a=rtpmap:97 MP4A-LATM【格式】/11025【采样率】/1
a=fmtp:97 profile-level-id=15; object=2;
cpresent=0; config=40002A103FC0
a=mpeg4-esid:101
【厂家信息】a=x-envivio-verid:00011118
【音频轨道】a=control:trackID=65637
c->s 【向服务器发起建立视频连接的呼叫】
【SETUP信令】SETUP rtsp://211.94.164.227/3.3gp/trackID=65737 RTSP/1.0
CSeq: 2
【传输信息】Transport: RTP/AVP;unicast【单播区别组播】;
client_port=5004-5005【客户端端口号】
s->c【服务器返回视频连接建立成功信息】
RTSP/1.0 200 OK
Server: HMS Mobile V100R001B08D023
CSeq: 2
【会话标识】Session: 4
【传输信息】Transport: RTP/AVP;unicast;client_port=5004-5005;
source=211.94.164.227;【服务器IP】
server_port=8090-8091【服务器端口号】;
ssrc=3e06【同步源描述符】
c->s【向服务器发起建立音频连接的呼叫】
SETUP rtsp://211.94.164.227/3.3gp/trackID=65637 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=5006-5007
Session: 4
s->c【服务器返回音频连接建立成功信息】
RTSP/1.0 200 OK
Server: HMS Mobile V100R001B08D023
CSeq: 3
Session: 4
Transport: RTP/AVP;unicast;client_port=5006-5007;
source=211.94.164.227;server_port=8092-8093;ssrc=3e06
c->s【向服务器发出播放请求】
PLAY rtsp://211.94.164.227/3.3gp RTSP/1.0
CSeq: 4
Session: 4
【播放位置】Range: npt=now- 【从当前位置开始播放】
s->c【服务器返回发出播放成功响应请求】
RTSP/1.0 200 OK
Server: HMS Mobile V100R001B08D023
CSeq: 4
Session: 4
【RTP信息】RTP-Info: url=trackID=65737;【轨道信息】seq=1;【RTP包序列号】
rtptime=0【RTP包时间戳】,url=trackID=65637;seq=1;rtptime=0 【播放范围】Range: npt=0.000000-60.193000
s->c【服务器发送视音频数据给终端】
【RTP包略】xxxx
c->s【向服务器发送终止请求】
【TEARDOWN信令】TEARDOWN rtsp://211.94.164.227/3.3gp RTSP/1.0
CSeq: 5
Session: 4
s->c【服务器返回终止成功信息】
RTSP/1.0 200 OK
Server: HMS Mobile V100R001B08D023
CSeq: 5
Session: 4
RTSP(实时流媒体协议)
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协议原理及应用 内部公开▲ 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协议学习笔记 目录 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)
RTC PRTP RTSP协议简介
一、 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.sodocs.net/doc/781251786.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协议学习笔记
目录 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)
RTSP中文版(实时流媒体协议)
E-mail：bryanj@https://www.sodocs.net/doc/781251786.html, 译者：Bryan.Wong（王晶，宁夏固原） 译文版本：alpha 0.80 译文发布时间：2007-7-25 版权：本中文翻译文档之版权归王晶所有。可于非商业用途前提下自由转载，但必须保留此翻译及版权信息。 https://www.sodocs.net/doc/781251786.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 消息头
rtsp协议摄像头
编号：_______________本资料为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协议以客户服务器方式工作，它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制，如：暂停/继续、后退、前进等。因此 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 媒体传输和控制协议
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协议 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 ALG应用
一．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又称为“因特网录像机遥控协议”。 RTSP(Real-Time Stream Protocol)是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学,网景和RealNetworks公司提交的IETF RFC 标准.对应的RFC编号是2326，可以在这里搜索 https://https://www.sodocs.net/doc/781251786.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协议与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协议转换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.sodocs.net/doc/781251786.html,/haibindev/archive/2011/12/29/2305712.html），实现摄像头直播”的技术方法，来加以实现。因此，主要需要处理的就是RTSP 直播流数据的获取，以及对其中H.264和AAC编码数据的处理。 于是可以画出大体结构如下： RtmpThread的主要工作就是发送音频数据流的解码信息头和视频数据流的解码信息头，并不断从DataBufferQueue中取出数据，封装为RTMP Packet，发送出去。流程如下列代码所示：（process_buf_queue_，即是上图中的DataBufferQueue）
RTSP协议总结
第一部分: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)来结束流媒体会话
RTPRTCPRTSP协议详解
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计算方法)
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协议原理及应用
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协议
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.sodocs.net/doc/781251786.html,/staff/sdp.ps e=* (email address) //e=zte@https://www.sodocs.net/doc/781251786.html,(general text如：王生) //或e=Mr. Wang