流的缓存

这个版本的QTSS中包含一些RTSP和RTP特性，使缓存代理服务器易于捕捉和管理一个流的原始拷贝。其中的一部分特性是先前版本的QTSS没有支持的RTSP元素，另外一些部分则是对RTSP和RTP的增强，具体如下：

• Speed RTSP报头。 这个版本的QTSS在任何可能的地方都支持Speed报头。这使得缓存代理服务器可以请求以比实际时间流动更快的速度分发流数据，从而将流数据尽可能快地转移到缓存代理服务器的缓冲区中。这个报头在“Speed RTSP报头”部分中进行描述。
• x-Transport-Options RTSP报头。这个版本的QTSS支持一个非标准的RTSP包头，即x-Transport-Options。缓存代理服务器可以通过这个报头告诉流媒体服务器在数据包延迟到什么程度时，流媒体服务器还可以发送数据，并使这些数据包仍然可用于缓存代理服务器。这个报头在“x-Transport-Options报头”部分中进行描述。
• RTP净负荷元信息（payload meta-information）。这个版本的QTSS 完全支持RTP净负荷元信息（一个IETF草案），包括数据包传输时间，唯一的数据包编号，以及视频帧类型等。缓存代理服务器可以使用这些信息来向客户端提供与原始服务器同样质量的服务。这个报头在“RTP净负荷元信息”部分中进行描述。
• x-Packet-Range RTSP报头。这个版本的QTSS支持一个非标准的RTSP包头，即x-Packet-Range。这个报头和Range RTSP报头相类似，但是允许客户端指定一个具体范围的数据包，而不是一个时间范围。缓存代理服务器可以通过x-Packet-Range报头告诉原始的服务器有选择地重新传输那些缓存代理服务器需要的数据包，目的是填充流的缓存拷贝中的某些空洞。这个报头在“x-Packet-Range RTSP报头”部分中进行描述。

下面部分的内容将对上面这些特性加以描述。

Speed RTSP报头

客户可以向服务器发送可选的Speed RTSP报头，请求服务器以特定的速度向客户端发送数据。服务器必须向客户端回弹一个Speed RTSP报头作为回应。如果服务器没有弹回Speed RTSP报头，则客户端必须认为服务器目前不能兼容这种请求。服务器可能会修改Speed RTSP报头的参数值。如果服务器对参数值进行修改，则客户端必须接受修改后的值。

Speed RTSP报头参数的值表达为一个十进制的率。下面的例子请求服务器以两倍于正常情况的速度发送数据：

Speed: 2.0 

请注意： 参数的值不能为零。

如果请求中也包含Range参数，则新的速度值将在指定的时间中生效。

这个报头的设计目的是希望在需要以更高或者更低数据率对流的内容进行预览时使用。会话的带宽可能已经在早些时候协商完成了（通过RTSP以外的方法），因此可能有必要重新协商。

当数据通过UDP进行分发时，我们强烈推荐使用诸如RTCP这样的手段来进行丢包率的跟踪。

x-Transport-Options报头

x-Transport-Options这个RTSP报头是可选的，应该在客户端（通常是一个缓存代理服务器）给服务器端的RTSP SETUP请求中发送，并且必须由服务器弹回。如果服务器没有弹回x-Transport-Options报头，则客户端必须假定服务器不支持这个报头。服务器可能会修改x-Transport-Options报头的参数值。如果服务器修改了参数值，则客户必须接受这个修改后的值。

这个报头的数据体中包含一个或者多个参数，不同的参数之间由分号分隔。对于这个版本的QTSS，只有一个参数，即late-tolerance参数。

late-tolerance参数的值为正数表示数据包的延迟秒数，在这个时间内服务器仍然可以发送媒体数据包，并使这些数据包仍然可以用于客户端。服务器应该以late-tolerance参数的值来作为指导，在分送媒体时尽最大的努力去尝试，使分发的数据不迟于late-tolerance参数指定的值。

下面是一个实例：

x-Transport-Options: late-tolerance=30 

如果这个例子用于视频流，则服务器会发送所有延迟小于30秒的视频帧，而将延迟超过30秒的帧丢弃，因为它们已经失效了。

RTP净负荷元信息

某些特定的RTP客户，比如缓存代理服务器，需要每个数据包的元信息，这些都是RTP报头所提供的数据包序列号和时间戳之外的信息。举例来说，缓存代理服务器可能希望向那些带宽受限的客户提供打薄后的流。如果流的打薄是基于原始服务器发送的视频帧类型进行的，则缓存代理服务器将不可能使用与净负荷无关的方法来确定帧的类型。

