rtsp协议分析.docx
- 文档编号:6257614
- 上传时间:2023-01-04
- 格式:DOCX
- 页数:10
- 大小:24.49KB
rtsp协议分析.docx
《rtsp协议分析.docx》由会员分享,可在线阅读,更多相关《rtsp协议分析.docx(10页珍藏版)》请在冰豆网上搜索。
rtsp协议分析
竭诚为您提供优质文档/双击可除
rtsp协议分析
篇一:
Rtsp协议学习笔记
第一部分:
总体概述
一、流媒体概念
流媒体包含广义和狭义两种内涵:
广义上的流媒体指的是使音频和视频形成稳定和连续的传输流和回放流的一系列技术、方法和协议的总称,即流媒体技术;狭义上的流媒体是相对于传统的下载-回放方式而言的,指的是一种从internet上获取音频和视频等多媒体数据的新方法,它能够支持多媒体数据流的实时传输和实时播放。
通过运用流媒体技术,服务器能够向客户机发送稳定和连续的多媒体数据流,客户机在接收数据的同时以一个稳定的速率回放,而不用等数据全部下载完之后再进行回放。
二、流媒体协议
实时传输协议(Real-timetransportprotocol,Rtp)是在internet上处理多媒体数据流的一种网络协议,利用它能够在一对一(unicast,单播)或者一对多(multicast,多播)的网络环境中实现传流媒体数据的实时传输。
Rtp通常使用udp来进行多媒体数据的传输,但如果需要的话可以使用tcp或者atm等其它协议,整个Rtp协议由两个密切相关的部分组成:
Rtp数据协议和Rtp控制协议。
实时流协议(Realtimestreamingprotocol,Rtsp)最早由Realnetworks和netscape公司共同提出,它位于Rtp和Rtcp之上,其目的是希望通过ip网络有效地传输多媒体数据。
实时流传输协议Rtsp(Real-timestreamingprotocol,RFc2326)、
实时传输协议(RtpReal-timetransferprotocol,RFc3550)、
实时传输控制协议(RtcpReal-timetransportcontrolprotocol,RFc1889)、
会话描述协议(sdpsessiondescriptionprotocol,RFc2327)。
目前在流媒体传输技术中使用最多的就是基于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所示:
图1Rtp头部格式
其中比较重要的几个域及其意义如下:
1、Version(V):
RFc1889Version
(2)
2、padding填充标志(p):
False
3、extension扩展标志(x):
False
4、csRc(contributingsourceidentifierscount)记数(cc):
表示csRc标识的数目。
csRc标识紧跟在Rtp固定头部之后,用来表示Rtp数据报的来源,Rtp协议允许在同一个会话中存在多个数据源,它们可以通过Rtp混合器合并为一个数据源。
例如,可以产生一个csRc列表来表示一个电话会议,该会议通过一个Rtp混合器将所有讲话者的语音数据组合为一个Rtp数据源。
5、m:
标志位。
标志位的具体解释可由具体协议规定。
如可用于帧边界标志。
6、负载类型(payloadtype)(pt):
标明Rtp负载的格式,包括所采用的编码算法、采样频率、承载通道等。
例如,类型2表明该Rtp数据包中承载的是用itug.721算法编码的语音数据,采样频率为8000hz,并且采用单声道。
对于h.264来说,该值为105。
7、序列号(sequencenumber):
用来为接收方提供探测数据丢失的方法,但如何处理丢失的数据则是应用程序自己的事情,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库,它完全遵循RFc1889设计,在很多场合下是一个非常不错的选择。
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安全实时传输协议(secureReal-timetransportprotocol或sRtp)是在实时传输协议(Real-timetransportprotocol或Rtp)基础上所定义的一个协议,旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。
它是由davidoran(思科)和Rolfblom(爱立信)开发的,并最早由ietF于20xx年3月作为RFc3711发布。
由于实时传输协议和可以被用来控制实时传输协议的会话的实时传输控制协议(Rtpcontrolprotocol或Rtcp)有着紧密的联系,安全实时传输协议同样也有一个伴生协议,它被称为安全实时传输控制协议(secureRtcp或sRtcp);安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性,就像安全实时传输协议为实时传输协议提供的那些一样。
在使用实时传输协议或实时传输控制协议时,使不使用安全实时传输协议或安全实时传输控制协议是可选的;但即使使用了安全实时传输协议或安全实时传输控制协议,所有它们提供的特性(如加密和认证)也都是可选的,这些特性可以被独立地使用或禁用。
唯一的例外是在使用安全实时传输控制协议时,必须要用到其消息认证特性。
第五部分:
Rtsp协议
一、Rtsp协议概述
Rtsp(Real-timestreamprotocol)作为一个应用层协议,提供了一个可供扩展的框架,它的意义在于使得实时流媒体数据的受控和点播变得可能。
总的说来,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为http1.1;
2.http是无状态的协议,而Rtsp为每个会话保持状态;
3.Rtsp协议的客户端和服务器端都可以发送Request请求,而在httpF协议中,只有客户端能发送Request
请求。
4.在Rtsp协议中,载荷数据一般是通过带外方式来传送的(除了交织的情况),及通过Rtp协议在不同的通
道中来传送载荷数据。
而http协议的载荷数据都是通过带内方式传送的,比如请求的网页数据是在回应的消息体中携带的。
5.使用iso10646(utF-8)而不是iso8859-1,以配合当前html的国际化;
6.Rtsp使用uRi请求时包含绝对uRi。
而由于历史原因造成的向后兼容性问题,http/1.1只在请求中包含绝
对路径,把主机名放入单独的标题域中;
三、Rtsp重要术语
1、集合控制(aggregatecontrol):
对多个流的同时控制。
对音频/视频来讲,客户端仅需发送一条播放或者暂停消息就可同时控制音频流和视频流。
2、实体(entity):
作为请求或者回应的有效负荷传输的信息。
由以实体标题域(entity-headerfield)形式存在的元信息和以实体主体(entitybody)形式存在的内容组成
3、容器文件(containerfile):
可以容纳多个媒体流的文件。
Rtsp服务器可以为这些容器文件提供集合控制。
4、Rtsp会话(Rtspsession):
Rtsp交互的全过程。
对一个电影的观看过程,会话(session)包括由客户端建立媒体流传输机制(setup),使用播放(play)或录制(RecoRd)开始传送流,用停止(teaRdown)关闭流。
四、Rtsp请求消息
篇二:
Rtsp中文版(实时流媒体协议)
本文为internet社区描述了一种internet标准跟踪协议,还需要讨论和建议以便进行改善。
请查看最新版本的"internet正式协议标准"(std1)了解本协议的标准化进程和状态。
本备忘录的传播不受限制。
版权声明:
摘要:
实时流协议(Rtsp)是应用层协议,控制实时数据的传送。
Rtsp提供了一个可扩展框架,使受控、按需传输实时数据(如音频与视频)成为可能。
数据源包括现场数据与存储在剪辑中的数据。
本协议旨在于控制多个数据发送会话,提供了一种选择传送途径(如udp、组播udp与tcp)的方法,并提供了一种选择基于Rtp(RFc1889)的传送机制的方法。
目录:
1介绍1.1目的1.2要求1.3术语1.4协议特性1.5Rtsp扩展1.6整体运作1.7Rtsp状态1.8与其他协议的关系2符号协定3协议参数3.1Rtsp版本3.2RtspuRl3.3会议标识3.4会话标识3.5smpte相对时间戳3.6正常播放时间3.7绝对时间
3.8.1用iana注册新的选项标签*4Rtsp消息4.1消息类型4.2消息头4.3消息主体4.4消息长度*5普通头部段*6请求6.1请求行6.2请求消息头段*7响应7.1状态行7.1.1状态码和原因短语7.1.2响应头部段*8实体8.1实体头部域8.2实体主体24*9连接9.1流水线化259.2可靠性及确认25*10方法定义2510.1可选项2610.2描述2610.3通知2610.4建立2610.5播放2710.6暂停2710.7断开2710.8获取参数28
10.9设置参数28
10.10重定向28
10.11录制29
10.12嵌入(交织)的二进制数据29*11状态码定义29
11.1成功2xx30
11.1.1存储空间低25030
11.2重定向3xx31
11.3客户端错误4xx31
11.3.1方法不允许32
11.3.2无法理解参数32
11.3.3会议未找到33
11.3.4带宽不足33
11.3.5会话未找到34
11.3.6本状态下该方法无效34
11.3.7头部域与资源不匹配34
11.3.8无效范围35
11.3.9参数为只读35
11.3.10不允许合操作36
11.3.11只允许合操作36
11.3.12不支持的传输36
11.3.13目标不可达37
11.3.14不支持的选项37
12头部段定义(headerFielddefinitins)12.1接受38
12.2接受-编码38
12.3接受-语言39
12.4允许(allw)39
12.5授权(authrizatin)40
12.6带宽4038
12.7块大小40
12.8缓存控制41
12.9会议41
12.10连接41
12.11内容-基础42
12.12内容-编码(cntent-encding)4212.13内容-语言43
12.14内容-长度(cntent-length)4312.15内容-位置43
12.16内容-类型(cntent-type)4412.17命令序列题头(cseq)4412.18日期(date)44
12.19过期(expires)45
12.20来自(Frm)45
12.21主机45
12.22如果匹配45
12.23如果-被修改-自从(if-mdified-since)12.24最后修改(last-mdified)4612.25位置(lcatin)46
12.26代理认证47
12.27代理要求47
12.28公布47
12.29范围49
12.30提交方(Referer)49
12.31稍后重试49
12.32要求49
12.33Rtp信息49
12.34倍速(scale)
12.35速度49
12.36服务器(server)4946
12.37会话4912.38时间戳4912.39传输4912.40不支持4912.41用户代理(user-agent)4912.42变化4912.43通过4912.44www-认证(www-authenticate)50*13缓存50*14例子5014.1按需点播(单播)5014.2容器文件的流化5114.3单个流容器文件5114.4实况媒体表示的组播5114.5在存在的会话中播放媒体5114.6录制52*15语法5215.1基本语法5216安全考虑(securitycnsideratins)52*附录aRtsp协议状态机53*a.1客户端状态机53*a.2服务器端状态机53*附录b与Rtp协议的交互53*附录c使用sdp进行Rtsp会话描述54+c.1定义54c.1.1控制uRl55c.1.2媒体流55c.1.3有效载荷类型55c.1.4详细格式参数55c.1.5表示的范围56
篇三:
Rtsp实时流媒体协议简单交互过程
Rtsp简介(zt)
Realtimestreamingprotocol或者Rtsp(实时流媒体协议),是由Realnetwork和netscape共同提出的如何有效地在ip网络上传输流媒体数据的应用层协议。
Rtsp提供一种可扩展的框架,使能够提供能控制的,按需传输实时数据,比如音频和视频文件。
源数据可以包括现场数据的反馈和存贮的文件。
rtsp对流媒体提供了诸如暂停,快进等控制,而它本身并不传输数据,rtsp作用相当于流媒体服务器的远程控制。
传输数据可以通过传输层的tcp,udp协议,rtsp也提供了基于rtp传输机制的一些有效的方法。
Rtsp消息格式:
Rtsp的消息有两大类,一是请求消息(request),一是回应消息(response),两种消息的格式不同.
请求消息:
方法uRiRtsp版本cRlF
消息头cRlFcRlF
消息体cRlF
其中方法包括option回应中所有的命令,uRi是接受方的地址,例
如:
rtsp:
//192.168.20.136Rtsp版本一般都是Rtsp/1.0.每行后面的cRlF表示回车换行,需要接受端有相应的解析,最后一个消息头需要有两个cRlF回应消息:
Rtsp版本状态码解释cRlF
消息头cRlFcRlF
消息体cRlF
其中Rtsp版本一般都是Rtsp/1.0,状态码是一个数值,200表示成功,解释是与状态码对应的文本解释.
简单的rtsp交互过程:
c表示rtsp客户端,s表示rtsp服务端
1.c->s:
optionrequest//询问s有哪些方法可用
1.s->c:
optionresponse//s回应信息中包括提供的所有可用方法
2.c->s:
descRiberequest//要求得到s提供的媒体初始化描述信息
2.s->c:
descRiberesponse//s回应媒体初始化描述信息,主要是sdp
3.c->s:
setuprequest//设置会话的属性,以及传输模式,提醒s建立会话
3.s->c:
setupresponse//s建立会话,返回会话标识符,以及会话相关信息
4.c->s:
playrequest//c请求播放
4.s->c:
playresponse//s回应该请求的信息
s->c:
发送流媒体数据
5.c->s:
teaRdownrequest//c请求关闭会话
5.s->c:
teaRdownresponse//s回应该请求
上述的过程是标准的、友好的rtsp流程,但实际的需求中并不一定按部就班来。
其中第3和4步是必需的!
第一步,只要服务器客户端约定好,有哪些方法可用,则option请求可以不要。
第二步,如果我们有其他途径得到媒体初始化描述信息(比如http请求等等),则我们也不需要通过rtsp中的describe请求来完成。
第五步,可以根据系统需求的设计来决定是否需要。
Rtsp中常用方法:
1.option方法
目的是得到服务器提供的可用方法:
optionsrtsp:
//192.168.20.136:
5000/xxx666Rtsp/1.0
cseq:
1//每个消息都有序号来标记,第一个包通常是option请求消息
user-agent:
Vlcmediaplayer(liVe555streamingmediav20xx.11.10)
服务器的回应信息包括提供的一些方法,例如:
Rtsp/1.0200ok
server:
userver0.9.7_rc1
cseq:
1//每个回应消息的cseq数值和请求消息的cseq相对应public:
options,descRibe,setup,teaRdown,play,pause,scale,get_paRameteR//服务器提供的可用的方法
2.descRibe方法
c向s发起descRibe请求,为了得到会话描述信息(sdp):
descRibe
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- rtsp 协议 分析