WO2011023074A1 - 多会话转移方法及呼叫控制设备和业务连续性服务器 - Google Patents

多会话转移方法及呼叫控制设备和业务连续性服务器 Download PDF

Info

Publication number
WO2011023074A1
WO2011023074A1 PCT/CN2010/076132 CN2010076132W WO2011023074A1 WO 2011023074 A1 WO2011023074 A1 WO 2011023074A1 CN 2010076132 W CN2010076132 W CN 2010076132W WO 2011023074 A1 WO2011023074 A1 WO 2011023074A1
Authority
WO
WIPO (PCT)
Prior art keywords
session
transfer
transferred
scc
network domain
Prior art date
Application number
PCT/CN2010/076132
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=43627248&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO2011023074(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by 华为终端有限公司 filed Critical 华为终端有限公司
Priority to ES10811234.3T priority Critical patent/ES2465218T5/es
Priority to EP10811234.3A priority patent/EP2464166B2/en
Publication of WO2011023074A1 publication Critical patent/WO2011023074A1/zh
Priority to US13/408,371 priority patent/US10021602B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • H04W36/00224—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB]
    • H04W36/00226—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB] wherein the core network technologies comprise IP multimedia system [IMS], e.g. single radio voice call continuity [SRVCC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • 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
    • 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/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a multi-session transfer method, a call control device, and a service continuity server. Background technique
  • the IMS Service Continuity (SC) technology is to implement the IP Multimedia Subsystem (IMS) user (User Equipment, UE) when moving between different access networks without interrupting the currently ongoing IMS. Tongue, to ensure a good user experience, the core of the SC is the Service Centralization and Continuity AS (SCC AS), SCC AS is used to control the user's session transfer on multiple networks.
  • IMS IP Multimedia Subsystem
  • UE User Equipment
  • IMS Centralized Service (ICS) UE is an IMS UE with enhanced ICS capability.
  • ICS capability usually refers to the ability to support Gm or II interfaces. Otherwise, non ICS UE refers to not supporting Gm, II interfaces, or supports this interface. However, UEs that do not use this interface to transmit signaling during the communication process.
  • the normal voice session is transferred from the Packet Switched (PS) domain to the Circuit Switched (CS) domain, and CS domain signaling (for example, setup message) is initiated in the CS domain as a transfer request.
  • PS Packet Switched
  • CS domain signaling for example, setup message
  • the session transfer number (STO) is the called number.
  • the UE Since the multi-session (session) transfer of the PS to the CS of the Non ICS UE only supports the transfer of two sessions, the UE releases the other sessions except the two sessions to be transferred before the transfer request is initiated. If the UE does not release successfully, the SCC AS receives After the transfer request, the transfer request needs to be associated with the to-be-transferred session. If there are more than two sessions at this time, the SCC AS can also initiate the session release.
  • the specific solution is to first transfer the active state session (if there is no active state session, only the most recently held session is transferred), after the transfer, the SCC AS will save the previous active state session or the most recently held state session information except the most recent active state session.
  • the MSC Server mobile switching center server
  • the MSC Server initiates the transfer of the second session instead of the UE.
  • the inventors of the present invention found that when the UE ZAPS network is transferred to the CS network, and the UE contains multiple sessions, when the transferred second session is a multimedia session, The technology does not consider that there may be an abnormal situation in which the second session cannot be transferred due to the fact that the current radio access network (RAN) of the UE does not support Video media transmission or the current network resources are insufficient to support video (Video) media transmission. .
  • RAN radio access network
  • the embodiment of the present invention provides a multi-session transfer method, a call control device, and a service continuity server, which can implement processing of a video medium that is not supported by the current network during the multi-session transfer process.
  • the multi-transfer method provided by the embodiment of the present invention after completing the transfer of the first session of the terminal from the source network domain to the target network domain, includes:
  • the mobile switching center server MSC Server Receiving, by the mobile switching center server MSC Server to which the target network domain belongs, status information of the second to-be-transferred session of the terminal that is sent by the centralized service and the service continuity SCC AS; the status information includes the a media type of the second session to be transferred, the media type including a video type;
  • the MSC Server determines that the target network domain cannot transmit video data, the MSC Server initiates a transfer request to the SCC AS for the voice media of the second to-be-transferred session, so that the SCC AS receives After the request, the second to-be-transferred session is converted into a voice session for transfer or the second to-be-transferred session is released.
  • the multimedia session transfer method provided by the embodiment of the present invention after completing the transfer of the first session of the terminal from the source network domain to the target network domain, includes:
  • the SCC AS Sending, by the SCC AS, status information of the second to-be-transferred session of the terminal to the MSC Server to which the target network domain belongs;
  • the status information includes a media type of the second to-be-transferred session, and the media type package Home video type;
  • the SCC AS receives the second to-be-transferred session transfer failure indication sent by the MSC Server because the target network domain cannot transmit video data, then the second to-be-transferred session transfer is converted into a voice session for transfer or Release the second pending transfer session.
  • a receiving unit configured to receive status information of a second to-be-transferred session of the terminal that is sent by the SCC AS, where the status information includes a media type of the second to-be-transferred session, and the media class Type contains the video type;
  • a session transfer control unit configured to determine whether the target network domain of the session transfer can transmit video data, and if not, initiate a transfer request to the SCC AS for the voice media of the second to-be-transferred session, so that the SCC After receiving the request, the AS converts the second to-be-transferred session to a voice session or drys the second to-be-transferred session.
  • a receiving unit configured to receive status information of a second to-be-transferred session of the terminal that is sent by the SCC AS; the status information includes a media type of the second to-be-transferred session, and the media type includes a video type;
  • a session transfer control unit configured to determine whether the target network domain of the session transfer can transmit video data, and if not, initiate the second to-be-transfer session transfer failure indication to the SCC AS, so that the SCC AS receives After the request, the second to-be-transferred session is transferred to a voice session or the second to-be-transferred session is released.
  • a sending unit configured to send status information of the second to-be-transferred session of the terminal to the MSC Server to which the terminal belongs;
  • the status information includes a media type of the second to-be-transferred session, and the media type includes a video type ;
  • a session processing unit configured to receive a transfer request of the voice media initiated by the MSC Server for the second to-be-transferred session, and convert the second to-be-transferred session transfer into a voice session to transfer or release the second The session to be transferred.
  • a sending unit configured to send status information of the second to-be-transferred session of the terminal to the MSC Server to which the terminal belongs, where the status information includes a media type of the second to-be-transferred session, and the media type includes a video type;
  • a session processing unit configured to receive the second to-be-transfer session transfer failure indication sent by the MSC Server because the target network domain cannot transmit video data, and convert the second to-be-transferred session transfer into a voice session for transfer or release The second session to be transferred.
  • the mobile switching center server judges the capability of the current network support, When the current network cannot transmit the video media, initiate a transfer request for the voice media of the second to-be-transferred session, and the centralized service and the service continuity server (SCC AS) receive the transfer request, and the second to-be-transferred session
  • SCC AS service and the service continuity server
  • the transfer is converted into a voice session or the second to-be-transferred session is released, so as to avoid the problem that the network that appears in the prior art cannot complete the session transfer, so that the multi-session transfer service across the network is more perfect.
  • FIG. 1 is a flowchart of a multi-session transfer method according to an embodiment of the present invention
  • FIG. 2 is a flowchart of a multi-session transfer method according to Embodiment 2 of the present invention.
  • FIG. 3 is a flowchart of converting a second to-be-transferred session transfer into a voice session according to an embodiment of the present invention
  • FIG. 5 is a signaling flowchart of Application Example 2 of the embodiment of the present invention.
  • FIG. 7 is a schematic structural diagram of a call control device according to Embodiment 3 of the present invention.
  • FIG. 8 is a schematic structural diagram of a call control device according to Embodiment 4 of the present invention.
  • FIG. 9 is a schematic structural diagram of a service continuity server according to Embodiment 5 of the present invention.
  • FIG. 10 is a schematic structural diagram of a service continuity server according to Embodiment 6 of the present invention. detailed description
  • Embodiments of the present invention provide a multi-session transfer method, a call control device, and a service continuity server. The details are described below separately.
  • Embodiment 1 A multi-session transfer method, as shown in FIG. 1 , after completing the transfer of the first session of the terminal from the source network domain to the target network domain, the method includes: Bl, the terminal receives the centralized service and the service continuity server (Service Centralization and Continuity AS) in the mobile switching center server (MSC Server) to which the target network domain belongs.
  • the service continuity server Service Centralization and Continuity AS
  • MSC Server mobile switching center server
  • the status information includes a media type of the second to-be-transferred session, and the media type includes a video type;
  • the terminal is a Non ICS UE or a user equipment having a similar function
  • the source network domain is a PS network domain name
  • the target network domain is a CS domain.
  • the mobile switching center server determines that the target network domain cannot transmit video data, the mobile switching center server initiates a transfer request to the SCC AS for the voice media of the second to-be-transferred session, and the SCC AS receives the After the request, the second to-be-transferred session is transferred to a voice session or the second to-be-transferred session is released.
  • the method may further include:
  • the MSC Server receives the failure response message sent by the SCC AS for the transfer request, and deletes the session state information of the second to-be-transferred session.
  • the target network cannot transmit video data for various reasons, for example: the access network does not support, the network bandwidth does not support, and the network resources are insufficient (the video service needs to occupy more resources than the voice service).
  • the request for initiating a transfer of the voice media to the second to-be-transferred session to the SCC AS may be implemented in the following manner:
  • the core network device sends only the session transfer request of the voice media to the SCC AS, and the video media transmission port number in the media line information in the request is set to 0, and only the transfer of the voice media is requested, so that the SCC AS receives the request. Thereafter, the second to-be-transferred session may be converted into a voice session for transfer or the second to-be-transferred session may be released.
  • the manner in which the specific mobile switching center server requests the SCC AS to convert the video session into a voice session may also be various, and does not constitute a limitation of the present invention.
  • the mobile switching center server judges the current network support capability, and when the current network cannot transmit the video media, initiates Receiving the transfer request of the voice media of the second to-be-transferred session, the centralized service and the service continuity server (SCC AS) receiving the transfer request, converting the second to-be-transferred session transfer into a voice session, or releasing the first Two sessions to be transferred,
  • the multi-session transfer service across the network is more perfect.
  • Embodiment 2 A multi-session transfer method, as shown in FIG. 2, after completing the transfer of the first session of the terminal from the source network domain to the target network domain, the method includes:
  • the CI the SCC AS sends the status information of the second to-be-transferred session of the terminal to the mobile switching center server to which the target network domain belongs;
  • the status information includes the media type of the second to-be-transferred session,
  • the media type includes a video type;
  • the releasing the second to-be-transferred session includes: releasing the second to-be-transferred session in the source network domain, and interacting with the communication peer end of the terminal to complete the communication peer access branch. Update process. It can be understood that the present embodiment can also perform the release of the session in other ways, and the specific manner does not constitute a limitation of the present invention.
  • the centralized service and the service continuity server converts the second to-be-transferred session to a voice session or releases the second to-be-transferred session.
  • the multi-session transfer service across the network is more perfect.
  • the SCC AS receives the second to-be-transfer session transfer failure indication that is sent by the mobile switching center server because the target network domain cannot transmit video data, and may be implemented as follows:
  • the SCC AS receives the second to-be-transfer session transfer failure indication sent by the mobile switching center server; the second to-be-transfer session transfer failure indication includes: a transfer failure reason parameter, and the transfer failure reason parameter indication
  • the destination network domain cannot transmit the transmission of video data.
  • the second to-be-transferred session transfer failure indication may be carried by a Session Initiation Protocol (SIP) information delivery request message (INFO message) or an instant message (Massage).
  • SIP Session Initiation Protocol
  • INFO message information delivery request message
  • Massage instant message
  • the SCC AS Before the SCC AS receives the second to-be-transfer session transfer failure indication sent by the mobile switching center server because the target network domain cannot transmit video data, the SCC AS includes: the SCC AS to the mobile switching center The server sends a subscription request ( SUBSCRIBE ) Message
  • the second to-be-transfer session transfer failure indication sent by the SCC AS to the mobile switching center server because the target network domain cannot transmit video data includes:
  • Notify Receiving a notification (Notify) message of the subscription request returned by the core network device, where the Notify message includes the second to-be-transferred session transfer failure indication.
  • the second to-be-transferred session is transferred to a voice session for transfer, which can be implemented in the following manner.
  • the flowchart is as shown in FIG. 3, and specifically includes:
  • the manner in which the server re-initiates the voice session transfer request may take the response of the reply message 200 OK or the Massage message of returning the INFO message or the Notify message to the mobile switching center server.
  • the communication peer end interaction with the terminal completes the update process of the communication peer access branch.
  • the specific completion of the update of the communication peer access branch can be implemented by the following process:
  • the SCC AS binds the call branch of the second to-be-transferred session in the H-target network domain to the call branch of the SCC AS and the communication peer;
  • the SCC AS is equivalent to a B2BUA (Back-to-Back Agent), which implements communication between the two parties through the SCC AS.
  • B2BUA Back-to-Back Agent
  • the communication peer interaction with the terminal updates the video media of the second to-be-transferred session to audio media. Because the second session is a video session between the terminal and the communication peer in the source network, the SCC AS needs to perform media negotiation with the communication peer to convert the video session into a voice session, and update related codec information, and the media negotiation can pass. Session Description Protocol (SDP M language implementation.
  • SDP M language implementation Session Description Protocol
  • the source network domain is the PS domain and the target network domain is the CS domain.
  • the MSC Server After receiving the multimedia session state information of the second to-be-transferred session, the MSC Server cannot initiate a multimedia session transfer for various reasons, and then initiates a voice media transfer request, which may be due to the current radio access network of the UE (radio access network) , RAN ) does not support video (Video) media transmission or network resources, etc., the flow chart shown in Figure 4:
  • F1-F4 is the same as that described in steps A1 to A4 of Fig. 1 of the prior art.
  • SCC AS determines whether the MSC Server where the UE is located supports Video. If the session state information of the multimedia session is delivered, the media type including Video needs to be indicated in the session state information.
  • the SCC AS releases the video media of the session in the original PS domain in the subsequent steps, and sends the session state information of the voice session, indicates the audio media type in the session state information, and causes the video media to
  • the media line port number of ( video ) is set to 0.
  • the SCC AS sends the selected session state information to the Serving Session Control Function (S-CSCF) or the Intersession Control Function Entity (I-CSCF) through the reply message (200 OK) of the INVITE request.
  • S-CSCF Serving Session Control Function
  • I-CSCF Intersession Control Function Entity
  • the S-CSCF sends a 200 OK reply message to the MSC Server.
  • the MSC Server receives the session state information of the second session (multimedia session), and determines whether the video transmission can be supported according to the current UE RAN and resource status.
  • F9a if the current network supports video transmission, initiate a transfer request of the multimedia session according to the prior art, and complete the peer update and session transfer.
  • the port number of the Video media is set to 0 in the SDP information in the sent Invite request.
  • the Invite request is sent by the S-CSCF to the SCC AS.
  • the SCC AS determines that the transfer request corresponding session is a multimedia session including video media, and selects to convert the multimedia session into a voice session, and then releases the video media of the original PS domain, that is, the SCC AS generates a re-INVITE according to the saved SDP information.
  • the request is made, and the port number corresponding to the Video media line in the SDP information is set to 0, and the release media request is sent to the local UE through the S-CSCF.
  • the SCC AS may find that the corresponding session has Video media, and according to the policy, refuse to convert the multimedia session into a voice session, and then return 4** After responding (such as 403 forbidden), and releasing the multimedia session, after the multimedia session is released, the peer can be updated, and step F22 is performed.
  • a specific policy may be configured in advance on the SCC AS. After receiving the 4** return message, the MSC Server deletes the session state information of the session.
  • the Video media on the UE is deleted, the UE sends a reply message 200 OK of the re-I VITE request, and the reply message is sent to the SCC AS via the S-CSCF.
  • the SCC AS sends an acknowledgment message ACK of the reply message, and is sent by the S-CSCF to the UE.
  • the SCC AS updates the peer with the SDP information of the INVITE request sent by the MSC Server.
  • the SCC AS responds to the INVITE request with a 200 OK response, and the 200 OK response is sent to the MSC Server via the S-CSCF.
  • the MSC Server sends an acknowledgment message ACK, and the ACK is sent to the SCC AS via the S-CSCF to complete the establishment of the access leg of the second session in the CS domain.
  • the SCC AS releases the session of the UE in the original PS domain.
  • the MSC Server when the MSC Server determines that the CS domain does not support Video media transmission, the MSC Server initiates the transfer of the voice media of the multimedia session, and further triggers the SCC AS to release the Video media of the original network domain, thereby realizing that the network condition is not allowed.
  • the multimedia session will be the transfer of the voice session.
  • the embodiment is intended to send an INFO message through the signaling channel of the first session that has been established, indicating that the SCC AS cannot transfer the second session.
  • the SCC AS releases the Video media of the PS domain after receiving the message, and then instructs the MSC Server to initiate the transfer of the voice media through the INFO message.
  • the flow chart is shown in Figure 5:
  • Gl-G9a which is the same as application example F1 to F9a, will not be described again.
  • the MSC Server initiates an INFO message, and the INFO message is transmitted in the channel established by the first session, and the INFO message carries the second session cannot be transferred.
  • the specific non-transfer indication can be carried by the message header or the message body, as follows: 1.
  • the message header carries: For example:
  • the destination header of the INFO message carries the untransferable Instructed: Since the subject header is intended to indicate the purpose of the call, in this embodiment, the subject header is extended, that is, the purpose of the INFO message is to indicate that the session cannot be transferred, and the reason for the inability to transfer is included.
  • the message body carries: In the message body of the INFO, the indication that the INFO message is to be delivered cannot be transferred, and the reason why the video cannot be transferred is "Video-not-supported" or "Lack-resource” .
  • the specific message body can use the Extensible Markup Language (XML) format, as follows:
  • the aes item describes the information about the second session
  • the i attribute indicates the Call-ID of the second session in the PS domain
  • the It attribute indicates the UE identity of the local end (the corresponding end of the MSC Server)
  • the rt attribute indicates the pair.
  • End UE identifier lUri indicates the local UE identity
  • rUri indicates the peer UE identity
  • s indicates the transition status options: success "success", failure "fail”, retry "retry”, if failed, cause Indicates the reason for the failure.
  • the possible causes are "Video-not-support” or "lack_resource” 0
  • the accept header and the Content-Type header of the INFO message are set to application/vnd.3gpp.ati+xml.
  • the G10b-Gl lb, INFO message is sent to the SCC AS via the S-CSCF.
  • SCC AS receives the INFO message and returns a successful response 200 OK, 200 OK is sent to the MSC Server through the S-CSCF.
  • Step G14b SCC AS parses the s field and the cause field of the message body of the INFO message, and finds that the multimedia session cannot be successfully transferred due to the above reasons, then the multimedia session is converted into a voice session for transfer, and the video media process of releasing the multimedia session is the same as the application example. Steps Fllb-F15b, and complete the peer update process. Of course, the SCC AS may choose to release the session without transferring the session. If the SCC AS releases the session, step G20b is directly executed. If the MSC Server does not receive the INFO message within a certain period of time, the transfer request is not initiated, and the second session to be transferred is related. The status information is deleted.
  • the SCC AS If the video media is successfully released, the SCC AS generates an INFO message indicating that the Video media has been successfully released and requires the MSC Server to re-initiate the transfer request for the session voice media.
  • the indication of initiating the transfer request may be indicated in the message body of the INFO message or in the subject message header. If given in the subject message header, "transfer voice" is written in the message header, if indicated in the message body, the message body The form is as follows:
  • the G15b-G16b, INFO message is sent to the MSC Server via the S-CSCF.
  • the MSC Server receives the INFO message and returns a successful response.
  • 200 OK is sent to the SCC AS via the S-CSCF.
  • the MSC Server receives the INFO message to parse the s field and the cause field, and re-initiates the transfer request Invite for the session by using the session information.
  • SCC AS receives the transfer request from the MSC Server in the CS domain and performs the peer update process.
  • the paper mode of the SIP message can replace the INFO message to complete the above operation, and the operation process is the same as above. If the SCC AS does not successfully release the Video media, it does not have to send an INFO message to notify the MSC Server to further release the second session in the original PS network. If the MSC Server does not receive the INFO message within a certain period of time, the transfer request is not initiated, and the related session state information of the second to-be-transferred session is deleted.
  • the SF (or Message message paper mode) of the Session Initiation Protocol (SIP) is used to implement the indication of the transfer failure information, so that the SCC AS converts the multimedia session to the case that the network does not support Video or insufficient network resources.
  • the MSC Server is notified by the INFO or Message message, and the MSC Server re-initiates the transfer request for the voice session. Since the INFO message and the Message message in the paper mode are both transmitted in the first session channel that has been established. Input, assuming that the MSC Server determines the network condition and exchanges information with the SCC AS, the first session will not be released.
  • the MSC Server subscribes to the transfer status of the second session, and learns whether the session is successfully transferred. If the failure occurs because the target network cannot transmit video media (video), the video media is further released, and the MSC Server is notified to initiate. Transfer of voice media to the second session to be transferred. Since the subscription request does not depend on the session, it can be subscribed within the first established session channel, or a new session subscription can be established.
  • the specific flow chart is shown in Figure 6, including:
  • the SCC AS sends a subscription request (subscribe), and the request-URI requested by the UE-related event is the UE identity information, and the subscription request indicates the subscription event through the event header or the request message body, where the subscription event is the second to-be-transferred session. Whether the transfer is successful, set the event header to "sscond-transfer".
  • the accept header of the request indicates the message body format of the supported Notify message, here using the xml type, set to: "application/vnd.3gpp.ati+xml" .
  • the SCC AS can issue the subscription request only when the second session to be transferred is a multimedia session.
  • the response message related to the subscription success is omitted here.
  • the subscription request is sent to the MSC Server via the S-CSCF ⁇
  • the MSC Server receives the session state information of the second to-be-transferred session (multimedia session), and determines whether the video transmission is supported according to the current UE network condition.
  • Hl la if the current network (network status or network resource) supports video transmission, initiate a transfer request of the multimedia session according to the prior art.
  • the second transfer session (multimedia session) is successfully transferred, and the MSC Server sends a Notify message to notify the SCC AS.
  • the content of the notification message is reflected in the Notify xml format message body.
  • the xml message body format is application/vnd.3gpp.ati+xml. See application example 2, and the s attribute is set to "success".
  • the Gauss property is set.
  • the Notify message is sent to the SCC AS via the S-CSCF.
  • MSC Server determines that the current network cannot transfer video media, then generates a Notify message with a transfer failure, the format is application/vnd.3gpp.ati+xml, s is 4 is "fail", and the cause cannot be transferred.
  • the reason for the conversation is "Video- not-supported” or "lack-resource”. The specific meaning is the same as application example 2.
  • the message body of the application vnd.3gpp.ati+xml format also includes session related information of the transfer session, where the Notify reply message may include the session information (other items except the "s" and "cause” attributes) to facilitate
  • the SCC AS performs the judgment and release operations, and may not include the session information but only the attributes s and causes.
  • the SCC AS knows the subscription event and can learn the session information of the second to-be-transferred session according to the saved session information.
  • H12b the Notify message is sent to the S-CSCF.
  • the Notify message is sent by the S-CSCF to the SCC AS.
  • the SCC AS receives the Notify message, parses the notification message content s and the cause value field, and learns that the multimedia session cannot be successfully transferred due to the above reasons, and the SCC AS selects to convert the multimedia session into a voice session according to the application example.
  • Step F 11 bF 15b Release the Video media in the PS domain and complete the peer update process.
  • the SCC AS may choose to release the session without transferring the session. If the SCC AS releases the session, reply 200 OK to the Notify message, and update the peer directly to perform step H21.
  • the MSC Server does not initiate the transfer request after receiving the re-initiation request within a certain period of time, and deletes the related session state information of the second to-be-transferred session.
  • the SCC AS sends a Notify response message 200 OK, and if the SCC AS successfully releases the Video media, in the message body of the 200 OK, the MSC Server is instructed to re-initiate the request for the session voice media.
  • the message body is the same as application example two:
  • the MSC Server does not initiate the transfer request after receiving the re-initiation request within a certain period of time, and deletes the related session status information of the second to-be-transferred session.
  • the H16b, 200 OK response is sent to the MSC Server via the S-CSCF.
  • the MSC Server receives the response message, and obtains a request for transfer of the originating voice media by parsing the message body.
  • H18b-H19b if the transfer succeeds, sends a notification message to the SCC AS.
  • the specific message content is the same as described in H12a.
  • H20b update the peer end, complete the session connection between the UE and the communication peer.
  • the SCC AS can cancel the subscription relationship with the MSC Server.
  • the SCC AS subscribes to the second session transfer state and receives the MSC Server notification message, and triggers the SCC AS to release the Video media when the network does not allow the multimedia session to be transferred, and converts the multimedia session into a voice session for transfer, by the MSC Server.
  • the transfer of the voice media of the session is initiated again, or the SCC AS releases the second pending transfer session without transferring.
  • the program can be stored in a computer readable storage medium.
  • the storage medium can include: ROM, RAM, disk or CD, etc.
  • Embodiment 3 is a schematic diagram of a call control device, as shown in FIG. 7 , including: a receiving unit 810, configured to receive status information of a second to-be-transferred session sent by an SCC AS;
  • the media type of the second to-be-transferred session is a video type;
  • the session transfer control unit 820 is configured to determine whether the target network domain of the session transfer can transmit video data, and if not, send the second to the SCC AS.
  • Voice of the session to be transferred The transfer request of the media, so that after the SCC AS receives the request, the second to-be-transferred session is transferred to a voice session or the second to-be-transferred session is placed.
  • the call control device in this embodiment transfers the second to-be-transferred session of the user, if it is found that the target network domain cannot support the video data transmission, the requesting to the SCC AS directly initiates the second waiting. Transferring the voice media transfer request of the session, for example: setting the video media transmission port number in the media line information of the request to 0, and requesting only the transfer of the voice media, so that the SCC AS may, after receiving the request, The second to-be-transferred session is converted to a voice session for transfer or the second to-be-transferred session is released.
  • the multi-session transfer service across the network is more perfect.
  • Embodiment 4 is a call control device.
  • the structure of the call control device is as follows.
  • the receiving unit 910 is configured to receive status information of a second to-be-transferred session of the terminal sent by the SCC AS. a media type of the second to-be-transferred session, where the media type includes a video type;
  • the session transfer control unit 920 is configured to determine whether the target network domain of the session transfer can transmit video data, and if not, initiate the second to-be-transfer session transfer failure indication to the SCC AS, so that the SCC AS receives the request. Afterwards, the second to-be-transferred session is transferred to a voice session or the second to-be-transferred session is released.
  • the call control device in this embodiment fails to initiate the transfer of the second to-be-transfer session to the SCC AS if the target network domain cannot support the video data transmission when the user's second to-be-transferred session is transferred. Instructed to cause the SCC AS to receive the failure indication for subsequent processing. In order to avoid the problem that the network in the prior art cannot complete the session transfer, the multi-session transfer service across the network is more perfect.
  • the call control device of the third embodiment and the fourth embodiment may be a network entity having a call control function in a circuit switched network, such as a mobile switching center server or the like.
  • Embodiment 5 is a service continuity server.
  • the structure is as shown in FIG. 9.
  • the sending unit 1010 is configured to send, to the mobile switching center server to which the terminal belongs, status information of the second to-be-transferred session of the terminal.
  • the status information includes a media type of the second to-be-transferred session, and the media type includes a video type;
  • the session processing unit 1020 is configured to receive the pair initiated by the mobile switching center server.
  • the transfer request of the voice media of the second to-be-transferred session converts the second to-be-transferred session into a voice session to transfer or release the second to-be-transferred session.
  • the method for providing the call control device and the service continuity server provided by the embodiment of the present invention can be referred to the description of the multiple embodiments of the present invention provided above, and is not repeated here.
  • Embodiment 6 is a service continuity server, and a schematic structural diagram is shown in FIG. 10, including: a sending unit 1110, configured to send, to a mobile switching center server to which the terminal belongs, state information of a second to-be-transferred session of the terminal; The status information indicates that the media type of the second to-be-transferred session is a video type;
  • the session processing unit 1120 is configured to receive the second to-be-transferred session transfer failure indication sent by the mobile switching center server because the target network domain cannot transmit video data, and convert the second to-be-transferred session transfer into a voice session. Transfer or release the second pending transfer session.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Description

多会话转移方法及呼叫控制设备和业务连续性服务器 技术领域
本发明涉及通信技术领域， 具体涉及多会话转移方法及呼叫控制设备 和业务连续性服务器。 背景技术
IMS会话连续性 (IMS Service Continuity, SC)技术是实现 IP多媒体子系 统（IP multimedia subsystem, IMS )用户 （ User Equipment, UE )在不同接 入网络之间移动时，不中断当前正在进行的 IMS^舌，确保良好的用户体验， SC的核心是集中业务和业务连续性服务器（ Service Centralization and Continuity AS, SCC AS ), SCC AS用于对用户在多个网络的会话转移进行 控制。
IMS集中业务（ IMS Centralized Service, ICS ) UE是一个增强了 ICS能 力的 IMS UE,具有 ICS能力通常指支持 Gm或 II接口的能力，反之 non ICS UE 指不支持 Gm、 II接口， 或支持此接口但在通信过程不使用此接口传送信令 的 UE。
对于 Non ICS UE普通语音会话由分组交换（ Packet Switched, PS )域转 移到电路交换（ Circuit Switched, CS )域， 在 CS域发起 CS域信令（例如： setup消息）作为转移请求， 请求包舍的会话转移号码（ Session Transfer Number, STO ) 为被叫号码， SCC AS收到该请求并由 STN值获知该请求为 转移请求， 则关联与之相关的 PS域会话， 更新对端， 释放 PS域相关会话， 完成转移过程。
由于 Non ICS UE的 PS到 CS的多会话（ session )转移只支持转移两个会 话的情况， UE在发起转移请求前释放待转移两个会话外的其它会话， 如果 UE没有释放成功， SCC AS收到转移请求后， 需要将此转移请求与待转移会 话关联， 如果此时存在多于两个会话， SCC AS也可以发起会话释放。 具体 解决方案为， 首先转移激活状态会话（若无激活状态会话， 则只转移最近 保持的会话），转移后 SCC AS将除最近激活状态会话外的前一个激活状态会 话或最近被 hold状态会话信息发送给移动交换中心服务器（ MSC Server )， 由 MSC Server代替 UE发起第二个会话的转移。 发明人在对现有技术的研究和实践过程中， 本发明的发明人发现当 UE ZAPS网络向 CS网络转移 , 且 UE中包含多个会话 , 当转移的第二个会话是多 媒体会话时， 现有技术没有考虑可能存在由于 UE当前无线接入网 （radio access network, RAN )不支持 Video媒体传输或当前网络资源不足以支持视 频（Video )媒体传输而出现的无法转移第二个会话的异常情况。
发明内容
本发明实施例提供多会话转移方法及呼叫控制设备和业务连续性服务 器， 可以实现多会话转移过程中， 对当前网络不支持视频媒体的处理。
本发明实施例提供的一种多^^转移方法， 当完成将终端的第一个会 话由源网络域向目标网络域的转移后， 包括：
所述终端在目标网络域所属的移动交换中心服务器 MSC Server接收集 中业务和业务连续性^ _务器 SCC AS发送的所述终端第二个待转移会话的状 态信息； 所述状态信息包含所述第二个待转移会话的媒体类型， 所述媒体 类型包含视频类型；
若所述 MSC Server判断所述目标网络域无法传输视频数据 , 则所述 MSC Server向所述 SCC AS发起对所述第二个待转移会话的语音媒体的转移 请求， 以使所述 SCC AS收到该请求后， 将所述第二个待转移会话转换为语 音会话进行转移或者释放所述第二个待转移会话。
本发明实施例提供的一种多媒体会话转移方法， 当完成将终端的第一 个会话由源网络域向目标网络域的转移后 , 包括：
所述 SCC AS向终端在目标网络域所属的 MSC Server发送所述终端第二 个待转移会话的状态信息； 所述状态信息包含所述第二个待转移会话的媒 体类型， 所述媒体类型包舍视频类型；
若所述 SCC AS收到所述 MSC Server因为目标网络域无法传输视频数据 而发送的所述第二个待转移会话转移失败指示， 则将第二个待转移会话转 移转换为语音会话进行转移或者释放所述第二个待转移会话。
本发明实施例提供的一种呼叫控制设备， 包括：
接收单元， 用于接收 SCC AS发送的所述终端第二个待转移会话的状态 信息； 所述状态信息包含所述第二个待转移会话的媒体类型， 所述媒体类 型包含视频类型；
会话转移控制单元， 用于判断会话转移的目标网络域是否可以传输视 频数据， 若不可以， 则向 SCC AS发起对所述第二个待转移会话的语音媒体 的转移请求， 以使所述 SCC AS收到该请求后， 将所述第二个待转移会话转 移转换为语音会话或者幹放所述第二个待转移会话。
本发明实施例提供的一种呼叫控制设备， 包括：
接收单元， 用于接收 SCC AS发送的所述终端第二个待转移会话的状态 信息； 所述状态信息包含所述第二个待转移会话的媒体类型， 所述媒体类 型包含视频类型；
会话转移控制单元， 用于判断会话转移的目标网络域是否可以传输视 频数据， 若不可以， 则向所述 SCC AS发起所述第二个待转移会话转移失败 指示， 以使所述 SCC AS收到该请求后， 将所述第二个待转移会话转移转换 为语音会话或者释放所述第二个待转移会话。
本发明实施例提供的一种业务连续性服务器， 包括：
发送单元， 用于终端所属的所述 MSC Server发送所述终端第二个待转 移会话的状态信息； 所述状态信息包含所述第二个待转移会话的媒体类型， 所述媒体类型包含视频类型；
会话处理单元 , 用于接收所述 MSC Server发起的对所述第二个待转移 会话的语音媒体的转移请求， 将第二个待转移会话转移转换为语音会话进 行转移或者释放所述第二个待转移会话。
本发明实施例提供的一种业务连续性服务器， 包括：
发送单元， 用于向终端所属的 MSC Server发送所述终端第二个待转移 会话的状态信息， 所述状态信息包含所述第二个待转移会话的媒体类型， 所述媒体类型包含视频类型；
会话处理单元 , 用于接收所述 MSC Server因为目标网络域无法传输视 频数据而发送的所述第二个待转移会话转移失败指示， 将第二个待转移会 话转移转换为语音会话进行转移或者释放所述第二个待转移会话。 本发明实施例中， 在多会话跨网络转移过程中， 且待转移的第二个会话 包含视频频媒体时， 移动交换中心服务器对当前网络支持的能力进行判断， 在当前网络无法传输视频媒体时， 发起对所述第二个待转移会话的语音媒 体的转移请求， 集中业务和业务连续性服务器（SCC AS )接收所述转移请 求， 将第二个待转移会话转移转换为语音会话或者释放所述第二个待转移 会话， 以避免现有技术中出现的网络无法完成会话转移的问题， 使得跨网 络的多会话转移业务更加完善。 附图说明
图 1是本发明实施例一多会话转移方法的流程图；
图 2是本发明实施例二多会话转移方法的流程图；
图 3是本发明实施例中将第二个待转移会话转移转换为语音会话进行 转移的流程图；
图 4是本发明实施例应用例一的信令流程图；
图 5是本发明实施例应用例二的信令流程图；
图 6是本发明实施例应用例三的信令流程图；
图 7是本发明实施例三呼叫控制设备的结构示意图；
图 8是本发明实施例四呼叫控制设备的结构示意图；
图 9是本发明实施例五业务连续性服务器的结构示意图；
图 10是本发明实施例六业务连续性服务器的结构示意图。 具体实施方式
下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进 行清楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而不是全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没 有作出创造性劳动前提下所获得的所有其他实施例， 都属于本发明保护的 范围。
本发明实施例提供多会话转移方法及呼叫控制设备和业务连续性服务 器。 以下分别进行详细说明。
实施例一、 一种多会话转移方法， 流程图如图 1所示， 当完成将终端的 第一个会话由源网络域向目标网络域的转移后， 包括： Bl , 终端在目标网络域所属的移动交换中心服务器（ MSC Server )接 收集中业务和业务连续性服务器（ Service Centralization and Continuity AS ,
SCC AS )发送的所述终端第二个待转移会话的状态信息； 所述状态信息包 含所述第二个待转移会话的媒体类型， 所述媒体类型包含视频类型；
本实施例中， 所述终端为 Non ICS UE或具有类似功能的用户设备， 所 述源网络域为 PS网络域名， 所述目标网络域为 CS域。
B2, 若所述移动交换中心服务器判断所述目标网络域无法传输视频数 据， 则移动交换中心服务器向 SCC AS发起对所述第二个待转移会话的语音 媒体的转移请求， SCC AS收到该请求后，将所述第二个待转移会话转移转 换为语音会话或者释放所述第二个待转移会话。
本发明实施例中， 所述 SCC AS释放所述第二个待转移会话之后还可以 包括：
MSC Server接收 SCC AS发送的对所述转移请求的失败响应消息， 将所 述第二个待转移会话的会话状态信息删除。
可以理解， 目标网络无法传输视频数据可能有多种原因， 例如： 接入 网络不支持、 网络带宽不支持、 网络资源不足（视频业务相对于语音业务 需要占用较多的资源）。
本实施例中， 所述向 SCC AS发起对所述第二个待转移会话的语音媒体 的转移请求可以通过以下方式实现：
具体的， 核心网设备向 SCC AS仅发送语音媒体的会话转移请求， 即将 请求中的媒体行信息中的视频媒体传输端口号置 0 , 仅请求语音媒体的转 移， 这样 SCC AS在收到该请求后， 则可以将所述第二个待转移会话转换为 语音会话进行转移或者释放所述第二个待转移会话。 具体的移动交换中心 服务器请求所述 SCC AS将视频会话转换为语音会话的方式还可以有多种， 不构成对本发明的限制。
实施例一中在多会话跨网络转移过程中， 且待转移的第二个会话包含视 频频媒体时，移动交换中心服务器对当前网络支持的能力进行判断，在当前 网络无法传输视频媒体时， 发起对所述第二个待转移会话的语音媒体的转 移请求， 集中业务和业务连续性服务器（SCC AS )接收所述转移请求， 将 第二个待转移会话转移转换为语音会话或者释放所述第二个待转移会话， 以避免现有技术中出现的网络无法完成会话转移的问题， 使得跨网络的多 会话转移业务更加完善。
实施例二、 一种多会话转移方法， 流程图如图 2所示， 当完成将终端的 第一个会话由源网络域向目标网络域的转移后， 包括：
CI , SCC AS向终端在目标网络域所属的所述移动交换中心服务器发送 所述终端第二个待转移会话的状态信息； 所述状态信息包含所述第二个待 转移会话的媒体类型 , 所述媒体类型包含视频类型；
C2, 若 SCC AS收到所述移动交换中心服务器因为目标网络域无法传输 视频数据而发送的所述第二个待转移会话转移失败指示， 则将第二个待转 移会话转移转换为语音会话进行转移或者释放所述第二个待转移会话。
本实施例中， 所述释放所述第二个待转移会话包括： 在源网络域释放 所述第二个待转移会话， 并与所述终端的通信对端交互完成通信对端接入 分支的更新过程。 可以理解， 本实施例还可以釆取现有的其他方式完成会 话的释放， 具体的方式不构成对本发明的限制。
本发明实施例二中， 在当前网络不支持视频会话时， 由集中业务和业 务连续性服务器 （SCC AS )将第二个待转移会话转移转换为语音会话或者 释放所述第二个待转移会话， 以避免现有技术中出现的网络无法完成会话 转移的问题， 使得跨网络的多会话转移业务更加完善。
实施例二中， SCC AS收到所述移动交换中心服务器因为目标网络域无 法传输视频数据而发送的所述第二个待转移会话转移失败指示可以采取以 下方式实现：
方式一、 SCC AS接收移动交换中心服务器发送的所述第二个待转移会 话转移失败指示； 所述第二个待转移会话转移失败指示中包含： 转移失败 原因参数， 所述转移失败原因参数指示目标网络域无法传输视频数据的传 输。 所述第二个待转移会话转移失败指示可以通过会话初始协议（Session Initiation Protocol, SIP ) 的信息传递请求消息 （INFO消息）或即时消息 ( Massage )携带。
方式二、 所述 SCC AS收到所述移动交换中心服务器因为目标网络域无 法传输视频数据而发送的所述第二个待转移会话转移失败指示之前包括： 所述 SCC AS向所述移动交换中心服务器发送订阅请求（ SUBSCRIBE ) 消息；
SCC AS接收所述移动交换中心服务器因为目标网络域无法传输视频数 据而发送的所述第二个待转移会话转移失败指示包括：
接收所述核心网设备返回的订阅请求的通知（ Notify )消息，所述 Notify 消息包含所述第二个待转移会话转移失败指示。
本发明实施例二中将第二个待转移会话转移转换为语音会话进行转 移， 可以采取以下方式实现， 流程图如图 3所示， 具体包括：
D1 , 在源网络域释放所述待转移会话的视频媒体；
D2, 通知所述移动交换中心服务器重新发起语音媒体类型的会话转移 请求， 以建立在所述第二个待转移会话在目标网络域的接入分支； 可以理 解， 所述通知所述移动交换中心 务器重新发起语音会话转移请求的方式 可以采取向所述移动交换中心服务器返回所述 INFO消息或者的 Notify消息 的回复消息 200OK或者 Massage消息的响应实现。
D3 , 与所述终端的通信对端交互完成通信对端接入分支的更新过程。 具体的完成通信对端接入分支的更新可以通过以下流程实现：
SCC AS将所述第二个待转移会话在 H标网络域的呼叫分支和与 SCC AS与所述通信对端的呼叫分支绑定；
SCC AS在将两个呼叫分支绑定的过程中， SCC AS相当于一个 B2BUA (背靠背代理）， 通过 SCC AS实现双方的通信。
与所述终端的通信对端交互将所述第二个待转移会话的视频媒体更新 为音频媒体。 因为在源网络中所述终端和通信对端进行第二会话为视频会 话，那么 SCC AS将视频会话转换为语音会话需要与通信对端进行媒体协商 , 更新相关的编解码信息，媒体协商可以通过会话描述协议（ SDP M言息实现。
可以理解， 在完成多会话转移后， 终端在源网络中的第二会话已经成 为冗余， SCC AS释放与所述终端在源网络域的呼叫分支。
为了更好的理解本发明， 下面提供本基于本发明实施例一和实施例二 应用具体通信协议的应用例， 下述应用例中， 源网络域为 PS域、 目标网络 域为 CS域。
应用例一、 MSC Server在收到第二个待转移会话的多媒体会话状态信息后， 由于 各种原因而无法发起多媒体会话转移 , 则发起语音媒体的转移请求， 原因 可能是 UE当前无线接入网（ radio access network, RAN )不支持视频（ Video ) 媒体的传输或网络资源不足等情况， 流程图如图 4所示：
F1-F4,与现有技术的图 1中步骤 A1到步骤 A4所描述内容相同不在赘述。
F5, SCC AS判断 UE所在 MSC Server是否支持 Video。 若支持则下发多 媒体会话的会话状态信息，需要在会话状态信息中指示媒体类型包括 Video。
若 MSC Server不支持 Video传输则 SCC AS在后续步骤中释放该会话在 原 PS域的 Video媒体， 下发语音会话的会话状态信息， 在会话状态信息中指 出语音 ( audio )媒体类型， 并令视频媒体 ( video )的媒体行端口号置 0。
F6, SCC AS将选择的会话状态信息通过 INVITE请求的回复消息（200 OK )发送到服务会话控制功能实体（ Server Call Session Control Function, S-CSCF )或访问会话控制功能实体（interrogating, I-CSCF ), 以下以 S-CSCF 为例进行说明， 对于 I-CSCF的处理情况相同。
F7， S-CSCF将 200 OK回复消息发送到 MSC Server。
F8, MSC Server收到第二个会话（多媒体会话） 的会话状态信息， 根 据当前 UE RAN和资源状况判断是否可以支持 Video传输。
F9a,若当前网络支持 Video传输，则按现有技术发起多媒体会话的转移 请求， 并完成对端更新和会话转移。
F9b, 若当前网络不能支持 Video传输则对该转移会话只转移语音媒体 , 则发起语音会话转移请求， 具体的是在发送的 Invite请求中 SDP信息中将 Video媒体的端口号置 0。
F10, 所述 Invite请求被 S-CSCF发送到 SCC AS。
Fl lb-F12b, SCC AS判断转移请求对应会话为包含视频媒体的多媒体 会话， 选择将多媒体会话转换为语音会话， 则释放原 PS域的 Video媒体， 即 SCC AS根据保存的 SDP信息生成 re-INVITE请求，并将 SDP信息中 Video媒体 行对应的端口号置 0 , 释放媒体请求经 S-CSCF发送到本端 UE。
当然本实施例中， SCC AS也可以收到所述 Invite请求后 , 发现对应会话 存在 Video媒体， 根据策略拒绝将多媒体会话转换为语音会话， 则返回 4** 响应 （如 403 forbidden ), 并释放多媒体会话， 多媒体会话释放后， 可以更 新对端， 并执行步骤 F22。本发明实施例中， 具体的策略可以预先在 SCC AS 上配置。 MSC Server收到 4**返回消息后将所述会话的会话状态信息删除。
F13b-F14b, UE上的 Video媒体被删除， UE发出 re-I VITE请求的回复 消息 200 OK, 回复消息经 S-CSCF发送到 SCC AS。
F15b-F16b, SCC AS发送回复消息的确认消息 ACK, 并由 S-CSCF发送 到 UE。
F17b, SCC AS利用 MSC Server发送的 INVITE请求的 SDP信息更新对 端。
F18b-F19b, SCC AS对 INVITE请求回复 200 OK响应， 200 OK响应经 S-CSCF发送到 MSC Server。
F20b-F21b, MSC Server发出确认消息 ACK, ACK经 S-CSCF发送到 SCC AS , 完成第二个会话在 CS域的呼叫分支（access leg )建立。
F22 , SCC AS释放所述 UE在原 PS域的会话。
本实施例 MSC Server端判断 CS域不支持 Video媒体传输时， 由 MSC Server发起对多媒体会话的语音媒体的转移， 进一步触发 SCC AS将原网絡 域的 Video媒体释放， 实现在网络条件不允许的情况下， 将多媒体会话将为 语音会话的转移。
应用例二、
当 MSC Server由于 CS网络原因无法发起对视频^ ¾■的转移时， 本实施 例意在通过已建立的第一个会话的信令信道发送 INFO消息， 指示 SCC AS 第二个会话的无法转移指示消息及无法转移原因， SCC AS收到该消息后释 放 PS域的 Video媒体，并再通过 INFO消息指示 MSC Server发起对语音媒体的 转移。 流程图如图 5所示：
Gl-G9a, 与应用例一 F1至 F9a相同， 不再赘述。
G9b, 若当前网络不支持 Video传输， 则 MSC Server发起 INFO消息， 该 INFO消息在第一个会话建立的信道内传输 , INFO消息中携带第二个会话无 法转移指示。 具体无法转移指示可以通过消息头或消息体携带， 具体如下： 一、 消息头携带： 例如： 在 INFO消息的目的头 subject中携带无法转移 指示： 由于 subject头原意是指示通话的目的， 因此， 本实施例中， 对 subject 头进行扩展， 即 INFO消息的目的是指示会话无法转移， 并包含无法转移的 原因，。
二、 消息体携带： 在 INFO的消息体中指出 INFO消息的所要传递的无法 转移指示， 以及具体无法转移原因 "不支持视频（Video— not— supported )" 或 "资源不足（ lack— resource )"。 具体的消息体可以釆用可扩展标记语言 (Extensible Markup Language, XML)格式 , 具体如下：
<?xml version="1.0"?>
<ati xmlns="urn:3gpp:ns:imscont:ati">
<aes i="callIdOfSessionY lt="UEATag" rt="SCCASTag" lUri- 'tel:+l -237-555-1111" rUri="sip:UE3@operator.net" s="fail" cause="Video_not_supported/lack_resource"/>
</ati>
其中 aes项描述了第二个 session的相关信息， i属性表示第二个会话在 PS 域对话的 Call-ID, It属性表示本端（与该 MSC Server对应端）的 UE标识， rt 属性表示对端 UE标识， lUri表示本端 UE身份标识， rUri表示对端 UE身份表 识， s表示转移状态可选项有： 成功 "success"、 失败 "fail" , 重试 "retry" ， 如果失败， 则 cause表示失败的原因， 可能的原因有 "Video— not— supported" 或 "lack_resource" 0
INFO 消 息 的 accept 头 和 Content-Type 头 设 为 application/vnd.3gpp.ati+xml。
G10b-Gl lb, INFO消息经过 S-CSCF发送到 SCC AS。
G12b-G13b, SCC AS收到 INFO消息返回成功响应 200 OK, 200 OK经过 S-CSCF发送到 MSC Server。
G14b, SCC AS解析 INFO消息的消息体的 s字段和 cause字段， 发现由于 上述原因导致多媒体会话不能成功转移， 则将多媒体会话转换为语音会话 进行转移， 释放多媒体会话的 video媒体过程同应用例一步骤 Fllb-F15b, 并 完成对端更新过程。 当然， SCC AS可以选择不转移该会话而将会话释放， 如果 SCC AS释放会话， 则直接执行步骤 G20b。 如果 MSC Server在一定时间 内没有收到 INFO消息则不发起转移请求， 而将第二个待转移会话的相关会 话状态信息删除。
如果 Video媒体释放成功 , 则 SCC AS生成 INFO消息， 指示 Video媒体已 成功释放需要 MSC Server重新发起对该会话语音媒体的转移请求。 再次发 起转移请求的指示可以在 INFO消息的 xml类型的消息体中或 subject消息头 指出， 若在 subject消息头给出， 则在消息头写入 "transfer voice" , 若在消 息体指出， 消息体形式如下：
<?xml version="l .0"?>
<ati xmlns="urn:3gpp:ns:imscont:ati">
<aes i="callIdOffiessionY" lt="UEATag" rt="SCCASTag" lUri="tel:+l -237-555-1111 " rUri="sip:UE3@operator.net
s="retry" cause="transfer_voice"/>
</ati>
G15b-G16b, INFO消息经过 S-CSCF发送到 MSC Server。
G17b-G18b, MSC Server收到 INFO消息返回成功响应 200 OK, 200 OK 经 S-CSCF发送到 SCC AS。
G19b, MSC Server收到 INFO消息解析 s字段和 cause字段， 并利用会话 信息重新发起对该会话的转移请求 Invite。
G20b, SCC AS收到 MSC Server在 CS域的转移请求，执行对端更新过程。
G21 , SCC AS释放 UE在原 PS域会话。
本发明实施例中， SIP的 Message的 paper模式可以取代 INFO消息完成上 述操作， 操作过程与上相同。 如果 SCC AS没有成功释放 Video媒体， 不必发 送 INFO消息通知 MSC Server, 进一步在原 PS网络中将第二个会话释放。 如 果 MSC Server在一定时间内没有收到 INFO消息则不发起转移清求 , 而将第 二个待转移会话的相关会话状态信息删除。
本实施例利用会话初始协议 ( SIP )的 INFO (或 Message消息 paper模式） 实现对转移失败信息的指示， 以使得在网络情况不支持 Video或网络资源不 足的情况下， SCC AS将多媒体会话转换为语音会话， 通过 INFO或 Message 消息通知 MSC Server, 由 MSC Server重新发起对语音会话的转移请求。 由 于 INFO消息和 paper模式的 Message消息都在已建立的第一个会话信道内传 输， 假设 MSC Server判断网络情况和与 SCC AS交换信息的过程中， 第一个 会话不会被释放。
应用例三、
本应用例中， MSC Server订阅第二个会话的转移状态， 获知会话是否 转移成功， 如果失败且失败的原因是由于目标网络无法传输视频媒体 ( video )则进一步释放 Video媒体 , 并告知 MSC Server发起对第二个待转移 会话的语音媒体的转移。 由于订阅请求不依赖于会话而存在， 因此这里可 以在第一个已建立会话信道内订阅， 也可以新建立会话订阅。 具体流程图 如图 6所示， 包括：
H1-H7 , 同应用例一 F1至 F7的， 在此不再赞述。
H8 , SCC AS下发订阅请求（Subscribe ) , 订阅 UE相关事件则请求的 request-URI为 UE身份信息， 订阅请求通过 event头或请求消息体指明订阅事 件， 这里订阅事件为第二个待转移会话是否转移成功， 设置 event头为 "sscond— transfer" 。
请求的 accept头指出所支持的 Notify消息的消息体格式， 此处使用 xml 类型， 设为： "application/vnd.3gpp.ati+xml" 。 SCC AS可以只在第二个需 转移的会话为多媒体会话时发出该订阅请求。 此处省略了订阅成功相关的 响应消息。
H9, 订阅请求经过 S-CSCF发送到 MSC Server^
H10, MSC Server收到第二个待转移会话（多媒体会话）的会话状态信 息 , 根据当前 UE的网络状况判断是否支持 Video传输。
Hl la, 若当前网络（网络状况或网络资源）支持 Video传输， 则按现有 技术发起多媒体会话的转移请求。
H12a， 第二个待转移会话（多媒体会话）转移成功， MSC Server发送 Notify消息通知 SCC AS。 通知消息内容在 Notify的 xml格式消息体中体现， xml消息体格式为 application/vnd.3gpp.ati+xml , 见应用例二, s属性置位 "success" 。 Gauss属性置 。
H13a, Notify消息经过 S-CSCF发送到 SCC AS。
H14a， MSC Server与 SCC AS在 CS域的 access leg建立成功， SCC AS更 新对端。
HI lb , MSC Server判断出当前网络无法转移 video媒体 , 则生成转移失 败的 Notify消息，格式为 application/vnd.3gpp.ati+xml, s属 4生为 "fail" , cause 写入无法转移第二个会话的原因 "Video— not— supported"或 "lack— resource"， 具体含义同应用例二。
<?xml version:" 1.0"?>
<ati xmlns="ura:3gpp:ns:imscont:ati">
<aes i-"callIdOfSessionY" lt="UEATag" rt-"SCCASTag" lUri="tel:+l-237-555-l 111" rUri="sip:UE3@operator.net" s="fail" cause="Video_not_supported/lack_resource"/>
</ati>
application vnd.3gpp.ati+xml格式的消息体中还包括转移会话的会话相 关信息， 此处 Notify回复消息可以包括该会话信息（除 "s" 、 "cause" 属 性外的其他项） ， 以利于 SCC AS执行判断和释放操作， 也可以不包含会话 信息而只包括属性 s和 cause, SCC AS知道订阅事件并根据保存的会话信息 可以获知第二个待转移会话的会话信息。 H12b， Notify消息被发送到 S-CSCF。
H13b, Notify消息由 S-CSCF发送到 SCC AS。
H14b， SCC AS收到 Notify消息， 解析通知消息内容 s和 cause值域， 获知 由于上述原因导致多媒体会话无法转移成功， SCC AS选择将多媒体会话转 换为语音会话则按应用例一步驟 F 11 b-F 15b在 PS域释放 Video媒体， 并完成 对端更新过程。 或者 SCC AS也可以选择不转移该会话而将会话释放， 如果 SCC AS释放会话， 对 Notify消息回复 200 OK, 并更新对端后直接执行步骤 H21。 MSC Server在一定时间内没有收到重新发起请求的指示则不再发起转 移请求， 而将第二个待转移会话的相关会话状态信息删除。
H15b, SCC AS发出 Notify的响应消息 200 OK,且如杲 SCC AS成功释放 Video媒体 ,在 200 OK的消息体中指示 MSC Server重新发起对该会话语音媒 体的请求。 消息体同应用例二：
<?xml version="1.0"?> <ati xmlns="urn:3gpp:ns:imscont:ati">
<aes i="callIdOfSessionY" lt="UEATag" rt="SCCASTag" lUri="tel:+l-237-555-l 111" rUri=" sip :UE3 ©operator .net"
s="retry" cause="transfer_voice"/>
</ati>
如果 SCC AS释放 Video媒体失败，则进一步尝试将第二个会话释放， 而 不向 MSC Server发出任何指示信息。 MSC Server在一定时间内没有收到重 新发起请求的指示则不再发起转移请求， 而将第二个待转移会话的相关会 话状态信息删除。
H16b, 200 OK响应经 S-CSCF发送到 MSC Server。
H17b, MSC Server收到响应消息， 通过解析消息体获知需要对发起语 音媒体的转移请求。
H18b-H19b,转移成功则向 SCC AS发送通知消息，具体消息内容同 H12a 中描述。
H20b, 更新对端， 完成 UE和通信对端的会话连接。
H21 , 释放原 PS网络会话。
SCC AS在一定时间后， 可以取消与 MSC Server的订阅关系。
本实施例通过 SCC AS订阅第二个会话转移状态及接收 MSC Server通知 消息， 在网络不允许多媒体会话转移的情况下触发 SCC AS释放 Video媒体， 将多媒体会话转换为语音会话进行转移， 由 MSC Server再次对该会话的语 音媒体发起转移， 或 SCC AS将第二个待转移会话释放而不进行转移。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分 步骤是可以通过程序来指令相关的硬件来完成， 该程序可以存储于一计算 机可读存储介质中， 存储介质可以包括： ROM、 RAM, 磁盘或光盘等。
实施例三、 一种呼叫控制设备， 结构示意图如图 7所示， 包括： 接收单元 810,用于接收 SCC AS发送的所述终端第二个待转移会话的状 态信息； 所述状态信息指示所述第二个待转移会话的媒体类型为视频类型； 会话转移控制单元 820， 用于判断会话转移的目标网络域是否能够传输 视频数据， 若无法传输， 则向 SCC AS发起对所述第二个待转移会话的语音 媒体的转移请求， 以使 SCC AS收到该请求后， 将所述第二个待转移会话转 移转换为语音会话或者#放所述第二个待转移会话。
本实施例中的呼叫控制设备， 在对用户的第二个待转移会话进行转移 时， 若发现目标网络域无法支持视频数据传输， 则直接向请求所述 SCC AS 发起对所述第二个待转移会话的语音媒体的转移请求， 例如： 将请求中的 媒体行信息中的视频媒体传输端口号置 0,仅请求语音媒体的转移，这样 SCC AS在收到该请求后 , 则可以将所述第二个待转移会话转换为语音会话进行 转移或者释放所述第二个待转移会话。 以避免现有技术中出现的网络无法 完成会话转移的问题， 使得跨网络的多会话转移业务更加完善。
实施例四， 一种呼叫控制设备， 结构示意图如图 8所示， 包括： 接收单元 910，用于接收 SCC AS发送的所述终端第二个待转移会话的状 态信息； 所述状态信息包含所述第二个待转移会话的媒体类型， 所述媒体 类型包含视频类型；
会话转移控制单元 920, 用于判断会话转移的目标网络域是否可以传输 视频数据， 若不可以， 则向 SCC AS发起所述第二个待转移会话转移失败指 示， 以使 SCC AS收到该请求后， 将所述第二个待转移会话转移转换为语音 会话或者释放所述第二个待转移会话。
本实施例中的呼叫控制设备， 在对用户的第二个待转移会话进行转移 时， 若发现目标网络域无法支持视频数据传输， 则直向 SCC AS发起所述第 二个待转移会话转移失败指示， 以使得 SCC AS收到所述失败指示， 进行后 续处理。 以避免现有技术中出现的网絡无法完成会话转移的问题， 使得跨 网络的多会话转移业务更加完善。
实施例三和实施例四的呼叫控制设备可以是电路交换网络中具有呼叫 控制功能的网络实体， 如： 移动交换中心服务器或者类似的设备。
实施例五、 一种业务连续性服务器， 结构示意图如图 9所示， 包括： 发送单元 1010, 用于向终端所属的所述移动交换中心服务器发送所述 终端第二个待转移会话的状态信息； 所述状态信息包含所述第二个待转移 会话的媒体类型， 所述媒体类型包含视频类型；
会话处理单元 1020, 用于在接收到所述移动交换中心服务器发起的对 所述第二个待转移会话的语音媒体的转移请求， 将所述第二个待转移会话 转换为语音会话进行转移或者释放所述第二个待转移会话。
本发明实施例提供的呼叫控制设备和业务连续性服务器可以运行的方 法， 可参考上文对本发明提供的提供多个方法实施例的描述， 在此不再重 复。
实施例六、 一种业务连续性服务器， 结构示意图如图 10所示， 包括： 发送单元 1110 , 用于向终端所属的移动交换中心服务器发送所述终端 第二个待转移会话的状态信息； 所述状态信息指示所述第二个待转移会话 的媒体类型为视频类型；
会话处理单元 1120, 用于接收所述移动交换中心服务器因为目标网络 域无法传输视频数据而发送的所述第二个待转移会话转移失败指示， 将第 二个待转移会话转移转换为语音会话进行转移或者释放所述第二个待转移 会话。
以上对本发明实施例所提供的多会话转移方法及呼叫控制设备和业务 连续性服务器进行了详细介绍， 本文中应用了具体个例对本发明的原理及 实施方式进行了阐述， 以上实施例的说明只是用于帮助理解本发明的方法 及其核心思想； 同时， 对于本领域的一般技术人员， 依据本发明的思想， 在具体实施方式及应用范围上均会有改变之处， 综上所述， 本说明书内容 不应理解为对本发明的限制。

