搜档网
当前位置:搜档网 › RTSP协议总结

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)来结束流媒体会话

1.1RTSP协议与HTTP协议区别

RTSP引入了几种新的方法,比如DESCRIBE、PLAY、SETUP 等,并且有不同的协议标识符,RTSP为rtsp 1.0,HTTP为http 1.1;

HTTP是无状态的协议,而RTSP为每个会话保持状态;

RTSP协议的客户端和服务器端都可以发送Request请求,而在HTTPF 协议中,只有客户端能发送Request请求。

在RTSP协议中,载荷数据一般是通过带外方式来传送的(除了交织的情况),及通过RTP协议在不同的通道中来传送载荷数据。而HTTP协议的载荷数据都是通过带内方式传送的,比如请求的网页数据是在回应的消息体中携带的。

使用ISO 10646(UTF-8) 而不是ISO 8859-1,以配合当前HTML的国际化;

RTSP使用URI请求时包含绝对URI。而由于历史原因造成的向后兼容性问题,HTTP/1.1只在请求中包含绝对路径,把主机名放入单独的标题域中;

1.2 RTSP重要术语

集合控制(Aggregate control ):

对多个流的同时控制。对音频/视频来讲,客户端仅需发送一条播放或者暂停消息就可同时控制音频流和视频流。

实体(Entity):

作为请求或者回应的有效负荷传输的信息。由以实体标题域(entity-header field)形式存在的元信息和以实体主体(entity body)形式存在的内容组成容器文件(Container file):

可以容纳多个媒体流的文件。RTSP服务器可以为这些容器文件提供集合控制。RTSP会话(RTSP session ):

RTSP交互的全过程。对一个电影的观看过程,会话(session)包括由客户端建立媒体流传输机制(SETUP),使用播放(PLAY)或录制(RECORD)开始传送流,用停止(TEARDOWN)关闭流。

1.3 RTSP请求消息

消息格式:

方法 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消息并不带消息体。

1.4 RTSP回应消息

消息格式:

RTSP版本状态码解释CR LF

消息头 CR LF CR LF

消息体 CR LF

其中RTSP版本一般都是RTSP/1.0,状态码是一个数值,用于表示Request消息的执行结果,比如200表示成功,解释是与状态码对应的文本解释.

1.5 RTSP 重要方法

1.OPTIONS:

用于得到服务器提供的可用方法,如:

OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0

CSeq: 1

服务器的回应信息会在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.sodocs.net/doc/9315118365.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.sodocs.net/doc/9315118365.html,/staff/M.Handley/sdp.03.ps

e=mjh@https://www.sodocs.net/doc/9315118365.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.sodocs.net/doc/9315118365.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.sodocs.net/doc/9315118365.html,/audio RTSP/1.0

CSeq: 835

Session: 12345678

Range: npt=10-15

C->S: PLAY rtsp://https://www.sodocs.net/doc/9315118365.html,/audio RTSP/1.0

CSeq: 836

Session: 12345678

Range: npt=20-25

C->S: PLAY rtsp://https://www.sodocs.net/doc/9315118365.html,/audio RTSP/1.0

CSeq: 837

Session: 12345678

Range: npt=30-

Range头可能包含一个时间参数。该参数以UTC格式指定了播放开始的时间。如果在这个指定时间后收到消息,那么播放立即开始。时间参数可能用来帮助同步从不同数据源获取的数据流。

不含Range头的PLAY请求也是合法的。它从媒体流开头开始播放,直到媒体流被暂停。

如果媒体流通过PAUSE暂停,媒体流传输将在暂停点(the pause point)重新开始。

如果媒体流正在播放,那么这样一个PLAY请求将不起更多的作用,只是客户端可以用此来测试服务器是否存活。

如上所示,range:0.00-3431代表了对应的流长度为57分11秒。

5.PAUSE:

PAUSE请求引起媒体流传输的暂时中断。如果请求URL中指定了具体的媒体流,那么只有该媒体流的播放和记录被暂停(halt)。比如,指定暂停音频,播放将会无声。如果请求URL 指定了一组流,那么在该组中的所有流的传输将被暂停。如:

