CN102195926A - 一种媒体处理方法及相关设备 - Google Patents

一种媒体处理方法及相关设备 Download PDF

Info

Publication number
CN102195926A
CN102195926A CN2010101165732A CN201010116573A CN102195926A CN 102195926 A CN102195926 A CN 102195926A CN 2010101165732 A CN2010101165732 A CN 2010101165732A CN 201010116573 A CN201010116573 A CN 201010116573A CN 102195926 A CN102195926 A CN 102195926A
Authority
CN
China
Prior art keywords
medium
control end
request
message
control
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN2010101165732A
Other languages
English (en)
Other versions
CN102195926B (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 Device Co Ltd
Huawei Device Shenzhen Co Ltd
Original Assignee
Huawei Device 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 Device Co Ltd filed Critical Huawei Device Co Ltd
Priority to CN201010116573.2A priority Critical patent/CN102195926B/zh
Publication of CN102195926A publication Critical patent/CN102195926A/zh
Application granted granted Critical
Publication of CN102195926B publication Critical patent/CN102195926B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Mobile Radio Communication Systems (AREA)

Abstract

本发明实施例公开了一种媒体处理方法及相关设备,本发明实施例方法包括:接收第一媒体处理请求;向各控制端UE发送第一媒体处理请求;接收第一控制端UE针对第一媒体处理请求反馈的第二媒体处理请求,第二媒体处理请求指示媒体在第二控制端UE中进行传输;当第二控制端UE同意在自身传输媒体时,向第一控制端UE发送第一通知消息以指示媒体处理成功,当第二控制端UE不同意在自身传输媒体时,向第一控制端UE发送第二通知消息以指示媒体处理失败。本发明实施例还提供一种应用服务器。本发明实施例可以有效提高系统性能以及用户体验。

Description

一种媒体处理方法及相关设备
技术领域
本发明涉及通信领域,尤其涉及一种媒体处理方法及相关设备。
背景技术
互联网协议多媒体子系统(IMS,IP Multimedia Subsystem)是基于互联网协议(IP,Internet Protocol)的多媒体流业务通信网络,它被认为是支持语音、视频、数据等多种媒体流及其组合业务,实现多种网络(例如移动与固定网络,PS与CS网络等)融合的下一代通信网络的核心技术。
在IMS网络中,当本端用户与对端用户在进行通话时,本端用户可以选择不同的媒体流在不同的用户设备(UE,User Equipment)上传输,例如语音媒体流在固定电话上传输,数据媒体流在电脑上传输;并且,本端用户可以有多个UE同时对这些媒体流进行控制。
本端用户的每个UE与业务集中和会话连续性应用服务器(SCC AS,Service Centralization&Continuity Application Server)有一个会话,多个终端与SCC AS间的多个会话合在一起成为一个联合会话。
具有联合会话的控制权的UE称为控制端UE(Controller UE),控制端UE可以对联合会话中的所有媒体流进行控制,这里的控制包括对联合会话内的任何媒体流进行转移,删除,增加,进行补充业务操作等。
在现有技术中,当联合会话内同时存在多个控制端UE时,各控制端UE在联合会话内的地位是相同的,都可以控制联合会话内的任何媒体。并且按照先到先处理的原则进行操作。
现有技术中一种媒体处理方法具体如下:
假设UE1和UE2均为联合会话中的控制端UE,当对端用户通过re-Invite消息发起媒体增加的请求时,SCC AS通过re-Invite消息同时向UE1以及UE2发起媒体增加请求;
如果UE1对该媒体增加的请求的处理消息先于UE2的处理消息到达SCCAS,例如,UE1发出将媒体转移(transfer)到UE2的请求;
由于UE1的处理消息先到达SCC AS,则SCC AS向UE2发出取消请求,可以为:SCC AS向UE2发送Cancel消息。如果UE2已通过refer发出将媒体转移给其他UE的请求,则SCC AS需要通过4xx消息拒绝该refer消息。如果UE2已发出200OK确认消息,则SCC AS首先向UE2回复ACK消息,再向UE2发送删除媒体的请求消息。
当SCC AS向UE2发出取消请求之后,SCC AS再次向UE2发送媒体增加请求,以请求UE2增加媒体,UE2则根据该媒体增加请求执行后续操作。
在上述现有技术的过程中,若UE1的处理消息首先到达SCC AS,且UE1请求将媒体转移至UE2,则UE2至少会收到一个取消请求以及两个内容完全相同的媒体增加请求,这样会增加网络数据传输的负担,影响系统性能;
其次,对于UE2来说,UE2在第一次接收到SCC AS发送的媒体增加请求之后可能就已经进行了处理操作,例如接受该媒体增加请求或拒绝该媒体增加,但是由于UE2的处理消息后到达SCC AS,因此UE2的本次操作会被认为无效,并且还需要再次进行一遍相同的处理,即对相同的操作处理两次,增加了操作时长,从而影响了用户体验。
发明内容
本发明实施例提供了一种媒体处理方法及相关设备,能够提高系统性能并提高用户体验。
本发明实施例提供的媒体处理方法,包括:接收第一媒体处理请求;向各控制端用户设备UE发送所述第一媒体处理请求,所述各控制端UE至少包括第一控制端UE以及第二控制端UE;接收第一控制端UE针对所述第一媒体处理请求反馈的第二媒体处理请求,所述第二媒体处理请求指示媒体在第二控制端UE中进行传输;若接收第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求,当所述第二控制端UE同意在自身传输所述媒体时,向所述第一控制端UE发送第一通知消息以指示媒体处理成功,当所述第二控制端UE不同意在自身传输所述媒体时,向所述第一控制端UE发送第二通知消息以指示媒体处理失败。
本发明实施例提供的应用服务器,包括:请求接收单元,用于接收第一媒体处理请求;请求发送单元,用于向各控制端用户设备UE发送所述第一媒体处理请求,所述各控制端UE至少包括第一控制端UE以及第二控制端UE;应答接收单元,用于接收第一控制端UE针对所述第一媒体处理请求反馈的第二媒体处理请求,所述第二媒体处理请求指示媒体在第二控制端UE中进行传输;通知单元,用于在应答接收单元接收第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求时,若所述第二控制端UE同意在自身传输所述媒体,则向所述第一控制端UE发送第一通知消息以指示媒体处理成功,若所述第二控制端UE不同意在自身传输所述媒体,则向所述第一控制端UE发送第二通知消息以指示媒体处理失败。
从以上技术方案可以看出,本发明实施例具有以下优点:
本实施例中,AS向各控制端UE发送第一媒体处理请求之后,若第一控制端UE的针对第一媒体处理请求反馈的第二媒体处理请求先到达AS,且要求媒体在第二控制端UE进行传输时,则AS会等待第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求,并判断第二控制端UE是否接受该媒体在其自身传输,若第二控制端UE接受了媒体在其自身传输,则AS会直接向第一控制端UE发送第一通知消息以指示媒体处理成功,若第二控制端UE不接受在其自身传输,则AS直接向第一控制端UE发送第二通知消息以指示媒体处理失败,因此,AS无需向第二控制端UE重复发送相同内容的媒体处理请求,从而可以减少网络数据传输量,提高系统性能;
其次,由于AS不会向第二控制端UE发送两次相同内容的媒体处理请求,因此,第二控制端UE所执行的操作为有效操作,不会重复执行相同的处理,因此减少了操作时长,增加了用户体验。
附图说明
图1为本发明实施例中媒体处理方法一个实施例示意图;
图2为本发明实施例中媒体处理方法另一实施例示意图;
图3为本发明实施例中媒体处理方法另一实施例示意图;
图4为本发明实施例中媒体处理方法另一实施例示意图;
图5为本发明实施例中媒体处理方法另一实施例示意图;
图6为本发明实施例中应用服务器一个实施例示意图;
图7为本发明实施例中应用服务器另一实施例示意图;
图8为本发明实施例中控制端用户设备一个实施例示意图;
图9为本发明实施例中媒体处理系统实施例示意图。
具体实施方式
本发明实施例提供了一种媒体处理方法及媒体处理系统以及相关设备,能够提高系统性能并提高用户体验。
请参阅图1,本发明实施例中媒体处理方法一个实施例包括:
101、接收第一媒体处理请求;
本实施例中,AS可以从对端用户接收第一媒体处理请求,例如对端用户请求增加媒体的请求;或从本端受控端用户设备(Controllee UE)接收第一媒体处理请求,例如本端受控端用户设备请求删除自身媒体的请求,该第一媒体处理请求中包含有对应的媒体。
需要说明的是,本实施例中的AS在实际应用中可以为SCC AS,也可以为其他类型的AS,具体类型此处不作限定。
102、向各控制端用户设备UE发送第一媒体处理请求;
AS在接收到第一媒体处理请求之后,会向与对端用户正在进行会话的本端用户的各控制端UE发送媒体第一处理请求。
本端用户的控制端UE至少包括第一控制端UE以及第二控制端UE,还可以进一步包括更多的控制端UE。
103、接收第一控制端UE针对第一媒体处理请求反馈的第二媒体处理请求;
各控制端UE在接收到媒体处理请求之后,会向AS反馈媒体处理请求,由于传输路径和网络状况的不同,各控制端UE反馈的媒体处理请求可能会先后到达AS。
本实施例中,假设AS会最先收到第一控制端UE反馈的第二媒体处理请求,例如,将该媒体转移到第二控制端UE中传输。
如果2个以上控制端UE发出的媒体处理请求同时到达AS,则AS可以根据用户的偏好和运营商策略仅选择一个控制端UE的处理请求进行处理。
104、判断是否接收到第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求,若是,则执行步骤105,若否,则执行步骤107;
本实施例中,AS在接收到第一控制端UE反馈的第二媒体处理请求之后,等待第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求。
105、判断第二控制端UE是否同意在自身传输媒体,若同意,则执行步骤106,若不同意,则执行步骤107;
当收到第二控制端UE的第三媒体处理请求后,可以根据第三媒体处理请求判断第二控制端UE是否同意在自身传输媒体,例如,当第二控制端UE接受了媒体在其自身传输,则认为同意,当第二控制端UE拒绝媒体在其自身传输或将发起媒体转移到其他UE的请求时,则认为不同意。
106、向第一控制端UE发送第一通知消息以指示媒体处理成功;
若第二控制端UE的第三媒体处理请求是同意在自身传输媒体,则AS可以向第一控制端UE发送第一通知消息以指示媒体处理成功,不再进行后续的媒体转移处理过程,之后第一控制端UE向AS返回确认消息,AS再向对端用户发送确认消息,则媒体处理过程完成。
如果存在第一、第二控制端UE外的其他控制端UE,AS在收到第二媒体处理请求后,需要向其他控制端UE发送取消消息。
107、向第一控制端UE发送第二通知消息以指示媒体处理失败。
若第二控制端UE的第三媒体处理请求是不同意在自身传输该媒体,则AS向第一控制端UE发送第二通知消息以指示第一控制端UE第二媒体处理请求失败。此时第一控制端UE可以选择将媒体在自身传输、转移到其他UE或拒绝该媒体等操作。
需要说明的是,若在预置时间内未收到第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求,则认为第二控制端UE不同意媒体在自身进行传输,则同样执行步骤107。
如果存在第一、第二控制端UE外的其他控制端UE,AS在收到第二媒体处理请求后,需要向其他控制端UE发送取消消息。如果AS未收到第三媒体处理请求,则AS也需要向第二控制端UE发送取消消息。
本实施例中,AS向各控制端UE发送第一媒体处理请求之后,若第一控制端UE的针对第一媒体处理请求反馈的第二媒体处理请求先到达AS,且要求媒体在第二控制端UE进行传输时,则AS会等待第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求,并判断第二控制端UE是否接受该媒体在其自身传输,若第二控制端UE接受了媒体在其自身传输,则AS会直接向第一控制端UE发送第一通知消息以指示媒体处理成功,若第二控制端UE不接受在其自身传输,则AS直接向第一控制端UE发送第二通知消息以指示媒体处理失败,因此,AS无需向第二控制端UE重复发送相同内容的媒体处理请求,从而可以减少网络数据传输量,提高系统性能;
其次,由于AS不会向第二控制端UE发送两次相同内容的媒体处理请求,因此,第二控制端UE所执行的操作为有效操作,不会重复执行相同的处理,因此减少了操作时长,增加了用户体验。
为便于理解,下面以两个具体实例对本实施例中的媒体处理方法进行说明:
一、第二控制端UE同意在自身传输媒体:
具体请参阅图2,本发明实施例中媒体处理方法另一实施例包括:
201、第一控制端UE与对端用户传输媒体A;
202、第二控制端UE与对端用户传输媒体B;
203~204、第一控制端UE向第二控制端UE共享控制权;
205、对端用户通过re-Invite消息向SCC AS1发送第一媒体处理请求;
本实施例中,以媒体增加请求作为媒体处理请求的例子进行说明,在实际应用中,该媒体处理请求还可以是其他的请求,例如媒体修改请求等,具体此处不作限定。
206、SCC AS1采用re-Invite消息向第一控制端UE发送第一媒体处理请求;
207~208、SCC AS1通过SCC AS2采用re-Invite消息向第二控制端UE发送第一媒体处理请求;
需要说明的是,本实施例中,步骤206与207为同时执行的步骤,没有先后顺序。
209、SCC AS1接收第一控制端UE的第二媒体处理请求;
本实施例中,假设第一控制端UE针对该第一媒体处理请求的第二媒体处理请求消息比第二控制端UE的第三媒体处理请求消息先到达SCC AS1。
第一控制端UE的第二媒体处理请求消息可以指示媒体在第二控制端UE中进行传输。
210、SCC AS1等待第二控制端UE的第三媒体处理请求消息;
SCC AS1在接收到第一控制端UE发送的第二媒体处理请求消息之后,获知第一控制端UE指示第二控制端UE传输媒体,则SCC AS1等待第二控制端UE的第三媒体处理请求消息。
211~212、第二控制端UE通过SCC AS2向SCC AS1发送200OK消息;
当第二控制端UE在步骤208中接收到SCC AS1发送的第一媒体处理请求之后,若第二控制端UE确定由自身来传输该媒体,则会通过SCC AS2向SCC AS1发送200OK消息。
213、SCC AS1向第一控制端UE发送第一通知消息;
当SCC AS1接收到第二控制端UE反馈的第三媒体处理请求消息为200OK消息时,则确定第二控制端UE同意自身传输媒体,而第一控制端UE发送的应答消息正是要求第二控制端UE传输媒体,则SCC AS1直接向第一控制端UE发送第一通知消息,以告知操作成功,不需要再进行后续的媒体转移处理过程。
214~215、第一控制端UE通过SCC AS1向对端用户发送200OK消息。
需要说明的是,若本端用户有三个或以上的控制端UE,即除了第一控制端UE以及第二控制端UE之外,还有其他的控制端UE,则SCC AS1还会在步骤206或207的同时向其他的控制端UE发送第一媒体处理请求,并且SCCAS1在步骤209之后会向除第一控制端UE以及第二控制端UE之外的其他控制端UE发送取消消息以取消发送至这些控制端UE的媒体处理请求。
本实施例中描述的SCC AS1与SCC AS2在实际应用中可以为同一个物理实体,则SCC AS1与SCC AS2之间的交互为网元内部交互,可以理解的是,SCC AS1与SCC AS2也可以为不同的物理实体,则SCC AS1与SCC AS2之间的交互为网元间交互。
本实施例中,步骤209时,SCC AS1会先接收到第一控制端UE反馈的第二媒体处理请求消息,在实际应用中,SCC AS1若同时接收到两个控制端UE反馈的媒体处理请求消息,则SCC AS1可以根据用户的偏好或运营商策略选择其中的一个媒体处理请求消息作为最先收到的媒体处理请求消息,则后续处理与上述处理过程相同。
二、第二控制端UE不同意在自身传输媒体:
具体请参阅图3,本发明实施例中媒体处理方法另一实施例包括:
301~310、与前述图2所示实施例中的步骤201至210相同,此处不再赘述;
311~312、第二控制端UE通过SCC AS2向SCC AS1发送第三媒体处理请求;
当第二控制端UE在步骤308中接收到SCC AS1发送的第一媒体处理请求之后,可以通过SCC AS2向SCC AS1发送第三媒体处理请求。
这里的第三媒体处理请求可以是媒体转移消息或拒绝传输消息(例如4xx消息)。若第二控制端UE发送的第三媒体处理请求是媒体转移请求,则SCCAS1还需要进一步向第二控制端UE发送拒绝消息,该拒绝消息的call-info消息头中指明拒绝的原因,例如可以为“禁止转移”等。
需要说明的是,在实际应用中,第二控制端UE也可能不反馈任何应答消息,即不执行步骤311~312,则在这种情况下,SCC AS1向第二控制端UE发送了第一媒体处理请求之后,即启动定时器,当该定时器超过预置的时长仍未收到第二控制端UE反馈的应答消息时,则默认认为第二控制端UE不同意在自身传输媒体,则SCC AS1需要向第二控制端UE发送取消消息。
313、SCC AS1向第一控制端UE发送第二通知消息;
当SCC AS1确定第二控制端UE不同意在自身传输媒体时,则SCC AS1向第一控制端UE发送第二通知消息以指示第一控制端UE拒绝媒体处理请求。
314、第一控制端UE进行相应处理;
第一控制端UE接收到SCC AS1发送的第二通知消息之后,则进行相应的处理,可以拒绝媒体处理请求,或安排其他控制端UE传输媒体,具体处理过程此处不作限定。
315、SCC AS1向第二控制端UE提供当前联合会话的状态信息。
本实施例中,SCC AS1具体可以通过通知(Notify)消息或re-Invite消息向第二控制端UE提供当前联合会话的状态,具体的消息体可以为:
<?xml version=″1.0″?>
<collaborative-session                 xmlns=″urn:ietf:params:xml:ns:
collaborative-session″>
<media-description media_type=″Media-A″
port=″6787″
aor=″sip:UE-1@example.com″
media_state=″sendrecv″
/>
<media-description media_type=″Media-B″
port=″6788″
aor=″sip:UE-2@example.com″
media_state=″sendrecv″
/>
</collaborative-session>
该联合会话的状态用以表明当前传输的媒体有哪些媒体类型,各媒体所在的UE,所使用的端口,以及媒体状态等信息。
需要说明的是,若本端用户有三个或以上的控制端UE,即除了第一控制端UE以及第二控制端UE之外,还有其他的控制端UE,则SCC AS1还会在步骤306或307的同时向其他的控制端UE发送第一媒体处理请求,并且SCCAS1在步骤309之后会向除第一控制端UE以及第二控制端UE之外的其他控制端UE发送取消消息以取消发送至这些控制端UE的媒体处理请求。
本实施例中描述的SCC AS1与SCC AS2在实际应用中可以为同一个物理实体,则SCC AS1与SCC AS2之间的交互为网元内部交互,可以理解的是,SCC AS1与SCC AS2也可以为不同的物理实体,则SCC AS1与SCC AS2之间的交互为网元间交互。
本实施例中,步骤309时,SCC AS1会先接收到第一控制端UE发送的第二媒体处理请求,在实际应用中,SCC AS1若同时接收到两个控制端UE反馈的媒体处理请求,则SCC AS1可以根据用户的偏好或运营商策略选择其中的一个媒体处理请求作为最先收到的应答消息,则后续处理与上述处理过程相同。
本实施例中,AS向各控制端UE发送第一媒体处理请求之后,若第一控制端UE的针对第一媒体处理请求反馈的第二媒体处理请求先到达AS,且要求媒体在第二控制端UE进行传输时,则AS会等待第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求,并判断第二控制端UE是否接受该媒体在其自身传输,若第二控制端UE接受了媒体处理在其自身传输,则AS会直接向第一控制端UE发送第一通知消息以指示媒体处理成功,若第二控制端UE不接受在其自身传输,则AS直接发送向第一控制端UE发送第二通知消息以指示媒体处理失败,因此,AS无需向第二控制端UE重复发送相同内容的媒体处理请求,从而可以减少网络数据传输量,提高系统性能;
其次,由于AS不会向第二控制端UE发送两次相同内容的媒体处理请求,因此,第二控制端UE所执行的操作为有效操作,不会重复执行相同的处理,因此减少了操作时长,增加了用户体验。
下面介绍本发明实施例中另一种媒体处理方法,请参阅图4,本发明实施例中媒体处理方法另一实施例包括:
401、接收第一控制端UE发送的控制权共享请求;
本实施例中,在执行联合会话的控制权共享过程中,AS会接收到第一控制端UE发送的控制权共享请求,该控制权共享请求指示将控制权共享给第二控制端UE,该控制权共享请求中包含第一控制端UE以及第二控制端UE的优先级信息。
402、当接收到媒体处理请求时,仅向优先级最高的控制端UE发送媒体处理请求。
AS接收到第一控制端UE发送的控制权共享请求之后,会记录第一控制端UE的优先级以及第二控制端UE的优先级。
当从对端用户接收到媒体处理请求时,AS仅会向优先级最高的控制端UE发送媒体处理请求。
本实施例中,由于第一控制端UE发送的控制权共享请求中指示将控制权共享给第二控制端UE,该控制权共享请求中包含第一控制端UE以及第二控制端UE的优先级信息,因此AS在接收到媒体处理请求时,会按照该优先级,仅向优先级最高的控制端UE发送媒体处理请求,由于只会有一个控制端UE接收到媒体处理请求,则可以避免多个控制端UE同时接收到媒体处理请求时所导致的操作冲突,因此可以避免第二控制端UE多次接收到媒体处理请求,从而可以减少网络数据传输量,提高系统性能;
其次,由于AS不会向第二控制端UE发送两次相同内容的媒体处理请求,因此,第二控制端UE所执行的操作为有效操作,不会重复执行相同的处理,因此减少了操作时长,增加了用户体验。
上面是从AS的角度进行描述,下面从第一控制端UE的角度进行描述,大致流程为:
(1)第一控制端UE确定需要共享控制权的第二控制端UE;
第一控制端UE可以根据本端用户的指令将控制权共享给第二控制端UE,具体的确定过程此处不作限定。
(2)第一控制端UE生成第一控制端UE以及第二控制端UE的优先级;
在确定了第二控制端UE之后,第一控制端UE即可生成优先级。
(3)第一控制端UE向应用服务器发送控制权共享请求。
本实施例中,该控制权共享请求指示将控制权共享给第二控制端UE,该控制权共享请求中包含第一控制端UE以及第二控制端UE的优先级信息,之后AS即可根据该优先级发送媒体处理请求。
为便于理解,下面以一具体实例进行说明,请参阅图5,本发明实施例中媒体处理方法另一实施例包括:
501、第一控制端UE与对端用户传输媒体A;
502、第二控制端UE与对端用户传输媒体B;
503~504、第一控制端UE向第二控制端UE共享控制权;
第一控制端UE发起将联合会话控制权共享给第二控制端UE的请求,在请求中可以包括如下信息:
共享联合会话控制权的指示;
控制权共享的发起方为第一控制端UE的指示;
控制权共享的目标方为第二控制端UE的指示;
第一控制端UE和/或第二控制端UE在联合会话中控制权的优先级的指示;可以是第一控制端UE为主控制端(master)、第一控制端UE为辅控制端(slave)的指示,或第一控制端UE的优先级为高,第一控制端UE的优先级为低的指示。
505、SCC AS1执行校验过程;
SCC AS1在接收到第一控制端UE发送的控制权共享请求之后,会判断第一控制端UE是否可以将控制权共享给第二控制端UE,具体的校验过程此处不作限定。
506、SCC AS1建立联合会话控制路径;
若SCC AS1确定第一控制端UE可以将控制端共享给第二控制端UE,则SCC AS1通过SCC AS2与第二控制端UE建立会话控制路径,即用于控制联合会话的接入分支,并向第二控制端UE告知其优先级。
507、对端用户通过re-Invite消息向SCC AS1发送媒体增加请求;
本实施例中,以媒体增加请求作为媒体处理请求的例子进行说明,在实际应用中,该媒体处理请求还可以是其他的请求,例如媒体修改请求等,具体此处不作限定。
508、SCC AS1采用re-Invite消息向第一控制端UE发送媒体增加请求;
当SCC AS1接收到媒体增加请求时,会根据优先级确定第一控制端UE的优先级高于第二控制端UE的优先级,则向第一控制端UE发送媒体增加请求。
需要说明的是,若第一控制端UE向多个控制端UE共享了控制权,则这些控制端UE的优先级也均低于第一控制端UE,则SCC AS1会向优先级最高的第一控制端UE发送媒体增加请求。
509、第一控制端UE执行后续的处理过程。
需要说明的是,若SCC AS1在步骤508之后的预置时长之内未能收到第一控制端UE反馈的应答消息,则SCC AS1可以认为第一控制端UE失效,则此时SCC AS1可以按照优先级顺序向优先级次高的控制端UE发送媒体增加请求,以此类推,每次只发送一个媒体增加请求。
本实施例中,由于第一控制端UE发送的控制权共享请求中指示将控制权共享给第二控制端UE,该控制权共享请求中包含第一控制端UE以及第二控制端UE的优先级信息,因此AS在接收到媒体处理请求时,会按照该优先级,仅向优先级最高的控制端UE发送媒体处理请求,由于只会有一个控制端UE接收到媒体处理请求,则可以避免多个控制端UE同时接收到媒体处理请求时所导致的操作冲突,因此可以避免第二控制端UE多次接收到媒体处理请求,从而可以减少网络数据传输量,提高系统性能;
其次,由于AS不会向第二控制端UE发送两次相同内容的媒体处理请求,因此,第二控制端UE所执行的操作为有效操作,不会重复执行相同的处理,因此减少了操作时长,增加了用户体验。
下面对本发明实施例中的应用服务器进行说明,请参阅图6,本发明实施例中应用服务器一个实施例包括:
请求接收单元601,用于接收第一媒体处理请求;
请求发送单元602,用于向各控制端用户设备UE发送第一媒体处理请求,各控制端UE至少包括第一控制端UE以及第二控制端UE;
应答接收单元603,用于接收第一控制端UE针对第一媒体处理请求反馈的第二媒体处理请求,第二媒体处理请求指示媒体在第二控制端UE中进行传输;
通知单元604,用于在应答接收单元接收第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求时,若第二控制端UE同意在自身传输媒体,则向第一控制端UE发送第一通知消息以指示媒体处理成功,若第二控制端UE不同意在自身传输媒体,则向第一控制端UE发送第二通知消息以指示媒体处理失败。
需要说明的是,若本实施例中除了第一控制端UE以及第二控制端UE之外,还包括有其他的控制端UE,则本实施例中的应用服务器还可以进一步包括:
取消单元605,用于向除第一控制端UE以及第二控制端UE之外的其他控制端UE发送取消消息以取消发送给其他控制端UE的媒体处理请求。
本实施例中的应用服务器还可以进一步包括:
确定单元606,用于当第三媒体处理请求为200OK消息时确定第二控制端UE同意在自身传输媒体,当第三媒体处理请求为媒体转移消息或拒绝传输消息时确定第二控制端UE不同意在自身传输媒体,当应答接收单元在预置的时长内未接收到第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求时确定第二控制端UE不同意在自身传输媒体。
需要说明的是,本实施例中的确定单元606具体确定第二控制端UE是否同意在自身传输媒体的过程与前述图2以及图3所示的实施例中描述的过程类似,此处不再赘述。
本实施例中,请求发送单元602向各控制端UE发送第一媒体处理请求之后,若第一控制端UE的针对第一媒体处理请求反馈的第二媒体处理请求先到达AS,且要求媒体在第二控制端UE进行传输时,则AS会等待第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求,并判断第二控制端UE是否接受该媒体在其自身传输,若第二控制端UE接受了媒体在其自身传输,则通知单元604会直接向第一控制端UE发送第一通知消息以指示媒体处理成功,若第二控制端UE不接受在其自身传输,则通知单元604直接向第一控制端UE发送第二通知消息以指示媒体处理失败,因此,AS无需向第二控制端UE重复发送相同内容的媒体处理请求,从而可以减少网络数据传输量,提高系统性能;
其次,由于AS不会向第二控制端UE发送两次相同内容的媒体处理请求,因此,第二控制端UE所执行的操作为有效操作,不会重复执行相同的处理,因此减少了操作时长,增加了用户体验。
请参阅图7,本发明实施例中应用服务器另一实施例包括:
共享请求接收单元701,用于接收第一控制端UE发送的控制权共享请求,控制权共享请求指示将控制权共享给第二控制端UE,控制权共享请求包含第一控制端UE以及第二控制端UE的优先级信息;
处理请求接收单元702,用于接收媒体处理请求;
第一发送单元703,用于仅向优先级最高的控制端UE发送媒体处理请求。
本实施例中的应用服务器还可以进一步包括:
控制建立单元704,用于判断是否允许将控制权共享给第二控制端UE,若允许,则为第二控制端UE建立用于控制联合会话的接入分支,并向第二控制端UE告知其优先级。
本实施例中的应用服务器还可以进一步包括:
第二发送单元705,用于向下一优先级较低的控制端UE发送媒体处理请求;
控制单元706,用于判断在预置时长内是否收到优先级最高的控制端UE反馈的应答消息,若未收到,则触发第二发送单元执行相应操作。
本实施例中,由于第一控制端UE发送的控制权共享请求中指示将控制权共享给第二控制端UE,控制权共享请求包含第一控制端UE以及第二控制端UE的优先级信息,因此处理请求接收单元702在接收到媒体处理请求时,第一发送单元703会按照该优先级,仅向优先级最高的控制端UE发送媒体处理请求,由于只会有一个控制端UE接收到媒体处理请求,则可以避免多个控制端UE同时接收到媒体处理请求时所导致的操作冲突,因此可以避免第二控制端UE多次接收到媒体处理请求,从而可以减少网络数据传输量,提高系统性能;
其次,由于第一发送单元703不会向第二控制端UE发送两次相同内容的媒体处理请求,因此,第二控制端UE所执行的操作为有效操作,不会重复执行相同的处理,因此减少了操作时长,增加了用户体验。
下面介绍本发明实施例中的控制端用户设备实施例,请参阅图8,本发明实施例中的控制端用户设备包括:
控制权确定单元801,用于确定需要共享控制权的第二控制端UE;
生成单元802,用于生成自身以及第二控制端UE的优先级;
共享请求发送单元803,用于向应用服务器发送控制权共享请求,控制权共享请求指示将控制权共享给第二控制端UE,该控制权共享请求包含第一控制端UE以及第二控制端UE的优先级信息。
本实施例中,由于共享请求发送单元803发送的控制权共享请求中指示将控制权共享给第二控制端UE,该控制权共享请求包含第一控制端UE以及第二控制端UE的优先级信息,因此AS在接收到媒体处理请求时,会按照该优先级,仅向优先级最高的控制端UE发送媒体处理请求,由于只会有一个控制端UE接收到媒体处理请求,则可以避免多个控制端UE同时接收到媒体处理请求时所导致的操作冲突,因此可以避免第二控制端UE多次接收到媒体处理请求,从而可以减少网络数据传输量,提高系统性能。
下面介绍本发明实施例中的媒体处理系统实施例,请参阅图9,本发明实施例中的媒体处理系统包括:
第一控制端用户设备901,第二控制端用户设备902以及应用服务器903;
需要说明的是,本实施例中的媒体处理系统可以分为两种情况:
在一种情况中,该第一控制端用户设备901与第二控制端用户设备902可以为本领域技术人员的公知常识,而应用服务器903可以为如图6所示实施例中的应用服务器,具体的单元功能以及单元间的联系均与图6所示实施例中描述的内容相同,此处不再赘述。
在另一种情况中,该第二控制端用户设备902可以为本领域技术人员的公知常识,而应用服务器903可以为如图7所示实施例中的应用服务器,具体的单元功能以及单元间的联系均与图7所示实施例中描述的内容相同,第一控制端用户设备901可以为如图8所示实施例中的控制端用户设备,具体的单元功能以及单元间的联系均与图8所示实施例中描述的内容相同,此处不再赘述。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成,该程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上对本发明所提供的一种媒体处理方法及媒体处理系统以及相关设备进行了详细介绍,对于本领域的一般技术人员,依据本发明实施例的思想,在具体实施方式及应用范围上均会有改变之处,因此,本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种媒体处理方法,其特征在于,包括:
接收第一媒体处理请求;
向各控制端用户设备UE发送所述第一媒体处理请求,所述各控制端UE至少包括第一控制端UE以及第二控制端UE;
接收第一控制端UE针对所述第一媒体处理请求反馈的第二媒体处理请求,所述第二媒体处理请求指示媒体在第二控制端UE中进行传输;
若接收第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求,当所述第二控制端UE同意在自身传输所述媒体时,向所述第一控制端UE发送第一通知消息以指示媒体处理成功,当所述第二控制端UE不同意在自身传输所述媒体时,向所述第一控制端UE发送第二通知消息以指示媒体处理失败。
2.根据权利要求1所述的方法,其特征在于,
若所述第三媒体处理请求为200OK消息,则确定第二控制端UE同意在自身传输所述媒体。
3.根据权利要求1所述的方法,其特征在于,
若所述第三媒体处理请求为媒体转移消息或拒绝传输消息,则确定第二控制端UE不同意在自身传输所述媒体。
4.根据权利要求1所述的方法,其特征在于,
若所述第三媒体处理请求为媒体转移消息,则收到所述媒体转移消息后,向所述第二控制端UE发送拒绝消息,在所述拒绝消息的call-info消息头中指明拒绝的原因。
5.根据权利要求1所述的方法,其特征在于,
若未接收第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求的,则确定第二控制端UE不同意在自身传输所述媒体。
6.根据权利要求3或5所述的方法,其特征在于,若所述第二控制端UE不同意在自身传输所述媒体信息,所述方法还包括:
向所述第二控制端UE提供当前联合会话的状态信息,所述当前联合会话的状态信息包括以下参数中的至少一种:联合会话内每个媒体的媒体类型、联合会话内每个媒体当前所在的UE标识、联合会话内每个媒体所使用的端口、联合会话内每个媒体的媒体状态。
7.根据权利要求1至4中任一项所述的方法,其特征在于,所述接收第一控制端UE针对所述第一媒体处理请求反馈的第二媒体处理请求之后包括:
向除第一控制端UE以及第二控制端UE之外的其他控制端UE发送取消消息以取消发送给所述其他控制端UE的媒体处理请求。
8.一种应用服务器,其特征在于,包括:
请求接收单元,用于接收第一媒体处理请求;
请求发送单元,用于向各控制端用户设备UE发送所述第一媒体处理请求,所述各控制端UE至少包括第一控制端UE以及第二控制端UE;
应答接收单元,用于接收第一控制端UE针对所述第一媒体处理请求反馈的第二媒体处理请求,所述第二媒体处理请求指示媒体在第二控制端UE中进行传输;
通知单元,用于在应答接收单元接收第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求时,若所述第二控制端UE同意在自身传输所述媒体,则向所述第一控制端UE发送第一通知消息以指示媒体处理成功,若所述第二控制端UE不同意在自身传输所述媒体,则向所述第一控制端UE发送第二通知消息以指示媒体处理失败。
9.根据权利要求8所述的应用服务器,其特征在于,所述应用服务器还包括:
确定单元,用于当所述第三媒体处理请求为200OK消息时确定第二控制端UE同意在自身传输所述媒体,当所述第三媒体处理请求为媒体转移消息或拒绝传输消息时确定第二控制端UE不同意在自身传输所述媒体,当应答接收单元在预置的时长内未接收到第二控制端UE针对第一媒体处理请求反馈的第三媒体处理请求时确定第二控制端UE不同意在自身传输所述媒体。
10.根据权利要求8或9所述的应用服务器,其特征在于,所述应用服务器还包括:
取消单元,用于向除第一控制端UE以及第二控制端UE之外的其他控制端UE发送取消消息以取消发送给所述其他控制端UE的媒体处理请求。
CN201010116573.2A 2010-03-01 2010-03-01 一种媒体处理方法及相关设备 Active CN102195926B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201010116573.2A CN102195926B (zh) 2010-03-01 2010-03-01 一种媒体处理方法及相关设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201010116573.2A CN102195926B (zh) 2010-03-01 2010-03-01 一种媒体处理方法及相关设备

Publications (2)

Publication Number Publication Date
CN102195926A true CN102195926A (zh) 2011-09-21
CN102195926B CN102195926B (zh) 2014-01-22

Family

ID=44603322

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201010116573.2A Active CN102195926B (zh) 2010-03-01 2010-03-01 一种媒体处理方法及相关设备

Country Status (1)

Country Link
CN (1) CN102195926B (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101383826A (zh) * 2008-10-07 2009-03-11 深圳华为通信技术有限公司 一种媒体流控制权转移的方法、装置及系统
CN101453402A (zh) * 2007-12-06 2009-06-10 华为技术有限公司 一种对媒体流控制的方法、系统及设备
US20090313378A1 (en) * 2008-08-06 2009-12-17 Futurewei Technologies, Inc. Remote Media IMS Sessions

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101453402A (zh) * 2007-12-06 2009-06-10 华为技术有限公司 一种对媒体流控制的方法、系统及设备
US20090313378A1 (en) * 2008-08-06 2009-12-17 Futurewei Technologies, Inc. Remote Media IMS Sessions
CN101383826A (zh) * 2008-10-07 2009-03-11 深圳华为通信技术有限公司 一种媒体流控制权转移的方法、装置及系统

Also Published As

Publication number Publication date
CN102195926B (zh) 2014-01-22

Similar Documents

Publication Publication Date Title
CN101364874B (zh) 一种媒体转移方法、终端及应用服务器
US8774178B2 (en) Call transfer with multiple application servers in session initiation protocol-based network
US8676888B2 (en) Method for multi-terminal session, and communication system and related device thereof
US7660850B2 (en) Supporting a serial and a parallel invitation protocol
CN101599924B (zh) 通信系统
CN101431737A (zh) 多媒体会话呼叫控制的方法及应用服务器
CN102067671A (zh) 在多分量通信会话中传递会话连续性信息
US20080225835A1 (en) Communication server
EP2182692A1 (en) A method, device and system for processing the continuity of the media stream in a session
EP2312806B1 (en) A media negotiation method for ip multimedia link
US20110231560A1 (en) User Equipment (UE) Session Notification in a Collaborative Communication Session
WO2010067090A1 (en) Communications system and method
CN1889565B (zh) 会话建立方法
US7882176B2 (en) Establishing a multiparty session by sending invitations in parallel
CN102348291B (zh) 基于对话关联标识的会话建立方法及系统
CN105072121B (zh) 一种ims终端自组网的方法及装置
EP2737679B1 (en) Method of operating a first communication device for receiving a media data stream from at least one second communication device, including a communication device, a telecommunications server and a telecommunications system
CN102195926B (zh) 一种媒体处理方法及相关设备
JP2011166453A (ja) SIP(SessionInitiationProtocol)中継装置、パケット変換装置、ネットワークシステム、制御方法及び制御プログラム
EP2566127B1 (en) Method and system for replacing replace parameter
CN101848194B (zh) 媒体转移方法和系统、服务器及用户设备
JP2010062692A (ja) Sipシグナリングにおけるコマンドシーケンス番号の制御方法、サーバ及びプログラム
JP6549523B2 (ja) 要求先端末のオプション機能の非使用を整合する網間制御方法、sipサーバ及びプログラム
CN117938815A (zh) 通信方法、设备及存储介质
CN116074769A (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
CP01 Change in the name or title of a patent holder

Address after: 518129 Building 2, B District, Bantian HUAWEI base, Longgang District, Shenzhen, Guangdong.

Patentee after: Huawei terminal (Shenzhen) Co.,Ltd.

Address before: 518129 Building 2, B District, Bantian HUAWEI base, Longgang District, Shenzhen, Guangdong.

Patentee before: HUAWEI DEVICE Co.,Ltd.

CP01 Change in the name or title of a patent holder
TR01 Transfer of patent right

Effective date of registration: 20181218

Address after: 523808 Southern Factory Building (Phase I) Project B2 Production Plant-5, New Town Avenue, Songshan Lake High-tech Industrial Development Zone, Dongguan City, Guangdong Province

Patentee after: HUAWEI DEVICE Co.,Ltd.

Address before: 518129 Building 2, B District, Bantian HUAWEI base, Longgang District, Shenzhen, Guangdong.

Patentee before: Huawei terminal (Shenzhen) Co.,Ltd.

TR01 Transfer of patent right