RTSP传输协议之Methods总结

 

 

  1. RTSP/1.0 200 OK  
  2. Server: DSS/5.5.5 (Build/489.16; Platform/Linux; Release/Darwin; state/beta; )  
  3. Cseq: 1  
  4. Last-Modified: Mon, 07 May 2007 20:03:31 GMT  
  5. Cache-Control: must-revalidate  
  6. Content-length: 1207  
  7. Date: Mon, 12 Aug 2013 08:08:55 GMT  
  8. Expires: Mon, 12 Aug 2013 08:08:55 GMT  
  9. Content-Type: application/sdp  
  10. x-Accept-Retransmit: our-retransmit  
  11. x-Accept-Dynamic-Rate: 1  
  12. Content-Base: rtsp://192.168.1.100/sample_100kbit.mp4/  
  13.   
  14. v=0  
  15. o=StreamingServer 3585283734 1178568211000 IN IP4 192.168.1.100  
  16. s=/sample_100kbit.mp4  
  17. u=http:///  
  18. e=admin@  
  19. c=IN IP4 0.0.0.0  
  20. b=AS:96  
  21. t=0 0  
  22. a=control:*  
  23. a=mpeg4-iod:"data:application/mpeg4-iod;  
  24. a=isma-compliance:1,1.0,1  
  25. a=range:npt=0-  70.00000  
  26. m=video 0 RTP/AVP 96  
  27. b=AS:76  
  28. a=rtpmap:96 MP4V-ES/90000  
  29. a=control:trackID=3  
  30. a=cliprect:0,0,242,192  
  31. a=framesize:96 192-242  
  32. a=fmtp:96 profile-level-id=1;config=000001B0F3000001B50EE040C0CF0000010000000120008440FA283020F2A21F  
  33. a=mpeg4-esid:201  
  34. m=audio 0 RTP/AVP 97  
  35. b=AS:20  
  36. a=rtpmap:97 mpeg4-generic/8000/2  
  37. a=control:trackID=4  
  38. a=fmtp:97 profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1590  
  39. a=mpeg4-esid:101  

 

如果媒体客户端从一个数据源获得表示描述，而非通过 DESCRIBE，并且该描述包含了一个媒体初始化参数的全集，那么客户端就应该使用这些参数,而不是再通过 RTSP 请求相同媒体的描述。再有，服务器不应该使用DESCRIBE Response作为media indirection的方法。

需要建立基本的规则,使得客户端有明确的方法了解何时通过 DESCRIBE 请求媒体初始化信息,何时不请求。强制 DESCRIBE 响应包含它所描述媒体流集合的所有初始化信息,不鼓励将 DESCRIBE 用作 media indirection 的方法,通过这两点避免了使用其他方法可能会引起的循环问题(looping problems).媒体初始化是任何基于RTSP系统的必要条件,但RTSP规范并没有规定它必须通过DESCRIBE方法完成。RTSP客户端可以通过3种方法来接收媒体初始化信息：

（1）利用DESCRIBE方法

（2）利用其它一些协议(HTTP,email 附件,等)

（3）利用命令行或标准输入(同一个 SDP 或其它媒体初始化格式的文件一起启动,工作方式类似于浏览器的帮助程序)

为了实际协同工作，对于最精简的服务器也推荐支持 DESCRIBE 方法，最精简的客户端也支持从标准输入,命令行和/或其它对于客户端操作环境合适的方法来接收媒体初始化文件的能力。

2、SETUP

SETUP 请求为 URI 指定流式媒体的传输机制。客户端能够发出一个 SETUP 请求为正在播放的媒体流改变传输参数,服务器可能同意这些参数的改变。若是不同意,它必须响应错误"455 Method Not Valid In This State"。 为了尽量绕开防火墙干涉,即使它不会影响参数,客户端也必须指出传输参数,例如,指出服务器向外发布的固定的广播地址。

由于 SETUP 包括了所有传输初始化信息,防火墙和其他中间的网络设备(它们需要这些信息)分让了解析 DESCRIBE 响应的繁琐任务,这些任务留给了媒体初始化。Transport 首部域指定了客户端数据传输时可接受的传输参数；响应包含了由服务器选出的传输参数。

下面代码示例创建了一个SETUP请求。

 

