diff --git "a/RTP_RTCP/RTP\347\272\240\351\224\231\346\234\272\345\210\266--\347\262\276\351\200\211\350\207\252\350\257\221.md" "b/RTP_RTCP/RTP\347\272\240\351\224\231\346\234\272\345\210\266--\347\262\276\351\200\211\350\207\252\350\257\221.md" index 11e4c64..9bfb36c 100644 --- "a/RTP_RTCP/RTP\347\272\240\351\224\231\346\234\272\345\210\266--\347\262\276\351\200\211\350\207\252\350\257\221.md" +++ "b/RTP_RTCP/RTP\347\272\240\351\224\231\346\234\272\345\210\266--\347\262\276\351\200\211\350\207\252\350\257\221.md" @@ -1,6 +1,6 @@ # 9. 纠错机制 ## 9.1 前向纠错(FEC) -  前向纠错(FEC)算法能让二进制流在传输过程中保持健壮性。传送大量二进制流在松散的媒介或网络下。额外的信息会加在二进制流中，能让接受者正确的重构在传输中丢失的数据。前向就戳算法主要应用在广域网，如手机网络、或包交换网络、或存储系统(如压缩盘、电脑硬盘或内存)。因为因特网是一个松散的媒介，因为媒体应用的信息对丢失非常敏感，FEC方案就被提议和编程RTP应用的标准。FEC方案能完成解压，和准确重构二进制流，取决FEC类型、应用数量，和丢失的方式。
+  前向纠错(FEC)算法能让二进制流在传输过程中保持健壮性。传送大量二进制流在松散的媒介或网络下。额外的信息会加在二进制流中，能让接受者正确的重构在传输中丢失的数据。前向就戳算法主要应用在广域网，如手机网络、或包交换网络、或存储系统(如压缩盘、电脑硬盘或内存)。因为因特网是一个松散的媒介，因为媒体应用的信息对丢失非常敏感，FEC方案就被提议和编程RTP应用的标准。FEC方案能完成解压，和准确重构二进制流，取决FEC类型、应用数量，和丢失的方式。
  当RTP应用FEC，就必须设计一下加入多少个FEC报文，取决于网络丢失数据的大小。一个方法就是，用RTCP RR报文中的loss fraction(丢失率)来决定加入多少FEC数据到媒体流中。
  理论上，通过改变媒体编码，是有可能确保一定丢失率下的纠错。但实际上，很多情况都表明，FEC只提供可能性的修复。关键点在于FEC报文的加入也增加了带宽消耗。带宽增加局限了FEC加入到有容量限制网络的总数，如果是因为网络拥塞造成丢包，FEC有可能造成更坏的影响。因为，带宽消耗增加会加重网络拥塞。这个会在本章后面的章节讨论。
  注意虽然FEC的数量根据接收者质量报告而变化，对报文丢失并不发送反馈，并且也不能保证所有的丢失报文都能修复。目的是让丢失率降低到能接受的丢失率，然后让错误隐藏解决剩下的错误率。
@@ -56,7 +56,7 @@ A XOR B OXR B = A ## 9.3 纠错重传   如果接受者向发送者发送消息，索要丢失的报文，丢失的报文就能避免。对于纠错机制来说，重传是常规的方法，它能在各种场景中应用。当然重传也有其应用的局限性。重传并不是RTP标准协议的一部分；但是，RTP配套的文档也在发展中，它应用基于RTCP的框架来发送重传请求和其他的即时反馈机制。
### 9.3.1 RTCP的重传机制 -  因为RTP包括了基于RTCP通道的反馈机制，如RR和其他的数据，很子软的也就用RTCP通道来进行重传请求。需要两部分:
+  因为RTP包括了基于RTCP通道的反馈机制，如RR和其他的数据，很自然的也就用RTCP通道来进行重传请求。需要两部分:
+ RTCP重传请求报文格式定义 + 允许立即反馈的时间准则 ### 9.3.2 RTCP重传请求格式 @@ -65,7 +65,7 @@ A XOR B OXR B = A + 丢包反馈: 最常用的是丢包反馈，向发送者报告一组丢失的报文
  丢包反馈格式(negative acknowledgment，今后简称NACK)，在图9.11中显示。NACK包含一个packeg identifier，其标识一个丢失的报文，其后面的字段bitmap of lost packets标识该报文后面16个报文哪几个丢失了，1代表丢失，0表示收到。即使收到NACK报文中bitmap字段中有0，发送者也不应该假想接受者已经收到该报文；只能确认到接受者当前并没有上报该RTP报文丢失。当接收到一个NACK，发送者应该重传NACK中标识丢失的RTP报文，虽然协议中没有强制这么做。
![RTCP_NACK](https://github.com/runner365/read_book/blob/master/RTP_RTCP/pic/RTCP_NACK.png)
-  ACK格式如图9.12所示。ACK报文包含RTP sequnece，其代表已经收到的RTP报恩，和bitmap或后面的报文个数。如果R设置1，表示后面的报文个数，如果R设置0，表示bitmap后面15个具体哪几个已经也收到了。这两个选择允许ACK针对少量丢失(R=1)，和ACK分散的丢失(R=0)。
+  ACK格式如图9.12所示。ACK报文包含RTP sequnece，其代表已经收到的RTP报文，和bitmap或后面的报文个数。如果R设置1，表示后面的报文个数，如果R设置0，表示bitmap后面15个具体哪几个已经也收到了。这两个选择允许ACK针对少量丢失(R=1)，和ACK分散的丢失(R=0)。
![RTCP_ACK](https://github.com/runner365/read_book/blob/master/RTP_RTCP/pic/RTCP_ACK.png)
  ACK和NACK用哪一个取决于具体修复算法和期望的机制。ACK表示部分报文收到了;发送者认为其他的丢失了。相反，NACK表示部分报文丢失了，而其他的报文也许收到，也许没收到(比如，当某个重要报文丢失需要重传，接受者针对这个报文发送NACK，但忽略其他不重要的报文信息)。
-  这样的反馈报文的发送也是作为RTCP组合报文的一部分，同其他的RTCP报文一样。反馈报文放在组合报文的最后，如在SR/RR和SDES后面。(见第五章，RTCP，具体RTCP格式介绍)
\ No newline at end of file +  这样的反馈报文的发送也是作为RTCP组合报文的一部分，同其他的RTCP报文一样。反馈报文放在组合报文的最后，如在SR/RR和SDES后面。(见第五章，RTCP，具体RTCP格式介绍)