放请求之前，每个媒体流必须使用SETUP被配置。
[0097] C->S ：SETUP rtsp ：//example. com/media. mp4/streamid = 0 RTSP/1. 0
[0098] CSeg ：3
[0099] Transport :RTP/AVP ;unicast ;client-port = 8000-8001
[0100] S->C ：RTSP/1. 0 200 OK
[0101] CSeq ：3
[0102] Transport ：RTP/AVP ；unicast ；client_port = 8000-8001 ；server_port = 9000-9001
[0103] Session : 12345678
[0104] PLAY请求将引起一个或所有媒体流被播放。可以通过发送多个PLAY请求堆积播 放请求^ URL可以是聚合的URL (以播放所有媒体流），或单一媒体流URL (以播放仅那个 流）。范围可以被指定。如果没有指定范围，则从开始播放流并且播放到末尾，或者，如果流 被暂停，则在暂停的点处恢复。
[0105] C->S ：PLAY rtsp ：//example. com/media. mp4 RTSP/1. 0
[0106] CSeq ：4
[0107] Range :npt = 5-20
[0108] Session : 12345678
[0109] S->C ：RTSP/1. 0 200 OK
[0110] CSeq ：4
[0111] Session : 12345678
[0112] RTP-Info ：
[0113] url = rtsp ：//example. com/media. mp4/streamid = 0 ；seq = 9810092 ；rtpti
[0114] me = 3450012
[0115] 存在针对允许客户端暂停或终止播放内容的RTSP的其它命令。
[0116] 在该工作中，我们将考虑大量的主机从源请求相同的内容的情况。我们假设所有 主机从相同位置播放内容，即内容以固定流的某种形式被传送，并且在源仍播放出固定流 (即，它已经完成之前）的同时主机可以在任何时间加入该流。我们进一步假设源经由单播 向每个主机传送内容作为单个固定流。
[0117] 为了经由单播提供相同内容的许多相同的副本浪费了网络带宽。因此，在网络运 营商的兴趣内以检测这种情况，并且由一个多播副本替换该内容的许多单播副本。
[0118] 考虑被连接到源并且提供到源的互联网接入的网关路由器。如果该路由器被多播 嵌入，则在多播情况下它将变成源的源DR。我们现在指定源DR可以如何检测许多单播固定 流正在作为前导被播放出以切换到多播。
[0119] 本质上，并且参照图3、图4和图5,多播使能器10(例如，在源DR 12上或在别处 运行）监视针对源14的关于一段媒体内容的请求，并且获得关于该特定内容的未来需求34 的预测。考虑未来需求34的预测，多播使能器10确定单播至多播切换算法22的结果。如 果切换算法22的结果是触发条件被满足，则它启动（24)关于正讨论的内容的多个单播数 据流到一个多播数据流的转换。如果切换算法的结果是触发条件没有被满足，则它保留多 个单播数据流并且不启动到多播的转换（26)。
[0120] 更详细地，源DR 12的多播使能器10监视针对源14的所有请求，并且保持URl的 表Turi和相关的计数器以及其它值（见下面表1)。表T URl可以被存储在多播使能器10的 表存储模块16内或者在别处（例如，在经由网络连接的分离的设备上）。源DR 12优选地 也考虑如果在负载平衡情况下可以从不同的源传送相同的内容。只要这些源被连接到相同 的源-DR，这可以例如通过剥去URI的第一部分（例如，WWW. example, com、wwwl. example-corn、 www2. example, com 都映射到 example, com) 被完成。
[0121] 每当经由来自互联网上的一些主机的进入请求检测到URI，该表中的条目就被创 建或者更新。源DR检查URI是否已经存储在表中，如果没有，它创建新的条目并且将计数 器设置为1。如果条目存在，则计数器增加。源DR也保持与URI的下载相关的会话的列表。 每当会话被终止，相应URI的计数器就减小。
[0122] 如果URI代表在更长的时间段上可用的内容，则源DR也可以收集针对每个URI的 附加的细节。这将是例如如果该内容代表每小时播放出的有规律地重复的一段内容的情 况。这可能是内容针对每次播出而改变的每小时新闻节目或再次每15分钟提供的电影等。 这些额外的细节可以是持续时间或内容的大小、被请求的内容的过去频率、在特定时刻被 请求的内容的概率、由于主机停止接收内容会话被提前终止的概率、在会话的数量属于阈 值之外之前播放出的内容的平均持续时间等。所有这些细节可以被源DR使用以决定是否 或何时启动多播，如在图4的流程图中所示意性地示出的以及如关于切换算法22在以下更 详细地描述的。
[0123] 表Turi也可以包括关于对所讨论的内容的未来需求的预测信息。如图5中所示意 性地示出的，在源DR(例如，在多播使能器10的需求预测模块18中）上或者在别处运行 的预测算法28可以监视内容消耗和正被请求的内容的类型。基于T uri中的细节（例如，数 据30)或者通过使用附加信息，该算法可以预测与URI有关的一段内容有多受欢迎，并且这 可以被用于当第一个请求到来时立即开始多播，否则被用于改变何时切换到多播的决策策 略。附加信息32可以来自社交网络，通过过滤例如用于内容推荐的Facebook或者Twitter 业务、或新闻内容可以针对可以指向新闻节目具有高的被请求的机会等的事实的事件（例 如，旧金山大地震）被过滤。趋势数据也可以从搜索引擎获得。通常，这些技术在内容推荐 器引擎中是公知的。来自这种引擎的信息可以被用于修改另外仅基于历史数据的未来内容 请求的预测。算法28使用这种信息来生成针对非常受欢迎的一段内容的似然值34,并且这 种似然值可以依次被源DR使用以修改它的用于将内容传送切换至多播的策略。
[0124] 表1 :表Turi的不例
[0125]
[0126] 表1的关键词（以及下面的表2和表3):
[0127] N=激活的会话的当前数量
[0128] MC/UC =多播（MC)或单播（UC)
[0129] C24 =前24小时的计数
[0130] CW=上周的计数
[0131] P =会话过早结束的概率
[0132] S=大小（MB)
[0133] AD =平均会话持续时间（分钟）
[0134] PSa.. 23 = -天的时间对内容的预测的需求
[0135] (条目的向量：小时·分钟：预测的会话的数量）
[0136] 表1包括针对Turi中预测信息的一个示例。表1的最后一列包括在接下来的24个 小时内每小时的预测会话数量。可以由许多类型的预测算法计算这些数字。一种非常简单 的方法是在最后例如3天的每个完整的小时给激活的会话计数，并且使用激活的会话的平 均数作为对接下来24小时时段的预测。将每小时地更新这些数字。也可能针对内容的类型 使用更长期的平均。例如，通过测量新的电影的卷绕（take-up)，有可能生成针对可以被用 于估计针对一天的每个小时的所请求的会话的数量的最初几天的典型的观看轮廓（见表1 的最后一列）。可以使用本领域的技术人员已知的其它更复杂的预测算法。
[0137] 采仿1丨.标/丨、时她彳+管钍对由容URI的需要，其中，队是在时间t的需要计数。
[0138]
[0139] 如图3所示，源DR使用Turi决定一些内容的传送是否应该被切换至多播。例如， 如果会话的当前数量超过某一阈值（例如，20)，并且预期的/预测的平均持续时间足够长 (例如，10分钟），以及过早地结束会话的概率小于某一概率（例如，〇. 5)等，则当前经由单 播服务的一些内容URI可以被切换至多播。针对该实施方式，我们假设下面简单的切换逻 辑使用t作为该天的当前小时并且使用当前和预测的信息（其它更复杂的决定逻辑可以被 实现）：
[0140] IF 没有多播 AND N>20AND AD>10AND P〈0. 5AND S>100AND PS(t+l)>N/2
[0141] THEN切换至多播
[0142] ELSE继续单播
[0143] 每当计数器针对还没有在多播上的URI增加，决定逻辑就针对该URI再次被调用。
[0144] 随着触发条件被满足在网络中采取以下动作：
[0145] 该部分描述一旦触发条件被满足就米取的动作。
[0146] 这里有两组可以进行的动作以便成功地从单播切换至多播。由于，在目前优选 的实施方式中，我们使用现有的PM-SM建树法，候选的RP(C-RP)和候选的引导路由器 (C-BSR)可能已经建立。组地址尚未被分配，因为这依赖于此时的预订需求。鉴于此，以下 的背景动作被保持以最小化针对转换所花费的时间。在另一个实施方式中，一旦多播工作， 就可以部分地或者全部地进行这些动作，但是我们的方法使在多播条件被满足和它在网络 中是完全可操作的之间的延时最小化。
[0147] 1.周期性地进行BSR选择而不考虑在网络中正进行多播。
[0148] 2. C-RP向所选择的BSR告知它们的候选资格，同时将组地址设为" 0"，使得当P頂 路由器加入网络时BSR可以生成引导消息。
[0149] 3.即使所有业务保持单播，启用了 P頂的路由器也向彼此发送Hello消息。这导 致它们具有当多播被触发时用于组到RP映射的RP集合。随后，当主机加入各自的组时仅 加入/删除消息需要被传播。
[0150] -旦我们提出的多播使能器决定将一段内容（基于URI)从单播切换至多播到X 个主机，如下的其它动作被我们提出的多播使能器触发。我们假设所有主机具有选择连接 到主机存在的本地子网的主机DR，如在RFC 2362和RFC 4601中所提出的。
[0151] 1.组地址系统被生成。存在许多方法做这件事。一种方法是为每个URI分配一个 组地址。这可能导致大量的组地址是可用的。在另一种方法中，可以为每个主机组和源的 地理位置组合分配组地址，使得组地址的哈希函数生成最接近于源和组成员两者的1^，使 得RPT结构更有效。多播地址动态客户端分配协议（MADCAP)在RFC 2730被提出，用以主 机请求并且被分配多播组地址。
[0152] 这里已经存在通过IANA的永久的多播地址分配。如果用户具有指定的范围的可 用性，这样的一个实现可以跨越在网络上传递的所有内容使用该现有的组地址的集合。另 选地，可以使用可以被再用作从管理的范围崩溃组的动态的地址池。
[0153] 地址分配服务器管理这方面并且向源DR针对它的单播源地址返回组地址。使用 源单播地址、RP集合（使用到"ALL-P頂-ROUTERS"的引导消息被充满）、组地址和哈希掩 码，使用在RFC 4601中描述的现有的哈希函数方法进行RP到组的映射。<