[cpp] view plaincopy

 

 

  1. string msg;  
  2. msg.append("SETUP ");  
  3. msg.append(trackurl);  
  4. msg.append(" RTSP/1.0\r\n");  
  5. msg.append("Transport: RTP/AVP/UDP;unicast;client_port=");  
  6. msg.append(rtpPort);  
  7. msg.append("-");  
  8. msg.append(rtpPort + 1);  
  9. msg.append("\r\n");  
  10. if (trackindex > 0) {  
  11.     msg->append("Session: ");  
  12.     msg->append(mSessionID);  
  13.     msg->append("\r\n");  
  14. }  
  15. msg.append("CSeq: ");  
  16. msg.append(CSeq);  
  17. msg.append("\r\n");  
  18. msg.append("\r\n");  

 

作为对 SETUP 请求的响应,服务器产生了会话标志符。如果对服务器的请求中包含了会话标志符,服务器必须将此 setup 请求捆绑到一个存在的会话,或者返回"459Aggregate Operation Not Allowed"。

如果包含多个Stream，比如既有Audio也有Video，则需要发送多次SETUP请求，同样也会有两个Response。下面是利用DarwinStreamingSrvrlinux-Linux建立的服务器的SETUP的Response的内容示例：

 

[plain] view plaincopy

 

 

  1. RTSP/1.0 200 OK    
  2. Server: DSS/5.5.5 (Build/489.16; Platform/Linux; Release/Darwin; state/beta; )    
  3. Cseq: 2    
  4. Last-Modified: Mon, 07 May 2007 20:03:31 GMT    
  5. Cache-Control: must-revalidate    
  6. Session: 3135849742811878224    
  7. Date: Mon, 12 Aug 2013 08:08:55 GMT    
  8. Expires: Mon, 12 Aug 2013 08:08:55 GMT    
  9. Transport: RTP/AVP/UDP;unicast;source=192.168.1.100;client_port=16390-16391;server_port=6970-6971;ssrc=0B0533AE   

 

这里需要注意的一点是：在上面创建SETUP请码的代码中有一个if语句，这里为什么需要一个if语句呢？在RTSP的Spec中有这样一句话，如下：

Once a client receives a Session identifier, it MUST return it for any request related to that session.

就是说，如果客户端收到的Response中有Session ID，那么，在之后的请求中都会用这个Session ID，相应的Response也会用同一个Session ID，而不会重新创建一个。如上面的代码，mSessionID就是从第一个SETUP的Response中获得的Session ID。如果这里每次都不设置Session ID，那么服务器都会针对SETUP创建一个新的Session ID，从而就会影响后面的PLAY请求，从而影响整个播放过程。当然了，如果只要求播放某个Stream，比如Audio或者Video，那么在创建SETUP请求的时候就可以不用设置Session ID，服务器会针对每个SETUP创建一个新的Session ID。后面发送PLAY请求的时候，设置哪个Session ID，就会播放相应的Stream。

3、PLAY

PLAY 方法告知服务器通过 SETUP 中指定的机制开始发送数据 。在尚未收到SETUP 请求的成功应答之前,客户端不可以发出 PLAY 请求。PLAY 请求将正常播放时间定位到指定范围的起始处，并且传输数据流直到播放范围结束。

下面代码示例创建了一个PLAY请求。

 

[cpp] view plaincopy

 

 

  1. string msg;  
  2. msg.append("PLAY ");  
  3. msg.append(mSessionURL);  
  4. msg.append(" RTSP/1.0\r\n");  
  5. msg.append("Session: ");  
  6. msg.append(mSessionID);  
  7. msg.append("\r\n");  
  8. msg.append("Range: npt=");  
  9. msg.append(start);  
  10. msg.append("-");  
  11. msg.append(end);  
  12. msg.append("\r\n");  
  13. msg.append("CSeq: ");  
  14. msg.append(CSeq);  
  15. msg.append("\r\n");  
  16. msg.append("\r\n");  

 

PLAY 请求会被放入队列中，服务器必须将 PLAY 请求放到队列中有序执行。也就是说，后一个 PLAY 请求需要等待前一个PLAY 请求完成才能得到执行。比如，Client连续创建了三个PLAY请求，Range域的设置如下所示：

（1）Range: npt=10-15

（2）Range: npt=20-25

（3）Range: npt=30-

不管到达的两个 PLAY 请求之间有多紧凑,服务器首先 play 第10 到 15 秒,然后立即第 20 到 25 秒,最后是第 30 秒直到结束。

下面是利用DarwinStreamingSrvrlinux-Linux建立的服务器的PLAY的Response的内容示例：

 

