不象HTTP,RTSP允许媒体服务器给媒体用户发送请求。然而,这仅在持久连接时才支持,否则媒体服务器没有可靠途径到达用户,这也是请求通过防火墙从媒体服务器传到用户的唯一途径。

9.1 流水线操作
  支持持久连接或无连接的客户端可能给其请求排队。服务器必须以收到请求的同样顺序发出回应。
9.2 可靠性及确认
如果请求不是发送给组播组,接收者就确认请求,如没有确认信息,发送者可在超过一个来回时间(RTT)后重发同一信息。 RTT在TCP中估计,初始值为500 ms。应用缓存最后所测量的RTT,作为将来连接的初始值。
如使用一个可靠传输协议传输RTSP,请求不允许重发,RTSP应用反过来依赖低层传输提供可靠性。
如两个低层可靠传输(如TCP 和RTSP)应用重发请求,有可能每个包损失导致两次重传。由于传输栈在第一次尝试到达接收着者前不会发送应用层重传,接收者也不能充分利用应用层重传。如包损失由阻塞引起,不同层的重发将使阻塞进一步恶化。
时标头用来避免重发模糊性问题,避免对圆锥算法的依赖。
每个请求在CSeq头中携带一个系列号,每发送一个不同请求,它就加一。如由于没有确认而重发请求,请求必须携带初始系列号。
  实现RTSP的系统必须支持通过TCP传输RTSP ,并支持UDP。对UDP和TCP,RTSP服务器的缺省端口都是554。许多目的一致的RTSP包被打包成单个低层PDU或TCP流。RTSP数据可与RTP和RTCP包交叉。不象HTTP,RTSP信息必须包含一个内容长度头,无论信息何时包含负载。否则,RTSP包以空行结束,后跟最后一个信息头。



RFC2326(中文版)-实时流协议(RTSP)文章来自:
RFC2326(中文版)-实时流协议(RTSP)引用通告地址: http://www.dzend.com/trackback.asp?tbID=71

相关文章:

  • 2021-12-26
  • 2022-12-23
猜你喜欢
  • 2022-12-23
  • 2022-01-15
  • 2021-09-21
  • 2021-12-22
  • 2021-12-19
  • 2021-10-03
  • 2021-12-15
相关资源
相似解决方案