RFC2326(中文版)(18)

RFC2326(中文版)

可能给其请求排队。服务器必须以收到请求的同样顺序发出回应。
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包以空行结束，后跟最后一个信息头。




现在已经知道的一些信息:

1.RTSP协议实际上只是一个控制协议，实际数据还需要一个传输协议。不过RTSP也支持在同一个TCP 连接中传输数据.

2.Xine[3]有一个librtsp的库，Mplayer也是Port的这个部分.我已经把Mplayer的这个部分的代码剥离出来，已经可以单独编译了。

3.LiveMedia是一个功能比较完整的RTSP/RTP Library. 不过居然不支持RealAudio/RealVedio.

4.我真正关心的RealAudio/RealVedio Stream, 居然不是用RTP 协议传输的，是个什么RDT的Real自己的非标准协议. Mplayer/Xine的代码应该都支持这个协议.

5.RTSPget[1]是一个基于Xine code base的RTSP流下载工具，目前还不知道是不是好用.

6.A simplified RTSP cilent[4]是一个非常不错的入门资料， 比较容易在直观感性上建立对RTSP协议的概念。

7.Python这个方面的库和实现好像都比较稀少，有一个叫shtoom[6]的Project 是一个基于Python的VoIP实现。

8.实践证明4.这个消息是比较过时的。现在的RTSP流基本上都是标准的RTP 协议了。因此重新回头，实现一个基于LiveMedia的RTSPGet. 看看是否可以直接从MPlayer中剥离代码

Useful URL and reference
1/RTSPget
lab.ox.ac.uk/
ian.collier/Misc/rtspget/
2/librtsp
http://doc.gua
ndang.net/
/
viewcvs.py/rtsp/librtsp/
3/xine
/
4/A simplified RTSP client
http://folk.uio.no