承载使用用于流传送的控制协议和传输协议保护的内容.pdf

各个实施例利用保护内容的各种方法，诸如数字权限管理(DRM)，来允许在诸如家庭媒体网络等的局域网内的多个机器和设备上安全地回放内容。在至少某些实施例中，分别使用用于流传送的控制协议和传输协议来传递消息和内容。在至少某些实施例中，用于流传送的控制协议是实时流传送协议(RTSP)，而传输协议为实时传输协议(RTP)。

1.  一种计算机实现的方法，包括：
试图使用用于流传送的控制协议来建立用于交换受保护内容的控制流数据流；以及
允许使用数据流来传输受保护内容，其中所述数据流使用一传输协议。

2.  如权利要求1所述的方法，其特征在于，所述试图建立控制流的动作包括：
向被配置成发送所述受保护内容的发送机发送许可证请求消息；以及
从所述发送机接收包含一许可证的许可证响应消息。

3.  如权利要求1所述的方法，其特征在于，所述试图建立控制流的动作包括：
从被配置成播放所述受保护内容的接收机接收许可证请求消息；以及
向所述接收机发送包含一许可证的许可证响应消息。

4.  如权利要求1所述的方法，其特征在于，所述试图建立控制流的动作是使用RTSP实现的。

5.  如权利要求4所述的方法，其特征在于，所述试图建立控制流的动作还包括：
在RTSP描述请求的正文中向发送机发送许可证请求消息；以及
从所述发送机接收包括含有许可证的许可证响应消息的RTSP会话描述协议(SDP)。

6.  如权利要求4所述的方法，其特征在于，所述试图建立控制流的动作还包括：
从接收机接收RTSP描述请求的正文中的许可证请求消息；以及
向所述接收机发送包括含有许可证的许可证响应消息的RTSP会话描述协议(SDP)。

7.  如权利要求1所述的方法，其特征在于，所述允许的动作是使用RTP来实现的。

8.  如权利要求1所述的方法，其特征在于，还包括在所述受保护内容的流传送期间更新与所述受保护内容相关联的策略或格式信息。

9.  如权利要求8所述的方法，其特征在于，所述更新的动作包括经由所述用于流传送的控制协议来发送更新。

10.  如权利要求9所述的方法，其特征在于，所述用于流传送的控制协议包括RTSP，且所述更新是经由RTSP通告请求来发送的。

11.  如权利要求8所述的方法，其特征在于，所述更新的动作包括经由用于流传送的控制协议来接收更新。

12.  如权利要求11所述的方法，其特征在于，所述用于流传送的控制协议包括RTSP，且所述更新是经由RTSP通告请求来接收的。

13.  一种计算机实现的方法，包括：
使用RTSP来建立用于交换受保护内容的控制流；以及
允许使用数据流来传送受保护内容，其中受保护内容是使用RTP封装的。

14.  如权利要求13所述的方法，其特征在于，所述允许的动作包括在包含经加密的受保护内容的RTP分组中包括可在将所述经加密的内容解密的解密过程中使用的加密参数。

15.  如权利要求14所述的方法，其特征在于，所述RTP分组可包含多个不同的经加密的有效负荷。

16.  如权利要求15所述的方法，其特征在于，所述加密参数包括用于每一经加密的有效负荷的密钥ID扩展和初始化向量。

17.  如权利要求13所述的方法，其特征在于，所述允许的动作包括：
定义包含可在将经加密的受保护内容解密的解密过程中使用的加密参数的描述符；以及
使所述描述符与所述受保护内容相关联。

18.  如权利要求17所述的方法，其特征在于，所述关联的动作包括将所述描述符追加在所述RTP分组的尾部。

19.  如权利要求17所述的方法，其特征在于，所述经加密的受保护内容可使用由所述描述符引用的单个密钥来解密。

