CN101383765B - 转移媒体流的方法、装置及通信系统 - Google Patents

Abstract

本发明实施例公开了转移媒体流的方法、装置及通信系统。在第一用户设备将媒体流转移给第二用户设备之后，第二用户设备将所述媒体流转移给第一用户设备，一种转移媒体流的方法，包括：接收第二用户设备发送的返还媒体流请求消息；根据所述返还媒体流请求消息，恢复所述媒体流在第一用户设备的收发。应用本发明实施例的技术方案，能够避免在第一用户设备中媒体流记录混乱。返还完成后，业务集中和会话连续性应用服务器SCC AS或第二用户设备可以将相关的媒体流转移关系记录删除，避免存储资源的浪费。

Description

转移媒体流的方法、装置及通信系统

技术领域

本发明涉及通信技术领域，特别是涉及转移媒体流的方法、装置及通信系统。

背景技术

IMS(IP Multimedia Subsystem，IP多媒体子系统)是基于IP(Internetprotocol，互联网协议)交换的业务网络，支持语音、视频、数据等多种业务，被认为是下一代通信网络的核心技术。UE(User Equipment，用户设备)可以通过分组交换接入网接入IMS网络进行多媒体业务。IMS的核心是CSCF(Call Session Control Function，呼叫会话控制功能)和各种AS(ApplicationServer，应用服务器)，S-CSCF(Serving-CSCF，服务CSCF)负责在满足条件时将呼叫请求路由到正确的AS，AS负责执行业务逻辑。

IMS中的SC(Service Continuity，业务连续性)课题，其目的是研究用户的媒体流在不同设备之间转移时，如何保证业务的连续性，即在不中断会话的情况下，实现用户媒体流在不同的用户设备间转移，具体包括：如何将当前UE中的媒体流转移给其他UE、如何从其他UE取回媒体流等。SC的核心功能实体是SCC AS(Service Centralization & Continuity Application Server，业务集中和会话连续性应用服务器)，用于完成不同用户设备间的切换。

现有技术中，可以实现将媒体流从UE-1(第一用户设备)转移给UE-2(第二用户设备)，这里称之为transfer流程；并且UE-1可以从UE-2将之前所转移的媒体流取回，这里称之为retrieve流程。如果UE-2需要主动将媒体流返还给UE-1，则仍然要采用transfer流程。

在实现本发明过程中，发明人发现以上现有技术中至少存在如下问题：

UE-1将媒体流转移给UE-2后，只是停止对相应媒体流进行收发，但是媒体流描述还是保留的；而UE-2采用transfer方式将媒体流返还给UE-1，对于UE-1来说相当于增加了新的媒体流，这样对于UE-1来说，同一个媒体流就会有两个不同的描述，造成媒体流记录混乱，并且浪费存储资源。

此外，对于transfer流程，转出媒体流的UE和SCC AS都会记录转移的相关信息。因此UE-2以transfer的方式将媒体流返还给UE-1后，UE-2会保留转移媒体流相关的信息，SCC AS也会同时保留UE-1将媒体流转移给UE-2的信息和UE-2将媒体流转移给UE-1的信息，这些信息都是没必要保留的，同样会造成存储资源浪费。

发明内容

有鉴于此，本发明实施例提供了转移媒体流的方法、装置及通信系统，以解决现有技术中所存在的返还媒体流之后媒体流记录混乱和存储资源浪费的问题，技术方案如下：

一种转移媒体流的方法，在第一用户设备将媒体流转移给第二用户设备之后，第二用户设备将所述媒体流转移给第一用户设备，所述转移媒体流的方法包括：

接收第二用户设备发送的返还媒体流请求消息；其中，所述第二用户设备，在接收对媒体流的转移请求、根据所述转移请求中携带的目标用户设备标识和所存储的转移关系记录，判断所述媒体流为所述目标用户设备转入的媒体流后，发送所述返还媒体流请求消息；

根据所述返还媒体流请求消息，向第一用户设备发送恢复媒体流请求消息，所述恢复媒体流请求消息用于指示第一用户设备恢复所述媒体流在第一用户设备的收发。

一种转移媒体流的方法，在第一用户设备将媒体流转移给第二用户设备之后，第二用户设备将所述媒体流转移给第一用户设备，所述转移媒体流的方法包括：

接收第二用户设备发送的转移媒体流请求消息；所述转移媒体流请求消息中携带所述媒体流的来源标识；

根据所述来源标识，判断所述媒体流是否为第一用户设备转移给第二用户设备的媒体流；

