CN101247386B - 媒体流获取方法及其系统、装置 - Google Patents

媒体流获取方法及其系统、装置 Download PDF

Info

Publication number
CN101247386B
CN101247386B CN2007100793982A CN200710079398A CN101247386B CN 101247386 B CN101247386 B CN 101247386B CN 2007100793982 A CN2007100793982 A CN 2007100793982A CN 200710079398 A CN200710079398 A CN 200710079398A CN 101247386 B CN101247386 B CN 101247386B
Authority
CN
China
Prior art keywords
media stream
end points
session
source
obtains
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
Application number
CN2007100793982A
Other languages
English (en)
Other versions
CN101247386A (zh
Inventor
何云
朱东铭
徐培利
张玉侠
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN2007100793982A priority Critical patent/CN101247386B/zh
Priority to PCT/CN2008/070322 priority patent/WO2008101443A1/zh
Publication of CN101247386A publication Critical patent/CN101247386A/zh
Application granted granted Critical
Publication of CN101247386B publication Critical patent/CN101247386B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本发明提供一种媒体流获取的方法，所述方法包括：目的端点发送获取媒体流的请求消息给对端点或源端点，所述获取媒体流请求消息包括需要获取的媒体流的信息；目的端点获取由对端点或源端点根据目的端点需要获取的媒体流的信息从源端点与对端点之间的至少一个源会话中切换至目的端点与对端点之间的会话中的媒体流。通过本发明实施例所提供的媒体流获取的方法及其系统、装置，能够实现从一个或多个源会话中获取部分或全部的媒体流。

Description

媒体流获取方法及其系统、装置 
技术领域
本发明涉及多媒体通信技术领域，特别涉及一种媒体流获取方法及其系统、装置。 
背景技术
会话发起协议(SIP，Session Initiation Protocol)是因特网工程任务组(IETF，Internet Engineering Task Force)制定的多媒体通信系统框架协议之一，它是一个基于文本的应用层控制协议，它独立于底层协议，用于建立、修改和终止互联网上的多媒体会话。在SIP中，多媒体会话是由一组多媒体发送者和接收者及其彼此之间的数据流组成，多媒体会话采用SIP进行对话并在对话期间发送请求时遵循SIP规则。所述对话指通信双方之间的一种SIP关系，它提供了在通信双方之间进行路由和消息排序时所依据的必要的状态信息。用户代理(UA，User Agent)或终端构成对话的端点。UA通常是用户设备(UE，UserEquipment)，即终端上的一个应用或一个专用的硬件设备。 
SIP通常使用会话描述协议(SDP，Session Description Protocol)提供/应答(offer/answer)模型进行媒体能力的交互同时完成承载能力的协商和承载的建立。比如：提供者向应答者提供一个SDP offer，其中包含提供者支持的和欲使用的媒体信息，包括媒体的类型，媒体地址和端口，媒体所采用的编解码类型以及相关的一些参数信息。应答者根据SDP offer的内容、自身的媒体能力、可以或愿意支持和使用的媒体类型等一系列信息对SDP offer做出应答，并且通过SDP answer对SDP offer做出应答。在应答者向提供者返回SDPanswer时需要对SDP offer提供的媒体流逐个进行应答，对每个媒体流的应答包括是否支持该媒体流，如果支持还需要返回应答者选用的编解码类型、应答端的媒体地址和端口、以及相关的一些参数信息。最终，提供者会根据SDPanswer和应答者建立媒体通道。 
用户有时需要获取其他设备之间的媒体流，例如：用户原本使用个人数字助理器(PDA，Personal Digital Assistant)和朋友视频聊天，他利用PDA的屏幕接收并播放朋友传来的视频流，利用PDA内置的摄像头发送自己的视频流 给朋友。这时，用户希望获取更好的视觉效果，于是他想操作投影仪获取原本是PDA收到的视频流，并用投影仪播放该视频流，但继续用PDA内置的摄像头发送视频流。通过使用SDP offer/answer模型，还无法实现媒体流的获取操作。 
现有技术提供了一种会话获取方法，假设UA2和UA3之间有一个会话，该会话包含一个音频流和一个视频流，UA1想把会话从UA3切换到自己这里，所述具体过程包括以下步骤： 
步骤a：UA1发送一个INVITE请求消息给UA2，所述INVITE请求消息包括Replaces头域，Replaces头域的内容是UA2和UA3之间的原有会话标识； 
所述INVITE请求消息结构如下： 
INVITE sip:ua2@example.com SIP/2.0 
To:<sip:ua2@example.com> 
From:<sip:ual@example.com>；tag＝uvw 
Call-ID:123 
Replaces:456；to-tag＝abc；from-tag＝def 
Contact:<sip:ual@example.com> 
Content-Type:application/sdp 
v＝0 
c＝IN IP4 192.168.0.10 
m＝audio 4400 RTP/AVP 0 8 
a＝sendonly 
m＝video 5400 RTP/AVP 31 34 
a＝sendrecv 
步骤b：UA2从Replaces头域中获得所述INVITE请求欲建立的会话，需要替代UA2和UA3之间的原有会话，UA2返回一个200OK响应消息，表明接受所述INVITE请求； 
步骤c：UA1发送一个ACK请求消息，表明新会话建立成功； 
步骤d：UA2把原来分配给被替代的会话的用户接口和其它资源分配给新的INVITE会话，并中止被替代的会话，并发送一个BYE请求给UA3； 
步骤e：UA3返回200OK响应消息，表明被替代的会话已经终止。 
从上述会话获取过程可以看出：当UA2接受了包含Replaces头域的INVITE请求后，它把属于UA3的整个会话切换给了UA1，但是UA1无法获取源会话中的部分媒体流，而且在INVITE请求中Replaces头域只能出现一次，因此UA1不能获取多个会话中的媒体流。因此，在进行本发明创造过程中，发明人发现现有技术中至少存在如下问题：现有技术提供的会话获取方法只能够获取一个会话，不能够获取一个或多个会话中部分或全部的媒体流。 
发明内容
有鉴于此，有必要提出一种媒体流获取方法及其系统、装置，能够实现从一个或多个源会话中获取部分或全部的媒体流。 
为解决上述技术问题，本发明实施例的目的是通过以下技术方案实现的： 
本发明实施例提供一种媒体流获取的方法，所述方法包括： 
目的端点发送获取媒体流的请求消息给对端点或源端点，所述获取媒体流请求消息包括需要获取的媒体流的信息； 
如果目的端点发送获取媒体流的请求消息给对端点，则目的端点获取由对端点根据所述媒体流的信息从源端点与对端点之间的至少一个源会话中切换至目的端点与对端点之间的会话中的媒体流； 
如果目的端点发送获取媒体流的请求消息给源端点，则目的端点获取由源端点根据目的端点需要获取的媒体流的信息从源端点与对端点之间的至少一个源会话中切换至目的端点与对端点之间的会话中的媒体流。 
本发明实施例还提供一种媒体流获取的系统，包括目的端点、对端点及源端点，所述目的端点用于从至少一个源端点与对端点之间的至少一个会话中获得需要获取的媒体流；所述目的端点包括： 
媒体流信息单元，用于获得目的端点需要获取的媒体流的信息； 
消息构造单元，用于根据媒体流信息单元获得的目的端点需要获取的媒体流的信息，构造获取媒体流的请求消息； 
信令处理单元，用于发送所述获取媒体流的请求消息； 
媒体处理单元，用于与对端点交互目的端点需要获取的媒体流。 
本发明实施例还提供一种媒体流获取的装置，用于从至少一个源端点与对端点之间的至少一个会话中获得需要获取的媒体流；所述装置包括： 
媒体流信息单元，用于获得需要获取的媒体流的信息； 
消息构造单元，用于根据媒体流信息单元获得的需要获取的媒体流的信息，构造获取媒体流的请求消息； 
信令处理单元，用于发送所述获取媒体流的请求消息； 
媒体处理单元，用于与其他设备交互需要获取的媒体流。 
通过本发明实施例提供的媒体流获取方法及其系统、装置，目的端点发送给对端点或源端点的获取媒体流的请求消息中包括需要获取的媒体流的信息，对端点或源端点可以根据目的端点需要获取的媒体流的信息从源端点与对端点之间的至少一个源会话中切换至目的端点与对端点之间的会话中的媒体流，因此能够实现从一个或多个源会话中获取部分或全部的媒体流。 
附图说明
图1为本发明媒体流获取方法第一较佳实施例的信令流程图； 
图2为本发明媒体流获取方法第二较佳实施例的信令流程图； 
图3为本发明媒体流获取方法第三较佳实施例的信令流程图； 
图4为本发明媒体流获取方法第四较佳实施例的信令流程图； 
图5为本发明媒体流获取系统第一较佳实施例的结构图； 
图6为本发明媒体流获取系统第二较佳实施例的结构图； 
图7为本发明媒体流获取装置较佳实施例的结构图。 
具体实施方式
本发明实施例提供一种媒体流获取方法及其系统、装置。为使本发明的技术方案更加清楚明白，以下参照附图并列举实施例，对本发明进一步详细说明。 
下面列举的几个本发明实施例中，参与媒体流获取操作的UA可分为源端点、对端点以及目的端点，其中，源端点通过与对端点之间建立的源会话进行媒体流交互，目的端点从源端点与对端点之间的源会话中获取媒体流，所述获取媒体流方法分为直接媒体流获取和间接媒体流获取两种方式：直接媒体流获取指的是目的端点直接发送SIP消息至对端点，要求从对端点与源端点之间的源会话中获取媒体流，对端点根据SIP消息把源会话中的媒体流切换至对端点与目的端点的会话中；间接媒体流获取指的是目的端点发送SIP 消息至源端点，要求从对端点与源端点之间的源会话中获取媒体流，源端点根据SIP消息把源会话中的媒体流切换至对端点与目的端点的会话中。 
请参照图1，为本发明媒体流获取方法第一较佳实施例的信令流程图。本实施例中，源端点与对端点之间存在两个音频流，目的端点采用直接媒体流获取方式从一个源会话中获取需要的音频流，即目的端点发送SIP消息给对端点，根据所述SIP消息，对端点将源会话中的第一个音频流切换至与目的端点的会话中，具体过程包括： 
步骤101：目的端点获得需要获取的媒体流的信息，所述媒体流的信息包括媒体流在源会话中的媒体流标识、媒体流所在源会话的标识等； 
本实施例中需要获取的媒体流的相关信息为源端点与对端点之间第一个音频流的相关信息。 
目的端点可以采用但不限于以下几种方法，获得需要获取的媒体流的相关信息： 
目的端点利用订阅/通知机制，向源端点发送SUBSCRIBE请求订阅媒体流信息，并根据从源端点返回的NOTIFY请求中获得需要获取的媒体流的相关信息； 
目的端点利用订阅/通知机制，向对端点发送SUBSCRIBE请求订阅媒体流信息，并根据从对端点返回的NOTIFY请求中获得需要获取的媒体流的相关信息； 
目的端点利用订阅/通知机制，向状态代理发送SUBSCRIBE请求订阅媒体流信息，并根据从状态代理返回的NOTIFY请求中获得需要获取的媒体流的相关信息； 
目的端点收到另一个UA(可以是对端点、源端点或其它UA)发送来的REFER请求，根据REFER请求中获得需要获取的媒体流的相关信息。 
步骤102：目的端点构造SIP消息，并发送给对端点，要求从源端点与对端点之间的源会话中获取需要的媒体流，所述SIP消息包括需要获取的媒体流的信息； 
所述SIP消息可以是一个SIP请求，例如INVITE请求(包括初始INVITE请求和对话内的INVITE请求)、UPDATE请求，也可以是一个SIP响应，例 如针对INVITE请求的200OK响应等。 
所述SIP消息包括预设的操作指示信息、目的端点提供的SDP offer、需要获取的媒体流的信息、以及原因信息。 
操作指示信息包括获取方式指示信息以及媒体流保留指示信息：获取方式指示信息用于指示媒体流获取方式为直接媒体流获取方式或者间接媒体流获取方式。本实施例中，获取方式指示信息指示媒体流获取方式为直接媒体流获取方式。媒体流保留指示信息用于指示执行媒体流获取操作后，收到所述SIP消息的对端点或源端点对源会话中的剩余媒体流的处理方式，处理方式包括源会话继续保留剩余的媒体流，以及删除剩余的媒体流。所述操作指示信息可以通过新增SIP头域来实现，也可以通过扩展已有的Replaces头域来实现，还可以通过扩展SIP消息携带的消息体来实现。 
所述目的端点提供的SDP offer，包括目的端点需要获取的媒体流的SDP参数，目的端点支持或者使用所述SDP参数。 
媒体流的信息包括源会话标识、媒体流标识等，源会话标识用于指示媒体流所属于的源会话；媒体流标识可以用于区别媒体流和所属会话中其他媒体流，也可以是用于媒体流区别其他媒体流的全局唯一标识。如果需要获取的媒体流为源端点与对端点之间源会话中部分媒体流，所述需要获取的媒体流的信息包括源会话标识和需要获取的媒体流的媒体流标识；如果需要获取的媒体流为源端点与对端点之间源会话中全部媒体流，所述需要获取的媒体流的信息可以仅包括源会话标识，因为所述SIP消息中可以仅通过源会话标识来指示目的端点需要获取的所有媒体流；如果需要获取的媒体流在源会话中的媒体流标识为全局唯一标识，所述需要获取的媒体流的信息可以仅包括需要获取的媒体流的媒体流标识，因为所述SIP消息中可以仅通过媒体流标识来指示目的端点需要获取的媒体流和媒体流所属的源会话。 
所述需要获取的媒体流的信息可以位于SIP消息的头域中，或者位于SDPoffer中，也可以位于SIP消息的头域中和SDP offer中。 
为实现直接媒体流获取方法，对端点需要为它参与的每个会话中的每个媒体流分配媒体流标识；假如对端点是发起SDP offer的一方，那么它在构建SDP offer时需要为每个媒体流分配一个媒体流标识；如果对端点是发送SDP answer的一方，如果它在收到的SDP offer中发现媒体流没有分配媒体流标识，那么可以在应答SDP answer时，为每个媒体流分配一个媒体流标识。 
为实现间接媒体流获取方法，源端点需要为它参与的每个会话中的每个媒体流分配媒体流标识。假如源端点是发起SDP offer的一方，那么它在构建SDP offer时需要为每个媒体流分配一个媒体流标识；如果源端点是发送SDPanswer的一方，如果它在收到的SDP offer中发现媒体流没有分配媒体流标识，那么可以在应答SDP answer时，为每个媒体流分配一个媒体流标识。 
媒体流标识可以采用任何一种合理形式，如果它是全局唯一标识，那么它可以是采用某种算法或者随机生成的唯一数，也可以是收发媒体流的媒体单元的IP地址和端口号等。如果它是在会话中唯一的标识，那么它可以是该媒体流在会话中的顺序号，也可以是一个标记，也可以是媒体流所属上层应用的内容属性，也可以是该媒体流的类型等。 
所述原因信息用于指明直接媒体流获取或者间接媒体流获取操作的相关文字描述信息，可以位于操作指示信息中，也可以位于其他头域中等。 
本实施例中，所述SIP消息为INVITE请求消息，所述INVITE请求消息携带的SDP offer中包括目的端点需要获取的媒体流的SDP参数，这些SDP参数是目的端点支持或欲使用的，下面举例说明INVITE消息的内容： 
INVITE sip:remote@example.com SIP/2.0 
To:<sip:remote@example.com> 
From:<sip:destination@example.com>；tag＝xyz 
Call-ID:456 
Replaces:123；to-tag＝aaa；from-tag＝bbb；media-retrieval 
preserve-direction＝true 
Content-Type:application/sdp 
v＝0 
c＝IN IP4 192.0.0.1 
m＝audio 4400 RTP/AVP 0 96 
a＝sendrecv 
a＝label:1 
本实施例中，所述INVITE请求消息通过扩展的Replaces头域表示操作指示信息，其中的参数media-retrieval表示这是一个直接媒体流获取操作；Replaces头域中的“123；to-tag＝aaa；from-tag＝bbb”指明了源会话标识，源会话标识对应的源会话标签“preserve-direction”表示媒体流保留指示信息，“true”表示媒体流获取操作结束后，将保留源会话中的剩余媒体流。 
所述SDP中，“c＝”行代表的是目的端点的IP地址；“m＝”行代表的是目的端点欲获取的媒体流；“a＝label”代表的是目的端点欲获取的媒体流的媒体流标识。在本实施例中，媒体流标识的取值是媒体流在源会话中的顺序号，“1”表明需要获取的是源会话中的第一个媒体流。 
步骤103：对端点根据接收的SIP消息，向目的端点返回携带SDP answer的应答消息，经过目的端点与对端点之间的SDP offer/answer交互后，对端点与目的端点之间建立新会话，所述新会话中包括目的端点需要获取的媒体流； 
本实施例中，对端点向目的端点返回“200OK”响应消息，表明对端点接受了所述INVITE会话请求，所述响应消息中携带的SDP answer中包括所述需要获取的媒体流的SDP参数，所述SDP参数是对端点支持或欲使用的，下面举例说明响应消息的内容： 
SIP/2.0200OK 
To:<sip:remote@example.com>；tag＝lmn 
From:<sip:destination@example.com>；tag＝xyz 
Call-ID:456 
Content-Type:application/sdp 
v＝0 
c＝IN IP4 192.0.0.3 
m＝audio 2000 RTP/AVP 0 96 
a＝sendrecv 
在所述SDP中，“c＝”行代表的是对端点的媒体处理单元的IP地址；“m＝”行代表的是需要获取的媒体流。 
步骤104：目的端点向对端点发送新会话建立成功的确认(ACK)消息； 
步骤105：对端点向源端点发送要求更新源会话的请求，要求删除目的端点已经获取的媒体流； 
本实施例中，所述更新源会话的请求为INVITE请求，下面举例说明INVITE请求的内容： 
INVITE sip:source@example.com SIP/2.0 
To:<sip:source@example.com>；tag＝bbb 
From:<sip:remote@example.com>；tag＝aaa 
Call-ID:123 
Content-Type:application/sdp 
v＝0 
c＝IN IP4 192.0.0.3 
m＝audio 0 RTP/AVP 96 
m＝audio 5500 RTP/AVP 98 99 
a＝sendrecv 
步骤106：源端点接受对端点发送的要求更新源会话的请求，向对端点返回“200OK”响应消息，并在源会话中删除目的端点获取的媒体流； 
步骤107：源端点向对端点发送确认消息，表明源会话更新成功。 
本实施例中，最终结果为目的端点与对端点之间新建的会话中包含第一个音频流，源端点与对端点的源会话中包含第二个音频流。 
请参照图2，为本发明获取媒体流方法第二较佳实施例的信令流程图，本实施例中，源端点1与对端点之间存在一个音频流，源端点2与对端点之间存在一个视频流，目的端点采用直接媒体流获取方式从多个源会话中获取需要的音频流以及视频流，具体过程包括： 
步骤201：目的端点获得需要获取的媒体流的相关信息； 
本实施例中需要获取的媒体流的相关信息为源端点1与对端点之间音频流的相关信息，以及源端点2与对端点之间的视频流的相关信息。 
目的端点获得需要获取的媒体流的相关信息的方法与第一较佳实施中相同，这里不再赘述。 
步骤202：目的端点构造SIP消息，并发送给对端点，要求从源端点1、 源端点2与对端点之间的源会话中获取需要的媒体流，所述SIP消息包括需要获取的媒体流的信息； 
所述SIP消息的类型和包括的内容与第一较佳实施中相同，这里不再赘述。 
本实施例中，所述SIP消息为INVITE请求消息，所述INVITE请求消息携带的SDP offer中包括目的端点需要获取的媒体流的SDP参数，所述SDP参数是目的端点支持或欲使用的，下面举例说明INVITE请求消息的内容： 
INVITE sip:remote@example.com SIP/2.0 
To:<sip:remote@example.com> 
From:<sip:destination@example.com>；tag＝xyz 
Call-ID:456 
Content-Type:application/sdp 
v＝0 
c＝IN IP4 192.0.0.1 
m＝audio 4400 RTP/AVP 0 96 
a＝sendrecv 
a＝unique-id:12456784333224 
m＝video 5400 RTP/AVP 97 98 
a＝sendrecv 
a＝unique-id:876493826224565 
本实施例中，获取方式指示信息指示媒体流获取方式为直接媒体流获取方式，在所述SDP中的“a＝unique-id”表示这是一个直接媒体流获取操作。媒体流标识的值“12456784333224”是一个媒体流的全局唯一标识，它代表对端点和源端点1之间的源会话中的媒体流；“876493826224565”是另一个媒体流的全局唯一标识，它代表对端点和源端点2之间的源会话中的媒体流。“c＝”行代表的是目的端点的媒体处理单元的IP地址；“m＝”行代表的是目的端点欲获取的媒体流。由于媒体流标识是对应媒体流的全局唯一标识，因此对端点通过媒体流标识能够获知源会话，所以INVITE消息中可以省略源会话标识。 
下面举例说明INVITE请求消息另一种内容： 
INVITE sip:remote@example.com SIP/2.0 
To:<sip:remote@example.com> 
From:<sip:destination@example.com>；tag＝xyz 
Call-ID:456 
Retrieval:123；to-tag＝aaa；from-tag＝bbb 
Retrieval:135；to-tag＝efg；from-tag＝hij 
Content-Type:application/sdp 
v＝0 
c＝IN IP 4 192.0.0.1 
m＝audio 4400 RTP/AVP 0 96 
a＝sendrecv 
m＝video 5400 RTP/AVP 97 98 
a＝sendrecv 
在所述INVITE请求中使用了预设的Retrieval头域代表操作指示信息，表明这是一个直接媒体流获取操作。第一个Retrieval头域的值“123；to-tag＝aaa；from-tag＝bbb”代表一个源会话标识，该源会话标识对应的是对端点和源端点1之间的源会话。另一个Retrieval头域的值“135；to-tag＝efg；from-tag＝hij”代表另一个源会话标识，该源会话标识对应的是对端点和源端点2之间的源会话。因为目的端点需要获取两个源会话中的全部媒体流，因此INVITE消息中可以省略媒体流标识。 
步骤203：对端点根据接收的SIP消息，向目的端点返回携带SDP answer的应答消息，经过目的端点与对端点之间的SDP offer/answer交互后，对端点与目的端点之间建立新会话，所述新会话中包括目的端点需要获取的媒体流； 
本实施例中，对端点向目的端点返回“200OK”响应消息，表明对端点接受了所述INVITE请求，所述响应消息中携带对端点应答的SDP answer，其中包括所述需要获取的媒体流的SDP参数，所述SDP参数是对端点支持或欲使用的。 
步骤204：目的端点向对端点发送新会话建立成功的确认消息； 
步骤205：对端点向源端点1发出终止两者间的源会话的请求，本实施例中终止两者间的源会话的请求为BYE请求； 
步骤206：源端点1接受对端点发送的终止两者间的源会话的请求，向对端点返回“200OK”响应消息，并终止两者间的源会话； 
步骤207：对端点向源端点2发出终止两者间的源会话的请求，本实施例中终止两者间的源会话的请求为BYE请求； 
步骤208：源端点2接受对端点发送的终止两者间的源会话的请求，向对端点返回“200OK”响应消息，并终止两者间的源会话。 
本实施例中，最终结果为目的端点和对端点之间新建会话中包含一个音频流和一个视频流。 
请参照图3，为本发明媒体流获取方法第三较佳实施例的信令流程图。本实施例中，源端点与对端点之间的源会话存在一个音频流和一个视频流，目的端点采用间接媒体流获取方式从所述源会话中获取需要的音频流，即目的端点发送SIP消息给源端点，根据所述SIP消息，源端点将源会话中的音频流切换至目的端点与对端点之间的会话中，具体过程包括： 
步骤301：目的端点获得需要获取的媒体流的相关信息； 
本实施例中需要获取的媒体流的相关信息为源端点与对端点之间音频流的相关信息。 
目的端点获得需要获取的媒体流的相关信息的方法与第一较佳实施中相同，这里不再赘述。 
步骤302：目的端点构造SIP消息，并发送给源端点，要求从源端点与对端点之间的源会话中获取需要的媒体流，所述SIP消息包括需要获取的媒体流的信息； 
所述SIP消息的类型和包括的内容与第一较佳实施中相同，这里不再赘述。 
本实施例中，所述SIP消息为INVITE请求消息，所述INVITE请求消息携带的SDP offer 1中包括目的端点需要获取的媒体流的相关SDP参数，所述SDP参数是目的端点支持或欲使用的，下面举例说明INVITE请求消息的内容： 
INVITE sip:source@example.com SIP/2.0 
To:<sip:source@example.com> 
From:<sip:destination@example.com>；tag＝xyz 
Call-ID:135 
Indirect-Retrieval:789；to-tag＝abc；from-tag＝def；preserve-direction＝true 
Content-Type:application/sdp 
v＝0 
c＝IN IP4 192.0.0.1 
m＝audio 4400 RTP/AVP 0 96 
a＝sendrecv 
a＝label:1 
本实施例中，获取方式指示信息指示媒体流获取方式为间接媒体流获取方式，在所述INVITE请求中，Indirect-Retrieva头域中1代表操作指示信息，表明这是一个间接媒体流获取操作；Indirect-Retrieval头域中的“789；to-tag＝abc；from-tag＝def”指明了源会话标识，所述源会话标识对应的是源端点和对端点之间的源会话；标签“preserve-direction”代表保留指示，“true”代表媒体流获取操作结束后，将保留源会话中的剩余媒体流。 
在SDP中，“a＝label”代表媒体流标识，媒体流标识的取值是媒体流在源会话中的顺序号，“1”表明需要获取的是源会话中的第一个媒体流。 
步骤303：源端点向对端点发送更新源会话的请求，所述请求消息中包括目的端点需要获取的媒体流的相关参数，以及源会话中剩余的媒体流的相关参数； 
本实施例中，所述更新源会话的请求为INVITE请求，所述INVITE请求消息携带的SDP offer 2中包括目的端点需要获取的媒体流的相关SDP参数，以及源会话中剩余的媒体流的相关SDP参数，下面举例说明INVITE消息的内容： 
INVITE sip:remote@example.com SIP/2.0 
To:<sip:remote@example.com>；tag＝def 
From:<sip:source@example.com>；tag＝abc 
Call-ID:789 
Content-Type:application/sdp 
v＝0 
m＝audio 4400 RTP/AVP 0 96 
a＝sendrecv 
c＝IN IP4 192.0.0.1 
m＝video 5500 RTP/AVP 98 99 
a＝sendrecv 
c＝IN IP4 192.0.0.2 
所述SDP offer 2中包含了SDP offer 1的信息，对于需要切换的音频流，SDP offer 2中列出的是目的端点的IP地址、端口号和欲使用的编解码格式等参数，这些信息是从SDP offer 1中提取的；对于源会话中剩余的视频流，SDPoffer 2中给出的是源端点的IP地址、端口号和欲使用的编解码格式等参数。 
步骤304：对端点根据接收的更新源会话的请求，向源端点返回响应消息，携带目的端点需要获取的媒体流的相关参数，以及源会话中剩余的媒体流的相关参数； 
本实施例中，对端点向源端点返回“200OK”响应消息，所述响应消息中携带对端点应答的SDP answer 2，其包括目的端点需要获取的媒体流的相关参数，以及源会话中剩余的媒体流的SDP参数，所述SDP参数是对端点支持或欲使用的，下面举例说明响应消息的内容： 
SIP/2.0 200OK 
To:<sip:remote@example.com>；tag＝def 
From:<sip:source@example.com>；tag＝abc 
Call-ID:789 
Content-Type:application/sdp 
v＝0 
c＝IN IP4 192.0.0.3 
m＝audio 5000 RTP/AVP 0 96 
a＝sendrecv 
m＝video 6000 RTP/AVP 98 99 
a＝sendrecv 
步骤305：源端点向对端点发送确认消息，表明源会话更新成功； 
步骤306：源端点向目的端点返回携带SDP answer的应答消息，携带目的端点需要获取的媒体流的SDP参数，所述SDP参数原本是对端点支持或欲使用的，经过目的端点与源端点、源端点与对端点之间的SDP offer/answer交互后，目的端点与对端点之间建立媒体通道以便获取需要的媒体流； 
本实施例中，源端点向目的端点返回“200OK”响应消息，所述响应消息中携带源端点应答的SDP answer 1，其包括目的端点需要获取的媒体流的相关参数，这些参数从SDP answer 2中获取，下面举例说明响应消息的内容： 
SIP/2.0 200OK 
To:<sip:source@example.com>；tag＝uvw 
From:<sip:destination@example.com>；tag＝xyz 
Call-ID:135 
Content-Type:application/sdp 
v＝0 
c＝IN IP4 192.0.0.3 
m＝audio 5000 RTP/AVP 0 96 
a＝sendrecv 
步骤307：目的端点向源端点发送确认消息，表明目的端点与源端点之间的对话建立成功。 
本实施例中，最终结果为目的端点和对端点之间建立媒体通道来传送媒体流，如果目的端点再次要求从源端点与对端点之间获取其他媒体流、目的端点或对端点的地址发生变化等，目的端点和对端点之间交互的信令需要经过源端点来转发。 
请参照图4，为本发明获取媒体流方法第四较佳实施例的信令流程图，本实施例中，源端点与对端点1之间存在一个音频流，源端点与对端点2之间存在一个视频流，目的端点采用间接媒体流获取方式从多个源会话中获取需要的音频流以及视频流，具体过程包括： 
步骤401：目的端点获得需要获取的媒体流的相关信息； 
本实施例中需要获取的媒体流的相关信息为源端点与对端点1之间音频流的相关信息，以及源端点与对端点2之间的视频流的相关信息； 
目的端点获得需要获取的媒体流的相关信息的方法与第一较佳实施中相同，这里不再赘述。 
步骤402：目的端点构造SIP消息，并发送给源端点，要求从源端点分别与对端点1、对端点2之间的源会话中获取需要的媒体流，所述SIP消息包括需要获取的媒体流的信息； 
所述SIP消息的类型和包括的内容与第一较佳实施中相同，这里不再赘述。 
本实施例中，所述SIP消息为INVITE请求消息，所述INVITE请求消息携带的SDP offer 1中包括目的端点需要获取的媒体流的SDP参数，所述SDP参数是目的端点支持或欲使用的，下面举例说明INVITE请求消息的内容： 
INVITE sip:source@example.com SIP/2.0 
To:<sip:source@example.com> 
From:<sip:destination@example.com>；tag＝xyz 
Call-ID:456 
Content-Type:application/sdp 
v＝0 
c＝IN IP4 192.0.0.1 
m＝audio 4400 RTP/AVP 0 96 
a＝sendrecv 
a＝uid:123abcgkeo224 
m＝video 5400 RTP/AVP 97 98 
a＝sendrecv 
a＝uid:zxywhi565dfddf 
本实施例中，获取方式指示信息指示媒体流获取方式为间接媒体流获取方式，在所SDP中的“a＝uid”表明这是一个间接媒体流获取操作。媒体流标识的值“123abcgkeo224”是一个媒体流的全局唯一标识，它代表源端点和对 端点1之间的源会话中的媒体流；“zxywhi565dfddf”是另一个媒体流的全局唯一标识，它代表源端点和对端点2之间的源会话中的媒体流。“c＝”行代表的是目的端点的IP地址；“m＝”行代表的是目的端点欲获取的媒体流。由于媒体流标识是对应媒体流的全局唯一标识，因此对端点通过媒体流标识能够获知源会话，所以SDP中可以省略源会话标识。 
下面举例说明INVITE请求消息另一种内容： 
INVITE sip:source@example.com SIP/2.0 
To:<sip:source@example.com> 
From:<sip:destination@example.com>；tag＝xyz 
Call-ID:456 
Indirect-Retrieval:111；to-tag＝hhh；from-tag＝jjj 
Indirect-Retrieval:335；to-tag＝xcv；from-tag＝zxd 
Content-Type:application/sdp 
v＝0 
c＝IN IP4 192.0.0.1 
m＝audio 4400 RTP/AVP 0 96 
a＝sendrecv 
m＝video 5400 RTP/AVP 97 98 
a＝sendrecv 
在所述INVITE请求中使用了预设的Indirect-Retrieval头域代表操作指示信息，表明这是一个间接媒体流获取操作。第一个Indirect-Retrieval头域的值“111；to-tag＝hhh；from-tag＝jjj”代表一个源会话标识，该源会话标识对应的是源端点和对端点1之间的源会话。另一个Indirect-Retrieval头域的值“335；to-tag＝xcv from-tag＝zxd”代表另一个源会话标识，该源会话标识对应的是源端点和对端点2之间的源会话。因为目的端点需要获取两个源会话中的全部媒体流，因此SIP消息中可以省略媒体流标识。 
步骤403：源端点向对端点1发送更新源会话的请求，所述请求消息中包括目的端点需要获取的媒体流的相关参数； 
本实施例中，所述更新源会话的请求为INVITE请求，所述INVITE请求 消息携带的SDP offer 2中包括目的端点需要获取的媒体流的SDP参数，所述SDP参数是目的端点支持或欲使用的，下面举例说明INVITE请求消息的内容： 
INVITE sip:remotel@example.com SIP/2.0 
To:<sip:remotel@example.com>；tag＝jjj 
From:<sip:source@example.com>；tag＝hhh 
Call-ID:111 
Content-Type:application/sdp 
v＝0 
c＝IN IP4 192.0.0.1 
m＝audio 4400 RTP/AVP 0 96 
a＝sendrecv 
所述SDP offer 2中包含了SDP offer 1的部分信息，对于需要切换的音频流，SDP offer 2中列出的是目的端点的IP地址、端口号和欲使用的编解码格式，这些信息是从SDP offer 1中提取的。 
步骤404：对端点1根据接收的更新源会话的请求，向源端点返回响应消息，携带目的端点需要获取的媒体流的相关参数； 
本实施例中，对端点1向源端点返回“200OK”响应消息，所述响应消息中携带对端点1应答的SDP answer 2，其包括目的端点需要获取的媒体流的SDP参数，所述SDP参数是对端点1支持或欲使用的下面举例说明响应消息的内容： 
SIP/2.0 200OK 
To:<sip:remotel@example.com>；tag＝jjj 
From:<sip:source@example.com>；tag＝hhh 
Call-ID:111 
Content-Type:application/sdp 
v＝0 
c＝IN IP4 192.168.99.1 
m＝audio 1000 RTP/AVP 0 96 
a＝sendrecv 
步骤405：源端点向对端点发送确认消息，表明源会话更新成功； 
步骤406：源端点向对端点2发送更新源会话的请求，所述请求消息中包括目的端点需要获取的媒体流的相关参数； 
本实施例中，所述更新源会话的请求为INVITE请求，所述INVITE请求消息携带的SDP offer 3中包括目的端点需要获取的媒体流的相关SDP参数，所述SDP参数是目的端点支持或欲使用的，下面举例说明INVITE请求消息的内容： 
INVITE sip:remotel@example.com SIP/2.0 
To:<sip:remotel@example.com>；tag＝zxd 
From:<sip:source@example.com>；tag＝xcv 
Call-ID:335 
Content-Type:application/sdp 
v＝0 
c＝IN IP4 192.0.0.1 
m＝video 5400 RTP/AVP 97 98 
a＝sendrecv 
所述SDP offer 3中包含了SDP offer 1的部分信息，对于需要切换的音频流，SDP offer 3中列出的是目的端点的IP地址、端口号和欲使用的编解码格式，这些信息是从SDP offer 1中提取的。 
步骤407：对端点2根据接收的更新源会话的请求，向源端点返回响应消息，携带目的端点需要获取的媒体流的相关参数； 
本实施例中，对端点2向源端点返回“200OK”响应消息，所述响应消息中携带对端点2应答的SDP answer 3，其包括目的端点需要获取的媒体流的SDP参数，所述SDP参数是对端点2支持或欲使用的，下面举例说明响应消息的内容： 
SIP/2.0 200OK 
To:<sip:remotel@example.com>；tag＝zxd 
From:<sip:source@example.com>；tag＝xcv 
Call-ID:335 
Content-Type:application/sdp 
v＝0 
c＝IN IP4 192.168.99.2 
m＝video 2000 RTP/AVP 97 98 
a＝sendrecv 
步骤408：源端点向对端点2发送确认消息，表明源会话更新成功； 
步骤409：源端点向目的端点返回携带SDP answer的应答消息，携带目的端点需要获取的媒体流的相关参数，经过目的端点与源端点、源端点分别与对端点1、对端点2之间的SDP offer/answer交互后，目的端点与对端点1、对端点2之间分别建立媒体通道以便获取需要的媒体流； 
本实施例中，源端点向目的端点返回“200OK”响应消息，所述响应消息中携带源端点应答的SDP answer 1，其包括目的端点需要获取的媒体流的相关参数，这些参数从SDP answer 2和SDP answer 3中获取，是对端点1或对端点2支持或欲使用的，下面举例说明响应消息的内容： 
SIP/2.0 200OK 
To:<sip:source@example.com>；tag＝oppe3edd 
From:<sip:destination@example.com>；tag＝xyz 
Call-ID:456 
Content-Type:application/sdp 
v＝0 
m＝audio 1000 RTP/AVP 0 96 
a＝sendrecv 
c＝IN IP4 192.168.99.1 
m＝video 2000 RTP/AVP 97 98 
a＝sendrecv 
c＝IN IP4 192.168.99.2 
步骤410：目的端点向源端点发送确认消息，表明目的端点与源端点之间对话建立成功。 
本实施例中，最终结果是目的端点和对端点1的媒体通道中包含一个音频流，目的端点和对端点2的媒体通道中包含一个视频流。如果目的端点再次要求从源端点与对端点1或对端点2之间获取其他媒体流、目的端点或对端点1、对端点2的地址发生变化等，目的端点和对端点1或对端点2之间交互的信令需要经过源端点来转发。 
请参照图5，为本发明媒体流获取系统第一较佳实施例的结构图。所述媒体流获取系统包括源端点51、对端点52以及目的端点53。所述源端点51包括信令处理单元511以及媒体处理单元512。所述对端点52包括媒体流标识生成单元521、媒体处理单元522、信令处理单元523以及操作处理单元524。所述目的端点53包括媒体流信息单元531、消息构造单元532、信令处理单元533以及媒体处理单元534。 
所述目的端点53的媒体流信息单元531用于获得目的端点需要获取的媒体流的信息；所述消息构造单元532用于根据媒体流信息单元531获得的目的端点需要获取的媒体流的信息，构造获取媒体流的请求消息；所述信令处理单元533用于发送所述获取媒体流的请求消息给对端点52；所述媒体处理单元534用于与对端点52交互需要获取的媒体流。 
所述源端点51的信令处理单元511用于与对端点52交互信令；所述媒体处理单元512用于与对端点52交互媒体流。 
所述对端点52的媒体流标识生成单元521用于为对端点所参与的会话中的媒体流分配媒体流标识；所述信令处理单元522用于接收目的端点53发送的获取媒体流的请求消息；所述操作处理单元524根据所述信令处理单元522获取媒体流的请求消息，将与源端点51之间的源会话中的目的端点需要获取的媒体流切换至与目的端点53之间的会话中；所述媒体处理单元523，用于与源端点51和目的端点53交互媒体流。 
本实施例中，目的端点可以从一个或多个源端点与对端点之间的一个或多个会话中获得需要获取的媒体流。 
请参照图6，为本发明媒体流获取系统第二较佳实施例的结构图。所述媒体流获取系统包括源端点61、对端点62以及目的端点63。所述源端点61包括媒体流标识生成单元611、信令处理单元612、媒体处理单元613以及操作 处理单元614。所述对端点62包括信令处理单元621和媒体处理单元622。所述目的端点63包括媒体流信息单元631、消息构造单元632、信令处理单元633以及媒体处理单元634。 
所述目的端点63的媒体流信息单元631用于获得目的端点需要获取的媒体流的信息；所述消息构造单元632用于根据媒体流信息单元631获得的目的端点需要获取的媒体流的信息，构造获取媒体流的请求消息；所述信令处理单元633用于发送所述获取媒体流的请求消息给源端点61；所述媒体处理单元634用于从对端点62获取需要的媒体流。 
所述源端点61的媒体流标识生成单元611用于为源端点所参与的会话中的媒体流分配媒体流标识；所述信令处理单元612用于接收目的端点63发送的获取媒体流的请求消息；所述操作处理单元614根据所述信令处理单元612接收的获取媒体流的请求消息，将源端点61与对端点62之间的源会话中的目的端点需要获取的媒体流切换至目的端点63与对端点62之间的会话中。所述媒体处理单元613用于与对端点62交互媒体流。 
所述对端点62的信令处理单元621用于与源端点61交互信令；所述媒体处理单元622用于与目的端点63和源端点61交互媒体流。 
本实施例中，目的端点可以从源端点与一个或多个对端点之间的一个或多个会话中获得需要获取的媒体流。 
请参照图7，为本发明获取媒体流装置较佳实施例的结构图。所述获取媒体流装置70包括媒体流信息单元71、消息构造单元72、信令处理单元73、媒体处理单元74。所述媒体流信息单元71用于获得需要获取的媒体流的信息；所述消息构造单元72用于根据媒体流信息单元获得的需要获取的媒体流的信息，构造获取媒体流的请求消息；所述信令处理单元73用于发送所述获取媒体流的请求消息；所述媒体处理单元74用于从其他设备获取需要的媒体流。 
通过本发明实施例提供的媒体流获取方法及其系统、装置，目的端点可以根据需要获取媒体流的媒体流标识，从源端点与对端点之间的一个或多个源会话中获得与媒体流标识对应的媒体流，因此能够实现从一个或多个源会话中获取部分或全部的媒体流。 
以上对本发明所提供的一种媒体流获取方法及其系统、装置行了详细介 绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明所揭示的技术方案；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。 

Claims (23)

1.一种媒体流获取的方法，其特征在于，所述方法包括：
目的端点发送获取媒体流的请求消息给对端点或源端点，要求获取源端点与对端点之间的至少一个源会话中的媒体流，所述获取媒体流请求消息包括需要获取的媒体流的信息；
如果目的端点发送获取媒体流的请求消息给对端点，则目的端点获取由对端点根据所述媒体流的信息从源端点与对端点之间的至少一个源会话中切换至目的端点与对端点之间的会话中的媒体流；
如果目的端点发送获取媒体流的请求消息给源端点，则目的端点获取由源端点根据目的端点需要获取的媒体流的信息从源端点与对端点之间的至少一个源会话中切换至目的端点与对端点之间的会话中的媒体流。
2.根据权利要求1所述的媒体流获取的方法，其特征在于，所述发送获取媒体流的请求消息为会话发起协议消息，所述会话发起协议消息携带会话描述协议提供消息体。
3.根据权利要求2所述的媒体流获取的方法，其特征在于，所述会话描述协议提供消息体中包括需要获取的媒体流的会话描述协议参数，所述需要获取的媒体流的信息位于会话发起协议消息的头域中，和/或位于会话描述协议提供消息体中。
4.根据权利要求2所述的媒体流获取的方法，其特征在于，对端点根据目的端点需要获取的媒体流的信息，将目的端点需要获取的媒体流从与至少一个源端点之间的源会话中切换至与目的端点之间的会话中具体为：
对端点根据从目的端点发送的会话发起协议消息所携带的会话描述协议提供消息体，向目的端点返回携带会话描述协议应答消息体的响应消息，所述会话描述协议应答消息体中包括需要获取的媒体流的会话描述协议参数；
经过目的端点与对端点之间的会话描述协议提供和应答交互后，对端点与目的端点之间建立新会话或者原有会话更新，对端点与目的端点通过建立的会话或者更新后的会话交互目的端点需要获取的媒体流。
5.根据权利要求4所述的媒体流获取的方法，其特征在于，所述经过目的端点与对端点之间的会话描述协议提供和应答交互后，对端点删除源会话中的目的端点需要获取的媒体流。
6.根据权利要求1所述的媒体流获取的方法，其特征在于，所述发送获取媒体流的请求消息为会话发起协议消息，所述会话发起协议消息携带第一会话描述协议提供消息体。
7.根据权利要求6所述的媒体流获取的方法，其特征在于，所述第一会话描述协议提供消息体中包括需要获取的媒体流的会话描述协议参数，所述需要获取的媒体流的信息位于会话发起协议消息的头域中，和/或位于第一会话描述协议提供消息体中。
8.根据权利要求6所述的媒体流获取的方法，其特征在于，源端点根据目的端点需要获取的媒体流的信息，将目的端点需要获取的媒体流从与至少一个对端点之间的源会话中切换至目的端点于各个对端点之间的会话中具体为：
源端点向对端点发送更新源端点与对端点之间源会话的请求，所述请求中携带第二会话描述协议提供消息体，所述第二会话描述协议提供消息体中包括需要获取的媒体流的会话描述协议参数，所述会话描述协议参数是目的端点在第一会话描述协议提供消息体中提供的；
根据从源端点发送的更新源会话请求中所携带的第二会话描述协议提供消息体，对端点向源端点返回携带第二会话描述协议应答消息体的响应消息，所述第二会话描述协议应答消息体中包括需要获取的媒体流的会话描述协议参数；
源端点根据收到的携带第二会话描述协议应答消息体的响应消息，生成第一会话描述协议应答消息体，所述第一会话描述协议应答消息体中包括需要获取的媒体流的会话描述协议参数，所述会话描述协议参数是对端点在第二会话描述协议应答消息体中提供的；
源端点发送携带第一会话描述协议应答消息体的响应消息给目的端点；
经过第一会话描述协议提供和应答、第二会话描述协议提供和应答的交互后，对端点与目的端点之间建立媒体通道，对端点与目的端点通过建立的媒体通道交互目的端点需要获取的媒体流。
9.根据权利要求1至5中任一权利要求所述的媒体流获取的方法，其特征在于，对端点为它参与的每个会话中的每个媒体流分配媒体流标识。
10.根据权利要求1、6至8中任一权利要求所述的媒体流获取的方法，其特征在于，源端点为它参与的每个会话中的每个媒体流分配媒体流标识。
11.根据权利要求1至5中任一权利要求所述的媒体流获取的方法，其特征在于，所述获取媒体流请求消息中还包括获取方式指示信息，所述获取方式指示信息用于指示媒体流获取方式为直接媒体流获取方式。
12.根据权利要求11所述的媒体流获取的方法，其特征在于，所述获取媒体流请求消息中还包括媒体流保留指示信息，用于指示对源会话中的剩余媒体流的处理方式，如果媒体流保留指示信息要求不保留剩余媒体流，则对端点删除源会话中的剩余媒体流。
13.根据权利要求6至8中任一权利要求所述的媒体流获取的方法，其特征在于，所述获取媒体流请求消息中还包括获取方式指示信息，所述获取方式指示信息用于指示媒体流获取方式为间接媒体流方式。
14.根据权利要求13所述的媒体流获取的方法，其特征在于，所述获取媒体流请求消息中还包括媒体流保留指示信息，用于指示对源会话中的剩余媒体流的处理方式，如果媒体流保留指示信息要求不保留剩余媒体流，则源端点删除源会话中的剩余媒体流。
15.根据权利要求1至8中任一权利要求所述的媒体流获取的方法，其特征在于，如果需要获取的媒体流为源端点与对端点之间源会话中部分媒体流，所述需要获取的媒体流的信息包括源会话标识和需要获取的媒体流的媒体流标识，所述源会话标识用于指示需要获取的媒体流所属于的源会话；所述媒体流标识用于指示需要获取的媒体流，它可以是用于区别媒体流和所属会话中的其他媒体流的标识，也可以是用于媒体流区别其它任何媒体流的全局唯一标识。
16.根据权利要求1至8中任一权利要求所述的媒体流获取的方法，其特征在于，如果需要获取的媒体流为源端点与对端点之间源会话中全部媒体流，所述需要获取的媒体流的信息包括源会话标识，所述源会话标识用于指示需要获取的媒体流所属于的源会话。
17.根据权利要求1至8中任一权利要求所述的媒体流获取的方法，其特征在于，如果需要获取的媒体流在源会话中的媒体流标识为全局唯一标识，所述需要获取的媒体流的信息包括需要获取的媒体流的媒体流标识，所述媒体流标识用于指示需要获取的媒体流。
18.一种媒体流获取的系统，包括目的端点、对端点及源端点，其特征在于，所述目的端点用于从至少一个源端点与对端点之间的至少一个会话中获得需要获取的媒体流；
所述目的端点包括：
媒体流信息单元，用于获得目的端点需要获取的媒体流的信息；
消息构造单元，用于根据媒体流信息单元获得的目的端点需要获取的媒体流的信息，构造获取媒体流的请求消息；
信令处理单元，用于发送所述获取媒体流的请求消息；
媒体处理单元，用于与对端点交互目的端点需要获取的媒体流。
19.根据权利要求18所述的媒体流获取的系统，其特征在于，
所述对端点包括：
信令处理单元，用于接收目的端点发送的获取媒体流的请求消息；
操作处理单元，根据所述信令处理单元接收的获取媒体流的请求消息，将目的端点需要获取的媒体流切换至与目的端点之间的会话中；
媒体处理单元，用于与源端点和目的端点交互媒体流；
所述源端点包括：
信令处理单元，用于与对端点交互信令；
媒体处理单元，用于与对端点交互媒体流。
20.根据权利要求19所述的媒体流获取的系统，其特征在于，所述对端点还包括媒体流标识生成单元，用于为对端点所参与的会话中的媒体流分配媒体流标识。
21.根据权利要求18所述的媒体流获取的系统，其特征在于，
所述源端点包括：
信令处理单元，用于接收目的端点发送的获取媒体流的请求消息；
操作处理单元，根据所述信令处理单元接收的获取媒体流的请求消息，将目的端点需要获取的媒体流切换至对端点与目的端点之间的会话中；
媒体处理单元，用于与对端点交互媒体流，
所述对端点包括：
信令处理单元，用于与源端点交互信令；
媒体处理单元，用于与源端点和目的端点交互媒体流。
22.根据权利要求21所述的媒体流获取的系统，其特征在于，所述源端点还包括媒体流标识生成单元，用于为源端点所参与的会话中的媒体流分配媒体流标识。
23.一种媒体流获取的装置，用于获取其他设备之间的媒体流，其特征在于，所述装置用于从至少一个源端点与对端点之间的至少一个会话中获得需要获取的媒体流；所述装置包括：
媒体流信息单元，用于获得需要获取的媒体流的信息；
消息构造单元，用于根据媒体流信息单元获得的需要获取的媒体流的信息，构造获取媒体流的请求消息；
信令处理单元，用于发送所述获取媒体流的请求消息；
媒体处理单元，用于与对端点交互需要获取的媒体流。
CN2007100793982A 2007-02-16 2007-02-16 媒体流获取方法及其系统、装置 Expired - Fee Related CN101247386B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN2007100793982A CN101247386B (zh) 2007-02-16 2007-02-16 媒体流获取方法及其系统、装置
PCT/CN2008/070322 WO2008101443A1 (fr) 2007-02-16 2008-02-18 Procédé, système et dispositif pour acquérir un flux multimédia

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN2007100793982A CN101247386B (zh) 2007-02-16 2007-02-16 媒体流获取方法及其系统、装置

Publications (2)

Publication Number Publication Date
CN101247386A CN101247386A (zh) 2008-08-20
CN101247386B true CN101247386B (zh) 2011-05-11

Family

ID=39709655

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2007100793982A Expired - Fee Related CN101247386B (zh) 2007-02-16 2007-02-16 媒体流获取方法及其系统、装置

Country Status (2)

Country Link
CN (1) CN101247386B (zh)
WO (1) WO2008101443A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101848194B (zh) * 2009-03-23 2013-01-02 华为技术有限公司 媒体转移方法和系统、服务器及用户设备
KR101918040B1 (ko) * 2012-02-20 2019-01-29 삼성전자주식회사 스크린 미러링 방법 및 그 장치
CN102801725B (zh) * 2012-08-06 2016-01-20 苏州工业园区云视信息技术有限公司 Sip音视频会议中进行音视频媒体传输的方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100353720C (zh) * 2004-08-20 2007-12-05 华为技术有限公司 实现媒体流旁路的方法
CN1848885B (zh) * 2005-04-13 2010-04-28 华为技术有限公司 通信系统中的呼叫代答方法
CN100459634C (zh) * 2005-11-09 2009-02-04 华为技术有限公司 通话的实现方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JP特开2004-240906A 2004.08.26

Also Published As

Publication number Publication date
CN101247386A (zh) 2008-08-20
WO2008101443A1 (fr) 2008-08-28

Similar Documents

Publication Publication Date Title
US11108838B2 (en) Method, user equipment and application server for adding media stream of multimedia session
CN101855890B (zh) 在ims中合并通信会话的方法、设备和程序产品
CN101313550A (zh) 实现多媒体通信的方法和设备
US20030095510A1 (en) Use and management of groups defined according to a call initiation protocol
EP2173068A1 (en) Method, application server and user device for transferring the media flow of the multimedia session
KR20070102578A (ko) 범용 이동 통신 시스템의 멀티미디어 기능 장치 사이에서통신 정보를 감소시키기 위한 시스템 및 방법
JP2008523662A (ja) 画像ベースのプッシュ・ツー・トークのユーザインタフェース向き画像交換方法
CN101257435B (zh) 基于nat-pt的sip应用层网关的实现方法
CN101459735B (zh) 一种彩铃、彩像业务的实现方法及系统
CN102342076A (zh) 通信网络中的能力查询处理
CN101123523B (zh) 一种创建多种媒体类型组合会议的方法
CN101511072A (zh) 一种sip或ims网络中实现增强型一号通业务的方法
CN101369906B (zh) 一种会议业务实现方法及设备
US20080208993A1 (en) Method For Distributing New Services in an Internet Multimedia Subsystem (Ims), and a Node Adapted Therefore
CN101247386B (zh) 媒体流获取方法及其系统、装置
CN101374138B (zh) 一种在sip协议中请求业务修改的方法、网络系统及装置
CN103828322B (zh) 媒体数据传输方法及设备
CN102668494B (zh) 在属于第一用户的终端与属于第二用户的至少一个终端之间的数据交换会话的监视
CN101552721B (zh) 一种融合业务系统及其业务实现方法
CN101459734B (zh) 一种在线播放彩铃彩像的实现方法
CN101459665A (zh) 早媒体信息播放控制方法
CN101448011A (zh) 早媒体信息播放选择方法
CN100571149C (zh) 一种基于会话发起协议更新会议媒体类型的实现方法
CN101047718B (zh) 实现媒体协商的系统、方法及服务器
CN101742005A (zh) 一种实现会议分割业务的方法、系统和网络装置

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
C17 Cessation of patent right
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20110511

Termination date: 20120216