20.  如权利要求13所述的方法，其特征在于，所述允许的动作还包括：
在RTSP描述请求的正文中向发送机发送许可证请求消息；
从接收机接收所述RTSP描述请求的正文中的所述许可证请求消息；
向所述接收机发送包括含有许可证的许可证响应消息的RTSP会话描述协议(SDP)；
从所述发送机接收包括含有所述许可证的所述许可证响应消息的所述RTSP会话描述协议(SDP)。

承载使用用于流传送的控制协议和传输协议保护的内容
背景
数字权限管理(DRM)指的是用于诸如通过控制或限制对数字媒体内容在电子设备上的使用来保护内容的技术。DRM的一个特性在于，它可将媒体内容绑定到给定的机器或设备。因此，一般将关于特定内容并定义与该内容相关联的权限和限制的许可证绑定至该给定的机器或设备。因此，用户一般不能够取得该内容，并将其移动至另一机器以便回放该内容。
存在许可受到DRM保护的内容被移动至其它机器以便于在这些机器上回放该内容的某些技术，但这些技术倾向于使用不适于同时传送和回放内容的非实时内容传送协议。
概述
各种实施例利用保护内容的各种方法，诸如数字权限管理(DRM)，来允许在诸如家庭媒体网络等的局域网内的多个机器和设备上安全地回放内容。在至少某些实施例中，分别使用用于流传送的控制协议和传输协议来传递消息和内容。在至少某些实施例中，用于流传送的控制协议是实时流传送协议(RTSP)，而传输协议为实时传输协议(RTP)。
图1示出了可用其来在一个实施例中采用本发明实施例的一协议的示例性注册过程。
图2示出了可用其来在一个实施例中采用本发明实施例的一协议的示例性邻近检测过程。
图3示出了可用其来在一个实施例中采用本发明实施例的一协议的示例性会话建立过程。
图4示出了可用其来在一个实施例中采用本发明实施例的一协议的示例性数据传送过程。
图5示出了可用其来根据一个实施例来利用本发明实施例的流传送协议的各个方面。
图6示出了结合一个实施例来利用的图5中的流传送协议。
图7示出了结合一个实施例来利用的图5中的流传送协议。
图8是描述根据一个实施例的一方法中各步骤的流程图。
图9示出了根据一个实施例的分组。
图10示出了根据一个实施例的样本加密。
图11示出了根据一个实施例的分组。
概观
此处描述的各个实施例利用了用于保护内容的各方法，诸如数字权限管理(DRM)以允许在诸如家庭媒体网络的局域网内的多个机器和设备上安全地回放内容。在至少某些实施例中，分别使用用于流传送的控制协议和传输协议来传递消息和内容。在至少某些实施例中，用于流传送的控制协议为实时流传送协议(RTSP)，而传输协议为实时传输协议(RTP)。如由本领域的技术人员所理解的，在这些实施例中，引入了协议扩展，它们享受由RTSP/RTP提供的优点，包括通过用户数据报协议(UDP)和客户机与服务器之间的双向通信来进行数据传递。
具体地，在至少某些实施例中，协议扩展使用RTSP安全地建立一会话，传输用RTP封装的受保护数据，提供根据RTP有效负荷格式来加密和传送数据的各种方案，以及用于同经加密的内容数据一起传送加密参数的各种方法。
在以下的讨论中，提供了题为“内容安全和许可证传送协议的章节，它描述了可在其中采用本发明技术的一个特定系统。在其之后，提供了题为“RTSP”的章节以向不熟悉RTSP的读者给出RTSP领域中用于理解本发明技术的至少某些上下文。在该章节之后，提供了题为“使用RTSP的示例性实现”的章节，它描述了采用RTSP以建立控制流并利用RTP来建立数据流的各种本发明技术。
内容安全和许可证传送协议
以下提供了一示例性协议的讨论，该协议提供用于内容通过数字链路流动的安全和传送许可证。该协议仅构成了可用其来采用各种发明的技术的一个示例性协议。可以理解和领会，可利用其它协议，而不背离所要求保护的本主体的精神和范围。
在描述中使用以下密码记号：
K{数据}      使用秘密密钥K来加密数据。
K[数据]      使用秘密密钥K来签署数据。
{数据}_设备    用设备的公钥来加密数据。
[数据]_设备    用设备的私钥来签署数据。
在此特定协议中，有五个主要过程：注册、重新验证、邻近检测、会话建立、和数据传送。
在注册过程中，发送机(即，有内容要发送给另一设备的一设备)可唯一且安全地表示预期的接收机(即，要向其发送内容的设备)。在该特定协议中，发送机维护具有已注册接收机的数据库，并确保不同时使用超过少量预定数目的接收机。在该注册过程期间，发送机还采用邻近检测过程来确保接收机位于网络中发送机的“附近”，以防止受保护内容的广泛分发。
重新验证过程被用来确保接收机继续在发送机“附近”。除非接收机在过去的一预定时间段内已注册或已重新验证，否则内容不被传递给该接收机。
只要接收机向发送机请求内容就使用会话建立过程。发送机强制在完成会话建立之前该设备必须经过注册或最近经过验证。
一旦建立了会话，所请求内容的数据传送可用安全的方式进行。接收机可再次使用该会话来检索该内容的特定部分(查找)，但必须建立一新会话以便检索不同的内容。
现在结合图1和描述注册期间在发送机和接收机之间传递的各个消息的下表来考虑注册过程。