C->S: PAUSE rtsp://https://www.sodocs.net/doc/9315118365.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.sodocs.net/doc/9315118365.html,/fizzle/foo RTSP/1.0

CSeq: 892

Session: 12345678

S->C: RTSP/1.0 200 OK

CSeq: 892

1.6 RTSP重要头字段参数

7.Accept:

用于指定客户端可以接受的媒体描述信息类型。比如:

Accept: application/rtsl, application/sdp;level=2

8.Bandwidth:

用于描述客户端可用的带宽值。

9.CSeq:

指定了RTSP请求回应对的序列号,在每个请求或回应中都必须包括这个头字段。对每个包含一个给定序列号的请求消息,都会有一个相同序列号的回应消息。

10.Rang:

用于指定一个时间范围,可以使用SMPTE、NTP或clock时间单元。

11.Session:

Session头字段标识了一个RTSP会话。Session ID 是由服务器在SETUP的回应中选择的,客户端一当得到Session ID后,在以后的对Session 的操作请求消息中都要包含Session ID.

12.Transport:

Transport头字段包含客户端可以接受的转输选项列表,包括传输协议,地址端口,TTL等。服务器端也通过这个头字段返回实际选择的具体选项。如:

Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",

RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"

1.7 简单的RTSP消息交互过程

C表示RTSP客户端,S表示RTSP服务端

1.第一步:查询服务器端可用方法

1.C->S:OPTION request //询问S有哪些方法可用

1.S->C:OPTION response //S回应信息的public头字段中包括提供的所有可用方法

2.第二步:得到媒体描述信息

2.C->S:DESCRIBE request //要求得到S提供的媒体描述信息

2.S->C:DESCRIBE response //S回应媒体描述信息,一般是sdp信息

3.第三步:建立RTSP会话

3.C->S:SETUP request //通过Transport头字段列出可接受的传输选项,请求S建立会话

3.S->C:SETUP response //S建立会话,通过Transport头字段返回选择的具体转输选项,并返回建立的Session ID;

4.第四步:请求开始传送数据

4.C->S:PLAY request //C请求S开始发送数据

4.S->C:PLAY response //S回应该请求的信息

5.第五步:数据传送播放中

S->C:发送流媒体数据// 通过RTP协议传送数据

6.第六步:关闭会话,退出

6.C->S:TEARDOWN request //C请求关闭会话

6.S->C:TEARDOWN response //S回应该请求

上述的过程只是标准的、友好的rtsp流程,但实际的需求中并不一定按此过程。

其中第三和第四步是必需的!第一步,只要服务器客户端约定好,有哪些方法可用,则option 请求可以不要。第二步,如果我们有其他途径得到媒体初始化描述信息(比如http请求等等),则我们也不需要通过rtsp中的describe请求来完成。

第二部分:SDP协议

2. SDP协议概述

SDP 完全是一种会话描述格式― 它不属于传输协议― 它只使用不同的适当的传输协议,包括会话通知协议(SAP)、会话初始协议(SIP)、实时流协议(RTSP)、MIME 扩展协议的电子邮件以及超文本传输协议(HTTP)。SDP协议是也是基于文本的协议,这样就能保证协议的可扩展性比较强,这样就使其具有广泛的应用范围。SDP 不支持会话内容或媒体编码的协商,所以在流媒体中只用来描述媒体信息。媒体协商这一块要用RTSP来实现.SDP(Session Description Protocol )会话描述协议,用于描述多媒体会话,它为会话通知、会

话初始和其它形式的多媒体会话初始等操作提供服务。

SDP 的设计宗旨是通用性协议,所有它可以应用于很大范围的网络环境和应用程序,但SDP 不支持会话内容或媒体编码的协商操作。

SDP信息包括:

会话名称和目标;

会话活动时间;

构成会话的媒体;

有关接收媒体的信息、地址等。

2.1 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个或多个会话属性线路)