[plain] view plaincopy

 

 

  1. RTSP/1.0 200 OK  
  2. Server: DSS/5.5.5 (Build/489.16; Platform/Linux; Release/Darwin; state/beta; )  
  3. Cseq: 4  
  4. Session: 3135849742811878224  
  5. Range: npt=0.00000-70.00000  
  6. RTP-Info: url=rtsp://192.168.1.100/sample_100kbit.mp4/trackID=3;seq=54996;rtptime=310659698,url=rtsp://192.168.1.100/sample_100kbit.mp4/trackID=4;seq=6084;rtptime=702565368  

 

不含 Range 首部域的 PLAY 请求也是合法的。它从媒体流开头开始播放,直到媒体流被暂停。如果媒体流通过 PAUSE 暂停,媒体流传输将在暂停点重新开始。如果媒体流正在播放,那么这样一个 PLAY 请求将不起更多的作用,只是客户端可以用此来测试服务器是否存活。

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

对于一个点播媒体流，服务器用播放的实际范围答复请求。This may differ from the requested range if alignment of the requested range to valid frame boundaries is required for the media source.如果在请求中没有指定范围,当前位置将在答复中返回。答复中播放范围的单位与请求中相同。在播放完被要求的范围后,表示将自动暂停,就好像发出了一个 PAUSE 请求。

4、PAUSE

PAUSE 请求引起媒体流传输的暂时中断。如果请求 URL 中指定了具体的媒体流，那么只有该媒体流的播放和记录被暂停。比如，指定暂停音频,播放将会无声。如果请求 URL 指定了一个表示或者媒体流已成组,那么在该表示或组中的所有当前活动流的传输将被暂停。在重启播放或记录后,必须维护不同track的同步。尽管服务器可能在暂停后,在timeout 的时间内关闭会话,释放资源，但是任何资源都必须保存,其中 timeout 参数位于 SETUP 消息的Session Header中。

Session Header的格式如下所示：

Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]

下面代码示例创建了一个PAUSE请求。

 

[cpp] view plaincopy

 

 

  1. string msg;  
  2. msg.append("PAUSE ");  
  3. msg.append(mSessionURL);  
  4. msg.append(" RTSP/1.0\r\n");  
  5. msg.append("Session: ");  
  6. msg.append(mSessionID);  
  7. msg.append("\r\n");  
  8. msg.append("CSeq: ");  
  9. msg.append(CSeq);  
  10. msg.append("\r\n");  
  11. msg.append("\r\n");  

 

PAUSE 请求中可能包含一个 Range 首部域用来指定何时Stream或Presentation暂停，我们称这个时刻为暂停点。该首部域必须包含一个精确的值,而不是一个时间范围。媒体流的正常播放时间设置成暂停点。当服务器遇到在任何当前挂起的 PLAY 请求中指定的时间点后,暂停请求生效。如果 Range 首部域指定了一个时间超出了任何一个当前挂起的 PLAY 请求,将返回错误"457 InvalidRange" 。如果一个媒体单元(比如一个音频或视频禎)正好在一个暂停点开始，那么表示将不会被播放或记录。如果 Range 首部域缺失，那么在收到暂停消息后媒体流传输立即中断，并且暂停点设置成当前正常播放时间。

利用 PAUSE 请求可忽视所有排队的 PLAY 请求，但必须维护媒体流中的暂停点。不带 Range 首部域的后继 PLAY 请求从暂停点重启播放。比如，如果服务器有两个挂起的播放请求，播放范围分别是 10 到 15 和 20 到 29，这时收到一个暂停请求,暂停点是 NPT21,那么它将会开始播放第二个范围,并且在 NPT21 处停止。如果服务器正在服务第一个请求播放到 NPT13 位置，收到暂停请求,暂停点 NPT12，那么它将立即停止。如果请求在 NPT16 暂停，那么服务器在完成第一个播放请求后停止,放弃了第二个播放请求。再如，服务器收到播放请求，播放范围从 10 到 15 和 13 到 20(即之间有重叠)，PAUSE 暂停点是 NPT14，则当服务器播放第一段范围时,PAUSE 请求将生效,而第二个 PLAY 请求会被忽略重叠部分,就好像服务器在开始播放第二段前收到 PAUSE 请求。不管 PAUSE 请求何时到达,它总是设置 NPT 到 14。

