WO2011015019A1 - 一种多方通话业务连续性的实现方法及系统 - Google Patents

一种多方通话业务连续性的实现方法及系统 Download PDF

Info

Publication number
WO2011015019A1
WO2011015019A1 PCT/CN2009/075956 CN2009075956W WO2011015019A1 WO 2011015019 A1 WO2011015019 A1 WO 2011015019A1 CN 2009075956 W CN2009075956 W CN 2009075956W WO 2011015019 A1 WO2011015019 A1 WO 2011015019A1
Authority
WO
WIPO (PCT)
Prior art keywords
call service
party call
conf
scc
identifier
Prior art date
Application number
PCT/CN2009/075956
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 中兴通讯股份有限公司
Publication of WO2011015019A1 publication Critical patent/WO2011015019A1/zh

Links

Classifications

    • 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/1095—Inter-network session 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
    • 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
    • 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/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences

Definitions

  • the present invention relates to the field of communications, and in particular to a method and system for implementing a multi-party call service continuity (SC) in an IP multimedia subsystem.
  • SC multi-party call service continuity
  • IP Multimedia Subsystem is an IP-based network architecture proposed by the 3rd Generation Partnership Project (3GPP). An open and flexible business environment that supports multimedia applications and provides users with rich multimedia services.
  • the control layer and the service layer are separated.
  • the control layer does not provide specific services, and only provides the necessary triggering, routing, and accounting functions to the service layer.
  • the service triggering and control functions in the control layer are completed by the Call Session Control Function (CSCF).
  • CSCF Call Session Control Function
  • the CSCF is divided into three types: Proxy Proxy (P-CSCF), Query Interrogating, and Serving Serving (S-CSCF).
  • P-CSCF Proxy Proxy
  • S-CSCF Serving Serving
  • the main responsibility is Serving, and the Interrogating type is optional.
  • the service layer is composed of a series of application servers (ASs), which can provide specific service services.
  • the AS can be an independent entity or exist in the S-CSCF.
  • the control layer S-CSCF controls the service trigger according to the subscription information of the user, invokes the service on the AS, and implements the service function.
  • AS and S-CSCF can be collectively referred to as Service Equipment (SE).
  • SE Service Equipment
  • the end-to-end device in the session is called User Equipment (UE) and is responsible for interaction with the user.
  • UE User Equipment
  • Some UEs have multiple access networks, including access to the network through 3GPP packet switching (PS Domain), access to the network through other non-3GPP data domains, and even circuit switching (Circuit Switch, CS). ) Domain access network, etc.
  • SCC AS Business Continuity Application Server
  • the multi-party call service is a service of the CS domain.
  • the multi-party call service includes at least three users, and one of the users can be heard by all other users.
  • the service is provided by the Mobile Switch Center (MSC).
  • MSC Mobile Switch Center
  • the service corresponding to the multi-party call service in the IMS network is the conference service. Therefore, when the service continuity occurs, after the UE switches from the CS domain to the PS domain, the multi-party call service also needs to be switched to the conference service, and the conference service is provided in the IMS network.
  • the application server is called a conference server (CONF AS).
  • FIG. 1 is a schematic diagram of a change in signaling/media path before and after traffic continuity, describing a signaling path and a media path in which UE-1 establishes a session with UE-2 before service continuity occurs, and UE-1 after service continuity occurs.
  • Signaling path and media path with UE-2 are used as an entity, and the standard Session Initiation Protocol (SIP) communication is used between the two.
  • SIP Session Initiation Protocol
  • A102 The signaling path between the UE-1 and the eMSC communicates with each other through a signaling protocol of the CS domain. For the SCC AS, this is an access leg path;
  • A104 The signaling path between the eMSC and the SCC AS/S-CSCF communicates with each other through the IMS SIP protocol. For the SCC AS, this also belongs to the Access leg path;
  • R101 The signaling path between the SCC AS/S-CSCF and the UE-2 communicates with each other through the SIP protocol of the IMS. For the SCC AS, this is a remote leg path; After the service continuity occurs, the signaling path and the media path between UE-1 and UE-2 are changed. The change of the signaling path is described as follows:
  • A112 The signaling path between the UE-1 and the P-CSCF communicates with each other through the SIP protocol of the IMS. For the SCC AS, this is an access leg path;
  • A114 The signaling path between the P-CSCF and the SCC AS/S-CSCF communicates with each other through the SIP protocol of the IMS. For the SCC AS, this also belongs to the Access leg path;
  • R101 The signaling path between the SCC AS/S-CSCF and the UE-2 communicates with each other through the SIP protocol of the IMS. For the SCC AS, this is a remote leg path. After the business continuity occurs, There is no change in this remote path.
  • the MGCF and the media processing part (MGW) are combined into one entity description, collectively referred to as an InterWorking Function entities (IFF), which combines the SCC AS and the CSCF into one entity description.
  • IFF InterWorking Function entities
  • the UE-A establishes a multi-party call between the CS domain and the UE-B and the UE-C.
  • the UE-A establishes the CS media with the IWF in the CS domain.
  • Link the IWF establishes an IMS media link 1 with the UE-B in the IMS domain, and establishes an IMS media link 2 with the UE-C.
  • Step 201 UE-A initiates an IMS call to the SCC AS in the PS domain, for example, sending an INVITE message, and the call passes through the CSCF to the SCC AS.
  • Step 202 The SCC AS finds that the UE-A participates in the IMS media links 1 and 2, and then selects the updated media link 1, for example, sends a re-invitation (relNVITE) message, and the message passes through the CSCF to reach the UE-B o.
  • relNVITE re-invitation
  • Step 203 UE-B agrees to update, sends a "200 OK" message, and the message passes through the CSCF to reach the SCC AS.
  • Step 204 The SCC AS answers the call of the UE-A, for example, sends a "200 OK" message, and carries session identification information of another session (that is, a session with the UE-C), for example, carried in the SIP message body, and the message is passed.
  • the CSCF arrives at UE-A.
  • Step 205 UE-A initiates a new IMS call, and calls the UE-C, for example, sends an INVITE message, and carries the session identification information in step 204, for example, in the Replaces header field or the Target-Dialog header field, and the message passes through the CSCF to reach the SCC.
  • UE-A initiates a new IMS call, and calls the UE-C, for example, sends an INVITE message, and carries the session identification information in step 204, for example, in the Replaces header field or the Target-Dialog header field, and the message passes through the CSCF to reach the SCC.
  • the UE-C for example, sends an INVITE message, and carries the session identification information in step 204, for example, in the Replaces header field or the Target-Dialog header field, and the message passes through the CSCF to reach the SCC.
  • the CSCF for example, in the Replaces header field or the Target-Dialog header field
  • Step 206 The SCC AS updates the IMS media link 2 according to the identifier information carried in step 205. For example, a relNVITE message occurs, and the message arrives at the UE-C via the CSCF.
  • Step 207 The UE-C agrees to update, for example, sends a "200 OK" message, and the message passes through the CSCF to reach the SCC AS.
  • Step 208 The SCC AS answers the UE-A call, for example, sends a "200 OK" message, and the message passes through the CSCF to reach the UE-A.
  • IMS Media Link 1 has been updated to be an IMS media link between UE-A and UE-B.
  • the IMS Media Link 2 is updated to an IMS media link between UE-A and UE-C.
  • Steps 209 ⁇ 210 UE-A calls the CONF AS in the IMS domain, for example, sends an INVITE message, and the message arrives at the CONF AS via the CSCF and the SCC AS.
  • Step 213 - 214 UE-A invites UE-C to join the conference, for example, sends a transfer (REFER) message, and the message arrives at CONF AS via CSCF and SCC AS.
  • REFER transfer
  • the UE-C may be invited to join the conference, or the UE-B may be invited to join.
  • Steps 215 ⁇ 216, CONF AS indicates consent, for example, sending a "202 Accepted" message, and the message arrives at UE-A via CSCF and SCC AS.
  • Step 217 The CONF AS calls the UE-C, for example, sends an INVITE message.
  • Step 218 The UE-C answers the call, for example, sends a "200 OK" message.
  • Step 219-220 The UE-A releases the UE-C session, for example, sends a BYE message, and the message passes through the CSCF and the SCC AS to the UE- (:.
  • Steps 221 ⁇ 222 UE-C agrees to hang up, for example, sends a "200 OK" message, and the message arrives at UE-A via CSCF and SCC AS.
  • Step 223 UE-A repeats the steps of steps 213 to 222, but only changes UE-C to UE-B. So far, the IMS media link 4 is established between the CONF AS and the UE-B, the IMS media link 5 is established with the UE-C, the media link 1 between the UE-A and the UE-B, and the media link between the UE-A and the UE-C 2 is released, CONF AS bridges IMS media links 3, 4, 5.
  • Steps 224 ⁇ 225 the SCC AS releases the IMS media link 1 on the IWF side and the resources of the IMS media link 2, for example, respectively sending a BYE message, the message passes through the CSCF to the IWF, and the CS media link is released.
  • the technical problem to be solved by the present invention is to provide a method and system for implementing multi-party call service continuity, which can reduce the handover procedure and effectively shorten the handover time.
  • a method for implementing continuity of a multi-party call service comprising:
  • the service continuity server SCC AS After receiving the call request targeted by the UE for the handover identity, the service continuity server SCC AS will determine each session corresponding to each session belonging to the multi-party call service if it is determined that the UE performs the multi-party call service.
  • the index identifier is sent to the conference server CONF AS;
  • the CONF AS sends a call request to each of the session index identifiers.
  • the SCC AS After receiving the call request targeted by the session index identifier, the SCC AS sends a call request to the remote end of the corresponding session according to the session index identifier.
  • the user sends an update request.
  • the call request with the handover identifier is carried in the multi-party call service identifier; the SCC AS determines that the UE performs the multi-party call service, and determines that the UE performs the multi-party call service according to the multi-party call service identifier.
  • the multi-party call service identifier includes one or a combination of the following indication information: a specific session initiation protocol SIP header field, or a SIP function identifier, indicating that the UE performs a multi-party call service, and all sessions in which the UE participates Or all active sessions or all held sessions belong to a multi-party call service;
  • the UE performs the multi-party call service by using the identifier information of other users included in the SIP message body, and the session with the other user that the UE participates belongs to the multi-party call service.
  • the SCC AS determines that the UE performs the multi-party call service according to: the UE participates in multiple active sessions or multiple hold sessions, and the multiple active sessions or multiple hold sessions belong to a multi-party call service.
  • Sending, by the SCC AS, the session index identifier to the CONF AS is:
  • the I identity is sent to the CONF AS in a call request initiated to the CONF AS.
  • the method further includes: initiating a transfer request to the CONF AS, respectively, and including each of the session index identifiers in the transfer request, and sending the information to the CONF AS.
  • a method for implementing continuity of a multi-party call service comprising:
  • the service continuity server SCC AS After the service continuity server SCC AS receives the call request initiated by the UE for the handover identity, if it is determined that the UE performs the multi-party call service, each session belonging to the multi-party call service is released, and each of the sessions is The session remote user ID is sent to the conference server CONF AS; The CONF AS sends a call request to the remote user identifier of each session, and establishes a conference session with the remote user of each session in the packet switched domain.
  • the call request with the handover identifier is carried in the multi-party call service identifier, and the SCC AS determines that the UE performs the multi-party call service, and determines that the UE performs the multi-party call service according to the multi-party call service identifier.
  • the multi-party call service identifier includes one or a combination of the following indication information: a specific session initiation protocol SIP header field, or a SIP function identifier, indicating that the UE performs a multi-party call service, and all sessions in which the UE participates Or all active sessions or all held sessions belong to a multi-party call service;
  • the UE performs the multi-party call service by using the identifier information of other users included in the SIP message body, and the session with the other user that the UE participates belongs to the multi-party call service.
  • the SCC AS determines that the UE performs the multi-party call service according to: the UE participates in multiple active or multiple hold sessions, and the multiple active sessions or multiple hold sessions belong to a multi-party call service.
  • the SCC AS sends the session identifier 1 to the CONF AS to: send the remote user identifiers to the CONF AS in a call request initiated by the CONF AS.
  • the method further includes: initiating a transfer request to the CONF AS, respectively, that is, the remote user identifiers are respectively included in the transfer request and sent to the CONF AS .
  • a system for implementing a multi-party call service continuity comprising: SCC AS and CONF AS, wherein
  • the SCC AS is configured to, after receiving the call request initiated by the UE for the handover identifier, if it is determined that the UE performs the multi-party call service, corresponding to each session belonging to the multi-party call service
  • Each session index identifier is sent to the CONF AS; and after receiving the call request targeted by the session index identifier, according to the session index identifier to the corresponding
  • the remote user of the session sends an update request;
  • the CONF AS is configured to send a call request to each of the session index identifiers after receiving the session identifiers from the SCC AS.
  • the call request targeted by the SCC AS for the handover identifier carries a multi-party call service identifier
  • the SCC AS is further configured to determine, according to the multi-party call service identifier, that the UE performs a multi-party call service.
  • the multi-party call service identifier used by the SCC AS to determine that the UE performs the multi-party call service includes one or a combination of the following indication information:
  • the SIP header field or the SIP function identifier indicates that the UE performs the multi-party call service, and all the sessions or all the active sessions or all the held sessions of the UE belong to the multi-party call service;
  • the UE performs the multi-party call service by using the identifier information of other users included in the SIP message body, and the session with the other user that the UE participates belongs to the multi-party call service.
  • the SCC AS is further configured to participate in multiple active sessions or multiple hold sessions according to the UE, and the multiple active sessions or multiple hold sessions belong to a multi-party call service.
  • the SCC AS is further configured to send the session index identifier to the CONF AS in a call request sent to the CONF AS.
  • the SCC AS is further configured to initiate a transfer request to the CONF AS after initiating a call request to the CONF AS, and respectively include each of the session index identifiers in the transfer request to send to the CONF AS .
  • a system for implementing a multi-party call service continuity comprising: SCC AS and CONF AS, wherein
  • the SCC AS is configured to: after receiving the call request initiated by the UE for the handover identifier, if it is determined that the UE performs the multi-party call service, release the multi-party call service Each session of the service, and sending the remote user identifier of each session to the CONF AS;
  • the CONF AS is configured to send a call request to the remote user identifier of each session, and establish a conference session with the remote user of each session in the packet switched domain.
  • the call request that is received by the SCC AS and is targeted by the handover identifier carries a multi-party service identifier.
  • the SCC AS is further configured to determine, according to the multi-party call service identifier, that the UE performs a multi-party call service.
  • the multi-party call service identifier used by the SCC AS to determine that the UE performs the multi-party call service includes one or a combination of the following indication information:
  • the SIP header field or the SIP function identifier indicates that the UE performs the multi-party call service, and all the sessions or all the active sessions or all the held sessions of the UE belong to the multi-party call service;
  • the UE performs the multi-party call service by using the identifier information of other users included in the SIP message body, and the session with the other user that the UE participates belongs to the multi-party call service.
  • the SCC AS is further configured to participate in multiple active or multiple hold sessions according to the UE, and the multiple active sessions or multiple hold sessions belong to a multi-party call service.
  • the SCC AS is further configured to send the remote user identifiers to the CONF AS in a call request initiated by the CONF AS.
  • the SCC AS is further configured to initiate a transfer request to the CONF AS after initiating a call request to the CONF AS, that is, separately including the remote user identifiers in the transfer request, and sending the CONF AS.
  • FIG. 1 is a schematic diagram of changes in signaling/media paths before and after business continuity occurs;
  • FIG. 2 is a flowchart of implementation of existing multi-party call service continuity;
  • 3 is a flowchart of implementing continuity of a multi-party call service according to Embodiment 1 of the present invention
  • 4 is a flowchart of implementing continuity of a multi-party call service according to Embodiment 2 of the present invention
  • FIG. 5 is a flowchart of implementing continuity of a multi-party call service according to Embodiment 3 of the present invention.
  • FIG. 6 is a flowchart of implementing continuity of a multi-party call service according to Embodiment 4 of the present invention. detailed description
  • the SCC AS recognizes that the UE participates in the multi-party call service, thereby replacing the UE requesting the CONF AS to create a conference, and joining the remaining multi-party call service participants to the created conference.
  • FIG. 3 is a flowchart of implementing a multi-party call service continuity according to Embodiment 1 of the present invention, and describes that UE-A establishes a multi-party call between the CS domain and UE-B and UE-C, wherein UE-A is established in the CS domain and the IWF.
  • the CS media link, the IWF establishes an IMS media link 1 with the UE-B in the IMS domain, and establishes an IMS media link 2 with the UE-C.
  • the UE-A switches to the PS domain, how does the UE-A and the network implement the multi-party call service?
  • the process of continuity is described as follows:
  • the request determines that the UE-A is to perform the transfer, and according to the handover identifier, the transition from the CS domain to the PS domain can be distinguished, and if the handover number is used, the transition from the PS domain to the CS domain can be distinguished. .
  • the multi-party call service identifier may be a specific SIP header field or a SIP function identifier for identifying that the user UE-A participates in the multi-party call service, or may be a multi-party call service participant (ie, UE) other than the user UE-A. -B and UE-C) identification information, or both.
  • Step 302 If the multi-party call service identifier is carried in step 301, the SCC AS may pass The identifier identifies that the UE-A performs the multi-party call service. If the multi-party call identifier includes other user identification information, the session between the UE-A and the other users belongs to the multi-party call service, otherwise all sessions or all activations of the UE-A are performed. The session or all the hold sessions belong to the multi-party call service; if the multi-party call service identifier is not carried in the step 301, the SCC AS may also participate in multiple active sessions or multiple hold sessions according to the UE-A to identify that the UE-A performs the multi-party call. Traffic, and these multiple active sessions or multiple hold sessions belong to a multi-party call service.
  • the session corresponding to the IMS media links 1 and 2 belongs to the multi-party call service, and the SCC AS initiates a call to the CONF AS, for example, sends an INVITE message, and the SCC AS generates the session index identifiers of the IMS media link 1 and the link 2, respectively, and The generated session index identifier carries the incoming call message, for example, carried in the SIP message body, and the message passes through the CSCF to reach the CONF AS.
  • the generated session IDs are used to associate with each session in which UE-A participates.
  • the domain name part of the identifier is the domain name of the SCC AS, so that after the CONF AS receives the session index identifier, the call request initiated by the session index identifier can reach the SCC AS.
  • the domain name part may not be the domain name of the SCC AS, but the CSCF routing configuration enables the call request initiated with the session index to reach the SCC AS.
  • the username part of the session index identifier is self-definable.
  • Step 303 The CONF AS creates a conference and answers the call, for example, sends a "200 OK" message, and the message passes through the CSCF to the SCC AS.
  • Step 304 The SCC AS forwards the response message to the UE-A, for example, sends a "200 OK" message, and the message arrives at the UE-A via the CSCF.
  • an IMS media link 3 is established between the UE-A and the CONF AS.
  • Step 305 The CONF AS initiates a call request according to the standard conference procedure according to the session information received in step 302, and takes the session index identifier of the received IMS media link 1 as a target, for example, sends an INVITE message, and the target is
  • the session index of the IMS media link 1 identifies that the message passing through the CSCF arrives at the SCC AS.
  • the CONF AS may first call the session index identifier of the IMS media link 1 and then call the session identifier of the IMS media link 2, or vice versa, and may simultaneously call the session index identifiers of the IMS media link 1 and the IMS media link 2, respectively.
  • Step 306 The SCC AS updates the UE-B, for example, sends a relNVITE message, and the message arrives at the UE-B via the CSCF.
  • Step 307 The UE-B agrees to update, for example, sends a "200 OK" message, and the message passes through the CSCF to reach the SCC AS.
  • Step 308 The SCC AS answers the call of step 305, for example, sends a "200 OK" message, and the message passes through the CSCF to reach the CONF AS.
  • the session index identifier of the IMS media link 1 is changed to the session index identifier of the IMS media link 2, and the SCC AS changes the UE-B to UE- (:.
  • IMS Media Link 1 has been updated to a media link between CONF AS and UE-B
  • IMS Media Link 2 has been updated to a media link between CONF AS and UE-C
  • CONF AS bridges IMS Media Links 1, 2, 3 .
  • Steps 310 to 313 are the same as steps 224 to 227 in Fig. 2.
  • FIG. 4 is a flowchart of implementing a multi-party call service continuity according to Embodiment 2 of the present invention, and describes that UE-A establishes a multi-party call between the CS domain and UE-B and UE-C, wherein UE-A is established in the CS domain and the IWF.
  • the CS media link, the IWF establishes an IMS media link 1 with the UE-B in the IMS domain, and establishes an IMS media link 2 with the UE-C.
  • the UE-A switches to the PS domain, and how the UE-A and the network implement the multi-party call service continuously.
  • the process of sex which is described as follows:
  • Step 401 is the same as step 301 of FIG.
  • Step 402 If the multi-party call service identifier is carried in step 401, the SCC AS may identify that the UE-A performs the multi-party call service; if the multi-party call identifier includes other If the user identification information is used, the session between the UE and the other user belongs to the multi-party call service. Otherwise, all the sessions or all the active sessions or all the hold sessions of the UE-A belong to the multi-party call service. If the multi-party call service identifier is not carried in the step 401, The SCC AS may also participate in multiple activation sessions or multiple hold sessions according to UE-A to identify that UE-A performs multi-party call service, and these multiple active sessions or multiple hold sessions belong to multi-party call service.
  • the session corresponding to the IMS media links 1 and 2 belongs to the multi-party call service, and the SCC AS initiates a call to the CONF AS, for example, sends an INVITE message, and the SCC AS generates the session identifiers I of the IMS media link 1 and the link 2, respectively.
  • the message passes through the CSCF to the CONF AS; wherein the generated session index identifiers are used to associate with the participating sessions.
  • the domain name part of the identifier is the domain name of the SCC AS, so that after the CONF AS receives the session identifier, the call request initiated by the session index identifier can reach the SCC AS, or the domain name of the SCC AS, through the CSCF.
  • the routing configuration enables call requests initiated with the session index identifier to reach the SCC AS; the username portion can be defined by itself.
  • Step 403 The CONF AS creates a conference and answers the call, for example, sends a "200 OK" message, and the message passes through the CSCF to the SCC AS.
  • Step 404 The SCC AS forwards the response message to the UE-A, for example, sends a “200 O” message, and the message arrives at the UE-A via the CSCF.
  • an IMS media link 3 is established between the UE-A and the CONF AS.
  • Step 405 The SCC AS requests the CONF AS to invite the session index of the IMS media link 1 to join the conference, for example, sending a REFER message, the Refer-To header field is a session index identifier of the IMS media link 1, and the message passes through the CSCF to reach the CONF AS.
  • the SCC AS may first request the CONF AS to join the session index identifier of the IMS media link 1 and then request to join the session identifier I of the IMS media link 2, or vice versa, and simultaneously request the CONF AS to join the IMS media link 1 and the IMS media link respectively. 2 session ID I.
  • Step 406 CONF AS agrees to the invitation, for example, sending a "202 Accepted" message, message Pass the CSCF to the SCC AS.
  • Step 407 The CONF AS initiates a call according to the session index of the IMS media link 1 in step 405, for example, sends an INVITE message, the target is the session index identifier, and the message passes through the CSCF to reach the SCC AS.
  • Step 408 The SCC AS updates the UE-B, for example, sending a relNVITE message, and the message is passed.
  • the CSCF arrives at UE-B.
  • Step 409 The UE-B agrees to update, for example, sends a "200 OK" message, and the message passes through the CSCF to reach the SCC AS.
  • Step 410 The SCC AS answers the call of step 407, for example, sends a "200 OK" message, and the message passes through the CSCF to reach the CONF AS.
  • Step 411 CONF AS, SCC AS repeats steps 405-410, except that CONF AS changes the session index identifier of IMS media link 1 to the session index identifier of IMS media link 2, and SCC AS changes UE-B to UE- (:.
  • IMS Media Link 1 has been updated to a media link between CONF AS and UE-B
  • IMS Media Link 2 has been updated to a media link between CONF AS and UE-C
  • CONF AS bridges IMS Media Links 1, 2, 3 .
  • Steps 412 - 415 are the same as steps 224 ⁇ 227 in Figure 2.
  • FIG. 5 is a flowchart of implementing a multi-party call service continuity according to Embodiment 3 of the present invention, and describes
  • the UE-A establishes a multi-party call between the CS domain and the UE-B and the UE-C.
  • the UE-A establishes a CS media link with the IWF in the CS domain, and the IWF establishes an IMS media link with the UE-B in the IMS domain.
  • the IMS media link 2 is established with the UE-C.
  • Step 501 is the same as step 301 of FIG.
  • Step 502 If the multi-party call service identifier is carried in step 501, the SCC AS may pass The identifier identifies that the UE-A performs the multi-party call service. If the multi-party call identifier includes other user identification information, the session between the UE-A and the other user belongs to the multi-party call service, otherwise all sessions or all active sessions of the UE-A Or all the hold sessions belong to the multi-party call service; if the multi-party call service identifier is not carried in step 501, the SCC AS may also participate in multiple active sessions or multiple hold sessions according to the UE-A to identify that the UE-A performs the multi-party call service. And these multiple activation sessions or multiple hold sessions belong to a multi-party call service.
  • the sessions corresponding to IMS media links 1 and 2 belong to a multi-party call service.
  • Steps 503-504 The SCC AS sends a release request to the remote user UE-B of the IMS media link 1 to release the resources of the IMS media link 1, such as a release (BYE) message, carrying the session corresponding to the IMS media link 1. Session ID, the message arrives at UE-B via CSCF.
  • BYE release
  • Steps 505 ⁇ 506 the SCC AS sends a release request to the remote user UE-C of the IMS media link 2 to release the resources of the IMS media link 2, such as a release (BYE) message, carrying the session corresponding to the IMS media link 2.
  • Session ID message passing CSCF to UE- (:.
  • Step 507 The SCC AS sends a release request to the near end of the IMS media link 1, ie, the IWF, to release the resources of the IMS media link 1, such as a BYE (release) message, and the session identifier of the session corresponding to the IMS media link 1
  • the message arrives at the IWF via the CSCF.
  • Step 508 The SCC AS sends a release request to the near end of the IMS media link 2, that is, the IWF, to release the resources of the IMS media link 2, such as a BYE (release) message, and the session identifier of the session corresponding to the IMS media link 2.
  • the message arrives at the IWF via the CSCF.
  • Step 509 The SCC AS initiates a call to the CONF AS, for example, sends an INVITE message, and carries the remote user identifier of each session into the call message, for example, carried in the SIP message body, and the message passes through the CSCF to the CONF AS.
  • Step 509 can be performed simultaneously with steps 503 ⁇ 508, without prioritization.
  • Step 510 The CONF AS creates a conference and answers the call, for example, sends a "200 OK" message, and the message passes through the CSCF to reach the SCC AS.
  • Step 511 The SCC AS forwards the response message to the UE-A, for example, sends a "200 OK" message, and the message arrives at the UE-A via the CSCF.
  • an IMS media link 3 is established between UE-A and CONF AS, and IMS media link 1 and
  • Step 512 The CONF AS initiates a call request according to the standard conference procedure according to the user identifiers received in step 503, and takes the received UE-B user identifier as a target, for example, sends an INVITE message, and the target is the UE-B user identifier.
  • the message arrives at UE-B through the CSCF route.
  • the CONF AS may first call the UE-B user identifier and then call the UE-C user identifier, or vice versa, and may also call the UE-B and UE-C user identifiers at the same time.
  • Step 513 The UE-B answers the call, for example, sends a "200 OK" message, and the message passes through the CSCF to reach the CONF AS.
  • Step 514 The CONF AS repeats steps 512 ⁇ 513, except that the CONF AS changes the UE-B user ID to the UE-C user ID.
  • FIG. 6 is a flowchart of implementing a multi-party call service continuity according to Embodiment 4 of the present invention, and describes that UE-A establishes a multi-party call between the CS domain and UE-B and UE-C, wherein UE-A is established in the CS domain and the IWF.
  • the CS media link, the IWF establishes an IMS media link 1 with the UE-B in the IMS domain, and establishes an IMS media link 2 with the UE-C.
  • the UE-A switches to the PS domain, and how the UE-A and the network implement the multi-party call service continuously.
  • the process of sex which is described as follows:
  • Steps 601 to 608 are the same as steps 501 to 508 of FIG.
  • Step 609 The SCC AS initiates a call to the CONF AS, for example, sends an INVITE message, and the message passes through the CSCF to reach the CONF AS.
  • Step 609 can be performed simultaneously with steps 603-608, without prioritization.
  • Step 610 The CONF AS creates a conference and answers the call, for example, sends a "200 OK" message, and the message passes through the CSCF to reach the SCC AS.
  • Step 611 The SCC AS forwards the response message to the UE-A, for example, sends a "200 OK" message, and the message arrives at the UE-A via the CSCF.
  • an IMS media link 3 is established between UE-A and CONF AS, and IMS media link 1 and
  • Step 612 The SCC AS requests the CONF AS to invite the UE-B user ID to join the conference, for example, sending a REFER message, the Refer-To header field is the UE-B user identifier, and the message passes through the CSCF to the CONF AS.
  • the SCC AS may first request the CONF AS to join the UE-B user identifier and then request to join the UE-C user identifier.
  • the SFC AS may also request the CONF AS to join the UE-B and the CONF AS.
  • Step 613 The CONF AS agrees to invite, for example, sending a "202 Accepted" message, and the message passes through the CSCF to the SCC AS.
  • Step 614 The CONF AS initiates a call according to the user identifier of the UE-B in step 612, for example, sends an INVITE message, and the target is the UE-B user identifier, and the message arrives through the CSCF.
  • Step 615 The UE-B answers the call, for example, sends a "200 OK" message, and the message arrives at the CONF AS via the CSCF.
  • Step 616 The CONF AS repeats steps 612 to 615, except that the CONF AS changes the UE-B user identifier to the UE-C user identifier.
  • the present invention also provides an implementation system for multi-party call service continuity, including: SCC AS and CONF AS, where The SCC AS is configured to: after receiving the call request initiated by the UE for the handover identifier, if it is determined that the UE performs the multi-party call service, identify the session index that belongs to the multi-party call service as the target call. After the request, sending an update request to the remote user of the corresponding session according to the session index identifier;
  • the CONF AS is configured to send a call request to each of the session index identifiers after receiving the session identifiers from the SCC AS.
  • the call request targeted by the SCC AS for the handover identifier carries a multi-party call service identifier
  • the SCC AS is further configured to determine, according to the multi-party call service identifier, that the UE performs a multi-party call service.
  • the multi-party call service identifier used by the SCC AS to determine that the UE performs the multi-party call service includes one or a combination of the following indication information:
  • the SIP header field or the SIP function identifier indicates that the UE performs the multi-party call service, and all the sessions or all the active sessions or all the held sessions of the UE belong to the multi-party call service;
  • the UE performs the multi-party call service by using the identifier information of other users included in the SIP message body, and the session with the other user that the UE participates belongs to the multi-party call service.
  • the SCC AS is further configured to participate in multiple active sessions or multiple hold sessions according to the UE, and the multiple active sessions or multiple hold sessions belong to a multi-party call service.
  • the SCC AS is further configured to send the session index identifier to the CONF AS in a call request sent to the CONF AS.
  • the SCC AS is further configured to initiate a transfer request to the CONF AS after initiating a call request to the CONF AS, and respectively include each of the session index identifiers in the transfer request to send to the CONF AS .
  • the present invention also provides an implementation system for multi-party call service continuity, including: SCC AS and CONF AS, wherein
  • the SCC AS is configured to: after receiving the call request initiated by the UE for the handover identifier, if it is determined that the UE performs the multi-party call service, release each session belonging to the multi-party call service, and The remote user identifier of each session is sent to the CONF AS;
  • the CONF AS is configured to send a call request to the remote user identifier of each session, and establish a conference session with the remote user of each session in the packet switched domain.
  • the call request that is received by the SCC AS and is targeted by the handover identifier carries a multi-party service identifier.
  • the SCC AS is further configured to determine, according to the multi-party call service identifier, that the UE performs a multi-party call service.
  • the multi-party call service identifier used by the SCC AS to determine that the UE performs the multi-party call service includes one or a combination of the following indication information:
  • the SIP header field or the SIP function identifier indicates that the UE performs the multi-party call service, and all the sessions or all the active sessions or all the held sessions of the UE belong to the multi-party call service;
  • the UE performs the multi-party call service by using the identifier information of other users included in the SIP message body, and the session with the other user that the UE participates belongs to the multi-party call service.
  • the SCC AS is further configured to participate in multiple active or multiple hold sessions according to the UE, and the multiple active sessions or multiple hold sessions belong to a multi-party call service.
  • the SCC AS is further configured to send the remote user identifiers to the CONF AS in a call request initiated by the CONF AS.
  • the SCC AS is further configured to initiate a transfer request to the CONF AS after initiating a call request to the CONF AS, that is, separately including the remote user identifiers in the transfer request, and sending the CONF AS.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本发明公开了一种多方通话业务连续性的实现方法，业务连续性服务器（SCC AS）接收到UE发起的以切换用标识为目标的呼叫请求后，如果判定UE执行了多方通话业务，则将与属于多方通话业务的各个会话相对应的各会话索引标识发送给会议服务器（CONF AS）；CONF AS分别以各所述会话索引标识为目标发送呼叫请求；SCC AS接收到以所述会话索引标识为目标的呼叫请求后，根据所述会话索引标识向相应的会话的远端用户发送更新请求。采用本发明方法，减少了切换步骤，可以有效缩短切换时间。

Description

一种多方通话业务连续性的实现方法及系统 技术领域
本发明涉及通信领域， 更具体地， 涉及一种 IP多媒体子系统中的多方 通话业务连续性（ Service Continuity, SC ) 的实现方法及系统。 背景技术
网络互联协议（ Internet Protocol, IP )多媒体子系统（ IP Multimedia Core Network Subsystem, 筒称 IMS )是由第三代合作伙伴计划 （ 3rd Generation Partnership Project, 3GPP )提出的一种基于 IP的网络架构， 构建了一个开 放而灵活的业务环境， 其支持多媒体应用， 能够为用户提供丰富的多媒体 业务。
在 IMS业务体系中， 控制层和业务层是分离的， 控制层不提供具体业 务， 只向业务层提供必要的触发、 路由、 计费等功能。 控制层中业务触发 和控制功能是呼叫会话控制功能（ Call Session Control Function, CSCF )完 成的， CSCF分为代理 Proxy ( P-CSCF )、 查询 Interrogating和服务 Serving 称 S-CSCF ) 三种类型， 其中负主要责任的是 Serving, Interrogating类型是 可选的。 业务层是由一系列应用服务器（Application Server, AS )组成， 能 提供具体业务服务， AS可以是独立的实体， 也可以存在于 S-CSCF中。 控 制层 S-CSCF根据用户的签约信息控制业务触发， 调用 AS上的业务， 实现 业务功能。 AS和 S-CSCF可以统称为服务设备 ( Server Equipment, SE )。 会话中的端到端设备称为用户设备（User Equipment, UE ), 负责与使用者 的交互。 有的 UE具有多种接入网络的方式， 包括通过 3GPP 的分组交换 ( Packet Switch, PS域 )接入网络、 通过其他非 3GPP的数据域接入网络， 甚至可以通过电路交换（Circuit Switch, CS )域接入网络等。 对于具有多种接入方式的 UE而言，无论其能同时使用多种接入方式还 是某一时刻只能使用一种接入方式， 假如其在一种接入方式下正在执行某 项业务， 比如通话业务， 当 UE移动到其他地方而需要改变使用的接入方式 时， 如果 UE和网络能提供某种方式使 UE正在执行的业务不被中断， 这样 的能力称之为业务连续性， 实现业务连续性的应用服务器称为业务连续性 应用服务器 （SCC AS )。
多方通话业务是 CS域的一种业务， 多方通话业务包含至少三个用户， 其中一个用户说的话可以被其他所有用户听到， 该业务由移动交换中心 ( Mobile Switch Center, MSC )提供。 多方通话业务在 IMS网絡中相对应 的业务为会议业务， 因此， 发生业务连续性时， UE从 CS域切换到 PS域 后， 多方通话业务也要切换为会议业务， IMS 网络中提供会议业务的应用 服务器称为会议服务器 （CONF AS )。
图 1是业务连续性前后信令 /媒体路径发生变化的示意图， 描述了业务 连续性发生前 UE-1与 UE-2建立会话的信令路径和媒体路径， 以及发生业 务连续性后 UE-1与 UE-2的信令路径和媒体路径。 为简化图示和描述， 将 S-CSCF和 SCC AS作为一个实体，两者间使用标准的会话发起协议（ Session Initiation Protocol, SIP )通讯。
如图 1所示， 业务连续性发生前， UE-1和 UE-2间建立了会话， 其信 令路径描述如下：
A102: UE-1和 eMSC之间的信令路径， 通过 CS域的信令协议互相通 讯， 对于 SCC AS而言， 这是访问端 （Access leg )路径；
A104: eMSC和 SCC AS/S-CSCF之间的信令路径， 通过 IMS的 SIP协 议互相通讯， 对于 SCC AS而言， 这也属于访问端 （Access leg )路径；
R101： SCC AS/S-CSCF和 UE-2之间的信令路径， 通过 IMS的 SIP协 议互相通讯， 对于 SCC AS而言， 这是远端 （Remote leg )路径； 业务连续性发生后， UE-1和 UE-2间的信令路径和媒体路径都发生了 变化， 其中信令路径的变化描述如下：
A112: UE-1和 P-CSCF之间的信令路径， 通过 IMS的 SIP协议互相通 讯， 对于 SCC AS而言， 这是访问端 （Access leg )路径；
A114: P-CSCF和 SCC AS/S-CSCF之间的信令路径， 通过 IMS的 SIP 协议互相通讯， 对于 SCC AS而言， 这也属于访问端 （Access leg )路径；
R101： SCC AS/S-CSCF和 UE-2之间的信令路径， 通过 IMS的 SIP协 议互相通讯， 对于 SCC AS而言， 这是远端 （Remote leg )路径， 在业务连 续性发生后， 该远端路径没有变化。
以下描述为筒明起见，将 MSC和 IMS网络的媒体网关（分为控制部分
MGCF 和媒体处理部分 MGW )合为一个实体描述， 统称为网络交互实体 ( InterWorking Function entities , IWF ), 将 SCC AS和 CSCF合为一个实体 描述。
图 2是现有的多方通话业务连续性的实现流程图， 描述了 UE-A在 CS 域和 UE-B、 UE-C间建立多方通话， 其中 UE-A在 CS域与 IWF建立了 CS 媒体链接， IWF在 IMS域分別与 UE-B建立了 IMS媒体链接 1及与 UE-C 建立了 IMS媒体链接 2, UE-A从 CS域切换到 PS域后， UE-A及网络如何 实现多方通话业务连续性的过程， 其具体描述如下：
步骤 201、 UE-A在 PS域向 SCC AS发起 IMS呼叫， 比如发送邀清 ( INVITE ) 消息， 呼叫经过 CSCF到达 SCC AS。
步骤 202、 SCC AS发现 UE-A参与 IMS媒体链接 1和 2， 于是选择更 新媒体链接 1 , 比如发送重邀请 ( relNVITE ) 消息， 消息途经 CSCF到达 UE-B o
该步骤中， 由于所有会话都锚定在 SCC AS, 因此， SCC AS可以发现 UE-A参与了多个会话。 步骤 203、 UE-B同意更新， 发送 "200 OK" 消息， 消息途经 CSCF到 达 SCC AS。
步骤 204、 SCC AS应答 UE-A的呼叫， 比如发送 "200 OK" 消息， 携 带另一个会话（即与 UE-C之间的会话） 的会话标识信息 ， 比如在 SIP消 息体中携带， 消息途经 CSCF到达 UE-A。
步骤 205、 UE-A发起新的 IMS呼叫， 呼叫 UE-C, 比如发送 INVITE 消息，携带步骤 204中的会话标识信息，比如在 Replaces头域或 Target-Dialog 头域中携带， 消息途经 CSCF到达 SCC AS。
步骤 206、 SCC AS根据步骤 205中携带的标识信息 , 更新 IMS媒体链 接 2， 比如发生 relNVITE消息， 消息途经 CSCF到达 UE-C。
步骤 207、 UE-C同意更新， 比如发送 " 200 OK" 消息， 消息途经 CSCF 到达 SCC AS。
步骤 208、 SCC AS应答 UE-A的呼叫， 比如发送 "200 OK" 消息， 消 息途经 CSCF到达 UE-A。
至此， IMS媒体链接 1 被更新为 UE-A和 UE-B间的 IMS媒体链接，
IMS媒体链接 2被更新为 UE-A和 UE-C间的 IMS媒体链接。
步骤 209 ~ 210、 UE-A在 IMS域呼叫 CONF AS, 比如发送 INVITE消 息， 消息途经 CSCF、 SCC AS到达 CONF AS。
步骤 211 ~ 212、 CONF AS创建会议， 并应答呼叫， 比如发送 "200 OK" 消息， 消息途经 CSCF、 SCC AS到达 UE-A。
至此， UE-A和 CONF AS间建立起了 IMS媒体链接 3。
步骤 213 - 214、 UE-A邀请 UE-C加入会议， 比如发送转移 （ REFER ) 消息， 消息途经 CSCF、 SCC AS到达 CONF AS。
UE-A在和 CONF AS间建立起 IMS媒体链接 3后， 可以先邀请 UE-C 加入会议， 也可以先邀请 UE-B加入。 步骤 215 ~ 216、 CONF AS表示同意， 比如发送 "202 Accepted" 消息， 消息途经 CSCF、 SCC AS到达 UE-A。
步骤 217、 CONF AS呼叫 UE-C , 比如发送 INVITE消息。
步骤 218、 UE-C应答呼叫， 比如发送 "200 OK" 消息。
步骤 219 - 220、 UE-A释放 UE-C的会话， 比如发送挂断（ BYE )消息， 消息途经 CSCF、 SCC AS到达 UE- (：。
步驟 221 ~ 222、 UE-C同意挂断， 比如发送 "200 OK" 消息， 消息途 经 CSCF、 SCC AS到达 UE-A。
步骤 223、 UE-A重复步骤 213 ~ 222的步骤， 只是将 UE-C改为 UE-B。 至此， CONF AS与 UE-B间建立 IMS媒体链接 4,与 UE-C间建立 IMS 媒体链接 5 , UE-A与 UE-B间的媒体链接 1及 UE-A与 UE-C间的媒体链 接 2被释放， CONF AS将 IMS媒体链接 3、 4、 5桥接起来。
步骤 224 ~ 225、 SCC AS释放 IWF侧的 IMS媒体链接 1和 IMS媒体链 接 2的资源 , 比如分别发送 BYE消息， 消息途经 CSCF到达 IWF, CS媒 体链接被释放。
可以看出， 上述现有的多方通话业务连续性实现方法存在如下缺点： 步骤繁多， 耗时较长。 发明内容
本发明要解决的技术问题是提供一种多方通话业务连续性实现方法及 系统， 能够减少切换步骤， 有效地缩短切换时间。
为达到上述目的， 本发明的技术方案是这样实现的：
一种多方通话业务连续性的实现方法， 包括：
业务连续性服务器 SCC AS接收到所述 UE发起的以切换用标识为目标 的呼叫请求后，如果判定所述 UE执行了多方通话业务， 则将与属于多方通 话业务的各个会话相对应的各会话索引标识发送给会议服务器 CONF AS; 所述 CONF AS分别以各所述会话索引标识为目标发送呼叫请求； 所述 SCC AS接收到以所述会话索引标识为目标的呼叫请求后，根据所 述会话索引标识向相应的会话的远端用户发送更新请求。
所述以切换用标识为目标的呼叫请求中携带有多方通话业务标识； 所述 SCC AS判定 UE执行了多方通话业务为：根据所述多方通话业务 标识判定所述 UE执行了多方通话业务。
所述多方通话业务标识中包括以下指示信息的一种或其组合： 通过特定的会话发起协议 SIP头域、或 SIP功能标识指示所述 UE执行 了多方通话业务，且所述 UE参与的所有会话或所有激活会话或所有保持会 话属于多方通话业务；
通过 SIP消息体中包含的其他用户的标识信息指示所述 UE执行了多方 通话业务， 且所述 UE参与的与所述其他用户的会话属于多方通话业务。
所述 SCC AS判定所述 UE执行了多方通话业务为： 根据所述 UE参与 多个激活会话或多个保持会话， 且所述多个激活会话或多个保持会话属于 多方通话业务。
所述 SCC AS将所述会话索引标识发送给 CONF AS为： 将所述会话索 ？ I标识包含在向所述 CONF AS发起的呼叫请求中发送给所述 CONF AS。
所述 SCC AS在向所述 CONF AS发起呼叫请求后还包括： 分别向所述 CONF AS发起转移请求， 分别将各所述会话索引标识包含在所述转移请求 中发送给所述 CONF AS。
一种多方通话业务连续性的实现方法， 包括：
业务连续性服务器 SCC AS接收到所述 UE发起的以切换用标识为目标 的呼叫请求后，如果判定所述 UE执行了多方通话业务， 则释放属于多方通 话业务的各个会话， 并将所述各个会话远端用户标识发送给会议服务器 CONF AS; 所述 CONF AS分别以所述各会话远端用户标识为目标发送呼叫请求， 与所述各会话远端用户在分组交换域建立起会议会话。
所述以切换用标识为目标的呼叫请求中携带有多方通话业务标识， 所 述 SCC AS判定 UE执行了多方通话业务为：根据所述多方通话业务标识判 定所述 UE执行了多方通话业务。
所述多方通话业务标识中包括以下指示信息的一种或其组合： 通过特定的会话发起协议 SIP头域、或 SIP功能标识指示所述 UE执行 了多方通话业务，且所述 UE参与的所有会话或所有激活会话或所有保持会 话属于多方通话业务；
通过 SIP消息体中包含的其他用户的标识信息指示所述 UE执行了多方 通话业务， 且所述 UE参与的与所述其他用户的会话属于多方通话业务。
所述 SCC AS判定所述 UE执行了多方通话业务为： 根据所述 UE参与 了多个激活或多个保持会话， 且所述多个激活会话或多个保持会话属于多 方通话业务。
所述 SCC AS将所述会话索 1标识发送给 CONF AS为： 将所述各远端 用户标识包含在向所述 CONF AS发起的呼叫请求中发送给所述 CONF AS。
所述 SCC AS在向所述 CONF AS发起呼叫请求后还包括： 分别向所述 CONF AS发起转移请求， 即分别将所述各远端用户标识包含在所述转移请 求中发送给所述 CONF AS。
一种多方通话业务连续性的实现系统， 包括： SCC AS和 CONF AS, 其中，
所述 SCC AS , 用于在接收到所述 UE发起的以切换用标识为目标的呼 叫请求后，如果判定所述 UE执行了多方通话业务， 则将与属于多方通话业 务的各个会话相对应的各会话索引标识发送给 CONF AS; 以及在接收到以 所述会话索引标识为目标的呼叫请求后， 根据所述会话索引标识向相应的 会话的远端用户发送更新请求；
所述 CONF AS, 用于在收到来自 SCC AS的各会话索 I标识后， 分别 以各所述会话索引标识为目标发送呼叫请求。
所述 SCC AS接收到的所述以切换用标识为目标的呼叫请求携带有多 方通话业务标识；
所述 SCC AS , 还用于根据所述多方通话业务标识判定所述 UE执行了 多方通话业务。
所述 SCC AS用于判定所述 UE执行了多方通话业务的多方通话业务标 识中包括以下指示信息的一种或其组合：
通过特定的会话发起协议 SIP头域、或 SIP功能标识指示所述 UE执行 了多方通话业务，且所述 UE参与的所有会话或所有激活会话或所有保持会 话属于多方通话业务；
通过 SIP消息体中包含的其他用户的标识信息指示所述 UE执行了多方 通话业务， 且所述 UE参与的与所述其他用户的会话属于多方通话业务。
所述 SCC AS ,还用于根据所述 UE参与多个激活会话或多个保持会话， 且所述多个激活会话或多个保持会话属于多方通话业务。
所述 SCC AS, 还用于将所述会话索引标识包含在向所述 CONF AS发 起的呼叫请求中发送给所述 CONF AS。
所述 SCC AS, 还用于在向所述 CONF AS发起呼叫请求后， 分别向所 述 CONF AS发起转移请求，分别将各所述会话索引标识包含在所述转移请 求中发送给所述 CONF AS。
一种多方通话业务连续性的实现系统， 包括： SCC AS和 CONF AS, 其中，
所述 SCC AS， 用于在接收到所述 UE发起的以切换用标识为目标的呼 叫请求后，如果判定所述 UE执行了多方通话业务， 则释放属于多方通话业 务的各个会话， 并将所述各个会话远端用户标识发送给 CONF AS;
所述 CONF AS , 用于分别以所述各会话远端用户标识为目标发送呼叫 请求， 与所述各会话远端用户在分组交换域建立起会议会话。
所述 SCC AS接收的以切换用标识为目标的呼叫请求中携带有多方通 话业务标识，
所述 SCC AS , 还用于根据所述多方通话业务标识判定所述 UE执行了 多方通话业务。
所述 SCC AS用于判定所述 UE执行了多方通话业务的多方通话业务标 识中包括以下指示信息的一种或其组合：
通过特定的会话发起协议 SIP头域、或 SIP功能标识指示所述 UE执行 了多方通话业务，且所述 UE参与的所有会话或所有激活会话或所有保持会 话属于多方通话业务；
通过 SIP消息体中包含的其他用户的标识信息指示所述 UE执行了多方 通话业务， 且所述 UE参与的与所述其他用户的会话属于多方通话业务。
所述 SCC AS , 还用于根据所述 UE参与了多个激活或多个保持会话， 且所述多个激活会话或多个保持会话属于多方通话业务。
所述 SCC AS, 还用于将所述各远端用户标识包含在向所述 CONF AS 发起的呼叫请求中发送给所述 CONF AS。
所述 SCC AS, 还用于在向所述 CONF AS发起呼叫请求后， 分别向所 述 CONF AS发起转移请求， 即分别将所述各远端用户标识包含在所述转移 请求中发送给所述 CONF AS。 附图说明
图 1是发生业务连续性前后信令 /媒体路径发生变化的示意图； 图 2是现有的多方通话业务连续性实现流程图；
图 3是本发明实施例一的多方通话业务连续性实现流程图； 图 4是本发明实施例二的多方通话业务连续性实现流程图；
图 5是本发明实施例三的多方通话业务连续性实现流程图；
图 6是本发明实施例四的多方通话业务连续性实现流程图。 具体实施方式
本发明的核心思想是： SCC AS通过识别出 UE参与了多方通话业务， 从而代替 UE要求 CONF AS创建会议， 并将其余多方通话业务参与方加入 所创建的会议。
下面将结合附图及实施例对本发明的技术方案进行更详细的说明。 实施例一
图 3 是本发明实施例一的多方通话业务连续性实现流程图， 描述了 UE-A在 CS域和 UE-B、 UE-C间建立多方通话，其中 UE-A在 CS域与 IWF 建立了 CS媒体链接， IWF在 IMS域分别与 UE-B建立了 IMS媒体链接 1 及与 UE-C建立了 IMS媒体链接 2, UE-A切换到 PS域后， UE-A及网絡如 何实现多方通话业务连续性的过程， 其描述如下：
步骤 301、 UE-A在 PS域以切换用标识为目标发起 IMS呼叫， 比如发 送邀请（ INVITE )消息 ,在消息中可携带多方通话业务标识，比如在 Contact 头域中含 sip.rendering= "yes" ; 或在 SIP消息体中携带 UE-B和 UE-C的标 识信息； 消息中也可不携带多方通话业务标识， 呼叫经过 CSCF 的路由到 达 SCC AS , SCC AS根据以切换用标识为目标的呼叫请求判断出 UE-A要 执行转移， 且根据其中的切换用标识可区分出是从 CS域到 PS域的转移， 而如果是切换用号码， 则可区分出是从 PS域到 CS域的转移。
其中，多方通话业务标识可以是用于标识用户 UE-A参与了多方通话业 务的特定 SIP头域、 或 SIP功能标识等， 也可以是除用户 UE-A外的多方通 话业务参与方 （即 UE-B和 UE-C ) 的标识信息， 还可两者都有。
步骤 302、 如果步骤 301中携带有多方通话业务标识， SCC AS可通过 该标识识别出 UE-A执行了多方通话业务，如果多方通话标识中包含有其他 用户标识信息， 则 UE-A 与这些其他用户的会话属于多方通话业务， 否则 UE-A的所有会话或所有激活会话或所有保持会话都属于多方通话业务；如 果步骤 301中不携带多方通话业务标识， SCC AS也可根据 UE-A参与了多 个激活会话或多个保持会话识别出 UE-A执行了多方通话业务，且这些多个 激活会话或多个保持会话属于多方通话业务。
此实施例中， IMS媒体链接 1和 2对应的会话属于多方通话业务， SCC AS向 CONF AS发起呼叫， 比如发送 INVITE消息， SCC AS分别生成 IMS 媒体链接 1和链接 2的会话索引标识， 并将生成的各会话索引标识携带入 呼叫消息， 比如在 SIP消息体中携带， 消息途经 CSCF到达 CONF AS。
其中， 所生成的各会话索 I标识用于关联到 UE- A所参与的各个会话。 该标识的域名部分为 SCC AS的域名， 以便 CONF AS收到该会话索引标识 后， 以该会话索引标识为目标发起的呼叫请求能够到达 SCC AS。 但其域名 部分也可不是 SCC AS的域名， 而是通过 CSCF的路由配置，使以该会话索 引标识为目标发起的呼叫请求能够到达 SCC AS。 而该会话索引标识的用户 名部分则可自行定义。
步骤 303、 CONF AS创建会议， 并应答呼叫， 比如发送 "200 OK" 消 息， 消息途经 CSCF到达 SCC AS。
步骤 304、 SCC AS转发应答消息给 UE-A, 比如发送 " 200 OK" 消息， 消息途经 CSCF到达 UE-A。
至此， UE-A和 CONF AS间建立 IMS媒体链接 3。
步骤 305、 CONF AS根据步骤 302中接收到的各会话索弓 |标识， 按标 准的会议流程发起呼叫请求， 以收到的 IMS媒体链接 1的会话索引标识为 目标， 比如发送 INVITE消息， 目标为 IMS媒体链接 1的会话索引标识， 消息途经 CSCF的路由到达 SCC AS。 CONF AS可以先呼叫 IMS媒体链接 1的会话索引标识再呼叫 IMS媒 体链接 2的会话索 I标识， 也可以反过来， 还可以同时分别呼叫 IMS媒体 链接 1和 IMS媒体链接 2的会话索引标识。
步骤 306、 SCC AS更新 UE-B, 比如发送 relNVITE消息， 消息途经 CSCF到达 UE-B。
步骤 307、 UE-B同意更新， 比如发送 " 200 OK" 消息， 消息途经 CSCF 到达 SCC AS。
步骤 308、 SCC AS应答步骤 305的呼叫， 比如发送 "200 OK" 消息， 消息途经 CSCF到达 CONF AS。
步骤 309、 CONF AS, SCC AS重复步骤 305 ~ 308, 只是 CONF AS将
IMS媒体链接 1的会话索引标识改为 IMS媒体链接 2的会话索引标识， SCC AS将 UE-B改为 UE- (：。
自此， IMS媒体链接 1被更新为 CONF AS与 UE-B的媒体链接， IMS 媒体链接 2被更新为 CONF AS与 UE-C的媒体链接， CONF AS将 IMS媒 体链接 1、 2、 3桥接起来。
步 310 ~ 313、 与图 2中的步骤 224 ~ 227相同。 实施例二
图 4 是本发明实施例二的多方通话业务连续性实现流程图， 描述了 UE-A在 CS域和 UE-B、 UE-C间建立多方通话 ,其中 UE-A在 CS域与 IWF 建立了 CS媒体链接， IWF在 IMS域分别与 UE-B建立了 IMS媒体链接 1 及与 UE-C建立了 IMS媒体链接 2， UE-A切换到 PS域， UE-A及网络如何 实现多方通话业务连续性的过程， 其描述如下：
步骤 401、 与图 3的步骤 301相同。
步驟 402、 如果步骤 401中携带有多方通话业务标识， SCC AS可通过 该标识识别出 UE-A执行了多方通话业务；如果多方通话标识中包含有其他 用户标识信息， 则 UE-A与其他用户的会话属于多方通话业务， 否则 UE-A 的所有会话或所有激活会话或所有保持会话都属于多方通话业务， 如果该 步骤 401中没有携带多方通话业务标识， SCC AS也可根据 UE- A参与了多 个激活会话或多个保持会话识别出 UE-A执行了多方通话业务，且这些多个 激活会话或多个保持会话属于多方通话业务。
此实施例中， IMS媒体链接 1和 2对应的会话属于多方通话业务， SCC AS向 CONF AS发起呼叫， 比如发送 INVITE消息， SCC AS分别生成 IMS 媒体链接 1和链接 2的各会话索 I标识， 消息途经 CSCF到达 CONF AS； 其中， 所生成的各会话索引标识用于关联到所参与的各个会话。 该标 识的域名部分为 SCC AS的域名， 以便 CONF AS收到该会话索弓 I标识后 , 以该会话索引标识为目标发起的呼叫请求能够到达 SCC AS ,也可不是 SCC AS的域名， 通过 CSCF的路由配置， 使以该会话索引标识为目标发起的呼 叫请求能够到达 SCC AS; 而用户名部分则可自行定义。
步骤 403、 CONF AS创建会议， 并应答呼叫， 比如发送 "200 OK" 消 息， 消息途经 CSCF到达 SCC AS。
步驟 404、 SCC AS转发应答消息给 UE-A, 比如发送 "200 O " 消息， 消息途经 CSCF到达 UE-A。
至此， UE-A和 CONF AS间建立 IMS媒体链接 3。
步骤 405、 SCC AS请求 CONF AS邀请 IMS媒体链接 1的会话索引标 识加入会议， 比如发送 REFER消息， Refer-To头域为 IMS媒体链接 1的会 话索引标识， 消息途经 CSCF到达 CONF AS。
SCC AS可以先要求 CONF AS加入 IMS媒体链接 1的会话索引标识再 要求加入 IMS媒体链接 2的会话索 I标识， 也可以反过来， 还可以同时分 别要求 CONF AS加入 IMS媒体链接 1和 IMS媒体链接 2的会话索 I标识。
步骤 406、 CONF AS同意邀请， 比如发送 "202 Accepted" 消息， 消息 途经 CSCF到达 SCC AS。
步骤 407、 CONF AS根据步骤 405中的 IMS媒体链接 1的会话索引标 识发起呼叫， 比如发送 INVITE 消息， 目标为该会话索引标识， 消息途经 CSCF到达 SCC AS。
步骤 408、 SCC AS更新 UE-B, 比如发送 relNVITE消息， 消息途经
CSCF到达 UE-B。
步驟 409、 UE-B同意更新， 比如发送 " 200 OK" 消息， 消息途经 CSCF 到达 SCC AS。
步骤 410、 SCC AS应答步骤 407的呼叫， 比如发送 "200 OK" 消息， 消息途经 CSCF到达 CONF AS。
步骤 411、 CONF AS, SCC AS重复步骤 405 ~ 410， 只是 CONF AS将 IMS媒体链接 1的会话索引标识改为 IMS媒体链接 2的会话索引标识， SCC AS将 UE-B改为 UE- (：。
自此， IMS媒体链接 1被更新为 CONF AS与 UE-B的媒体链接， IMS 媒体链接 2被更新为 CONF AS与 UE-C的媒体链接， CONF AS将 IMS媒 体链接 1、 2、 3桥接起来。
步骤 412 - 415、 与图 2中的步骤 224 ~ 227相同。 实施例三
图 5 是本发明实施例三的多方通话业务连续性实现流程图， 描述了
UE-A在 CS域和 UE-B、 UE-C间建立多方通话，其中 UE-A在 CS域与 IWF 建立了 CS媒体链接， IWF在 IMS域分别与 UE-B建立了 IMS媒体链接 1 及与 UE-C建立了 IMS媒体链接 2, UE-A切换到 PS域后， UE-A及网络如 何实现多方通话业务连续性的过程， 其描述如下：
步驟 501、 与图 3的步骤 301相同。
步骤 502、 如果步骤 501中携带有多方通话业务标识， SCC AS可通过 该标识识别出 UE-A执行了多方通话业务，如果多方通话标识中包含有其他 用户标识信息， 则 UE-A与其他用户的会话属于多方通话业务， 否则 UE-A 的所有会话或所有激活会话或所有保持会话都属于多方通话业务； 如果步 骤 501中不带多方通话业务标识， SCC AS也可根据 UE-A参与了多个激活 会话或多个保持会话识别出 UE-A执行了多方通话业务，且这些多个激活会 话或多个保持会话属于多方通话业务。
此实施例中， IMS媒体链接 1和 2对应的会话属于多方通话业务。 步骤 503 ~ 504、 SCC AS向 IMS媒体链接 1的远端用户 UE-B发送释 放请求以释放其上 IMS媒体链接 1的资源 , 比如发生释放 ( BYE ) 消息 , 携带 IMS媒体链接 1所对应会话的会话标识， 消息途经 CSCF到达 UE-B。
步骤 505 ~ 506、 SCC AS向 IMS媒体链接 2的远端用户 UE-C发送释 放请求以释放其上 IMS媒体链接 2的资源， 比如发生释放 ( BYE ) 消息， 携带 IMS媒体链接 2所对应会话的会话标识， 消息途经 CSCF到达 UE- (：。
步骤 507、 SCC AS向 IMS媒体链接 1的近端， 即 IWF， 发送释放请求 以释放其上 IMS媒体链接 1的资源，比如发生 BYE (释放 )消息，携带 IMS 媒体链接 1所对应会话的会话标识， 消息途经 CSCF到达 IWF。
步骤 508、 SCC AS向 IMS媒体链接 2的近端， 即 IWF, 发送释放请求 以释放其上 IMS媒体链接 2的资源，比如发生 BYE (释放 )消息，携带 IMS 媒体链接 2所对应会话的会话标识， 消息途经 CSCF到达 IWF。
步骤 509、 SCC AS向 CONF AS发起呼叫， 比如发送 INVITE消息， 并 将各会话的远端用户标识携带入呼叫消息， 比如在 SIP 消息体中携带， 消 息途经 CSCF到达 CONF AS。
步骤 509可与步骤 503 ~ 508同时执行， 无先后顺序。
步驟 510、 CONF AS创建会议， 并应答呼叫， 比如发送 "200 OK" 消 息， 消息途经 CSCF到达 SCC AS。 步骤 511、 SCC AS转发应答消息给 UE-A , 比如发送 "200 OK" 消息， 消息途经 CSCF到达 UE-A。
至此， UE-A和 CONF AS间建立 IMS媒体链接 3 , IMS媒体链接 1和
2被释放。
步骤 512、 CONF AS根据步骤 503中接收到的各用户标识， 按标准的 会议流程发起呼叫请求，以收到的 UE-B用户标识为目标，比如发送 INVITE 消息， 目标为 UE-B的用户标识， 消息途经 CSCF的路由到达 UE-B。
CONF AS可以先呼叫 UE-B的用户标识再呼叫 UE-C的用户标识， 也 可以反过来， 还可以同时分别呼叫 UE-B和 UE-C的用户标识。
步骤 513、 UE-B应答呼叫， 比如发送 " 200 OK" 消息， 消息途经 CSCF 到达 CONF AS。
步骤 514、 CONF AS重复步骤 512 ~ 513 , 只是 CONF AS将 UE-B的用 户标识改为 UE-C的用户标识。
自此， IMS媒体链接 4及 IMS媒体链接 5被创建， CONF AS将 IMS 媒体链接 3、 4、 5桥接起来。 实施例四
图 6 是本发明实施例四的多方通话业务连续性实现流程图， 描述了 UE-A在 CS域和 UE-B、 UE-C间建立多方通话，其中 UE-A在 CS域与 IWF 建立了 CS媒体链接， IWF在 IMS域分别与 UE-B建立了 IMS媒体链接 1 及与 UE-C建立了 IMS媒体链接 2, UE-A切换到 PS域， UE-A及网络如何 实现多方通话业务连续性的过程， 其描述如下：
步骤 601 ~ 608、 与图 5的步骤 501 ~ 508相同。
步骤 609、 SCC AS向 CONF AS发起呼叫， 比如发送 INVITE消息， 消 息途经 CSCF到达 CONF AS。
步骤 609可与步骤 603 ~ 608同时执行， 无先后顺序。 步骤 610、 CONF AS创建会议， 并应答呼叫， 比如发送 "200 OK" 消 息， 消息途经 CSCF到达 SCC AS。
步骤 611、 SCC AS转发应答消息给 UE-A, 比如发送 "200 OK" 消息， 消息途经 CSCF到达 UE-A。
至此， UE-A和 CONF AS间建立 IMS媒体链接 3 , IMS媒体链接 1和
2被释放。
步驟 612、 SCC AS请求 CONF AS邀请 UE-B的用户标识加入会议， 比 如发送 REFER消息， Refer-To头域为 UE-B的用户标识， 消息途经 CSCF 到达 CONF AS。
SCC AS可以先要求 CONF AS加入 UE-B的用户标识再要求加入 UE-C 的用户标识， 也可以反过来， 还可以同时分别要求 CONF AS加入 UE-B和
UE-C的用户标识。
步骤 613、 CONF AS同意邀请， 比如发送 "202 Accepted" 消息， 消息 途经 CSCF到达 SCC AS。
步骤 614、 CONF AS根据步骤 612中的 UE-B的用户标识发起呼叫， 比如发送 INVITE消息， 目标为 UE-B 的用户标识， 消息途经 CSCF到达
UE-B o
步骤 615、 UE-B应答呼叫， 比如发送 " 200 OK" 消息， 消息途经 CSCF 到达 CONF AS。
步骤 616、 CONF AS重复步骤 612 ~ 615， 只是 CONF AS将 UE-B的用 户标识改为 UE-C的用户标识。
自此， IMS媒体链接 4与 IMS媒体链接 5被创建， CONF AS将 IMS 媒体链接 3、 4、 5桥接起来。
此外， 本发明还提出一种多方通话业务连续性的实现系统， 包括： SCC AS和 CONF AS , 其中， SCC AS , 用于在接收到所述 UE发起的以切换用标识为目标的呼叫请 求后，如果判定所述 UE执行了多方通话业务， 则将与属于多方通话业务的 会话索引标识为目标的呼叫请求后， 根据所述会话索引标识向相应的会话 的远端用户发送更新请求；
CONF AS , 用于在收到来自 SCC AS的各会话索弓 I标识后， 分别以各 所述会话索引标识为目标发送呼叫请求。
所述 SCC AS接收到的所述以切换用标识为目标的呼叫请求携带有多 方通话业务标识；
所述 SCC AS , 还用于根据所述多方通话业务标识判定所述 UE执行了 多方通话业务。
所述 SCC AS用于判定所述 UE执行了多方通话业务的多方通话业务标 识中包括以下指示信息的一种或其组合：
通过特定的会话发起协议 SIP头域、或 SIP功能标识指示所述 UE执行 了多方通话业务，且所述 UE参与的所有会话或所有激活会话或所有保持会 话属于多方通话业务；
通过 SIP消息体中包含的其他用户的标识信息指示所述 UE执行了多方 通话业务， 且所述 UE参与的与所述其他用户的会话属于多方通话业务。
所述 SCC AS ,还用于根据所述 UE参与多个激活会话或多个保持会话， 且所述多个激活会话或多个保持会话属于多方通话业务。
所述 SCC AS, 还用于将所述会话索引标识包含在向所述 CONF AS发 起的呼叫请求中发送给所述 CONF AS。
所述 SCC AS, 还用于在向所述 CONF AS发起呼叫请求后， 分别向所 述 CONF AS发起转移请求，分别将各所述会话索引标识包含在所述转移请 求中发送给所述 CONF AS。 本发明还提出一种多方通话业务连续性的实现系统， 包括： SCC AS和 CONF AS, 其中，
所述 SCC AS , 用于在接收到所述 UE发起的以切换用标识为目标的呼 叫请求后，如果判定所述 UE执行了多方通话业务， 则释放属于多方通话业 务的各个会话， 并将所述各个会话远端用户标识发送给 CONF AS;
所述 CONF AS , 用于分别以所述各会话远端用户标识为目标发送呼叫 请求， 与所述各会话远端用户在分组交换域建立起会议会话。
所述 SCC AS接收的以切换用标识为目标的呼叫请求中携带有多方通 话业务标识，
所述 SCC AS , 还用于根据所述多方通话业务标识判定所述 UE执行了 多方通话业务。
所述 SCC AS用于判定所述 UE执行了多方通话业务的多方通话业务标 识中包括以下指示信息的一种或其组合：
通过特定的会话发起协议 SIP头域、或 SIP功能标识指示所述 UE执行 了多方通话业务，且所述 UE参与的所有会话或所有激活会话或所有保持会 话属于多方通话业务；
通过 SIP消息体中包含的其他用户的标识信息指示所述 UE执行了多方 通话业务， 且所述 UE参与的与所述其他用户的会话属于多方通话业务。
所述 SCC AS , 还用于根据所述 UE参与了多个激活或多个保持会话， 且所述多个激活会话或多个保持会话属于多方通话业务。
所述 SCC AS, 还用于将所述各远端用户标识包含在向所述 CONF AS 发起的呼叫请求中发送给所述 CONF AS。
所述 SCC AS, 还用于在向所述 CONF AS发起呼叫请求后， 分别向所 述 CONF AS发起转移请求， 即分别将所述各远端用户标识包含在所述转移 请求中发送给所述 CONF AS。 当然， 本发明还可有其他多种实施例， 在不背离本发明精神及其实质 的情况下， 熟悉本领域的技术人员当可根据本发明作出各种相应的改变和 变形， 但这些相应的改变和变形都应属于本发明所附的权利要求的保护范 围。

Claims

权利要求书
1、 一种多方通话业务连续性的实现方法， 其特征在于， 该方法包括： 业务连续性服务器 SCC AS接收到所述 UE发起的以切换用标识为目标 的呼叫请求后，如果判定所述 UE执行了多方通话业务， 则将与属于多方通 话业务的各个会话相对应的各会话索引标识发送给会议服务器 CONF AS; 所述 CONF AS分別以各所述会话索引标识为目标发送呼叫请求； 所述 SCC AS接收到以所述会话索引标识为目标的呼叫请求后，根据所 述会话索引标识向相应的会话的远端用户发送更新请求。
2、 如权利要求 1所述的方法， 其特征在于，
所述以切换用标识为目标的呼叫请求中携带有多方通话业务标识； 所述 SCC AS判定 UE执行了多方通话业务为：根据所述多方通话业务 标识判定所述 UE执行了多方通话业务。
3、 如权利要求 2所述的方法， 其特征在于，
所述多方通话业务标识中包括以下指示信息的一种或其组合： 通过特定的会话发起协议 SIP头域、或 SIP功能标识指示所述 UE执行 了多方通话业务，且所述 UE参与的所有会话或所有激活会话或所有保持会 话属于多方通话业务；
通过 SIP消息体中包含的其他用户的标识信息指示所述 UE执行了多方 通话业务， 且所述 UE参与的与所述其他用户的会话属于多方通话业务。
4、 如权利要求 1所述的方法， 其特征在于，
所述 SCC AS判定所述 UE执行了多方通话业务为： 根据所述 UE参与 多个激活会话或多个保持会话， 且所述多个激活会话或多个保持会话属于 多方通话业务。
5、 如权利要求 1至 4任一项所述的方法， 其特征在于，
所述 SCC AS将所述会话索引标识发送给 CONF AS为： 将所述会话索 ？ I标识包含在向所述 CONF AS发起的呼叫请求中发送给所述 CONF AS。
6、 如权利要求 5所述的方法， 其特征在于，
所述 SCC AS在向所述 CONF AS发起呼叫请求后还包括： 分别向所述 CONF AS发起转移请求， 分别将各所述会话索引标识包含在所述转移请求 中发送给所述 CONF AS。
7、 一种多方通话业务连续性的实现方法， 其特征在于， 该方法包括： 业务连续性服务器 SCC AS接收到所述 UE发起的以切换用标识为目标 的呼叫请求后，如果判定所述 UE执行了多方通话业务， 则释放属于多方通 话业务的各个会话， 并将所述各个会话远端用户标识发送给会议服务器 CONF AS;
所述 CONF AS分别以所述各会话远端用户标识为目标发送呼叫请求， 与所述各会话远端用户在分组交换域建立起会议会话。
8、 如权利要求 7所述的方法， 其特征在于，
所述以切换用标识为目标的呼叫请求中携带有多方通话业务标识， 所 述 SCC AS判定 UE执行了多方通话业务为：根据所述多方通话业务标识判 定所述 UE执行了多方通话业务。
9、 如权利要求 8所述的方法， 其特征在于，
所述多方通话业务标识中包括以下指示信息的一种或其组合： 通过特定的会话发起协议 SIP头域、或 SIP功能标识指示所述 UE执行 了多方通话业务，且所述 UE参与的所有会话或所有激活会话或所有保持会 话属于多方通话业务；
通过 SIP消息体中包含的其他用户的标识信息指示所述 UE执行了多方 通话业务， 且所述 UE参与的与所述其他用户的会话属于多方通话业务。
10、 如权利要求 7所述的方法， 其特征在于，
所述 SCC AS判定所述 UE执行了多方通话业务为： 根据所述 UE参与 了多个激活或多个保持会话， 且所述多个激活会话或多个保持会话属于多 方通话业务。
11、 如权利要求 7至 10任一项所述的方法， 其特征在于，
所述 SCC AS将所述会话索引标识发送给 CONF AS为： 将所述各远端 用户标识包含在向所述 CONF AS发起的呼叫请求中发送给所述 CONF AS。
12、 如权利要求 11所述的方法， 其特征在于，
所述 SCC AS在向所述 CONF AS发起呼叫请求后还包括： 分别向所述 CONF AS发起转移请求， 即分别将所述各远端用户标识包含在所述转移请 求中发送给所述 CONF AS。
13、 一种多方通话业务连续性的实现系统， 其特征在于， 该系统包括： SCC AS和 CONF AS, 其中，
所述 SCC AS , 用于在接收到所述 UE发起的以切换用标识为目标的呼 叫请求后，如果判定所述 UE执行了多方通话业务， 则将与属于多方通话业 务的各个会话相对应的各会话索引标识发送给 CONF AS; 以及在接收到以 所述会话索引标识为目标的呼叫请求后， 根据所述会话索引标识向相应的 会话的远端用户发送更新请求；
所述 CONF AS, 用于在收到来自 SCC AS的各会话索 I标识后， 分别 以各所述会话索引标识为目标发送呼叫请求。
14、 如权利要求 13所述的系统， 其特征在于， 所述 SCC AS接收到的 所述以切换用标识为目标的呼叫请求携带有多方通话业务标识；
所述 SCC AS , 还用于根据所述多方通话业务标识判定所述 UE执行了 多方通话业务。
15、 如权利要求 14所述的系统， 其特征在于， 所述 SCC AS用于判定 所述 UE执行了多方通话业务的多方通话业务标识中包括以下指示信息的 一种或其组合： 通过特定的会话发起协议 SIP头域、或 SIP功能标识指示所述 UE执行 了多方通话业务，且所述 UE参与的所有会话或所有激活会话或所有保持会 话属于多方通话业务；
通过 SIP消息体中包含的其他用户的标识信息指示所述 UE执行了多方 通话业务， 且所述 UE参与的与所述其他用户的会话属于多方通话业务。
16、 如权利要求 13所述的系统， 其特征在于，
所述 SCC AS，还用于根据所述 UE参与多个激活会话或多个保持会话， 且所述多个激活会话或多个保持会话属于多方通话业务。
17、 如权利要求 13至 16任一项所述的系统， 其特征在于，
所述 SCC AS, 还用于将所述会话索引标识包含在向所述 CONF AS发 起的呼叫请求中发送给所述 CONF AS。
18、 如权利要求 17所述的系统， 其特征在于，
所述 SCC AS, 还用于在向所述 CONF AS发起呼叫请求后， 分别向所 述 CONF AS发起转移请求，分别将各所述会话索引标识包含在所述转移请 求中发送给所述 CONF AS。
19、 一种多方通话业务连续性的实现系统， 其特征在于， 该系统包括： SCC AS和 CONF AS, 其中，
所述 SCC AS , 用于在接收到所述 UE发起的以切换用标识为目标的呼 叫请求后，如果判定所述 UE执行了多方通话业务， 则释放属于多方通话业 务的各个会话， 并将所述各个会话远端用户标识发送给 CONF AS;
所述 CONF AS， 用于分别以所述各会话远端用户标识为目标发送呼叫 请求， 与所述各会话远端用户在分组交换域建立起会议会话。
20、 如权利要求 19所述的系统， 其特征在于， 所述 SCC AS接收的以 切换用标识为目标的呼叫请求中携带有多方通话业务标识，
所述 SCC AS , 还用于根据所述多方通话业务标识判定所述 UE执行了 多方通话业务。
21、 如权利要求 20所述的系统， 其特征在于， 所述 SCC AS用于判定 所述 UE执行了多方通话业务的多方通话业务标识中包括以下指示信息的 一种或其组合：
通过特定的会话发起协议 SIP头域、或 SIP功能标识指示所述 UE执行 了多方通话业务，且所述 UE参与的所有会话或所有激活会话或所有保持会 话属于多方通话业务；
通过 SIP消息体中包含的其他用户的标识信息指示所述 UE执行了多方 通话业务， 且所述 UE参与的与所述其他用户的会话属于多方通话业务。
22、 如权利要求 19所述的系统， 其特征在于，
所述 SCC AS , 还用于根据所述 UE参与了多个激活或多个保持会话， 且所述多个激活会话或多个保持会话属于多方通话业务。
23、 如权利要求 19至 22任一项所述的系统， 其特征在于，
所述 SCC AS, 还用于将所述各远端用户标识包含在向所述 CONF AS 发起的呼叫请求中发送给所述 CONF AS。
24、 如权利要求 23所述的系统， 其特征在于，
所述 SCC AS, 还用于在向所述 CONF AS发起呼叫请求后， 分别向所 述 CONF AS发起转移请求， 即分别将所述各远端用户标识包含在所述转移 请求中发送给所述 CONF AS。
PCT/CN2009/075956 2009-08-04 2009-12-24 一种多方通话业务连续性的实现方法及系统 WO2011015019A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200910161576.5 2009-08-04
CN200910161576.5A CN101990267B (zh) 2009-08-04 2009-08-04 一种多方通话业务连续性的实现方法

Publications (1)

Publication Number Publication Date
WO2011015019A1 true WO2011015019A1 (zh) 2011-02-10

Family

ID=43543880

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/075956 WO2011015019A1 (zh) 2009-08-04 2009-12-24 一种多方通话业务连续性的实现方法及系统

Country Status (2)

Country Link
CN (1) CN101990267B (zh)
WO (1) WO2011015019A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105939351A (zh) * 2011-03-08 2016-09-14 交互数字专利控股公司 用户设备间转移用户的隐私
CN107078917A (zh) * 2014-12-17 2017-08-18 惠普发展公司，有限责任合伙企业 托管电话会议
WO2023016172A1 (zh) * 2021-08-13 2023-02-16 华为技术有限公司 一种呼叫处理方法、装置及系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080037746A1 (en) * 2006-06-29 2008-02-14 Nortel Networks Limited Method and system for automatic call redialing
US7505482B2 (en) * 2004-11-15 2009-03-17 At&T Intellectual Property I, L.P. Application services infrastructure for next generation networks

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101394605B (zh) * 2008-10-30 2012-04-04 华为终端有限公司 一种终端设备间媒体转移方法、装置和网络设备

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7505482B2 (en) * 2004-11-15 2009-03-17 At&T Intellectual Property I, L.P. Application services infrastructure for next generation networks
US20080037746A1 (en) * 2006-06-29 2008-02-14 Nortel Networks Limited Method and system for automatic call redialing

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105939351A (zh) * 2011-03-08 2016-09-14 交互数字专利控股公司 用户设备间转移用户的隐私
CN107078917A (zh) * 2014-12-17 2017-08-18 惠普发展公司，有限责任合伙企业 托管电话会议
CN107078917B (zh) * 2014-12-17 2021-03-19 惠普发展公司，有限责任合伙企业 托管电话会议
US11032709B2 (en) 2014-12-17 2021-06-08 Hewlett-Packard Development Company, L.P. Host a conference call
WO2023016172A1 (zh) * 2021-08-13 2023-02-16 华为技术有限公司 一种呼叫处理方法、装置及系统

Also Published As

Publication number Publication date
CN101990267A (zh) 2011-03-23
CN101990267B (zh) 2013-06-05

Similar Documents

Publication Publication Date Title
EP2202934B1 (en) A multimedia session call control method and the application server thereof
US9026663B2 (en) Method, apparatus and program product for merging communication sessions in an IMS
EP2175605B1 (en) A method for switching the session control path of ip multimedia core network subsystem centralized service
RU2431236C2 (ru) Непрерывность сеанса в сетях связи
US8730917B2 (en) Method and system for realizing single radio voice call continuity
KR101263741B1 (ko) 멀티미디어 세션 전달을 위한 방법, 사용자 디바이스 및 서버
EP2312806B1 (en) A media negotiation method for ip multimedia link
EP2234452B2 (en) Method for implementing centralized service chairman side conference service of ip multimedia subsystem
WO2012024908A1 (zh) 一种终端能力上报的方法及系统
JP5645329B2 (ja) 回線交換ドメインサービスをパケット交換ドメインにハンドオーバする方法及びシステム
EP2117177B1 (en) Method for controlling call, circuit switched domain adapter and terminal device
EP2485530B1 (en) System and method for switching ringing state session with customized alerting tone
EP2421218B1 (en) Session transfer method, apparatus and system thereof
WO2011127790A1 (zh) 一种实现单待业务连续性会话保活的方法和系统
WO2011057568A1 (zh) 一种会话切换的实现方法和系统
WO2011130949A1 (zh) 反向单待业务连续性实现方法及系统
WO2012149866A1 (zh) 单一无线语音呼叫连续性域的切换方法及系统
WO2011015019A1 (zh) 一种多方通话业务连续性的实现方法及系统
WO2011017881A1 (zh) 一种多会话业务连续性的实现方法和系统
WO2013064105A1 (zh) 一种反向单待业务连续性承载切换方法及装置
Kirubakaran et al. An improved SIP protocol in heterogeneous mobile network for efficient communication
WO2011130954A1 (zh) 单待终端业务连续性实现方法和系统
WO2009092245A1 (zh) 多媒体会话连续性业务的起呼方法
WO2011097966A1 (zh) 一种单模业务连续实现方法和系统
CN101771933B (zh) 一种实现多会话业务连续性的方法

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09847997

Country of ref document: EP

Kind code of ref document: A1