此处，接收机发送除其它信息外还包含接收机的数字证书的注册请求消息。响应于接收该注册请求消息，发送机验证接收机的证书，生成种子和随机会话ID，在注册响应消息中按上述格式向接收机返回同样内容。接收机然后验证发送机的签名，获取会话ID并执行附图中所示的其它动作。接收机和发送机然后可经历以下描述的邻近检测过程。
对于重新验证，执行与上述相同的过程，区别在于，在重新验证期间，接收机已在数据库中注册。
对于邻近检测，结合图2考虑以下。
在邻近检测过程期间，接收机向发送机发送包含邻近检测初始化消息中指示的会话Id的消息。发送机然后向接收机发送包含现时值(Nonce)(128位随机值)的消息，并测量接收机以使用内容加密密钥加密的现时值来答复所花的时间。最后，发送机向接收机发送指示邻近检测成功与否的消息。
接收机可重复该过程，直到它确认邻近检测成功。当该特定协议在基于IP的网络上使用时，通过UDP来交换邻近检测消息。接收机经由注册响应消息知道发送机的地址。接收机的地址不需要单独传送，因为可通过检查承载邻近检测初始化消息的UDP分组的传入IP头来确定。
下表描述了在邻近检测期间交换的消息：

对于会话建立，结合图3和描述在会话建立期间交换的消息的下表考虑以下。

