WO2011097982A1 - 用户设备间媒体转移方法和应用服务器 - Google Patents

用户设备间媒体转移方法和应用服务器 Download PDF

Info

Publication number
WO2011097982A1
WO2011097982A1 PCT/CN2011/070504 CN2011070504W WO2011097982A1 WO 2011097982 A1 WO2011097982 A1 WO 2011097982A1 CN 2011070504 W CN2011070504 W CN 2011070504W WO 2011097982 A1 WO2011097982 A1 WO 2011097982A1
Authority
WO
WIPO (PCT)
Prior art keywords
session
application server
scc
media
master
Prior art date
Application number
PCT/CN2011/070504
Other languages
English (en)
French (fr)
Inventor
衣强
金辉
Original Assignee
华为终端有限公司
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 华为终端有限公司 filed Critical 华为终端有限公司
Priority to EP11741853.3A priority Critical patent/EP2472952B1/en
Publication of WO2011097982A1 publication Critical patent/WO2011097982A1/zh
Priority to US13/584,371 priority patent/US9531816B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/148—Migration or transfer of sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1063—Application servers providing network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1089—In-session procedures by adding media; by removing media
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1093—In-session procedures by adding participants; by removing participants
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1094—Inter-user-equipment sessions transfer or sharing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management

Definitions

  • the embodiments of the present invention relate to communication technologies, and in particular, to a media transfer method and an application server between user devices. Background technique
  • the IP Multimedia Subsystem is an IP-based multimedia service communication network.
  • the IMS network adopts the IMS core network subsystem (IP Multimedia Core Network Subsystem) for service control, and the packet switching network or circuit-switched network serves as an access network to provide bearer for signaling and media transmission, thereby separating service control and bearer into IP multimedia.
  • IP Multimedia Core Network Subsystem IP Multimedia Core Network Subsystem
  • the application provides a unified and flexible support platform.
  • IMS sessions When IMS users move between different access networks, in order to ensure a good user experience, it is required to maintain the IMS session continuity (Session Continuity, SC for short) without interrupting the ongoing IMS session.
  • SC Session Continuity
  • the continuity of business in the process of transferring some or all media streams of an IMS session between different UEs (Inter-UE Transfer, IUT for short) is part of the continuity of the IMS session.
  • One end of the session may include one or more UEs.
  • the sessions of the multiple UEs form a joint session.
  • the media stream may be transferred from one UE to another UE, or transferred to a UE outside the joint session, and the UE joins the joint session after the transfer is completed.
  • Service Centralization and Continuity Server (Service Centralization and The Continuity Application Server (SCC AS) is a key functional entity in the IMS session continuity system. It interacts with the IMS user through a Serving Call Session Control Function (S-CSCF) to execute the core SC.
  • S-CSCF Serving Call Session Control Function
  • Business ⁇ control To simplify the description, this paper refers to the business concentration and continuity application server as a continuous application server.
  • each UE may present multiple access legs through the SCC AS to which it belongs, and multiple access branches are anchored to the SCC AS of the master UE and present a peer to the peer end. Branch ( remote leg ).
  • the SCC AS to which the master UE belongs is referred to as the master SCC AS
  • the SCC AS to which the controlled UE belongs is referred to as the controlled SCC AS.
  • the master SCC AS maintains the UEs in the joint session and the media related information.
  • the media transfer mode in which the UE transfers the media on the other UEs to the UE by sending a request is called a "pull mode", that is, a pull mode, and the requesting UE may be a controlled UE in the joint session, or may be a UE outside the joint session. .
  • the session discovery phase of the UE if a discovered target UE is a controlled UE of the joint session, and the controlled UE and the master UE are different contracted UEs, and belong to different SCC ASs, After the pull mode media transfer request is sent to the SCC AS to which the target UE belongs, the media transfer operation cannot be completed because the controlled SCC AS does not have the media transfer right. It can be seen that the prior art has a great limitation on the media transfer operation between UEs, and the continuity of the session cannot be reliably guaranteed. Summary of the invention
  • the embodiments of the present invention provide a media transfer method and an application server between user equipments to implement media transfer between user equipments belonging to different service sets and continuous application servers to ensure session continuity.
  • a method for media transfer between user devices including:
  • the target continuity application server receives a pull mode media transfer request initiated by the initiator user equipment to the target user equipment, where the target continuity application server is a continuity application server to which the target user equipment belongs, and the pull mode medium
  • the transfer request includes session identification information, where the session identification information is used to identify a session in which the media to be transferred is located on the target user equipment; and the session in which the media to be transferred is located is a joint session, and the target continuity application server Determining, according to the session identification information, that the local machine is a controlled continuity of a joint session in which the media to be transferred is located
  • the pull mode media transfer request is forwarded to the master continuous application server of the joint session, so that the master continuous application server performs media transfer, where the master continuity application
  • the server is a continuity application server to which the master user equipment of the joint session belongs.
  • a continuity application server including:
  • a receiving module configured to receive a pull mode media transfer request initiated by the initiator user equipment to the target user equipment, where the pull mode media transfer request includes session identifier information, where the session identifier information is used to identify the target user equipment The session where the media to be transferred is located;
  • a forwarding module configured to: when the session where the to-be-transferred media is a federation session, and determining, according to the session identification information, that the local device is a controlled continuity application server of a joint session where the media to be transferred is located, The media transfer request is forwarded to the master continuous application server of the joint session, so that the master continuous application server performs media transfer, where the master continuous application server is the master user of the joint session.
  • the continuity application server to which the device belongs.
  • the pull mode media transfer request may be forwarded to the main control continuity application server, so that the main control continuity application server performs In the media transfer operation, when the continuous application servers in the media transfer operation are the same network element, the operation scheme of this embodiment may also be applicable and simplified. Therefore, the present embodiment can be applied to various situations in which media transfer operations occur, reliably perform media transfer operations, and ensure session continuity.
  • FIG. 1 is a flowchart of a media transfer method between user equipments according to Embodiment 1 of the present invention
  • FIG. 1 is a signaling flowchart of a media transfer method between user equipments according to Embodiment 2 of the present invention
  • FIG. 4 is a signaling flowchart of a method for media transfer between user equipments according to Embodiment 4 of the present invention
  • FIG. 5 is a flowchart of a continuous application server according to Embodiment 6 of the present invention; Schematic. detailed description
  • the media in addition to the master UE, the media can be actively transferred to the controlled UE, and the controlled UE can also be in the joint session in the master UE or other controlled UE.
  • the media is transferred to itself, or the UE in the joint session initiates a pull mode media transfer request, transfers the media in the joint session to itself and joins the joint session, thereby enhancing the IUT function.
  • the session continuity topic allows media to be transferred to different subscribed UEs in the REL10 phase. In the UE discovery process, it is allowed to discover UE information belonging to different subscriptions and session information thereon. Similarly, for the pull mode media transfer, the UEs belonging to the same subscription are allowed to initiate the pull.
  • the mode media transfer request also allows the UEs belonging to the different subscriptions to initiate the pull mode media transfer request.
  • the same subscription here refers to the UE that initiates the pull mode media transfer request and the target UE where the media is located belongs to the same contract.
  • the obtained session information is only the session information on the target UE and does not include the information in the joint session where the target UE is located.
  • the technical solutions of the embodiments of the present invention can implement the pull mode media transfer to ensure the continuity of the session.
  • the SCC AS to which the master UE in the joint session belongs is called a master SCC AS;
  • the SCC AS to which the control UE belongs is referred to as the controlled SCC AS;
  • the UE that initiates the pull mode media transfer operation is referred to as the initiator UE;
  • the SCC AS to which the initiator UE belongs is referred to as the initiator SCC AS;
  • the UE is referred to as the target UE, and the SCC AS to which the target UE belongs is referred to as the target SCC AS.
  • the initiator UE may also be the controlled UE in the joint session, and the initiator SCC AS, the target SCC AS, and the master SCC AS may also be The same SCC AS. Different UEs may belong to the same contract, belong to the same SCC AS, and may belong to different subscriptions and belong to different SCC ASs.
  • the initiator UE Before requesting to perform the media transfer, the initiator UE first discovers the session information on the target UE during the session discovery process, and the discovered target UE may be the master UE of the joint session or the controlled UE of the joint session.
  • the discovered session information includes session identification information (ses si on_ID ) and media type of each session in which the discovered target UE participates.
  • the initiator UE determines to transfer one or more of the media to itself based on the above information.
  • Step 100 The target SCC AS receives a pull mode media transfer request initiated by the initiator UE to the target UE, and the target SCC AS terminates sending the pull mode media transfer request to the target UE.
  • the target SCC AS is the SCC AS to which the target UE belongs
  • the pull mode media transfer request includes session identification information, where the session identifier information is used to identify the session where the media to be transferred on the target UE is located, specifically the target UE. Session identification information of the session with the target SCC AS.
  • the pull mode media transfer request may further include other information, such as an initiator UE identifier and a target UE identifier, and the like;
  • the pull mode media transfer request may be sent to the initiator SCC AS to which the initiator UE belongs by using the initial filtering criterion (iFC) through the S_CSCF to which the initiator UE belongs.
  • iFC initial filtering criterion
  • the target SCC AS receiving the pull mode media transfer request from the initiator UE specifically includes: determining, by the SCC AS that receives the pull mode media transfer request, whether the target UE belongs to the local device according to the target UE identifier in the media transfer request If yes, it is determined that the local device is the target SCC AS, and the subsequent step 2 00 is continued. If not, the pull mode media transfer request is sent according to the target UE identity, until the target SCC AS receives the pull mode media transfer request from the initiator UE. . That is, the pull mode media transfer request is based on the target UE identity and can be forwarded to the target SCC AS via multiple hops. Since the request is a media transfer request of the pull mode, it terminates after reaching the target SCC AS, and the media transfer operation is performed by the SCC AS, so that it is not necessary to transmit to the target UE.
  • Step 200 When the session where the media to be transferred is located is a joint session, and the target SCC AS determines that the local device is the controlled SCC AS of the joint session where the media to be transferred is located according to the session identification information, forwarding the pull mode media transfer request to the session
  • the master SCC AS of the joint session is configured to enable the master SCC AS to perform media transfer, where the master SCC AS is the SCC AS to which the master UE of the joint session belongs.
  • each SCC AS can determine whether the local device is the master SCC AS according to the session identification information in the pull mode media transfer request and the joint session information saved by the local device.
  • the target SCC AS determines that the local device is the master SCC AS
  • the target SCC AS can directly perform the media transfer operation as the master SCC AS, which is also the master UE as the target UE, or the target UE and the master UE belong to the same The simple case of SCC AS.
  • the session identifier information between the target UE and the target SCC AS included in the pull mode media transfer request may be further converted into the target SCC. Session identification information between the AS and the master SCC AS.
  • the target SCC AS is a controlled SCC AS that requires conversion of session identification information.
  • the reason for changing the session identification information is:
  • the controlled SCC AS acts as a back to back user agent (B2BUA) when the controlled UE establishes the media, and sends signaling to the master SCC AS, and thus the controlled UE
  • B2BUA back to back user agent
  • the session between the controlled UE and the controlled SCC AS and the session between the controlled SCC AS and the master SCC AS have different session identifiers, resulting in different session identification information.
  • the session identification information in the original pull mode media transfer request is the session identifier between the controlled UE and the controlled SCC AS, and the master SCC AS cannot be matched, so the conversion needs to be performed, so that the master SCC AS is based on the controlled SCC AS and the master.
  • the session identification information between the control SCC ASs matches the session in which the media to be transferred is located.
  • the target SCC AS forwards the pull mode media transfer request to the master SCC AS in various ways, such as: including redirect and direct transmission.
  • the inv i te message can be used as a pull mode media transfer request, which is indicated by the message header in the invite message.
  • the header can specifically use content deployment or topic headers.
  • the forwarding operation may be: the target SCC AS determines, according to the initiator UE identifier in the invite message, whether the initiator UE belongs to the local device;
  • the target SCC AS may send a redirect message to the initiator UE to send the invite message to the master SCC AS, and carry the redirect message between the target SCC AS and the master SCC AS.
  • the session identification information is such that the session identification information in the initiator SCC AS update invitation message is updated to the session identification information between the target SCC AS and the master SCC AS, and the invitation message is directly sent to the master SCC AS.
  • the invitation message is sent directly to the master SCC AS.
  • the target SCC AS directly forwards the pull mode media transfer request to the master SCC AS.
  • the redirection is used, and the initiator UE sends a pull mode media transfer request to the master SCC AS.
  • the pull mode media transfer request may also adopt a refer message, and the header field of the message in the transfer message indicates that the initiator UE joins the current joint session after completing the pull mode media transfer.
  • the header field can be a refer-to header field carrying information indicating joining the current federation session.
  • the forwarding operation may be that the target SCC AS directly sends the transfer message to the master SCC AS, and the original session identifier information in the transfer message is updated to the session identifier information between the target SCC AS and the master SCC AS.
  • the manner in which the target SCC AS forwards the pull mode media transfer request to the master SCC AS includes but is not limited to the above two.
  • the master SCC AS transfers the to-be-transferred media from the target UE to the target UE according to the target UE identifier, the initiator UE identifier, and the converted session identifier information in the pull mode media transfer request.
  • the step of the initiator UE may specifically include:
  • the master SCC AS determines whether the initiator UE is in the current joint session, and if not, creates a new session with the initiator UE, establishes a to-be-transferred media in the newly created session, and updates the peer end to dry the media on the target UE, thereby Transferring the to-be-transferred media to the initiator UE; if yes, you can create a new session to the initiator UE, establish the media to be transferred in the newly created session, or add the pending access branch corresponding to the initiator UE in the current joint session. The media is transferred, and the peer is updated, and the media on the target UE is released, thereby completing the media transfer operation.
  • the master SCC AS may further send a notification message to the initiator SCC AS to notify the initiator SCC AS whether the initiator UE is in the current joint session.
  • the new session belongs to the current joint session, the initiator UE is the controlled UE of the joint session, the information of the master UE of the joint session, and/or the information of the master SCC AS of the joint session, such as the master UE and the master SCC AS.
  • the address information and the identity information, etc. so that the initiator UE and the initiator SCC AS each know their identity information in the joint session, and are easy to perform other operations.
  • Session initiation protocol Session initiation protocol (Ses s ion Initiating Protocol Protoco l is generally used in IMS networks)
  • SIP Session initiation protocol
  • the embodiment of the present invention can implement an inter-UE media transfer method based on an existing signaling message, which is separately described in the following embodiments.
  • FIG. 2 is a signaling flowchart of a media transfer method between user equipments according to Embodiment 2 of the present invention.
  • the invite message is specifically used as the pull mode media transfer request, and the applicable situation is that the master UE and the controlled UE in the joint session belong to different SCC ASs, and the initiator UE that is not part of the joint session
  • the transferred media is requested to the controlled UE of the joint session, and the initiator UE and the master UE and the controlled UE respectively belong to different subscriptions and belong to different SCC ASs.
  • the initiator UE obtains the session and media information on the target UE through the session discovery process.
  • the invitation message is a type of SIP signaling, including multiple header fields and message bodies.
  • the method performed by the embodiment based on the invitation message includes the following steps:
  • Step 201 The initiator UE initiates an invite message to establish a session, and carries a pull-type media transfer indication in the invite message.
  • the invite message includes at least an initiator UE identifier, a target UE identifier, and session identifier information between the target UE and the target SCC AS.
  • the invitation message is actually sent to the initiator SCC AS first, and the network side performs route forwarding according to the destination address.
  • the destination address of the invite message is the target UE identifier.
  • the invitation message can use its header field and message body to carry information, for example: Session Description Protocol (SDP) message body, content deployment or topic header i or, join header field, uniform resource identification request (request Uniform Resource) Identifier, simple request-URI ) Header field, target header field, and source header field.
  • SDP Session Description Protocol
  • uniform resource identification request request Uniform Resource
  • simple request-URI simple request-URI
  • the media line of the SDP message body indicates the media to be established in itself, that is, the type of the media to be transferred;
  • the join header field can be specifically The session identification information on the target UE obtained in the session discovery phase is specifically the session identification information of the session between the controlled UE and the controlled SCC AS.
  • the session identifier information may be composed of a session identifier, a session source identifier, and a session peer identifier.
  • the specific form may be "Jo in:
  • a unified resource identification request (reque s t-URI) header field which may also be referred to as an identification request header field, indicating the destination to which the invitation message is sent.
  • the destination address is the target UE identity.
  • Each UE identity may be, but is not limited to, identified by the URI of the UE.
  • the target header field and the source header field, the source domain is the identity information of the initiator UE, for example, "From: initiator UE URI”
  • the target header field is the identity information of the target UE, for example, "To: Controlled UE URI” .
  • the parameters of the target header field and the identifier request header field are identical, they have different identification functions when they are recognized and recognized.
  • Step 202 The SCC AS that receives the invite message determines, according to the destination address in the invite message, whether the local device is the SCC AS to which the UE belongs to the destination address, and if yes, proceeds to step 2 G4, and if not, continues to send according to the destination address.
  • the message is invited, and step 203 is performed.
  • the invitation message in this embodiment is first sent to the initiator SCC AS. Since the initiator SCC AS and the target SCC AS are different SCC ASs, the current SCC AS judgment is no, and the invitation is forwarded. Message.
  • the SCC AS that receives the invitation message may first identify the invitation message as a pull mode media transfer request according to the invitation message content deployment or the topic header field. After the step of identifying the inviting message as the pull mode media transfer request, the initiator SCC AS may further verify whether the initiator UE has the right to initiate the pull mode media transfer request, and if yes, continue to perform the subsequent step 203, otherwise The initiator UE returns an error response, such as a 4** response message, for terminating the invite message.
  • Step 203 The SCC AS that receives the invite message determines whether the local device is the SCC AS to which the UE belongs to the destination address according to the destination address in the invite message, and is consistent with the operation of the step 202. If yes, proceed to the subsequent step 204; If no, the invitation message is sent according to the destination address, until the SCC AS to which the UE belongs to the destination address receives the invite message from the initiator UE, and the embodiment sends the message to the target SCC AS.
  • Step 204 The invitation message is sent to the target SCC AS to which the target UE belongs, and the target SCC AS identifies the invitation message as the pull mode media transfer request according to the invitation message content deployment or the topic header field. That is, the request is sent to the target UE. Further, before performing the subsequent judgment logic, the target SCC AS may also authenticate to the target UE whether the initiator UE is allowed to initiate a pull mode media transfer request to the target UE.
  • the target SCC AS that receives the invite message determines whether the local device is the master SCC AS of the joint session where the media to be transferred is located. If yes, the SCC AS can perform media transfer as the master UE. If not, step 205 is performed.
  • the invite message is sent to the controlled SCC AS, so the target SCC AS in step 204 is the controlled SCC AS, and the controlled SCC AS and the master SCC AS are Different SCC ASs, so the determination result is no, and step 205 is continued.
  • the SCC AS determines whether the local device is the master of the joint session.
  • the SCC AS may specifically determine the session identifier information included in the invitation message and the joint session information saved by the local device.
  • Step 205 The target SCC AS determines, according to the initiator UE identifier in the invite message, whether the initiator UE belongs to the local device, and if not, returns a redirect message to indicate that the initiator SCC AS that receives the redirect message according to the redirect message Update the session identification information in the invitation message, and send the updated invitation message to the master SCC AS. If yes, the target SCC AS updates the session identifier information in the invited message, and directly updates the updated invitation message. The master SCC AS sends.
  • the step 205 actually performs the redirection operation, and the converted session identification information is carried in the redirect message.
  • the reason that the session identification information in the invitation message needs to be updated is as follows:
  • the session identifier information of the invitation message added to the header field is the session identifier between the controlled UE and the controlled SCC AS, so that the master SCC AS can find the match with the session identifier.
  • the session needs to update the session identification information in the join header field to the session identification information of the session between the controlled SCC AS and the master SCC AS.
  • step 205 the process of converting the session identification information and then carrying it in the redirect message is as follows:
  • the redirect message can be implemented using a 302 redirect response message (302 (redi rect)).
  • the address of the contact in the redirecting response message is specifically the public service identifier of the joint session master SCC AS saved by the controlled SCC AS, and is used for the public service identifier (PS I ) of the joint session master SCC AS.
  • PS I public service identifier
  • the message is sent to the address specified by the interaction address header field, that is, the master SCC AS of the joint session.
  • the converted session identification information is carried in the 302 redirect response message through an Extensible Markup Language (XML) message body.
  • XML Extensible Markup Language
  • Content-Type appl icat ion/vnd.3gpp.
  • the type of the join+xml// message body indicates that the content of the message body is used to indicate the session information of joining the session.
  • Step 206 is: After the initiator SCC AS receives the 302 redirect response message, it sends an invite message to the master SCC AS according to the 302 redirection response message.
  • step 206 after the initiator SCC AS receives the 302 redirect response message, it sends a 302 redirect response message to the initiator UE as a B2BUA termination, and according to the indication information of the 3 C 2 redirect response message, to the interaction address.
  • the address indicated by the header field sends an invite message, and the XML message body content of the 302 redirect response message is written into the redirected invite message header field, and the source field and the target header field are unchanged, and the original invite message is The other related header fields and message bodies are copied into the redirected invite message.
  • Step 207 to step 217 the master SCC AS receives an invite message from the initiator UE indicating that the media transfer is requested by the pull mode, and the master SCC AS determines the target UE identity, the initiator UE identity, and the translation according to the pull mode media transfer request.
  • the session identification information transfers the to-be-transferred media from the target UE to the initiator UE.
  • the master SCC AS that receives the invitation message identifies the invitation message as a pull mode media transfer request according to the content deployment or the topic message header, and determines that the local device is the federation of the media to be transferred according to the session identifier information and the joint session information saved locally.
  • the master of the session SCC AS is the master of the session SCC AS.
  • the master SCC AS determines, according to the initiator UE identifier in the source field of the invitation message and the joint session information saved by the local device, whether the initiator UE performs the corresponding media transfer operation in the current joint session, when the initiator UE is not in the joint session.
  • the operation is as follows:
  • Step 207 Before performing the media transfer operation, the master SCC AS may authenticate to the master UE whether the sender UE is allowed to initiate a pull mode media transfer request, and when receiving the master UE, the initiator UE is allowed to initiate a pull mode media transfer request. And performing a subsequent step, if the master UE does not allow the initiator UE to initiate a pull mode media transfer request, returning a failure response, for example, a 4** failure response message;
  • Step 208 After verifying that the initiator UE is allowed to transfer the media of the target UE to itself, the master SCC AS sends a re-inv i te message to the peer to update the peer, so that the corresponding media is in the initiator UE. Communication with the peer;
  • Step 209 The peer end returns a 200 ok response message.
  • Step 21 Q ⁇ 213 the master SCC AS returns a 200 ok response message of the invite message to the initiator UE by the initiator SCC AS according to the information returned by the peer, completes the transferred media negotiation, and the initiator UE passes the initiator SCC AS.
  • the master SCC AS returns a 200 ok confirmation message ACK;
  • the master SCC AS when it returns a 200 ok response message of the invite message to the initiator UE, it may send a notification message to the initiator SCC AS to notify the initiator SCC AS that the new session belongs to the current joint session, and the corresponding UE is subject to Controlling the UE, the SCC AS belongs to the SCC AS to which the controlled UE belongs.
  • the notification message may also include main information of the joint session, such as the address of the master UE, the master SCC AS, or identity information.
  • the above information can be carried in the XML message body of the 20Q ok response message.
  • the initiator SCC AS recognizes the message, and saves the message body content information, deletes the message body, and the 200 ok response message continues to be sent to the initiator UE.
  • Step 214 The main control SCC AS returns a confirmation message ACK of the 200 ok response message to the opposite end;
  • Steps 215 ⁇ 216 the target SCC AS updates the target UE where the media is located, and releases the media transferred to the initiator UE from the target UE.
  • Step 217 The master SCC AS updates the joint session information held by the master UE, that is, the UE where the transferred media is changed from the target UE to the initiator UE.
  • the initiator UE that sends the invite message belongs to the same contract and belongs to the same SCC AS
  • the invitation message is directly sent to the target SCC AS to which the target UE belongs according to the target header field of the invite message.
  • the SCC AS determines that the initiator UE that sent the invite message belongs to the current target SCC AS by using the source domain, and may not send the 302 redirect response message, but directly sends the invite message to the master controller to which the master UE of the joint session belongs.
  • SCC AS determines that the initiator UE that sent the invite message belongs to the current target SCC AS by using the source domain, and may not send the 302 redirect response message, but directly sends the invite message to the master controller to which the master UE of the joint session belongs.
  • This embodiment provides a process in which a UE that is not in a joint session requests a media transfer from a controlled UE of a joint session by using an invite message.
  • the controlled UE and the master UE belong to different subscriptions, and the controlled SCC AS receives the pull mode.
  • the master SCC AS completes the media transfer process.
  • the technical solution guarantees the reliability of media transfer between UEs.
  • FIG. 3 is a signaling flowchart of a media transfer method between user equipments according to Embodiment 3 of the present invention.
  • the established joint session includes a master UE and two or more controlled UEs.
  • An embodiment is described by taking two controlled UEs as an example, that is, a first controlled UE and a second controlled UE, The three controlled UEs belong to different SCC ASs, and the second controlled SCC AS and the master SCC AS are different SCC ASs.
  • the embodiment is specifically a method for the second controlled UE to request to transfer the media on the first controlled UE to itself.
  • the second controlled UE is the initiator UE
  • the first controlled UE is the target UE, and the invitation message is used.
  • the initiator UE can still discover session and media information on other UEs through the session discovery process, and accordingly, it is decided to request one or more media on the target UE to transfer to itself.
  • the initiator UE does not know that it is the controlled UE in the joint session, and cannot learn that the target UE belongs to the same joint session through the session discovery process. Therefore, the second controlled UE still initiates pulling similar to the second embodiment.
  • Mode media transfer request the media transfer method includes the following steps: Step 301 - Step 306 is substantially the same as steps 201 - 206 in Embodiment 2.
  • the second controlled UE initiates an invite message as an initiator UE to establish a signaling connection of the media transfer, where the invite message includes at least an initiator UE identifier, a target UE identifier, and session identifier information between the target UE and the target SCC AS. And the media to be transferred; wherein the media to be transferred is one or more media on the target UE.
  • the invitation message is sent to the master SCC AS.
  • the format of the header field and the message body of the invitation message is the same as that of the second embodiment, and will not be described again.
  • the master SCC AS transfers the to-be-transferred media from the target UE to the initiator UE according to the target UE identifier, the initiator UE identifier, and the converted session identifier information in the pull mode media transfer request.
  • the master SCC AS determines that the invite message is a pull mode media transfer request according to the content deployment or the topic message header of the invite message, and learns that the local machine is the master SCC AS in the joint session according to the session identifier information in the join header field.
  • the master SCC AS determines whether the initiator UE is in the current joint session according to the initiator UE identifier in the source field of the invitation message and the joint session information saved by the local device. If not, the steps 207-217 of the second embodiment may be performed. If yes, the master SCC AS adds the to-be-transferred media to the original access branch corresponding to the initiator UE in the current joint session, so that the signaling information of all media on the initiator UE is transmitted in the same access branch.
  • the media transfer performed by the master SCC AS differs from the second embodiment in that the initiator UE belongs to the joint session in this embodiment.
  • the specific process is as follows:
  • Step 307 The master SCC AS initiates a request for authenticating the initiator UE to the master UE, and receives a result of whether the returned authentication is allowed. If the authentication permits, the following steps are continued; Steps 3Q8 to 309, the master SCC AS returns a termination response of the invite message to the initiator UE, such as a 487 response message (487 Reques t Termined), and forwards the initiator message to the initiator UE via the initiator SCC AS to terminate the invite message.
  • a termination response of the invite message such as a 487 response message (487 Reques t Termined
  • Steps 310 ⁇ 311 the initiator UE's final response message to the master SCC AS returns an acknowledgement message ACK via the initiator SCC AS;
  • Step 312 - 313 The master SCC AS searches for the original access branch corresponding to the initiator UE in the current joint session, sends a re-invitation message in the original access branch of the initiator UE, and adds the to-be-transferred message in the re-invitation message.
  • the media may specifically add a re-inv i te wi th pu ll med ia des cr ipt ion in SDP in the SDP message body of the re-invitation message, and the re-invitation message is sent to the initiator through the initiator SCC AS.
  • UE to add to the initiator UE the media to be transferred;
  • Steps 314 ⁇ 315 the initiator UE returns a 2 G 0 ok response message of the re-invitation message via the initiator SCC AS, where the response message carries media description information such as the port number allocated by the initiator UE for the transfer media;
  • Steps 316 ⁇ 317 The master SCC AS sends a re-invitation message to the peer end to update the peer end according to the description information of the transferred media returned by the initiator UE, and the peer end returns a 200 ok response message;
  • Step 318 - 319 the master SCC AS returns an acknowledgement message ACK to the initiator response message for the 200 ok response message;
  • Step 320 The primary control SCC AS returns an acknowledgement message ACK of the 200 ok response message to the opposite end;
  • Steps 321 ⁇ 322 the target SCC AS updates the target UE where the media is located, and releases the media transferred to the initiator UE from the target UE.
  • Step 323 The master SCC AS updates the joint session information held by the master UE, and the UE where the media is transferred is changed from the first controlled UE to the second controlled UE.
  • the pull mode media transfer request may be directly sent to the first controlled SCC AS, and the first controlled SCC AS obtains the above judgment process. If the request is sent by the UE belonging to the SCC AS, the 302 redirect response message does not have to be returned, and the invite message is directly forwarded to the master SCC AS.
  • the media transfer mode of the second embodiment may be adopted, that is, the newly created session of the initiator UE is not terminated. So that the initiator UE has two access branches in this joint session. There are two access branches so that the UE can transmit different media streams in different session networks, such as a controlled UE requesting a transfer.
  • the video media is used to establish an access branch of the video medium in the packet domain access network with a larger channel bandwidth, so as to facilitate the media stream transmission.
  • the specific implementation process is as described in the second embodiment.
  • This embodiment provides a scheme in which a controlled UE of a joint session requests media transfer from other controlled UEs of the joint session.
  • the initiator UE sends a pull mode media transfer request in the joint session
  • the target SCC AS receives the pull mode media transfer request, and sends the pull mode media transfer request to the master SCC AS, and the master SCC AS completes the media transfer process.
  • the master SCC AS determines whether the initiator UE belongs to the joint session and performs different processing methods.
  • the master UE may also initiate the pull mode according to the joint session.
  • the media transfer request method to perform media transfer. The technical solution of this embodiment ensures the reliability of media transfer between UEs.
  • FIG. 4 is a signaling flowchart of a media transfer method between user equipments according to Embodiment 4 of the present invention.
  • This embodiment may follow the case of the second embodiment, but the difference from the second embodiment is that the initiator UE may or may not belong to the current joint session.
  • the referral message is used as the pull mode media transfer request.
  • the initiator UE, the target UE, and the master UE belong to different subscriptions and belong to different SCC ASs.
  • the initiator UE discovers the session and media information of other UEs through the session discovery process, and transfers the target UE—one or more media to itself according to the obtained target UE session information, where the target UE is the controlled UE of the joint session.
  • Step 401 The initiator UE initiates a transfer message to transfer the media on the target UE to the host.
  • the transfer message includes at least an initiator UE identifier, a target UE identifier, and session identifier information between the target UE and the target SCC AS, and The media to be transferred; wherein the media to be transferred is one or more media on the target UE.
  • the above information can be indicated by using multiple header fields and message bodies of the transfer message.
  • the specific header fields are described below:
  • the refer-to header field because the media needs to be transferred to the initiator UE, the transfer target header record initiator UE indicates, that is, the identity information of the initiator UE itself (which may include the global routable user agent identifier ( Globally Routable User Agent URI, referred to as GRUU)).
  • the type of media that the originator UE wants to transfer can be included in the transfer target header field as the type of media that needs to be established on its own. For example, "Refer-to: ⁇ target- URI; GRUU; audio; video; >", "audio", "video” means to establish audio and video media on the UE indicated by the transfer destination header field.
  • the media type may be carried by the message body, such as carrying the SDP information in the forwarding target header field or carrying the XML message body in the invitation message to indicate the media to be transferred.
  • the method item in the transfer target header field can be set to "invite" 0
  • the target-dialog header field is used to record the session identifier information of the target UE where the media to be transferred is located, which is equivalent to the function of adding the header field to the invitation message.
  • the initiator UE may indicate the transfer to the master SCC AS and join the joint session.
  • the initiator UE embodies this information by enhancing the transfer destination header field of the transfer message.
  • the capability information or feature information of the target UE may be carried. For example, according to "RFC3840", the following settings may be made:
  • the target header field and the source header field, the source domain is the identity information of the initiator UE, for example, "From: originator UE URI", and the target header field is identity information of the target UE, for example, "To: Controlled UE URI”.
  • the parameters of the target header field and the identifier request header field are the same, they have different identification functions when they are recognized and recognized.
  • a uniform resource identification request (request-URI) header field indicating the destination to which the transfer message is sent.
  • the destination address is the target UE identity.
  • the transfer message may be identified as a pull mode media transfer request by using multiple parameter items, for example, by using the same value of the source field and the transfer target header field to identify the pull mode media transfer request, or by subject (subject)
  • the header field such as "subject: pull-media", identifies the pull mode media transfer request. If the transfer message contains a message body, you can pass
  • Step 402 The transfer message is sent to the SCC AS to which the initiator UE belongs by using the S-CSCF, and the initiator SCC AS determines that the transfer message is a pull mode requesting media transfer, and may first verify whether the initiator UE can issue a pull mode media transfer. The request, if possible, continues with the subsequent steps, if the initiator UE is not allowed to issue a pull mode media transfer request, a "4** response message" is returned for the transfer message.
  • the SCC AS that has received the transfer message determines that the local device is the destination of the transfer message according to the destination address in the transfer message. If yes, the request is a pull mode media transfer request, so the transmission to the target UE is terminated, and step 404 is continued. Otherwise, the pull mode media transfer request is continued according to the destination address, and step 403 is performed.
  • Step 403 Similar to step 402, the target SCC AS to which the target UE belongs receives the transfer message.
  • Step 404 When the target SCC AS recognizes that the transfer message is a pull mode media transfer request, it terminates the sending of the transfer message to the target UE, and the target SCC AS forwards the session identification information in the target session header of the transfer message and saves The joint session information determines whether the local device is the master SCC AS of the joint session where the media to be transferred is located, and if so, the target SCC AS can perform the media transfer operation as the master UE, and if not, execute step 405;
  • the target SCC AS determines that the received transfer message is a pull mode media transfer request, and may also authenticate to the target UE whether to allow the initiator UE to initiate a pull mode media transfer request to the target UE before performing the subsequent decision logic.
  • Step 405 The target SCC AS converts the session identification information included in the transfer message into session identification information between the target SCC AS and the master SCC AS, and forwards the transfer message to the master SCC AS (redi rec t: refer ) In order to host the SCC AS to perform media transfer according to the invitation message.
  • the target SCC AS forwards the converted transfer message to the master SCC AS.
  • the session identifier information of the target session header field may be replaced with the session identifier information between the target SCC AS and the master SCC AS, so that the master SCC AS finds a matching session according to the target session header field, and The media transfer operation is performed according to the initiator UE and the target UE identity.
  • the target UE UR I of the uniform resource identifier request header field is replaced by the primary control SCC AS PSI, and the source domain and the target header field are kept unchanged, and Copy other header fields and message bodies.
  • the master SCC AS PSI is similar to the master UE identifier and is used to identify an entity.
  • Step 406 - 418 the master SCC AS receives the transfer message, parses the target session header field in the transfer message, and determines, according to the joint session information saved by the local machine, that the local machine is the master SCC AS in the joint session to which the target session belongs,
  • the master SCC AS transfers the to-be-transferred media from the target UE to the initiator UE according to the target UE identifier, the initiator UE identifier, and the converted session identifier information in the pull mode media transfer request.
  • the specific process is as follows:
  • Step 406 The master SCC AS may send a transfer authentication request to the master UE, so that the master UE may perform the pull mode media transfer request by the master UE, and when the master UE allows the pull mode transfer request to be initiated,
  • the pull mode media transfer request returns an accept response message, such as a "202 accept" response message, and if the master UE does not allow it to initiate a pull mode transfer request, a failure response is returned, such as a 4** failure response message, which is considered here.
  • the master UE allows the initiator UE to initiate a pull mode media transfer request;
  • Step 407--409 controller SCC AS receiving the pull mode media transfer request, the transfer return accept response (2 Q2 accept) to the initiator UE 0
  • Step 410 The master SCC AS determines, according to the initiator UE identifier in the source field of the transfer message and the session identifier information in the target session header field, and the joint session information saved by the local device, whether the initiator UE belongs to the current joint session, and if not, Step 411 is performed. If yes, the media is added to the original access branch corresponding to the initiator UE in the current joint session, and the media transfer process is completed.
  • Step 411 The master SCC AS sends an invite message to the initiator UE according to the media type to be transferred indicated in the pull mode media transfer request, to establish a new session between the initiator UE and the master SCC AS, in the new session. Establish transfer media;
  • the SDP message body of the invite message carries the corresponding media peer port number and media description information saved by the master SCC AS.
  • the master SCC AS may carry the notification information in the invite message to indicate that the initiator SCC AS belongs to the current joint session, and the corresponding initiator UE is the controlled UE, and the initiator SCC AS is subject to Control SCC AS.
  • the notification information may also include main information of the joint session: such as the address or identity information of the master UE and the master SCC AS.
  • the above information may be carried by the XML message body of the invitation message, the initiator SCC AS identifies the invitation message, and saves the message body content information of the invitation message, deletes the message body, and continues the invitation message. Sent to the initiator UE.
  • Step 412 The initiator UE returns a 200 ok response message via the initiator SCC AS.
  • Steps 413 ⁇ 414 the master SCC AS sends a re-invitation message to the peer end, updates the peer connection, and the peer returns a 200 ok response message;
  • Step 415 The master SCC AS returns an acknowledgement message ACK of the 200 ok response message to the initiator UE via the initiator SCC AS.
  • Step 416 The master SCC AS returns an acknowledgement message ACK to the peer end, and completes the media negotiation process between the initiator UE and the peer end.
  • Step 417 The master SCC AS updates the media information of the original UE where the transfer media is located, and releases the media transferred to the initiator UE from the target UE.
  • Step 418 The master SCC AS updates the joint session information held by the master UE, and the UE to be transferred by the media is changed from the target UE to the initiator UE.
  • the process is similar to the foregoing process, and the transfer request may be directly sent to the master SCC AS via its SCC AS.
  • the process of transferring the media to the other controlled UEs in the joint session is similar to the foregoing process, and the difference is also that the signaling connection existing by the initiator UE is in step 410.
  • the media is established to the initiator UE by the re-invitation message, and does not have to carry an XML message body indicating that the initiator SCC AS is the controlled SCC AS.
  • This embodiment provides a method for the initiator UE to request a media transfer from the controlled UE in the joint session by using the transfer message, and the initiator UE may or may not belong to the joint session.
  • the controlled SCC AS After receiving the transfer message, the controlled SCC AS sends it to the master SCC AS of the joint session, and the master SCC AS performs the media transfer process.
  • the technical solution of this embodiment ensures the reliability of media transfer between UEs.
  • the fifth embodiment of the present invention provides a method for a user equipment to implement media transfer, which is specifically a method performed by an initiator UE, and includes the following steps:
  • the initiator UE initiates a pull mode media transfer request to the target UE, where the pull mode media transfer request includes session identifier information, where the session identifier information is used to identify the session where the media to be transferred is located on the target UE, and the session identifier information is used as the target SCC.
  • the session where the media to be transferred is located is a joint session, and the local machine is determined to be the joint session of the media to be transferred.
  • the pull mode media transfer request is forwarded to the master SCC AS of the joint session, so that the master SCC AS performs media transfer, where the target SCC AS is the SCC AS to which the target UE belongs, and the master control
  • the SCC AS is the SCC AS to which the master UE of the joint session belongs.
  • the UE may use different messages as pull mode media transfer requests.
  • One way is that the initiator UE uses the invite message as the pull mode media transfer request, and the pull mode of the media transfer request is indicated by the message header in the invitation message.
  • the other way is that the initiator UE adopts the transfer message as the pull mode media transfer request, and uses the header field in the transfer message to indicate that the initiator UE completes the pull mode media transfer and joins the current joint session.
  • Specific application examples can be referred to in the foregoing embodiments.
  • the method provided in this embodiment can cooperate with the method performed by the SCC AS provided by the present invention to implement an inter-UE media transfer operation.
  • FIG. 5 is a schematic structural diagram of a continuity application server according to Embodiment 6 of the present invention, which specifically includes: a receiving module 51 0 and a forwarding module 520.
  • the receiving module 510 is configured to receive a pull mode media transfer request initiated by the initiator UE to the target UE, where the pull mode media transfer request includes session identifier information, where the session identifier information is used to identify the to-be-transferred media of the target UE.
  • the forwarding module 520 is configured to forward the pull mode media transfer request to the federation when the session in which the media to be transferred is located is a joint session and the local identity is the controlled SCC AS of the joint session in which the media to be transferred is located according to the session identification information.
  • the master of the session is the SCC AS, so that the master SCC AS performs media transfer, where the master SCC AS is the SCC AS to which the master UE of the joint session belongs.
  • the SCC AS may further include a conversion module 530, configured to convert the session identification information included in the pull mode media transfer request to the local device and the main device when determining that the local device is not the master SCC AS of the joint session where the media to be transferred is located. Control session identification information between SCC ASs.
  • Pull mode media transfer requests can be implemented using a variety of messages.
  • the forwarding module specifically includes: a redirecting unit, configured to redirect the invite message to the master SCC AS when determining that the initiator UE does not belong to the local machine.
  • the method further includes a transfer control module 540, configured to determine, according to the pull mode media transfer request, that the local machine is the master SCC AS of the joint session where the media to be transferred is located, according to Pull mode media transfer request for media transfer.
  • a transfer control module 540 configured to determine, according to the pull mode media transfer request, that the local machine is the master SCC AS of the joint session where the media to be transferred is located, according to Pull mode media transfer request for media transfer.
  • the transfer control module 540 may specifically include: a first transfer control unit 541 and/or a second conversion Control unit 542.
  • the first transfer control unit 541 is configured to create a new session to the initiator UE, and establish a to-be-transferred media in the newly created session.
  • the second transition control unit 542 is configured to: when determining that the initiator UE is in the current joint session, in the initiator UE. Add the media to be transferred in the original access branch in the current joint session.
  • the notification module 550 may be further included, and is connected to the first transition control unit 541, and configured to send a notification message to the initiator SCC AS to notify the newly-created session that the current joint session belongs to the initiator UE.
  • the embodiment of the present invention further provides a user equipment, including a request initiation module, configured to initiate a pull mode media transfer request to a target UE, where the pull mode media transfer request includes session identifier information, and the session identifier information is used to identify the target UE to be camped on.
  • the session identifier information is used when the target SCC AS receives the pull mode media transfer request, and the session in which the media to be transferred is located is a joint session, and the local machine is determined to be the controlled SCC of the joint session where the media to be transferred is located.
  • the pull mode media transfer request is forwarded to the master SCC AS of the joint session, so that the master SCC AS performs media transfer, where the target SCC AS is the SCC AS to which the target UE belongs, and the master SCC AS is federated.
  • the embodiment of the invention further provides a media transfer system between user equipments, including: a target SCC AS and a master SCC AS.
  • the target SCC AS is configured to receive a pull mode media transfer request initiated by the initiator UE to the target UE, where the target SCC AS is the SCC AS to which the target UE belongs, and the pull mode media transfer request includes the session identifier information, and the session identifier information is used.
  • the session in which the media to be transferred is located on the target UE is identified, and when the session in which the media to be transferred is located is a joint session, and the target SCC AS determines that the local device is the controlled SCC AS of the joint session in which the media to be transferred is located according to the session identification information,
  • the pull mode media transfer request is forwarded to the master SCC AS of the joint session;
  • the master SCC AS is configured to perform media when determining that the local device is the master SCC AS of the joint session where the media to be transferred is located according to the session identifier information of the session where the media to be transferred is indicated in the received pull mode media transfer request. Transfer.
  • the user equipment, the continuity application server, and the system provided by the embodiments of the present invention may perform the media transfer method between user equipments provided by the embodiments of the present invention, and have corresponding functional modules.
  • the technical solution of the embodiment of the present invention solves the problem that the target controlled UE and the master UE do not belong to the prior art.
  • the initiator UE cannot request the transfer of media from the controlled UE of the joint session.
  • the master SCC AS involved in the embodiment of the present invention includes, but is not limited to, at least one of the following:
  • the foregoing storage medium includes: a medium that can store a program code, such as a ROM, a RAM, a magnetic disk, or an optical disk.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)