Claims

权利要求
1、 一种多会话转移方法， 其特征在于， 当完成将终端的第一个会话由 源网络域向目标网络域的转移后， 包括：
所述终端在目标网络域所属的移动交换中心服务器 MSC Server接收集 中业务和业务连续性^ ^务器 SCC AS发送的所述终端第二个待转移会话的状 态信息； 所述状态信息包含所述第二个待转移会话的媒体类型， 所述媒体 类型包含视频类型；
若所述 MSC Server判断所述目标网络域无法传输视频数据， 则所述 MSC Server向所述 SCC AS发起对所述第二个待转移会话的语音媒体的转移 请求， 以使所述 SCC AS收到该请求后， 将所述第二个待转移会话转换为语 音会话进行转移或者释放所述第二个待转移会话。
2、 如权利要求 1所述的方法， 其特征在于， 所述源网络域为分组交换 域、 所述目标网络域为电路交换域。
3、 如权利要求 1或 2所述的方法， 其特征在于， 所述 SCC AS释放所述第 二个待转移会话之后包括：
所述 MSC Server接收所述 SCC AS发送的对所述转移请求的失败响应消 息， 将所述第二个待转移会话的会话状态信息删除。
4、 一种多媒体会话转移方法， 其特征在于， 当完成将终端的第一个会 话由源网络域向目标网络域的转移后， 包括：
所述 SCC AS向终端在目标网络域所属的 MSC Server发送所述终端第二 个待转移会话的状态信息； 所述状态信息包含所述第二个待转移会话的媒 体类型， 所述媒体类型包含视频类型；
若所述 SCC AS收到所述 MSC Server因为目标网络域无法传输视频数据 而发送的所述第二个待转移会话转移失败指示， 则将第二个待转移会话转 移转换为语音会话进行转移或者释放所述第二个待转移会话。
5、 如权利要求 4所述的方法， 其特征在于， 所述 SCC AS收到所述 MSC Server因为目标网络域无法传输视频数据而发送的所述第二个待转移会话 转移失败指示之前包括：
所述 SCC AS向所述 MSC Server发送订阅请求消息； 所述 SCC AS收到所述 MSC Server因为目标网络域无法传输视频数据而 发送的所述第二个待转移会话转移失败指示包括：
接收所述核心网设备返回的订阅请求的通知消息， 所述通知消息包含 所述第二个待转移会话转移失败指示。
6、 如权利要求 4所述的方法， 其特征在于， 所述第二个待转移会话转 移失败指示通过信息传递请求消息或即时消息携带。
7、 如权利要求 4或 5所述的方法， 其特征在于，
所述将所述第二个待转移会话转换为语音会话进行转移包括： 在源网络域释放所述待转移会话的视频媒体；
通知所述 MSC Server重新发起所述会话的语音媒体的会话转移请求； 以建立在所述第二个待转移会话在目标网络域的接入分支；
与所述终端的通信对端交互完成通信对端接入分支的更新过程； 所述释放所述第二个待转移会话包括：
在源网絡域释放所述第二个待转移会话， 并与所述终端的通信对端交 互完成通信对端接入分支的更新过程。
8、 如权利要求 4或 5所述的方法， 其特征在于， 所述源网络域为分组交 换域、 所述目标网络域为电路交换域。
9、 一种呼叫控制设备， 其特征在于， 包括：
接收单元， 用于接收 SCC AS发送的所述终端第二个待转移会话的状态 信息； 所述状态信息包含所述第二个待转移会话的媒体类型， 所述媒体类 型包含视频类型；
会话转移控制单元， 用于判断会话转移的目标网络域是否可以传输视 频数据， 若不可以， 则向 SCC AS发起对所述第二个待转移会话的语音媒体 的转移请求， 以使所述 SCC AS收到该请求后， 将所述第二个待转移会话转 移转换为语音会话或者释放所述第二个待转移会话。
10、 一种呼叫控制设备， 其特征在于， 包括：
接收单元， 用于接收 SCC AS发送的所述终端第二个待转移会话的状态 信息； 所述状态信息包含所述第二个待转移会话的媒体类型， 所述媒体类 型包含视频类型； 会话转移控制单元， 用于判断会话转移的目标网络域是否可以传输视 频数据， 若不可以， 则向所述 SCC AS发起所述第二个待转移会话转移失败 指示， 以使所述 SCC AS收到该请求后， 将所述第二个待转移会话转移转换 为语音会话或者释放所述第二个待转移会话。
11、 一种业务连续性服务器， 其特征在于， 包括：
发送单元， 用于终端所属的所述 MSC Server发送所述终端第二个待转 移会话的状态信息； 所述状态信息包含所述第二个待转移会话的媒体类型， 所述媒体类型包含视频类型；
会话处理单元， 用于接收所述 MSC Server发起的对所述第二个待转移 会话的语音媒体的转移请求， 将第二个待转移会话转移转换为语音会话进 行转移或者释放所述第二个待转移会话。
12、 一种业务连续性服务器， 其特征在于， 包括：
发送单元， 用于向终端所属的 MSC Server发送所述终端第二个待转移 会话的状态信息， 所述状态信息包含所述第二个待转移会话的媒体类型， 所述媒体类型包含视频类型；
会话处理单元， 用于接收所述 MSC Server因为目标网络域无法传输视 频数据而发送的所述第二个待转移会话转移失败指示， 将第二个待转移会 话转移转换为语音会话进行转移或者释放所述第二个待转移会话。
PCT/CN2010/076132 2009-08-31 2010-08-19 多会话转移方法及呼叫控制设备和业务连续性服务器 WO2011023074A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
ES10811234.3T ES2465218T5 (es) 2009-08-31 2010-08-19 Método para transferir múltiples sesiones, dispositivo de control de llamadas y servidor de continuidad de servicio
EP10811234.3A EP2464166B2 (en) 2009-08-31 2010-08-19 Method for transferring multiple sessions, call control device and service continuity server
US13/408,371 US10021602B2 (en) 2009-08-31 2012-02-29 Multi-session transfer method, call control device, service continuity and continuity application server

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200910171816XA CN102006645B (zh) 2009-08-31 2009-08-31 多会话转移方法及呼叫控制设备和业务连续性服务器
CN200910171816.X 2009-08-31

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/408,371 Continuation US10021602B2 (en) 2009-08-31 2012-02-29 Multi-session transfer method, call control device, service continuity and continuity application server