如果判断结果为是，则向第一用户设备发送恢复媒体流请求消息，所述恢复媒体流请求消息用于指示第一用户设备恢复所述媒体流在第一用户设备的收发。

一种转移媒体流的方法，包括：

接收对媒体流的转移请求；

根据所述转移请求中携带的目标用户设备标识，和所存储的转移关系记录，判断所述媒体流是否为所述目标用户设备转入的媒体流；

如果判断结果为是，则向所述目标设备发送返还媒体流请求消息。

一种转移媒体流的方法，包括：

接收第二用户设备发送的转移媒体流请求消息；所述转移媒体流请求消息中携带所述媒体流的来源标识；

根据所述来源标识，判断所述媒体流是否为自身转移给第二用户设备的媒体流；

如果判断结果为是，则向第二用户设备发起媒体流取回流程，恢复对所述媒体流的收发。

一种业务集中和会话连续性应用服务器，包括：

返还请求接收单元，用于接收第二用户设备发送的返还媒体流请求消息，所述媒体流为第一用户设备转移给第二用户设备的媒体流；其中，所述第二用户设备，在接收对媒体流的转移请求、根据所述转移请求中携带的目标用户设备标识和所存储的转移关系记录，判断所述媒体流为所述目标用户设备转入的媒体流后，发送所述返还媒体流请求消息；

恢复单元，用于根据所述返还请求接收单元所接收的返还媒体流请求消息，向第一用户设备发送恢复媒体流请求消息，所述恢复媒体流请求消息用于指示第一用户设备恢复所述媒体流在第一用户设备的收发。

一种业务集中和会话连续性应用服务器，包括：

转移请求接收单元，用于接收第二用户设备发送的转移媒体流请求消息，所述转移媒体流请求消息中携带所述媒体流的来源标识；

判断单元，用于根据所述转移请求接收单元接收的转移请求消息中携带的所述媒体流的来源标识，和所存储的转移关系记录，判断所述媒体流是否为第一用户设备转移给第二用户设备的媒体流；

恢复单元，如果所述判断单元的判断结果为是，则根据所述转移请求，向第一用户设备发送恢复媒体流请求消息，所述恢复媒体流请求消息用于指示第一用户设备恢复所述媒体流在第一用户设备的收发。

一种用户设备，包括：

转移请求接收单元，用于接收对媒体流的转移请求；

判断单元，用于根据所述转移请求接收单元接收的转移请求中携带的目标用户设备标识，和所存储的转移关系记录，判断所述媒体流是否为所述目标用户设备转入的媒体流；

返还请求发送单元，如果所述判断单元的判断结果为是，则向所述目标用户设备发送返还媒体流请求消息。

一种用户设备，包括：

转移请求接收单元，用于接收第二用户设备发送的对媒体流的转移请求；

判断单元，用于根据所述转移请求接收单元接收的转移请求中携带的所述媒体流的来源标识，判断所述媒体流是否为自身转移给第二用户设备的媒体流；

取回单元，如果所述判断单元的判断结果为是，则向第二用户设备发起媒体流取回流程，恢复对所述媒体流的收发。

一种通信系统，包括业务集中和会话连续性应用服务器、第一用户设备和第二用户设备；

所述第二用户设备，用于向所述业务集中和会话连续性应用服务器发送媒体流转移请求；

所述业务集中和会话连续性应用服务器，用于接收所述第二用户设备发送的对媒体流的转移请求；根据所述转移请求中携带的所述媒体流的来源标识、转移的目标设备标识，和所存储的转移关系记录，判断所述媒体流是否为第一用户设备转移给第二用户设备的媒体流；如果是，则恢复所述媒体流在第一用户设备的收发；

所述第一用户设备，用于接收所述业务集中和会话连续性应用服务器所恢复的媒体流。

以上技术方案，可以实现第二用户设备主动将媒体流返还给第一用户设备，与现有技术中通过transfer流程返还媒体流的方法相比，由于先行确认了媒体流是由第一用户设备转给第二用户设备的，因此可以根据确认的结果，由第一用户设备将之前转出的媒体流取回，或者由SCC AS完成返还操作。这样就避免了在第一用户设备中媒体流记录混乱的情况。返还过程完成之后，SCC AS或第二用户设备可以将相关的媒体流转移关系的记录删除，从而避免存储资源的浪费。

附图说明

图1为实现本发明方法具体实施例一的流程图；

图2为实现本发明方法具体实施例二的流程图；

图3为实现本发明方法具体实施例三的流程图；

图4为实现本发明方法具体实施例四的流程图；

图5为本发明实施例用户设备的结构示意图；

图6为本发明实施例用户设备的另一种结构示意图；