Description

用户设备间媒体转移方法和应用服务器 本申请要求于 2010年 2月 11 日提交中国专利局、 申请号为 201010111665.1 发明名称为"用户设备间媒体转移方法和应用服务器 "的中国专利申请的 优先权， 其全部内容通过引用结合在本申请中。 技术领域
本发明实施例涉及通信技术， 尤其涉及一种用户设备间媒体转移方法和 应用服务器。 背景技术
基于 IP的多媒体子系统（IP Multimedia Subsystem, 简称 IMS)是基 于 IP的多媒体业务通信网络。 IMS网络采用 IMS核心网子系统（ IP Multimedia Core Network Subsystem)进行业务控制， 分组交换网络或电路交换网络作 为接入网络为信令和媒体传输提供承载， 从而将业务控制和承载分离， 为 IP 多媒体应用提供了统一和灵活的支持平台。
当 IMS用户在不同接入网络之间移动时， 为了确保良好的用户体验， 要 求不中断当前正在进行的 IMS 会话， 即保持 IMS 会话连续性 （Session Continuity, 简称 SC)。 类似地， 当用户将正在进行的 IMS会话的部分或全 部媒体流由一个用户设备 (User Equipment, 简称 UE )转移到另一个 UE时， 为了提供良好的用户体验， 要求会话媒体流在此转移过程中也保持连续、 不 中断。 实现 IMS 会话的部分或全部媒体流在不同 UE 之间转移（Inter-UE Transfer, 简称 IUT)过程中的业务连续性即是 IMS会话连续性的一部分。
会话某一端可以包含一个或多个 UE, —端由多个 UE参予并与同一对端 UE进行通信时，此多个 UE中的会话组成联合会话。在联合会话的多个 UE中， 可以有一个或多个主控 UE ( controller UE )， 以及一个或多个受控 UE ( control lee UE )， 主控 UE可以控制联合会话中的各 UE及其上的媒体流。 在联合会话中， 可以将媒体流从一个 UE转移至另一个 UE， 或者转移至联合 会话外的 UE , 转移完成后该 UE加入联合会话。
业务集中与连续性应用 务器 （ Service Centralization and Continuity Application Server, 简称 SCC AS)是 IMS会话连续性系统中 的关键功能实体，通过服务型呼叫会话控制功能实体（Serving Call Session Control Function, 筒称 S- CSCF)与 IMS用户交互， 执行核心的 SC业务 ΐ£ 辑控制。 为简化描述起见， 本文将业务集中与连续性应用服务器简称为连续 性应用服务器。 IMS用户在向 IMS域注册的过程时，还会向该 UE所归属的 SCC AS进行第三方注册， 而不同签约的 IMS用户可能归属于不同 SCC AS。
在联合会话中， 各 UE可以通过其所归属的 SCC AS而呈现出多个接入分 支（ access leg )， 多个接入分支锚定在主控 UE的 SCC AS并向对端呈现一个 对端分支（ remote leg )。 为描述清楚起见， 将主控 UE所归属的 SCC AS称为 主控 SCC AS, 将受控 UE所归属的 SCC AS称为受控 SCC AS。 主控 SCC AS保 存着联合会话中各 UE及其上媒体相关信息。 UE通过发送请求将其他 UE上的 媒体转移到自身的媒体转移方式称为 "pull mode", 即拉方式， 发出请求的 UE可以是联合会话中的受控 UE， 也可以是联合会话外的 UE。
在 UE的会话发现（ session discovery ) 阶段， 若某个被发现的目标 UE 是联合会话的受控 UE,且受控 UE与主控 UE为不同签约下的 UE,并归属于不 同的 SCC AS, 当拉方式媒体转移请求发送到目标 UE归属的 SCC AS后， 由于 受控 SCC AS不具备媒体转移权利， 所以无法完成媒体转移操作。 由此可知， 现有技术对于 UE间媒体转移操作的限制很大， 无法可靠地保证会话连续性。 发明内容
本发明实施例提供一种用户设备间媒体转移方法和应用服务器， 以在归 属于不同业务集中与连续性应用服务器的用户设备间实现媒体转移， 保证会 话连续性。
一方面， 提供了一种用户设备间媒体转移方法， 包括：
目标连续性应用服务器接收发起者用户设备向目标用户设备发起的拉方 式媒体转移请求， 其中， 所述目标连续性应用服务器为所述目标用户设备所 归属的连续性应用服务器， 所述拉方式媒体转移请求中包含会话标识信息， 所述会话标识信息用于标识所述目标用户设备上待转移媒体所在的会话； 当所述待转移媒体所在的会话为联合会话， 且所述目标连续性应用服务 器根据所述会话标识信息判断本机是待转移媒体所在联合会话的受控连续性 应用服务器时， 则将所述拉方式媒体转移请求转发至所述联合会话的主控连 续性应用服务器， 以使得所述主控连续性应用服务器进行媒体转移， 其中， 所述主控连续性应用服务器为所述联合会话的主控用户设备所归属的连续性 应用服务器。
另一方面， 提供了一种连续性应用服务器， 包括：
接收模块， 用于接收发起者用户设备向目标用户设备发起的拉方式媒体 转移请求， 其中， 所述拉方式媒体转移请求中包含会话标识信息， 所述会话 标识信息用于标识所述目标用户设备上待转移媒体所在的会话；
转发模块， 用于当所述待转移媒体所在的会话为联合会话， 且根据所述 会话标识信息判断本机是待转移媒体所在联合会话的受控连续性应用服务器 时， 则将所述拉方式媒体转移请求转发至所述联合会话的主控连续性应用服 务器， 以使得所述主控连续性应用服务器进行媒体转移， 其中， 所述主控连 续性应用服务器为所述联合会话的主控用户设备所归属的连续性应用服务 器。
采用本发明实施例的技术方案， 目标连续性应用服务器若不是主控连续 性应用服务器， 则可以将拉方式媒体转移请求转发至主控连续性应用服务器， 以使得由主控连续性应用服务器执行媒体转移操作， 对于媒体转移操作中各 连续性应用服务器为相同网元时， 本实施例的操作方案也可以适用且更为简 化。 因此， 本实施例可以适用于媒体转移操作出现的各种情况， 可靠的进行 媒体转移操作， 保证了会话连续性。 附图说明
图 1为本发明实施例一提供的用户设备间媒体转移方法的流程图； 图 1为本发明实施例二提供的用户设备间媒体转移方法的信令流程图； 图 3为本发明实施例三提供的用户设备间媒体转移方法的信令流程图 图 4为本发明实施例四提供的用户设备间媒体转移方法的信令流程图； 图 5为本发明实施例六提供的连续性应用服务器的结构示意图。 具体实施方式
为使本发明实施例的目的、 技术方案和优点更加清楚， 下面将结合本发 明实施例中的附图， 对本发明实施例中的技术方案进行清楚、 完整地描述， 显然， 所描述的实施例是本发明一部分实施例， 而不是全部的实施例。 基于 本发明中的实施例， 本领域普通技术人员在没有做出创造性劳动前提下所获 得的所有其他实施例， 都属于本发明保护的范围。
在 IMS网络所实现的会话中，主要特征之一是在 IUT过程中除了主控 UE 可以主动将媒体转移到受控 UE,受控 UE也可以将联合会话中主控 UE或其他 受控 UE上的媒体转移到自身， 或不在联合会话的 UE发起拉方式媒体转移请 求，将联合会话中的媒体转移到自身并加入联合会话，从而增强了 IUT功能。 会话连续性课题在 REL10阶段允许向不同签约 UE转移媒体， 在 UE发现过程 允许发现属于不同签约的 UE信息及其上的会话信息，同理对于拉方式媒体转 移，允许属于同一签约的 UE发起拉方式媒体转移请求，也允许属于不同签约 的 UE发起拉方式媒体转移请求，这里的同一签约是指发起拉方式媒体转移请 求的 UE与媒体所在的目标 UE属于同一签约。
在会话发现阶段， 若被发现的目标 UE是联合会话的受控 UE , 所获得的 会话信息仅是目标 UE上的会话信息而不包含目标 UE所在联合会话中的信息。 针对现有技术的已有情况，无论发起媒体转移的 UE是否在联合会话中，无论 是向主控 UE还是受控 UE发起拉方式媒体转移请求， 且无论发起者 UE > 受控 UE和主控 UE是否归属于同一 SCC AS， 本发明实施例的技术方案皆可实现拉 方式媒体转移， 保证会话连续性。
实施例一
图 1为本发明实施例一提供的用户设备间媒体转移方法的流程图， 为描 述清楚起见， 进行如下命名定义： 联合会话中的主控 UE所归属的 SCC AS称 为主控 SCC AS; 受控 UE所归属的 SCC AS称为受控 SCC AS; 发起拉方式媒体 转移操作的 UE称为发起者 UE;发起者 UE所归属的 SCC AS称为发起者 SCC AS; 被转移的媒体所在的原 UE称为目标 UE, 目标 UE所归属的 SCC AS称为目标 SCC AS。 上述的命名是从不同角度对 UE和 SCC AS进行的区分， 实际应用中， 发起者 UE也可能是联合会话中的受控 UE， 发起者 SCC AS、 目标 SCC AS和主 控 SCC AS也可能是同一 SCC AS。 不同的 UE可能属于同一签约， 归属于同一 SCC AS , 也可能属于不同签约并归属于不同 SCC AS。 在请求执行媒体转移之前，首先是发起者 UE在会话发现过程中发现目标 UE上的会话信息，所发现的目标 UE可能是联合会话的主控 UE也可能是联合 会话的受控 UE。 所发现的会话信息包括被发现的目标 UE所参与的各会话的 会话标识信息（ ses s i on_ID )和媒体类型等。发起者 UE根据以上信息确定将 其中一个或多个媒体转移到自身。
本实施例的 UE间媒体转移方法具体包括如下步骤：
步骤 100、 目标 SCC AS接收发起者 UE向目标 UE发起的拉方式媒体转移 请求， 目标 SCC AS终止将拉方式媒体转移请求发送至目标 UE;
在步骤 100中， 目标 SCC AS为目标 UE所归属的 SCC AS , 该拉方式媒体 转移请求中包含会话标识信息，该会话标识信息用于标识目标 UE上待转移媒 体所在的会话， 具体为目标 UE与目标 SCC AS之间会话的会话标识信息。 在 该拉方式媒体转移请求中还可以包括其他信息， 例如发起者 UE 标识和目标 UE标识等；
在 IMS网络中， 拉方式媒体转移请求可以经发起者 UE所属的 S_CSCF， 通过初始过滤准则 （ Ini t i a l F i l t er Cr i ter i a , 简称 iFC )发送到发起者 UE 所归属的发起者 SCC AS。 UE与 SCC AS之间所传送消息需经过的中间网元本 文将不再赘述。
在步骤 1 00中， 目标 SCC AS接收来自发起者 UE的拉方式媒体转移请求具 体包括： 接收到拉方式媒体转移请求的 SCC AS根据媒体转移请求中的目标 UE标识判断目标 UE是否归属于本机， 若是， 则确定本机为目标 SCC AS , 继 续执行后续步骤 2 00， 若否， 则根据目标 UE标识发送拉方式媒体转移请求， 直至目标 SCC AS接收到来自发起者 UE的拉方式媒体转移请求。 即， 拉方式 媒体转移请求是基于目标 UE标识， 可经多跳转发至目标 SCC AS的。 由于该 请求是拉方式的媒体转移请求， 所以其到达目标 SCC AS之后终止， 由 SCC AS 执行媒体转移操作， 从而无须向目标 UE发送。
步骤 200、 当该待转移媒体所在的会话为联合会话， 且目标 SCC AS根据 会话标识信息判断本机是待转移媒体所在联合会话的受控 SCC AS时，则将拉 方式媒体转移请求转发至该联合会话的主控 SCC AS , 以使得主控 SCC AS进 行媒体转移， 其中， 主控 SCC AS为该联合会话的主控 UE所归属的 SCC AS。 具体应用中，各 SCC AS可以根据拉方式媒体转移请求中的会话标识信息 以及本机保存的联合会话信息判断本机是否为主控 SCC AS。
当目标 SCC AS判断出本机是主控 SCC AS时， 则目标 SCC AS作为主控 SCC AS可以直接进行媒体转移操作， 这也是主控 UE作为目标 UE， 或目标 UE 和主控 UE归属于同一 SCC AS的简单情况。
在目标 SCC AS将拉方式媒体转移请求转发至主控 SCC AS的过程中， 还 可以进一步将拉方式媒体转移请求中所包含的目标 UE与目标 SCC AS之间的 会话标识信息， 转换为目标 SCC AS与主控 SCC AS之间的会话标识信息。
在步骤 200中， 目标 SCC AS是一个受控 SCC AS , 需要进行会话标识信 息的转换。 改变会话标识信息的原因在于： 受控 SCC AS在受控 UE建立媒体 时作为背靠背用户代理 ( back t o back User Agent , 简称 B2BUA ), 将信令 发送到主控 SCC AS , 因此在该受控 UE的接入分支中， 受控 UE与受控 SCC AS 间的会话与受控 SCC AS与主控 SCC AS间的会话具有不同的会话标识， 导致 有不同的会话标识信息。 原始拉方式媒体转移请求中的会话标识信息为受控 UE与受控 SCC AS间的会话标识， 主控 SCC AS无法匹配到， 所以需要进行转 换， 使得主控 SCC AS根据受控 SCC AS与主控 SCC AS之间的会话标识信息匹 配到待转移媒体所在的会话。
目标 SCC AS向主控 SCC AS转发拉方式媒体转移请求的方式有多种， 例 如： 包括重定向和直接发送的方式。
可以采用邀奇 ( inv i te ) 消息作为拉方式媒体转移请求， 该拉方式通过 邀请消息中的消息头指示。 消息头具体可以采用内容部署或主题消息头。
当拉方式媒体转移请求采用邀请消息时，转发操作具体可以为： 目标 SCC AS根据邀请消息中的发起者 UE标识判断发起者 UE是否归属于本机；
若否， 则将邀请消息重定向至主控 SCC AS。 具体的， 目标 SCC AS可以 向发起者 UE发送的邀诸消息返回重定向消息，以将邀请消息直接发送到主控 SCC AS , 并在重定向消息中携带目标 SCC AS与主控 SCC AS间的会话标识信 息， 以使得发起者 SCC AS更新邀请消息中的会话标识信息， 更新为目标 SCC AS与主控 SCC AS间的会话标识信息，并将该邀请消息直接发送至主控 SCC AS。
若是， 则直接将邀请消息向主控 SCC AS发送。 实际应用中， 即使发起者 SCC AS和目标 SCC AS不是同一个 SCC AS , 也可以不进行重定向， 而由目标 SCC AS直接将拉方式媒体转移请求转发至主控 SCC AS。 实际应用中采用重定向， 由发起者 UE向主控 SCC AS发送拉方式媒体转移请求的手段， 其优点是在后续 所执行的信令流程中， 可以减少目标 SCC AS作为中间节点的转发过程。
拉方式媒体转移请求还可以采用转移（refer )消息， 转移消息中采用消 息的头域指示发起者 UE完成拉方式媒体转移后加入当前联合会话。 该头域可 以为转移目标（refer-to ) 头域， 其中携带表示加入当前联合会话的信息。 在该方式下， 转发操作可以是目标 SCC AS直接将转移消息向主控 SCC AS发送， 同时， 将转移消息中原有的会话标识信息更新为目标 SCC AS与主控 SCC AS间 的会话标识信息。
目标 SCC AS向主控 SCC AS转发拉方式媒体转移请求的方式包括但不限于 为上述两种。
当拉方式媒体转移请求发送至主控 SCC AS之后， 主控 SCC AS根据拉方式 媒体转移请求中的目标 UE标识、 发起者 UE标识和转换后的会话标识信息将待 转移媒体从目标 UE转移至发起者 UE的步骤具体可以包括：
主控 SCC AS判断发起者 UE是否在当前联合会话中， 若否， 则向发起者 UE 新建会话， 在新建的会话中建立待转移媒体， 并更新对端， 幹放目标 UE上的 媒体， 从而将待转移媒体转移至发起者 UE; 若是， 则可以向发起者 UE新建会 话， 在新建的会话中建立待转移媒体， 或者可以在当前联合会话中发起者 UE 对应的原接入分支中增加待转移媒体， 并更新对端， 释放目标 UE上的媒体， 从而完成媒体转移操作。
无论发起者 UE是否在当前联合会话中， 主控 SCC AS通过新建会话进行 媒体转移操作的过程中， 还可以进一步包括： 主控 SCC AS向发起者 SCC AS 发送通知消息， 以通知发起者 SCC AS 新建会话属于当前联合会话、 发起者 UE为该联合会话的受控 UE、联合会话的主控 UE的信息和 /或联合会话的主控 SCC AS的信息， 例如主控 UE和主控 SCC AS的地址信息和身份信息等以便发 起者 UE和发起者 SCC AS各自获知自身在联合会话中的身份信息， 易于其他 操作的执行。
IMS网络中一般采用会话发起协议（Ses s ion Ini t i a t ion Protoco l , 简 称 SIP)信令作为呼叫控制信令。 本发明实施例可以基于已有的信令消息来 实现 UE间媒体转移方法， 下面通过各实施例分别进行描述。
实施例二
图 2为本发明实施例二提供的用户设备间媒体转移方法的信令流程图。 本实施例具体采用邀请 ( invite) 消息作为拉方式媒体转移请求， 所适用的 情况具体为联合会话中的主控 UE和受控 UE归属于不同的 SCC AS, 由不属于 联合会话的发起者 UE向联合会话的受控 UE请求转移媒体，且发起者 UE与主 控 UE和受控 UE分别属于不同签约， 归属于不同的 SCC AS。 发起者 UE通过 会话发现过程获取到目标 UE上的会话及媒体信息。
邀请消息是 SIP信令的一种， 包括多个头域和消息体。 本实施例基于该 邀请消息所执行的方法包括如下步骤：
步骤 201、 发起者 UE发起邀请消息以建立会话， 并在邀请消息中携带拉方 式媒体转移指示。
该邀请消息中至少包括发起者 UE标识、 目标 UE标识、 以及目标 UE与目标 SCC AS之间的会话标识信息。 该邀请消息实际上首先被发送至发起者 SCC AS, 由网络侧根据目的地址进行路由转发。 在本实施例中邀请消息的目的地址是 目标 UE标识。
邀请消息可以利用其头域和消息体来携带信息， 例如： 会话描述协议 (Session Description Protocol, 简称 SDP)消息体、 内容部署或主题头 i或、 加入头域、 统一资源标识请求 ( request Uniform Resource Identifier, 简 request-URI ) 头域、 目标头域和源头域。
1 ) SDP消息体的媒体行指示在其自身所要建立的媒体， 即待转移媒体的 类型；
2 ) 内容部署或主题 ( content- di spos i t ion/sub ject： pull- media ) 头 域， 通过消息头内容部署或主题头域来指示该邀请消息为拉方式的媒体转移 清求；
3 )加入 ( Join )头域， 可以利用加入头域来指示待转移媒体所在目标 UE 上的会话信息， 也表示发起者 UE在完成媒体转移后加入该联合会话， 以区别 于转移媒体后新建 IMS会话的情况。 为表达上述信息， 加入头域具体可以为在 会话发现阶段获取到的目标 UE上的会话标识信息， 本实施例中具体为受控 UE 与受控 SCC AS间会话的会话标识信息。 会话标识信息可以由会话标识、 会话 源端标识和会话对端标识组成， 例如具体形式可以为 "Jo in:
7Sc. examp le, org; t o-t ag=xyz; f rom_t ag=pdq"。
4 )统一资源标识请求（ reque s t-URI ) 头域， 又可称为标识请求头域， 指示该邀请消息所发送的目的地。 在发起拉方式媒体转移请求时， 目的地址 是目标 UE标识。 各个 UE标识可以但不限于釆用 UE的 URI来进行标识。
5 ) 目标头域和源头域， 源头域中为发起者 UE的身份信息， 例如， "From: 发起者 UE URI " , 目标头域为目标 UE的身份信息， 例如 "To: 受控 UE URI "。 目标头域和标识请求头域的参数虽然一致， 但是其在被解析识别时具备不同 的标识功能。
步骤 202、 接收到邀请消息的 SCC AS根据邀请消息中的目的地址判断本机 是否为目的地址所指向 UE归属的 SCC AS , 若是， 则继续执行步骤 2 G4， 若否， 则根据目的地址继续发送邀请消息， 并执行步骤 203。
本实施例中的邀请消息首先被发送至发起者 SCC AS， 由于假设发起者 SCC AS和目标 SCC AS为不同的 SCC AS , 所以本次发起者 SCC AS的判断结杲为否， 继续转发该邀请消息。
在步骤 202中， 接收到邀请消息的 SCC AS可以首先根据邀请消息内容部署 或主题头域来识别出该邀请消息为拉方式媒体转移请求。 本步骤在识別到邀 请消息为拉方式媒体转移请求后， 还可以由发起者 SCC AS进一步验证发起者 UE是否具有发起拉方式媒体转移请求的权利，若是，则继续执行后续步骤 203， 否则向发起者 UE返回错误响应， 例如 4 **响应消息， 用于终止邀请消息。
步骤 203、 接收到邀请消息的 SCC AS根据邀请消息中的目的地址判断本机 是否为发送目的地址所指向 UE归属的 SCC AS , 与步珮 202的操作一致， 若是， 则继续执行后续步骤 204 ; 若否， 则根据目的地址发送邀请消息， 直至目的地 址所指向 UE归属的 SCC AS接收到来自发起者 UE的邀请消息， 本实施例即发送 至目标 SCC AS。
步骤 204、 邀请消息发送至目标 UE所归属的目标 SCC AS , 目标 SCC AS根据 邀请消息内容部署或主题头域识别出该邀清消息为拉方式媒体转移请求时， 即终止将该请求向目标 UE发送。 进一步的， 目标 SCC AS在进行后续判断逻辑 之前， 也可以向目标 UE认证是否允许发起者 UE向目标 UE发起拉方式媒体转移 请求。
接收到邀请消息的目标 SCC AS判断本机是否为待转移媒体所在联合会话 的主控 SCC AS, 若是， 则该 SCC AS可以作为主控 UE执行媒体转移， 若否， 则 执行步骤 205。
在本实施例中，由于目标 UE是受控 UE，所以邀请消息被发送至受控 SCC AS , 因此步骤 204中的目标 SCC AS作为受控 SCC AS , 且受控 SCC AS和主控 SCC AS为 不同的 SCC AS, 所以判断结果为否， 继续执行步驟 205。
步骤 204中 SCC AS判断本机是否为联合会话的主控 SCC AS具体可以依据邀 请消息中包含的会话标识信息以及本机保存的联合会话信息进行判断。
步骤 205、 目标 SCC AS根据邀请消息中的发起者 UE标识判断发起者 UE是否 归属于本机， 若否， 则返回重定向消息， 以指示接收到重定向消息的发起者 SCC AS根据重定向消息更新邀请消息中的会话标识信息， 并将更新后的邀请 消息向主控 SCC AS发送， 若是， 则目标 SCC AS将邀诸消息中的会话标识信息 进行更新， 并将已更新的邀请消息直接向主控 SCC AS发送。
本实施例中由于发起者 SCC AS和目标 SCC AS不是同一个 SCC AS , 所以步 骤 205实际上执行重定向的操作， 将转换后的会话标识信息携带在重定向消息 中发送。
邀请消息中的会话标识信息需要更新的原因在于： 邀请消息加入头域中 的会话标识信息为受控 UE与受控 SCC AS间的会话标识， 为使主控 SCC AS可以 找到与该会话标识匹配的会话， 需要将加入头域中的会话标识信息更新为受 控 SCC AS与主控 SCC AS之间会话的会话标识信息。
步骤 205中， 对会话标识信息进行转换处理， 而后将其携带在重定向消息 中的具体操作如下：
重定向消息可以采用 302重定向响应消息（ 302 ( redi rect ) )来实现。 302 重定向响应消息中的交互地址（contact ) 头域具体为受控 SCC AS保存的该联 合会话主控 SCC AS的公共业务标识 （Pub l i c Serv i ce Ident i ty , 简称 PS I )， 用于表示重定向的目的地址， 指示收到该重定向消息的发起者 SCC AS将原邀 请消息发送到交互地址头域所指定的地址， 即联合会话的主控 SCC AS。
由于加入头域不允许在回复消息中携带， 因此在 302重定向响应消息中通 过可扩展标记语言 (Extensible Markup Language, 筒称 XML) 消息体来携带 转换后的会话标识信息。 XML消息体的具体形式如下：
1 )用 application/dialog- info+xml格式消息体
Content-Type: ap l i cat i on/dialog- info+xml
Content-Disposition: Join-session //表示消息体的内容
<?xml version="l.0"?>
<dialog— info xmlns = "urn: ietf : pa rams: xml: ns: dialog-info" version="l"
state="fuH"
ent i ty=" sip: sccas2Sexample. com">
<dialog id="as7d900as8" cal l-id="a84b4c76e66710"
local- g=" 1928301774" remote-tag="456887766,,> 〃该项表示加入会话的会话标识信息 <state>conf irmed</s tate>
</dialog>
</dialog-info>
2)为加入会话 ( Join session)新定义 xml格式消息体
Xml schema:
<?xml version="l.0"?>
<xs: schema targetNamespace="urn: 3gpp: ns: imsiut: join"
xmlns: join="urn: 3gpp: ns: imsiut: join"
xmlns: xs="ht tp: //www. w3. org/2001/XMLSchema "
elementFormDef aul t="qual if ied"
attr ibuteFormDef aul t="unqual if ied">
<xs: element name=" join" type=" join: jo in-sess ion-id" /> <xs: complexType name=" join-sess ion- id" >
<xs: sequence>
<xs: element name=" sess ion- id" type=" join: Session minOccurs="0" maxOccurs=" 1 "/>
<xs: any namespace=" other " processContents=" lax minOccurs="0" maxOccurs=" unbounded" />
</xs: sequence
<xs: anyAt tr ibute namespace="##other processContents=" lax"/>
</xs: complexType>
<xs: complexType name="Session">
<xs: sequence>
<xs: any namespace=" other " processContents=" lax" minOccurs="0" maxOccurs=" unbounded" />
</xs: sequence>
<xs: attribute name="call-id" type="xs: st ring"/>
<xs: attribute name=" It" type=Mxs: string"/>
<xs: attribute name="rt" type="xs: string"/>
<xs: anyAt tr ibute namespace="##other" processContents=" lax"/>
</xs: complexType>
</xs: schema>
具体形式如：
Content-Type: appl icat ion/vnd.3gpp. join+xml//消息体的类型， 表明 该消息体的内容是用来表示加入会话的会话信息。
<?xml version="l.0"?>
<join xmlns = "urn: 3gpp: ns: imsiut: j o i n " > <s es s ion— i d ca l l— i d=" a 84b4c76e66710 " l t=" 1928301774 " r t = " 456887766 " />〃表示加入会话的会话标识信息。
</a t i >
上述无论哪种 XML消息体都是一种可能的实现方式。
步骤 206为： 当发起者 SCC AS接收到 302重定向响应消息后， 根据 302重定 向响应消息向主控 SCC AS发送邀请消息。
在步骤 206中， 当发起者 SCC AS接收到 302重定向响应消息后， 作为 B2BUA 终止将 302重定向响应消息发到发起者 UE， 而根据 3 C 2重定向响应消息的指示 信息， 向交互地址头域所指示的地址发送邀请消息， 并将 302重定向响应消息 的 XML消息体内容写入重定向的邀诸消息的加入头域中， 源头域和目标头域不 变， 将原邀请消息中的其他相关头域和消息体复制到重定向的邀请消息中。
步骤 207〜步骤 217、 主控 SCC AS接收到来自发起者 UE表示通过拉方式请 求媒体转移的邀请消息， 主控 SCC AS根据拉方式媒体转移请求中的目标 UE标 识、 发起者 UE标识和转换后的会话标识信息将待转移媒体从目标 UE转移至发 起者 UE。
接收到邀请消息的主控 SCC AS根据内容部署或主题消息头识别出该邀请 消息为拉方式媒体转移请求， 并根据会话标识信息和本机保存的联合会话信 息判断本机为待转移媒体所在联合会话的主控 SCC AS。
主控 SCC AS根据邀请消息源头域中的发起者 UE标识以及本机保存的联合 会话信息判断发起者 UE是否在当前联合会话中， 执行相应的媒体转移操作， 当发起者 UE不在该联合会话中时， 关联到联合会话信息等操作如下：
步骤 207、 在执行媒体转移操作之前， 主控 SCC AS可以向主控 UE认证是否 允许发送者 UE发起拉方式媒体转移请求， 当接收到主控 UE允许该发起者 UE发 起拉方式媒体转移请求时， 则执行后续步骤， 若主控 UE不允许该发起者 UE发 起拉方式媒体转移请求时， 则返回失败响应， 例如 4 * *失败响应消息；
步骤 208、 经过验证允许发起者 UE将目标 UE的媒体转移到自身时， 则主控 SCC AS向对端发送重邀请 ( re-inv i te ) 消息以更新对端， 使得相应媒体在发 起者 UE与对端之间通信；
步骤 209、 对端返回 200 ok响应消息; 步骤 21 Q ~ 213、 主控 SCC AS根据对端返回的信息， 经发起者 SCC AS向发 起者 UE返回邀请消息的 200 ok响应消息， 完成转移的媒体协商， 发起者 UE经 发起者 SCC AS向主控 SCC AS返回 200 ok确认消息 ACK;
进一步的， 主控 SCC AS向发起者 UE返回邀请消息的 200 ok响应消息时， 可以向发起者 SCC AS发送通知消息， 以通知发起者 SCC AS该新建会话属于当 前联合会话， 且对应 UE为受控 UE， 该 SCC AS属于受控 UE归属的 SCC AS。
该通知消息还可以包括联合会话的主要信息， 如主控 UE、 主控 SCC AS的 地址或身份信息等。
以上信息可以通过 20Q ok响应消息的 XML消息体来携带， 发起者 SCC AS识 别该消息， 并保存消息体内容信息后删除该消息体， 200 ok响应消息继续发 送到发起者 UE。
步骤 214、 主控 SCC AS向对端返回 200 ok响应消息的确认消息 ACK;
步骤 215 ~ 216、 主控 SCC AS更新媒体所在的目标 UE， 将转移到发起者 UE 的媒体从目标 UE释放。
步骤 217， 主控 SCC AS更新主控 UE所保存的联合会话信息， 即被转移的媒 体所在 UE由目标 UE变为发起者 UE。
在实际应用中， 如果发出邀请消息的发起者 UE与目标 UE属于相同签约并 归属于相同 SCC AS , 则根据邀请消息的目标头域， 邀请消息会直接发送到目 标 UE归属的目标 SCC AS , 目标 SCC AS通过判断源头域得知发出邀请消息的发 起者 UE归属于当前的目标 SCC AS， 则可以不发送 302重定向响应消息， 而直接 将邀请消息发送到联合会话的主控 UE所属的主控 SCC AS。
本实施例给出了不在联合会话的 UE利用邀请消息向联合会话的受控 UE 请求媒体转移的流程， 在联合会话中受控 UE与主控 UE属于不同签约， 受控 SCC AS收到拉方式媒体转移请求后将其发送到主控 SCC AS , 由主控 SCC AS 完成媒体转移过程。 该技术方案保证了 UE间媒体转移的可靠性。
实施例三
图 3为本发明实施例三提供的用户设备间媒体转移方法的信令流程图， 本实施例所适用的情况为：已建立的联合会话中包括主控 UE和两个以上受控 UE, 本实施例以两个受控 UE为例进行说明， 即第一受控 UE和第二受控 UE， 三个 UE属于不同签约下， 分别归属的第一受控 SCC AS , 第二受控 SCC AS和 主控 SCC AS为不同的 SCC AS。 本实施例具体为第二受控 UE请求将第一受控 UE上的媒体转移到自身的解决方法， 第二受控 UE作为发起者 UE , 第一受控 UE作为目标 UE， 且以邀请消息作为拉方式媒体转移请求。
本实施例中， 与实施例二类似， 发起者 UE仍可通过会话发现过程来发现 其他 UE上的会话及媒体信息， 据此决定请求目标 UE上的一个或多个媒体转移 到自身。 发起者 UE不知道自身已是该联合会话中的受控 UE， 而且通过会话发 现过程也无法获知与目标 UE属于同一个联合会话， 因此， 第二受控 UE仍类似 于实施例二来发起拉方式媒体转移请求， 该媒体转移方法包括如下步骤： 步骤 301 -步骤 306与实施例二中的步骤 201 - 206基本相同。 第二受控 UE 作为发起者 UE发起邀请消息以建立媒体转移的信令连接， 该邀请消息中至少 包括发起者 UE标识、 目标 UE标识、 以及目标 UE与目标 SCC AS之间的会话标识 信息， 以及待转移媒体； 其中待转移媒体为目标 UE上的一个或多个媒体。 该 邀请消息被发送至主控 SCC AS。 该邀请消息的头域和消息体等设定格式与实 施例二相同， 不再赘述。
步骤 307 ~ 323、 主控 SCC AS根据拉方式媒体转移请求中的目标 UE标识、 发起者 UE标识和转换后的会话标识信息将待转移媒体从目标 UE转移至发起者 UE。
主控 SCC AS根据邀请消息的内容部署或主题消息头判断出该邀请消息为 拉方式媒体转移请求， 根据加入头域中的会话标识信息得知本机为该联合会 话中的主控 SCC AS , 主控 SCC AS根据邀请消息源头域中的发起者 UE标识以及 本机保存的联合会话信息判断发起者 UE是否在当前联合会话中， 如杲否， 则 可以执行实施例二的步骤 207 ~ 217， 若是， 则主控 SCC AS在当前联合会话中 发起者 UE对应的原接入分支中增加待转移媒体， 使得在同一接入分支内传递 发起者 UE上所有媒体的信令信息。
由于本实施例中发起者 UE已属于该联合会话， 所以主控 SCC AS所执行的 媒体转移与实施例二有所区别， 具体流程如下：
步骤 307、 主控 SCC AS向主控 UE发起认证发起者 UE的请求， 并接收返回的 认证是否允许的结果， 若认证允许， 则继续执行下述步骤； 步骤 3Q8 ~ 309、 主控 SCC AS向发起者 UE返回邀请消息的终止响应， 如 487 响应消息 （487 Reques t Termina ted ), 经发起者 SCC AS转发至发起者 UE， 以 终止该邀请消息。
步骤 310 ~ 311、 发起者 UE对主控 SCC AS的最终响应消息经发起者 SCC AS 返回确认消息 ACK;
步骤 312 - 313、 主控 SCC AS查找发起者 UE在当前联合会话中对应的原接 入分支， 在发起者 UE的原接入分支内发送重邀清消息， 并在重邀请消息中增 加待转移媒体， 具体可以在重邀请消息的 SDP消息体中增加待转移媒体行 ( re- inv i te wi th pu l l med i a des cr i p t ion in SDP ), 重邀请消息经过发起 者 SCC AS发送至发起者 UE， 以向该发起者 UE增加待转移媒体；
步骤 314 ~ 315、 发起者 UE经发起者 SCC AS返回重邀请消息的 2 G 0 ok响应 消息， 该响应消息中携带发起者 UE为转移媒体分配的端口号等媒体描述信息； 步骤 316 ~ 317、 主控 SCC AS根据发起者 UE返回的转移媒体的描述信息向 对端发送重邀请消息以更新对端， 对端返回 200 ok响应消息；
步骤 318 - 319、 主控 SCC AS向发起者 UE返回对 200 ok响应消息的确认消 息 ACK;
步骤 320、 主控 SCC AS向对端返回 200 ok响应消息的确认消息 ACK;
步骤 321 ~ 322、 主控 SCC AS更新媒体所在的目标 UE , 将转移到发起者 UE 的媒体从目标 UE释放。
步骤 323、 主控 SCC AS更新主控 UE所保存的联合会话信息， 即将转移媒体 所在 UE由第一受控 UE变为第二受控 UE。
如果发起者 UE与目标 UE属于相同签约， 并归属于相同的 SCC AS时， 则拉 方式媒体转移请求可以直接被发送到第一受控 SCC AS， 由第一受控 SCC AS经 过上述判断过程得出是由归属于本 SCC AS的 UE发出的请求， 则不必返回 302重 定向响应消息， 而直接将邀请消息转发到主控 SCC AS。
一个受控 UE向联合会话中其他受控 UE发起拉方式媒体转移请求时， 即使 发起者 UE在联合会话中， 也可以采用实施例二的媒体转移方式， 即不终止发 起者 UE新创建的会话， 而使得发起者 UE在此联合会话中有两个接入分支。 存 在两个接入分支使得 UE可以在不同会话网传输不同媒体流， 如受控 UE请求转 移视频媒体， 在信道带宽更大的分组域接入网中建立视频媒体的接入分支， 以利于媒体流传输， 具体实现过程如实施例二所述。
本实施例给出联合会话的受控 UE 向联合会话的其他受控 UE请求媒体 转移的方案。 发起者 UE按照不在联合会话发出拉方式媒体转移请求， 目标 SCC AS收到拉方式媒体转移请求， 将该拉方式媒体转移请求发送到主控 SCC AS, 由主控 SCC AS完成媒体转移过程。 主控 SCC AS收到拉方式媒体转移请 求后， 判断发起者 UE是否属于联合会话， 并执行不同的处理方法； 或者， 对 于属于联合会话的发起者 UE，也可以按照不在联合会话中发起拉方式媒体转 移请求的方法来执行媒体转移。本实施例的技术方案保证了 UE间媒体转移的 可靠性。
实施例四
图 4为本发明实施例四提供的用户设备间媒体转移方法的信令流程图。 本实施例可以沿用实施例二的情况， 但与实施例二的区别在于， 发起者 UE 可以属于或不属于当前的联合会话， 本实施例釆用转移（ refer )消息作为拉 方式媒体转移请求。 其中， 发起者 UE、 目标 UE与主控 UE属于不同签约， 并 归属于不同 SCC AS。 发起者 UE通过会话发现过程发现其他 UE的会话及媒体 信息， 根据获得的目标 UE会话信息将目标 UE—个或多个媒体转移到自身， 该目标 UE为联合会话的受控 UE。
步骤 401、 发起者 UE发起转移消息以将目标 UE上的媒体转移到自身， 该转 移消息中至少包括发起者 UE标识、 目标 UE标识、 以及目标 UE与目标 SCC AS之 间的会话标识信息， 以及待转移媒体； 其中待转移媒体为目标 UE上的一个或 多个媒体。
可以利用转移消息的多个头域和消息体来指示上述信息。 具体的头域介 绍如下：
转移目标（refer-to) 头域， 由于需要将媒体转移至发起者 UE, 所以转 移目标头域记录发起者 UE表示， 即发起者 UE自身的身份信息 （可包括全局可 路由用户代理标识符 (Globally Routable User Agent URI, 简称 GRUU) )。 发起者 UE所要转移的媒体类型可以包含在转移目标头域中， 作为需要在其自 身建立的媒体类型。例如为 "Refer- to: <target- URI; GRUU; audio; video; >", "audio", "video" 表示在转移目标头域所指的 UE上建立音频、 视频媒体。 或者媒体类型也可以通过消息体携带， 如在转移目标头域中携带 SDP信息或在 邀请消息中携带 XML消息体， 来指示待转移媒体。 转移目标头域中的方式 (method)项可以设置为 "邀请 ( invite )"0
目标会话 ( target-dialog)头域， 用于记录待转移媒体所在目标 UE的会 话标识信息， 相当于邀请消息中加入头域的功能。 为区别于转移媒体后单独 建立会话， 发起者 UE可以向主控 SCC AS指示转移后加入联合会话， 发起者 UE 通过对转移消息的转移目标头域进行增强来体现这一信息。 转移目标头域的 转移目标 UE URI后可携带目标 UE的能力信息或特征信息，例如，根据" RFC3840" 可以进行如下设定：
方法一： "sip: actor" 中， 可以用 "attendant" 表示力口入目标会话头 域所指向的会话， 用 "principal" 表示单独建立新的 IMS会话;
方法二： " "sip: events = session" 表示新建会话， 而对于加入联合 会话不特殊指示， 网络侧只有收到有 "events^ session"指示才新建立会话， 否则表示媒体转移后加入会话。
具体形式为 "Refer-To: sip: conf4451exaraple. com; principal
(attendant) /sessioru"
目标头域和源头域， 源头域中为发起者 UE的身份信息， 例如， "From: 发 起者 UE URI", 目标头域为目标 UE的身份信息， 例如 "To: 受控 UE URI"。 目 标头域和标识请求头域的参数虽然一致， 但是其在被解析识别时具备不同的 标识功能。
统一资源标识请求（ request-URI )头域， 指示该转移消息所发送的目的 地。 在发起拉方式媒体转移请求时， 目的地址是目标 UE标识。
实际应用中， 可以通过多种参数项来标识该转移消息为拉方式媒体转移 请求， 例如通过源头域和转移目标头域的值相同来标识为拉方式媒体转移请 求， 也可以通过主题 ( subject )头域， 如 "subject: pull-media" 来标识 为拉方式媒体转移请求。 如果转移消息中包含消息体， 则可以通过
"content-di spos i ton" , 如 "content- di spos i ton: pull-media" 来标识为 拉方式媒体转移请求。 步骤 402、 转移消息经过 S- CSCF被发送到发起者 UE所归属的 SCC AS , 发起 者 SCC AS判断出转移消息是通过拉方式请求媒体转移时可以首先验证发起者 UE是否可以发出拉方式媒体转移请求， 如果可以则继续后续步骤， 如果不允 许发起者 UE发出拉方式媒体转移请求， 则对转移消息返回 "4**响应消息"。
接收到转移消息的 SCC AS根据转移消息中的目的地址判断本机为转移消 息的发送目的， 若是， 则由于该请求是拉方式媒体转移请求， 所以终止向目 标 UE发送， 继续执行步骤 404， 若否， 则根据目的地址继续发送拉方式媒体转 移请求， 并执行步骤 403。
步骤 403、 与步骤 402类似， 目标 UE所归属的目标 SCC AS接收到该转移消 息。
步骤 404、 目标 SCC AS识别到该转移消息为拉方式媒体转移请求时， 则终 止将转移消息向目标 UE的发送， 目标 SCC AS才艮据转移消息目标会话头^ Ϊ中的 会话标识信息和保存的联合会话信息判断本机是否为待转移媒体所在联合会 话的主控 SCC AS , 若是， 则该目标 SCC AS可以作为主控 UE执行媒体转移操作， 若否， 则执行步骤 405 ;
进一步的， 目标 SCC AS判断收到的转移消息为拉方式媒体转移请求， 在 进行后续判断逻辑之前，也可以向目标 UE认证是否允许发起者 UE向目标 UE 发起拉方式媒体转移请求。
步骤 405、 目标 SCC AS将转移消息中所包含的会话标识信息转换为目标 SCC AS与主控 SCC AS之间的会话标识信息， 将该转移消息转发至主控 SCC AS ( redi rec t: refer ), 以便主控 SCC AS根据邀请消息进行媒体转移。
目标 SCC AS将转换后的转移消息转发至主控 SCC AS。
对会话标识信息的转换， 具体可以将目标会话头域的会话标识信息替换 为目标 SCC AS与主控 SCC AS间的会话标识信息， 以便主控 SCC AS根据目标会 话头域找到匹配的会话， 并根据发起者 UE和目标 UE标识执行媒体转移操作。
为将转移消息发送至主控 SCC AS , 可以对转移消息作以下处理： 将统一资源标识请求头域的目标 UE UR I替换为主控 SCC AS PSI , 保持源 头域和目标头域不变， 并复制其他头域及消息体。 主控 SCC AS PSI与主控 UE 标识类似， 均用于标识某一实体。 步骤 406 - 418 , 主控 SCC AS接收到转移消息， 解析转移消息中的目标会 话头域， 根据本机保存的联合会话信息判断出本机在目标会话所属联合会话 中为主控 SCC AS , 则主控 SCC AS根据拉方式媒体转移请求中的目标 UE标识、 发起者 UE标识和转换后的会话标识信息将待转移媒体从目标 UE转移至发起者 UE。 具体流程如下：
步骤 406、 主控 SCC AS可以向主控 UE发送转移认证请求， 以奇求主控 UE 认证是否允许发送者 UE发起拉方式媒体转移请求， 当主控 UE允许其发起拉方 式转移请求时， 则对该拉方式媒体转移请求返回接受响应消息， 例如 " 202 accept"响应消息，若主控 UE不允许其发起拉方式转移请求时， 则返回失败响 应，例如 4**失败响应消息，此处认为主控 UE允许发起者 UE发起拉方式媒体转 移请求；
步骤 407 - 409、 主控 SCC AS接受拉方式媒体转移请求， 向发起者 UE返回 转移接受响应 （2 Q2 accept )0
步骤 410、主控 SCC AS根据转移消息源头域中的发起者 UE标识和目标会话 头域中的会话标识信息 , 及本机保存的联合会话信息判断发起者 UE是否属于 当前联合会话， 若否， 则执行步骤 411， 若是， 则在当前联合会话中发起者 UE 对应的原接入分支上增加媒体， 完成媒体转移过程；
步骤 411、主控 SCC AS根据拉方式媒体转移请求中所指示的待转移媒体类 型， 向发起者 UE发出邀请消息， 以建立发起者 UE和主控 SCC AS之间的新会话， 在新会话中建立转移媒体；
该邀请消息的 SDP消息体中携带主控 SCC AS保存的相应媒体对端端口号 和媒体描述信息。
进一步的， 主控 SCC AS可以在该邀倚消息中携带通知信息， 以指示发起 者 SCC AS该新建会话属于当前联合会话， 且对应的发起者 UE为受控 UE， 该发 起者 SCC AS为受控 SCC AS.
通知信息中还可以包括该联合会话的主要信息： 如主控 UE和主控 SCC AS 的地址或身份信息等。
以上信息可以通过邀请消息的 XML消息体来携带， 发起者 SCC AS识别该邀 请消息， 并保存邀请消息的消息体内容信息后删除消息体， 将邀请消息继续 发送到发起者 UE。
步骤 412、 发起者 UE经发起者 SCC AS返回 200 ok响应消息；
步骤 413 ~ 414、 主控 SCC AS向对端发送重邀请消息， 更新对端连接， 对 端返回 200 ok响应消息；
步骤 415、 主控 SCC AS经发起者 SCC AS向发起者 UE返回 200 ok响应消息的 确认消息 ACK;
步骤 416、 主控 SCC AS向对端返回确认消息 ACK， 完成发起者 UE与对端的 媒体协商过程；
步骤 417、 主控 SCC AS更新转移媒体所在的原 UE上媒体信息， 将转移到发 起者 UE的媒体从目标 UE释放；
步骤 418、 主控 SCC AS更新主控 UE所保存的联合会话信息， 即将被转移媒 体所在 UE由目标 UE变为发起者 UE。
本实施例中， 当发起者 UE与目标 UE属于相同签约， 归属于相同 SCC AS时， 其流程与上述过程相似， 转移请求可经其 SCC AS直接发送到主控 SCC AS。
若发起者 UE为联合会话的受控 UE , 向联合会话中其它受控 UE采用拉方式 转移媒体过程与上述过程相似， 不同之处还在于步骤 410中在发起者 UE已有的 信令连接上通过重邀请消息向发起者 UE建立媒体， 且不必携带指示发起者 SCC AS为受控 SCC AS的 XML消息体。
本实施例给出了发起者 UE通过转移消息向联合会话中的受控 UE请求媒 体转移的方法， 发起者 UE可以属于或不属于该联合会话。 受控 SCC AS收到 转移消息后会将其发送到联合会话的主控 SCC AS, 由主控 SCC AS来执行媒 体转移过程。 本实施例的技术方案保证了 UE间媒体转移的可靠性。
实施例五
本发明实施例五提供了用户设备实现媒体转移的方法，具体为发起者 UE 所执行的方法， 包括如下步骤：
发起者 UE向目标 UE发起拉方式媒体转移请求， 该拉方式媒体转移请求 中包含会话标识信息，该会话标识信息用于标识目标 UE上待转移媒体所在的 会话， 会话标识信息用于当目标 SCC AS接收到拉方式媒体转移请求时， 在待 转移媒体所在的会话为联合会话， 且判断本机是待转移媒体所在联合会话的 受控 SCC AS时， 则将拉方式媒体转移请求转发至该联合会话的主控 SCC AS , 以使得主控 SCC AS进行媒体转移， 其中， 目标 SCC AS为目标 UE所归属的 SCC AS , 主控 SCC AS为联合会话的主控 UE所归属的 SCC AS。
UE可以采用不同的消息作为拉方式媒体转移请求。一种方式为发起者 UE 釆用邀请消息作为拉方式媒体转移请求， 媒体转移请求的拉方式通过邀请消 息中的消息头指示。另一种方式为发起者 UE采用转移消息作为拉方式媒体转 移请求，并在转移消息中釆用头域指示发起者 UE完成拉方式媒体转移后加入 当前联合会话。 具体的应用实例可参加前述实施例所述。
本实施例提供的方法可以与本发明所提供的 SCC AS执行的方法配合实现 UE间媒体转移操作。
实施例六
图 5为本发明实施例六提供的连续性应用服务器的结构示意图，具体包 括： 接收模块 51 0和转发模块 520。 其中， 接收模块 51 0用于接收发起者 UE 向目标 UE发起的拉方式媒体转移请求， 其中， 拉方式媒体转移请求中包含 会话标识信息， 会话标识信息用于标识目标 UE上待转移媒体所在的会话； 转发模块 520用于当待转移媒体所在的会话为联合会话，且根据会话标识信 息判断本机是待转移媒体所在联合会话的受控 SCC AS时， 则将拉方式媒体 转移请求转发至联合会话的主控 SCC AS , 以使得主控 SCC AS进行媒体转移， 其中， 主控 SCC AS为联合会话的主控 UE所归属的 SCC AS。
该 SCC AS还可以进一步包括转换模块 530 , 用于在判断本机不是待转移媒 体所在联合会话的主控 SCC AS时， 将拉方式媒体转移请求中所包含的会话标 识信息转换为本机与主控 SCC AS之间的会话标识信息。
拉方式媒体转移请求可以釆用多种消息来实现。 当拉方式媒体转移请求 为邀请消息时， 转发模块具体包括： 重定向单元， 用于当判断发起者 UE不归 属于本机时， 将邀请消息重定向至主控 SCC AS。
当本实施例的 SCC AS作为主控 SCC AS时， 还可以进一步包括转移控制模 块 540， 用于当根据拉方式媒体转移请求判断本机是待转移媒体所在联合会话 的主控 SCC AS时， 根据拉方式媒体转移请求进行媒体转移。
该转移控制模块 540具体可以包括： 第一转移控制单元 541和 /或第二转换 控制单元 542。 其中， 第一转移控制单元 541用于向发起者 UE新建会话， 在新 建的会话建立待转移媒体； 第二转换控制单元 542用于当判断发起者 UE在当前 联合会话中时， 在发起者 UE在当前联合会话中的原接入分支中增加待转移媒 体。
作为主控 SCC AS时， 还可以包括通知模块 550， 与第一转换控制单元 541 相连， 用于向发起者 SCC AS发送通知消息， 以通知新建的会话属于当前联合 会话、 发起者 UE为受控 UE、 主控 UE的信息和 /或主控 SCC AS的信息。
本发明实施例还提供了一种用户设备， 包括请求发起模块， 用于向目标 UE发起拉方式媒体转移请求， 拉方式媒体转移请求中包含会话标识信息， 会 话标识信息用于标识目标 UE上待转移媒体所在的会话， 会话标识信息用于当 目标 SCC AS接收到拉方式媒体转移请求时， 在待转移媒体所在的会话为联合 会话， 且判断本机是待转移媒体所在联合会话的受控 SCC AS时， 则将拉方式 媒体转移请求转发至联合会话的主控 SCC AS , 以使得主控 SCC AS进行媒体转 移， 其中， 目标 SCC AS为目标 UE所归属的 SCC AS， 主控 SCC AS为联合会话的 主控 UE所归属的 SCC AS。
本发明实施例还提供了一种用户设备间媒体转移系统， 包括： 目标 SCC AS 和主控 SCC AS。
目标 SCC AS , 用于接收发起者 UE向目标 UE发起的拉方式媒体转移请求， 其中， 目标 SCC AS为目标 UE所归属的 SCC AS , 拉方式媒体转移请求中包含会 话标识信息， 会话标识信息用于标识目标 UE上待转移媒体所在的会话， 且当 待转移媒体所在的会话为联合会话， 且目标 SCC AS根据会话标识信息判断本 机是待转移媒体所在联合会话的受控 SCC AS时， 将拉方式媒体转移请求转发 至联合会话的主控 SCC AS;
主控 SCC AS , 用于当根据接收到的拉方式媒体转移请求中所指示的待转 移媒体所在会话的会话标识信息， 判断本机是待转移媒体所在联合会话的主 控 SCC AS时， 进行媒体转移。
本发明实施例所提供的用户设备、 连续性应用服务器和系统， 可以执行 本发明实施例所提供的用户设备间媒体转移方法， 具备相应的功能模块。 本发明实施例的技术方案解决了现有技术中， 目标受控 UE与主控 UE不归属于 同一 SCC AS时， 发起者 UE无法向联合会话的受控 UE请求转移媒体的问题。 需要说明的是： 本发明实施例中所涉及的主控 SCC AS包括但不限于下述 中的至少一种：
主控 UE归属的 SCC AS或管理联合会话各会话分支的主控 SCC AS , 即， Hos t ing SCC AS。
本领域普通技术人员可以理解： 实现上述方法实施例的全部或部分步骤 可以通过程序指令相关的硬件来完成， 前述的程序可以存储于一计算机可读 取存储介质中， 该程序在执行时， 执行包括上述方法实施例的步骤； 而前述 的存储介质包括： R0M、 RAM, 磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是： 以上实施例仅用以说明本发明的技术方案， 而非对其 限制； 尽管参照前述实施例对本发明进行了详细的说明， 本领域的普通技术 人员应当理解： 其依然可以对前述各实施例所记载的技术方案进行修改， 或 者对其中部分技术特征进行等同替换； 而这些修改或者替换， 并不使相应技 术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims

权 利 要 求
1、 一种用户设备间媒体转移方法， 其特征在于， 包括：
目标连续性应用服务器接收发起者用户设备向目标用户设备发起的拉方 式媒体转移请求， 其中， 所述目标连续性应用服务器为所述目标用户设备所 归属的连续性应用服务器， 所述拉方式媒体转移请求中包含会话标识信息， 所述会话标识信息用于标识所述目标用户设备上待转移媒体所在的会话； 当所述待转移媒体所在的会话为联合会话， 且所述目标连续性应用服务 器根据所述会话标识信息判断本机是待转移媒体所在联合会话的受控连续性 应用服务器时， 则将所述拉方式媒体转移请求转发至所述联合会话的主控连 续性应用服务器， 以使得所述主控连续性应用服务器进行媒体转移， 其中， 所述主控连续性应用服务器为所述联合会话的主控用户设备所归属的连续性 应用服务器。
2、 根据权利要求 1所述的方法， 其特征在于， 所述目标连续性应用服 务器将所述拉方式媒体转移请求转发至所述主控连续性应用服务器过程中还 包括：
所述目标连续性应用服务器将所述拉方式媒体转移请求中所包含的会话 标识信息转换为所述目标连续性应用服务器与所述主控连续性应用服务器之 间的会话标识信息。
3、 根据权利要求 1或 1所述的方法， 其特征在于， 所述目标连续性应 用服务器将所述拉方式媒体转移请求转发至所述主控连续性应用服务器包括： 所述拉方式媒体转移请求为邀请消息时， 当所述目标连续性应用服务器 判断所述发起者用户设备不归属于本机时， 将所述邀请消息重定向至所述主 控连续性应用服务器。
4、 根据权利要求 3所述的方法， 其特征在于， 所述目标连续性应用服 务器将所述邀请消息重定向至所述主控连续性应用服务器包括： 所述目标连续性应用服务器向所述发起者用户设备发送的邀请消息返回 重定向消息， 以将所述邀请消息直接发送到所述主控连续性应用服务器， 并 在所述重定向消息中携带所述目标连续性应用服务器与主控连续性应用服务 器间的会话标识信息， 以更新所 i«请消息中的会话标识信息。
5、 根据权利要求 1或 2所述的方法， 其特征在于， 所述主控连续性应 用服务器进行媒体转移包括：
所述主控连续性应用服务器向所述发起者用户设备新建会话， 在新建的 所述会话建立所述待转移媒体； 或者，
当所述主控连续性应用服务器判断所述发起者用户设备在当前联合会话 中时， 在当前联合会话中的发起者用户设备原接入分支中增加所述待转移媒 体。
6、 根据权利要求 5所述的方法， 其特征在于，
所述主控连续性应用服务器向所述发起者用户设备新建会话， 在新建的 所述会话建立所述待转移媒体包括： 所述主控连续性应用服务器向发起者连 续性应用服务器发送通知消息， 以通知新建的所述会话属于当前联合会话、 所述发起者用户设备为受控用户设备、 主控用户设备的信息和 /或所述主控连 续性应用服务器的信息； 或者，
当所述主控连续性应用服务器判断所述发起者用户设备在当前联合会话 中时， 在所述发起者用户设备在当前联合会话中的所述原接入分支中增加所 述待转移媒体包括：
当所述拉方式媒体转移请求为邀请消息时， 所述主控连续性应用服务器 向所述发起者用户设备返回所述邀请消息的终止响应， 以终止所述邀请消息； 所述主控连续性应用服务器向所述发起者用户设备发送重邀请消息， 以 请求在当前联合会话中所述发起者用户设备的原接入分支中增加所述待转移 媒体。
7、 一种连续性应用服务器， 其特征在于， 包括：
接收模块， 用于接收发起者用户设备向目标用户设备发起的拉方式媒体 转移请求， 其中， 所述拉方式媒体转移请求中包含会话标识信息， 所述会话 标识信息用于标识所述目标用户设备上待转移媒体所在的会话； 转发模块， 用于当所述待转移媒体所在的会话为联合会话， 且根据所述会 话标识信息判断本机是待转移媒体所在联合会话的受控连续性应用服务器时， 则将所述拉方式媒体转移请求转发至所述联合会话的主控连续性应用服务器， 以使得所述主控连续性应用服务器进行媒体转移， 其中， 所述主控连续性应用 服务器为所述联合会话的主控用户设备所归属的连续性应用服务器。
8、 根据权利要求 7所述的连续性应用服务器， 其特征在于， 还至少包 括以下任意一种模块：
转换模块， 用于在判断本机不是待转移媒体所在联合会话的主控连续性 应用服务器时， 将所述拉方式媒体转移请求中所包含的会话标识信息转换为 本机与所述主控连续性应用服务器之间的会话标识信息；
转移控制模块， 用于当根据所述拉方式媒体转移请求判断本机是待转移 媒体所在联合会话的主控连续性应用服务器时， 根据所述拉方式媒体转移请 求进行媒体转移。
9、 根据权利要求 7所述的连续性应用服务器， 其特征在于， 所述拉方 式媒体转移请求为邀请消息， 所述转发模块包括：
重定向单元， 用于当判断所述发起者用户设备不归属于本机时， 将所述 邀请消息重定向至所述主控连续性应用服务器。
10、 根据权利要求 8所述的连续性应用服务器， 其特征在于， 所述转移 控制模块至少包括以下一种单元：
第一转移控制单元， 用于向所述发起者用户设备新建会话， 在新建的所 述会话建立所述待转移媒体；
第二转换控制单元， 用于当判断所述发起者用户设备在当前联合会话中 时， 在所述发起者用户设备在当前联合会话中的原接入分支中增加所述待转 移媒体。
PCT/CN2011/070504 2010-02-11 2011-01-24 用户设备间媒体转移方法和应用服务器 WO2011097982A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP11741853.3A EP2472952B1 (en) 2010-02-11 2011-01-24 Method for inter-ue media transfer and application server thereof
US13/584,371 US9531816B2 (en) 2010-02-11 2012-08-13 Method and apparatus for media transfer between user equipment

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010111665.1 2010-02-11
CN2010101116651A CN102158466B (zh) 2010-02-11 2010-02-11 用户设备间媒体转移方法和应用服务器

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/584,371 Continuation US9531816B2 (en) 2010-02-11 2012-08-13 Method and apparatus for media transfer between user equipment