Publications (1)

Publication Number Publication Date
WO2011023074A1 true WO2011023074A1 (zh) 2011-03-03

Family

ID=43627248

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/076132 WO2011023074A1 (zh) 2009-08-31 2010-08-19 多会话转移方法及呼叫控制设备和业务连续性服务器

Country Status (5)

Country Link
US (1) US10021602B2 (zh)
EP (1) EP2464166B2 (zh)
CN (1) CN102006645B (zh)
ES (1) ES2465218T5 (zh)
WO (1) WO2011023074A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10021602B2 (en) 2009-08-31 2018-07-10 Huawei Device Co., Ltd. Multi-session transfer method, call control device, service continuity and continuity application server

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101127766B (zh) * 2007-09-24 2010-06-09 中兴通讯股份有限公司 基于sip协议的消息处理方法、装置及ip通信系统
CN103118238B (zh) * 2011-11-17 2016-03-16 中国电信股份有限公司 视频会议的控制方法和视频会议系统
GB201320770D0 (en) 2013-11-25 2014-01-08 Microsoft Corp Communication system architecture
GB201320778D0 (en) 2013-11-25 2014-01-08 Microsoft Corp Communication system architecture
GB201320774D0 (en) 2013-11-25 2014-01-08 Microsoft Corp Communication system architecture
GB201320776D0 (en) 2013-11-25 2014-01-08 Microsoft Corp Communication system architecture
NO2707687T3 (zh) 2014-03-20 2018-08-25
US9591124B2 (en) 2014-04-30 2017-03-07 Motorola Solutions, Inc. Method and system for transferring an audio signal between devices of a single user
US9544253B2 (en) * 2014-07-09 2017-01-10 Genband Us Llc Multimedia conversation transfer
CN107371140B (zh) * 2016-05-11 2021-01-12 中国移动通信有限公司研究院 一种呼叫前转的处理方法及设备
EP3525545B1 (en) 2016-10-07 2021-07-14 LG Electronics Inc. Methods for selecting session and service continuity mode in a wireless communication system
CN109842643B (zh) 2017-11-27 2021-11-09 华为技术有限公司 一种会话处理的方法、装置及系统
WO2023241294A1 (en) * 2022-06-14 2023-12-21 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for application context relocation

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1439725B1 (en) * 2003-01-16 2006-08-02 Sony Ericsson Mobile Communications AB Handover of video telephony session with degraded quality
CN101110946A (zh) * 2007-08-17 2008-01-23 中兴通讯股份有限公司 对会话初始化协议终端的音频和视频通信进行切换的方法
US20080049725A1 (en) * 2006-08-28 2008-02-28 Nokia Corporation Method, System and terminal for multimedia session establishment
CN101325732A (zh) * 2007-06-15 2008-12-17 华为技术有限公司 呼叫控制的方法和ims的电路交换控制装置及终端设备

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040180689A1 (en) * 2003-03-14 2004-09-16 Logicacmg Wireless Networks, Inc. Systems and methods for establishing communication between a first wireless terminal and a second wireless terminal differing in respect to at least one feature
US20070100981A1 (en) * 2005-04-08 2007-05-03 Maria Adamczyk Application services infrastructure for next generation networks including one or more IP multimedia subsystem elements and methods of providing the same
IES20070550A2 (en) * 2006-08-03 2008-04-30 Accuris Technologies Ltd A roaming gateway
KR101250589B1 (ko) * 2006-10-02 2013-04-03 삼성전자주식회사 멀티미디어 통화 서비스를 수행하기 위한 멀티미디어ＰｏＣ 세션 개설 및 관리 시스템과 그 방법 및 단말장치
GB0707387D0 (en) 2007-04-17 2007-05-23 Lucent Technologies Inc Single radio VCC:LTE-VMSC anchor solution
US8619675B2 (en) * 2008-08-18 2013-12-31 Telefonaktiebolaget L M Ericsson (Publ) Technique for emergency session handling in a communication network
US10477607B2 (en) * 2009-06-29 2019-11-12 Blackberry Limited System and method for voice service in an evolved packet system
CN102006645B (zh) 2009-08-31 2012-01-04 华为终端有限公司 多会话转移方法及呼叫控制设备和业务连续性服务器

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1439725B1 (en) * 2003-01-16 2006-08-02 Sony Ericsson Mobile Communications AB Handover of video telephony session with degraded quality
US20080049725A1 (en) * 2006-08-28 2008-02-28 Nokia Corporation Method, System and terminal for multimedia session establishment
CN101325732A (zh) * 2007-06-15 2008-12-17 华为技术有限公司 呼叫控制的方法和ims的电路交换控制装置及终端设备
CN101110946A (zh) * 2007-08-17 2008-01-23 中兴通讯股份有限公司 对会话初始化协议终端的音频和视频通信进行切换的方法