图7为本发明实施例业务集中和会话连续性应用服务器的结构示意图；

图8为本发明实施例业务集中和会话连续性应用服务器的另一种结构示意图。

具体实施方式

下面结合附图，对本发明的实施方案进行详细描述。以下实施例，均是假设前期UE-1将媒体流media2转移给UE-2，后续UE-2需要执行return(返还)操作，将media2返还给UE-1。

实施例一：

假定UE-1和UE-2分别与同一个Remote-UE(对端UE)存在媒体流连接media1和media2，并且UE-2中的媒体流media2是UE-1在前期通过transfer流程转移给UE-2的。在本实施例中，UE-2获知需要执行返还操作之后，向UE-1发送返还媒体流请求，并完成后续的返还流程，方法流程图可参见图1所示，具体包括：

S101.UE-2接收对media2的操作请求，根据该请求发起返还流程，删除与media2相关的媒体流转移关系的记录。

UE-2接收到对media2的操作请求后，根据存储的媒体流转移关系记录判断media2是否为UE-1转移给UE-2的，如果是，则发起一个返还请求，执行本实施例后续的返还流程；如果不是，则发起转移请求，即通过现有技术中的transfer流程将media2转移给UE-1。

其中，UE-2也可以在收到UE-1所转移的media2之后，直接针对media2提供相关选项，例如，在UI(User Interface，用户界面)中提供return选项，这样，UE-2就可以通过用户的选择直接发起返还请求。

UE-2发起return请求后，会删除与media2相关的媒体流转移关系的记录。

S102.UE-2向UE-1发送返还媒体流请求消息。

UE-2可以通过以下两种方式向UE-1发送返还媒体流请求消息：

方式一：UE-2向UE-1发送return请求消息，该请求消息可以通过refer消息携带。在该refer消息中包含请求的行为(return媒体流)、return的目标设备标识(该实施例中为UE-1)、待return的媒体流描述(包括媒体流类型、编码方式、与媒体流相关联的会话信息等)。通过refer消息的refer-to消息头指示执行return操作，refer-to消息的内容可以是如下形式：urn:feature:ReturnMedia或urn:feature:RetrieveMedia。

方式二：UE-2向UE-1发送transfer请求消息，同时在该消息中包含return媒体流指示信息。所述return媒体流指示信息可以用一个特殊的字符串来标识，例如isReturn，通过refer消息的refer-to或contact消息头进行携带。

transfer请求消息也可以通过refer消息携带，在该refer消息中包含请求的行为(transfer媒体流)、transfer的目标设备标识(该实施例中为UE-1)。在refer消息中还包含media2的媒体流描述(如media2的类型、media2编码方式、与media2相关联的会话信息等)。

需要说明的是，由图1可以看出，在本步骤中SCC AS仅负责转发消息，而不对消息做其他处理，因此通过上述两种方式发送的返还媒体流请求消息，也可以不经过SCC AS，直接由UE-1发送给S-CSCF，再由S-CSCF发送给UE-2。

S103.UE-1收到返还媒体流请求消息后，向SCC AS发送re-Invite(再邀请)消息，请求取回media2，即恢复media2的收发。该消息经S-CSCF到达SCC AS。

S104.SCC AS向对端UE发送re-Invite消息，更新对端会话分支。该消息经S-CSCF到达对端UE。

S105.对端UE接收到新的媒体流参数后，通过200OK消息进行确认回复，并开始接收/发送媒体流media2。该消息经S-CSCF到达SCCAS。

S106.SCC AS将对端UE确认的媒体流参数通过200OK应答消息发送给UE-1，并开始发送/接收媒体流media2。该消息经S-CSCF到达UE-1。

S107.SCC AS向UE-2发送Bye消息，断开与UE-2的连接，同时删除所保存的与media2相关的媒体流转移关系的记录。所述记录包括：UE-1将media2转移给UE-2的记录，和UE-2将media2转移给UE-1的记录。

需要说明的是，在本说明书中的具体实施例中，都是通过refer消息发起返还操作。在实际应用中，也可以使用其他的SIP(Session Initiation Protocol，会话初始协议)消息，例如Message、Info等，发起返还操作，这些均不影响本发明实施例的实现。

上述方法实现了UE-2主动将媒体流返还给UE-1，与现有技术中通过transfer流程返还媒体流的方法相比，由于UE-2事先确认了媒体流是由UE-1所转出的，因此向UE-1发送返还请求，UE-1根据所述返还请求，将之前转出的媒体流取回，这样就避免了在UE-1中，相同的媒体流有两个不同描述的情况出现。此外，UE-2发起返还请求后，会删除与media2相关的媒体流转移关系的记录，SCC AS也会在与UE-2断开连接之后，删除与media2相关的媒体流转移关系的记录，避免了存储资源的浪费。

