CN101459572B - 一种在ip分组网中实现关联媒体流的方法及装置 - Google Patents
一种在ip分组网中实现关联媒体流的方法及装置 Download PDFInfo
- Publication number
- CN101459572B CN101459572B CN2007100324208A CN200710032420A CN101459572B CN 101459572 B CN101459572 B CN 101459572B CN 2007100324208 A CN2007100324208 A CN 2007100324208A CN 200710032420 A CN200710032420 A CN 200710032420A CN 101459572 B CN101459572 B CN 101459572B
- Authority
- CN
- China
- Prior art keywords
- sdp
- media stream
- information
- entity
- medium
- 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.)
- Expired - Fee Related
Links
Images
Abstract
本发明实施例公开了一种在IP分组网中实现关联媒体流的方法，包括：业务提供实体获取第一客户端会话信息和第二客户端会话信息；所述业务提供实体根据所述第一客户端会话信息和所述第二客户端会话信息生成关联关系；所述业务提供实体将所述关联关系发送给媒体处理实体。相应地，本发明实施例还公开了一种业务控制实体。本发明的实施例可以实现在诸如IPTV应用中将不同的客户端的媒体流进行关联，以实现诸如客户端的媒体流共享等功能。
Description
技术领域
本发明涉及媒体流传送领域，更为具体地，本发明涉及一种在IP分组网中实现关联媒体流的方法及装置。
背景技术
网络电视(Internet Protocol Television，IPTV)是一种利用宽带有线电视网，集互联网、多媒体、通讯等多种技术于一体，向家庭用户提供包括数字电视在内的多种交互式服务的崭新技术。用户在家中可以使用个人计算机(Personal Computer，PC)或者通过网络机顶盒在普通电视机上享受IPTV业务，也可以通过移动终端享受IPTV业务。IPTV使用传输控制协议(Transmission Control Protocol，TCP)/网际协议(Internet Protocol，IP)作为承载协议进行单播、广播或组播视频业务，有效地将电视网、电话网和互联网三个领域结合在一起，是三网融合最具代表性的业务，正受业界越来越多的关注。
基于IMS实现的IPTV(IMS based IPTV)就是在IP多媒体子系统(IPMultimedia Subsystem，IMS)的整体架构下提供IPTV业务，以充分利用IMS网络中已有的注册、认证、路由、会话控制与建立、业务触发、计费、端到端服务质量(Quality of Service，QoS)保证等机制来为用户提供流媒体业务及融合流媒体和实时会话业务的多媒体业务，即：用户到内容的多媒体会话是通过IMS已有的会话控制机制来完成，在建立会话过程中，需要为媒体流的传送预留承载资源。
在IMS中，会话建立和媒体协商是通过会话发起协议(Session Initiation Protocol，SIP)与实时传输协议(Realtime Transport Protocol，RTP)/实时传输控制协议(Real time Transport Control Protocol，RTCP)、会话描述协议(Session Description Protocol，SDP)、实时流协议(Real Time Streaming Protocol，RTSP)、DNS等协议配合完成的。其中，SIP是由IETF(Internet 工程任务组)制定的多媒体通信系统框架协议之一，用于建立、改变或结束多媒体会话的应用层协议。RTSP是应用级协议，控制实时数据的发送，其提供了一个可扩展框架，使实时数据(如音频和视频)的受控、点播传送成为可能。数据源包括现场数据(如直播)与存储在剪辑中的数据(如VOD等)。该协议目的在于控制多个数据传送会话，提供选择传送通道的方法，传送通道如用户数据报协议(User Datagram Protocol，UDP)、组播UDP与TCP，提供基于RTP选择传输机制的方法。
IETF的一个草案(draft-boulton-sip-control-framework-04.txt)定义了一个媒体控制的通用架构。如图1所示，在所述通用架构中定义了三个逻辑角色：
控制服务器(Control Server)：接收控制客户端(Control Client)的媒体处理请求，执行具体的媒体处理操作，如：放音、录音、媒体混合等。
控制客户端(Control Client)：向Control Server发送消息，请求处理媒体资源。
媒体控制通道(Control Channel)：Control Client通过SIP与Control Server间的SDP交互、协商建立的一个用于传递控制消息的通道，基于可靠连接。
图2为欧洲电信标准协会(European Telecommunications Standards Institute，ETSI)电信和互联网融合业务及高级网络协议(Telecommunications and Internet Converged Services and Protocols for Advanced Networking，TISPAN)定义的IMS based IPTV的业务功能架构，其中，IPTV媒体控制功能(IPTV Media Control Function)负责到用户设备(UE)媒体流的控制与交付(Delivery)，从功能角度分解为媒体控制功能(Media Control Function，MCF)和媒体交付功能(Media Delivery Function，MDF)。媒体交付功能通常是一些媒体服务器，在媒体控制功能的控制下向用户终端或用户设备(UE)传送用户需要的媒体流。媒体控制功能还能接收和处理用户的播放控制(通常使用RTSP协议实现)，例如媒体的快进、后退、暂停、定位等操作。IPTV业务控制功能(IPTV Service Control Function，IPTV SCF)负责向UE提供业务，包括：会话初始化、用户账户控制、控制MCF提供相应的媒体功能等。SCF通过y2接口与MCF交互，请求媒体处理服务。
在流媒体应用中，如视频共享，需要通过将源用户终端正在接收的媒体流复制到其它终端的方式实现，此时需要对源媒体流与目的媒体流进行关联实现媒体流的复制，发明人在实现本发明的过程中发现在IP分组网中，目前还没有技术可以实现对媒体流进行关联。
发明内容
本发明实施例所要解决的技术问题在于，提供一种在IP分组网中实现关联媒体流的方法及装置，可以实现不同媒体流之间的关联。
为解决上述技术问题，本发明实施例的一种在IP分组网中实现关联媒体流的方法，包括：
业务提供实体获取源客户端会话信息和目的客户端会话信息；
所述业务提供实体根据所述源客户端会话信息和所述目的客户端会话信息生成关联关系包括：由所述第一客户端会话信息和所述第二客户端会话信息生成聚合的SDP信息，在所述聚合的SDP信息中包含至少一个媒体复制组，从每一媒体复制组中确定一个媒体流作为输入媒体流；或通过复制逻辑来生成所述关联关系，在所述复制逻辑中确定一个媒体流为输入媒体流，以及与所述输入媒体流对应的至少一个输出媒体流；
所述业务提供实体将所述关联关系发送给媒体处理实体。
相应地，一种业务控制实体，用于在IP分组网中实现关联媒体流，包括：
会话信息获取单元，用于获取第一客户端会话信息和第二客户端会话信息；
关联处理单元，用于为会话信息获取单元所获取的第一客户端会话信息和第二客户端会话信息生成关联关系，包括：由所述第一客户端会话信息和所述第二客户端会话信息生成聚合的SDP信息，在所述聚合的SDP信息中包含至少一个媒体复制组，从每一媒体复制组中确定一个媒体流作为输入媒体流；或者通过复制逻辑来生成所述关联关系，在所述复制逻辑中确定一个媒体流为输入媒体流，以及与所述输入媒体流对应的至少一个输出媒体流；
关联关系发送单元，用于将关联处理单元所生成的所述关联关系发送给媒体处理实体。
本发明实施例的在IP分组网中实现关联媒体流的方法及装置，通过将第一客户端会话信息和第二客户端会话信息中的媒体流进行关联，可以很方便地应用于媒体流(如视频等)的共享、会话媒体流监控等多种场景中。
附图说明
图1是现有的IETF定义的一个媒体控制的通用架构的示意图；
图2是现有的TISPAN中IMS-based IPTV业务功能架构的示意图；
图3是本发明的应用环境的原理模型示意图；
图4是本发明在IP分组网中实现关联媒体流的业务控制实体的实施例的结构示意图；
图5是图4中关联处理模块的一种实施例的结构示意图；
图6是图4中关联处理模块的另一种实施例的结构示意图；
图7是本发明在IP分组网中实现关联媒体流的方法的第一具体实施例流程图；
图8是本发明在IP分组网中实现关联媒体流的方法的第二具体实施流程图；
图9是本发明在IP分组网中实现关联媒体流的方法的第三具体实施流程图。
图10是本发明的第一应用例流程图；
图11是本发明的第二应用例流程图；
图12是本发明的第三应用例流程图。
具体实施方式
下面结合附图以优选实施例对本发明进行详细说明。
如图3所示，是本发明的应用环境的原理模型示意图；其中，源客户端1首先需要与业务控制实体2建立SIP会话，并接收媒体处理实体3的所发送的媒体流；且在需要将正在接收的媒体流复制至其他客户端(目的客户端4)时，发送媒体流关联复制请求指示进行媒体流的关联复制，所述关联复制请求至少包括进行关联复制的属性标识、需要复制的源媒体流信息及目的客户端标识；
业务控制实体2，用于在获得所述媒体流关联复制请求时，获得目的客户端会话信息与及源客户端会话信息，对所获得的目的客户端会话信息与源客户端会话信息中的源媒体流与输出媒体流进行关联，并指示媒体处理实体3将指定的媒体流复制发送给所述目的客户端4；
媒体处理实体3，用于根据与所述业务控制实体2的指示，将所述源媒体流复制发送给所述目的客户端4。
具体进行关联的过程及细节会在下文中进行说明。
如图4所示，是本发明在IP分组网中实现关联媒体流的业务控制实体的第一具体实施例结构图。其中包括：
会话信息获取单元20，用于获取第一客户端会话信息和第二客户端会话信息；其中，该第一客户端会话信息为第一客户端与业务提供实体建立媒体会话的SDP信息，第二客户端会话信息为第二客户端与业务提供实体建立媒体会话的SDP信息，在具体实施时，该第一客户端可以是源客户端，该第二客户端可以是目的客户端。
关联处理单元22，用于根据会话信息获取单元20所获取的源客户端会话信息和目的客户端会话信息生成关联关系；
关联关系发送单元24，用于将关联处理单元22所生成的所述关联关系发送给媒体处理实体，其中，该关联关系可以通过SIP消息或媒体控制消息发送给媒体处理实体。
参见图5所示，为图4中关联处理模块22的一种实施例的结构示意图；其中，关联处理模块22进一步包括：
SDP信息聚合单元220，用于根据所述第一客户端会话信息(SDP信息)和所述第二客户端会话信息(SDP信息)生成聚合的SDP信息，其中，每个聚合的SDP信息中至少包括一个媒体复制组，在该媒体复制组中包括两个以上的媒体流信息，通过该媒体复制组将所述两个以上的媒体流进行关联。
其中，该SDP信息聚合单元220进一步包括媒体流类型确定单元2220，用于在所述聚合的SDP信息中所包含的每个媒体复制组中确定一个媒体流作为输入媒体流，该媒体复制组中其他的媒体流为输出媒体流。具体地，该媒体流类型确定单元2220可以以下述任一种方式来确定媒体复制组中的一个媒体流为输入媒体流：
在对媒体复制组中对所述输入媒体流的mid说明中以一预定值(如“src”等)进行标示；
在所述媒体复制组中的所述输入媒体流的组号后以一预定值(如“src”等)进行标识；
将所述媒体复制组中默认位置的组号所对应的媒体流确定为输入媒体流，例如可以将该媒体复制组中的第一个或最后一个媒体流确定为输入媒体流。
这样，业务控制单元可以通过SIP消息携带该聚合的SDP信息将关联关系发送给媒体处理实体。
参见图6所示，为图4中关联处理模块22的另一种实施例的结构示意图；其中，关联处理模块22进一步包括：
SDP信息聚合单元220，用于根据所述第一客户端会话信息(SDP信息)和所述第二客户端会话信息(SDP信息)生成聚合的SDP信息。
会话信息转换单元222，用于根据第一客户端会话信息生成第一SDP信息，根据第二客户端会话信息生成第二SDP信息。
复制逻辑生成单元224，用于根据SDP信息聚合单元220或会话信息转换单元222的结果生成表示有该第一客户端会话信息和第二客户端会话信息中媒体流的关联关系的复制逻辑。
具体地，该复制逻辑生成单元224进一步包括：
媒体流类型确定单元2240，用于在所复制逻辑中确定至少一个媒体流为输入媒体流，以及与所述输入媒体流对应的至少一个输出媒体流，其中一个输入媒体流与一个或多个输出媒体流相对应，从而将该一个输入媒体流与该一个或多个输出媒体流关联起来。
在实际实施中，该复制逻辑中的输入媒体流和所述输出媒体流通过其在所述聚合的SDP中的位置信息(如label信息，或在SDP中描述的媒体行的顺序号)进行表示；或者
该复制逻辑中，该输入媒体流通过其在第一SDP中的位置信息(如label信息，或在SDP中描述的媒体行的顺序号)和第一SDP关联业务提供实体与媒体处理实体间建立的第一对话(Dialog)进行表示，该输出媒体流通过其在所述第二SDP中的位置信息(如label信息)和第二SDP关联业务提供实体与媒体处理实体间建立的第二对话(Dialog)进行表示；其中，每一对话包括有call-id、from-tag、to-tag信息。
需要说明的是，在其他的一些实施例中，关联处理单元22可以只包括SDP信息聚合单元220和会话信息转换单元222中的一个。
下面通过多个实施例对本发明的实现关联媒体流的方法进行说明。
如图7所示，是本发明的在IP分组网中实现关联媒体流的方法第一实施例示意图；其中
步骤S70，业务提供实体获取第一客户端会话信息和第二客户端会话信息；例如，当业务提供实体接收到来自第一客户端的指示，需要对第一客户端与第二客户端进行关联，则业务提供实体需要获取第一客户端会话信息和第二客户端的会话信息。该第一客户端会话信息可以为第一客户端与业务提供实体建立媒体会话的SDP信息，第二客户端会话信息可以为第二客户端与业务提供实体建立媒体会话的SDP信息。
步骤S72，所述业务提供实体根据所述第一客户端会话信息和所述第二客户端会话信息生成关联关系；其中，生成关联关系的步骤具体如下：
业务提供实体根据第一客户端会话信息和第二客户端会话信息生成聚合的SDP信息。
在该聚合的SDP中包括至少一个媒体复制组，并在每一媒体复制组中确定一个媒体流作为输入媒体流，其他的媒体流作为输出媒体流，从而将该输入媒体流和该输出媒体流进行关联。
例如，在本发明的一些实施例中，可以通过扩展RFC388来定义新的group类型和mid的扩展标识，来标识出媒体复制组和输入媒体流。如
在RFC3388中，原group属性定义如下：
group-attribute ＝″a＝group:″semantics
*(space identification-tag)
semantics ＝″LS″|″FID″
原mid属性定义如下：
mid-attribute ＝″a＝mid:″identification-tag
identification-tag＝token
对其进行扩展后，定义如下：
group-attribute ＝″a＝group:″semantics
*(space identification-tag)
semantics ＝″LS″|″FID″|″COPY″
其中，在“semantics”中新增的“COPY”表示媒体组(group)的类型是媒体复制组。该媒体复制组中只能有一个输入的媒体流，可以有多个输出的媒体流。可以采用多种方式来标识该媒体复制组中的哪个为输入媒体流，哪些为输出的媒体流。例如可以采用下述方式：
方式一、在媒体复制组中对输入媒体流的mid说明中以一预定值进行标示：例如，通过定义一个″src″来标识输入媒体流，可以设置在mid的identification-tag后，用逗号进行分隔，产生新的identification-tag。具有″src″标识的mid对应的媒体行是输入媒体流；没有″src″标识的mid对应的媒体行是输出媒体流。在SDP中可以出现多个媒体复制组。同一媒体复制组中的媒体流的类型必须相同，例如必须同为音频或同为视频等，不能出现不同类型的媒体流在同一个媒体复制组中。
方式二、在媒体复制组中的输入媒体流的组号后以一预定值进行标识：例如，将″src″标识设置在group-attribute的identification-tag中，用于标识输入的媒体流，用逗号将原identification-tag和″src″标识分隔，产生新的identification-tag。具有“src”标识的为输入媒体流，其它没有“src”标识的就是输出媒体流。
方式三、在媒体复制组中默认位置的组号所对应的媒体流确定为输入媒体流：例如可以定义一个媒体复制组中，第一个identification-tag所对应的就是输入媒体流，其他的全为输出媒体流；或者反之，可以定义该媒体复制组中最后一个是输入媒体流，其他的全为输出媒体流。
需要说明的，上述三种方式仅为举例，当可以有更多的方式来指示输入媒体流和输出媒体流。
为便以理解，下述举例来说明前述的对SDP信息进行聚合的过程。
假设，需要对一个第一客户端与两个第二客户端的SDP信息进行聚合。其中，
第一客户端(SrcUe)与业务提供实体建立会话的源媒体流SDP中，包括了视频(video)和音频(audio)两个媒体流，其SDP信息如下：
v＝0
o＝SCF 511111111 511111111IN IP4scf.example.com
s＝
c＝IN IP4SrcUe.example.com
t＝0 0
m＝audio 40000RTP/AVP 0 8 97
a＝rtpmap:8PCMA/8000
m＝video 40010RTP/AVP 31 32
a＝rtpmap:31H261/90000
第一个第二客户端(DstUe1)与业务提供实体建立会话的媒体流SDP，包括一个视频媒体流，其SDP格式如下：
v＝0
o＝SCF 611111111 611111111IN IP4scf.example.com
s＝
c＝IN IP4DstUe1.example.com
t＝0 0
m＝video 50000RTP/AVP 31 32
a＝rtpmap:31H261/90000
第二个第二客户端(DstUe2)与业务提供实体建立会话的媒体流SDP，包括一个音频媒体流，其SDP信息如下：
v＝0
o＝SCF 711111111 711111111IN IP4scf.example.com
s＝
c＝IN IP4DstUe2.example.com
t＝0 0
m＝audio 60000RTP/AVP 0 8 97
a＝rtpmap:8PCMA/8000
在业务提供实体上，可以将上述三个SDP聚合成一个新的SDP；对应于对输入媒体流与输出媒体流进行标识的方式一，该聚合的SDP信息可以为：
v＝0
o＝SCF 811111111 811111111IN IP4scf.example.com
s＝
c＝IN IP4SrcUe.example.com
t＝0 0
a＝group:COPY 1 4
a＝group:COPY2 3
m＝audio 41000RTP/AVP 0 8 97
a＝rtpmap:8PCMA/8000
a＝mid:1，src
m＝video 41010RTP/AVP 31 32
a＝rtpmap:31H261/90000
a＝mid:2，src
m＝video 51000RTP/AVP 31 32
c＝IN IP4DstUe1.example.com
a＝rtpmap:31H261/90000
a＝mid:3
m＝audio 61000RTP/AVP 0 8 97
c＝IN IP4DstUe2.example.com
a＝rtpmap:8PCMA/8000
a＝mid:4
对应于对输入媒体流与输出媒体流进行标识的方式二，该聚合的SDP信息可以为：
v＝0
o＝SCF 811111111 811111111IN IP4scf.example.com
s＝
c＝IN IP4SrcUe.example.com
t＝0 0
a＝group:COPY 1，src 4
a＝group:COPY 2，src 3
m＝audio 41000RTP/AVP 0 8 97
a＝rtpmap:8PCMA/8000
a＝mid:1
m＝video 41010RTP/AVP 31 32
a＝rtpmap:31H261/90000
a＝mid:2
m＝video 51000RTP/AVP 31 32
c＝IN IP4DstUe1.example.com
a＝rtpmap:31H261/90000
a＝mid:3
m＝audio 61000RTP/AVP 0 8 97
c＝IN IP4DstUe2.example.com
a＝rtpmap:8PCMA/8000
a＝mid:4
对应于对输入媒体流与输出媒体流进行标识的方式三，该聚合的SDP信息可以为：
v＝0
o＝SCF 811111111 811111111IN IP4scf.example.com
s＝
c＝IN IP4SrcUe.example.com
t＝0 0
a＝group:COPY 14 /*第一个标识“1”对应的为输入媒体流*/
a＝group:COPY 23 /*第一个标识“2”对应的为输入媒体流*/
m＝audio 41000RTP/AVP 0 8 97
a＝rtpmap:8PCMA/8000
a＝mid:1
m＝video 41010RTP/AVP 31 32
a＝rtpmap:31H261/90000
a＝mid:2
m＝video 51000RTP/AVP 31 32
c＝IN IP4DstUe1.example.com
a＝rtpmap:31H261/90000
a＝mid:3
m＝audio 61000RTP/AVP 0 8 97
c＝IN IP4DstUe2.example.com
a＝rtpmap:8PCMA/8000
a＝mid:4
在上述的三个聚合的SDP中，其中包括有两个媒体复制组，分别为关联mid号为1，4的音频媒体流组和关联mid号为2，3的视频媒体流组；其中，mid号为1和2的作为输入媒体流(对应于第一客户端的媒体流)，而mid号为3和4的作为输出媒体流(对应于第二客户端的媒体流)。
步骤S74，业务控制实体在完成了对第一客户端会话信息与第二客户端会话信息中的媒体流的关联操作后；业务控制实体就可以通过SIP消息(如reINVITE/UPDATE等)携带所述聚合的SDP信息并发送给媒体处理实体，以将所述关联关系发送给媒体处理实体。
由于在业务控制实体与媒体处理实体之间的交互信息中均需要包括SDP信息，上述的通过聚合的SDP信息指示输入媒体流与输出媒体流之间的关系，实现起来非常方便。
如图8所示，是本发明的在IP分组网中实现关联媒体流的方法第二实施例示意图；其中
步骤S80，业务提供实体获取第一客户端会话信息和第二客户端会话信息；例如，当业务提供实体接收到来自第一客户端的指示，需要对第一客户端与第二客户端进行关联，则业务提供实体需要获取第一客户端会话信息和第二客户端的会话信息。该第一客户端会话信息可以为第一客户端与业务提供实体建立媒体会话的SDP信息，第二客户端会话信息可以为第二客户端与业务提供实体建立媒体会话的SDP信息。
步骤S82，所述业务提供实体根据所述第一客户端会话信息和所述第二客户端会话信息生成关联关系；其中，生成关联关系的步骤具体如下：
首先，业务提供实体根据第一客户端会话信息和第二客户端会话信息生成聚合的SDP信息；
例如需要将第一客户端和两个第二客户端的SDP合并，其中，
第一客户端(SrcUe)与业务提供实体建立会话的源媒体流SDP，包括了视频和音频两个媒体流，其SDP信息如下：
v＝0
o＝SCF 511111111 511111111IN IP4scf.example.com
s＝
c＝IN IP4SrcUe.example.com
t＝0 0
m＝audio 40000RTP/AVP 0 8 97
a＝rtpmap:8PCMA/8000
m＝video 40010RTP/AVP 31 32
a＝rtpmap:31H261/90000
第一个第二客户端(DstUe1)与业务提供实体建立会话的媒体流SDP，包括一个视频媒体流，其SDP信息如下：
v＝0
o＝SCF 611111111 611111111IN IP4scf.example.com
s＝
c＝IN IP4DstUe1.example.com
t＝0 0
m＝video 50000RTP/AVP 31 32
a＝rtpmap:31H261/90000
第二个第二客户端(DstUe2)与业务提供实体建立会话的媒体流SDP，包括一个音频媒体流，其SDP信息如下：
v＝0
o＝SCF 711111111 711111111IN IP4scf.example.com
s＝
c＝IN IP4DstUe2.example.com
t＝0 0
m＝audio 60000RTP/AVP 0 8 97
a＝rtpmap:8PCMA/8000
则聚合的SDP信息可以为：
v＝0
o＝SCF 811111111 811111111IN IP4scf.example.com
s＝
c＝IN IP4SrcUe.example.com
t＝0 0
m＝audio 41000RTP/AVP 0 8 97
a＝rtpmap:8PCMA/8000
a＝label:1
m＝video 41010RTP/AVP 31 32
a＝rtpmap:31H261/90000
a＝label:2
m＝video 51000RTP/AVP 31 32
c＝IN IP4DstUe1.example.com
a＝rtpmap:31H261/90000
a＝label:3
m＝audio 61000RTP/AVP 0 8 97
c＝IN IP4DstUe2.example.com
a＝rtpmap:8PCMA/8000
a＝label:4
其次，在进行SDP信息聚合后，业务控制实体通过生成复制逻辑来对该第一客户端会话信息和所述第二客户端会话信息中的媒体流进行关联，从而诸如指导媒体处理实体进行媒体流复制操作。
在该复制逻辑中需要确定一个媒体流为输入媒体流，以及与所述输入媒体流对应的至少一个输出媒体流，该输入媒体流和所述输出媒体流根据其在所述聚合的SDP中的位置信息(如label信息，或在SDP中描述的媒体行的顺序号)来确定的。其中，由于输入媒体流和输出媒体流都在一个聚合后的SDP中。该复制逻辑的格式可以诸如为(采用XML方式进行描述)：
其中，<input>标签表明输入媒体流，可以有多个<input>；<output>标签表明输出媒体流，可以有多个<output>；<output>是<input>的子元素，表示该输出媒体流与输入媒体流的关联关系。从中可以看出，在聚合的SDP信息中，“label＝1”所对应的媒体流和“label＝4”所对应的媒体流存在关联关系，且前者为输入媒体流，后者为输出媒体流；同理，“label＝2”所对应的媒体流和“label＝3”所对应的媒体流存在关联关系，且前者为输入媒体流，后者为输出媒体流。
步骤S84，在业务控制实体就完成了对第一客户端会话信息与第二客户端会话信息中媒体流的关联操作；业务控制实体就可以通过媒体控制消息携带所述复制逻辑发送给媒体处理实体，以将该关联关系发送给媒体处理实体。
如图9所示，是本发明的在IP分组网中实现关联媒体流的方法第三实施例示意图；其中
步骤S90，业务提供实体获取第一客户端会话信息和第二客户端会话信息；例如，当业务提供实体接收到来自第一客户端的指示，需要对第一客户端与第二客户端进行关联，则业务提供实体需要获取第一客户端会话信息和第二客户端的会话信息。该第一客户端会话信息可以为第一客户端与业务提供实体建立媒体会话的SDP信息，第二客户端会话信息可以为第二客户端与业务提供实体建立媒体会话的SDP信息。
步骤S92，所述业务提供实体根据所述第一客户端会话信息和所述第二客户端会话信息生成关联关系；其中，生成关联关系的步骤具体如下：
首先，所述业务提供实体根据所述第一客户端会话信息生成第一SDP信息，所述业务提供实体根据所述第二客户端会话信息生成第二SDP信息，第一SDP信息用于业务提供实体与媒体处理实体间第一对话(Dialog)的会话交互，第二SDP信息用于业务提供实体与媒体处理实体间第二对话(Dialog)的会话交互。
其次，在完成所述第一客户端会话信息与第二客户端会话信息的转换之后，业务控制实体通过生成复制逻辑来对该第一客户端会话信息和所述第二客户端会话信息中的媒体流进行关联，从而诸如指导媒体处理实体进行媒体流复制操作。
在该复制逻辑中需要确定一个媒体流为输入媒体流，以及与所述输入媒体流对应的至少一个输出媒体流，从而将该输入媒体流与该至少一个输出媒体流进行关联。该输入媒体流根据其在所述第一SDP中的位置信息和第一SDP关联业务提供实体与媒体处理实体间建立的第一对话(Dialog)来确定的，该输出媒体流根据其在所述第二SDP中的位置信息和第二SDP关联业务提供实体与媒体处理实体间建立的第二对话(Dialog)来确定的。其中，由于输入媒体流和输出媒体流在不同会话的不同SDP中。该复制逻辑的格式可以诸如为(采用XML方式进行描述)：
其中，<input>标签表明输入媒体流，可以有多个<input>；<output>标签表明输出媒体流，可以有多个<output>；<output>是<input>的子元素，表示该输出媒体流与输入媒体流的关联关系。call-id，from-tag，to-tag用于标识一个对话(Dialog)，位置信息(label)与SDP中媒体行的label属性值相等，用于标示具体位置所指示的媒体流。通过对话(Dialog)信息与位置信息的结合，从而确定不同会话中的具体媒体流。从中可以看出，“call-id＝dsffsfrom-tag＝dfds to-tag＝fr343 label＝1”所对应的媒体流与“call-id＝sdfsfrom-tag＝aadd to-tag＝ffsa label＝1”所对应的媒体流存在关联关系，且前者为输入媒体流，后者为输出媒体流。同理，“call-id＝dsffs from-tag＝dfds to-tag＝fr43label＝2”所对应的媒体流与“call-id＝wwe from-tag＝fgdf to-tag＝tyu label＝1”及“call-id＝w23e from-tag＝fgl2f to-tag＝td3454 label＝1”所对应的媒体流存在关联关系，前者为输入媒体流，后两者为输出媒体流。
步骤S94，在业务控制实体就完成了对第一客户端会话信息与第二客户端会话信息中媒体流的关联操作；业务控制实体就可以通过媒体控制消息携带所述复制逻辑并发送给媒体处理实体，以将该关联关系发送给媒体处理实体。
上述通过复制逻辑来表示输入媒体流与输出媒体流的关联关系的方法，实施起来非常灵活，可以将不同对话(Dialog)中的媒体流进行关联，应用范围非常广泛。
在上述的具体实施例中，如果应用在TISPAN IPTV中时，其中的业务提供实体可以为业务控制功能实体(SCF)，媒体处理实体可以为媒体功能实体(MF)。而媒体功能实体(MF)包括媒体控制功能实体(MCF)和媒体交付功能实体(MDF)。业务开展过程中，业务控制功能实体(SCF)与媒体控制功能实体(MCF)进行交互实现业务，媒体控制功能实体(MCF)控制媒体交付功能实体(MDF)完成媒体处理和交付。
如果应用在IMS架构中，则其中的业务提供实体为应用服务器(Application server，AS)，媒体处理实体为媒体资源功能实体(MRF)。而媒体资源功能实体(Multimedia Resource Function，MRF)包括媒体资源功能控制实体(Media Resource Function-Controller Part，MRFC)和媒体资源功能处理实体(Media Resource Function-Process Part，MRFP)。业务开展过程中，应用服务器(AS)与媒体资源功能控制实体(MRFC)进行交互实现业务，媒体资源功能控制实体(MRFC)控制媒体资源功能处理实体(MRFP)完成媒体处理和交付。
上述描述了本发明实施例的实施例的基本流程，为便于理解本发明，下述将以更详细的例子来说明本发明的具体应用场景。下述例子仅为举例，非为限制本发明的应用场景，本领域的技术人员可以理解，本发明当可应用在其他场景下。后文以TISPAN IPTV为业务场景进行描述，相关流程同样可应用于IMS架构。以下仅举出三种典型的应用流程，在此就不进行穷举。
为了描述方便，下述所述的MCF即为媒体处理实体，当MCF和MDF作为一个整体时，描述MCF即代表MF。
如图10所示，是本发明的第一应用例流程图。该图示出了本发明应用在源客户端指示目的客户端接收复制媒体流的场景下的具体过程。
首先，源客户端(Src UE)已经通过SCF与MCF间建立了媒体流的传输，假定所述媒体流包括音频流和视频流。在该实施例中，需要向目的客户端复制视频流。
步骤F1：源客户端(Src UE)向目的客户端(Dst UE)发送REFER消息，指示Dst UE与SCF建立会话接收Src UE的复制媒体流，并在refer-to头域中携带video的属性标识，指示Dst UE复制的媒体流是视频媒体流；
其中，在本发明的实施例中，需要中定义一个属性标识(如“mediacopy”)来指示需要进行关联复制媒体；该属性标识可以通过已有的机制在refer-to头域的SIP URI参数部分携带，同时在refer-to中携带call-id，from-tag，to-tag，cid用于标识一个需要复制具休的媒体流。所述的属性标识可通过Request-URI，Contact，Accept-Contact等头域携带，为描述方便，在下述流程均为在Accept-Contact头域中携带所述属性标识。
例如，该REFER消息为：
REFER sip:Bob@example.com SIP/2.0
Via：...
Route：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
Refer-to：<sip:scf.example.com；call-id＝48020298；to-tag＝7743；
from-tag＝6472；cid＝2？Accept-Contact＝mediacopy>；
method＝INVITE；video
Referred-By：<sip:Alice@SrcUe.example.com>
步骤F2：Dst UE返回202OK表示REFER请求正在处理；
步骤F3～F4：Dst UE返回NOTIFY，报告REFER处理的进展；
步骤F5：Dst UE根据REFER消息的向业务控制实体(SCF)发送INVITE请求复制媒体流。如：
INVITE sip:scf.example.com；call-id＝48020298；
to-tag＝7743；from-tag＝6472；cid＝2；mediacopy SIP/2.0
Via：...
Route：...
Max-Forwards：...
From：...
To：...
Call-ID：...
Accept-Contact:mediacopy
v＝0
o＝Bob 40000000 40000000IN IP4DstUe.example.com
s＝
c＝IN IP4DstUe.example.com
t＝0 0
m＝video 40010RTP/AVP 31 32
a＝rtpmap:32MPV/90000
其中，Dst UE的编码采用MPV方式，与源客户端所发送的REFER消息中所指示的被复制媒体流编码H261不同。
步骤F6：SCF收到Dst UE发送的INVITE消息，检查发现Accept-Contact头域中带有mediacopy属性标识，则对该INVITE消息执行媒体流复制处理：根据Request-URI中携带的dialog-id|，to-tag，from-tag参数，匹配到SCF与Src UE建立的对话(Dialog)，并根据这个对话(Dialog)获得SCF与MCF建立的媒体会话(Session)的对话(Dialog)，根据该媒体Session的Dialog的已有媒体信息和Request-URI中的cid参数，构造reINVITE消息，携带新的SDP信息(增加了Dst UE的媒体描述)并发送给MCF；如：
INVITE sip:mf.example.com SIP/2.0
Via：...
Route：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
v＝0
o＝SCF 210000000 210000001IN IP4scf.example.com
s＝
c＝IN IP4SrcUe.example.com
t＝0 0
a＝group:COPY 1 2 /*可以是多个a行，表示多个聚合的组*/
m＝audio 10000RTP/AVP 0 8 97
a＝rtpmap:8PCMA/8000
m＝video 10010RTP/AVP 31 32
a＝rtpmap:31H261/90000
a＝mid:1，src /*1所对应的媒体流为源媒体流，如果组内的m
行编码有不同的，MF以源的编码为标准进行
转换*/
m＝video 40010RTP/AVP 31 32
c＝IN IP4DstUe.example.com
a＝rtpmap:32MPV/90000
a＝mid:2
其中，斜体字部分为目的客户端的SDP信息，为新增部分；另外，由于源媒体流的编码与新增媒体流的编码不同，MCF需要完成编码的转换处理。
步骤F7：MCF接收SCF的reINVITE消息，在200OK中返回更新的SDP信息。如：
SIP/2.0200OK
Via：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
v＝0
o＝MF 300000000 300000000IN IP4mfhost.example.com
s＝
c＝IN IP4mcfhost.example.com
t＝0 0
m＝audio 30000RTP/AVP 0 8 97
a＝rtpmap:8PCMA/8000
m＝video 30010RTP/AVP 31 32
a＝rtpmap:31H261/90000
m＝video 20010RTP/AVP 31 32 /*新增的媒体流*//
a＝rtpmap:32MPV/90000
步骤F8：SCF接收MCF返回的200OK，根据其中的SDP回复构造新的SDP，通过200OK响应消息发送给Dst UE；如：
SIP/2.0200OK
Via：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
v＝0
o＝SCF 200000000 200000000IN IP4scf.example.com
s＝
c＝IN IP4mcfhost.example.com
t＝00
m＝video 20010RTP/AVP 31 32
a＝rtpmap:32MPV/90000
步骤F9：Dst UE收到SCF的200OK返回ACK；
步骤F10：SCF收到Dst UE的ACK，向MCF返回ACK，MCF向Dst UE发送复制的媒体流；
步骤F11～F12：在复制完所有媒体流后，Dst UE通过NOTIFY消息向Src UE报告复制媒体流操作完成。
如图11所示，是本发明的第二应用例流程图。该图示出了本发明应用在源客户端指示SCF将媒体目的客户端接收复制媒体流的场景下的具体过程。
如图8所示，是本发明的实现关联复制媒体流的方法的第二具体实施例流程图；该流程包括：
首先，源客户端(Src UE)已经通过SCF与MCF间建立了媒体流的传输，假定所述媒体流包括音频流和视频流。在该实施例中，需要向目的客户端复制视频流。
步骤F1：源客户端(Src UE)向业务控制实体(SCF)发送REFER消息，指示SCF将Src UE的视频媒体流复制到Dst UE，例如，在Request-URI中携带关于关联复制的属性标识(如，mediacopy)，并指示需要复制的为视频媒体流(例如可以在refer-to头域中携带video来进行指示)。例如，该REFER消息为：
REFER sip:scf.example.com；call-id＝48020298；to-tag＝7743；
from-tag＝6472；cid＝2；mediacopy；video SIP/2.0
Via：...
Route：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
Refer-to：<sip:Bob@example.com；method＝INVITE>
Referred-By：<sip:Alice@example.com>
步骤F2：SCF返回202OK表示REFER请求正在处理；
步骤F3～F4：SCF返回NOTIFY，报告REFER处理的进展；
步骤F5：SCF根据REFER消息的Request-URI中的“mediacopy”属性标识确认Src UE希望复制媒体流，根据Request-URI中的dialog-id，from-tag，to-tag匹配到Src UE与SCF间的对话(Dialog)，再根据Request-URI中的cid确定Src UE请求复制的媒体流是SDP中的视频媒体流(其中，cid＝2，表示SDP中的第二个m行)。SCF构造携带mediacopy属性标识的INVITE消息发送给Dst UE。SCF在SDP中携带MCF支持的所有的视频编码格式的信息。该INVITE消息例如为：
INVITE sip:Bob@example.com SIP/2.0
Via：...
Route：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
Accept-Contact：mediacopy
v＝0
o＝SCF 20000000 20000000IN IP4scf.example.com
s＝
c＝IN IP4mcfhost.example.com
t＝0 0
m＝video 30010RTP/AVP 31 32/*如果SCF不能决定媒体参数，就将
30010部分设为0*/
a＝rtpmap:31H261/90000
a＝rtpmap:32MPV/90000
其中，在SCF构造的SDP中，如果SCF不能决定新增媒体流在MCF上的媒体参数，就将该媒体流保持(Hold)住，也就是将m行的端口设为0。这样SCF通过步骤F8获得媒体参数后，需要与Dst UE进行二次SDP协商将媒体流激活。另外，在步骤F5中，SCF可以发送不带SDP的INVITE，由Dst UE发送200OK携带SDP提供(offer)，SCF通过ACK携带SDP回复(answer)确认。
步骤F6：Dst UE接收INVITE消息，返回200OK消息。该200OK消息例如为：
SIP/2.0200OK
Via：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
v＝0
o＝Bob 40000000 40000000IN IP4DstUe.example.com
s＝
c＝IN IP4DstUe.example.com
t＝0 0
m＝video 40010RTP/AVP 31 32
a＝rtpmap:31H261/90000
步骤F7：SCF接收Dst UE的200OK，根据Dst UE响应中的SDP构造INVITE消息发送给MCF。如：
/*单SDP方式*/
INVITE sip:mf.example.com SIP/2.0
Via：...
Route：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
v＝0
o＝SCF 21000000 21000001IN IP4scf.example.com
s＝
c＝IN IP4SrcUe.example.com
t＝0 0
m＝audio 10000RTP/AVP 0 8 97
a＝rtpmap:8PCMA/8000
m＝video 10010RTP/AVP 31 32
a＝rtpmap:31H261/90000
a＝label:1
m＝video 40010RTP/AVP 31 32 /*增加DstUe的媒体描述部分，同时为
两个m＝video的媒体行增加
label*/
c＝IN IP4DstUe.example.com
a＝rtpmap:31H261/90000
a＝label:2
或者例如，将DstUe的的SDP部分作为一个单独的SDP携带在INVITE消息中，这样INVITE消息中就存在SrcUe的SDP和DstUe的SDP两个SDP：
/*多SDP方式*/
INVITE sip:mf.example.com SIP/2.0
Via：...
Route：...
From：...
To：...
Call-ID：...
Content-Type：ultipart/related；type＝application/sdp；
start＝″<nXYxAE@example.com>″；
boundary＝″50UBfW7LSCVLtggUPe5z″
Content-Length：...
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding：binary
Content-ID：<nXYxAE@example.com>
Content-Type：application/sdp
v＝0
o＝SCF 21000000 21000001IN IP4scf.example.com
s＝
c＝IN IP4SrcUe.example.com
t＝0 0
m＝audio 10000RTP/AVP 0 8 97
a＝rtpmap:8PCMA/8000
m＝video 10010RTP/AVP 31 32
a＝rtpmap:31H261/90000
a＝label:1
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding：binary
Content-ID：<wcwcwc@example.com>
Content-Type：application/sdp
v＝0
o＝SCF 21100000 21100000IN IP4scf.example.com
s＝
c＝IN IP4DstUe.example.com
t＝0 0
m＝video 40010RTP/AVP 31 32
a＝rtpmap:31H261/90000
a＝label:1
--50UBfW7LSCVLtggUPe5z-
步骤F8：MCF返回200OK消息，携带SDP answer信息。如：
/*单SDP方式*/
SIP/2.0200OK
Via：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
v＝0
o＝MF 30000000 30000000IN IP4mfhost.example.com
s＝
c＝IN IP4mfhost.example.com
t＝0 0
m＝audio 30000RTP/AVP 0 8 97
a＝rtpmap:8PCMA/8000
m＝video 30010RTP/AVP 31 32
a＝rtpmap:31H261/90000
a＝label:1
m＝video 20010RTP/AVP 31 32
a＝rtpmap:31H261/90000
a＝label:2
步骤F9：SCF向MCF返回ACK；
步骤F10：SCF向Dst UE返回ACK；
步骤F11：SCF向MCF下发媒体控制消息(Request)请求复制指定的媒体流，Request消息体中携带指示复制指定媒体流的复制逻辑。如：
其中，input表示源媒体流，output表示输出的复制媒体流。在多SDP方式下，<item>和<output>标签中的sessionid属性对应SCF向MCF发送的SDP offer中的sess-id，input＝1对应第一个SDP中lable＝1，output＝1对应第二个SDP中label＝1。
步骤F12：MCF接收SCF下发的媒体复制请求消息，返回Response响应；MCF将复制的媒体流发送到Dst UE；
步骤F13～F14：SCF向Src UE发送NOTIFY消息报告媒体流复制完成。
如图12所示，是本发明的第二应用例流程图。该图示出了本发明应用在源客户端创建复制焦点，并指示目的客户端加入该复制焦点，从而将媒体流发送给目的客户端的场景下的具体过程。
首先，源客户端(Src UE)已经通过SCF与MCF间建立了媒体流的传输，假定所述媒体流包括音频流和视频流。在该实施例中，需要向目的客户端复制视频流。
步骤S1：Src UE与媒体复制控制实体进行会话交互，创建复制焦点；
步骤F1：Src UE向媒体复制控制实体发送INVITE消息，携带mediacopy的属性标识，在SDP offer中携带两个视频媒体流描述，其中一个视频流是MCF发出的作为输入媒体流，另一个视频流是由Src UE接收的作为输出媒体流；如：
INVITE sip:scfcopy.example.com；SIP/2.0
Via：...
Route：...
Max-Forwards：...
From：...
To：...
Call-ID：...
Accept-Contact：mediacopy
v＝0
o＝Alice 20000000 20000000IN IP4SrcUe.example.com
s＝
c＝IN IP4SrcUe.example.com
t＝0 0
a＝group:COPY 1 2
m＝video 20000RTP/AVP 31 32 /*协商建立MCF与媒体复制处理实体
的媒体流，MCF作为媒体流
发送源*/
c＝IN IP4mcf.example.com
a＝rtpmap:31H261/90000
a＝sendonly
a＝mid:1
m＝video 20100RTP/AVP 31 32/*协商建立Src UE与媒体复制处理实体
的媒体流，Src UE作为媒体流
接收端*/
a＝rtpmap:31H261/90000
a＝recvonly
a＝mid:2
其中：SDP中使用“COPY”组标识，“COPY”后的第一个标识(mid:1)默认为输入媒体流，其后的标识是输出媒体流。
步骤F2：媒体复制控制实体接收Src UE发送的INVITE消息，检测到其中携带有mediacopy的属性标识，则创建业务层的复制焦点，向媒体复制处理实体发送INVITE请求创建媒体层复制焦点；如：
INVITE sip:mcfcopy.example.com；SIP/2.0
Via：...
Route：...
Max-Forwards：...
From：...
To：...
Call-ID：...
Accept-Contact：mediacopy
v＝0
o＝SCFCopy 30000000 30000000IN IP4scfcopy.example.com
s＝
c＝IN IP4SrcUe.example.com
t＝0 0
a＝group:COPY 1 2
m＝video 20000RTP/AVP 31 32/* 协商建立MCF与媒体复制处理实体的
媒体流，MCF作为媒体流发送
源*/
c＝IN IP4mcf.example.com
a＝rtpmap:31H261/90000
a＝sendonly
a＝mid:1
m＝video 20100RTP/AVP 31 32/*协商建立Src UE与媒体复制处理实
体的媒体流，Src UE作为媒体
流接收端*/
a＝rtpmap:31H261/90000
a＝recvonly
a＝mid:2
F3：媒体复制处理实体接收媒体复制控制实体发送的INVITE消息，检查其中携带了mediacopy属性标识，将创建媒体层的复制焦点与创建焦点的会话(Session)进行关联，将SDP中描述的属性是mid:1的媒体流作为焦点的输入媒体流，将SDP中描述的属性是mid:2的媒体流作为焦点的输出媒体流，媒体层复制焦点能自动执行媒体编码转换，如果输入输出编码不同，将输入媒体流编码转换成输出媒体流编码；媒体复制处理实体返回200OK消息；
SIP/2.0200OK
Via：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
v＝0
o＝MCFCopy 30000000 30000000IN IP4mcfcopy.example.com
s＝
c＝IN IP4mcfcopy.example.com
t＝0 0
a＝group:COPY 1 2
m＝video 30000RTP/AVP 31 32/*协商建立MCF与媒体复制处理实体的
媒体流，MCF作为媒体流发送
源*/
a＝rtpmap:31H261/90000
a＝recvonly
a＝mid:1
m＝video 30100RTP/AVP 31 32/*协商建立Src UE与媒体复制处理实体
的媒体流，Src UE作为媒体流
接收端*/
a＝rtpmap:31H261/90000
a＝sendonly
a＝mid:2
步骤F4：媒体复制控制实体接收200OK消息，返回ACK消息；
步骤F5：媒体复制控制实体向Src UE发送200OK消息，在Contact头域中携带业务层复制焦点标识；
SIP/2.0200OK
Via：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
Contact：scfcopy.example.com；focusid＝xyzswq
v＝0
o＝MCFCopy 30000000 30000000IN IP4mcfcopy.example.com
s＝
c＝IN IP4mcfcopy.example.com
t＝0 0
a＝group:COPY 1 2
m＝video 30000RTP/AVP 31 32/*协商建立MCF与媒体复制处理实体的
媒体流，MCF作为媒体流发送
源*/
a＝rtpmap:31H261/90000
a＝recvonly
a＝mid:1
m＝video 30100RTP/AVP 31 32/*协商建立Src UE与媒体复制处理实体
的媒体流，Src UE作为媒体流
接收端*/
a＝rtpmap:31H261/90000
a＝sendonly
a＝mid:2
步骤F6：Src UE返回ACK；
步骤S2：Src UE与SCF进行媒体重协商，将MCF发送到Src UE的视频流改向到媒体复制处理实体(MCFCopy)；
步骤F7：Src UE向SCF发送reINVITE携带SDP offer，将视频媒体行改为F5步骤中接收到的SDP中属性为recvonly的媒体行；
INVITE sip:scf.example.com SIP/2.0
Via：...
Route：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
v＝0
o＝Alice 100000000 100000001IN IP4SrcUe.example.com
s＝
c＝IN IP4SrcUe.example.com
t＝00
m＝audio 10000RTP/AVP 0 8 97
a＝rtpmap:8PCMA/8000
m＝video 30100RTP/AVP 31 32
c＝IN IP4mcfcopy.example.com
a＝rtpmap:31H261/90000
a＝recvonly
F8：SCF向MCF发送reINVITE携带SDP offer；
INVITE sip:mcf.example.com SIP/2.0
Via：...
Route：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
v＝0
o＝SCF 400000000 400000001IN IP4scf.example.com
s＝
c＝IN IP4SrcUe.example.com
t＝0 0
m＝audio 10000RTP/AVP 0 8 97
a＝rtpmap:8PCMA/8000
m＝video 30100RTP/AVP 31 32
c＝IN IP4mcfcopy.example.com
a＝rtpmap:31H261/90000
a＝recvonly
步骤F9～F10：MCF向SCF返回200OK携带SDP answer，SCF返回ACK消息；
步骤F11～F12：SCF向Src UE返回200OK携带SDP answer，Src UE返回ACK消息；
步骤S3：Src UE指示Dst UE加入复制焦点；
步骤F13：Src UE向Dst UE发送REFER消息，携带复制焦点标识和mediacopy属性标识；如：
REFER sip:Bob@example.com；mediacopy；video SIP/2.0
Via：...
Route：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
Refer-to：<sip:scfcopy.example.com；focusid＝xyzswq>；method＝INVITE
Referred-By：<sip:Alice@example.com>
Refer-Sub：false
Supported：norefersub
步骤F14：Dst UE向Src UE返回200OK消息；
步骤F15：Dst UE向媒体复制控制实体发出INVITE消息在Request-URI中携带复制焦点标识，在Accept-Contact中携带mediacopy属性标识，请求加入媒体复制焦点；
可以理解的是，其中，复制焦点标识也可以在Accept-Contact中携带。如：
INVITE sip:scfcopy.example.com；focusid＝xyzswq SIP/2.0
Via：...
Route：...
Max-Forwards：...
From：...
To：...
Call-ID：...
Accept-Contact：mediacopy
v＝0
o＝Bob 40000000 40000000IN IP4DstUe.example.com
s＝
c＝IN IP4DstUe.example.com
t＝0 0
m＝video 40010RTP/AVP 31 32
a＝rtpmap:32MPV/90000
F16：媒体复制控制实体向媒体复制处理实体发送reINVITE消息，通过媒体重协商在创建复制焦点的Session中增加Dst UE的SDP描述，将Dst UE加入到媒体复制处理实体的复制焦点中；如：
INVITE sip:mcfcopy.example.com；SIP/2.0
Via：...
Route：...
Max-Forwards：...
From：...
To：...
Call-ID：...
Accept-Contact：mediacopy
v＝0
o＝SCFCopy 30000000 30000001IN IP4scfcopy.example.com
s＝
c＝IN IP4SrcUe.example.com
t＝0 0
a＝group:COPY 1 2 3
m＝video 20000RTP/AVP 31 32/*协商建立MCF与媒体复制处理实体的
媒体流，MCF作为媒体流发送
源*/
c＝IN IP4mcf.example.com
a＝rtpmap:31H261/90000
a＝sendonly
a＝mid:1
m＝video 20100RTP/AVP 31 32/*协商建立Src UE与媒体复制
处理实体的媒体流，Src UE作
为媒体流接收端*/
a＝rtpmap:31H261/90000
a＝recvonly
a＝mid:2
m＝video 40010RTP/AVP 31 32 /*Dst UE的媒体流描述*/
c＝IN IP4DstUe.example.com
a＝rtpmap:32MPV/90000
a＝recvonly
a＝mid:3
步骤F17：媒体复制处理实体返回200OK消息，其中携带有SDP answer；
SIP/2.0200OK
Via：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
v＝0
o＝MCFCopy 30000000 30000000IN IP4mcfcopy.example.com
s＝
c＝IN IP4mcfcopy.example.com
t＝0 0
a＝group:COPY 1 2 3
m＝video 30000RTP/AVP 31 32/*协商建立MCF与媒体复制处理实体的
媒体流，MCF作为媒体流发送
源*/
a＝rtpmap:31H261/90000
a＝recvonly
a＝mid:1
m＝video 30100RTP/AVP 3132/*协商建立Src UE与媒体复制处理实体
的媒体流，Src UE作为媒体流
接收端*/
a＝rtpmap:31H261/90000
a＝sendonly
a＝mid:2
m＝video 40020RTP/AVP 3132 /*Dst UE的媒体流描述*/
a＝rtpmap:32MPV/90000
a＝sendonly
a＝mid:3
步骤F18：媒体复制控制实体根据媒体复制处理实体返回的SDP answer，构造新的SDP answer通过200OK消息发送给Dst UE；如：
SIP/2.0200OK
Via：...
Max-Forwards：...
From：...
To：...
Call-ID：...
CSeq：...
v＝0
o＝SCFCopy 60000000 60000000IN IP4scfcopy.example.com
s＝
c＝IN IP4mcfcopy.example.com
t＝0 0
m＝video 40020RTP/AVP 31 32
a＝rtpmap:32MPV/90000
a＝sendonly
F19：Dst UE收到200OK消息向媒体复制控制实体返回ACK消息；
F20：媒体复制控制实体向媒体复制处理实体发送ACK消息，媒体复制处理实体收到ACK向Dst UE发送复制媒体流。
在上述描述的三个应用场景中，业务控制实体利用输入媒体流与输出媒体流的关联关系来指示媒体处理实体进行媒体流的复制，可以减少现有的IPTV中的点播的次数，并且可以由源客户端来控制将正在接收的媒体流复制到哪个或哪些目的客户端，增加了用户的使用体验。
本发明实施例的在IP分组网中实现关联媒体流的方法及装置，通过将源客户端会话信息和目的客户端会话信息进行关联，可以应用于媒体流(如视频等)的共享、会话媒体流监控等多种场景中。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (19)
1.一种在IP分组网中实现关联媒体流的方法，其特征在于，包括：
业务提供实体获取第一客户端会话信息和第二客户端会话信息；
所述业务提供实体根据所述第一客户端会话信息和所述第二客户端会话信息生成关联关系，包括：
由所述第一客户端会话信息和所述第二客户端会话信息生成聚合的SDP信息，在所述聚合的SDP信息中包含至少一个媒体复制组，从每一媒体复制组中确定一个媒体流作为输入媒体流；或者
通过复制逻辑来生成所述关联关系，在所述复制逻辑中确定一个媒体流为输入媒体流，以及与所述输入媒体流对应的至少一个输出媒体流；所述业务提供实体将所述关联关系发送给媒体处理实体。
2.如权利要求1所述的方法，其特征在于，所述第一客户端会话信息为第一客户端与业务提供实体建立媒体会话的SDP信息，第二客户端会话信息为第二客户端与业务提供实体建立媒体会话的SDP信息。
3.如权利要求1所述的方法，其特征在于，所述业务提供实体根据所述第一客户端会话信息和所述第二客户端会话信息生成关联关系的步骤包括：
所述业务提供实体根据所述第一客户端会话信息生成第一SDP信息，所述业务提供实体根据所述第二客户端会话信息生成第二SDP信息。
4.如权利要求3所述的方法，其特征在于，所述第一客户端会话信息为第一客户端与业务提供实体建立媒体会话的SDP信息，第二客户端会话信息为第二客户端与业务提供实体建立媒体会话的SDP信息。
5.如权利要求4所述的方法，其特征在于，以下述任一种方法来确定媒 体复制组中的一个媒体流为输入媒体流：
在媒体复制组中对所述输入媒体流的mid说明中以一预定值进行标示；或
在所述媒体复制组中的所述输入媒体流的组号后以一预定值进行标识；或
将所述媒体复制组中默认位置的组号所对应的媒体流确定为输入媒体流。
6.如权利要求1所述的方法，其特征在于，所述复制逻辑中所确定的所述输入媒体流和所述输出媒体流是根据其在所述聚合的SDP中的位置信息来确定的。
7.如权利要求3或4所述的方法，其特征在于，所述业务提供实体根据所述第一客户端会话信息和所述第二客户端会话信息生成关联关系的步骤为：
通过复制逻辑来生成所述第一客户端会话信息和所述第二客户端会话信息中媒体流的关联关系。
8.如权利要求7所述的方法，其特征在于，所述复制逻辑中确定一个媒体流为输入媒体流，以及与所述输入媒体流对应的至少一个输出媒体流，所述输入媒体流是根据其在所述第一SDP中的位置信息和第一SDP关联业务提供实体与媒体处理实体间建立的第一对话(Dialog)来确定的，所述输出媒体流是根据其在所述第二SDP中的位置信息和第二SDP关联业务提供实体与媒体处理实体间建立的第二对话(Dialog)来确定的。
9.一种业务控制实体，用于在IP分组网中实现关联媒体流，其特征在于， 包括：
会话信息获取单元，用于获取第一客户端会话信息和第二客户端会话信息；
关联处理单元，用于为会话信息获取单元所获取的第一客户端会话信息和第二客户端会话信息生成关联关系，包括：由所述第一客户端会话信息和所述第二客户端会话信息生成聚合的SDP信息，在所述聚合的SDP信息中包含至少一个媒体复制组，从每一媒体复制组中确定一个媒体流作为输入媒体流；或者通过复制逻辑来生成所述关联关系，在所述复制逻辑中确定一个媒体流为输入媒体流，以及与所述输入媒体流对应的至少一个输出媒体流；
关联关系发送单元，用于将关联处理单元所生成的所述关联关系发送给媒体处理实体。
10.如权利要求9所述的业务控制实体，其特征在于，
所述会话信息获取单元获取的所述第一客户端会话信息为第一客户端与业务提供实体建立媒体会话的SDP信息，第二客户端会话信息为第二客户端与业务提供实体建立媒体会话的SDP信息。
11.如权利要求10所述的业务控制实体，其特征在于，所述关联处理单元进一步包括：
SDP信息聚合单元，用于根据所述第一客户端会话信息和所述第二客户端会话信息生成聚合的SDP信息。
12.如权利要求11所述的业务控制实体，其特征在于，所述SDP信息聚合单元进一步包括：
媒体流类型确定单元，用于在所述聚合的SDP信息中所包含的每个媒体复制组中确定一个媒体流作为输入媒体流。
13.如权利要求12所述的业务控制实体，其特征在于，所述媒体流类型确定单元以下述任一种方式来确定媒体复制组中的一个媒体流为输入媒体流：
在媒体复制组中对所述输入媒体流的mid说明中以一预定值进行标示；
在所述媒体复制组中的所述输入媒体流的组号后以一预定值进行标识；
将所述媒体复制组中默认位置的组号所对应的媒体流确定为输入媒体流。
14.如权利要求13所述的业务控制实体，其特征在于，所述关联处理单元进一步包括：
会话信息转换单元，用于根据所述第一客户端会话信息生成第一SDP信息，根据所述第二客户端会话信息生成第二SDP信息。
15.如权利要求9所述的业务控制实体，其特征在于，所述第一客户端会话信息为第一客户端与业务提供实体建立媒体会话的SDP信息，第二客户端会话信息为第二客户端与业务提供实体建立媒体会话的SDP信息。
16.如权利要求11、12、13或14所述的业务控制实体，其特征在于，所述关联处理单元进一步包括：
复制逻辑生成单元，用于根据所述SDP信息聚合单元或会话信息转换单元的结果生成表示有所述第一客户端会话信息和所述第二客户端会话信息中媒体流的关联关系的复制逻辑。
17.如权利要求16所述的业务控制实体，其特征在于，所述复制逻辑生成单元进一步包括：
媒体流类型确定单元，用于在所述复制逻辑中确定至少一个媒体流为输入媒体流，以及与所述输入媒体流对应的至少一个输出媒体流。
18.如权利要求17所述的业务控制实体，其特征在于：
所述输入媒体流和所述输出媒体流是根据所述聚合的SDP中的位置信息来确定的；或者
所述输入媒体流是根据其在所述第一SDP中的位置信息和第一SDP关联业务提供实体与媒体处理实体间建立的第一对话(Dialog)来确定的，所述输出媒体流是根据其在所述第二SDP中的位置信息和第二SDP关联业务提供实体与媒体处理实体间建立的第二对话(Dialog)来确定的。
19.如权利要求9至15任一项所述的业务控制实体，其特征在于，所述业务控制实体为IPTV SCF，所述媒体处理实体为IPTV MF；或者所述业务控制实体为应用服务器(AS)，所述媒体处理实体为媒体资源功能实体(MRF)。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2007100324208A CN101459572B (zh) | 2007-12-13 | 2007-12-13 | 一种在ip分组网中实现关联媒体流的方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2007100324208A CN101459572B (zh) | 2007-12-13 | 2007-12-13 | 一种在ip分组网中实现关联媒体流的方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101459572A CN101459572A (zh) | 2009-06-17 |
| CN101459572B true CN101459572B (zh) | 2011-07-06 |
Family
ID=40770211
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2007100324208A Expired - Fee Related CN101459572B (zh) | 2007-12-13 | 2007-12-13 | 一种在ip分组网中实现关联媒体流的方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101459572B (zh) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102006504A (zh) * | 2009-08-31 | 2011-04-06 | 中兴通讯股份有限公司 | 一种媒体统一控制方法和系统 |
| CN109756445B (zh) * | 2017-11-01 | 2021-11-16 | 中兴通讯股份有限公司 | 媒体采集方法、媒体采集请求的生成方法及相关设备 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1829345A (zh) * | 2005-08-12 | 2006-09-06 | 深圳华为移动通信技术有限公司 | 实现移动终端间数据共享的方法和系统 |
| CN1886987A (zh) * | 2003-12-01 | 2006-12-27 | 松下电器产业株式会社 | 流媒体系统 |
| CN1889578A (zh) * | 2006-07-28 | 2007-01-03 | 华为技术有限公司 | 通信控制方法、装置及系统 |
-
2007
- 2007-12-13 CN CN2007100324208A patent/CN101459572B/zh not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1886987A (zh) * | 2003-12-01 | 2006-12-27 | 松下电器产业株式会社 | 流媒体系统 |
| CN1829345A (zh) * | 2005-08-12 | 2006-09-06 | 深圳华为移动通信技术有限公司 | 实现移动终端间数据共享的方法和系统 |
| CN1889578A (zh) * | 2006-07-28 | 2007-01-03 | 华为技术有限公司 | 通信控制方法、装置及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101459572A (zh) | 2009-06-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7716310B2 (en) | Method and Internet Protocol Television (IPTV) content manager server for IPTV servicing | |
| US8307049B2 (en) | Method and device for obtaining media description information of IPTV services | |
| CN101026615B (zh) | 一种基于ims的流媒体网络系统 | |
| KR100891745B1 (ko) | 주문형 비디오 서비스 제공을 위한 프로토콜 변환 방법 및 그 장치 | |
| WO2009018738A1 (fr) | Procédé, dispositif et système de service associé destinés à fournir un contenu vidéo | |
| KR100802088B1 (ko) | 실시간 ｖｏｄ 서비스 제공 방법 및 장치 | |
| CN102594794B (zh) | 一种媒体加密会议的接入方法及装置 | |
| CN101459572B (zh) | 一种在ip分组网中实现关联媒体流的方法及装置 | |
| CN101453402A (zh) | 一种对媒体流控制的方法、系统及设备 | |
| CN101626396A (zh) | 多用户业务建立和控制通道转移方法、装置及系统 | |
| CN101883443B (zh) | 实现sip会话转移的方法及设备 | |
| CN101340428A (zh) | 媒体服务器切换过程中提供媒体流的方法及系统 | |
| Shibeshi et al. | Using an RTSP Proxy to implement the IPTV Media Function via a streaming server | |
| CN101483532B (zh) | 一种媒体流复制的方法、系统及设备 | |
| CN102088447A (zh) | Ims系统中的媒体控制方法及其系统 | |
| CN101616133A (zh) | 实现共享群业务的方法、系统和装置 | |
| CN101686137A (zh) | 一种会议业务的实现方法、设备和系统 | |
| WO2009030171A1 (fr) | Procédé d'implémentation de service média, système de communication et dispositifs associés | |
| CN102150407B (zh) | 网络电视频道业务实现方法和相关设备 | |
| CN101047718B (zh) | 实现媒体协商的系统、方法及服务器 | |
| CN101355552A (zh) | 一种控制流媒体的方法及装置 | |
| CN101378546A (zh) | 实现媒体交付控制的方法、实体及系统 | |
| CN100571149C (zh) | 一种基于会话发起协议更新会议媒体类型的实现方法 | |
| WO2009043241A1 (fr) | Procédé, système et dispositif permettant à une entité prestataire de services de réguler un flux multimédia | |
| Gaglianello et al. | IMS shared streaming video |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110706 Termination date: 20141213 |
|
| EXPY | Termination of patent right or utility model |