在此示例中，从接收机向发送机发送许可证请求消息，它包含上述信息。作为响应，发送机可发送包含上述信息的许可证响应消息。
在该特定示例中，用XMR格式表示许可证，许可证包括内容加密密钥、内容完整性密钥、发送机CRL的版本、128位权限Id和128位序列号。许可证还包含使用OMAC用内容完整性密钥计算的OMAC。
对于数据传送过程，结合图4考虑以下。一旦会话建立完成，即以控制协议专用的方式执行数据传送。数据传送请求和响应两者必须为控制协议和内容类型特别定义。这概念性地表示在图4中。
现在提供了可用其来采用本发明实施例的示例性协议的简要概观，现在考虑RTSP的一些背景信息。
RTSP
如本领域的技术人员所理解，实时流传送协议即RTSP是用于对具有实时特性的数据传递(即流传送)进行控制的应用层协议。RTSP提供允许对诸如音频和视频的实时数据进行受控、按需传递的可扩展框架。数据源可包括实况数据馈送和已存储的剪辑两者。该协议旨在控制多个数据传递会话，提供用于选择诸如UDP、组播UDP和TCP的传递信道的手段，并提供用于基于RTP选择传递机制的手段。
RTSP建立并控制单个或多个时间同步的连续媒体流，诸如音频和视频。它自己一般不传递连续流，尽管连续媒体流与控制流的交织是可能的。换言之，RTSP用作多媒体服务器的“网络遥控器”。
要被控制的流的集合由演示描述定义。在RTSP中，不存在RTSP连接的概念；相反，服务器维护由标识符标记的会话。RTSP会话决不绑定至传输层连接，诸如TCP连接。在RTSP会话期间，RTSP客户机可打开或关闭至服务器的众多可靠的传输连接以发出RTSP请求。或者，如本领域的技术人员可以理解，可使用诸如UDP的无连接传输协议。
由RTSP控制的流可使用RTP，但RTSP的操作不依赖于用于承载连续媒体的传输机制。
现在结合图5考虑客户机/接收机500与服务器/发送机502之间的典型的RTSP请求/响应交换。
初步地，RTSP请求/响应具有为简洁起见未做描述的标头。在RTSP中，客户机/接收机500一般发出被称为描述的请求，它针对从服务器502检索由请求URL标识的演示或媒体对象的描述。服务器502用以会话描述协议(SDP)表示的被请求资源的描述作出响应。描述响应(SDP)包含其所描述的资源的所有媒体初始化信息。
接着，客户机500发送对指定要用于流传送媒体的传输机制的URI的设置请求。在图5的示例中，为音频和视频两者发送设置请求。客户机500还在设置请求中指示它将利用的传输参数。设置请求中的传输标头指定客户机可接受用于数据传输的传输参数。来自服务器502的响应包含由服务器所选的传输参数。服务器还响应于该设置请求生成会话标识符。
此时，客户机可发出播放请求，它告知服务器以经由设置中指定的机制来开始发送数据。响应于接收播放请求，服务器可开始流传送内容，在此示例中，该内容为音频/视频内容。如本领域的技术人员可以理解，在此示例中，流传送的内容使用RTP分组封装并通过UDP发送。
RTSP协议具有感兴趣的其它方法，包括暂停、拆卸、获取参数、设置参数、重定向和记录。对关于RTSP的其它背景，读者应查询1998年4月的RTSP草案，Schulzrinne，H.，Rao，A.和R.Lanphier的“Real Time Streaming Protocol(实时流传送协议)(RTSP)”，草案2326，可在http://www.ietf.org/rfc/rfc2326.txt提供。
使用RTSP的示例性实现
在以下讨论中，有两个主要的子章节，一个题为“控制流”，描述如何使用RTSP建立受DRM保护的内容的控制流，另一个题为“数据流”，描述了如何使用RTSP建立受DRM保护的内容的数据流。这些主要子章节中的每一个都具有与之相关联的描述本发明的实施例的各方面的子章节。
在以下讨论中，提供了如何根据一个实施例使用RTSP/RTP来实现上述协议的会话建立和数据传送过程的描述。更具体地，在以下的“控制流”章节中，提供了如何使用RTSP实现会话建立的描述。在“数据流”章节中，提供了如何使用RTP实现数据传送的描述。
控制流
根据该实施例，由希望回放受DRM保护的内容——即，具有相关联许可证的内容的接收机设备发起会话建立。回想以上对内容安全和许可证协议的讨论，客户机/接收机可相应地向服务器/发送机发送许可证请求消息，服务器/发送机可以许可证响应消息来对其答复。许可证响应消息又承载一许可证，在以上示例中该许可证是以可扩展媒体权限(XMR)来表示的。许可证包含与所请求的内容相关联的策略和内容密钥。
在描述请求中承载许可证请求消息
现在结合图6考虑内容安全和许可证协议与RTSP的汇合。具体地，图6示出了根据一个实施例的客户机/接收机600和服务器/发送机602。根据该实施例，当客户机/接收机600希望访问受DRM保护的内容时，客户机在描述请求的正文中插入许可证请求消息。
仅作为一个实现示例，考虑以下根据一个实施例包括许可证请求消息的描述请求消息摘录。
DESCRIBE rtsp://eduardo01/file.wmv RTSP/1.0
Accept:application/sdp
CSeq:1
Supported:com.microsoft.wmdrm-nd，com.microsoft.wm.eosmsg，
    method.announce