实施例二：

假定UE-1和UE-2分别与同一个对端UE存在媒体流连接media1和media2，并且UE-2中的媒体流media2是UE-1在前期通过transfer流程转移给UE-2的。在本实施例中，UE-2向UE-1发送媒体流转移请求，由UE-1判断转入的媒体流是否为其转出的媒体流，并完成后续的返还流程，方法流程图可参见图2所示，具体包括：

S201.UE-2向UE-1发送转移媒体流请求消息。消息中携带待转移媒体流的来源标识，使UE-1能够判断出待转移的媒体流是否为其自身之前所转出。

所述转移媒体流请求消息可以通过refer携带。在该refer消息中，需要包含media2的来源标识，使得UE-1能够判断出media2是否为UE-1之前转出的媒体流。所述来源标识可以是：media2是从哪个设备转移过来的描述信息，也可以是media2在UE-2中的媒体流序列号信息、或media2在UE-2中的端口信息等形式。

此外，在refer消息中，还包含请求的行为(transfer媒体流)、transfer的目标设备标识(该实施例中为UE-1)、待转移媒体流信息(例如媒体流类型、编码方式、与媒体流相关联的会话信息等)。

与S101类似，在本步骤中SCC AS仅负责转发消息，而不对消息做其他处理，因此上述的媒体流请求消息也可以不经过SCC AS，直接由UE-1发送给S-CSCF，再由S-CSCF发送给UE-2。

S202.UE-1收到转移请求消息后，根据UE-1中存储的媒体流转移关系记录和转移请求消息中携带的来源信息，判断待转入的媒体流是否为UE-1转出的媒体流(如果来源标识为S201中所述的“media2是从哪个设备转移过来的描述信息”的形式，则不必查询媒体流转移关系记录)。如果是，执行本实施例后续的返还流程；如果不是，则通知UE-2，通过现有技术中的transfer流程将media2转移给UE-1

S203.UE-1向SCC AS发送re-Invite消息，请求取回media2，即恢复media2的收发。该消息经S-CSCF到达SCC AS。

S204.SCC AS向对端UE发送re-Invite消息，更新对端会话分支。该消息经S-CSCF到达对端UE。

S205.对端UE接收到新的媒体流参数后，通过200OK消息进行确认回复，并开始接收/发送媒体流media2。该消息经S-CSCF到达SCC AS。

S206.SCC AS将对端UE确认的媒体流参数通过200OK应答消息发送给UE-1，并开始发送/接收媒体流media2。该消息经S-CSCF到达UE-1。

S207.SCC AS向UE-2发送Bye消息，断开与UE-2的连接，同时删除所保存的与media2相关的媒体流转移关系的记录。所述记录包括：UE-1将media2转移给UE-2的记录，和UE-2将media2转移给UE-1的记录。

本实施例与实施例一的不同之处在于：实施例一是由UE-2来判断media2是否为UE-1转移给UE-2的，而本实施例是由UE-1来判断所要转入的media2是否自身之前所转出，这样，对于之前自身所转出的媒体流，执行取回流程，同样可以避免在UE-1中，相同的媒体流有两个不同描述的情况出现。在实际应用中，可以根据用户设备的功能，选择实施例一或二中的任意方法，实现媒体流的返还。

实施例三：

假定UE-1和UE-2分别与同一个对端UE存在媒体流连接media1和media2，并且UE-2中的媒体流media2是UE-1在前期通过transfer流程转移给UE-2的。在本实施例中，UE-2获知需要执行返还操作之后，向SCC AS发送返还媒体流请求消息，由SCC AS完成后续的返还流程，方法流程图可参见图3所示，具体包括：

S301.UE-2接收对media2的操作请求，根据该请求发起返还流程，删除与media2相关的媒体流转移关系的记录。

本步骤的具体实现，与S101所述相同。

S302.UE-2向SCC AS发送返还媒体流请求消息。

本步骤的具体实现，与S102所述类似，不同之处仅在于，将返还媒体流请求消息的发送目的地，由S102中的UE-1更换为SCC AS。

S303.SCC AS根据所收到的返还媒体流请求消息，向UE-1发送恢复媒体流请求消息re-Invite，请求UE-1恢复media2的收发。该消息经S-CSCF到达UE-1。

S304.UE-1向SCC AS发送200OK应答消息，并开始发送/接收数据流media2。该消息经S-CSCF到达SCC AS。