2.2 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.sodocs.net/doc/9315118365.html,/staff/M.Handley/sdp.03.ps

e=mjh@https://www.sodocs.net/doc/9315118365.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=

;O rigin ,给定了会话的发起者信息

s= ;给定了S ession Name

i= ; I nformation 关于Session的一些信息

u= ; U RI

e= ;E mail

c=

;C onnect Data包含连接数据

t= ;T ime

a= ; A ttribute

a=:

m= ; M edia Announcements

如下阐述了一个更为详细的SDP示例:

下面是一个helix 流媒体服务器的RTSP协议中的SDP协议:

v=0 //SDP version

// o field定义的源的一些信息。其格式为:o=

o=- 1271659412 1271659412 IN IP4 10.56.136.37 s=

i= //session的信息

c=IN IP4 0.0.0.0 //connect 的信息,分别描述了:网络协议,地址的类型,连接地址。

c=IN IP4 0.0.0.0

t=0 0 //时间信息,分别表示开始的时间和结束的时间,一般在流媒体的直播的时移中见的比较多。

a=SdpplinVersion:1610641560 //描述性的信息

a=StreamCount:integer;2 //用来描述媒体流的信息,表示有两个媒体流。integer表示信息的格式为整数。

a=control:*

a=DefaultLicenseValue:integer;0 //License信息

a=FileType:string;"MPEG4" ////用来描述媒体流的信息说明当前协商的文件是mpeg4格式的文件

a=LicenseKey:string;"license.Summary.Datatypes.RealMPEG4.Enabled"

a=range:npt=0-72.080000 //用来表示媒体流的长度

m=audio 0 RTP/A VP 96 //做为媒体描述信息的重要组成部分描述了媒体信息的详细内容:表示session的audio是通过RTP来格式传送的,其payload值为96传送的端口还没有定。b=as:24 //audio 的bitrate

b=RR:1800

b=RS:600

a=control:streamid=1 //通过媒体流1来发送音频

a=range:npt=0-72.080000 //说明媒体流的长度。

a=length:npt=72.080000

a=rtpmap:96 MPEG4-GENERIC/32000/2 //rtpmap的信息,表示音频为AAC的其sample为32000

a=fmtp:96

profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=121 0 //config为AAC的详细格式信息

a=mimetype:string;"audio/MPEG4-GENERIC"

a=Helix-Adaptation-Support:1

a=AvgBitRate:integer;48000

a=HasOutOfOrderTS:integer;1

a=MaxBitRate:integer;48000

a=Preroll:integer;1000

a=OpaqueData:buffer;"A4CAgCIAAAAEgICAFEA V ABgAAAC7gAAAu4AFgICAAhKIBoCAg AEC"

a=StreamName:string;"Audio Track"

下面是video的信息基本和audio的信息相对称,这里就不再说了。

m=video 0 RTP/A VP 97

b=as:150

b=RR:11250

b=RS:3750

a=control:streamid=2

a=range:npt=0-72.080000

a=length:npt=72.080000

a=rtpmap:97 MP4V-ES/2500

a=fmtp:97 profile-level-id=1;

a=mimetype:string;"video/MP4V-ES"

a=Helix-Adaptation-Support:1

a=AvgBitRate:integer;300000

a=HasOutOfOrderTS:integer;1

a=Height:integer;240 //影片的长度

a=MaxBitRate:integer;300000

a=MaxPacketSize:integer;1400

a=Preroll:integer;1000

a=Width:integer;320 //影片的宽度

a=OpaqueData:buffer;"AzcAAB8ELyARAbd0AAST4AAEk+AFIAAAAbDzAAABtQ7gQMDP

AAABAAAAASAAhED6KFAg8KIfBgEC"

a=StreamName:string;"Video Track"

第三部分:项目流程

3.1模块关系和交互流程

图2 模块关系图

在视频分析仪上运行RTSP client程序用于和流媒体服务器上的RTSP server程序交互,完成流媒体播放的控制,然后流媒体服务器才能开始下放视频流。

图3 VA实现中RTSP交互图