如果服务器已经在 Range 首部域指定的时间外发送了数据，后继的 PLAY 仍会在暂停点及时重启，因为它认为客户端会丢弃在暂停点后收到的数据。这就确保了连续的、无隙的暂停/播放循环。

5、ANNOUNCE

ANNOUNCE 方法有两个用途:

（1）当客户端向服务器发送时，ANNOUNCE 将通过请求 URL 识别的表示描述或者媒体对象提交给服务器;

（2）当服务器相客户端发送时，ANNOUNCE 实时更新会话描述。

如果有新的媒体流加到表示中(比如在一个现场表示中)，整个表示描述应该重发；而不只是增加组件,如果这样做的话，组件也可以被删除了。

ANNOUNCE请求包括两个部分，一部分是RTSP标准请求内容，另一部分是按照SDP格式描述的内容。下面代码示例创建了一个从Client到Server的ANNOUNCE请求。

 

[cpp] view plaincopy

 

 

  1. string msg;  
  2. msg.append("ANNOUNCE ");  
  3. msg.append(mSessionURL);  
  4. msg.append(" RTSP/1.0\r\n");  
  5. msg.append("Session: ");  
  6. msg.append(mSessionID);  
  7. msg.append("\r\n");  
  8. msg.append("CSeq: ");  
  9. msg.append(CSeq);  
  10. msg.append("\r\n");  
  11. msg.append("Content-Type: application/sdp\r\n");  
  12. msg.append("Content-Length: ");  
  13. msg.append(SDPSize);  
  14. msg.append("\r\n");  
  15. msg.append("\r\n");  
  16. msg.append(SDPContent);  
  17. msg.append("\r\n");  
  18. msg.append("\r\n");  

 

其中，SDPContent是按照SDP格式描述的一段内容，SDPSize是SDPContent的内容的大小。一个简单的SDPContent如下所示：

 

[plain] view plaincopy

 

 

  1. v=0  
  2. o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4  
  3. s=SDP Seminar  
  4. i=A Seminar on the session description protocol  
  5. u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps  
  6. e=mjh@isi.edu (Mark Handley)  
  7. c=IN IP4 224.2.17.12/127  
  8. t=2873397496 2873404696  
  9. a=recvonly  
  10. m=audio 3456 RTP/AVP 0  
  11. m=video 2232 RTP/AVP 31  

 

6、OPTIONS

7、RECORD

8、GER_PARAMETER

9、SER_PARAMETER

10、REDIRECT

11、TEARDOWN

TEARDOWN 请求终止了给定 URI 的媒体流传输，并释放了与该媒体流相关的资源。如果该 URI 是对此Presentation的Presentation URI，那么任何与此会话相关的任何 RTSP 会话标志符将不再有效。除非所有传输参数由会话描述符定义，否则 SETUP 请求必须在会话能被再次播放之前发出。

下面代码示例创建了一个TEARDOWN请求。

 

[cpp] view plaincopy

 

 

    1. string msg;  
    2. msg.append("TEARDOWN ");  
    3. msg.append(mSessionURL);  
    4. msg.append(" RTSP/1.0\r\n");  
    5. msg.append("Session: ");  
    6. msg.append(mSessionID);  
    7. msg.append("\r\n");  
    8. msg.append("CSeq: ");  
    9. msg.append(CSeq);  
    10. msg.append("\r\n");  
    11. msg.append("\r\n");  
时间： 2024-09-23 17:00:28

RTSP传输协议之Methods总结的相关文章

超文本传输协议 -- HTTP/1.0 Hyptertext Transfer Protocol