S305.SCC AS向对端UE发送re-Invite消息，更新远端会话分支。该消息经S-CSCF到达对端UE。

S306.对端UE接收到新的媒体流参数后，通过200OK消息进行确认回复，并开始接收/发送媒体流media2。该消息经S-CSCF到达SCC AS。

S307.SCC AS向UE-2发送Bye消息，断开与UE-2的连接，同时删除所保存的与media2相关的媒体流转移关系的记录。所述记录包括：UE-1将media2转移给UE-2的记录，和UE-2将media2转移给UE-1的记录。

需要说明的是，在本实施例中，步骤S305也可以在S303之前执行，或与S303同时执行。即SCCAS向UE-1和对端UE发送re-Invite消息的步骤是可以不限制先后顺序的。

本实施例中，也是由UE-2来判断待转移的媒体流media2是否为UE-1之前所转出，与实施例一不同之处在于，UE-2不是直接向UE-1发送返还媒体流请求消息，而是先将该消息发送给SCC AS，再由SCC AS完成后续的返还流程。本实施例方法可以适用于UE-1不支持取回功能的情况。

实施例四：

假定UE-1和UE-2分别与同一个对端UE存在媒体流连接media1和media2，并且UE-2中的媒体流media2是UE-1在前期通过transfer流程转移给UE-2的。在本实施例中，UE-2向SCC AS发送媒体流转移请求，由SCC AS判断待转移的媒体流是否为目标UE前期所转出的媒体流，并完成后续的返还流程，方法流程图可参见图4所示，具体包括：

S401.UE-2向UE-1发送转移媒体流请求消息。消息中携带媒体流的来源标识，使SCC AS能够判断出待转移的媒体流是否为转移目标UE(UE-1)之前所转出。

所述转移媒体流请求消息可以通过refer携带。在该refer消息中，需要包含请求的行为(transfer媒体流)、transfer的目标设备标识(该实施例中为UE-1)、待转移媒体流信息(例如媒体流类型、编码方式、与媒体流相关联的会话信息等)和media2的来源标识。

S402.SCC AS收到转移请求消息后根据上述transfer的目标设备标识、media2的来源标识，和自身所存储的媒体流转移关系，判断待转移的媒体流media2是否为UE-1之前所转出的媒体流。如果是，执行本实施例后续的返还流程；如果不是，则通知UE-2，通过现有技术中的transfer流程将media2转移给UE-1。

S403.SCC AS向UE-1发送恢复媒体流恢复请求消息re-Invite，请求UE-1恢复media2的收发。该消息经S-CSCF到达UE-1。

S404.UE-1向SCC AS发送200OK应答消息，并开始发送/接收数据流media2。该消息经S-CSCF到达SCC AS。

S405.SCC AS向对端UE发送re-Invite消息，更新远端会话分支。该消息经S-CSCF到达对端UE。

S406.对端UE接收到新的媒体流参数后，通过200OK消息进行确认回复，并开始接收/发送媒体流media2。该消息经S-CSCF到达SCC AS。

S407.SCC AS向UE-2发送Bye消息，断开与UE-2的连接，同时删除所保存的与media2相关的媒体流转移关系的记录。所述记录包括：UE-1将media2转移给UE-2的记录，和UE-2将media2转移给UE-1的记录。

与实施四类似，在本实施例中，步骤S405也可以在S403之前执行，或与S403同时执行。即SCCAS向UE-1和对端UE发送re-Invite消息的步骤是可以不限制先后顺序的。

本实施例中与实施例三的不同之处在于，UE-2向SCC AS发送返还媒体流请求消息后，由SCC AS判断待转移的媒体是否为UE-1之前所转出。应用本实施例的方法，除了不要求UE-1支持取回功能外，还可以不要求UE-2执行判断操作，进一步降低了实现返还流程对用户设备功能的要求。

以上方法实施例，都可以实现UE-2主动将媒体流返还给UE-1，与现有技术中通过transfer流程返还媒体流的方法相比，由于先确认了媒体流是由UE-1转给UE-2的(每个具体实施例执确认的主体不同)，因此可以根据确认的结果，由UE-1将之前转出的媒体流取回，或者由SCCAS完成返还操作。这样就避免了在UE-1中媒体流记录混乱的情况。返还过程完成之后，SCC AS或UE-2会删除相关的媒体流转移关系的记录，避免了存储资源的浪费。

实施例五：

相应于上面的方法实施例一，本发明实施例提供一种用户设备，参见图5所示，包括：

转移请求接收单元501，用于接收对媒体流的转移请求；