从RTSP client发出的是请求消息对应上图中的1、3、5、7、9,从RTSP server发出的是回应消息对应上图中的2、4、6、8、10。下面对交互过程中的重要参数做一些解释。

1 C->S: DESCRIBE request 请求消息中必须携带所请求播放的资源URL ,比如:rtsp://58.223.228.214:554/vod/00100000020001083765.mpg,且必须携带的参数如下:江苏和上海版本vcdnid=vcdn001&boid=001&playtype=0&nodelevel=3。安徽版本vcdnid=001&boid=001&playtype=%d&nodelevel=3 ,其中playtype(0:点播,2:回看)。

2 S->C: DESCRIBE reply 回复消息中第一行为RTSP/1.0 200 OK 表示正确回复。否则表示发生了错误,同时会给出错误码。如果回复302则表示需要重定向,返回前一步。该回复中携带sdp信息,附录中有sdp信息的简单介绍。

3 C->S: SETUP request 请求消息中必须携带接收视频流的address和port(具体的协议UDP或TCP由服务器选择)。

4 S->C: SETUP reply 回复消息中会携带服务器选择的协议(TCP 或者UDP),以及选择的相应port,同时会给出一个session会话号标记本次会话。

5 C->S: PLAY request 请求播放视频。请求消息中需要携带会话号session。以及请求播放的视频范围。如果在非NAT情况下,当服务器收到该消息流开始下放。

6 S->C: PLAY reply 回复可以开始播放,回复码为200,否则表示发生了错误。如果是NAT情况下,client端收到server端的消息后需要发送一个84B的UDP数据包,完成NAT 穿越的工作,当server端收到该84B的UDP数据包以后开始下放流。(由于视频分析仪是在源端监控,所以是属于非NAT的情况。)

7 C->S: GET_PARAMETER request 每隔15秒发送一次

8 S->C: GET_PARAMETER reply 如果2分钟收不到则server端发送annonce并且强制截断视频流。

9 C->S TEARDOWN request 请求关闭此次会话。

10 S->C: TEARDOWN reply 回复是否成功关闭。

其中,NAT下的84B数据结构:

3.2主要的数据结构

1 rtsp_client_t

struct rtsp_client_t

{

char url[URL_STR_LEN]; //需要申请的资源URL

char *urlOtherStr; //save parameter

char *contentBase; //save setup url

char *session; //标记会话的SESSION

char *videoTime; //stream time

int notice; //announce

int videoType; //order -- 0 ; back --2;

int loIpToInt[4]; //client端IP地址

int rtpSe[10];

int CSeq; //标记会话的顺序

int clientSocket; //RTSP 交互client端的rtsp socket

int rtpFSocket; //用于流下放的第一个rtp socket

int rtpSSocket; //用于流下放的第二个 rtp socket

char conDev[16]; //ETH0

char localAddr[24]; //字符型client端IP地址

char localMac[32]; //字符型client端MAC地址

uint16 localPort; //RTSP 交互过程中使用的port

uint16 rtpLfPort; //用于流下放的第一个port

uint16 rtpLsPort; //用于流下放的第二个port(有服务端选择具体那个port) TIMEVAL parmtv; //recode getparameter time

TIMEVAL udptv; //recode udp 84B time

pthread_mutex_t rtspPauseMutex;

int pauseFlag; //pause

pthread_mutex_t rtPortMutex; //rtp port

pthread_mutex_t rtspCloseMutex; //close

int closeFlag;

pthread_mutex_t rtspErrorMutex; //error

int errorFlag;

}rtsp_client_t;

该数据结构是RTSP 交互的核心数据结构。

2 rtspRecvBuff

struct rtspRecvBuff

{

enum rtspSessionStatus sessionStatus;

int m_buffer_len;

int m_offset_on;

char m_recv_buffer[SEND_RECV_BUFF_LEN + 1];

enum rtspResponse recvState;

}

