媒体频道管理的制作方法

专利名称：媒体频道管理的制作方法
技术领域：
本发明 一般涉及通信系统中媒体会话的管理，并且特别涉及在这
样的媒体会话中减少切换媒体频道(media channel)的用户察觉时间。
背景技术：
在现有移动网络和移动通信系统中提供和供应大范围的新业务 已成为趋势。目前对于使用移动网络用于多媒体或者电视内容存在很 大的兴趣。在本技术领域这经常被称为移动电视。移动电视应用的目 的是提供类似电视的体验，用户可以选择并且轻易地在不同的多媒体 或者电视频道之间快速移动。
普通的电视频道被广播给以许多用户，并且典型地用户可以选择 接收和观看哪个频道。类似地移动电视向若干终端用户发送一組(实 况的)媒体或者多媒体流。每个多媒体流对应一个电视频道，并且每 个用户将能够选择观看哪个频道。此刻，用于移动电视的广播/组播 传送方法处于开发中。这样的标准化努力的例子是3GPP多媒体广播/ 组播服务(MBMS)以及欧洲电信标准协会(ETSI)手持式数字视频 广播(DVB-H)。这些标准在其广播分配方式方面类似于传统TV。
同时，直到基于组播/广播的移动电视可用，存在对可以在现有 移动传输频道上实现的解决方案的需求。稍后对于单播传输是优选分 配方法的具有足够容量的网络和具有少数用户的蜂窝也将具有很大 的兴趣。
在基于网络的网际协议(IP)上使用流的类似移动电视的服务可 以在现有移动网络中实现。例子是在3GPP中开发的包交换(PS)流々某 体服务(Packet-Switched Streaming Service: PSS )。为了开始这样的多媒体或者电视会话，用户 一般沖浪到网页或者入口并且点击或者 选择链接来观看流媒体直播频道。
还存在几个可用于移动电视的专有流媒体解决方案，例如
RealNetworks (真实网络)、Apple的Quicktime (迅时)和Microsoft 的mediaplayer (媒体播放器)。这些解决方案还一般具有点击链接以 开始接收某个频道的入口或者网页。
移动电视服务的目标之一是能够在频道之间快速移动，如同某人 可对通用的广播电视频道所做那样。如果将全部频道广播，接收机可 以通过选择适当的传输频道以及使用适当的多路输出选择器在本地 在频道之间选择。这是对于有线、卫星或者地面电视和即将出现的移 动标准MBMS和DVB-H的情况。然而，对于单4番会话，客户端必须改 为影响"服务器"或者多媒体提供者以发送想要的频道。
执行基于IP的移动流媒体的传统方法是在浏览器中选择特定的内 容。这开始会话描述协议(Session Description Protocol: SDP)或者同 步多々某体集成语言(Synchronize Multimedia Integration Language: SMIL)文件的下载，其又在用户终端的媒体播放器中发起实时流媒体 协议(Real Time Streaming Protocol: RTSP )流々某体会话。直到用户 在用户终端的屏幕上看到内容所需要花费的大约时间一般是大约或 者稍微超过10秒，其中大概5秒用于请求建立而其余用于信令(大约2 秒)和緩冲(大约3到4秒)。如果用户想要切换到另一""多媒体或者 电视频道"，他必须终止当前数据流并且返回到他通过点击链接来选择 另一频道的浏览器。那么，开始新的RTSP会话，媒体播放器启动并且 开始緩冲，并且存在新的大约10秒的延迟。
在超出用于选择单播频道的浏览器链接时，最简单的途径是每当 某人切换频道就发出向新的URI (Univeral Resource Identifiers:通用 资源标志符)建立新流媒体会话的请求。这是相当普遍的，但是相当 慢，因为必须进行全新的RTSP信令处理以及内容的緩沖。
为了补救这个緩慢的过程，已经开发了更快的解决方案[l]，其中每个用户具有连续的流媒体会话并且可以通过在HTTP (Hypertext Transfer Protocol:超文本传输协议)或其它协议上的单独信令来启动 频道切换。

发明内容
道以使能够对每个媒体流进行一个连续RTP (实时传输协议)会话。 本发明克服了先有配置的技术的这些和其它的缺点。 本发明的一般目的是提供有效的媒体会话管理。
如随附专利权利要求书所定义的本发明满足这些以及其他目的。 简言之，本发明包括基于单播的媒体会话管理，该媒体会话管理 包括用户终端和具有多个基于单播的媒体频道的访问的媒体服务器。 通过从用户终端到媒体服务器的通用频道透明会话请求的传输发起 通用频道透明会话建立过程。该建立过程包括在用户终端和服务器之 间以频道透明请求和响应的形式的信息交换。然而，在此建立过程期 间不选择々某体频道。这意味着媒体服务器仍然不知道终端想收听什么 频道以及服务器应该发送什么媒体内容给用户终端。
首先，在完成建立过程时，终端以对此频道的频道具体呈现请求 形式通知媒体服务器所请求的媒体频道。然后，服务器可使用在先前 频道透明建立过程期间协商的机制和端口开始传递该频道的媒体内 容。
如果用户随后希望切换到服务器的新的基于单播的频道，则终端 在正在进行会话期间仅向服务器传输仅对新频道的新频道具体呈现 请求。这意味着该频道切换发生在会话内部，不需要首先结束当前会 话然后建立新会话的任何要求。因此，对新频道要再使用该传送机制 和端口。这将显著地减少频道切换时间，因为在服务器和终端需要的往返和数据处理更少。
本发明还允许在单播和广播传递之间的无缝或者接近无缝的切 换。用户终端仅向媒体服务器传输呈现引起当前基于单播的频道的媒 体内容的传送的暂时停止的暂停请求。终端现在可以收听广播频道。 如果用户重新希望收听先前的基于单播的频道或者其它基于单播的 频道，那么终端发送对该频道的新频道具体呈现请求。因此，不需要 任何新的会话建立过程就恢复媒体频道。