RTP净负荷元信息的报头通过包含一些信息来解决这个效率低下的问题。RTP客户可以使用这些信息来向客户提供品质和原始服务器相同品质的服务。本文接下来的部分，即“RTP数据”，将描述服务器在RTP净负荷元信息报头中发送的RTP数据。

RTP数据

服务器通过RTP净负荷元信息类型的报头来向RTP客户提供下面信息：

• 传输时间，在“传输时间”部分中加以描述。
• 帧类型，在“帧类型”部分中加以描述。
• 包编号，在“包编号”部分中加以描述。
• 包位置，在“包位置”部分中加以描述。
• 媒体数据，在“媒体数据”部分中加以描述。
• 序列号，在“序列号”部分中加以描述。

传输时间

服务器会以一个发送four-octet的无符号整形数形式发送一个传输时间，表示RTP数据包推荐的传输时间，以毫秒计。

传输时间总是以媒体表示的起始时间为起点的时间偏移量。举例来说，如果提供URL的SDP响应中包含的范围为0-729.45，而客户端发出一个范围为100-729.45的PLAY请求，则从服务器发出的第一个RTP数据包应该提供一个值约为100,000的传输时间（这个值可能不一定正好是100,000，因为服务器可以自由地在请求的时间点附件找到一帧。如果提供URL的SDP并不包含一个范围，则客户端至少可以使用这些值来作为相对偏移量。

帧类型

服务器将帧类型信息作为一个16位的无符号整形数进行发送，这个整形数定义了几个众所周知的值，代表不同的帧类型。这些周知值定义如下：

• 0 代表未知的帧类型
• 1 代表关键帧
• 2 代表b帧
• 3 代表p帧

请注意：帧类型的定义仅对视频RTP流有效

数据包的编号

服务器将数据包的编号作为一个64位的无符号整形数进行发送。数据包编号的值是相对于流的绝对起始点的数据包偏移量，举例来说，如果传送URL的SDP响应中含有一个0-729.45的范围信息，而且客户端也发出一个带有0-729.45范围信息的PLAY请求，则第一个数据包的编号就应该是0，并且接下来的每个数据包的编号都逐一递增。如果流的前60秒数据中有1000个数据包，而客户端发出的PLAY请求的请求播放范围为60-729.45，则第一个包的编号将是1001，而接下来的数据包的编号逐一递加。

数据包的位置

服务器将数据包的位置作为一个64位的无符号整形数进行发送，它的值是当前数据包相对于流的绝对起始位置的字节偏移量。举例来说，如果传送URL的SDP响应中含有一个0-729.45的范围信息，而且客户端也发出一个带有100-729.45范围信息的PLAY请求，则第一个视频RTP数据包的包位置值将是从0到100的RTP数据包中包含的字节总数。只有RTP数据包中的净负荷（即数据包中包含的媒体样本）的字节数才用于计算每个数据包的位置值。

服务器不能为直播流或者动态媒体提供包的位置信息。通常情况下，如果媒体SDP有范围属性，服务器就能提供数据包的位置信息。

媒体数据

服务器为隐含的RTP协议发送媒体数据。

序列号

服务器将RTP序列号作为一个two-octet值进行发送。序列号用于将RTP元信息映射到它们引用的有效负荷数据上，如果这些数据被发送为带外数据的话。

标准格式

由服务器返回的RTP有效负荷的元信息是有一系列的域组成的，每个域则由报头和数据两部分组成。如果数据以标准格式返回，则报头的第一位应该为0，表示该域是标准格式（也就是说是无压缩的）。

紧跟着第一个数据位的是由15个数据位构成的Name子域。Name子域包含两个ASCII字母或数字字符，表示某个“RTP数据”部分列出RTP数据类型。第一个字符有七个数据位长，因此Name子域的值必须包含七个数据位的ASCII字符。

表2-26列出每个RTP数据类型的Name子域的值。

Name子域后面紧跟的是一个two-octet的Length子域，该域中含有Data子域的总长度信息。

图 2-9显示的是Name子域的标准格式。

图 2-10显示的是RTP数据的标准格式。

压缩格式

如果服务器提供的RTP元信息域是压缩格式的，则该域由报头和数据组成。报头的第一个数据位设置为１，表示报头的其它部分是压缩格式的。