Non-Patent Citations (1)

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

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10021602B2 (en) 2009-08-31 2018-07-10 Huawei Device Co., Ltd. Multi-session transfer method, call control device, service continuity and continuity application server

Also Published As

Publication number Publication date
ES2465218T5 (es) 2017-08-16
EP2464166A1 (en) 2012-06-13
EP2464166A4 (en) 2012-06-13
ES2465218T3 (es) 2014-06-05
US20120155457A1 (en) 2012-06-21
EP2464166B1 (en) 2014-03-05
US10021602B2 (en) 2018-07-10
EP2464166B2 (en) 2016-12-21
CN102006645A (zh) 2011-04-06
CN102006645B (zh) 2012-01-04

Similar Documents

Publication Publication Date Title
WO2011023074A1 (zh) 多会话转移方法及呼叫控制设备和业务连续性服务器
US10469545B2 (en) Multimedia session call control method and application server
US8588211B2 (en) Method for changing session media, method for establishing a call, and equipment thereof
EP3240257B1 (en) A domain transferring method for single radio voice call continuity
WO2009015525A1 (en) A method for switching the session control path of ip multimedia core network subsystem centralized service
US20100169495A1 (en) Method, apparatus, and system for processing continuity of media streams in a session
WO2011026438A1 (zh) 跨无线接入技术的语音切换方法、设备及网络系统
WO2009012665A1 (fr) Procédé pour assurer une continuité d&#39;appel multimédia, équipement et système associés
EP2517500A1 (en) Method and apparatus for inter user-equipment transfer (iut), access transfer and fallback initiated by a service centralization and continuity application server (scc as)
US20110116473A1 (en) METHOD AND APPARATUS FOR INTER-DEVICE HANDOVER (HO) BETWEEN INTERNET PROTOCOL (IP) MULTIMEDIA SUBSYSTEM (IMS) AND CIRCUIT SWITCHED (CS) WIRELESS TRANSMIT/RECEIVE UNITS (WTRUs)
EP2472952B1 (en) Method for inter-ue media transfer and application server thereof
EP2421218B1 (en) Session transfer method, apparatus and system thereof
US8577012B2 (en) Session transfer method and user equipment
WO2011050698A1 (zh) 一种带有彩铃的振铃状态会话的切换系统及方法
US20150207829A1 (en) Method and apparatus for service control
EP2073482B1 (en) A method of call control and a ims cs control apparatus and terminal device
WO2008110110A1 (fr) Procédé et système de fourniture de service de sous-système multimédia ip
WO2012159483A1 (zh) 语音呼叫处理方法及业务连续性服务器
WO2012129979A1 (zh) 振铃态域切换的方法、系统及装置
WO2012089064A1 (zh) 在电路域接入终端与as之间交互控制信息的方法及设备
WO2008119278A1 (fr) Procédé, terminal et dispositif réseau pour le changement d&#39;état de domaine à commutation de paquets
EP3073799A1 (en) Method and apparatus for notifying/triggering call forwarding/deflection service
JP6549523B2 (ja) 要求先端末のオプション機能の非使用を整合する網間制御方法、ｓｉｐサーバ及びプログラム

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: 10811234

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2010811234

Country of ref document: EP