Require:com.microsoft.wmdrm-nd
Content-Type:application/vnd.ms-wmdrm-license-request
Content-Length:1078
License_Request_Message
在该示例中使用“Require(要求)：com.microsoft.wmdrm-nd”以指示接收机期望服务器为特定类型的发送机。在该示例中使用“Content-Type(内容类型)：application/vnd.ms-wmdrm-license-request”以指示该描述的正文包含许可证请求消息。
除非存在错误，否则发送机应以SDP描述来答复，该描述包括在下一章节中描述的许可证响应消息。
将许可证响应消息嵌入到SDP描述中
接收到在正文中包含许可证请求消息的描述请求之后，服务器可返回许可证响应消息。在此示例中，服务器返回不仅包含前述各个参数而且包含许可证响应消息的SDP描述。在此实施例中，如前所述，许可证响应消息将承载指定将对内容应用哪些策略的XMR许可证。
仅作为一个实现示例，考虑以下根据一个实施例包括许可证响应请求的SDP摘录。
RTSP/1.0 200 OK
Last-Modified:Thu，19 Dec 2002 15:36:18 GMT
Content-Length:1891
Content-Type:application/sdp
CSeq:1
Supported:com.microsoft.wmdrm-nd，com.microsoft.wm.eosmsg，
   method.announce