判断单元502，用于根据所述转移请求接收单元501接收的转移请求中携带的目标用户设备标识，和，所存储的转移关系记录，判断所述媒体流是否为所述目标用户设备转入的媒体流；

返还请求发送单元503，如果所述判断单元502的判断结果为是，则向所述目标用户设备发送返还媒体流请求消息。

其中，用户设备中还可以进一步包括转移记录删除单元504，用于在所述返还请求发送单元504发送返还媒体流请求消息之后，删除媒体流的转移关系记录。

上述用户设备，相应于方法实施例一中的UE-2，该用户设备能够自行确认媒体流是否为目标用户设备之前所转入的媒体流，并向目标用户设备发送返还媒体流请求消息。目标用户设备根据该请求，发起取回流程，恢复媒体流的收发。这样就避免了在目标用户设备中，相同的媒体流有两个不同描述的情况出现。

实施例六：

相应于上面的方法实施例二，本发明实施例还提供另一种用户设备，参见图6所示，包括：

转移请求接收单元601，用于接收第二用户设备发送的对媒体流的转移请求；

判断单元602，用于根据所述转移请求接收单元601接收的转移请求中携带的所述媒体流的来源标识，判断所述媒体流是否为自身转移给第二用户设备的媒体流；

取回单元603，如果所述判断单元602的判断结果为是，则向第二用户设备发起媒体流取回流程，恢复对所述媒体流的收发。

上述用户设备，相应于方法实施例一中的UE-1，与实施例五所述用户设备不同之处在于：该用户设备作为返还操作的目标设备，对待转移的媒体流进行判断，判断是否为自身之前所转出的媒体流，如果是，则完成取回流程。当返还操作的源设备不支持判断功能时，可以使用本实施例所述设备，实现在返还目标用户设备进行判断。

实施例七：

相应于上面的方法实施例三，本发明实施例还提供一种业务集中和会话连续性应用服务器SCC AS，参见图7所示，包括：

返还请求接收单元701，用于接收第二用户设备发送的返还媒体流请求消息，所述媒体流为第一用户设备在之前转移给第二用户设备的媒体流；

恢复单元702，用于根据所述返还请求接收单元701所接收的返还媒体流请求消息，向第一用户设备发送恢复媒体流请求消息，所述恢复媒体流请求消息用于指示第一用户设备恢复所述媒体流在第一用户设备的收发。

上述SCC AS，还可以进一步包括转移记录删除单元703，用于所述恢复单元702恢复所述媒体流在第一用户设备的收发之后，删除所述媒体流的转移关系记录。

上述SCC AS，接收第二用户设备的返还请求，即第二用户设备已经自行确认了要对媒体流执行返还操作，因此SCC AS可以直接完成后续流程，使用本实施例提供的SCC AS，可以不需要返还的目标设备支持取回功能。

实施例八：

相应于上面的方法实施例四，本发明实施例还提供另一种SCC AS，参见图8所示，包括：

转移请求接收单元801，用于接收第二用户设备发送的转移媒体流请求消息，所述转移媒体流请求消息中携带所述媒体流的来源标识；

判断单元802，用于根据所述转移请求接收单元801接收的转移请求中携带的所述媒体流的来源标识、和所存储的转移关系记录，判断所述媒体流是否为第一用户设备转移给第二用户设备的媒体流。

恢复单元803，如果所述判断单元802的判断结果为是，则根据所述转移请求，向第一用户设备发送恢复媒体流请求消息，所述恢复媒体流请求消息用于指示第一用户设备恢复所述媒体流在第一用户设备的收发。

上述SCC AS，还可以进一步包括转移记录删除单元804，用于所述恢复单元803恢复所述媒体流在第一用户设备的收发之后，删除所述媒体流的转移关系记录。

上述SCC AS，接收第二用户设备的媒体流转移请求，自行判断是否对所述媒体流进行返还操作，并完成后续流程，使用本实施例提供的SCC AS，不但不要求返还的目标设备(第一用户设备)支持取回功能，还可以不要求第二用户设备支持判断功能，进一步降低了实现返还流程对用户设备功能的要求。

实施例九：

本发明实施例还提供一种通信系统，包括业务集中和会话连续性应用服务器SCC AS、第一用户设备和第二用户设备；上述三种实体都可以实现判断待转移的媒体流是否为第一用户设备转移给第二用户设备的媒体流。根据执行判断的主体不同，则各实体的具体功能也不同：

如果执行判断的主体为SCC AS，则：

所述第二用户设备，用于向所述SCC AS发送媒体流转移请求；

