一、IPTV系统中的CDN流媒体系统要求

       IPTV业务经过将近20年的发展，用户已经超过4亿，其已经和传统有线电视、OTT互联网视频等深度融合，互相渗透，互相影响。IPTV本身作为IP网络基础之上的IP专网视频业务，为了更好的兼容传统有线电视业务，在IP网络之上采用了TS流格式的封装媒体流。如下图所示：

       业务音视频媒体流，包括MPEG4或者H264、H.265等编码格式数据，首先经过TS系统流的封装之后，再使用IP网络进行传输。从上图可以看出，TS 流本身也可以直接经过UDP 或者TCP 的方式传输，无需再次进行RTP封装，而且TS本身也有音视频合成，以及同步机制等。但是TS流本身是为广播传输系统设计的，为单向传输服务，没有考虑到IP网络本身的特性，无法进行丢包重传，也未考虑快进快退等问题，为了更好的解决这些问题，在IPTV系统内TS流之上，一般采用RTP机制进行传输。
      但是我们可以看到原有的标准RTP传输机制在IPTV中，只是解决点到点，或者点到多点的媒体传输和服务，它只负责解决CDN流媒体服务器或者网络设备直接到终端传输的最后这一个服务环节。而 IPTV 要在IP 网络基础上提供大容量、高并发的服务，并保证较好的QoS，为用户提供良好的观看体验，保证良好的音视频质量，仅仅依靠这些机制是不够的。它还需要一个有效的后台服务体系，该体系负责从节目的源头开始，对节目进行各种处理和分发，或者录制，并且保证处理、分发和录制的及时性、有效性，并能适应IP 网络条件将节目数据分发到不同的地域，分发到距离用户最近的服务器为用户提供服务，还能应付各种突发事件，某些情况下，能够从不同地域重新组合节目数据，保证节目完整性。

       如上图所示，在实际部署的IPTV CDN服务系统中，传统RTP传输机制只能解决图中绿线所示部分的传输问题，而对于更加复杂，更加重要的内容传输和分发没有考虑，如上图黄色部分所示。为此采用了RTP协议扩展的方式，为IPTV系统中CDN的工作机制提供基础，力求不同的厂商系统之间的媒体流数据可以达到互通，互相使用的目的。

二、RTP格式要求

遵循RFC3550的规定，以RFC3550为基础进行扩展。按照RFC规定，RTP包头可以分为两部分，第一部分是固定格式部分，第二部分是扩展部分。

2.1 RTP固定格式部分

RTP包头固定格式部分如下图所示：

该格式严格遵循RFC3550 的规定，以下为各个字段的意义和要求：

2.2 RTP扩展部分

按照RFC3550 规定的方法扩展了RTP 包头，具体扩展格式如下图所示：

以下为各个字段的意义和要求：

字段说明

为符合实际业务运营需要，针对现有的 IPTV 业务中对于RTP 包头扩展部分的部分字段进行详细说明如下：

• version (V)
  在中国电信IPTV4.0规范中，单独为扩展格式部分设定了版本号，目的是为了和RTP 格式版本相分离。在这两个版本之间并没有必然的联系，有可能RTP 版本未变的情况，该扩展格式版本号升级到10，或者其他。也有可能RTP 版本号升级了，但是本扩展格式版本号，继续使用01。在具体实现时，各处理单元要对该版本号进行验证，以便判断是否支持，本扩展协议的后续版本，格式可能并不一致。
• frame_type(FT)：

  取值	定义
  0	I帧
  1	P帧
  2	B帧
  3	预留

  
  在 IPTV 中，RTP 负荷中包含的是TS 流数据，而且一个RTP 包含了多个TS 包，因此可能存在一个情况，就是一个RTP 包包含的多个TS 包中，有一部分是I 帧的，一部分可能是B 帧的。这种情况下，上述机制就不能正常工作。因此规定，在使用RTP 包进行传输时，一个RTP 包中包含的数据，只能属于一个帧，不能包含两个帧的数据。这样以来，一个帧可能会分成多个RTP 包，而一个RTP 中不可能含有多个帧的数据。如果一个RTP包含的数据到了帧尾，只剩下少数数据，那么该RTP 包大小可以小于正常的大小值。

• frame_pos(FP)

  取值	定义
  0	开始
  1	中间
  2	结尾
  3	开始和结尾（完整）

  如上所述，一个RTP 包只能包含一个帧的数据，但是一个帧可能会分为多个RTP包，因此这里用FP 来表示当前的RTP 中的数据是当前帧的开始，还是结束，或者是中间，还是头尾都包含。
• segment_pos(SP)

       该值取值范围和意义如下，关于存储片段的描述，请参见segment_id 相关介绍：

• segment_id

         在 IPTV 业务系统中，流媒体数据不仅要发送到终端，为终端提供音视频数据流服务，也需在后台要进行录制，保存和分发，或者重新组织。那么在进行存储和分发的时候，总是需要以一段数据为单位进行组织，在这里，定义了一个单位—存储片段，把它作为流媒体能力分发和存储的最小单位。这意味者，流媒体能力的分发和存储最小只能存储和分发这样的一个单位，不能再进行更小的划分。

       一个存储片段对应一个节目流中的某一时间段的全部数据，互相相邻的两个时间段，存储片段标识的差为1，也就是N，N＋1。而且两段相邻的数据不能有重复，不能缺少部分流数据。

       在 IPTV 媒体分发网络中进行分发和录制时，建议整个网络中的流媒体数据采用一致的segment_id 标识，也就是说，在整个网络范围内，要保证所有节点，所有服务器，对于同一个节目的相同时间的存储片段，他们的标识都是相同的，数据也要相同。   

           要实现以上目的，最好在节目源头，或者节目进入IPTV 媒体分发网络的开始就对流媒体数据进行分片处理，打上segment_id 标识，保证全网存储片段 标识和数据的一致性。在进行分片处理时，可以设置一定的时间间隔，过了这个时间，就生成一个新的片段，标识的值加1。同时，为了方便处理，每个片段的都以I 帧数据开始，完整帧结尾。
           各个节点对存储片段进行处理时，要保证数据的完整性和一致性，不能随意更改存储片段标识，当数据不完整时，必须进行适当处理。数据的完整性可以依靠segment_pos 进行判断和处理。

• segment_offset

       该字段主要是为了保证在进行节目录制时，如果出现了丢包，服务器仍然可以正常进行录制。如下所述：
      在 IP 网络中传输数据，经常出现丢包，或者顺序不一致，有可能先发的RTP 包后到，或者中间发送的一个RTP包出现了丢失，重传还没有完成，但是后续的RTP包已经达到了，在这种情况，后来的RTP 数据也需要进行保存。这个时候，就需要为中间丢失的那些数据保留一定的磁盘空间，而segment_offset 就指出了保留的位置。
      该 segment_offset 值包含了RTP 包头和TS 流数据中的媒体数据大小，如果在录制时，不保存RTP 包头，要进行换算才能得出实际的存储偏移量。

• sreserve field

       该字段主要是为了适应当前 IPTV 发展的实际情况，预留给厂商自己使用，不同的厂商可以自己定义这些字段，但前提是要保证遵循上述的所有规定，同时不同厂商之间的设备和系统将忽略该字段。

• 其他说明

      重传机制：采用RTP 协议作为基础，因此如果需要重传，就可以以RTP 的序列号作为标识进行重传。

      存储机制：采用存储片段作为分发和存储的最小片段，只是一个逻辑上的区分，并不限制存储机制本身，一个片段本身不和任何实际存储单位关联，比如文件，分区等。