SDP_Description
根据一个实施例，由发送机返回的SDP包括根据2397草案(http://www.ietf.org/rfc/rfc2397.txt)的规范被编码在数据URL中的许可证响应消息。在一个示例中，包含在数据URL中的数据必须是Base64编码的，且MIME类型必须被设置为“application/vnd.ms-wmdrm-license-response”。
作为句法的示例，考虑以下：
data：application/vnd.ms-wmdrm-license-response；base64，
AggAAAAAAAABOFhNUgAAAAAB+TTbzXCRwls+/jA4fQQY0wADAAEAAAEgAAMAA
gAAADwAAQADAAAAEgBkAAAAAAAAAAAAAQAMAAAAGKRuHVtxsJ1Lk7WPrQPe5X
0AAQANAAAACgABAAMABAAAABoAAQAFAAAAEgBkAGQAZABkAGQAAwAJAAAApgA
BAAoAAACeajiAiUBMGrAGUAOIqMGBggABAAEAgC7V1QF54EzuYbTYKPbgBEK6
nDXGtbV+bJKF+Cn2yd/FUaC4vTIOxkF/eQLx+FqvLCUMtxvRSw01dns9Ejt02
1se2T+IROiZA0t5pRuNl3gq7JK9JKs+ZX8hKsEJFW0V7cyp9wdaCMh2esJ97r
9agH1Sxf0mAqcQ0j1Q5dtXlWx/AAEACwAAABwAAQAQZZaX5nGEUAV8w6p6BQr
++Q＝＝
在该示例中，根据SDP密钥管理扩展规范，数据URL必须使用“a＝key-mgmt”属性被插入到SDP会话层，该规范迄今为止仍是进展中的工作。句法如下：a＝key-mgmt:wmdrm-nd URL
URL参数为上述数据URL。
在通告(announce)请求中承载许可证响应消息
现在考虑一些媒体文件包含需要实施不同策略的片段。作为示例，采取由Windows媒体中心TV录制版生成的文件的情况。这样的文件受到WMDRM的保护，并具有与之相关联的多个策略。例如，对TV演出可能要求Macrovision，但对出现在同一录制内的商业广告片段则不需要。
该要求导致需要定义用于在流中间传递经更新的策略的机制。根据一个实施例，可使用RTSP的通告请求在流中间传递经更新的策略。在此实施例中，通告请求可承载包含新的XMR许可证的许可证响应消息。
在此示例中，有两种与流传送媒体相关联的策略可能改变的情况。在第一种情况中，仅与特定流相关的策略可能改变。第二种情况中，策略和内容格式本身均可改变。
考虑其中仅与流传送媒体相关联的策略可能改变的第一种情况。该情况的一个示例为TV演出片段与商业广告之间的切换，其中TV片段需要在模拟输出上启用Macrovision，而商业广告不需要。注意到，在该示例中，仅策略改变：诸如比特率、编解码器等编码参数保持不变。
考虑其中策略和内容格式两者均改变的第二种情况。该情况的一个示例也是TV演出片段与商业广告之间的切换，对策略有相同类型的改变。然而，在该示例中，TV演出和商业广告是使用不同编码参数编码的，诸如从高清晰度编码过渡到标准清晰度编码。这样的场景一般被命名为“格式改变”。该情况的另一示例涉及通常被称为“条目改变”的情况。条目改变一般是在作为“服务器方播放列表”的一部分由服务器传递的媒体文件之间切换的结果。这些播放列表一般由不必共有任何编码参数或策略的媒体文件的集合组成。
只要策略改变时格式未变，如在第一种情况中示出，服务器仅将新策略发送给客户机，作为通告请求的正文的一部分。在这种情况中，许可证响应消息被包括在通告消息的正文中。作为示例，考虑图7，它示出了示例性的客户机/接收机700和向客户机/接收机发出通告请求以续接(articulate)带有经更新策略的新许可证的服务器/发送机702。
只要策略改变且格式改变，如第二种情况中所示，服务器向客户机传递经更新的SDP描述。要求该SDP描述以描述发生的格式改变。在该示例中，SDP描述在格式改变的情况中也被作为通告请求传递。因此代替传递其中一个包含格式改变、另一包含策略改变的两个连续通告请求，服务器可仅发送承载SDP描述的一个通告请求。然后将策略改变作为嵌入在SDP描述中的许可证响应请求发送。再次考虑图7，它示出了其正文包含具有嵌入的许可证响应消息的经更新SDP的通告请求。
用于将许可证响应消息嵌入到作为通告请求的一部分的SDP描述中的格式与前述用于嵌入作为描述响应的一部分的SDP描述的格式相同。
图8是描述根据一个实施例的方法中各步骤的流程图。该方法可结合任何合适的硬件、软件、固件或其组合来实现。在一个实施例中，该方法被实现为具体化成某种类型的计算机可读介质的一组计算机可读指令或软件代码。
步骤800试图通过经由流传送协议发送对受DRM内容的许可证的请求来建立控制流。在所示和所述实施例中，该步骤由客户机/接收机执行。对许可证的请求的一个具体示例为上述的许可证请求消息。可利用其它的请求类型或格式，而不背离所要求保护的主题的精神和范围。此外，以上描述了流传送协议的一个示例(即，RTSP)。可使用其它流传送协议，而不背离所要求保护的主题的精神和范围。在RTSP实施例中，将请求插入描述请求的正文内。
步骤802试图通过接收该对许可证的请求来建立控制流。该步骤在此示例中由服务器/发送机实现。响应于接收请求，步骤804可使用流传送协议向客户机/接收机发送许可证。以上提供了将许可证返回给客户机/接收机的一个具体示例，其中向客户机/接收机发送了许可证响应消息形式的许可证。可利用其它响应类型或格式，而不背离所要求保护的主题的精神和范围。此外，以上描述了流传送协议的一个示例(即，RTSP)。可利用其他流传送协议，而不背离所要求保护的主题的精神和范围。在RTSP实施例中，响应是用SDP发送的。
可以理解和领会，步骤804也可被实现成向客户机/接收机发送更新。在此情况和RTSP示例的上下文中，可使用上述通告请求来传递更新。
步骤806经由流传送协议接收许可证。在所示和所述实施例中，该步骤由客户机/接收机实现。在接收许可证之后，客户机可根据许可证中定义的条款来访问并消费内容。
以下描述跟随许可证获取过程的数据流。
数据流
描述了结合受DRM保护的内容利用RTSP的控制流的示例性实施例，现在考虑包含实际受DRM保护的内容或允许其通信的数据流。
在以下描述的实施例中，使用RTP作为数据传送协议在发送机和接收机之间传输受DRM保护的内容。即，受DRM保护的内容传输自发送机并传输至接收机。
在提供的特定示例中，描述了两种不同的方法。在第一种方法中，所利用的RTP有效负荷格式支持扩展，进而允许诸如密钥ID扩展和初始化向量的加密参数被包括在RTP分组中，使得经加密的有效负荷数据可经历解密过程并被解密。在第二种方法中，RTP有效负荷格式不支持扩展。因此，在该方法中，定义了描述符，它与包含经加密的有效负荷的RTP分组相关联。描述符包含诸如密钥ID扩展和初始化向量等可在解密过程中使用来对经加密的有效负荷数据解密的加密参数。
通过Windows媒体有效负荷格式来承载样本加密的有效负荷
图9示出了根据一个实施例、整体在900处的RTP分组的示例性部分。在该实施例中，所利用的RTP有效负荷格式以允许诸如密钥ID扩展和初始化向量等的加密参数连同经加密的有效负荷内容一起被包括在RTP分组中的方式来支持扩展。这样的格式的一个示例为Windows媒体RTP有效负荷格式，它在http://download.microsoft.com/download/5/5/a/55a7b886-b742-4613-8ea8-d8b8b5c27bbc/RTPPayloadFormat_for_WMAandWMV_vl.doc描述。然而，可利用其他格式，而不背离所要求保护的主题的精神和范围。
在该示例中，分组900包括RTP标头902和有效负荷格式标头904。有效负荷格式标头在该示例中允许扩展。因此，分组900还包括密钥ID扩展906和初始化向量908，以及与密钥ID扩展906和初始化向量908相关联并可用其来解密的经加密有效负荷数据910(音频或视频数据中任一)。此外，RTP分组900可包括多个其它经加密的有效负荷。在此特定示例中，分组900还包括另一有效负荷格式标头904a、密钥ID扩展906a、初始化向量908a、以及与密钥ID扩展906a和初始化向量908a相关联并可用其来解密的经加密有效负荷数据910a(音频或视频数据中任一)。
在该特定实施例中，一个RTP分组可包含多个不同的经加密的有效负荷。作为仅在一个特定上下文中的特定实现示例，结合Windows媒体音频和视频内容考虑以下。
当承载受上述许可证保护的Windows媒体内容时，必须在RTP分组中设置以下值和字段。
1.“MAU属性”部分中位字段(Bit Field)2中的“加密”位(E)必须被设置为1。
2.“MAU定时”部分中“扩展存在”位(X)必须为设置为1，以指示扩展字段的存在性。
3.“经加密有效负荷边界”扩展不允许存在。
4.必须包括“WMDRM初始化向量”扩展。以下值必须被设置：
a.“扩展类型”必须被设置为2。
b.“扩展长度”必须被设置为8(意为64位)。
c.必须用如以下在题为“样本加密”的章节中定义的样本ID值来设置“扩展数据”。
d.必须为每个MAU的第一有效负荷包括该扩展。如果MAU被分成多个有效负荷，则该扩展应仅存在于第一有效负荷中。
5.必须包括“WMDRM密钥ID”。以下值必须被设置：
a.“扩展类型”必须被设置为3。
b.“扩展长度”必须被设置为16(意为128位)。
c.在承载ASF内容时必须用来自ASF内容加密对象的密钥ID值来设置“扩展数据”。或者，在承载诸如DVR-MS的非ASF内容时，它被设置为表示所使用的加密密钥的密钥ID值。
d.必须为每个多有效负荷RTP分组中的第一有效负荷包括该扩展以解决分组丢失问题。
样本加密
作为对以上项目4(c)的进一步解释，考虑以下。在该实施例中，每一样本应使用计数器模式的AES加密。图10示出了用于使用该技术对单个样本加密的过程。
在该实施例中，计数器模式创建字节流，这些字节然后与媒体样本的明文字节异或(XOR)以创建经加密的媒体样本。密钥流生成器使用AES轮来一次生成16字节块的密钥流。对AES轮的输入为内容加密密钥(KC)以及样本ID与样本内块号的128位级联。
密钥流生成器的输出应与来自媒体样本的相应块(i)的数据逐个字节地异或。在媒体样本未被按16字节平均划分的情况中，仅来自最后一块的媒体数据的有效字节应与密钥流异或并被保留为经加密的样本。
当加密来自ASF文件的样本时，样本ID等效于来自有效负荷扩展的样本ID。
因此，在该实施例中，根据“样本”边界来加密和解密数据，这些边界是给定媒体类型的自然边界，例如视频流的视频帧或音频流的音频样本块。
使用数据片段描述符通过RTP有效负荷格式来承载链路加密的有效负荷
图11示出了根据另一个实施例、整体在1100处的分组的各个方面。在该示例中，分组1100可包括IP标头1102、UDP标头1104、RTP标头1106、有效负荷格式标头1108、有效负荷数据1110和描述符1112。在该特定示例中，将描述符追加到有效负荷数据的尾部，尽管它可被置于任何合适的位置。如本领域的技术人员可以理解的，将描述符置于有效负荷数据的尾部可减轻后向兼容问题。
在该实施例中，除RTP标头以外的RTP分组被视为与描述符1112相关联的数据片段来处理。描述符1112又承载了可在能够解密有效负荷数据1110的解密过程中使用的加密参数。在该特定实施例中，对有效负荷数据1110应用了单个策略和内容加密密钥。
根据一个实施例，描述符1112包括如下的数据结构：

在该示例中，标志部分为指示数据属性的位字段。当前定义以下值：0x01指示经加密数据。当该标志被置位时，它指示数据处于加密形式。否则，该数据为明文。
对于扩展部分，扩展个数字段指示包括在该描述符中的可变长度扩展的个数。对于可变长度扩展字段，每一扩展具有以下格式：

根据一个实施例，密钥ID扩展和数据片段ID扩展被如下定义：
密钥ID扩展
扩展类型：对于密钥ID扩展，必须被设置为0x01。
扩展长度：必须被设置为16，表示128位(16字节)。
扩展：必须包含同该描述符一起传递的经加密媒体的密钥ID值。该扩展仅在加密数据标志被置位时才使用。
数据片段ID扩展
扩展类型：对于数据片段ID扩展，必须被设置为0x02。
扩展长度：必须被设置为8，表示64位(8字节)。
扩展：必须包含同该描述符一起传递的经加密媒体的数据片段ID值。该扩展仅在加密数据标志被置位时才使用。
对于长度部分，在该实施例中，该部分必须包含以字节为单位的数据片段描述符的总长度。该长度并不包括同该描述符一起传递的媒体数据的大小。
结论
上述各个实施例利用保护内容的各种方法，诸如数字权限管理(DRM)来允许在诸如家庭媒体网络的局域网内的多个机器和设备上安全地回放内容。在至少某些实施例中，经由实时流传送协议(RTSP)和实时传输协议(RTP)来传递消息和内容，且引入了协议扩展，它享受由RTSP/RTP提供的优点，包括通过用户数据报协议(UDP)以及客户机与服务器之间双向通信来进行数据传递。
尽管用结构特征和/或方法步骤专用的语言描述了本发明，但可以理解，所附权利要求书中定义的本发明不必限于所述的特定特征或步骤。相反，特定特征和步骤被公开为实现所要求保护的本发明的优选形式。