通过参考以下结合附图所作的说明可以更好地理解本发明及其
更多的目标和优势，其中
图1A和1B是根据先有技术图解频道建立过程与频道切换过程的
信令框图。
图2是根据本发明图解管理基于单播的媒体会话的方法的流程
图3是根据本发明的实施例图解频道透明会话建立过程的信号框
图4是根据本发明的另 一 实施例图解频道透明会话建立的信号框
图5是根据本发明的再一实施例图解频道透明会话建立过程的信 号框图6是根据本发明的实施例图解频道请求过程的信号框图； 图7是图解本发明的用于暂停以及用于终止基于单播的媒体会话 过程的信号框图8是可应用本发明的教导的通信系统的部分的示意概图； 图9是根据本发明的用户终端示意框图10是根据可在图9的用户终端中实现的本发明的会话建立管理 器的示意框图；图ll是根据本发明媒体服务器的示意框图；以及 图12是根据可在图11的媒体服务器中实现的本发明的会话建立 管理器的示意框图。
具体实施例方式
在附图中，对于相应或者相似单元将使用相同的参考标号。
本发明涉及媒体会话管理，特别涉及管理基于单播的媒体会话。 与先有技术的方法相比，本发明的会话管理减少了切换基于单播的媒 体频道或者在单播和组播/广播频道之间切换所需要的往返的数目。
由于往返数量的减少，切换媒体频道的用户察觉时间减短，接近 "真正的"快速移动水平。因此，本发明在基于单播的通信系统中提供 与当前的通用电视系统和即将来临的基于组播/广播的移动电视相似 的类似电视的体验。本发明的教导可用于任何此类单播系统、尤其使 用因特网协议(IP)的无线通信系统，以供数据通信。这样的通信系 统的典型示例是通过PS流(PPS)向已连接用户提供多媒体数据的包 交换(PS)系统。更多的PPS的信息可以参考文档[2]。
根据本发明，媒体频道可以例如携带"实况"媒体或者包括由一个 或多个剪辑组成的预先录制的内容。
从用户角度而言，本发明的频道切换将被更加平稳地体验，将在 更短的时段执行，并且不需要像先有技术的单播解决方案所需要的那 样访问多媒体提供者的网页也不需要建立新的媒体会话。
根据本发明，媒体或者多媒体数据包括可以在用户终端呈现和显 示的任何形式和类型的媒体。这包括但不限于图像、视频、音频以及 其他在呈现期间能够由用户察觉的々某体类型。
为了简化对本发明及其优点的理解，首先结合图1A和1B简单回顾 建立基于单播的蝶体会话以及切换々某体频道的先有技术方法。这些图 示出了在建立期间执行的信令以及实时流媒体协议(RTSP )会话的管 理。如本领域中所公知的，RTSP是用于对具有实时性的媒体数据传送的控制的应用级协议。现在，可用包括RTSP 1.0和RTSP2.0的不同版 本的RTSP。本发明可结合这两种版本和其它任何RTSP版本使用。
可用在用户终端的DESCRIBE (描述)请求的编辑和发送初始化 RTSP会话。响应DESCRIBE请求，媒体服务器编译并且返回包括请求 的媒体内容说明的响应(200 OK消息)。响应一般包括在媒体服务 器的媒体描述的通用资源定位(URL)。此响应包含用于请求的媒体 内容的全部媒体初始化信息。在典型实施例中，描述具有会话描述协 议(SDP)文件的形式。其中，除描述信息的通用资源标志符(URI) 之外，此SDP文件包含经所选媒体的名称、传输地址以及可用于媒体 的编解码器(codec)。
具有SDP文件的DESCRIBE响应的典型示例可如同
RTSP/1.0 200 OK
CSeq:"会话唯一序列号"
Date:"创建日期和时间"
Content-Type:"包含于响应中的文件的内容类型" Content-Length:"文件长度"
上述四行构成RTSP响应的头标。下面的行举例说明SDP文件内容 的例子
v=0 "SDP文件的开始"
0="创建者"
8="会话名称" 1="会话信息"
uJ'描述的URT e-"电子邮件地址"
c一'连接信息" t^'会话活动计时"
a= control:* "会话层上使用的控制行，^旨定控制URI与用于 DESCRIBE的相同"a=control:audiotrack "用于具有相关URI的音频媒体的控制行" m= audio 3456 RTP/ AVP 0
a=control:videotrack "用于具有相关URI的视频媒体的控制行" m= video 2232 RTP/AVP 31
在用户终端(UE)与媒体服务器(MS)之间的通信的典型实例 可以因此是
UE — MS response:
DESCRIBE rtsp:〃mediaserver.com/movie.test RTSP/1.0 CSeq:l
MS->UE response: RTSP/1.0 200 OK CSeq: 1
Date: 28 Feb 2006 15:35:06 GMT Content-Type: application /sdp Content-Length: 435 v=0
o=- 950814089 950814089 IN IP4 144.132.134.67
s=Example of aggregate control of ARM speech and H.263 video
e=foo@bar.com
c=IN IP4 192.168.30.29
b=AS:77
t=0 0
a=range:npt=0-59.3478
a=control:*
b=AS: 13
a=fmtp:97 mode-set=0,2,5，7; maxptime=200 a=control: streamID=0 m=video 0 RTP/ AVP 98 b=AS:64f
a=rtpmap:98 H263-200/90000 a=fintp:98 profile=3; level=10a=control: streamID=l SDP文件的更多信息可参考文档[3]。
此后，用户终端编译并且传输对需要的々某体内容的通用资源标志 符(URI)的SETUP (建立)请求。典型的媒体会话包括通过基于单 播的i某体频道传输的视频和音频内容。在此情况下，对于两种内容类 型逐步执行SETUP过程。例如，可以首先传输包含视频内容的URI的 视频SETUP请求。对于媒体数据传输，该请求还包含用户终端可接受 的传输参数的指示。这些参数尤其包括用于视频内容的客户端输入端 口。响应SETUP请求，媒体服务器产生此后作为当前媒体会话标识符 使用的会话标识符。把此会话标识符与由服务器和视频输出端口选择 的传输参数一起返回。
把相应的音频SETUP请求和响应在用户终端与媒体服务器之间 通信，用于协商音频传输参数。与视频SETUP消息形成明显对比，音 频SETUP请求包含所通知的会话标识符。
现在成功地建立RTSP会话，并且可以开始实际的媒体内容传送。 用户终端因此编译PLAY (播放)请求，该请求告诉服务器启动经在 会话建立期间协商的传送机制发送通知的媒体内容。PLAY请求可以 指定正常播放时间应该开始的范围，或者指定回放或媒体呈现应该开 始的时间参数。i某体服务器处理此PLAY请求并且以确认的时间参数 或者范围以及同步信息响应，比如依据在此响应的RTP信息域中的 RTP时间。
然后，能够使用确定的传送机制在基于单播的i某体频道传递所请 求的媒体。
如果用户随后想要切换到第二基于单播的频道，必须首先结束当 前RTSP会话。这可以通过传输PAUSE (暂停)请求实现，该请求包 含到媒体服务器的会话标识符和媒体URI。这引起传递的媒体流的暂 时中断。但是，此时没有分配给此流的资源被释放。用户终端继续， 传输TEARDOWN (拆卸)请求以停止对给定URI的流传递，释放与其关联的资源。这就结束了当前媒体会话。更多RTSP的信息可参考文档 [4]。
然后，迫使用户终端建立新的、但用于新的媒体频道的RTSP会话， 如图1B所示。这样，再一次进行与如前所述的相同过程，但使用新的 媒体内容的URI并使用新的会话标识符。因此，在能呈现新^ 某体频道 的媒体内容之前，频道切换包括进行6次往返的大范围信令以及媒体 服务器和用户终端的某些处理延迟。
本发明经频道特定呈现请求(RTSPPLAY请求)以及通用频道透 明会话建立过程，通过选#^某体频道减少此与频道切换有关的大范围 信令。
图2是管理基于单播的媒体会话的方法流程图，所述媒体会话包 括用户终端(客户端)以及提供多个、即至少两个不同的媒体频道的 媒体服务器。从步骤S1开始，在这里用户终端产生并且向媒体服务器 传输通用频道透明会话请求。因此，此会话请求不选择具体媒体内容 或者媒体频道。这样，此时仍然没有通知媒体服务器用户终端请求哪
个媒体内容。根据频道透明会话请求的接收，媒体服务器以及用户终 端在下一步骤S2执行通用频道透明媒体会话建立过程。此建立过程基 于先前产生和传输的会话请求实施。这样，步骤S2主要包括在用户终 端与服务器之间建立RTSP会话。但是，与先有技术成明显对比，此会 话建立过程不包括随后向用户终端传递媒体内容的任何规范。这样， 在用户终端与媒体服务器之间交换信息、比如传输参数协商以及会话 标识符通告。然而，执行此信息交换，没有要用于々某体会话的任何明 确或者隐含的媒体频道的选择。这意味着推迟实际的々某体内容/频道选 择直到已完成会话建立过程。
一旦已成功建立通用频道透明媒体会话，首先产生需要的々某体频 道和内容的通告。此时，在步骤S3，用户终端产生并且向媒体服务器 传输用于所需频道的频道具体呈现请求。首先，现在服务器知道用户 终端请求哪个特定媒体内容，因此开始使用经协商的传送机制传递所请求频道的媒体数据。在步骤S4中，当终端接收媒体数据时，它的媒
体播放器开始为其使用者在终端上呈现或者回放该内容。该数据呈现 一般包括在用户终端的显示屏上或者在连接到用户终端的显示屏上 显示视频内容，并且在终端的扬声器上或者连接到终端的扬声器上播 放音频内容。
然后本方法结束。下面，将结合图3到图5的信号框图更详细地说 明描述通用频道透明会话建立过程的不同情形。在这些框图中，媒体 会话作为RTSP会话执行并且因此在这些图中使用了这种RTSP请求和 响应的术语。本发明的教导仍然可适用于其它用于建立和管理基于单 播的媒体会话的协议。
图3是根据本发明的实施例图解执行通用频道透明媒体会话建立 过程的信号框图。通过向々某体服务器的通用频道透明会话请求消息的 传输发起该建立。此请求消息可以是DESCRIBE请求(如果使用的话) 或者SETUP请求。在此图以及其后的图中，已经使用了DESCRIBE请 求和响应，但是也可以把本发明用于没有这些请求和响应的过程。
DESCRIBE请求并不像本领域那样指定实际的频道(在图1A中的 RTSP:〃tv.com//channell.sdp , 以及在图 IB 中的 rtsp:/ /tv.com/channel2.sdp)。成明显对比的是，该请求在它通过来自媒体 服务器的基于单播的传递请求多个、优选为全部的可用媒体内容的描 述方面是通用的。
媒体服务器基于接收的DESCRIBE请求产生描述消息或者取预先 产生的这种消息。此DESCRIBE响应优选地具有SDP文件的形式或者 某种别的消息格式。此SDP文件包含可用媒体频道对其媒体内容的宣 告。符合先前列出的先有技术SDP文件的示例，在DESCRIBE响应中 返回的SDP文件可以具有下述形式
RTSP/2.0 200 OK
CSeq: 1
Date:"创建日期与时间" Content-Type: allchannels/sdp
19Content-Length:"文件长度" v=0
0="创建者"
i^'会话信息"
u-"描述的URT
t^'会话活动计时"
a=control:tv.com/allchannels.sdp/channell a=control:tv.com/allchannels.sdp / channel2
a=control :tv. com/allchannels.sdp/channelN
这意味着以多个会话控制行补充该SDP描述，其中每个这样的行 宣布可用媒体频道之一。在备选方法中，将新属性"altcontrol"(备选控 制)引入SDP文件中。这意味着保留控制属性用于向后兼容。
那么，在SDP文件中的对应媒体行可以看起来像
a=altcontrol: list channel 1
a=altcontrol: list channel2
a= altcontrol: list channelN
在这两个实施例中，媒体频道宣告可以具有所谓的汇聚控制 (aggregated control: AC) URI的形式。这样的AC URI涉及要在用户 终端一起呈现的视频内容和相关联的音频内容。在备选方法中，对于 包含视频和音频的媒体内容，可在control (控制)或者altcontrol (备 选控制)行中使用单独的URI，以用于每个可用媒体频道的两种媒体 类型。
在向后兼容的情况下，除altcontrol属性以外，还可以用控制属性 行补充SDP文件，即
a=control: defaultchannel a=altcontrol: list channel 1 a=altcontrol: list channel 2a=altcontrol: list channel
那么，默认频道可以是由媒体服务器选择的预先定义的默认频 道，并且对于那些不支持altcontrol属性的用户终端作为初始媒体频道 使用。在这样的情况下，这些用户终端可以用默认频道根据先有技术 继续会话建立过程。
为了引起信令回退(fallback),会话请求可以包括支持请求，无 论々某体服务器是否支持通用频道透明建立过程。这可以通过在由用户 终端传输的第一个DESCRIBE请求中使用具有要求头标(header)的 特征标记实现。因此，此头标能够包括新属性multiple-control-uris (多 控制URI):
DESCRIBE rtsp:〃tv.com/allchannels,sdp RTSP/2.0 Require: multiple-control-uris
如果服务器不支持通用建立过程，那么它可以错误信息、比如不 ;故支持的551 Option (选项)响应。
一旦用户终端接收到具有优选AC URI的描述消息，它就产生通用 频道透明传输或者建立请求消息。与结合图1A的论述一致，如果i某体 频道包含^L频和音频内容，那么优选地，对于如图3所示的两个内容 类型，编译并且发送通用频道透明建立请求。第一此类的通用频道透 明请求可以用于视频(音频)内容，而第二个请求则专用于音频(视 频)内容。优选地，这些请求指定用户终端可接受的传输参数，以供 随后的々某体传输。例如，它们包括用户终端输入^f见频和音频端口的通 告以及其它用于建立媒体会话所需要的传输参数。
此通用建立请求消息一般根据在媒体服务器的接收触发传送机 制的协商(提供-应答过程)以及会话标识符的产生。这样，媒体服务 器包括分别由服务器、产生的会话标识符以及输出视频和音频端口所 选择的、要在响应中用于随后的媒体传递的传输参数的信息。
因此，如果第一SETUP请求和响应涉及视频内容，则对于音频内 容优选重复此过程。如上所述， 一旦会话标识符已经产生并且通知了 用户终端，就把它优选地包括在随后的用户终端和媒体服务器间的通信中。
现在建立了本发明的通用频道透明媒体会话。这意味着已经选择 并通报了所需的输入和输出端口 ，已经协商了传输参数且已经产生会 话标识符。尽管已经没有要在会话中使用的特定媒体频道的任何规定 或选择地进行了所有这些过程。
在上文结合与图3所述的实施例中，在描述消息(DESCRIBE响应 的SDP文件)中向用户终端通报不同的可用媒体频道的AC URI。然而， 可能，这些URI、即媒体频道标识符在创建SDP文件时并不巳知。此 外，媒体频道的有效性可信赖于该日的时间或者可以不同于不同的 天。因此，固定的预先定义的SDP文件的使用将太不灵活而不能应对 此情形。那么，可能的解决方案可以是在媒体服务器接收DESCRIBE 响应的每个时间产生新的SDP文件。然而，这增加媒体服务器的数据 处理要求并且在媒体会话建立过程中引入更多延迟。
备选方法改为在SDP文件中使用通用模板(template)，然后在建 立过程中的稍后位置告知用户终端相应^ 某体频道URI。在图4和图5中 已采用了此方法。
图4是根据本发明的另 一实施例图解执行通用频道透明i某体会话 建立过程的信号框图。通过向媒体服务器的通用频道透明会话 (DESCRIBE)请求消息的传输发起该建立。根据此消息的接收，媒 体服务器提供SDP文件或者其它包含可用媒体频道的通用宣告的描述 消息。此宣告可结合以下控制属性使用
a=control:tv.com/allchannels/*
或者新的altcontrol属性
a=altcontrol: dynamic
这就发信号通知备选AC URI的目录在特定动作是动态的或者未 知的，且这要由其它方法提供。在增添的巴科斯范式(Bachus-Naur form: ABNF)语法中(参见文档[5]) ， SDP文件的会话部分可以写作
altcontrol-line = "a-altcontrol:" control-type [sp rtsp誦URI]
control-type = "list" / "dynamic" /tokenrtsp-URI = "specified as in RTSP 2.0"
还可以在SDP文件中提供各个控制行的实际含义，但可在描述单 播频道或者单播和广播频道的完整频道表中更好地定义。
剩余的SETUP请求和响应信令按在上文结合图3所述的方式相同 的通用频道透明方式执行。
然后，用户终端将编译并且发送用于在SDP文件中被动态/一般宣 布的AC URI的请求。可把此请求发给媒体服务器或者在通信系统中的 其它服务器或节点，所述通信系统具有对在媒体服务器的当前可用单 播J 某体频道的信息的访问及其各自的URI。例如，此请求可能具有规 则HTTP请求或者对完整频道表的请求的形式。媒体服务器或者其它 服务器/节点通过返回在媒体服务器的当前可用的基于单播的媒体频 道的URI的信息来响应此请求。
在另一方法中，通过从媒体服务器或者其它服务器或者节点的广 播或者多播传输执行UW通告。在图5中示意地图解此情形。在此信号 图中，单独的服务器控制器以广播/多播用户服务描述(user service description: USD)的形式执行ACURI通告。
媒体服务器已经预先通知服务器控制器它的不同的基于单播的 频道及频道的有效性和URI。
如前所述，本发明的通用频道透明媒体会话建立过程的执行不一 定必须通过DESCRIBE请求的传输发起。这在当前图中进一步图解， 如可省略的虚线框所示。因此，可以通过从用户终端的通用频道透明 SETUP请求消息的传输直接发起建立过程。其后的直到最后的SETUP 响应的信令类似于先前结合图3所述。
此时，通过来自服务器控制器的USD广播或者多播，将在媒体服 务器当前可用的士某体频道的AC URI通知用户终端。不一定必须在频道 透明建立过程的完成以后发送USD消息。这意味着用户终端可改为在 发起建立过程(不久)以前或者建立过程期间的某个时间已经接收 USD。在这种情况下，可把服务器控制器配置成在适合的时间间隔周期地广播或者多播USD。
本发明预期，在图3到图5中任意所公开的信令的组合可以使用且 处于本发明的范围内。例如，能够把URI通告组合到具有URI广播的 SDP文件，在该情况下可用々某体频道的更新是突出的。
媒体会话现在已经以通用频道透明方式建立，而没有任何在会话 期间用户终端实际上应该收听的媒体频道的选择。本发明的媒体频道 及其因而媒体内容选择首先在呈现请求、例如RTSP PLAY请求的编译 和发送发生，如图6所示。此PLAY请求包含所选士某体频道的标识符。 优选地，基于与所选媒体频道相关联且先前在用户终端所接收的通用 资源标志符(URI)产生该请求。优选地，呈现请求包含所选媒体频 道的AC而。
媒体服务器处理PLAY请求并且以确认的时间参数或者范围以及 同步信息响应，比如依据此响应的RTP信息域中的RTP时间。
然后，使用传送机制、在通用频道透明建立过程确定的到媒体内 容的输入和输出端口传输所请求的频道的媒体内容。
如果用户终端随后想切换到任何由媒体服务器所提供且先前已 向与建立有关的终端通报的其它基于单播的媒体频道的任何频道，那 么对于新的媒体频道，终端仅仅编译并且传输新的呈现请求、即PLAY 请求。此频道具体PLAY请求优选地基于新频道的ACURI产生，且更 优选地包含新频道的ACURI或者某些别的标识符。此外，在终端上， 基于例如按4建的按下、触摸感应屏或者一些其它输入行为的用户输入 产生PLAY请求。
媒体服务器以包括同步和时间信息的呈现响应答复。当PLAY响 应提供同步信息以及用于SSRC字段的值时，在终端的解码器可以开始 播放新频道并且识别数据包。使用服务器的相同输出端口将新频道的 J(某体内容传输至用户终端的相同输入端口 ，如用于先前的频道那样。 一^:保留在频道透明建立过程期间所确定的其它传输参数。
本发明预期，如第一PLAY请求优选包含的那样，第二PLAY请求优选包含在通用会话建立过程期间所分配的会话标识符。
在优选实施例中，为所有媒体流和频道发送新同步值(SSRC)。 来自媒体服务器的PLAY响应因此可能具有以下布局 RTSP/ 2.0 200 OK
RTSP-Info: URI="rtsp:〃tv.com/allchannels.sdp/audiotrack"
ssrc=0D12F123 : seq=5712 ; rtptime=93407921, URI="rtsp:〃 tv.com/allchannels.sdp/videotrack" ssrc=789DAF12 : seq=57654: rtptime=2792482193 因此，本发明的快速频道切换在正在进行的媒体会话、例如RTSP 会话内利用呈现请求、比如RTSP PLAY请求来请求新频道。所以， 在本发明的通用频道透明建立期间所协商和确定的所有那些参数也 可以保留用于新媒体内容的传递。这可与先有技术的切换相比较，在 先有技术的切换中，必须首先停止和拆卸当前RTSP会话，在将新频道 的媒体内容交付并呈现于用户终端以前，必须建立全新的频道具体 RTSP会话。通过将图6与图1A和1B的情况相比较，4艮明显，与该信令 有关的处理和大约6次的往返对于切换媒体频道不再是必需的。因此， 本发明的频道切换比先有技术的切换更快。
本发明的呈现请求的实际设计不是决定性的。 一个示例可如下
PLAY rtsp:〃tv.com/allchannels.sdp/channe12 RTSP/2.0
其中，"tv.com/allchannels.sdp/channel2"是媒体频道号2的AC URI。
备选方法要使用 PLAY rtsp:〃tv.com/allchannels.sdp channeH2 RTSP/2.0 其中，查询部分被用于基(base) URI "tv.com/allchannels.sdp"以
及"2"是所请求的频道的标识符。
对每一媒体频道，优选使用ACURI代替使用唯一的URI，能够对 于所有基于单播的媒体频道使用同样的URI但要增加某些信息以区别 频道。例如，可以引入新头标。在这样的情况中，PLAY请求可以如 下
PLAY rtsp:〃tv.com/allchannels.sdp RTSP/2.0x-channel:"所请求频道的标识符"
标识符可以仅仅是数值l、 2、 3等，或者包括MBMS用户服务标 识符的其它名称或者标识符。
与先有技术相比，除了减少的切换时间以及更少的往返和与切换 有关的处理之外，本发明的频道切换还具有其它优势。本发明可用于 在单播频道和广播/多播频道之间提供转换，反之亦然。
如果用户想要从当前基于单播的频道切换到广播频道，那么暂时 中止当前媒体内容的传递。图7是提供这样的单播-广播过渡时机的本 发明实施例的信号框图。
一旦用户终端接收到切换到广播频道的用户输入，终端就编译呈 现暂停请求、例如RTSP PAUSE (暂停)请求。此请求是传统的PAUSE 请求，如结合图1A所述。媒体服务器通过暂停当前基于单播的频道的 媒体数据的发送响应，并且优选地用PAUSE答复或者响应答复。
然后，用户终端开始收听广播频道并且接收该频道的媒体数据。 此广播频道可以由通信系统中的同 一媒体服务器或者其它媒体服务 器提供。
如果用户随后想返回收听先前基于单播的媒体频道或者收听由 该媒体服务器提供的另 一基于单播的频道，那么用户终端编译并且向 媒体服务器传输新的频道具体呈现请求、即PLAY请求。媒体服务器 以PLAY响应答复，并且使用预先协商的传送机制和端口将所选基于 单播的频道的媒体数据传输到用户终端。
这意味着在到广播频道的临时切换期间没有终止基于单播的媒 体会话。相反，会话在休眠(dormant)并且依据新的呈现请求又变成 活动的。
如果用户终端在切换期间的短时间并行接收两个媒体数据流，那 么对于相同内容，可使从单播到广播访问的切换或者从广播到单播访 问的切换无缝。这意味着在此短时期内，用户终端即从旧的(单播或 者广播)频道又从新的(单播或者广播)频道接收媒体内容。那么，用户终端将在RTP緩沖以前切换来源。
为了使这样的无缝转换可靠，优选地，单播和广播之间的传输延 迟小。最佳地，这两个流相同或者完全同步。在这样的情况中，可以 在流中的任何地方进行切换。否则， 一般在用户终端中在短时期内并 行接收来自两个流的媒体内容，并且切换发生在帧内。这降低了漏失 ^H 某体数据的数据包的风险。
由媒体服务器提供的不同的单播和广播频道可以使用不同的编 码和编解码器设置。这可以通过、例如在描述文件(SDP文件)中描
述不同的编码/设置来解决，并且供给他们不同的有效载荷类型值。根 据频道切换，用户终端将在接收新频道的数据包时匆忙(on the fly) 切换解码器配置。也能够对不同的基于单播的频道使用不同的编码。
本发明也非常灵活，因为它能够对于单播和广播使用同一媒体流 而不改变任何RTP头标域。这尤其与流的相同密码的使用结合，简化 了在正在进行的媒体会话期间从单播到广播的无缝转换。
即使用户首先想要收听广播频道，也可执行本发明的通用频道透 明建立过程。这意味着，单播媒体会话建立了但接着休眠了，直到用 户终端停止收听广播频道并且向媒体服务器传输PLAY请求。这意味
着本发明的第一频道具体呈现请求不一定必须在频道透明建立过程 的完成滞后直接传输。改为， 一旦用户想要从广播频道切换到单播频 道，就首先发送呈现请求。
如果用户终端随后想结束当前媒体会话，执行先前描述的具有 PAUSE和TEARDOWN (拆卸)请求和响应的过程。
优选地，在所有随后通信的请求和响应中，由媒体服务器和用户 终端使用媒体服务器优选地产生的、与(第一)通用频道透明SETUP 请求的接收有关的会话标识符。这意味着，优选把会话标识符包含在 随后的用于切换单播频道的呈现请求中。另外，在用户终端的广播频 道的暂时收听之后恢复媒体会话的呈现请求也优选地包含此会话标 识符。本发明的通用频道透明会话建立过程不一定必须遵循结合图3到 图6所描述的信令。在备选方法中，RTSP请求和答复的流水线操作是 可能的。在这样的情况中，用户终端编译并且传输频道透明的^L频和 音频SETUP请求，接着是频道具体PLAY请求。这意味着终端在传输 下一个以前不等待对先前传输的请求的任何答复。媒体服务器以接连 地或者实际上一起地发送一见频SETUP响应、音频SETUP响应以及 PLAY响应来响应。然后，向用户终端递送首先在PLAY请求所请求的 媒体频道的媒体数据。
在此流水线操作的实施例中，在频道透明建立过程已经结束且所 请求的々某体频道已经请求以后，首先向用户终端通报会话标识符。为 了识别用户终端以及当前会话，终端优选地产生唯一的临时标识符并 且将其包括在SETUP以及PLAY请求中。这允许媒体服务器确定这些 请求发起于一个和同一用户终端。 一旦终端已经从媒体服务器、典型 地在第 一个SETUP答复中接收到会话标识符，它就要在切换媒体频道 时在任何随后的PLAY请求中使用此会话标识符替代临时标识符。
图8是根据本发明实施例的基于单播的无线通信系统l的示意概 图。通信系统1包含向已连接的用户终端10、 100传输媒体内容的基站 或者网络节点20。基站20包含或者连接至本发明的媒体服务器200， 该媒体服务器具有多个可用的基于单播的媒体频道。在该图中，第一 用户终端100收听这些基于单播的媒体频道之一。但是，另两个用户 终端10收听在々某体服务器200也是可用的广播频道。
图9是根据本发明实施例的用户终端100的示意框图。用户终端 100包含发射机和接收机或者收发器IIO，在图中作为单个单元示意 示出。单元110包括传统的发射才几/接收^L功能，比如调制器/解调器、 编码器/解码器等。
发射机110适合于向媒体服务器传输在频道透明会话建立过程期 间的通用频道透明请求，频道具体呈现请求指示^ 某体传递和/或频道切 换的开始。接收机110适合于接收对由发射机链110所发送的请求的响应且当然也接收来自媒体服务器的成流的4某体数据。
用户终端100包含会话建立管理器140，该管理器构成用于与媒体 服务器执行通用频道透明基于单播的会话建立过程的装置。该建立管 理器140因此编译由发射机110发送给媒体服务器的频道透明请求消 息，并且处理由接收机110所接收的相应的响应消息。频道透明建立 过程包括在用户终端IOO与服务器之间的信息交换，但是不包括要使 用的媒体频道的明确选择直到会话建立。管理器140基于由发射机发 送的、通用频道透明会话请求(DESCRIBE或者SETUP请求)与媒体 服务器执行此建立过程。
一旦建立管理器140已与媒体服务器完成频道透明建立过程，就 在用户终端中执行呈现或者播放请求产生器135以编译频道具体呈现 请求。请求消息包含所选々某体频道的标识符，例如ACURI或者其它频 道标识符。把经编译的呈现请求转送到IIO，发射机又把它转送到媒 体服务器用于开始媒体传递。
一般通过终端100的用户输入(未示出)激活建立管理器140和请 求发生器135。这将引起本发明的请求消息的产生及其向媒体服务器 的传输。
通过在到另 一基于单播的频道的切换期间触发或激活用户输入， 或者依据在广播频道收听的临时时段之后返回收听基于单播的频道， 也把请求发生器135激活。因此，在正在进行的会话期间的频道切换， 请求发生器135对新媒体频道编译呈现请求，该请求优选包含此频道 的标识符。相应地，在到广播收听的切换，播放请求发生器135编译 由发射机110发送到Jf某体服务器的呈现暂停请求。如果用户再想返回 先前的基于单播的频道或者另一此类基于单播的媒体频道，那么请求 发生器135形成具有那个媒体频道的标识符的频道具体呈现请求。
可在多媒体或者用户终端100的媒体播放器130中执行请求发生 器135。媒体播放器130优选地与终端100的显示屏120和的扬声器160 通信，以用于在其上显示和播出媒体。可在用户终端100中执行可选的媒体緩存器150,以用于在由媒体 播放器130在屏幕120和/或扩音器160呈现所接收的媒体数据以前将其 暂时存储。在频道切换的情况下、尤其对于单播到广播或者广播到单 播的切换緩存器150有用，因为可以并行接收两个媒体流并且将其存 储在緩存器150中以允许无缝的频道转换。
可以软件、硬件或其组合提供用户终端100的单元110、 130、 135 以及140。可在如本图所示的媒体播放器130中或者在终端100中的另 一位置实现播》文请求发生器135 。
图10是图9的用户终端的会话建立管理器140的实施例的示意框 图。建立管理器140可选地、但优选地包含用于产生频道透明描述请 求的单元141。该DESCRIBE请求发生器141编译先前已讨论的、可构 成本发明通用频道透明会话请求消息的频道透明DESCRIBE请求。
产生的DESCRIBE响应由可选的、但是优选的描述消息处理器142 处理。该处理器142检索(retrieve)在媒体服务器可用的多个媒体频 道的宣告。在此情况下，把频道的URI或者其它标识符包括在描述消 息中，处理器142检索这些标识符并且将它们转送给用户终端的呈现 请求发生器。
在建立管理器140中提供用于组成本发明频道透明的视频SETUP 请求的视频建立请求发生器143。该SETUP请求优选地包含用户终端 可接受的那些(视频)传输参数的信息，包括终端的输入视频端口。 在实施例中，该;现频SETUP请求构成本发明的通用频道透明会话请 求。
建立请求管理器140也包括^L频建立消息或者响应处理器144,用 于处理来自媒体服务器的视频SETUP响应。这意味着处理器144检索 媒体服务器的视频输出端口的信息以及媒体服务器已经选择的那些 视频传输参数。把此信息转送到终端的发射机/接收机单元以供在随后 的媒体数据接收期间使用。
优选地在建立管理器140中实现对应的音频建立请求发生器145,以用于产生频道透明的音频SETUP请求。该建立请求包括用户终端可 接受的那些(音频)传输参数的信息，包括终端的输入音频端口。在 实施例中，该音频建立请求构成本发明通用频道透明会话请求。
管理器140包括音频建立响应或者消息处理器146。该处理器146 处理由终端接收机接收的、并由发生器145响应音频SETUP请求发生 器产生的、且由终端发射机发射的音频SETUP响应。处理器146尤其 检索由媒体服务器选择的音频传输参数以及用于音频内容的输出端 口的信息。也把此信息转送到终端的接收机，以便在媒体接收期间使 用。
由本发明可预期，；规频建立发生器143和处理器144或者音频建立 发生器145和处理器146可以从建立管理器140中忽略。在此情况下， 媒体内容将仅包含音频内容或者视频内容。然而，对于多数典型实施
例，在建立管理器140中要求并执行视频和音频发生器/处理器143、 144、 145、 146。
要是频道标识符没有包含在由描述答复处理器142处理的描述消 息中或者没有接收到这样的描述响应，则建立管理器140优选地利用 可选的但是优选的标识符请求发生器147。该发生器147对在々某体服务 器可用的基于单播的频道标识符形成请求消息。 一般把所产生的消息 传输到服务器，但是可备选地传输到可以访问此信息的其它网络节 点。
把来自媒体服务器或者其它节点的响应消息从终端接收机转送 到建立管理器140的标识符响应处理器148。该处理器148检索媒体频 道的信息，该信息一般以URI的形式并优选地以AC URI的形式包含在 答复中。然后，^fe标识符信息转送到呈现请求发生器并且当形成频道 具体呈现请求时由发生器使用。
如果通过广播或者多播传输通报频道标识符，那么配置标识符消 息处理器148用于处理接收的广播/多播信息并且从其中^r索频道标识 符信息。会话建立管理器140的单元141到148可以软件、硬件或其组合提 供。单元141到148可以在建立管理器140中一起实现。把某些单元设 置在用户终端中其它地方的分布式的实现也是可能的。
图1 l是根据本发明的媒体服务器200的示意框图。媒体服务器200 包括安排来与外部单元进行通信并处理输入和输出消息的发射机和 接收机单元210。特别地，执行发射机210用于向用户终端传输响应消 息和包含媒体数据的数据包。特别地，执行接收机210用于接收来自 用户终端的请求消息。
媒体服务器200包括或者可以访问多个媒体频道400、 410。这意 味着服务器200可以包括或者连接至存储有预先录制的媒体内容的数 据库。备选地，或者此外，媒体源可为在媒体服务器200所接收的实 况媒体内容的形式，用于进一步向请求终端的传输。执行该服务器200 的媒体管理器230用于负责正确的媒体处理，例如为不同终端选择正 确的媒体内容、用媒体内容产生数据包。
媒体服务器200还包括会话建立管理器220,该管理器220构成用 于与用户终端执行通用频道透明基于单播的会话设置过程的装置。根 据由从终端发起的通用频道透明会话请求的接收机触发建立管理器 220。建立管理器220产生频道透明响应消息，并分别处理由发射机210 发送到用户终端并由接收机21 O从终端接收的频道透明请求消息。
一旦完成了频道透明会话建立过程，并且接收机210接收频道具 体呈现请求，则此请求被带到媒体管理器230。纟某体管理器230基于该 请求中的频道标识符识别正确的媒体频道，并且向发射机210转送该 频道的媒体内容。发射机使用由会话建立管理器220协商的传送机制 向终端转送数据内容。
如果接收机210随后从终端接收新的频道具体呈现请求，则媒体 管理器230将在处理该请求以后把媒体内容的传递从先前的媒体频道 切换到新请求的频道。
暂停请求的接收将触发媒体管理器230以便暂时停止向发送请求的终端提供々某体内容。如果稍后接收到新的频道具体呈现请求，则管
理器230将向发射机210提供那个频道的媒体数据内容，用于正在进行 的会话期间的向用户终端的传递。
图5示意性地图解单独的服务器控制器300的使用，该服务器控制 器可在无线、基于射频的通信系统中使用，用于传输可来自于媒体服 务器200的单播(以及广播)频道的标识符。该控制器300已在图11中 示出。在此情况下，该控制器300优选地包括用于产生包含此标识符 信息的消息的标识符管理器320。然后，控制器300的发射机310向相 应终端一般以组播或者广播传输的形式发送消息。
依靠发射机310，标识符管理器320还可以询问媒体服务器200媒 体频道的信息，包括频道的标识符和有效性。
服务器控制器300可以连接到并包括来自安装在通信系统中的若 干不同媒体服务器200的频道信息。
可以软件、硬件或其组合提供媒体服务器200的单元210到230。 在单网络节点中，可在服务器200中一起实现单元210到230。可把某 些单元设置在网络中的不同节点中的分布式实现也是可能的。关于软 件/硬件实现的相同论述也适用于服务器控制器300的单元310和320。
图12是图11中的媒体服务器的会话建立管理器220示意框图。建 立管理器220可选地、但是优选地包括用于处理来自用户终端的频道 透明请求的描述请求处理器221。处理器221—般识别发起请求的终 端，并且通知可选的、但是优选的描述响应或消息发生器222。发生 器编译先前已论述的、包含在媒体服务器可用的媒体频道的通告的 DESCRIBE响应。该通告可以是频道的URI或者实际标识符或者可以 被终端选择的多个频道的通知，在通知的情况下将分开通告频道的标 识符。
视频建立请求处理器223和音频建立请求处理器225处理所接收 的视频和音频SETUP请求。处理器223、 225选择包括要用于会话的输 出视频和音频端口的传输参数。把该信息既转送到媒体服务器的发射机以用于即将来临的媒体传递，又转送到各自的^L频建立响应发生器 224和音频建立响应发生器226。发生器224编译各自的包含输入传输 参数的视频和音频建立响应，用于向终端的传输。视频SETUP响应发 生器224优选地也包括会话标识符，该会话标识符在J 某体服务器产生 的，并包含在在服务器和用户终端之间交换的所有随后的响应和请求 中。
如果描述响应发生器222不把媒体频道标识符包括在描述响应 中，那么建立管理器220可以利用可选的标识符消息发生器228。该发 生器228形成包含当前在服务器可用的基于单播的媒体频道的标识 符、比如ACURI的消息。可依据来自用户终端的明确请求的接收操作 发生器228。备选地，产生的消息可由服务器广播或者多播到多个终 端。
可以软件、硬件或其組合提供会话建立管理器220的单元221到 228。单元221到228可在建立管理器220中一起实现。把某些单元设置 在媒体服务器中其它地方的分布式实现也是可能的。
本领域技术人员要理解，在没有脱离本发明范围下可对本发明做 各种修改和变化，本发明的范围由随附的权利要求书定义。
参考文献 WO 2006/096104 3GPP TS 26.234 v7丄0; 3rd Generation Partnership Project; Technical Specification group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs, December 2006 Network Working Group, Request for Comments: 2327, April 1998, SDP: Session Description Protocol Network Working Group, Request for Comments: 2326, April 1998， Real Time Streaming Protocol (RTSP) Network Working Group, Request for Comments: 4234, October 2005, Augmented BNF for Syntax Specifications: ABNF
权利要求
1. 一种管理包括用户终端(100)和提供多个媒体频道的媒体服务器(200)的基于单播的媒体会话的方法，所述方法包括以下步骤所述用户终端(100)向所述媒体服务器(200)传输通用频道透明会话请求；所述用户终端(100)与所述媒体服务器(200)并基于所述会话请求执行通用频道透明媒体会话建立过程；以及一旦完成了所述通用频道透明媒体会话建立过程，所述用户终端(100)就向所述媒体服务器(200)传输对所述多个媒体频道的第一媒体频道的频道具体呈现请求。
2. 如权利要求l所述的方法，其中，所述执行步骤包括 所述用户终端(100)与所述媒体服务器(200)并基于所述会话请求执行包括在所述用户终端(100)和所述媒体服务器(200)之间 的信息的交换的所述通用频道透明媒体会话建立过程，而没有任何要 用于所述媒体会话的媒体频道的明确选择。
3. 如权利要求1或2所述的方法，其中，所述执行步骤包括 所述用户终端(100)从所述媒体服务器(200)接收基于所述会话请求所产生的通用频道透明会话描述消息，所述通用频道透明会话 描述消息包括所述多个媒体频道的通告。
4. 如权利要求1到2中任意项所述的方法，其中，所述执行步骤包括所述用户终端(100)向所述士某体服务器(200)传输通用频道透 明建立请求消息；以及所述用户终端(100 )接收来自所述媒体服务器(200 )且基于所 述建立请求消息产生的、包括用于所述々某体会话的至少一个通信端口 的信息的通用频道透明建立消息。
5. 如权利要求1到4中任意项所述的方法，其中，所述执行步骤包括所述用户终端(100)向所述媒体服务器(200)传输对用于所述 多个媒体频道的每个媒体频道的唯一媒体资源标识符的标识符请求， 所述方法还包括所述用户终端(100)基于与所述第一媒体频道关联的唯一媒体 资源标识符产生所述呈现请求。
6. 如权利要求1到5中任意项所述的方法，其中，所述执行步骤包括所述用户终端(100)接收用于所述多个媒体频道的每个媒体频 道的唯一媒体资源标识符，所述方法还包括所述用户终端(100)基于与所述第一媒体频道关联的唯一媒体 资源标识符产生所述呈现请求。
7. 如权利要求1到6中任意项所述的方法，其中，所述传输步骤包括一旦完成了通用频道透明媒体会话建立过程，所述用户终端 (100)就向所述媒体服务器(200)传输包括与所述第一媒体频道关 联的唯一纟某体资源标识符。
8. 如权利要求1到7中任意项所述的方法，还包括 在所述媒体会话期间所述用户终端(100)向所述媒体服务器(200 )传输对所述多个々某体频道的第二媒体频道的频道具体呈现请 求以便从所述第一媒体频道切换到所述第二媒体频道。
9. 如权利要求1到8中任意项所述的方法，还包括 所述用户终端(100)向所述媒体服务器(200)传输呈现暂停请求，以暂停来自所述媒体服务器的所述第一媒体频道的媒体数据的接 收；以及在所述媒体会话期间所述用户终端(100)向所述媒体服务器 (200 )传输对所述多个媒体频道的媒体频道的频道具体呈现请求以 便恢复媒体数据的接收。
10. —种管理包括用户终端(100)和提供多个媒体频道的媒体服 务器(200)的基于单播的媒体会话的方法，所述方法包括以下步骤所述媒体服务器(200)从所述用户终端(100)接收通用频道透 明会话请求；所述々某体服务器(200)与所述用户终端(100)并基于所述会话 请求执行通用频道透明媒体会话建立过程；以及一旦完成了所述通用频道透明媒体会话建立过程，所述媒体服务 器(200 )就向所述用户终端(100)并基于发起于所述用户终端(100 ) 的且被接收的、对所述多个媒体频道的第一媒体频道的频道具体呈现 请求，传输第一媒体频道的媒体数据。
11. 如权利要求10所述的方法，其中，所述执行步骤包括 所述々某体服务器(200)与所述用户终端(100)并基于所述会话请求执行包括所述媒体服务器(200)和所述用户终端(100)之间的 信息的交换的所述通用频道透明媒体会话建立过程，而没有要用于所 述媒体会话的媒体频道的任何明确选择。
12. 如权利要求10或11所述的方法，其中，所述执行步骤包括 所述媒体服务器(200)基于所述会话请求产生包括所述多个媒体频道的通告的通用频道透明会话描述消息；以及所述媒体服务器(200)向所述用户终端(100)传输所述通用频 道透明会话描述消息。
13. 如权利要求10到12中任意项所述的方法，其中，所述执行步 骤包括所述媒体服务器(200)基于从所述用户终端(100)所接收的通用频道透明建立请求消息产生包括要用于所述媒体会话的至少一个 通信端口的信息的通用频道透明建立消息；以及所述媒体服务器(200)向所述用户终端(100)传输所述通用频 道透明建立消息。
14. 如权利要求3或13所述的方法，其中，所述通告包括用于所述多个媒体频道的每个媒体频道的唯一媒体资源标识符。
15. 如权利要求10到14中任意项所述的方法，其中，所述执行步 骤包括所述媒体服务器(200)向所述用户终端(100)传输用于所述多 个媒体频道的每个媒体频道的唯一媒体资源标识符。
16. 如权利要求10到15中任意项所述的方法，还包括 在所述媒体会话期间，所述媒体服务器(200)向所述用户终端(100)并基于对发起于所述用户终端(100)的、对所述多个媒体频 道的第二媒体频道的频道具体呈现请求，传输所述第二媒体频道的々某体数据。
17. 如权利要求10到16中任意项所述的方法，还包括 所述媒体服务器(200)基于发起于所述用户终端(100)的呈现暂停请求暂停向所述用户终端(100)的所述第一媒体频道的所述媒 体数据的传输；以及所述媒体服务器(200)向所述用户终端(100)并基于发起于所 述用户终端(100)的、对所述多个媒体频道的媒体频道的频道具体 呈现请求，传输所述请求的媒体频道的媒体数据。
18. 如权利要求1到17中任意项所述的方法，其中，所述基于单^番 的媒体会话是实时流媒体协议(RTSP)会话。
19. 一种在基于单播的媒体会话中切换媒体频道的方法，所述媒 体会话包括从提供第一媒体频道和第二媒体频道的媒体服务器(200 ) 接收所述第一媒体频道的媒体数据的用户终端(100),所述方法包 括所述用户终端(100)在所述正在进行的基于单播的媒体会话期间 向所述媒体服务器(200)传输对所述第二^ 某体频道的频道具体呈现 请求。
20. 如权利要求19所述的方法，其中，所述传输步骤包括 所述用户终端(100)向所述媒体服务器(200)传输包括与所述正在进行的基于单播的媒体会话关联的、且在所述基于单播的媒体会话的建立期间所分配的会话标识符的频道具体呈现请求。
21. 如权利要求19或20所述的方法，还包括所述用户终端(100)在与所述用户终端(100)用于接收所述第 一媒体频道的媒体数据所使用的输入端口相同的输入端口上接收所 述第二媒体频道的媒体数据。
22. —种用户终端(100)，包括发射机(110)，用于向提供多个媒体频道的媒体服务器(200) 发送通用频道透明会话请求；以及装置(140)，用于与所述i某体服务器(200)并基于所述会话请 求执行通用频道透明基于单播的媒体会话建立过程，其中，设置所述 发射机(110)用于一旦所述执行装置已经完成所述通用频道透明媒 体会话建立过程就向所述媒体服务器(200)传输对所述多个媒体频 道的第一J 某体频道的频道具体呈现请求。
23. 如权利要求22所述的用户终端，其中，所述执行装置(140) 包括描述消息处理器(142)，用于处理发起于所述々某体服务器(200 ) 且基于所述会话请求所产生的通用频道透明会话描述消息以检索所 述多个媒体频道的通告。
24. 如权利要求22或23所述的用户终端，其中，所述执行装置 (140)包括建立请求发生器(143、 145 ),用于产生去往所述纟某体服务器(200 ) 的通用频道透明建立请求；以及建立信息处理器(144、 146)，用于处理发起于所述媒体服务器 (200)并基于所述建立请求所产生的通用频道透明建立消息，所述 通用频道透明建立消息包括在所述媒体会话期间要由所述用户终端 (100)的接收机(110)所使用的至少一个通信端口的信息。
25. 如权利要求22到24中任意项所述的用户终端，其中，所述执 行装置(140 )包括标识符消息处理器(148)，用于从标识符消息检索用于所述多 个媒体频道的每个媒体频道的唯一媒体资源标识符，所述用户终端 (100)还包括呈现请求发生器(135),用于基于与所述第一媒体频道关联的 唯一i某体资源标识符产生所述呈现请求。
26. 如权利要求22到25中任意项所述的用户终端，其中，设置所 述发射机(110)用于一旦所述执行装置(140)已经完成所述通用频 道透明媒体会话建立过程就向所述媒体服务器(200)发送包括与所 述第一媒体频道关联的唯一媒体资源标识符的所述频道具体呈现请求。
27. 如权利要求22到26中任意项所述的用户终端，其中，设置所 述发射机(110)用于在所述媒体会话期间向所述媒体服务器(200) 发送对所述多个媒体频道的第二媒体频道的频道具体呈现请求，以便 从所述第 一媒体频道切换到所述第二媒体频道。
28. 如权利要求22到27中任意项所述的用户终端，其中，设置所 述发射机(110 )用于在所述媒体会话期间i )向所述媒体服务器(200 ) 发送呈现暂停请求以暂停来自所述媒体服务器(200)的所述第一媒 体频道的媒体数据的接收，以及ii)向媒体服务器(200)发送对所 述多个媒体频道的媒体频道的频道具体呈现请求以便恢复媒体数据 的接收。
29. —种用户终端(100),包括频道开关(135),用于在正在进行的基于单播的媒体会话期间 切换媒体频道，设置所述频道开关用于产生对新媒体频道的频道具体 呈现请求；以及发射机(110),用于向给所述用户终端(100)提供当前媒体频 道并且具有对所述新媒体频道的访问的媒体服务器(200)发送所述 频道具体呈现请求。
30. —种提供多个媒体频道的媒体服务器(200)，所述媒体服务器(200 )包括接收机(210 )，用于从用户终端(100 )接收通用频道透明会话请求；装置(220),用于与所述用户终端(100)并基于所述会话请求 执行通用频道透明基于单播的媒体会话建立过程；发射机(210)，用于一旦所述执行装置(220)已经完成通用频 道透明々某体会话建立过程就向所述用户终端(100)并基于发起于所 述用户终端(100)并由所述接收机(210)所接收的、对所述多个媒 体频道的第 一媒体频道的频道具体呈现请求，发送所述第 一媒体频道 的媒体数据。
31. 如权利要求30所述的媒体服务器，其中，所述执行装置(220) 包括会话描述消息发生器(222)，用于基于所述会话请求产生包括 所述多个媒体频道的通告的通用频道透明会话描述消息，其中，设置 所述发射机(210)用于向所述用户终端(100)发送所述通用频道透 明会话描述消息。
32. 如权利要求30或31所述的媒体服务器，其中，所述执行装置 (220)包括建立消息发生器(224、 226)，用于基于从所述用户终端(100) 所接收的通用频道透明建立请求消息产生包括要用于所述媒体会话 的至少一个通信端口的信息的通用频道透明建立消息，其中，设置所 述发射机(210)用于向所述用户终端(100)发送所述通用频道透明 建立消息。
33. 如权利要求30到32中任意项所述的媒体服务器，其中，设置 所述发射机(210)用于在所述々某体会话期间向所述用户终端(100) 并基于发起于所述用户终端(100)的、对所述多个媒体频道的第二 媒体频道的频道具体呈现请求发送所述第二媒体频道的媒体数据。
34. 如权利要求30到33中任意项所述的媒体服务器，其中，设置所述发射机(210)用于i)基于发起于所述用户终端(100)的呈现 暂停请求暂停向所述用户终端(100)的所述第一媒体频道的所述媒 体数据的发送，以及ii)向所述用户终端(100)并基于发起于所述 用户终端(100)的、对所述多个媒体频道的媒体频道的频道具体呈 现请求发送所述所请求的媒体频道的媒体数据。
35. —种网络节点(20)，所述网络节点(20)包括依照权利要 求30到34中任意项所述的々某体服务器(200)。
全文摘要
本发明的媒体会话管理包括具有对多个基于单播的频道的访问的媒体服务器(200)和用户终端(100)。用户终端(100)产生并向所述服务器(200)传输通用频道透明会话请求。此请求发起终端(100)和服务器(200)之间的通用频道透明媒体会话建立过程。该建立过程包括请求和响应的交换，但是在服务器(200)仍没有选择或者通知媒体频道。一旦完成了频道透明建立，用户终端(100)就向服务器(200)发送对需要的媒体频道的频道具体呈现请求。在随后的频道切换中，终端(100)在正在进行的会话期间仅向所述服务器(200)传输对新频道的新频道具体请求，并且再使用频道透明建立过程的经协商的传输参数。
文档编号H04N7/24GK101473654SQ200780022592
公开日2009年7月1日 申请日期2007年5月4日 优先权日2006年6月19日
发明者M·韦斯特伦德, T·埃纳森, T·洛马, U·霍恩 申请人:艾利森电话股份有限公司