所述SCC AS，用于接收所述第二用户设备发送的对媒体流的转移请求；根据所述转移请求中携带的所述媒体流的来源标识、转移的目标设备标识，和，所存储的转移关系记录，判断所述媒体流是否为第一用户设备转移给第二用户设备的媒体流；如果是，则恢复所述媒体流在第一用户设备的收发；

所述第一用户设备，用于接收所述SCC AS所恢复的媒体流。

如果执行判断的主体为第一用户设备，则：

所述第二用户设备，用于向所述第一用户设备发送媒体流转移请求；

所述第一用户设备，用于接收所述第二用户设备发送的对媒体流的转移请求；根据所述转移请求中携带的所述媒体流的来源标识，判断所述媒体流是否为自身转移给第二用户设备的媒体流；如果是，则向所述第二用户设备发起媒体流取回流程，恢复对所述媒体流的收发。

如果执行判断的主体为第二用户设备，则：

所述第二用户设备，用于根据媒体流转移目标用户设备标识，和，所存储的转移关系记录，判断所述媒体流是否为第一用户设备转入的媒体流；如果是，则向所述第一用户设备发送返还媒体流请求消息；

所述第一用户设备，用于根据所述第二用户设备发送的返还媒体流请求消息，向所述第二用户设备发起媒体流取回流程，恢复对所述媒体流的收发。

或者，

所述第二用户设备，用于根据媒体流转移目标用户设备标识，和，所存储的转移关系记录，判断所述媒体流是否为第一用户设备转入的媒体流；如果是，则向所述SCC AS发送返还媒体流请求消息；

所述SCC AS，用于接收所述第二用户设备发送的返还媒体流请求消息；则恢复所述媒体流在第一用户设备的收发；

所述第一用户设备，用于接收所述SCC AS所转移的媒体流。

对于装置与系统实施例而言，由于其基本相应于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置与系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (20)

1.一种转移媒体流的方法，在第一用户设备将媒体流转移给第二用户设备之后，第二用户设备将所述媒体流转移给第一用户设备，其特征在于，所述转移媒体流的方法包括：

接收第二用户设备发送的返还媒体流请求消息；其中，所述第二用户设备，在接收对媒体流的转移请求、根据所述转移请求中携带的目标用户设备标识和所存储的转移关系记录，判断所述媒体流为所述目标用户设备转入的媒体流后，发送所述返还媒体流请求消息；

根据所述返还媒体流请求消息，向第一用户设备发送恢复媒体流请求消息，所述恢复媒体流请求消息用于指示第一用户设备恢复所述媒体流在第一用户设备的收发。

2.根据权利要求1所述的方法，其特征在于，所述接收第二用户设备发送的返还媒体流请求消息，具体实现为：

接收第二用户设备发送的转移媒体流请求消息，所述转移媒体流请求消息中携带返还媒体流指示信息。

3.根据权利要求2所述的方法，其特征在于，所述返还媒体流指示信息通过参考refer消息的refer-to或连接contact消息头携带。

4.根据权利要求1至3中任一项所述的方法，其特征在于，还包括：

删除所述媒体流的转移关系记录。

5.一种转移媒体流的方法，在第一用户设备将媒体流转移给第二用户设备之后，第二用户设备将所述媒体流转移给第一用户设备，其特征在于，所述转移媒体流的方法包括：

接收第二用户设备发送的转移媒体流请求消息；所述转移媒体流请求消息中携带所述媒体流的来源标识；

根据所述来源标识，判断所述媒体流是否为第一用户设备转移给第二用户设备的媒体流；

如果判断结果为是，则向第一用户设备发送恢复媒体流请求消息，所述恢复媒体流请求消息用于指示第一用户设备恢复所述媒体流在第一用户设备的收发。

6.根据权利要求5所述的方法，其特征在于，所述来源标识为： 

所述媒体流是从哪个设备转移过来的描述信息。

7.根据权利要求5所述的方法，其特征在于，所述来源标识为：

所述媒体流在第二用户设备中的媒体流序列号信息，和/或所述媒体流在第二用户设备中的端口信息。

8.根据权利要求5所述的方法，其特征在于，所述根据所述来源标识，判断所述媒体流是否为第一用户设备转移给第二用户设备的媒体流，具体实现为：

根据所述来源标识，和所存储的转移关系记录，判断所述媒体流是否为第一用户设备转移给第二用户设备的媒体流。

9.根据权利要求5至8所述的方法，其特征在于，还包括：

删除所述媒体流的转移关系记录。

10.一种转移媒体流的方法，其特征在于，包括：

接收对媒体流的转移请求；

根据所述转移请求中携带的目标用户设备标识，和所存储的转移关系记录，判断所述媒体流是否为所述目标用户设备转入的媒体流；