该数据结构用于记录发送和受到的数据信息。sessionStatus 用于记录当前的状态,根据此状态client端选择所采取的动作,m_buffer_len用于记录收到的消息体的长度,m_offset_on用于记录需求的信息在buffer中的偏移量。m_recv_buffer是一个数组用于存放消息体,recvState用于存放当前受到的回复状态。

3rtspInfoH

struct rtspInfoH

{

char *accept;

char *authorization;

char *range;

char *session;

char *transport;

char *zmssRtxSdp;

char *adaption;

char *scale;

char *xNat;

int speed;

};

该数据结构用于暂时存放RTSP client端待发送的请求消息头的一些信息。每次发送消息前由程序根据当前client端状态和收到的server端的回复信息填充(每一次填充的内容会有区别具体请查看源代码)。

4 rtspRespH

struct rtspRespH

{

int content_length;

int cseq;

char *content_base;

char retcode[4];

char *body;

char *caption;

char *retresp;

char *rtp_info;

char *session;

char *xnotice;

char *transport;

char *location;

};

该数据结构用于存放RTSP server端返回的消息,其中content_length表示收到的消息体的长度,body用于存放消息体内容,cseq表示当前的会话顺序号,session标记会话号,transport:server端告之client端视频流采用何种方式。

3.3流程图和接口函数

图4 RTSP交互流程图

RTSP Client端根据自己当前的状态发送请求消息(describe、setup、play)给RTSP server端,然后server端返回一个消息,client端需要先处理返回过来的消息然后跟新自己的当前状态,由当前的新状态来决定下一步所以采取的动作。视频流数据是通过RTP方式发送过来,client端在接收视频流期间,每隔15秒发送getparameter给server端。在视频流结束时,server端发送announce给client端(xnotice—2101:表示server端视频流的正常结束,2103:表示server端强制截断视频流),然后client端再发送teardown给server端。

接口函数

1 rtspStructInit

Int rtspStructInit(rtsp_client_t *rtspClientInfo,char *rtspUrl,int type,char*dev);

功能:根据传入的参数:rtspUrl,type,dev,初始化结构体rtspClientInfo

返回值:成功返回1否则返回-1。

2 rtspRunProcess

int rtspRunProcess(rtsp_client_t *rtspClientInfo);

功能:根据传入的rtspClientInfo完成RTSP(describe/setup/play)交互。

返回值:错误返回-1,成功返回相应代码。

3 rtspKeepAliveRun

static void *rtspKeepAliveRun(void *rtspClientInfo)

功能:主要进行每隔15秒的getparameter发送,以及检测announce以便发送teardown.

4 getRtpPort

int getRtpPort(rtsp_client_t *rtspClientInfo, uint16 *port);

功能:根据rtspClientInfo,返回RTP port。

返回值:成功返回port,错误返回-1.

现网RTSP交互阐述

以江苏现网为例

(1)对于NAT环境下,通过RTP及RTCP两个端口发送udp keepalive消息(每5s发送一次,发送内容如下)。

而应答接收到的内容则为:ZXV10USS,RTP或RTCP任一端口socket通信接收到该信息则跳出loop

(2)每15s发送一次keepalive消息(通过GET_PARAMETER方法发送)

client_info->client_socket端口维护,非RTP及RTCP端口

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/9315118365.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/9315118365.html, 译者:Bryan.Wong(王晶,宁夏固原) 译文版本:alpha 0.80 译文发布时间:2007-7-25 版权:本中文翻译文档之版权归王晶所有。可于非商业用途前提下自由转载,但必须保留此翻译及版权信息。 https://www.sodocs.net/doc/9315118365.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/9315118365.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/9315118365.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/9315118365.html,/staff/sdp.ps e=* (email address) //e=zte@https://www.sodocs.net/doc/9315118365.html,(general text如:王生) //或e=Mr. Wang p=* (phone number) //p=+86-0755-********-7110(wang) 6011 253 617 p=+1 //or c=* (connection information -如已经包含在所有媒体中则该行不需要) //c=<网络类型><地址信息><连接地址> //多点会议包括TTL //连接地址: // //c=IN IP4 224.2.13.23/127