Publications (1)

Publication Number Publication Date
WO2011097982A1 true WO2011097982A1 (zh) 2011-08-18

Family

ID=44367255

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/070504 WO2011097982A1 (zh) 2010-02-11 2011-01-24 用户设备间媒体转移方法和应用服务器

Country Status (4)

Country Link
US (1) US9531816B2 (zh)
EP (1) EP2472952B1 (zh)
CN (1) CN102158466B (zh)
WO (1) WO2011097982A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101585679B1 (ko) * 2009-04-17 2016-01-15 엘지전자 주식회사 Ｉｍｓ 기반의 시스템에서 ｉｕｔ의 수행방법
WO2011056034A2 (en) * 2009-11-09 2011-05-12 Lg Electronics Inc. Method for controlling session and server using the same
CN104936208B (zh) * 2014-03-21 2019-12-10 中兴通讯股份有限公司 SRVCC的Refer业务处理方法、装置及系统
CN105025049B (zh) * 2014-04-22 2019-03-22 深圳市尼得科技有限公司 一种媒体流存储方法、装置及服务器
CN110557381B (zh) * 2019-08-08 2021-09-03 武汉兴图新科电子股份有限公司 基于媒体流热迁移机制的媒体高可用系统
US20230421519A1 (en) * 2022-06-27 2023-12-28 Twilio Inc. Transferring messaging conversations between user accounts using a software as a service platform

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101299785A (zh) * 2007-04-30 2008-11-05 华为技术有限公司 一种会话处理的方法、系统以及业务服务器
JP2009044314A (ja) * 2007-08-07 2009-02-26 Nippon Telegr & Teleph Corp <Ntt> メディア転送方法、その装置およびプログラム
CN101383827A (zh) * 2008-10-13 2009-03-11 深圳华为通信技术有限公司 一种转移媒体的方法、装置和系统
CN101494648A (zh) * 2009-02-03 2009-07-29 深圳华为通信技术有限公司 一种终端设备间媒体转移方法和网络设备

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7567555B1 (en) * 2004-03-22 2009-07-28 At&T Corp. Post answer call redirection via voice over IP
US9318152B2 (en) * 2006-10-20 2016-04-19 Sony Corporation Super share
US20080275966A1 (en) 2007-03-13 2008-11-06 Mackinnon Allan S Methods and apparatus for provider-managed content delivery
US8111712B2 (en) * 2008-04-10 2012-02-07 Nokia Siemens Networks Oy Apparatus, method, system and program for communication
US7979558B2 (en) * 2008-08-06 2011-07-12 Futurewei Technologies, Inc. Remote session control
US8032589B2 (en) * 2008-10-27 2011-10-04 Telefonaktiebolaget L M Ericsson (Publ) Methods and systems for resuming, transferring or copying a multimedia session
WO2010081146A2 (en) * 2009-01-12 2010-07-15 Starent Networks, Corp Transferring sessions in a communications network
CN101848512B (zh) 2009-03-24 2012-08-29 华为技术有限公司 会话相关信息的转移方法及装置
US9094423B2 (en) * 2010-08-13 2015-07-28 Qualcomm Incorporated Apparatus and methods for inter-user equipment transfers
US9103468B2 (en) * 2012-07-30 2015-08-11 University Of South Carolina Enhanced flow boiling in microchannels by high frequency microbubble-excited and -modulated oscillations

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101299785A (zh) * 2007-04-30 2008-11-05 华为技术有限公司 一种会话处理的方法、系统以及业务服务器
JP2009044314A (ja) * 2007-08-07 2009-02-26 Nippon Telegr & Teleph Corp <Ntt> メディア転送方法、その装置およびプログラム
CN101383827A (zh) * 2008-10-13 2009-03-11 深圳华为通信技术有限公司 一种转移媒体的方法、装置和系统
CN101494648A (zh) * 2009-02-03 2009-07-29 深圳华为通信技术有限公司 一种终端设备间媒体转移方法和网络设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2472952A4 *

