CN102577304B - 动态转发第一协议的消息的方法和系统及其控制节点 - Google Patents
动态转发第一协议的消息的方法和系统及其控制节点 Download PDFInfo
- Publication number
- CN102577304B CN102577304B CN201080035640.6A CN201080035640A CN102577304B CN 102577304 B CN102577304 B CN 102577304B CN 201080035640 A CN201080035640 A CN 201080035640A CN 102577304 B CN102577304 B CN 102577304B
- Authority
- CN
- China
- Prior art keywords
- message
- recipient
- rtcp
- node
- transmit leg
- 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.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/564—Enhancement of application control based on intercepted application data
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
- Communication Control (AREA)
Abstract
一种用于动态转发与一个或更多个RTP流相关联的RTCP消息的方法和系统。每个RTP流与媒体会话相关联并与发送方节点(MF)和一个或更多个接收方节点(UE)相关联。所述方法包括以下步骤:为至少一个RTP流分配至少一个控制节点(MSAS);将所述控制节点的地址提供给与所述RTP流相关联的接收方节点,所述地址在会话控制协议消息或HTTP消息中被提供至所述接收方节点,并且所述地址不同于相关联的发送方节点的地址(4);以及,所述接收方节点发送接收方RTCP消息至所述控制节点,使用包含在所述会话控制协议消息或HTTP消息中的所述地址(8)。
Description
技术领域
本发明涉及网络中RTCP消息的动态转发,涉及一种用于动态转发网络中的RTCP消息的方法和系统,用于在这样的系统中使用的网元和用户设备,以及用于执行所述方法的计算机程序产品,但不限于此。
背景技术
当今实时传输(RTP)协议和相关联的RTP控制协议(RTCP)已分别广泛用于凭借基于IP的网络将多媒体数据流式传输至一个或更多个接收方和用于提供关于媒体流的控制和管理信息。RTCP协议是可用于各种不同目的的灵活的协议。其可位于机制的核心,该机制允许单一目标的多源媒体数据流的同步,例如在视频流和音频流之间的唇音同步。可选地,其用于监测服务或整个网络的质量。基于RTCP反馈,操作员可采取适当的措施加强网络的功能。例如,基于由RTCP消息提供的信息,操作员可通过指示媒体源编码并以较少带宽消耗方式发送媒体流来消除某些路由的网络堵塞。
例如,IP多媒体子系统(IMS)架构采用RTP作为传输协议,该架构为支持范围广泛的、由会话初始化协议(SIP)的灵活性激活的服务的统一架构。IMS由某些3GPP和3GPP2标准(例如3GPPTS22.228,TS23.218,TS23.228,TS24.228,TS24.229,TS29.228,TS29.229,TS29.328和TS23.320Releases5-7)定义。将IMS用于IPTV是由某些ETSI规范(例如ETSITS182027和ETSITS183063)定义的。一旦使用会话初始化协议(SIP)建立会话,实时传输(RTP)协议就会用于将多媒体从媒体源或发送方流式传输至接收方,可选地,为了唇音同步和服务信息质量,在媒体发送方和接收方之间采用RTCP协议。同样地,如在TS183064所述的下一代网络(NGN)集成IPTV架构采用HTTP设置RTP媒体会话。
对于某些应用,例如交互目标(组)同步、选择性监测和内容自适应,在RTCP消息路径上具有独立的活跃元素是有利的。例如US2008/0320132描述了一种用于拦截RTCP控制消息和测量在发送方和接收方之间传送的数据的质量的代理服务器。进一步地,WO2009/070202描述了监测媒体发送方和接收方之间的RTCP消息的中间媒体处理器,其能够拦截和修改RTCP控制消息并将这些修改过的控制消息进一步转发给接收方。
关于在网络中实施这种已知的活跃元素的问题涉及的事实在于这些元素首先需要接收RTCP消息以便他们能够从中提取信息。现有技术方案以不同方式处理这种问题。
一个方案是在网络节点放置活跃元素,所有RTCP消息和间或所有RTP媒体包通过所述网络节点并指示活跃元素拦截和检查这些RTCP包以便从中提取有用信息。这种方案将活跃元素的用途仅静态局限于网络中的某个位置。进一步地,这种方案不提供使用网络资源的有效方法,因为在这些类型的状况中通常仅有少数RTCP通信量被监测。最后,这种方案限制了对于由第三方控制的第三方服务使用这些活跃元素的可能性,因为操作员不太可能允许由第三方控制的活跃元素来拦截和检查网络中的所有或至少部分RTCP通信量。
其它在网络中使用这些活跃元素的方案使用了预配置的媒体发送方、媒体接收方和活跃元素来经由活跃元素转发RTCP消息路径。预配置可缓和上文列举的某些缺点,但缺点在于其仍然是静态的。一旦发送方、接收方和活跃元素被预配置以便以某种方式转发RTCP消息,那么网络受限于上述状况。不允许操作员灵活地为基于RTCP的不同服务选择不同的活跃元素,或不允许当例如一个活跃元素发生故障或需要更新时迅速地更换为另一个。同样地,当活跃元素由第三方管理和控制时,预配置方案是非常死板的。
更普遍地,在目前的全球IP网络的环境中,每一天每一秒都有许多新的媒体发送方连接到网络,因此为了从适当的媒体发送方或接收方经由适当的活跃元素转发RTCP消息,几乎不可能通过调整接收方、发送方和活跃元素的静态配置来追踪这些媒体源。
因此,现有技术需要较为灵活的转发RTCP消息的方法和系统。
发明内容
本发明的一个目的在于减少或消除现有技术的至少一个已知缺点,并且在本发明的第一方面提供了一种动态转发与一个或更多个RTP流相关联的RTCP消息的方法,其中每个RTP流关联于媒体会话、发送方节点和一个或更多个接收方节点。所述方法包含以下步骤:给至少一个RTP流分配至少一个控制节点;将所述控制节点的地址提供给与所述RTP流相关联的接收方节点,所述地址在会话控制协议消息或HTTP消息中被提供至所述接收方节点,并且所述地址不同于关联的发送方节点的地址;以及,所述接收方节点发送接收方RTCP消息至所述控制节点,使用在所述会话控制协议消息或HTTP消息中包含的所述地址。因此,通过交换UE和控制节点之间的会话控制协议消息或HTTP消息,例如IMSIPTV系统中的IPTVSCF或NGN集成IPTV系统中的CFIA,可将转发信息(例如活跃网元地址和诸如同步会话ID的会话标识)提供给媒体会话中涉及的网元,例如UE、媒体发送方和另一网元,从而允许媒体控制消息(例如RTCP消息)通过另一网元被转发,该网元可为应用服务器,比如媒体同步应用服务器(MSAS)、(第三方)媒体会话监测器、会话边界控制器等。
HTTP提供的优点是其容易实现,因为原则上它不要求对使用会话控制协议消息(如在SIP的情况下)的会话控制状态机器的实现和维护。进一步地,HTTP允许以多种方式(例如URI、SDP、XML等)传送参数并可用于创建和删除会话组,比如同步组。
在一个实施例中所述方法进一步包括以下步骤:向所述接收方节点提供与所述RTP流相关联的组同步标识;以及,在接收方RTCP消息中发送所述组同步标识至所述控制节点。
在进一步的实施例中,方法进一步包括以下步骤:所述接收方节点产生同步状态信息;在发送方RTCP消息中发送所述同步状态信息至所述控制节点,所述控制节点包括同步功能,所述同步功能用于使与所述发送方RTCP消息相关联的RTP流与已分配给所述控制节点的一个或更多个其它RTP流同步。
在又一个实施例中,所述方法进一步包括以下步骤:所述同步功能使用所述同步状态信息来计算同步设置信息;所述控制节点发送所述同步设置信息至所述接收方节点,所述接收方节点使用所述同步设置信息来指示与所述接收方节点相关联的延迟缓冲器。
在一个实施例中,所述方法进一步包括以下步骤:将所述控制节点的地址提供给与所述RTP流相关联的所述发送方节点,所述地址在会话控制协议消息或HTTP消息中被提供给所述发送方节点;所述发送方节点将发送方RTCP消息发送至所述控制节点,使用在所述会话控制协议消息中包含的所述地址。
在另一个实施例中,所述方法进一步包括以下步骤:当所述RTCP消息中的RTP会话标识、优选地为SSRC相同时,控制节点接收一个或更多个接收方RTCP消息和一个或更多个发送方RTCP消息并使接收的RTCP消息与发送方RTCP相关联;控制节点发送接收方RTCP消息至关联的发送方RTCP消息发起的地址和/或将发送方RTCP消息发送至关联的接收方RTCP消息发起的地址。
在一个变形中,所述接收方RTCP消息中的至少一个包括同步状态信息,所述方法进一步包括以下步骤:从所述接收方RTCP消息中移除所述同步状态信息;以及,发送所述接收方控制消息至所述关联的发送方节点。
在另一个变形中,所述方法进一步包括以下步骤:所述同步功能提供同步设置信息;以及,在发送方RTCP消息中发送所述同步设置信息至所述接收方节点。
在又一个变形中,所述方法进一步包括以下步骤:至少一个发送方节点组播所述RTP流和关联的发送方RTCP消息中的至少一个至一个或更多个接收方节点。
在另一个实施例中,所述方法进一步包括以下步骤:接收方节点发送所述RTCP消息中的至少一个至所述控制节点。
在一个实施例中,所述方法包括以下步骤:发送将控制节点加入与所述组播相关联的成员组的请求,或,为了提供发送方RTCP消息至所述控制节点而在发送方节点和控制节点之间提供单播连接。
在另一个实施例中,所述方法包括以下步骤:当所述RTCP消息中的RTP会话标识、优选为SSRC相同时,控制节点接收一个或更多个接收方RTCP消息和一个或更多个发送方RTCP消息,并且使接收的RTCP消息与发送方RTCP相关联;控制节点发送接收方RTCP消息至关联的发送方RTCP消息发起的地址和/或将发送方RTCP消息发送至关联的接收方RTCP消息发起的地址。
在又一个实施例中,所述会话描述协议为SIP协议或RTSP协议。在又一个变形中,所述控制节点为用于同步接收方节点组的同步服务器,或,其中所述控制节点包括一个或更多个用于监测所述控制消息中的信息、尤其是服务质量、数据通信信息和/或数据管理信息的功能,和/或用于根据一个或更多个预定规则修改所述控制消息中的信息的功能。
在另一方面本发明涉及用于动态转发RTCP消息的系统,所述系统包括:控制节点,其用于接收由一个或更多个接收方节点产生的接收方RTCP消息和/或由一个或更多个发送方节点产生的发送方RTCP消息中的一个或更多个;转发控制功能,其与所述控制节点相关联,所述控制功能被配置为将所述控制节点地址提供给与所述RTP流相关联的接收方节点和/或发送方节点,所述地址在会话控制协议消息中被提供至所述接收方和/或发送方节点,至少一个接收方节点被配置为发送RTCP消息至所述控制节点,使用所述会话控制协议消息中包含的所述地址。
在一个变形中,所述系统包括:至少一个发送方节点,其被配置为发送RTCP消息至所述控制节点,使用所述会话控制协议消息或HTTP消息中包含的所述地址;其中所述控制节点进一步包括:至少一个输入,其用于接收源自一个或更多个接收方节点的接收方RTCP消息和/或源自一个或更多个发送方节点的发送方RTCP消息;映射功能,其用于在所述RTCP消息内的RTP会话标识、优选为SSRC相同时,使接收的RTCP消息与发送方RTCP相关联;至少一个输出,其用于发送接收方RTCP消息至关联的发送方RTCP消息发起的地址和/或将发送方RTCP消息发送至关联的接收方RTCP消息发起的地址。
在再一个变形中,所述接收方节点被配置为在所述接收方RTCP消息中插入同步状态信息。
在一个变形的系统中,所述系统进一步包括:同步功能,其与所述控制节点关联,所述同步功能被配置为接收由在一个或更多个接收方RTCP消息中的、由一个或更多个接收方节点发送至所述控制节点的同步状态信息,并基于所述同步状态信息计算用于所述一个或更多个接收方节点的同步设置信息,所述同步设置信息允许一个或更多个接收方节点延迟至少一个RTP流。
在另一方面本发明涉及在上文描述的系统中使用的接收方节点,所述接收方节点包括:转发客户端,其被配置为用于接收包含控制节点地址的会话控制协议消息或HTTP消息并发送由所述接收方节点产生的接收方RTCP消息至所述控制节点,使用在所述会话控制协议消息中包含的所述地址;以及同步客户端,其被配置为用于产生同步状态信息,用于将所述同步状态信息插入接收方RTCP消息中并发送所述接收方RTCP消息至所述控制节点。
本发明还涉及在上文描述的系统中使用的控制节点,所述控制节点包括:至少一个输入,其用于接收源自一个或更多个接收方节点的接收方RTCP消息和/或源自一个或更多个发送方节点的发送方RTCP消息;映射功能,其用于在所述RTCP消息中的RTP会话标识、优选为SSRC相同时,使接收的RTCP消息与发送方RTCP相关联;至少一个输出,其用于发送接收方RTCP消息至关联的发送方RTCP消息发起的地址和/或将发送方RTCP消息发送至关联的接收方RTCP消息发起的地址;并且,可选地,同步功能,其被配置为用于接收一个或更多个接收方RTCP消息中的、由一个或更多个接收方节点发送至所述控制节点的同步状态信息并基于所述同步状态信息为所述一个或更多个接收方节点计算同步设置信息,所述同步设置信息允许一个或更多个接收方节点延时至少一个RTP流。
本发明进一步涉及包含软件代码部分的计算机程序产品,其被配成在一个或更多个网络节点的存储器中运行时执行上文描述的方法步骤。
将参考附图对本发明进行更进一步的说明,附图中示意性地示出了根据本发明的实施例。应当理解,本发明在任何情况下都不限于这些具体的实施例。
附图说明
图1描述了根据本发明的一个实施例的系统;
图2描述了根据本发明的一个实施例的方法的消息流程图;
图3描述了根据本发明的一个实施例的方法的可选的消息流程图;
图4图示了根据本发明的一个方面的RTCPXR报告块的可能的定义;
图5图示了根据本发明的另一个方面的RTCPXR报告块的可能的定义;
图6描述了根据本发明的另一个实施例的另一个消息流;
图7图示了根据本发明的一个实施例在IP组播场景中的消息流;
图8图示了根据本发明的另一个方面的RTCPXR报告块的可能的定义;
图9描述了根据本发明的另一个实施例的另一个流程;
图10描述了根据本发明的一个实施例的另一个系统;
图11描述了根据本发明的一个实施例的消息流;
图12描述了根据本发明的另一个实施例在IP组播场景中的流程。
具体实施方式
图1图示了由ETSITISPANTS183063和TS182027定义的基于IMS的IPTV系统100的一个实例。根据本发明的第一实施例,所述系统适于动态转发RTCP消息。所述系统包括IMS核心107,其包含一套呼叫/会话控制功能(CSCF):例如代理CSCF(P-CSCF)、询问CSCF(I-CSCF)和服务CSCF(S-CSCF)。IMS核心连接到用户设备(UE)105、用于在网络(例如广播SCF、内容点播SCF等)中控制IPTV服务的IPTV服务控制功能(SCF)106、以及包括媒体控制功能(MCF)102和媒体传送功能(MDF)103的媒体功能(MF)101,所述媒体功能(MF)101用于控制媒体内容和控制包经由传输功能(TF)104至用户设备的传送。
来自TS182027的架构中扩展有媒体同步应用服务器(MSAS)108,其被设置为执行交互目标同步功能。交互目标媒体同步意味着某一媒体的表现最终与该媒体在不同目标处的相同,例如同时在不同的目标处播放相同的视频片段或音频样本。使用同步客户端(SC)109位置处的缓冲器110,在用户设备或网络节点处的同步活动可被执行。通过指示缓冲器延迟接收到的媒体流,同步客户端与MSAS协作并协调缓冲器活动。
图1中的IPTV系统使用会话初始化协议(SIP)来设置和控制在用户终端间或用户终端和包含SCF和MF的应用服务器之间的会话。由SIP信令携带的会话描述协议(SDP)用于描述和协商会话中的媒体组件。进一步的,实时流传输协议(RTSP)用于媒体控制,其提供例如广播伎俩模式、内容点播(CoD)和网络个人视频录像机(NPVR),并且实时传输协议(RTP)用于媒体传输。
图2描述了根据本发明的一个典型实施例的用于UE接收单播-内容点播媒体流的协议流程。在本实施例中,UE的用户想接收内容点播(CoD)并以同步方式与其它UE的一个或更多个用户一起观看。为此,个别UE的CoDRTP流的播放时间需要与其它UE接收到的其它相关的CoDRTP流(例如相同的电影)的播放时间同步。
在本实例中,SIP协议用于根据ETSITS183063RTSP方法1的会话建立。在第一步中,UE发送初始化SIPINVITE消息至SCF。该SIPINVITE包括称为SyncGroupId的参数,其识别特定UE所属的同步组。在本实例中,假定SyncGroupId对于UE是已知的。然而其它实施方式也是可能的。例如,SyncGroupId也可在会话建立期间由SCF分配并在步骤4的SIP200OK消息中首次与UE通信。
同步组为UE的组,其要求关于一个或更多个指定媒体流同步。这种组的一个实例可为归属于两个不同位置的两个不同用户的两个UE,其要求以同步的方式同时观看相同的内容点播(电影)。
SyncGroupId参数可实施为会话描述协议(SDP)会话级属性,例如a=RTCP-xr:sync-group=<value>。在一个实施例中,可使用从IETFRFC3611中获知的RTCP-xr的属性域,因为其准备就关于RTCP协议的应用特定扩展的信息进行通信。SCF接收建立请求并可添加用户至同步组。然后SCF可为该同步会话选择适当的MSAS。在步骤2中,SIPINVITE消息被发送至包含SyncGroupId和选定的MSAS的网络地址两者的适当MF。该MSAS地址可包含在另一个会话级属性中,例如在来自IETFRFC3605的SDP中使用RTCP属性。发送至MF的RTCP属性也可包括端口号。MF可使用来自包含在SIP消息中的RTCP属性的信息作为新地址指令来发送关于此会话的RTCP消息。假使没有可供选择的端口号在SIPINVITE消息中进行通信,MF可根据IETFRFC3550使用默认RTCP端口号发送RTCP消息,也就是采用RTP端口号并加1。
一旦接收到会话建立(SIPINVITE)消息,MF分配SSRC标识给被请求的一个或更多个RTP流。在步骤3中,MF发送SIP200OK响应至SIPINVITE,其包括SyncGroupId和新生成的SSRC标识,用于媒体流。可使用根据IETFRFC5576的SDP中的媒体级属性发送唯一标识媒体流的SSRC。在步骤4中,SCF发送SIP200OK消息至UE,其响应最终确认。该SIP200OK消息包含被请求的媒体流的SSRC,和MSAS地址和,可选地,一个或更多个可供选择的RTCP端口号。此外,SIP消息可包含新分配的或议定的SyncGroupId。UE可使用接收到的MSAS地址和可供选择的端口信息作为新地址指令来发送关于此会话的RTCP消息。更具体地,可使用这些新地址指令、经由RTCP发送同步状态信息至MSAS,MSAS具有与一个或更多个媒体流的源(发送方)地址不同的地址。
假定没有可供选择的端口号在SIPOK消息中进行通信,UE可根据IETFRFC3550使用默认的RTCP端口号来发送RTCP消息,也就是采用RTP端口号并加1。在步骤5和6中,UE和SCF都用SIPACK消息响应接收到的SIPOK消息。
在步骤7中,RTSP控制用来建立实际媒体流,然后媒体流开始从MF流向UE。在ETSITS183063中描述了建立媒体流的方式。在步骤8中,在媒体流传送期间,UE可将同步状态信息和SyncgroupId添加至其RTCP接收方报告(RTCPRR)。例如这可使用RTCP扩展报告(RTCPXR)完成,或例如根据IETFRFC3550以SDESPRIV项目的形式完成。UE将该信息作为RTCP消息发送给MSAS。
在步骤9中,MF将其RTCP发送方报告(RTCPSR)作为RTCP消息发送给MSAS。发送媒体源(MF)和接收媒体目标(UE)两者的RTCP消息(其被MSAS接收)都有一个公共媒体流标识(SSRC)。
通过匹配收到的每个报告中的SSRC,MSAS现在可将接收自UE的RTCP消息转发至MF并将接收自MF的RTCP消息转发至UE。SSRC标识对给定RTP流是唯一的,因此包含相同SSRC标识的、来自媒体发送方(MF)和来自媒体接收方(UE)的RTCP消息可被匹配。在步骤10和11中,接收到的媒体发送方报告RTCP消息被发送至已匹配的媒体接收方报告RTCP消息发起的IP地址,反之亦然。MSAS可为在同步会话中涉及的每个UE计算设置指令,使用来自RTCP消息的同步状态信息,所述RTCP消息接收自具有相同SyncgroupId的多个UE。使用上文描述的机制,这些设置指令可包含在特定RTCPXR中并作为RTCP消息被发送至各自的UE,其中,这些设置指令包括同步组中每个UE的延迟信息。
图3图示了根据本发明的一个实施例的另一个典型消息流。在本实施例中,根据ETSITS183063RTSP方法2使用SIP和RTSP的组合来建立媒体会话。步骤1至6类似于图2描述的消息流的步骤1至6,因此不做进一步的详细描述。在图2和3中关于步骤1至6的消息流之间的唯一不同是在图3图示的方法的SIPOK消息中(步骤3和4)缺少SSRC标识。因此,图3中消息流的后续步骤稍微不同于图2中的那些。
根据ETSITS183063RTSP方法2,使用RTSPDESCRIBE消息(而不是使用SIPINVITE)设置(协商/交换)媒体级属性。因为由MF产生并分配的SSRC标识是媒体级属性,其对RTP媒体流是唯一的,MF将使用SIP200OK来响应SIPINVITE,其中,SIP200OK包含SyncGroupId和MSAS地址,而不是SSRC标识。在RTSP通道的SIP会话建立后,UE使用RTSPDESCRIBE消息来建立实际媒体流。当MF在步骤7中接收该DESCRIBE消息时,其产生并分配SSRC标识并添加该标识至在步骤8中被发送至UE的RTSP200OK消息中,以响应DESCRIBE消息。这可在包含在RTSP200OK消息中的媒体的SDP描述中被完成,使用根据IETFRFC5576的SDP中的媒体级属性。在图2和3分别图示的实施例中,从媒体流程的启动开始,包括RTCP转发机制的后续步骤都a是类似的。
一般地,同步状态信息可被最佳描述为在每个同步客户端(SC)的媒体接收的时序信息。同步客户端(SC)可位于用户设备(UE)中或位于网络中任何可测量媒体包的接收的其它点。SC与同步服务器(也称作MSAS)协作,以同步在不同接收方处接收到的流或同步在相同接收方处接收到的不同流。接收方可为媒体流的最终目标或中间目标。用于确定同步状态信息的各个采样点也称作同步点。
图4图示了用于携带同步状态信息的RTCPXR报告块的可能的定义。第一排包含头信息,该头信息包括定义了RTCPXP报告块、保留空间和块长度的定义块类型。第二排包含RTP媒体流的SSRC标识,RTCP报告块就其进行报告。第三排包含RTP流的接收方的NTP时间戳。该NTP时间戳要求64位并因此以最高和最低有效字分割。最终,给出在该NTP时间(戳)所接收的包的RTP时间戳,且给出在该NTP时间所展示(播放/呈现)的包的RTP时间戳。可基于包接收时间戳或基于实际的包展示/显示时间戳执行接收方的组同步,这取决于同步服务器的配置。由于不同类型的UE可在他们的接收界面和展示界面之间显示出不同的延迟,为了最大化用户体验,可优选使用实际展示/显示时间戳。然而,由于不是在异构网络环境中的所有用户设备都能报告实际展示次数,优选地(尽管不必要),包接收和包展示时间戳都被合并在由UE(接收方)发送至MSAS的RTCPXR报告中。
一般地,同步设置指令可被最佳地描述为:同步客户端(SC)可从中直接或间接地获得的、应当延迟多少媒体流的指令(或指示)。媒体流可为,例如广播(BC)通道、单播或多播(通道)。然后,同步客户端可进一步指示适当的缓存区来延迟相关媒体流。
图5图示了用于携带同步设置指令的RTCPXR报告块的可能的定义。在这里使用了来自IETF互联网草案draft-ietf-avt-rtcpssm-18的接收方汇总信息包的格式。在该实例中的RTCPXR块就NTP时间戳作报告,基于NTP时间戳计算所有RTP时间戳。这包含所有UE的RTP时间戳都在其上被映射的NTP时间戳,以及在该特定时间同步组中所有UE的RTP时间戳最小和最大值。报告可包含多个RTP时间戳,尽管为了交互目标同步的目的仅需要最小RTP时间戳(对应于最大延迟流)。从该信息(同步设置指令),每个同步客户端能够计算关于最大延迟数据流应延迟其数据流的大小。
作为替代方案,MSAS可只需发送任意值(低于从所有SC接收到的测得的最低RTP时间戳),SC使用任意值用于同步其数据流。这将减轻网络中固有的延迟波动并将防止SC太过频繁地重调缓存器。
图6描述了根据本发明的一个实施例的另一个典型流程。对于媒体会话建立和同步机制,该消息流类似于图2的信息流,除了图6描述的实施例图示的一种情况,在这种情况中2个UE(UE1和UE2)中的每个都从不同媒体源(MF1和MF2)接收媒体流,且其中要求同步这两个媒体流。
在本实施例中,SCF分配相同的MSAS(MSAS地址,可选地,和RTCP端口号)给会话建立期间的两个独立会话。这导致UE1和UE2与MF1和MF2都发送其RTCP消息至相同的MSAS。因为用于从MF1到UE1的媒体流的SSRC标识与用于从MF2到UE2的媒体流的SSRC标识不同,MSAS能将从MF1接收到的RTCP消息(和包含在其中的报告)与从UE1接收到的RTCP消息进行匹配,同样还能够将从MF2接收到的RTCP消息与从UE2接收到的RTCP消息进行匹配。随后MSAS可使用此处已描述的机制将RTCP消息转发至正确的UE(媒体流接收方)和MF(媒体流发送方)。
基于从由UE1和UE2接收到的RTCP消息中提取的相关同步设置信息,MSAS可计算或确定延迟设置指令,以将到达UE1(或由UE1展示/显示)的媒体流与到达UE2(或由UE2展示/显示)的媒体流同步。MSAS可将与发送至UE1的RTP流相关的同步状态信息匹配到与发送至UE2的相关的同步状态信息,因为UE1和UE2都在或已在其发送至MSAS的至少一个RTCP消息中向MSAS报告相同的SyncGroupId参数。如前所述,MSAS可在发送延迟设置指令至各自的UE之前,将延迟设置指令添加到从MF接收到的RTCP消息中。
从不同源到不同UE的不同媒体流的同步要求MF1和MF2要么在播放各自的媒体流时使用相同的RTP时间戳来代替随机偏移,要么在MSAS开始计算或确定延迟设置指令之前,RTP时间戳之间的关联是事前可知的,或已提供给MSAS。
通常在IP组播期间,RTP和RTCP包都使用组播机制发送。媒体发送方和接收方都发送其RTCP报告至相同的组播地址作为媒体通信量,但使用下一个比RTP通信量更高的端口号。在互联网草案draft-ietf-avt-rtcpssm-18中,系统被描述为用于单源组播(SSM),其中媒体仅从一个源流向多个接收方。在SSM中,媒体接收方通常不应发送(RTCP)至相同的组播地址,尤其是在具有多个观众的IPTV组播的情况下,从而避免已分配的网络资源充满不需要的非内容通信量(例如RTCP控制消息)。草案提出了用于接收方发送RTCP报告的单播机制的应用。可单播RTCP报告至所谓反馈目标。此外,引进分配源,其接收来自发送方的媒体并分配该媒体至接收方。同样,需要注意发送方和接收方之间的RTCP消息的分配。
可把反馈目标和分配源分开,但分配源的传输地址必须被配置在反馈目标中,以便反馈目标能转发RTCP消息至分配源。同样,根据本文,接收方需要被预配置有反馈目标地址,使其事前知道向何处发送其RTCP消息。换句话说,由媒体的接收方产生的RTCP消息的整个转发机制是静态的(预配置的),并且其要求网络中存在一种称为分配源的新的实体。
图7图示了在IP组播方案中的根据本发明的一个典型实施例的消息流。本实施例涉及订阅组播频道的接收方(UE)的交互目标同步。本方案可被应用在例如当两个用户想在不同位置的不同UE上以同步方式收看相同的直播内容(例如组播足球赛)。他们可具有连续的聊天会话或开放的电话线,一起欣赏比赛,而不用面临一个用户在其他用户之前数秒看到一个进球的风险。
可设想到,本文详细描述的本发明可被用作附加的“分离一起观看”同步服务的基础,其可通过不同于内容提供者的第三方发送。下文描述了根据本发明的适用于本方案的一个可能实施例。在本实施例中,在用户加入组播之前的会话建立期间开始同步服务。
根据ETSITS183063,当接收方希望加入组播时,其首先必须与适当的SCF建立会话。根据图7中的步骤1至3,可使用SIP消息这么做。在本实施例中,在步骤1中由UE发送的SIPINVITE已包含称为SyncGroupId的参数,该参数识别UE所属的同步组。可选择地,SyncGroupId可由SCF分配并在步骤2中传送至UE。
SyncGroupId可如何被打包的典型实施使用了会话描述协议(SDP)会话级属性,例如a=RTCP-xr:sync-group=<value>。SCF接收建立请求并可添加用户至适当的同步组。然后,SCF可为此同步会话选择适当的MSAS,并在对INVITE的答复、也就是在步骤2的SIP200OK消息中发送MSAS传输地址。该MSAS地址可例如包含在另一个会话级属性中,比如使用来自IETFRFC3605的SDP中的RTCP属性。可以根据IETFRFC3550、以与选择常规RTCP端口号相同的方式来选择端口号,也就是采用RTP端口号并加1。
下一步,在步骤4中,使用例如IGMP建立媒体流以订阅特定媒体流。在步骤5中,UE现在可使用接收到的来自SCF的MSAS地址(RTCP转发地址)直接向MSAS发送包含同步状态信息的RTCP消息。这些RTCP消息可以是用于发送同步状态信息和SyncGroupId的具有适当扩展的接收方报告消息。在本实施例中,所有组播接收方都接收包含相同的RTP时间戳的相同的组播流,因此MSAS不需要任何RTCP发送方报告信息来计算同步指令。同样,MSAS不需要发送方报告来确定从UE接收的RTCP消息需要发送至哪个媒体发送方,因为在SSM配置中的媒体发送方在很多情况下根本不会收到任何来自UE(媒体接收方)的RTCP消息。在本实施例中,不需要在各种RTCP消息之间进行匹配,因此包含在RTCP消息中的SSRC也不被MSAS使用。相反,如步骤6所示,使用单播RTCP消息(例如包含这样的设置的RTCP扩展报告)、仅通过使用以前收到的RTCP消息的原始地址,MSAS可仅发送其同步设置指令至适当的UE。
在特定情况下,为了组播环境中的同步,MSAS可要求发送方报告。例如因为不同的接收方收看在不同的数据流中的相同的内容,例如在一个组播频道中的高清晰度数据流对在另一个组播频道中的SD数据流。这些发送方报告可由MSAS以若干不同的方式获得。
图8例示了MSAS接收RTCP发送方报告的三个实施例。在第一个实施例中(选项1),组播的接收方添加发送方报告至接收方报告中,以作为RTCP消息发送至MSAS。所有的组播接收方在相同的组播地址而不是在不同的端口号上接收发送方报告。他们可发送这些发送报告的副本给MSAS。
在第二个实施例中(选项2),MSAS订阅组播频道。MSAS发送适当的IGMP消息,并成为组播组中的一员。然后MSAS将接收发送至该组的所有消息,包括RTCP消息。由于组播通信量的粒度仅在地址上,而不在端口号上,这意味着MSAS还将接收所有的媒体通信量。为了防止这种情况,优选地,网络过滤媒体通信量,且仅转发RTCP通信量。这相当容易想到,因为在标准配置中RTP应仅使用偶数端口号,而RTCP仅使用奇数端口号。
在第三个实施例中(选项3),媒体源(媒体功能MF)使用单播机制发送其发送方报告的副本至MSAS。
如果MSAS能接收发送方报告,其不再需要媒体源的传输地址的配置就能转发接收方报告。相反,其可使用将从媒体接收方接收到的RTCP消息的SSRC与从发送方接收到的RTCP消息的SSRC进行匹配的相同的动态机制,使用上文详细阐述的机制来确定媒体发送方的正确传输地址。
图9进一步图示了根据该可供选择的实施例的消息流。作为一个实例,在步骤5中由来自媒体接收方(UE)的MSAS接收到的RTCPRR(接收方报告)消息通过其SSRC被匹配至在步骤6中由来自媒体发送方(MF)的MSAS接收到的适当的RTCPSR(发送方报告)消息。在步骤7中,基于该匹配,MSAS转发RTCPRR消息给MF。这个动态转发机制使得不必再为MSAS预配置媒体发送方的传输地址。因此提供了一种非常灵活并简练的转发RTCP消息的方法。
要注意的是,在图9图示的实施例中,需要一些配置从而能够通过MSAS从媒体发送方接收RTCP消息。如果MSAS例如要求订阅组播地址(例如,为了获得所述RTCP消息),需要预配置有该地址或通过某一其它机制获得该地址。如果媒体发送方(MF)需要使用单播机制来发送其组播RTCP消息的副本,则需要MSAS的单播地址。如果接收方转发RTCP媒体发送方消息给MSAS,然后MSAS将不会获悉MF的传输地址,因此在那种情况下MSAS不能转发接收方报告给媒体发送方。当然,接收方可在其RTCP消息中包括媒体发送方(MF)的传输地址,但这会要求定义另一个扩展给RTCP。
图10描述了本发明的另一个实施例的原理图。具体地,图10描述了由ETSITISPANTS183064定义的、集成IPTV系统的下一代网络(NGN)的原理图。这种NGN集成IPTV系统架构的一般布局几乎与参考图1描述的IMS系统类似,且适于根据本发明的另一个实施例来动态转发RTCP消息。
NGN集成IPTV系统包含IPTV核心(IPTV-C)1007和基于HTTP的用户面向IPTV应用(CFIA)1006。IPTV-C被配置以检查连接至系统的用户设备UE1、UE21005是否已被CFIA授权,并提供包含媒体控制功能(MCF)1002和媒体传送功能(MDF)1003的媒体功能(MF)1001的适当的选择,用于控制经由传输功能(TF)1004至用户设备的、媒体内容和控制包的传送。
类似于图1中的IMS系统,NGN集成IPTV系统扩展有一个或更多个媒体同步应用服务器(MSAS)1008,其被设置为执行交互目标同步功能。使用在同步客户端(SC)1009位置处的缓存区1010,可执行在用户设备或网络节点处的同步活动。
CFIA被配置为维持活跃同步组与不同交互目标同步服务相关联,其中,连接到系统的UE可连接至不同交互目标同步服务。CFIA还可被连接到服务发现与选择(SD&S)功能(未示出),其向CFIA提供关于所述同步服务的信息,例如借助于来自电子节目菜单(EPG)的信息。
该系统使用了用于媒体控制的实时流传输协议(RTSP)和用于媒体传输的实时传输协议(RTP)。然而,对比图1中的IPTV系统,NGN集成IPTV系统使用超文本传输协议(HTTP)在用户终端间或用户终端和包含MF的应用服务器之间建立(RTP)媒体会话。作为无状态协议,HTTP提供的优点是易于实现,因为原则上它不要求会话控制状态机器的实施和维护(就像状态协议比如SIP一样)。此外,HTTP还允许以多种方式(如URI、SDP、XML等)传输参数,并可用于创建和删除同步组。下面将参考图11和12对实施和相关联的优点进行更详细的描述。
图11描述了根据本发明的一个典型实施例的、用于UE接收单播内容点播媒体流的协议流1100。类似于图2中的协议流,图11中的协议流涉及请求内容点播(CoD)的UE用户,为了与其他UE的一个或更多个用户一起观看内容而同步该内容点播(CoD)。
在本实施例中使用HTTP实现会话建立。在第一步中,UE发送包含识别同步组的SyncGroupId的HTTPGET消息,特定UE归属于CFIA。UE已知该SyncGroupId。可选择地,SyncGroupId可例如由UE在会话建立期间创建。
可使用XML、SDP、SOAP或任何其它适合的协议,在HTTP消息中传送SyncGroupId参数。适当的实施将会在下文中描述。CFIA接收HTTPGET消息并可基于SyncGroupId添加用户至适当的同步组中。然后,CFIA可选择用于该同步会话的适当的MSAS,并将地址关联至所选择的MSAS。
在步骤2中,将HTTPGET消息发送至包含SyncGroupId和所选择的MSAS的网络地址的适当的MF。可使用XML、SDP、SOAP在HTTP消息中或在另一个适合嵌入的会话级属性中传送该MSAS地址,例如来自IETFRFC3605的SDP中的RTCP属性。发送至MF的HTTP消息也可包含端口号。
MF可检索在HTTP消息中的信息,并可将包含在其中的地址和端口信息视为发送关于该会话的RTCP消息至该地址的指令。
一旦收到HTTP消息,MF分配SSRC标识给被请求的RTP流。在步骤3中,MF回送HTTP200OK消息至CFIA,其中200OK消息包含SyncGroupId和用于媒体流的新生成的SSRC标识两者。
在步骤4中,CFIA可发送200OK消息至UE,该UE可响应最终确认。该200OK消息包含被请求的媒体流的SSRC和MSAS地址,以及任意可选择的RTCP端口号。此外,该HTTP消息可包含新分配的或议定的SyncGroupId。UE可将接收到的MSAS地址和可选择的端口信息视为发送关于该会话的RTCP消息至该地址的指令。更具体的,可使用这些新地址指令、通过RTCP消息发送同步状态信息至MSAS,MSAS具有与媒体流的源(发送方)的地址不同的地址。
其后,在步骤5-9中,使用RTSP控制来设置实际媒体流,且使用RTCP接收方报告(RTCPRR)和RTCP扩展报告(RTCPXR),媒体流开始从MF流向UE。这些步骤等同于图2中描述的和TS183063中更详细描述的过程。
类似地,HTTP可被用于UE通过首先建立与CFIA的HTTP会话来请求加入组播。图12中描述了这个过程并且这个过程类似于图7中基于SIP的消息流。
HTTP可使用不同的协议传送参数,例如SyncGroupId、MSAS地址等。在一个实施例中,可使用可扩展的标示语言协议(XML)来传送这些参数。例如,用于在UE和CFIA之间发送参数的HTTP消息可包含XML正文。例如UE可使用下文的HTTP请求从CFIA请求同步信息:
GEThttp://cfia.etsi.org/syncgroup/?SyncGroupId=217a5bd0
HTTP/1.1
User-Agent:IPTVClient/1.0
可选择地,URL可有另一种格式,例如http://cfia.etsi.org/syncgroup/217a5bd0HTTP/1.1。作为响应,CFIA可通过HTTP响应发送被请求的信息,HTTP响应包含具有与SyncGroupId217a5bd0相关联的参数的XML正文:
HTTP/1.1200OK
Server:CFIA/1.0
Content-Type:application/vnd.etsi.iptvsyncgroup+xml
Content-Length:35
<?xmlversion="l.0"?>
<syncgroupid="217a5bd0">
<rtcpssrc="AF"recv="192.168.1.100:1234"/>
</syncgroup>
在本实例中,XML正文识别与该同步会话相关联的SSRC和MSAS(recv)的IP地址和端口号。与XML正文相关联的XML架构如下:
应当理解,这种XML架构的多种变形都是可行的,以获得相同或类似的XML正文。
在另一个实施例中,简单对象访问协议(SOAP)可被用来传送参数。至于消息格式,SOAP信赖可扩展标示语言(XML)。HTTP请求的一个可能的SOAP实施和在UE和CFIA之间传送的相关联的HTTP响应如下:
在又一个实施例中,通过SDP正文以类似于SIP实例中使用的方式来传送参数。那样的话,HTTP请求的可能的SDP实施和在UE和CFIA之间传送的相关联的HTTP响应如下:
因此,HTTP提供了一种在UE、CFIA和MF之间非常灵活的传送参数、尤其是同步参数的方式。HTTP还允许更高的灵活性,这是因为在进一步的变形中,HTTPPUT(或POST)和HTTPDELETE消息可允许UE加入或离开现有的同步组。加入现有的同步组的一个实施例如下:
在这个实施例中,UE可发送HTTPPUT消息,其请求CFIA添加userBetsi.org至同步组217a5bd0中。反过来,UE接收CIFA的UE被添加的确认。进一步地,响应消息包含关于SSRC的信息和与同步组相关联的MSAS的地址。可选择地,响应消息包括进一步的信息,例如同步组中的参与者,其在这种情况下被识别为userAetsi.org和userBetsl.org。
可通过发送HTTPDELETE信息DELETEhttp://m8as.etsi.org/syncgrouρ/217a5bd0/parbicipant:s/userAetsi.orgHTTP/1.1,User-Agent:IPTVClient/1.0至CFIA来实现离开现有同步组。
类似地,可通过发送HTTPPOST消息至CFIA来创建新的同步组:
本发明的实施例可作为用于与计算机系统一起使用的程序产品来实现。所述程序产品的程序定义实施例(包括此处所描述的方法)的功能,并且可包含在各种计算机可读存储媒介中。示例性的计算机可读存储媒介包括但不限于:(i)在其上永久存储信息的不可写存储媒介(例如,计算机中的只读存储器装置,比如可由CD-ROM驱动器读取的CD-ROM盘、闪存、ROM芯片或固态非易失性半导体存储器);以及(ii)在其上存储可改写信息的可写存储媒介(例如,软盘驱动或硬盘驱动内的软盘或任何类型的固态随机访问半导体存储器)。
应当理解,与任意一个实施例相关描述的任意特征都可单独使用,或与所描述的其它特征结合,并且还可与任意其它实施例的一个或更多个特征或任意其它实施例的任意组合结合使用。此外,在不脱离随附的权利要求书中所定义的本发明的范围的情况下,也可以采用上文未描述的等同物和修改。
Claims (16)
1.一种动态转发第一协议的消息的方法,所述第一协议用于提供关于媒体流的控制和管理信息,所述消息与一个或更多个基于第二协议的多媒体流相关联,所述第二协议被设置用于在基于IP的网络上流式传输多媒体数据,每个流与媒体会话相关联并与发送方节点和一个或更多个接收方节点相关联,所述方法包括以下步骤:
向至少一个流分配至少一个控制节点;
将所述控制节点的地址提供给与所述流相关联的接收方节点,所述地址在会话控制协议消息或HTTP消息中被提供至所述接收方节点,并且所述地址不同于相关联的发送方节点的地址;以及,
所述接收方节点发送所述第一协议的接收方消息至所述控制节点,使用在所述会话控制协议消息或HTTP消息中包含的所述地址;
其中所述第一协议为RTCP,所述第二协议为RTP,并且所述流为RTP流。
2.如权利要求1所述的方法,其中所述方法进一步包括以下步骤:
向所述接收方节点提供与所述RTP流相关联的组同步标识;以及
在接收方RTCP消息中发送所述组同步标识至所述控制节点。
3.如权利要求1所述的方法,其中所述方法进一步包括以下步骤:
所述接收方节点生成同步状态信息;
在接收方RTCP消息中发送所述同步状态信息至所述控制节点,所述控制节点包括同步功能,所述同步功能用于将与所述发送方RTCP消息相关联的RTP流与已分配给所述控制节点的一个或更多个其它RTP流同步。
4.如权利要求3所述的方法,所述方法进一步包括以下步骤:
所述同步功能使用所述同步状态信息来计算同步设置信息;
所述控制节点发送所述同步设置信息至所述接收方节点,
所述接收方节点使用所述同步设置信息来指示与所述接收方节点相关联的延迟缓冲。
5.如权利要求1-4中任一项所述的方法,所述方法进一步包括以下步骤:
将所述控制节点的地址提供给与所述RTP流相关联的所述发送方节点,所述地址在会话控制协议消息中被提供给所述发送方节点;
所述发送方节点将发送方RTCP消息发送至所述控制节点,使用包含在所述会话控制协议消息中的所述地址。
6.如权利要求5所述的方法,所述方法进一步包括以下步骤:
当所述RTCP消息中的SSRC标识相同时,控制节点接收一个或更多个接收方RTCP消息和一个或更多个发送方RTCP消息,并将接收方RTCP消息与发送方RTCP消息相关联;
控制节点发送接收方RTCP消息至相关联的发送方RTCP消息发起的地址和/或将发送方RTCP消息发送至相关联的接收方RTCP消息发起的地址。
7.如权利要求6所述的方法,其中所述接收方RTCP消息中的至少一个包括同步状态信息,所述方法进一步包括以下步骤:
从所述接收方RTCP消息中移除所述同步状态信息;以及,
发送所述接收方控制消息至所述相关联的发送方节点。
8.如权利要求6所述的方法,其中所述方法进一步包括以下步骤:
所述同步功能提供同步设置信息;以及,
在发送方RTCP消息中发送所述同步设置信息至所述接收方节点。
9.如权利要求1-4中任一项所述的方法,所述方法进一步包括以下步骤:
至少一个发送方节点组播多个所述RTP流和关联的发送方RTCP消息中的至少一个至一个或更多个接收方节点。
10.如权利要求9所述的方法,所述方法进一步包括以下步骤:
接收方节点发送所述RTCP消息中的至少一个至所述控制节点。
11.如权利要求9所述的方法,所述方法包括以下步骤:
发送将控制节点加入与所述组播相关联的成员组的请求,或为了提供发送方RTCP消息至所述控制节点而在发送方节点和控制节点之间提供单播连接。
12.如权利要求9所述的方法,所述方法包括以下步骤:
控制节点接收一个或更多个接收方RTCP消息和一个或更多个发送方RTCP消息,并且当所述RTCP消息中的SSRC标识相同时,将接收方RTCP消息与发送方RTCP消息相关联;
控制节点发送接收方RTCP消息至相关联的发送方RTCP消息发起的地址和/或将发送方RTCP消息发送至相关联的接收方RTCP消息发起的地址。
13.一种动态转发第一协议的消息的系统,所述第一协议用于提供关于媒体流的控制和管理信息,所述系统包括:
控制节点,其用于接收由一个或更多个接收方节点产生的第一协议的接收方消息和/或由一个或更多个发送方节点产生的第一协议的发送方消息中的一个或更多个;
转发控制功能,其与所述控制节点相关联,所述控制功能被配置为将所述控制节点的地址提供给与基于第二协议的媒体流相关联的接收方节点和/或发送方节点,所述地址在会话控制协议消息或HTTP消息中被提供至所述接收方和/或发送方节点,所述第二协议被设置为用于在基于IP的网络上流式传输多媒体数据;
至少一个接收方节点,其被配置为发送第一协议的消息至所述控制节点,使用包含在所述会话控制协议消息或HTTP消息中的所述地址;
其中所述第一协议为RTCP,所述第二协议为RTP,并且所述流为RTP流。
14.如权利要求13所述的系统,所述系统进一步包括:
至少一个发送方节点,其被配置为发送RTCP消息至所述控制节点,使用包含在所述会话控制协议消息或HTTP消息中的所述地址;
其中所述控制节点进一步包括:
至少一个输入,其用于接收源自一个或更多个接收方节点的接收方RTCP消息和/或源自一个或更多个发送方节点的发送方RTCP消息;
映射功能,其用于在当所述RTCP消息中的SSRC标识相同时,使接收方RTCP消息与发送方RTCP消息相关联;
至少一个输出,其用于发送接收方RTCP消息至相关联的发送方RTCP消息发起的地址和/或将发送方RTCP消息发送至相关联的接收方RTCP消息发起的地址。
15.一种在如权利要求13或14所述的系统中使用的接收方节点,所述接收方节点被配置为用于接收包含控制节点地址的会话控制协议消息或HTTP消息,并用于发送由所述接收方节点产生的接收方RTCP消息至所述控制节点,使用包含在所述会话控制协议消息中的所述地址,所述接收方节点进一步包括:
同步客户端,其被配置为用于产生同步状态信息,用于将所述同步状态信息插入接收方RTCP消息中,并发送所述接收方RTCP消息至所述控制节点。
16.一种在如权利要求13或14所述的系统中使用的控制节点,所述控制节点包括:
至少一个输入,其用于接收源自一个或更多个接收方节点的接收方RTCP消息和/或源自一个或更多个发送方节点的发送方RTCP消息;
映射功能,其用于在当所述RTCP消息中的SSRC标识相同时,使接收方RTCP消息与发送方RTCP消息相关联;
至少一个输出,其用于发送接收方RTCP消息至相关联的发送方RTCP消息发起的地址和/或将发送方RTCP消息发送至相关联的接收方RTCP消息发起的地址;并且,可选地,
同步功能,其被配置为用于接收在一个或更多个接收方RTCP消息中的、由一个或更多个接收方节点发送至所述控制节点的同步状态信息,并基于所述同步状态信息为所述一个或更多个接收方节点计算同步设置信息,所述同步设置信息允许所述一个或更多个接收方节点延时至少一个RTP流。
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP09010396.1 | 2009-08-12 | ||
EP09010396 | 2009-08-12 | ||
EP09013566.6 | 2009-10-28 | ||
EP09013566 | 2009-10-28 | ||
PCT/EP2010/061135 WO2011018368A1 (en) | 2009-08-12 | 2010-07-30 | Dynamic rtcp relay |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102577304A CN102577304A (zh) | 2012-07-11 |
CN102577304B true CN102577304B (zh) | 2015-12-09 |
Family
ID=43126862
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201080035640.6A Active CN102577304B (zh) | 2009-08-12 | 2010-07-30 | 动态转发第一协议的消息的方法和系统及其控制节点 |
Country Status (6)
Country | Link |
---|---|
US (1) | US20120144056A1 (zh) |
EP (1) | EP2465241A1 (zh) |
JP (1) | JP5675807B2 (zh) |
KR (1) | KR101439709B1 (zh) |
CN (1) | CN102577304B (zh) |
WO (1) | WO2011018368A1 (zh) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9531579B2 (en) | 2010-08-10 | 2016-12-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Session control for media stream transmission |
US9178640B2 (en) * | 2010-08-20 | 2015-11-03 | Qualcomm Incorporated | Determination of network synchronization |
US9143539B2 (en) * | 2010-11-18 | 2015-09-22 | Interdigital Patent Holdings, Inc. | Method and apparatus for inter-user equipment transfer of streaming media |
US9065744B2 (en) * | 2011-06-20 | 2015-06-23 | Netscout Systems, Inc. | Performance optimized and configurable state based heuristic for the classification of real-time transport protocol traffic |
DE102011078021A1 (de) * | 2011-06-22 | 2012-12-27 | Institut für Rundfunktechnik GmbH | Vorrichtung und Verfahren zum Schalten von Echtzeitmedienströmen |
CN104079870B (zh) * | 2013-03-29 | 2017-07-11 | 杭州海康威视数字技术股份有限公司 | 单路视频多路音频的视频监控方法及系统 |
US9300713B2 (en) | 2013-08-16 | 2016-03-29 | Qualcomm Incorporated | Clock synchronization for multi-processor/multi-chipset solution |
KR20150033827A (ko) * | 2013-09-24 | 2015-04-02 | 삼성전자주식회사 | 영상표시장치, 서버 및 그 동작방법 |
CN104660546B (zh) * | 2013-11-18 | 2018-01-19 | 北京信威通信技术股份有限公司 | 一种基于ssrc的收发rtp包的方法 |
GB2518921B (en) * | 2014-03-24 | 2016-02-17 | Imagination Tech Ltd | High definition timing synchronisation function |
CN104539480B (zh) * | 2014-12-23 | 2018-08-10 | 深圳市有信网络技术有限公司 | 一种流媒体传输质量监测方法及其系统 |
EP3284233B1 (en) * | 2015-04-14 | 2019-02-27 | Telefonaktiebolaget LM Ericsson (publ) | In-session communication for service application |
WO2017052436A1 (en) | 2015-09-25 | 2017-03-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and interworking network node for enabling bit rate adaption in media streaming |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6332163B1 (en) * | 1999-09-01 | 2001-12-18 | Accenture, Llp | Method for providing communication services over a computer network system |
CN101277179A (zh) * | 2007-03-29 | 2008-10-01 | 华为技术有限公司 | 发送、接收通知消息的方法、装置及系统 |
CN101453349A (zh) * | 2007-12-03 | 2009-06-10 | 华为技术有限公司 | 一种处理实时流媒体协议的方法及系统 |
Family Cites Families (47)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6477580B1 (en) * | 1999-08-31 | 2002-11-05 | Accenture Llp | Self-described stream in a communication services patterns environment |
US6724736B1 (en) * | 2000-05-12 | 2004-04-20 | 3Com Corporation | Remote echo cancellation in a packet based network |
US7221660B1 (en) * | 2000-08-08 | 2007-05-22 | E.F. Johnson Company | System and method for multicast communications using real time transport protocol (RTP) |
US8010469B2 (en) * | 2000-09-25 | 2011-08-30 | Crossbeam Systems, Inc. | Systems and methods for processing data flows |
US20110214157A1 (en) * | 2000-09-25 | 2011-09-01 | Yevgeny Korsunsky | Securing a network with data flow processing |
US20070192863A1 (en) * | 2005-07-01 | 2007-08-16 | Harsh Kapoor | Systems and methods for processing data flows |
EP1340381A2 (en) * | 2000-10-27 | 2003-09-03 | Polycom Israel Ltd. | Apparatus and method for improving the quality of video communication over a packet-based network |
US6934756B2 (en) * | 2000-11-01 | 2005-08-23 | International Business Machines Corporation | Conversational networking via transport, coding and control conversational protocols |
US7684565B2 (en) * | 2001-01-16 | 2010-03-23 | General Instrument Corporation | System for securely communicating information packets |
GB0103381D0 (en) * | 2001-02-12 | 2001-03-28 | Eyretel Ltd | Packet data recording method and system |
US7016339B1 (en) * | 2001-02-22 | 2006-03-21 | 3Com Corporation | Method and apparatus for real time protocol feedback mixer traversal |
EP1490767B1 (en) * | 2001-04-05 | 2014-06-11 | Audible Magic Corporation | Copyright detection and protection system and method |
US7237108B2 (en) * | 2001-09-26 | 2007-06-26 | General Instrument Corporation | Encryption of streaming control protocols and their headers |
DE10148875A1 (de) * | 2001-10-04 | 2003-04-24 | Siemens Ag | Verfahren zum Aktuellhalten von Software auf verschiedenen Endgeräten |
JP3786936B2 (ja) * | 2003-06-20 | 2006-06-21 | 日本電信電話株式会社 | パケット転送システム、パケット監視方法、呼制御装置、パケット転送装置、およびモニタ装置 |
FR2844938B1 (fr) * | 2002-09-23 | 2005-01-14 | Cit Alcatel | Procede d'interception de donnees de controle, notamment de qualite de service, et dispositif associe |
USRE44782E1 (en) * | 2002-11-11 | 2014-02-25 | Supracomm, Inc. | Multicast videoconferencing |
US7586938B2 (en) * | 2003-10-24 | 2009-09-08 | Microsoft Corporation | Methods and systems for self-describing multicasting of multimedia presentations |
US20050002402A1 (en) * | 2003-05-19 | 2005-01-06 | Sony Corporation And Sony Electronics Inc. | Real-time transport protocol |
US7417989B1 (en) * | 2003-07-29 | 2008-08-26 | Sprint Spectrum L.P. | Method and system for actually identifying a media source in a real-time-protocol stream |
US7643414B1 (en) * | 2004-02-10 | 2010-01-05 | Avaya Inc. | WAN keeper efficient bandwidth management |
US7979368B2 (en) * | 2005-07-01 | 2011-07-12 | Crossbeam Systems, Inc. | Systems and methods for processing data flows |
US20070019645A1 (en) * | 2005-07-05 | 2007-01-25 | Deepthy Menon | Method and system for multicasting data in a communication network |
US7587507B2 (en) * | 2005-07-22 | 2009-09-08 | Microsoft Corporation | Media recording functions in a streaming media server |
EP1758334A1 (en) * | 2005-08-26 | 2007-02-28 | Matsushita Electric Industrial Co., Ltd. | Establishment of media sessions with media adaptation |
US20080119165A1 (en) * | 2005-10-03 | 2008-05-22 | Ajay Mittal | Call routing via recipient authentication |
KR20080068690A (ko) * | 2005-10-07 | 2008-07-23 | 에이저 시스템즈 인크 | 상보적 지정 파일을 이용하여 실시간전송프로토콜 출구스트리밍을 위한 방법 및 장치 |
US8045542B2 (en) * | 2005-11-02 | 2011-10-25 | Nokia Corporation | Traffic generation during inactive user plane |
JP2007274019A (ja) * | 2006-03-30 | 2007-10-18 | Matsushita Electric Ind Co Ltd | デジタル方式情報配信システムおよびその方法 |
US8510404B2 (en) * | 2006-04-03 | 2013-08-13 | Kinglite Holdings Inc. | Peer to peer Synchronization system and method |
US7912075B1 (en) * | 2006-05-26 | 2011-03-22 | Avaya Inc. | Mechanisms and algorithms for arbitrating between and synchronizing state of duplicated media processing components |
US8306063B2 (en) * | 2006-08-29 | 2012-11-06 | EXFO Services Assurance, Inc. | Real-time transport protocol stream detection system and method |
FR2917937B1 (fr) * | 2007-06-25 | 2009-10-16 | Alcatel Lucent Sas | Procede de communication avec interception de messages de controle |
US20090055540A1 (en) * | 2007-08-20 | 2009-02-26 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods and Systems for Multicast Control and Channel Switching for Streaming Media in an IMS Environment |
US20090135735A1 (en) | 2007-11-27 | 2009-05-28 | Tellabs Operations, Inc. | Method and apparatus of RTP control protocol (RTCP) processing in real-time transport protocol (RTP) intermediate systems |
KR20100096220A (ko) * | 2007-12-03 | 2010-09-01 | 노키아 코포레이션 | 패킷 생성 장치, 인코딩 신호의 동기화 장치, 패킷 생성 방법 및 인코딩 신호의 동기화 방법 |
CN101889422B (zh) * | 2007-12-05 | 2014-07-09 | 皇家Kpn公司 | 用于使终端的输出同步的方法及系统 |
US8307029B2 (en) * | 2007-12-10 | 2012-11-06 | Yahoo! Inc. | System and method for conditional delivery of messages |
US7716310B2 (en) | 2007-12-21 | 2010-05-11 | Telefonaktiebolaget L M Ericsson (Publ) | Method and Internet Protocol Television (IPTV) content manager server for IPTV servicing |
JP2009177620A (ja) * | 2008-01-25 | 2009-08-06 | Nec Corp | 通信制御装置、通信システム、通信制御方法及び通信制御プログラム |
GB0802294D0 (en) * | 2008-02-07 | 2008-03-12 | British Telecomm | Communications network |
US8165090B2 (en) * | 2008-05-15 | 2012-04-24 | Nix John A | Efficient handover of media communications in heterogeneous IP networks |
US20110138022A1 (en) * | 2008-08-12 | 2011-06-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Fast Content Switching in a Communication System |
CN101364999B (zh) * | 2008-09-18 | 2012-07-04 | 华为技术有限公司 | 一种基于流的服务质量处理的方法、设备及系统 |
US7953883B2 (en) * | 2009-01-27 | 2011-05-31 | Cisco Technology, Inc. | Failover mechanism for real-time packet streaming sessions |
US9525710B2 (en) * | 2009-01-29 | 2016-12-20 | Avaya Gmbh & Co., Kg | Seamless switch over from centralized to decentralized media streaming |
US9438741B2 (en) * | 2009-09-30 | 2016-09-06 | Nuance Communications, Inc. | Spoken tags for telecom web platforms in a social network |
-
2010
- 2010-07-30 EP EP10737911A patent/EP2465241A1/en not_active Withdrawn
- 2010-07-30 CN CN201080035640.6A patent/CN102577304B/zh active Active
- 2010-07-30 JP JP2012524187A patent/JP5675807B2/ja active Active
- 2010-07-30 KR KR1020127005978A patent/KR101439709B1/ko active IP Right Grant
- 2010-07-30 WO PCT/EP2010/061135 patent/WO2011018368A1/en active Application Filing
- 2010-07-30 US US13/389,725 patent/US20120144056A1/en not_active Abandoned
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6332163B1 (en) * | 1999-09-01 | 2001-12-18 | Accenture, Llp | Method for providing communication services over a computer network system |
CN101277179A (zh) * | 2007-03-29 | 2008-10-01 | 华为技术有限公司 | 发送、接收通知消息的方法、装置及系统 |
CN101453349A (zh) * | 2007-12-03 | 2009-06-10 | 华为技术有限公司 | 一种处理实时流媒体协议的方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
KR20120054050A (ko) | 2012-05-29 |
US20120144056A1 (en) | 2012-06-07 |
WO2011018368A1 (en) | 2011-02-17 |
CN102577304A (zh) | 2012-07-11 |
JP2013502123A (ja) | 2013-01-17 |
JP5675807B2 (ja) | 2015-02-25 |
EP2465241A1 (en) | 2012-06-20 |
KR101439709B1 (ko) | 2014-09-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102577304B (zh) | 动态转发第一协议的消息的方法和系统及其控制节点 | |
Montagud et al. | Inter-destination multimedia synchronization: schemes, use cases and standardization | |
US8839340B2 (en) | Method, system and device for synchronization of media streams | |
US8332527B2 (en) | Streaming media network system, streaming media service realization method and streaming media service enabler | |
EP2979422B1 (en) | Content delivery system and method | |
US8514705B2 (en) | Method and system for synchronizing a group of end-terminals | |
CN101401427B (zh) | 用于iptv系统的时间偏移和追踪播放 | |
US8307049B2 (en) | Method and device for obtaining media description information of IPTV services | |
CN102356623B (zh) | 在网络中管理关联的会话 | |
US20100269132A1 (en) | Method and System For Inserting Advertisements In A Content Stream In Internet Protocol Television (IPTV) | |
US20130073684A1 (en) | Method and Apparatus For The Transmission of Multimedia Content | |
JP2014520442A (ja) | 空間的にセグメント化されたコンテンツの配信 | |
CN105656910B (zh) | 媒体传输服务器、媒体传输系统、用户终端和媒体传输方法 | |
Boronat et al. | The need for inter-destination synchronization for emerging social interactive multimedia applications | |
CN101883333B (zh) | 获取指定用户实时媒体播放信息的方法、系统和装置 | |
CN101483532B (zh) | 一种媒体流复制的方法、系统及设备 | |
US8239902B2 (en) | Method and apparatus for bandwidth optimization of a content on demand service | |
Patnaik et al. | A Framework for Converged Video Services in the IMS |
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: 1171587 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: WD Ref document number: 1171587 Country of ref document: HK |