CN101473654A - 媒体频道管理 - Google Patents

媒体频道管理 Download PDF

Info

Publication number
CN101473654A
CN101473654A CNA2007800225925A CN200780022592A CN101473654A CN 101473654 A CN101473654 A CN 101473654A CN A2007800225925 A CNA2007800225925 A CN A2007800225925A CN 200780022592 A CN200780022592 A CN 200780022592A CN 101473654 A CN101473654 A CN 101473654A
Authority
CN
China
Prior art keywords
media
channel
user terminal
request
session
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CNA2007800225925A
Other languages
English (en)
Other versions
CN101473654B (zh
Inventor
T·埃纳森
U·霍恩
T·洛马
M·韦斯特伦德
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of CN101473654A publication Critical patent/CN101473654A/zh
Application granted granted Critical
Publication of CN101473654B publication Critical patent/CN101473654B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23424Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for inserting or substituting an advertisement
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4383Accessing a communication channel
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4383Accessing a communication channel
    • H04N21/4384Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44016Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for substituting a video clip
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64Addressing
    • H04N21/6408Unicasting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • H04N21/6437Real-time Transport Protocol [RTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server
    • H04N21/6587Control parameters, e.g. trick play commands, viewpoint selection

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本发明的媒体会话管理包括具有对多个基于单播的频道的访问的媒体服务器(200)和用户终端(100)。用户终端(100)产生并向所述服务器(200)传输通用频道透明会话请求。此请求发起终端(100)和服务器(200)之间的通用频道透明媒体会话建立过程。该建立过程包括请求和响应的交换,但是在服务器(200)仍没有选择或者通知媒体频道。一旦完成了频道透明建立,用户终端(100)就向服务器(200)发送对需要的媒体频道的频道具体呈现请求。在随后的频道切换中,终端(100)在正在进行的会话期间仅向所述服务器(200)传输对新频道的新频道具体请求,并且再使用频道透明建立过程的经协商的传输参数。

Description

媒体频道管理
技术领域
本发明一般涉及通信系统中媒体会话的管理,并且特别涉及在这样的媒体会话中减少切换媒体频道(media channel)的用户察觉时间。
背景技术
在现有移动网络和移动通信系统中提供和供应大范围的新业务已成为趋势。目前对于使用移动网络用于多媒体或者电视内容存在很大的兴趣。在本技术领域这经常被称为移动电视。移动电视应用的目的是提供类似电视的体验,用户可以选择并且轻易地在不同的多媒体或者电视频道之间快速移动。
普通的电视频道被广播给以许多用户,并且典型地用户可以选择接收和观看哪个频道。类似地移动电视向若干终端用户发送一组(实况的)媒体或者多媒体流。每个多媒体流对应一个电视频道,并且每个用户将能够选择观看哪个频道。此刻,用于移动电视的广播/组播传送方法处于开发中。这样的标准化努力的例子是3GPP多媒体广播/组播服务(MBMS)以及欧洲电信标准协会(ETSI)手持式数字视频广播(DVB-H)。这些标准在其广播分配方式方面类似于传统TV。
同时,直到基于组播/广播的移动电视可用,存在对可以在现有移动传输频道上实现的解决方案的需求。稍后对于单播传输是优选分配方法的具有足够容量的网络和具有少数用户的蜂窝也将具有很大的兴趣。
在基于网络的网际协议(IP)上使用流的类似移动电视的服务可以在现有移动网络中实现。例子是在3GPP中开发的包交换(PS)流媒体服务(Packet-Switched Streaming Service:PSS)。为了开始这样的多媒体或者电视会话,用户一般冲浪到网页或者入口并且点击或者选择链接来观看流媒体直播频道。
还存在几个可用于移动电视的专有流媒体解决方案,例如RealNetworks(真实网络)、Apple的Quicktime(迅时)和Microsoft的media player(媒体播放器)。这些解决方案还一般具有点击链接以开始接收某个频道的入口或者网页。
移动电视服务的目标之一是能够在频道之间快速移动,如同某人可对通用的广播电视频道所做那样。如果将全部频道广播,接收机可以通过选择适当的传输频道以及使用适当的多路输出选择器在本地在频道之间选择。这是对于有线、卫星或者地面电视和即将出现的移动标准MBMS和DVB-H的情况。然而,对于单播会话,客户端必须改为影响"服务器"或者多媒体提供者以发送想要的频道。
执行基于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信令处理以及内容的缓冲。
为了补救这个缓慢的过程,已经开发了更快的解决方案[1],其中每个用户具有连续的流媒体会话并且可以通过在HTTP(HypertextTransfer Protocol:超文本传输协议)或其它协议上的单独信令来启动频道切换。
发明内容
在文献[1]中提出的过程的局限性是必须按相同方式编码全部频道以使能够对每个媒体流进行一个连续RTP(实时传输协议)会话。
本发明克服了先有配置的技术的这些和其它的缺点。
本发明的一般目的是提供有效的媒体会话管理。
本发明的特定目的是提供允许短的频道切换时间的媒体会话管理。
如随附专利权利要求书所定义的本发明满足这些以及其他目的。
简言之,本发明包括基于单播的媒体会话管理,该媒体会话管理包括用户终端和具有多个基于单播的媒体频道的访问的媒体服务器。通过从用户终端到媒体服务器的通用频道透明会话请求的传输发起通用频道透明会话建立过程。该建立过程包括在用户终端和服务器之间以频道透明请求和响应的形式的信息交换。然而,在此建立过程期间不选择媒体频道。这意味着媒体服务器仍然不知道终端想收听什么频道以及服务器应该发送什么媒体内容给用户终端。
首先,在完成建立过程时,终端以对此频道的频道具体呈现请求形式通知媒体服务器所请求的媒体频道。然后,服务器可使用在先前频道透明建立过程期间协商的机制和端口开始传递该频道的媒体内容。
如果用户随后希望切换到服务器的新的基于单播的频道,则终端在正在进行会话期间仅向服务器传输仅对新频道的新频道具体呈现请求。这意味着该频道切换发生在会话内部,不需要首先结束当前会话然后建立新会话的任何要求。因此,对新频道要再使用该传送机制和端口。这将显著地减少频道切换时间,因为在服务器和终端需要的往返和数据处理更少。
本发明还允许在单播和广播传递之间的无缝或者接近无缝的切换。用户终端仅向媒体服务器传输呈现引起当前基于单播的频道的媒体内容的传送的暂时停止的暂停请求。终端现在可以收听广播频道。如果用户重新希望收听先前的基于单播的频道或者其它基于单播的频道,那么终端发送对该频道的新频道具体呈现请求。因此,不需要任何新的会话建立过程就恢复媒体频道。
附图说明
通过参考以下结合附图所作的说明可以更好地理解本发明及其更多的目标和优势,其中:
图1A和1B是根据先有技术图解频道建立过程与频道切换过程的信令框图。
图2是根据本发明图解管理基于单播的媒体会话的方法的流程图;
图3是根据本发明的实施例图解频道透明会话建立过程的信号框图;
图4是根据本发明的另一实施例图解频道透明会话建立的信号框图;
图5是根据本发明的再一实施例图解频道透明会话建立过程的信号框图;
图6是根据本发明的实施例图解频道请求过程的信号框图;
图7是图解本发明的用于暂停以及用于终止基于单播的媒体会话过程的信号框图;
图8是可应用本发明的教导的通信系统的部分的示意概图;
图9是根据本发明的用户终端示意框图;
图10是根据可在图9的用户终端中实现的本发明的会话建立管理器的示意框图;
图11是根据本发明媒体服务器的示意框图;以及
图12是根据可在图11的媒体服务器中实现的本发明的会话建立管理器的示意框图。
具体实施方式
在附图中,对于相应或者相似单元将使用相同的参考标号。
本发明涉及媒体会话管理,特别涉及管理基于单播的媒体会话。与先有技术的方法相比,本发明的会话管理减少了切换基于单播的媒体频道或者在单播和组播/广播频道之间切换所需要的往返的数目。
由于往返数量的减少,切换媒体频道的用户察觉时间减短,接近"真正的"快速移动水平。因此,本发明在基于单播的通信系统中提供与当前的通用电视系统和即将来临的基于组播/广播的移动电视相似的类似电视的体验。本发明的教导可用于任何此类单播系统、尤其使用因特网协议(IP)的无线通信系统,以供数据通信。这样的通信系统的典型示例是通过PS流(PPS)向已连接用户提供多媒体数据的包交换(PS)系统。更多的PPS的信息可以参考文档[2]。
根据本发明,媒体频道可以例如携带“实况”媒体或者包括由一个或多个剪辑组成的预先录制的内容。
从用户角度而言,本发明的频道切换将被更加平稳地体验,将在更短的时段执行,并且不需要像先有技术的单播解决方案所需要的那样访问多媒体提供者的网页也不需要建立新的媒体会话。
根据本发明,媒体或者多媒体数据包括可以在用户终端呈现和显示的任何形式和类型的媒体。这包括但不限于图像、视频、音频以及其他在呈现期间能够由用户察觉的媒体类型。
为了简化对本发明及其优点的理解,首先结合图1A和1B简单回顾建立基于单播的媒体会话以及切换媒体频道的先有技术方法。这些图示出了在建立期间执行的信令以及实时流媒体协议(RTSP)会话的管理。如本领域中所公知的,RTSP是用于对具有实时性的媒体数据传送的控制的应用级协议。现在,可用包括RTSP 1.0和RTSP 2.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文件的开始"
o="创建者"
s="会话名称"
i="会话信息"
u="描述的URI"
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:1
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=00
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=fmtp:98 profile=3;level=10
a=control:streamID=1
SDP文件的更多信息可参考文档[3]。
此后,用户终端编译并且传输对需要的媒体内容的通用资源标志符(URI)的SETUP(建立)请求。典型的媒体会话包括通过基于单播的媒体频道传输的视频和音频内容。在此情况下,对于两种内容类型逐步执行SETUP过程。例如,可以首先传输包含视频内容的URI的视频SETUP请求。对于媒体数据传输,该请求还包含用户终端可接受的传输参数的指示。这些参数尤其包括用于视频内容的客户端输入端口。响应SETUP请求,媒体服务器产生此后作为当前媒体会话标识符使用的会话标识符。把此会话标识符与由服务器和视频输出端口选择的传输参数一起返回。
把相应的音频SETUP请求和响应在用户终端与媒体服务器之间通信,用于协商音频传输参数。与视频SETUP消息形成明显对比,音频SETUP请求包含所通知的会话标识符。
现在成功地建立RTSP会话,并且可以开始实际的媒体内容传送。用户终端因此编译PLAY(播放)请求,该请求告诉服务器启动经在会话建立期间协商的传送机制发送通知的媒体内容。PLAY请求可以指定正常播放时间应该开始的范围,或者指定回放或媒体呈现应该开始的时间参数。媒体服务器处理此PLAY请求并且以确认的时间参数或者范围以及同步信息响应,比如依据在此响应的RTP信息域中的RTP时间。
然后,能够使用确定的传送机制在基于单播的媒体频道传递所请求的媒体。
如果用户随后想要切换到第二基于单播的频道,必须首先结束当前RTSP会话。这可以通过传输PAUSE(暂停)请求实现,该请求包含到媒体服务器的会话标识符和媒体URI。这引起传递的媒体流的暂时中断。但是,此时没有分配给此流的资源被释放。用户终端继续,传输TEARDOWN(拆卸)请求以停止对给定URI的流传递,释放与其关联的资源。这就结束了当前媒体会话。更多RTSP的信息可参考文档[4]。
然后,迫使用户终端建立新的、但用于新的媒体频道的RTSP会话,如图1B所示。这样,再一次进行与如前所述的相同过程,但使用新的媒体内容的URI并使用新的会话标识符。因此,在能呈现新媒体频道的媒体内容之前,频道切换包括进行6次往返的大范围信令以及媒体服务器和用户终端的某些处理延迟。
本发明经频道特定呈现请求(RTSP PLAY请求)以及通用频道透明会话建立过程,通过选择媒体频道减少此与频道切换有关的大范围信令。
图2是管理基于单播的媒体会话的方法流程图,所述媒体会话包括用户终端(客户端)以及提供多个、即至少两个不同的媒体频道的媒体服务器。从步骤S1开始,在这里用户终端产生并且向媒体服务器传输通用频道透明会话请求。因此,此会话请求不选择具体媒体内容或者媒体频道。这样,此时仍然没有通知媒体服务器用户终端请求哪个媒体内容。根据频道透明会话请求的接收,媒体服务器以及用户终端在下一步骤S2执行通用频道透明媒体会话建立过程。此建立过程基于先前产生和传输的会话请求实施。这样,步骤S2主要包括在用户终端与服务器之间建立RTSP会话。但是,与先有技术成明显对比,此会话建立过程不包括随后向用户终端传递媒体内容的任何规范。这样,在用户终端与媒体服务器之间交换信息、比如传输参数协商以及会话标识符通告。然而,执行此信息交换,没有要用于媒体会话的任何明确或者隐含的媒体频道的选择。这意味着推迟实际的媒体内容/频道选择直到已完成会话建立过程。
一旦已成功建立通用频道透明媒体会话,首先产生需要的媒体频道和内容的通告。此时,在步骤S3,用户终端产生并且向媒体服务器传输用于所需频道的频道具体呈现请求。首先,现在服务器知道用户终端请求哪个特定媒体内容,因此开始使用经协商的传送机制传递所请求频道的媒体数据。在步骤S4中,当终端接收媒体数据时,它的媒体播放器开始为其使用者在终端上呈现或者回放该内容。该数据呈现一般包括在用户终端的显示屏上或者在连接到用户终端的显示屏上显示视频内容,并且在终端的扬声器上或者连接到终端的扬声器上播放音频内容。
然后本方法结束。下面,将结合图3到图5的信号框图更详细地说明描述通用频道透明会话建立过程的不同情形。在这些框图中,媒体会话作为RTSP会话执行并且因此在这些图中使用了这种RTSP请求和响应的术语。本发明的教导仍然可适用于其它用于建立和管理基于单播的媒体会话的协议。
图3是根据本发明的实施例图解执行通用频道透明媒体会话建立过程的信号框图。通过向媒体服务器的通用频道透明会话请求消息的传输发起该建立。此请求消息可以是DESCRIBE请求(如果使用的话)或者SETUP请求。在此图以及其后的图中,已经使用了DESCRIBE请求和响应,但是也可以把本发明用于没有这些请求和响应的过程。
DESCRIBE请求并不像本领域那样指定实际的频道(在图1A中的RTSP://tv.com//channel1.sdp,以及在图1B中的rtsp://tv.com/channel2.sdp)。成明显对比的是,该请求在它通过来自媒体服务器的基于单播的传递请求多个、优选为全部的可用媒体内容的描述方面是通用的。
媒体服务器基于接收的DESCRIBE请求产生描述消息或者取预先产生的这种消息。此DESCRIBE响应优选地具有SDP文件的形式或者某种别的消息格式。此SDP文件包含可用媒体频道对其媒体内容的宣告。符合先前列出的先有技术SDP文件的示例,在DESCRIBE响应中返回的SDP文件可以具有下述形式:
RTSP/2.0 200 OK
CSeq:1
Date:"创建日期与时间"
Content-Type:allchannels/sdp
Content-Length:"文件长度"
v=0
o="创建者"
i="会话信息"
u="描述的URI"
t="会话活动计时"
a=control:tv.com/allchannels.sdp/channel1
a=control:tv.com/allchannels.sdp/channel2
......
a=control:tv.com/allchannels.sdp/channelN
这意味着以多个会话控制行补充该SDP描述,其中每个这样的行宣布可用媒体频道之一。在备选方法中,将新属性"altcontrol"(备选控制)引入SDP文件中。这意味着保留控制属性用于向后兼容。
那么,在SDP文件中的对应媒体行可以看起来像:
a=altcontrol:list channel1
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 2
......
a=altcontrol:list channel
那么,默认频道可以是由媒体服务器选择的预先定义的默认频道,并且对于那些不支持altcontrol属性的用户终端作为初始媒体频道使用。在这样的情况下,这些用户终端可以用默认频道根据先有技术继续会话建立过程。
为了引起信令回退(fallback),会话请求可以包括支持请求,无论媒体服务器是否支持通用频道透明建立过程。这可以通过在由用户终端传输的第一个DESCRIBE请求中使用具有要求头标(header)的特征标记实现。因此,此头标能够包括新属性multiple-control-uris(多控制URI):
DESCRIBE rtsp://tv.com/allchannels.sdp RTSP/2.0
Require:multiple-control-uris
如果服务器不支持通用建立过程,那么它可以错误信息、比如不被支持的551Option(选项)响应。
一旦用户终端接收到具有优选AC URI的描述消息,它就产生通用频道透明传输或者建立请求消息。与结合图1A的论述一致,如果媒体频道包含视频和音频内容,那么优选地,对于如图3所示的两个内容类型,编译并且发送通用频道透明建立请求。第一此类的通用频道透明请求可以用于视频(音频)内容,而第二个请求则专用于音频(视频)内容。优选地,这些请求指定用户终端可接受的传输参数,以供随后的媒体传输。例如,它们包括用户终端输入视频和音频端口的通告以及其它用于建立媒体会话所需要的传输参数。
此通用建立请求消息一般根据在媒体服务器的接收触发传送机制的协商(提供-应答过程)以及会话标识符的产生。这样,媒体服务器包括分别由服务器、产生的会话标识符以及输出视频和音频端口所选择的、要在响应中用于随后的媒体传递的传输参数的信息。
因此,如果第一SETUP请求和响应涉及视频内容,则对于音频内容优选重复此过程。如上所述,一旦会话标识符已经产生并且通知了用户终端,就把它优选地包括在随后的用户终端和媒体服务器间的通信中。
现在建立了本发明的通用频道透明媒体会话。这意味着已经选择并通报了所需的输入和输出端口,已经协商了传输参数且已经产生会话标识符。尽管已经没有要在会话中使用的特定媒体频道的任何规定或选择地进行了所有这些过程。
在上文结合与图3所述的实施例中,在描述消息(DESCRIBE响应的SDP文件)中向用户终端通报不同的可用媒体频道的AC URI。然而,可能,这些URI、即媒体频道标识符在创建SDP文件时并不巳知。此外,媒体频道的有效性可信赖于该日的时间或者可以不同于不同的天。因此,固定的预先定义的SDP文件的使用将太不灵活而不能应对此情形。那么,可能的解决方案可以是在媒体服务器接收DESCRIBE响应的每个时间产生新的SDP文件。然而,这增加媒体服务器的数据处理要求并且在媒体会话建立过程中引入更多延迟。
备选方法改为在SDP文件中使用通用模板(template),然后在建立过程中的稍后位置告知用户终端相应媒体频道URI。在图4和图5中已采用了此方法。
图4是根据本发明的另一实施例图解执行通用频道透明媒体会话建立过程的信号框图。通过向媒体服务器的通用频道透明会话(DESCRIBE)请求消息的传输发起该建立。根据此消息的接收,媒体服务器提供SDP文件或者其它包含可用媒体频道的通用宣告的描述消息。此宣告可结合以下控制属性使用:
a=control:tv.com/allchannels/*
或者新的altcontrol属性:
a=altcontrol:dynamic
这就发信号通知备选AC URI的目录在特定动作是动态的或者未知的,且这要由其它方法提供。在增添的巴科斯范式(Bachus-Naurform:ABNF)语法中(参见文档[5]),SDP文件的会话部分可以写作:
altcontrol-line="a=altcontrol:"control-type[sp rtsp-URI]
control-type="list"/"dynamic"/token
rtsp-URI="specified as in RTSP 2.0"
还可以在SDP文件中提供各个控制行的实际含义,但可在描述单播频道或者单播和广播频道的完整频道表中更好地定义。
剩余的SETUP请求和响应信令按在上文结合图3所述的方式相同的通用频道透明方式执行。
然后,用户终端将编译并且发送用于在SDP文件中被动态/一般宣布的AC URI的请求。可把此请求发给媒体服务器或者在通信系统中的其它服务器或节点,所述通信系统具有对在媒体服务器的当前可用单播媒体频道的信息的访问及其各自的URI。例如,此请求可能具有规则HTTP请求或者对完整频道表的请求的形式。媒体服务器或者其它服务器/节点通过返回在媒体服务器的当前可用的基于单播的媒体频道的URI的信息来响应此请求。
在另一方法中,通过从媒体服务器或者其它服务器或者节点的广播或者多播传输执行URI通告。在图5中示意地图解此情形。在此信号图中,单独的服务器控制器以广播/多播用户服务描述(user servicedescription:USD)的形式执行AC URI通告。
媒体服务器已经预先通知服务器控制器它的不同的基于单播的频道及频道的有效性和URI。
如前所述,本发明的通用频道透明媒体会话建立过程的执行不一定必须通过DESCRIBE请求的传输发起。这在当前图中进一步图解,如可省略的虚线框所示。因此,可以通过从用户终端的通用频道透明SETUP请求消息的传输直接发起建立过程。其后的直到最后的SETUP响应的信令类似于先前结合图3所述。
此时,通过来自服务器控制器的USD广播或者多播,将在媒体服务器当前可用的媒体频道的AC URI通知用户终端。不一定必须在频道透明建立过程的完成以后发送USD消息。这意味着用户终端可改为在发起建立过程(不久)以前或者建立过程期间的某个时间已经接收USD。在这种情况下,可把服务器控制器配置成在适合的时间间隔周期地广播或者多播USD。
本发明预期,在图3到图5中任意所公开的信令的组合可以使用且处于本发明的范围内。例如,能够把URI通告组合到具有URI广播的SDP文件,在该情况下可用媒体频道的更新是突出的。
媒体会话现在已经以通用频道透明方式建立,而没有任何在会话期间用户终端实际上应该收听的媒体频道的选择。本发明的媒体频道及其因而媒体内容选择首先在呈现请求、例如RTSP PLAY请求的编译和发送发生,如图6所示。此PLAY请求包含所选媒体频道的标识符。优选地,基于与所选媒体频道相关联且先前在用户终端所接收的通用资源标志符(URI)产生该请求。优选地,呈现请求包含所选媒体频道的AC URI。
媒体服务器处理PLAY请求并且以确认的时间参数或者范围以及同步信息响应,比如依据此响应的RTP信息域中的RTP时间。
然后,使用传送机制、在通用频道透明建立过程确定的到媒体内容的输入和输出端口传输所请求的频道的媒体内容。
如果用户终端随后想切换到任何由媒体服务器所提供且先前已向与建立有关的终端通报的其它基于单播的媒体频道的任何频道,那么对于新的媒体频道,终端仅仅编译并且传输新的呈现请求、即PLAY请求。此频道具体PLAY请求优选地基于新频道的AC URI产生,且更优选地包含新频道的AC URI或者某些别的标识符。此外,在终端上,基于例如按键的按下、触摸感应屏或者一些其它输入行为的用户输入产生PLAY请求。
媒体服务器以包括同步和时间信息的呈现响应答复。当PLAY响应提供同步信息以及用于SSRC字段的值时,在终端的解码器可以开始播放新频道并且识别数据包。使用服务器的相同输出端口将新频道的媒体内容传输至用户终端的相同输入端口,如用于先前的频道那样。一般保留在频道透明建立过程期间所确定的其它传输参数。
本发明预期,如第一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的情况相比较,很明显,与该信令有关的处理和大约6次的往返对于切换媒体频道不再是必需的。因此,本发明的频道切换比先有技术的切换更快。
本发明的呈现请求的实际设计不是决定性的。一个示例可如下:
PLAY rtsp://tv.com/allchannels.sdp/channel2 RTSP/2.0
其中,"tv.com/allchannels.sdp/channel2"是媒体频道号2的AC URI。
备选方法要使用:
PLAY rtsp://tv.com/allchannels.sdp?channel=2 RTSP/2.0
其中,查询部分被用于基(base)URI"tv.com/allchannels.sdp"以及"2"是所请求的频道的标识符。
对每一媒体频道,优选使用AC URI代替使用唯一的URI,能够对于所有基于单播的媒体频道使用同样的URI但要增加某些信息以区别频道。例如,可以引入新头标。在这样的情况中,PLAY请求可以如下:
PLAY rtsp://tv.com/allchannels.sdp RTSP/2.0
x-channel:"所请求频道的标识符"
标识符可以仅仅是数值1、2、3等,或者包括MBMS用户服务标识符的其它名称或者标识符。
与先有技术相比,除了减少的切换时间以及更少的往返和与切换有关的处理之外,本发明的频道切换还具有其它优势。本发明可用于在单播频道和广播/多播频道之间提供转换,反之亦然。
如果用户想要从当前基于单播的频道切换到广播频道,那么暂时中止当前媒体内容的传递。图7是提供这样的单播-广播过渡时机的本发明实施例的信号框图。
一旦用户终端接收到切换到广播频道的用户输入,终端就编译呈现暂停请求、例如RTSP PAUSE(暂停)请求。此请求是传统的PAUSE请求,如结合图1A所述。媒体服务器通过暂停当前基于单播的频道的媒体数据的发送响应,并且优选地用PAUSE答复或者响应答复。
然后,用户终端开始收听广播频道并且接收该频道的媒体数据。此广播频道可以由通信系统中的同一媒体服务器或者其它媒体服务器提供。
如果用户随后想返回收听先前基于单播的媒体频道或者收听由该媒体服务器提供的另一基于单播的频道,那么用户终端编译并且向媒体服务器传输新的频道具体呈现请求、即PLAY请求。媒体服务器以PLAY响应答复,并且使用预先协商的传送机制和端口将所选基于单播的频道的媒体数据传输到用户终端。
这意味着在到广播频道的临时切换期间没有终止基于单播的媒体会话。相反,会话在休眠(dormant)并且依据新的呈现请求又变成活动的。
如果用户终端在切换期间的短时间并行接收两个媒体数据流,那么对于相同内容,可使从单播到广播访问的切换或者从广播到单播访问的切换无缝。这意味着在此短时期内,用户终端即从旧的(单播或者广播)频道又从新的(单播或者广播)频道接收媒体内容。那么,用户终端将在RTP缓冲以前切换来源。
为了使这样的无缝转换可靠,优选地,单播和广播之间的传输延迟小。最佳地,这两个流相同或者完全同步。在这样的情况中,可以在流中的任何地方进行切换。否则,一般在用户终端中在短时期内并行接收来自两个流的媒体内容,并且切换发生在帧内。这降低了漏失含媒体数据的数据包的风险。
由媒体服务器提供的不同的单播和广播频道可以使用不同的编码和编解码器设置。这可以通过、例如在描述文件(SDP文件)中描述不同的编码/设置来解决,并且供给他们不同的有效载荷类型值。根据频道切换,用户终端将在接收新频道的数据包时匆忙(on the fly)切换解码器配置。也能够对不同的基于单播的频道使用不同的编码。
本发明也非常灵活,因为它能够对于单播和广播使用同一媒体流而不改变任何RTP头标域。这尤其与流的相同密码的使用结合,简化了在正在进行的媒体会话期间从单播到广播的无缝转换。
即使用户首先想要收听广播频道,也可执行本发明的通用频道透明建立过程。这意味着,单播媒体会话建立了但接着休眠了,直到用户终端停止收听广播频道并且向媒体服务器传输PLAY请求。这意味着本发明的第一频道具体呈现请求不一定必须在频道透明建立过程的完成滞后直接传输。改为,一旦用户想要从广播频道切换到单播频道,就首先发送呈现请求。
如果用户终端随后想结束当前媒体会话,执行先前描述的具有PAUSE和TEARDOWN(拆卸)请求和响应的过程。
优选地,在所有随后通信的请求和响应中,由媒体服务器和用户终端使用媒体服务器优选地产生的、与(第一)通用频道透明SETUP请求的接收有关的会话标识符。这意味着,优选把会话标识符包含在随后的用于切换单播频道的呈现请求中。另外,在用户终端的广播频道的暂时收听之后恢复媒体会话的呈现请求也优选地包含此会话标识符。
本发明的通用频道透明会话建立过程不一定必须遵循结合图3到图6所描述的信令。在备选方法中,RTSP请求和答复的流水线操作是可能的。在这样的情况中,用户终端编译并且传输频道透明的视频和音频SETUP请求,接着是频道具体PLAY请求。这意味着终端在传输下一个以前不等待对先前传输的请求的任何答复。媒体服务器以接连地或者实际上一起地发送视频SETUP响应、音频SETUP响应以及PLAY响应来响应。然后,向用户终端递送首先在PLAY请求所请求的媒体频道的媒体数据。
在此流水线操作的实施例中,在频道透明建立过程已经结束且所请求的媒体频道已经请求以后,首先向用户终端通报会话标识符。为了识别用户终端以及当前会话,终端优选地产生唯一的临时标识符并且将其包括在SETUP以及PLAY请求中。这允许媒体服务器确定这些请求发起于一个和同一用户终端。一旦终端已经从媒体服务器、典型地在第一个SETUP答复中接收到会话标识符,它就要在切换媒体频道时在任何随后的PLAY请求中使用此会话标识符替代临时标识符。
图8是根据本发明实施例的基于单播的无线通信系统1的示意概图。通信系统1包含向已连接的用户终端10、100传输媒体内容的基站或者网络节点20。基站20包含或者连接至本发明的媒体服务器200,该媒体服务器具有多个可用的基于单播的媒体频道。在该图中,第一用户终端100收听这些基于单播的媒体频道之一。但是,另两个用户终端10收听在媒体服务器200也是可用的广播频道。
图9是根据本发明实施例的用户终端100的示意框图。用户终端100包含发射机和接收机或者收发器110,在图中作为单个单元示意示出。单元110包括传统的发射机/接收机功能,比如调制器/解调器、编码器/解码器等。
发射机110适合于向媒体服务器传输在频道透明会话建立过程期间的通用频道透明请求,频道具体呈现请求指示媒体传递和/或频道切换的开始。接收机110适合于接收对由发射机链110所发送的请求的响应且当然也接收来自媒体服务器的成流的媒体数据。
用户终端100包含会话建立管理器140,该管理器构成用于与媒体服务器执行通用频道透明基于单播的会话建立过程的装置。该建立管理器140因此编译由发射机110发送给媒体服务器的频道透明请求消息,并且处理由接收机110所接收的相应的响应消息。频道透明建立过程包括在用户终端100与服务器之间的信息交换,但是不包括要使用的媒体频道的明确选择直到会话建立。管理器140基于由发射机发送的、通用频道透明会话请求(DESCRIBE或者SETUP请求)与媒体服务器执行此建立过程。
一旦建立管理器140已与媒体服务器完成频道透明建立过程,就在用户终端中执行呈现或者播放请求产生器135以编译频道具体呈现请求。请求消息包含所选媒体频道的标识符,例如AC URI或者其它频道标识符。把经编译的呈现请求转送到110,发射机又把它转送到媒体服务器用于开始媒体传递。
一般通过终端100的用户输入(未示出)激活建立管理器140和请求发生器135。这将引起本发明的请求消息的产生及其向媒体服务器的传输。
通过在到另一基于单播的频道的切换期间触发或激活用户输入,或者依据在广播频道收听的临时时段之后返回收听基于单播的频道,也把请求发生器135激活。因此,在正在进行的会话期间的频道切换,请求发生器135对新媒体频道编译呈现请求,该请求优选包含此频道的标识符。相应地,在到广播收听的切换,播放请求发生器135编译由发射机110发送到媒体服务器的呈现暂停请求。如果用户再想返回先前的基于单播的频道或者另一此类基于单播的媒体频道,那么请求发生器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也包括视频建立消息或者响应处理器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的形式包含在答复中。然后,把标识符信息转送到呈现请求发生器并且当形成频道具体呈现请求时由发生器使用。
如果通过广播或者多播传输通报频道标识符,那么配置标识符消息处理器148用于处理接收的广播/多播信息并且从其中检索频道标识符信息。
会话建立管理器140的单元141到148可以软件、硬件或其组合提供。单元141到148可以在建立管理器140中一起实现。把某些单元设置在用户终端中其它地方的分布式的实现也是可能的。
图11是根据本发明的媒体服务器200的示意框图。媒体服务器200包括安排来与外部单元进行通信并处理输入和输出消息的发射机和接收机单元210。特别地,执行发射机210用于向用户终端传输响应消息和包含媒体数据的数据包。特别地,执行接收机210用于接收来自用户终端的请求消息。
媒体服务器200包括或者可以访问多个媒体频道400、410。这意味着服务器200可以包括或者连接至存储有预先录制的媒体内容的数据库。备选地,或者此外,媒体源可为在媒体服务器200所接收的实况媒体内容的形式,用于进一步向请求终端的传输。执行该服务器200的媒体管理器230用于负责正确的媒体处理,例如为不同终端选择正确的媒体内容、用媒体内容产生数据包。
媒体服务器200还包括会话建立管理器220,该管理器220构成用于与用户终端执行通用频道透明基于单播的会话设置过程的装置。根据由从终端发起的通用频道透明会话请求的接收机触发建立管理器220。建立管理器220产生频道透明响应消息,并分别处理由发射机210发送到用户终端并由接收机210从终端接收的频道透明请求消息。
一旦完成了频道透明会话建立过程,并且接收机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选择包括要用于会话的输出视频和音频端口的传输参数。把该信息既转送到媒体服务器的发射机以用于即将来临的媒体传递,又转送到各自的视频建立响应发生器224和音频建立响应发生器226。发生器224编译各自的包含输入传输参数的视频和音频建立响应,用于向终端的传输。视频SETUP响应发生器224优选地也包括会话标识符,该会话标识符在媒体服务器产生的,并包含在在服务器和用户终端之间交换的所有随后的响应和请求中。
如果描述响应发生器222不把媒体频道标识符包括在描述响应中,那么建立管理器220可以利用可选的标识符消息发生器228。该发生器228形成包含当前在服务器可用的基于单播的媒体频道的标识符、比如AC URI的消息。可依据来自用户终端的明确请求的接收操作发生器228。备选地,产生的消息可由服务器广播或者多播到多个终端。
可以软件、硬件或其组合提供会话建立管理器220的单元221到228。单元221到228可在建立管理器220中一起实现。把某些单元设置在媒体服务器中其它地方的分布式实现也是可能的。
本领域技术人员要理解,在没有脱离本发明范围下可对本发明做各种修改和变化,本发明的范围由随附的权利要求书定义。
参考文献
[1]WO 2006/096104
[2]3GPP TS 26.234 v7.1.0;3rd Generation Partnership Project;TechnicalSpecification group Services and System Aspects;Transparent end-to-endPacket-switched Streaming Service(PSS);Protocols and codecs,December 2006
[3]Network Working Group,Request for Comments:2327,April 1998,SDP:Session Description Protocol
[4]Network Working Group,Request for Comments:2326,April 1998,Real TimeStreaming Protocol(RTSP)
[5]Network Working Group,Request for Comments:4234,October 2005,Augmented BNF for Syntax Specifications:ABNF

Claims (35)

1.一种管理包括用户终端(100)和提供多个媒体频道的媒体服务器(200)的基于单播的媒体会话的方法,所述方法包括以下步骤:
所述用户终端(100)向所述媒体服务器(200)传输通用频道透明会话请求;
所述用户终端(100)与所述媒体服务器(200)并基于所述会话请求执行通用频道透明媒体会话建立过程;以及
一旦完成了所述通用频道透明媒体会话建立过程,所述用户终端(100)就向所述媒体服务器(200)传输对所述多个媒体频道的第一媒体频道的频道具体呈现请求。
2.如权利要求1所述的方法,其中,所述执行步骤包括:
所述用户终端(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),用于与所述媒体服务器(200)并基于所述会话请求执行通用频道透明基于单播的媒体会话建立过程,其中,设置所述发射机(110)用于一旦所述执行装置已经完成所述通用频道透明媒体会话建立过程就向所述媒体服务器(200)传输对所述多个媒体频道的第一媒体频道的频道具体呈现请求。
23.如权利要求22所述的用户终端,其中,所述执行装置(140)包括:
描述消息处理器(142),用于处理发起于所述媒体服务器(200)且基于所述会话请求所产生的通用频道透明会话描述消息以检索所述多个媒体频道的通告。
24.如权利要求22或23所述的用户终端,其中,所述执行装置(140)包括:
建立请求发生器(143、145),用于产生去往所述媒体服务器(200)的通用频道透明建立请求;以及
建立信息处理器(144、146),用于处理发起于所述媒体服务器(200)并基于所述建立请求所产生的通用频道透明建立消息,所述通用频道透明建立消息包括在所述媒体会话期间要由所述用户终端(100)的接收机(110)所使用的至少一个通信端口的信息。
25.如权利要求22到24中任意项所述的用户终端,其中,所述执行装置(140)包括:
标识符消息处理器(148),用于从标识符消息检索用于所述多个媒体频道的每个媒体频道的唯一媒体资源标识符,所述用户终端(100)还包括:
呈现请求发生器(135),用于基于与所述第一媒体频道关联的唯一媒体资源标识符产生所述呈现请求。
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)。
CN2007800225925A 2006-06-19 2007-05-04 媒体频道管理 Active CN101473654B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US80511206P 2006-06-19 2006-06-19
US60/805,112 2006-06-19
PCT/SE2007/000438 WO2007149029A1 (en) 2006-06-19 2007-05-04 Media channel management

Publications (2)

Publication Number Publication Date
CN101473654A true CN101473654A (zh) 2009-07-01
CN101473654B CN101473654B (zh) 2011-08-03

Family

ID=38833676

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2007800225925A Active CN101473654B (zh) 2006-06-19 2007-05-04 媒体频道管理

Country Status (9)

Country Link
US (2) US8230044B2 (zh)
EP (2) EP2227017B1 (zh)
KR (1) KR101375454B1 (zh)
CN (1) CN101473654B (zh)
DK (1) DK2227017T3 (zh)
ES (1) ES2550949T3 (zh)
HK (1) HK1134874A1 (zh)
RU (1) RU2494562C2 (zh)
WO (1) WO2007149029A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011009403A1 (zh) * 2009-07-21 2011-01-27 华为技术有限公司 一种实现流业务的方法及通信系统以及相关设备
CN102662598A (zh) * 2012-04-25 2012-09-12 深圳市中兴移动通信有限公司 基于手势滑动的会话查看方法及装置、触屏智能终端

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9008598B2 (en) * 2006-06-16 2015-04-14 Core Wireless Licensing S.A.R.L Broadcast channel identification
US8340113B2 (en) 2007-06-20 2012-12-25 Telefonaktiebolaget Lm Erricsson (Publ) Method and arrangement for improved media session management
KR20090017351A (ko) * 2007-08-14 2009-02-18 (주)씨디네트웍스 프로그램 제어장치, 프로그램 제어방법 및 그 기록 매체
US9553911B1 (en) 2007-09-04 2017-01-24 Arris Enterprises, Inc. System, method and computer readable medium for managing program switch requests
CN101471902A (zh) * 2007-12-29 2009-07-01 华为技术有限公司 一种实现信号暂停的方法及设备
CN101227745B (zh) * 2008-02-02 2011-02-09 华为软件技术有限公司 移动多媒体业务的网络切换方法、装置和系统
US7979557B2 (en) * 2008-04-11 2011-07-12 Mobitv, Inc. Fast setup response prediction
US7921222B2 (en) 2008-05-06 2011-04-05 Vantrix Corporation Method and system for fast channel switching using standard RTSP messages
US9197690B2 (en) * 2008-09-25 2015-11-24 Arris Enterprises, Inc. Method and system for transmitting content
US8082351B1 (en) * 2009-05-26 2011-12-20 Adobe Systems Incorporated Software load balancing for session requests that maintain state information
EP2293524A1 (en) * 2009-09-07 2011-03-09 Nxp B.V. Set-up of media stream transmission and server and client for media stream transmission
KR101541197B1 (ko) * 2009-12-21 2015-08-05 한국전자통신연구원 스트리밍 서버군에서 서비스 중인 콘텐츠의 정보를 갱신하는 방법
CN101969431B (zh) * 2010-09-28 2013-06-12 广东威创视讯科技股份有限公司 一种实现流媒体播放单播、多播无缝切换的方法
CN102075976B (zh) * 2011-01-11 2013-07-24 中国联合网络通信集团有限公司 移动流媒体播放器和移动流媒体播放方法
US8775664B2 (en) * 2011-02-16 2014-07-08 Sony Corporation Method and apparatus for use in tracking playback of media streams while in stand-by mode
CN102857478B (zh) * 2011-06-30 2016-09-28 华为技术有限公司 媒体数据控制方法及装置
US8819264B2 (en) * 2011-07-18 2014-08-26 Verizon Patent And Licensing Inc. Systems and methods for dynamically switching between unicast and multicast delivery of media content in a wireless network
US8837488B2 (en) * 2011-07-29 2014-09-16 Blackfire Research Corporation Two tier multiple sliding window mechanism for multidestination media applications
US9918115B2 (en) 2011-10-04 2018-03-13 Google Llc System and method for obtaining video streams
US8787726B2 (en) 2012-02-26 2014-07-22 Antonio Rossi Streaming video navigation systems and methods
US9712580B2 (en) * 2012-04-03 2017-07-18 Netflix, Inc. Pipelining for parallel network connections to transmit a digital content stream
US9392340B2 (en) * 2012-05-14 2016-07-12 Lg Electronics Inc. Method and a control device for controlling and operating a media renderer and a media server and for notifying the media renderer when there are too many resource being prefetched, and a method of operating a media renderer device
EP2951972A1 (en) * 2013-01-31 2015-12-09 Codemate AS Network content delivery method using a delivery helper node
KR102249147B1 (ko) * 2014-03-29 2021-05-07 삼성전자주식회사 복합 네트워크에서 멀티미디어 데이터 관련 정보를 송수신하기 위한 장치 및 방법과 그 구조
US10560514B2 (en) * 2014-03-29 2020-02-11 Samsung Electronics Co., Ltd. Apparatus and method for transmitting and receiving information related to multimedia data in a hybrid network and structure thereof
US10375528B2 (en) * 2015-07-09 2019-08-06 At&T Intellectual Property I, L.P. Dynamically switching between broadcast and unicast services for service continuity between wireless networks
US10123226B2 (en) * 2015-12-02 2018-11-06 At&T Intellectual Property I, L.P. Detection of active listeners and dynamic provisioning of cell sites for broadcast
CN105516115B (zh) * 2015-12-02 2019-06-18 华为软件技术有限公司 一种频道快速播放的方法及用户设备ue
CN109151614B (zh) * 2017-06-19 2023-05-16 中兴通讯股份有限公司 一种降低hls直播播放延迟的方法及装置
CN110167190B (zh) * 2018-02-14 2021-02-12 华为技术有限公司 会话建立方法和设备
US11489603B2 (en) * 2019-09-23 2022-11-01 Nbcuniversal Media, Llc Media essence library
US11638040B2 (en) 2020-08-24 2023-04-25 Schmied Enterprises LLC Eco-friendly codec-based system for low latency transmission

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2243359A1 (en) * 1996-01-31 1997-08-07 Ipsilon Networks, Inc. Improved method and apparatus for dynamically shifting between routing and switching packets in a transmission network
WO2001013579A1 (fr) * 1999-08-18 2001-02-22 Fujitsu Limited Systeme et procede de repartition de charge dans un reseau, et support d'enregistrement destine au programme de ce systeme
AU4869801A (en) * 2000-03-24 2001-10-03 Reality Commerce Corporation Method and system for subject video streaming
US7571244B2 (en) * 2000-07-15 2009-08-04 Filippo Costanzo Audio-video data switching and viewing system
WO2002009009A1 (en) * 2000-07-26 2002-01-31 Cool Partners, Inc. Method and apparatus for selecting streaming media in real-time
US6973081B1 (en) * 2000-10-12 2005-12-06 Realnetworks, Inc. System and method for seamlessly joining multicast session
GB2368224B (en) * 2000-10-17 2004-08-25 Hewlett Packard Co Content provider entity for communication session
US20030048808A1 (en) * 2001-09-12 2003-03-13 Stahl Thomas Anthony Method and apparatus for changing received streaming content channels
US7296074B2 (en) * 2002-03-20 2007-11-13 Scientific-Atlanta, Inc. Media on demand session re-use
US8397269B2 (en) * 2002-08-13 2013-03-12 Microsoft Corporation Fast digital channel changing
CN100566332C (zh) * 2002-08-28 2009-12-02 Nxp股份有限公司 流出多媒体数据的方法
KR100487124B1 (ko) * 2002-11-12 2005-05-03 삼성전자주식회사 세션 이니세이션 프로토콜 시스템의 세션 정보 처리 방법및 그 기록매체
KR100476457B1 (ko) * 2003-02-13 2005-03-18 삼성전자주식회사 네트워크 디지털 방송 서비스를 위한 제어 방법
US20040260827A1 (en) * 2003-06-19 2004-12-23 Nokia Corporation Stream switching based on gradual decoder refresh
DE602004003070T2 (de) * 2003-07-21 2007-05-31 France Telecom Zugriffsregelung für eine multimedia-sitzung gemäss netzwerk-betriebsmittelverfügbarkeit
US7162533B2 (en) * 2004-04-30 2007-01-09 Microsoft Corporation Session description message extensions
US7720983B2 (en) * 2004-05-03 2010-05-18 Microsoft Corporation Fast startup for streaming media
SE0402876D0 (sv) * 2004-11-25 2004-11-25 Ericsson Telefon Ab L M TV-like standards-compliant unicast streaming over IP
US8522293B2 (en) * 2004-12-15 2013-08-27 Time Warner Cable Enterprises Llc Method and apparatus for high bandwidth data transmission in content-based networks
EP1675343A1 (en) * 2004-12-23 2006-06-28 Siemens S.p.A. Method and system to minimize the switching delay between two RTP multimedia streaming sessions
US7500133B2 (en) * 2004-12-28 2009-03-03 Sap Ag Connection manager for handling message oriented protocol-based requests
US7567565B2 (en) * 2005-02-01 2009-07-28 Time Warner Cable Inc. Method and apparatus for network bandwidth conservation
CA2597850C (en) * 2005-02-23 2012-08-28 Arroyo Video Solutions, Inc. Playout-dependent unicast streaming of digital video content
WO2006096104A1 (en) * 2005-03-07 2006-09-14 Telefonaktiebolaget Lm Ericsson (Publ) Multimedia channel switching
US7609700B1 (en) * 2005-03-11 2009-10-27 At&T Mobility Ii Llc QoS channels for multimedia services on a general purpose operating system platform using data cards
US8028322B2 (en) * 2005-03-14 2011-09-27 Time Warner Cable Inc. Method and apparatus for network content download and recording
US20070168523A1 (en) * 2005-04-11 2007-07-19 Roundbox, Inc. Multicast-unicast adapter
US8347341B2 (en) * 2006-03-16 2013-01-01 Time Warner Cable Inc. Methods and apparatus for centralized content and data delivery
US20070245391A1 (en) * 2006-03-27 2007-10-18 Dalton Pont System and method for an end-to-end IP television interactive broadcasting platform
US7921222B2 (en) * 2008-05-06 2011-04-05 Vantrix Corporation Method and system for fast channel switching using standard RTSP messages

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011009403A1 (zh) * 2009-07-21 2011-01-27 华为技术有限公司 一种实现流业务的方法及通信系统以及相关设备
CN102662598A (zh) * 2012-04-25 2012-09-12 深圳市中兴移动通信有限公司 基于手势滑动的会话查看方法及装置、触屏智能终端

Also Published As

Publication number Publication date
KR20090039682A (ko) 2009-04-22
DK2227017T3 (en) 2015-10-26
RU2009101322A (ru) 2010-07-27
ES2550949T3 (es) 2015-11-13
WO2007149029A1 (en) 2007-12-27
EP2227017A1 (en) 2010-09-08
HK1134874A1 (en) 2010-05-14
EP2036350A1 (en) 2009-03-18
US20120239779A1 (en) 2012-09-20
CN101473654B (zh) 2011-08-03
KR101375454B1 (ko) 2014-03-25
RU2494562C2 (ru) 2013-09-27
EP2227017B1 (en) 2015-07-22
EP2036350A4 (en) 2010-05-05
EP2036350B1 (en) 2015-07-22
US8230044B2 (en) 2012-07-24
US20100223357A1 (en) 2010-09-02

Similar Documents

Publication Publication Date Title
CN101473654B (zh) 媒体频道管理
CN101133645B (zh) 多媒体会话建立方法、设施、网络节点和用户终端
CN101573943B (zh) 媒体频道管理
KR20100032425A (ko) 엠비엠에스로부터 피에스에스로의 핸드오버를 위한 시스템 및 방법
EP2288151A1 (en) Methods and apparatuses for generating channel information, access controlling and delivering and iptv system
EP1856911A1 (en) Multimedia channel switching
JP2008530835A (ja) パケット交換ネットワーク上のオンデマンドマルチチャネルストリーミングセッション
WO2012059376A1 (en) Methods and devices for media description delivery
CN102761550A (zh) 实现流媒体服务的方法、装置及系统
JP4225994B2 (ja) 移動通信端末機のチャネル切替装置及び方法
CN100592790C (zh) 多媒体信道切换
CN101212320B (zh) 访问网络电视服务的方法、系统及网络电视终端
JP4773505B2 (ja) マルチメディアチャネルの切り替え
WO2010145139A1 (zh) 包交换域中彩铃信息传输方法及系统及彩铃服务器和终端
KR100705940B1 (ko) 무선 데이터 통신 망에서의 미디어 소스 실시간 인코딩제어 방법 및 이를 이용한 시스템

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1134874

Country of ref document: HK

C14 Grant of patent or utility model
GR01 Patent grant
REG Reference to a national code

Ref country code: HK

Ref legal event code: GR

Ref document number: 1134874

Country of ref document: HK