组织:中国互动出版网(http://www.china-pub.com/)RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm)E-mail:ouyang@china-pub.com译者:黄晓东(黄晓东  xdhuang@eyou.com)译文发布时间:2001-7-14版权:本中文翻译文档版权归中国互动出版网所有.可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息.   Network Working G

FTP文件传输协议两种方式的工作原理

FTP是一种文件传输协议,它支持两种模式,一种方式叫做Standard (也就是 Active,主动方式),一种是 Passive (也就是PASV,被动方式). Standard模式 FTP的客户端发送 PORT 命令到FTP server.Passive模式FTP的客户端发送 PASV命令到 FTP Server. 下面介绍一个这两种方式的工作原理: Standard模式 FTP 客户端首先和FTP Server的TCP 21端口建立连接,通过这个通道发送命令,客户端需要接收数据的时候在这个

简单邮件传输协议SMTP封装类

在Internet上,Email是最流行的传输媒体.这篇文章包括两个协议:. POP 3 协议: POP3协议(邮政传输协议)就是指从Email服务器接收信件.我已经提交了一个封装POP3协议的类.该协议官方的描述你可查阅RFC1225. SMTP协议: SMTP (简单邮件传输协议) 指发送邮件到它的目的地. 有关SMTP 协议的细节你可参考RCF 821 .我最新地贡献是封装了SMTP协议.我不能完全实现 SMTP协议但你可用它在许多应用场合发送邮件.该类有若干方法,我选方法名同SMTP命令

SMTP简单邮件传输协议

SMTP:简单邮件传输协议(Simple Mail Transfer Protocol) SMTP 是一种提供可靠且有效电子邮件传输的协议. SMTP 是建模在 FTP 文件传输服务上的一种邮件服务,主要用于传输系统之间的邮件信息并提供来信有关的通知. SMTP 独立于特定的传输子系统,且只需要可靠有序的数据流信道支持. SMTP 重要特性之一是其能跨越网络传输邮件,即"SMTP 邮件中继".通常,一个网络可以由公用互联网上 TCP 可相互访问的主机.防火墙分隔的 TCP/IP 网络上

浅析FreeBSD超文本传输协议HTTP

由于能够提供图形.声音等多媒体数据,WWW已经成为Internet使用者最喜爱的访问方式,当前的大部分 Internet流量均是由WWW浏览产生的.由于这种多媒体浏览方式的帮助,Internet不再仅仅是由专业人员使用,对计算机了解不多的普通使用者也能进入Internet的世界,享受Internet带来的新鲜内容. 虽然WWW服务非常之流行,然而要建立一个WWW服务器以提供WWW服务却仍然属于专业领域的任务.当前能够提供WWW服务的软件有很多种,分别运行在不同的操作系统之上,其中有一些软件能够运

FTP文件传输协议

文件传输协议(FTP:File Transfer Protocol)使得主机间可以共享文件. FTP 使用 TCP 生成一个虚拟连接用于控制信息,然后再生成一个单独的 TCP 连接用于数据传输.控制连接使用类似 TELNET 协议在主机间交换命令和消息. FTP 的主要功能如下: 提供文件的共享(计算机程序 / 数据): 支持间接使用远程计算机: 使用户不因各类主机文件存储器系统的差异而受影响: 可靠且有效的传输数据. FTP ,尽管可以直接被终端用户使用,但其应用主要还是通过程序实现. FTP

本地邮件传输协议：SMTP和LMTP

SMTP需要管理一个队列,一个邮件操作可以把一封邮件发送向不同的接收者,而一个SMTP命令却只有一个返回码,这就带来的问题,如果服务器需要把一个邮件发向两个接收者,发送第一个的时候成功了,而发送第二个时候暂时失败了,服务器必须把这封邮件放入队列,以后再发送,而发送方却不可能知道这一切.SMTP的这种队列机制在最初设计时是为了考虑到转发的需要,但在有些时候,并不需要 服务器管理这个队列,而需要由客户进行队列的管理,我们看一下下面这个例子:上图中有三个独立的通信系统,三个方框内的就是,第一个是 队列

应用-有名的开源的“可靠UDP传输协议”有哪些，怎么选择？

问题描述 有名的开源的"可靠UDP传输协议"有哪些,怎么选择? 有名的开源的"可靠UDP传输协议"有哪些,怎么选择? 问题背景: 1.两台主机只能单向传输,即A只能到B,这是在硬件层面上的限制,所以没有丢包等反馈 2.因为要应用到实际生产环境中,所以要求传输速率蛮,要达到千兆 3.丢包率得要在0.1%的级别 4.是开源的项目,源码拿过来就能够直接部署应用,所以需要的是能直接解决问题的东西,而不是解决问题的想法和理论 在网上找了找 很多人推荐UDT,不知道大家有没有其

WCF如何克服HTTP传输协议的局限提供对不同消息传输模式的实现

WCF采用消息作为通信的唯一手段,它支持不同的消息交换模式(MEP:Message Exchange Pattern),比较典型的有以下三种MEP:One-Way.Request/Reply和Duplex.消息会被WCF的信道层发送到传输层,并通过相应的传输协议发送到目的地.对于TCP协议来说,其本身就能提供一个双工通道,所以能够对以上三种MEP原生的支持.而HTTP协议,大家都知道它天生就基于Request/Reply模式的,那么它是如何能够突破自己的局限,为One-Way和Duplex消息交