Also Published As

Publication number Publication date
US9531816B2 (en) 2016-12-27
EP2472952A1 (en) 2012-07-04
CN102158466B (zh) 2013-10-09
US20120311026A1 (en) 2012-12-06
EP2472952A4 (en) 2012-07-04
EP2472952B1 (en) 2016-11-16
CN102158466A (zh) 2011-08-17

Similar Documents

Publication Publication Date Title
KR101141125B1 (ko) 멀티미디어 세션 호 제어 방법 및 애플리케이션 서버
US11431774B2 (en) Method, user equipment and application server for adding media stream of multimedia session
US9300696B2 (en) Method of sharing one or more media in a session between terminals
US9026663B2 (en) Method, apparatus and program product for merging communication sessions in an IMS
US8725802B2 (en) Method for transferring file in conference system, file transfer system and conference server
US20100169495A1 (en) Method, apparatus, and system for processing continuity of media streams in a session
US20100146142A1 (en) Method, application server and user equipment for transferring media streams of multimedia session
US9848022B2 (en) Method and apparatus for inter-device transfer (handoff) between IMS and generic IP clients
US20110116495A1 (en) Method and apparatus for inter-device session transfer between internet protocol (ip) multimedia subsystem (ims) and h.323 based clients
US9531816B2 (en) Method and apparatus for media transfer between user equipment
WO2009018755A1 (fr) Procédé de session multi-terminal, système de communication et dispositifs associés
WO2011017889A1 (zh) 一种多媒体会议的实现方法及系统
WO2009155824A1 (zh) 一种彩铃、彩像业务的实现方法及系统
WO2009149635A1 (zh) 一种实现显式呼叫转移的方法、设备及移动通信系统
WO2009046653A1 (fr) Procédé, dispositif et système d&#39;application de lignes directrices
WO2007062609A1 (fr) Procede, serveur d&#39;application et systeme pour la mise en oeuvre de service de controle de tiers
WO2011018008A1 (zh) 一种i1接口的业务控制方法、装置和系统
WO2009049518A1 (fr) Procédé, système et entité d&#39;établissement de session de système de télévision par internet ip
WO2009121310A1 (zh) 一种网关选择的方法、系统及设备
WO2010022603A1 (zh) 附着到对等网络及获取iptv内容的方法、系统和装置
WO2009046645A1 (fr) Procédé pour la réalisation d&#39;une interaction entre un service de transfert aveugle de conversation et un service de session
JP6549523B2 (ja) 要求先端末のオプション機能の非使用を整合する網間制御方法、ｓｉｐサーバ及びプログラム
WO2010075719A1 (zh) 一种多媒体会话在接入网间转移的方法、装置及系统
KR20110066034A (ko) 단말 간 전달 기술에서의 관리 권한의 전달 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11741853

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2011741853

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2011741853

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE