大虾们！rtcp协议怎么实现丢包重发！？？？？

[lazyter1]

看了一下rtp/RTCP 协议，发现RTCP 的报文中仅仅有丢包率这样的概念，但好像客户端并没有将所有丢失的包的序列号或时间戳发给服务器要求重发，所以想问问大虾们：

1. rtcp到底怎样实现丢包补发的？

2. rtcp如果有重发（补发）的机制，那么是根据序列号重发还是时间戳？大虾请详细讲讲。

3. 另外，由于rtp 的序列号仅仅2个字节（最高65536帧），经过对live 555开源rtsp服务器打印序列号log，
发现序列号是循环复用的。那么对于大文件或直播不断增长的缓存文件，服务器再接受到客户端丢失包
的序列号后，如何根据序列号在文件中找到相应的帧，重发？


补充：问题产生的缘由，假设某个点播文件比较大，并超过65536帧，那么rtsp服务器再发送第65536帧后，
以后的帧的序列号会由1重新开始。那么如果这个时候客户端发送的报告中说帧为1的数据丢失了，那么
这时候服务器如果根据序列号的话，把文件开始的第一帧发送出去就会出错。因为实际应该是65537帧丢失了。
所以，rtp/rtcp如何解决序列号2个字节不够用的问题的？


以上任何文件答对都给分。

[红街咖啡]

http://blog.csdn.net/ly_zsf/archive/2008/02/26/2123445.aspx

[rotus]

问题产生的缘由，
假设某个点播文件比较大，并超过65536帧，那么rtsp服务器再发送第65536帧后，
以后的帧的序列号会由1重新开始。那么如果这个时候客户端发送的报告中说帧为1的数据丢失了，那么
这时候服务器如果根据序列号的话，把文件开始的第一帧发送出去就会出错。

LZ这样的问题是实际遇到的，还是假设？

如果65536帧 才告诉第1帧丢了，中间要隔多少时间啊，所以不会发生这样的情况吧。也就是说，要丢包，也是短时间内丢，然后重发，所以65536应该够用了。。。

再翻翻标准吧，如果真有LZ说的这种问题，我想标准也应该会提到。。

[loveneo421]

可怜我抓包过程中一直没有抓到rtcp包

[lazyter1]

经过几天的研究做个总结吧，如有错误，希望网友指正。当然之前首先感谢前面的几个网友的参与。

1. rtp ，rtcp 可以通过UDP 实现，也可以通过TCP实现。

2. UDP实现的rtp rtcp，客户端通过rtcp反馈给服务器的一般只是丢包率，
然后服务器根据这个参数 调整发送速率。不会补包。但有的公司和大拿 也会扩展RTCP既有功能以实现
丢包补发，但这里面的算法要做到恰到好处，因为太复杂了，不如用tcp实现rtp，rtcp，而且RTP往往
用于实时性高的系统，如：直播，所以往往为了实时性，往往能够接受个别丢包现象。

3. 另外，如果用tcp实现，就不需要考虑丢包，乱序等问题了。


4. 至于序列号不够用的问题，我是这样想的，如果用RTP,RTCP OVER TCP ,那么tcp的机制是自然保证
数据的有序性的，可靠性的。所以也就不用考虑序列号不够用的问题了，试图通过序列号排序的问题也
就没有了；而对于UDP实现的RTP,RTCP,因为默认没有补包机制，所以，试图想通过序列号来要求服务
器重发帧的时候，恰好出现出现序列号被服务器循环复用，导致二义性的问题，也同样不存在了。

[lazyter1]

给个链接，关于个别公司实现rtcp 提供丢包补发的机制的。

http://www.h3c.com.cn/Products___Technology/Products/IP_Multimedia/Home/Media_Information/Tec_Hot/200801/331008_30003_0.htm