如果判断结果为是，则向所述目标设备发送返还媒体流请求消息。

11.根据权利要求10所述的方法，其特征在于，还包括：

删除所述媒体流的转移关系记录。

12.一种转移媒体流的方法，其特征在于，包括：

接收第二用户设备发送的转移媒体流请求消息；所述转移媒体流请求消息中携带所述媒体流的来源标识；

根据所述来源标识，判断所述媒体流是否为自身转移给第二用户设备的媒体流；

如果判断结果为是，则向第二用户设备发起媒体流取回流程，恢复对所述媒体流的收发。

13.一种业务集中和会话连续性应用服务器，其特征在于，包括：

返还请求接收单元，用于接收第二用户设备发送的返还媒体流请求消息，所述媒体流为第一用户设备转移给第二用户设备的媒体流；其中，所述第二用户设备，在接收对媒体流的转移请求、根据所述转移请求中携带的目标用户设备标识和所存储的转移关系记录，判断所述媒体流为所述目标用户设备转入的媒体流后，发送所述返还媒体流请求消息；

恢复单元，用于根据所述返还请求接收单元所接收的返还媒体流请求消息，向第一用户设备发送恢复媒体流请求消息，所述恢复媒体流请求消息用于指示第一用户设备恢复所述媒体流在第一用户设备的收发。

14.根据权利要求13所述的服务器，其特征在于，该服务器进一步包括：

转移记录删除单元，用于在所述恢复单元恢复所述媒体流在第一用户设备的收发之后，删除所述媒体流的转移关系记录。

15.一种业务集中和会话连续性应用服务器，其特征在于，包括：

转移请求接收单元，用于接收第二用户设备发送的转移媒体流请求消息，所述转移媒体流请求消息中携带所述媒体流的来源标识；

判断单元，用于根据所述转移请求接收单元接收的转移请求消息中携带的所述媒体流的来源标识，和所存储的转移关系记录，判断所述媒体流是否为第一用户设备转移给第二用户设备的媒体流；

恢复单元，如果所述判断单元的判断结果为是，则根据所述转移请求，向第一用户设备发送恢复媒体流请求消息，所述恢复媒体流请求消息用于指示第一用户设备恢复所述媒体流在第一用户设备的收发。

16.根据权利要求15所述的服务器，其特征在于，该服务器进一步包括：

转移记录删除单元，用于在所述恢复单元恢复所述媒体流在第一用户设备的收发之后，删除所述媒体流的转移关系记录。

17.一种用户设备，其特征在于，包括：

转移请求接收单元，用于接收对媒体流的转移请求；

判断单元，用于根据所述转移请求接收单元接收的转移请求中携带的目标用户设备标识，和所存储的转移关系记录，判断所述媒体流是否为所述目标用户设备转入的媒体流；

返还请求发送单元，如果所述判断单元的判断结果为是，则向所述目标用户设备发送返还媒体流请求消息。

18.根据权利要求17所述的用户设备，其特征在于，该用户设备进一步包括： 

转移记录删除单元，用于在所述返还请求发送单元发送返还媒体流请求消息之后，删除所述媒体流的转移关系记录。

19.一种用户设备，其特征在于，包括：

转移请求接收单元，用于接收第二用户设备发送的对媒体流的转移请求；

判断单元，用于根据所述转移请求接收单元接收的转移请求中携带的所述媒体流的来源标识，判断所述媒体流是否为自身转移给第二用户设备的媒体流；

取回单元，如果所述判断单元的判断结果为是，则向第二用户设备发起媒体流取回流程，恢复对所述媒体流的收发。

20.一种通信系统，其特征在于，包括业务集中和会话连续性应用服务器、第一用户设备和第二用户设备；

所述第二用户设备，用于向所述业务集中和会话连续性应用服务器发送媒体流转移请求；

所述业务集中和会话连续性应用服务器包括转移请求接收单元、判断单元和恢复单元，其中，转移请求接收单元，用于接收所述第二用户设备发送的对媒体流的转移请求；判断单元，用于根据所述转移请求中携带的所述媒体流的来源标识、转移的目标设备标识，和所存储的转移关系记录，判断所述媒体流是否为第一用户设备转移给第二用户设备的媒体流；恢复单元，用于如果所述判断单元的判断结果为是，则根据所述转移请求，向第一用户设备发送恢复媒体流请求消息，所述恢复媒体流请求消息用于指示第一用户设备恢复所述媒体流在第一用户设备的收发；

所述第一用户设备，用于接收所述业务集中和会话连续性应用服务器所恢复的媒体流。 

Images