紧接在第一个数据位之后的是七个数据位长的ID子域，表示的是Data子域中数据的类型。如“x-RTP-Meta-Info RTSP报头协商”部分描述的那样，ID子域的意义是由服务器分配的。

ID子域后面跟的是one-octet的Length子域，包含紧接其后的Data子域的总长度信息。

图 2-11显示的是ID子域的压缩格式。

图 2-12显示的当某些域是压缩格式，另外一些域是标准格式时的RTP有效负荷元信息数据包。

协商使用压缩格式

压缩格式的使用需要在客户和服务器之间进行带外协商。在这个协商过程中，服务器会给每个RTP数据类型分配一个七个数据位的ID。在RTP的有效负荷中，并不发送RTP数据类型的名称（比如，ft），而只是发送ID。

对使用压缩格式的协商可能有两种方式：

• 通过x-RTP-Meta-Info这个RTSP报头进行，如“x-RTP-Meta-Info RTSP报头协商”部分所述。
• 通过数据的SDP描述进行，如“在SDP中描述RTP-Meta-Info有效负荷”部分所述。

x-RTP-Meta-Info RTSP 报头协商

通过在SETUP请求中向服务器发送x-RTP-Meta-Info RTSP报头，客户端可以和服务器就任何有效负荷的压缩进行协商。如果服务器没有在其SETUP响应中重复这个报头，则客户端必须假定服务器不支持这个报头。

客户端的SETUP请求中指定了客户端在指定的RTP流中希望接收的RTP数据类型。下面是一个客户端请求的实例：

x-RTP-Meta-Info: to;bi;bo 

服务器的响应中列出了即将提供给指定RTP流的RTP数据名称。如果服务器支持压缩格式，则响应中可能也会包含ID和部分或者全部名称之间的映射关系。如果服务器并不支持所有被请求的名称，或者某些被请求的名称不能应用到由SETUP请求指定的RTP流，则服务器可能返回一个名称的子集。下面是两个服务器响应的实例：

x-RTP-Meta-Info: to=0;bi;bo=1
    x-RTP-Meta-Info: to;bi 

在第一个响应中，服务器表示自己将以标准格式提供bi数据。服务器将以压缩格式发送to数据，并用值为0的ID来标识包含to数据的域。服务器将以压缩格式发送bo数据，并用值为1的ID来标识包含bo数据的域。由于ID由７个数据位来表示，所以它的值必须在0和127之间。

在第二个响应中，服务器表示自己将以标准格式提供to和bi数据。

在SDP中描述RTP-Meta-Info有效负荷

RTP-Meta-Info有效负荷数据包的发起者应该将有效负荷的内容作为媒体的SDP描述的一部分加以描述。RTP-Meta-Info描述由两个额外的a= h报头组成。

a=x-embedded-rtpmap报头告知客户端RTP有效负荷的类型。

a=x-RTP-Meta-Info报头则告知客户端服务器将要提供的RTP数据类型。下面是RTP-Meta-Info有效负荷的SDP描述的一个实例：

m=other 5084 RTP/AVP 96
    a=rtpmap:96 x-RTP-Meta-Info
    a=x-embedded-rtpmap:96 x-QT}
    a=x-RTP-Meta-Info: standard;to;bi;bo 

x-Packet-Range RTSP报头

x-Packet-Range RTSP报头允许客户端（通常是一个缓存代理服务器）指定服务器应该传输的数据包的范围，从而使客户端能够填充自身的流拷贝中存在的洞。客户端应该在PLAY请求中发送x-Packet-Range RTSP报头，以代替Range报头。如果服务器不支持这个报头，则会向客户发送一个“501 报头没有实现”的响应。

这个报头的主体中包含当前PLAY请求的起始和终止的数据包编号。具体的数据包编号必须基于RTP-Meta-Info域中的包编号。如果需要知道如何通过请求数据包编号来得到部分的RTP流，请参见RTP-Meta-Info有效负荷格式的IETF草案。

报头格式是由两个参数组成，由分号分开。第一个参数必须是数据包编号范围，其值是起始和停止包的编号，中间用连字符号（-）连接；第二个参数必须是指定数据包所属流的URL。

下面这个实例请求trackID3流中编号范围从4551到4689的数据包：

x-Packet-Range: pn=4551-4689;url=trackID3 

终止数据包的编号必须等于或者大于起始数据包的编号，否则服务器可能返回一个错误，也可能在PLAY响应之后不再发送媒体数据。