Nothing Special   »   [go: up one dir, main page]

GB2443462A - Identifying a session to be transferred between communications domains - Google Patents

Identifying a session to be transferred between communications domains Download PDF

Info

Publication number
GB2443462A
GB2443462A GB0621927A GB0621927A GB2443462A GB 2443462 A GB2443462 A GB 2443462A GB 0621927 A GB0621927 A GB 0621927A GB 0621927 A GB0621927 A GB 0621927A GB 2443462 A GB2443462 A GB 2443462A
Authority
GB
United Kingdom
Prior art keywords
domain transfer
message
session
request indicator
domain
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
GB0621927A
Other versions
GB0621927D0 (en
Inventor
Bo Astroem
Ralf Keller
Kazuhiko Nakada
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Priority to GB0621927A priority Critical patent/GB2443462A/en
Publication of GB0621927D0 publication Critical patent/GB0621927D0/en
Priority to PCT/EP2007/061741 priority patent/WO2008053013A1/en
Publication of GB2443462A publication Critical patent/GB2443462A/en
Withdrawn legal-status Critical Current

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/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H04Q7/3846—
    • H04L29/06027—
    • H04L29/12009—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • 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/1101—Session protocols

Landscapes

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

Abstract

A node in a communications network receives a message relating to a client terminal session, and generates a domain transfer request indicator and a domain transfer telecommunication number to be sent to the client terminal. The invention has particular relevance to moving between an Internet Protocol (IP) Multimedia Subsystem (IMS) network and a Circuit Switched (CS) network using the Voice Call Continuity (VCC) Domain Transfer Uniform Resource Indicator (URI) (VDI) and VCC Domain Transfer Number (VDN) to identify a session to be transferred between the domains. The domain transfer request indicator (e.g. VDI) and domain transfer telecommunication number (e.g. VDN) may be sent in one of a session establishment message, Session Initiation Protocol (SIP) INFO message, a SIP NOTIFY message, or a SIP MESSAGE message.

Description

Moving between Communications Domains
Field of the Invention
The present invention relates to the field of movmg between communications networks, and in particular to moving between an IMS network and a Circuit Switched network.
Background to the Invention
Voice Call Continuity (VCC) is an IP Multimedia Subsystem (IMS) application to transfer voice calls between a Circuit Switched (CS) domain and an [MS domain. VCC is a working item in 3GPP Release 7. VCC application can be implemented in an ISC (IP Multimedia Service Control) connected [MS Application Server and voice calls arc always anchored at the VCC application to provide voice call continuity between the CS domain and the IMS domain. The VCC application server acts as a 3 party call control (3pcc) Back to Back User Agent (B2BUA) and updates the media address of a VCC user access leg towards the remote end when a user moves from a CS domain to an [MS domain or from an IMS domain to a CS domain. Figure 1 illustrates schematically the signalling and media path change example when a VCC user moves from CS domain to IMS domain.
When a VCC Application receives an ThJVITE message from a new IMS domain into which a user has just moved, the VCC Application needs to identify that this is an ThJVITE message requesting Domain Transfer. A VCC Domain Transfer URI (VDI) is populated in a Request-URI in an INVITE message to indicate that Domain Transfer shall be performed. On receipt of an INVITE message with \TDI, the VCC Application Server sends a re-INVITE or UPDATE message towards the remote end to inform that the access leg bearer address has changed.
In 3GPP Release 7 VCC when a user moves from a CS network to an IMS network, it is assumed that only one on-going call exists for a VCC user, and the VCC application can find the corresponding source session anchored in VCC application by VCC user's Public User ID included in the INVITE message from a new IMS domain. It is also assumed that VDI is configured in UE at initial provisioning of VCC service subscription, e.g., using Open Mobile Alliance (OMA) Device Management (DM).
Similarly, as shown in Figure 2, when a VCC user moves from an IMS domain to a CS domain, the user dials a VCC Domain Transfer Number (VDN) in the CS domain to request Domain Transfer (using normal call control procedures). VDN is also configured at initial VCC service subscription. VDN is typically a number common to all VCC subscribers and cannot be used to establish a call to one specific subscriber.
The common number must first be translated into a user specific VDN. The Customised Application for Mobile network Enhanced Logic (CAMEL) mechanism is used for this translation. The user-specific VDN is used as a Public Service Identity (PSI) in a SIP Request-URI, i.e. a DTF PSI (Domain Transfer Function Public Service Identity) in a Media Gateway Control Function (MGCF). The DTF PSI can route the call to VCC Application server, which recognizes that this is a Domain Transfer request (the VCC application has provided the user-specific \TDN that is subsequently used as a DTF PSI).
The Public User ID can be used to identify the single on-going call anchored in the VCC Application Server.
A mechanism is needed in which the UE can use the VDN and VDI to uniquely identify the session which shall be transferred between domains by the ICS-VCC or GSC application server.
Summary of the Invention
According to a first aspect of the present invention, there is provided a method of operating a node in a communications network, the method comprising: receiving a message relating to a client terminal session; generating a domain transfer request indicator and a domain transfer telecommunication number; and sending to the client terminal the generated domain transfer request indicator and domain transfer telecommunication number.
Preferably, the domain transfer request indicator is a Voice Call Continuity Domain Transfer Uniform Resource Indicator, and the domain transfer number is a Voice Call Continuity Domain Transfer Number.
The method may comprise sending the domain transfer request indicator and the domain transfer number in a message selected from one of a session establishment message; a Session Initiation Protocol INFO message; a Session Initiation Protocol NOTIFY message; and a Session initiation Protocol MESSAGE message.
The method may comprise generating the domain transfer request indicator and the domain transfer telecommunication number in response to receipt of a session establishment message. Alternatively, the method may comprise generating the domain transfer request indicator and the domain transfer telecommunication number in response to receipt of a registration message.
According to a second aspect of the invention, there is provided a node in a communications network comprising: means for receiving a message relating to a client terminal registration or session; means for generating a domain transfer request indicator and a domain transfer telecommunication number; and means for sending to the client terminal the generated domain transfer request and domain transfer telecommunication number.
Preferably, the domain transfer request indicator is a Voice Call Continuity Domain Transfer Uniform Resource Indicator, and the domain transfer number is a Voice Call Continuity Domain Transfer Number.
The node may comprise means to send the domain transfer request indicator and the domain transfer number in a message selected from one of a session establishment message; a Session Initiation Protocol INFO message; a Session Initiation Protocol NOTIFY message; and a Session Initiation Protocol MESSAGE message.
The domain transfer request indicator and the domain transfer telecommunication number may be generated in response to receipt of a session establishment message.
Alternatively, the domain transfer request indicator and the domain transfer telecommunication number may be generated in response to receipt of a registration message.
According to a third aspect of the present invention, there is provided a client terminal for use in a telecommunications network, the client terminal comprising: means to receive a domain transfer request indicator and a domain transfer telecommunication number; and means to subsequently use the received domain transfer request indicator and domain transfer telecommunication number to initiate a domain transfer.
Brief Description of the Drawings
Figure 1 illustrates schematically the signalling when a VCC user moves from a CS network to an IMS network.
Figure 2 illustrates schematically the signalling when a VCC user moves from an IMS network to a CS network.
Figure 3 illustrates schematically the signalling when a VCC user moves from one IP-CAN network to another IP-CAN network.
Figure 4 illustrates schematically the signalling when a ICS-VCC user moves from a CS network to an IMS network via an ICS Terminal Adapter.
Figure 5 illustrates schematically the signalling when a ICS-VCC user moves from an IMS network to a CS network via a ICS Terminal Adapter.
Figure 6 illustrates schematically the signalling required to generate and deliver VDIIVDN using a session establishment message method where an IMS session is the source access leg.
Figure 7 illustrates schematically the signalling required to generate and VDI/VDN using an originating session establishment message method where an ICS session is the source access leg.
Figure 8 illustrates schematically the signalling required to generate and deliver VDINDN using a terminating session establishment message method where an ICS session is the source access leg.
Figure 9 illustrates schematically the signalling required to generate and deliver VDIJVDN using a SIP INFO message method where an IMS session is the source access leg.
Figure 10 illustrates schematically the signalling required to generate and deliver \TDI/VDN using a SIP iNFO message method where an ICS session is the source access leg.
Figure 11 illustrates schematically the signalling required to generate and deliver VDI/VDN using a SIP NOTIFY message method where an IMS session is the source access leg.
Figure 12 illustrates schematically the signalling required to generate and deliver VDI/VDN using a SIP NOTIFY message method where an ICS session is the source access leg.
Figure 13 illustrates schematically the signalling required to generate and deliver VDIJ'VDN using a SIP MESSAGE message method where an IMS session is the source access leg.
Figure 14 illustrates schematically the signalling required to generate and deliver VDIJVDN using a SIP MESSAGE message method where an 1CS session is the source access leg.
Figure 15 illustrates schematically the signalling required to generate and deliver VDIJVDN at registration where an IMS session is the source access leg.
Figure 16 illustrates schematically the signalling required to generate and deliver VDIIVDN at registration where an ICS session is the source access leg.
Detailed Description of the Preferred Embodiments
In circumstances where a user moves from one IMS network to another IMS network, Generic Session Continuity (GSC) extends the VCC concept with providing IP Connectivity Access Network (IP-CAN) to IP-CAN continuity. GSC is an application that is typically implemented as an add-on to a VCC application, used to transfer any Communication Service (CoSe) between 2 IP-CANs and is implemented in an ISC connected IMS Application server. A CoSe session is always anchored at the GSC application server which acts as 3pcc B2BUA and updates the media address of a GSC user access leg towards the remote end when a user moves from one IP-CAN to another IP-CAN.
The example illustrated in Figure 3 shows the use of a VDI mechanism in the GSC application. A particular Domain Transfer request is identified by VDI which is transferred in a Request-URI in an INViTE message from the new IP-CAN.
Although VCC R7 assumed only one on-going voice session, GSC extends this assumption to multiple numbers of any CoSe sessions. The GSC application needs the information to identify the corresponding source session to be transferred to a new IP-CAN when it receives an INVITE message with VDI. A GSC user's Public User ID is enough to identify a GSC user, but not enough to identify the concerned session if the GSC user has ongoing multiple sessions. The multiple sessions can be the same CoSe towards multiple remote users or multiple CoSe sessions to the same remote user or those combinations.
IMS Centralized Services (ICS) is a work item in 3GPP Re! 8 that makes it possible to offer IMS services over many types of access networks, such as a CS network. The Service Engine (service implementation) resides in IMS and the CS network is merely used as an access network to the services in IMS. In addition to providing access to the IMS service engine, ICS also extends VCC solution developed in 3GPP Rd 7.
VDIsIVDNs can be used for ICS voice call continuity.
The VDI mechanism described above can be used with ICS (IMS Centralised Service)- compliant networks, as illustrated in Figure 4. In order to support, for example, mid-call signalling, line identification services, and conference services in IMS, ICS introduces an IA (IMS Adapter (which is a CS Terminal Adapter towards IMS)) and the ICS protocol carried over USSD dialogues or any other suitable bearers between a UE and an IA. The IA emulates a Proxy Call Session Control Function (P-CSCF) towards the Serving Call Session Control Function (S-CSCF). A Media Proxy (MP) is also introduced so that IA can manipulate and control the media part on behalf of IJE.
Similar to VCC, ICS-VCC can be implemented as an ISC connected application to transfer the voice session between ICS CS access and PS access, implemented in an IMS Application Server and typically as an extension to a VCC/GSC application. ICS-VCC also acts as 3pcc B2BUA and identifies the session transfer request by VDI in an INVITE message from a new access leg.
A user may move from an ICS domain to an IMS Domain. Where VCC assumes only one voice on-going session, ICS-VCC extends this assumption to multiple numbers of voice sessions and allows multiparty call session continuity. The ICS-VCC application therefore needs additional information to identify the concerned existing session to be transferred to an IMS network when it receives an INVITE message with a VDI. The Public User ID of ICS-VCC user is not sufficient in this case since multiple sessions may be subject to domain transfer.
The same problem occurs for allocation of VDNs (and DTF PSI) in ICS-VCC when multiple calls are transferred from an IMS domain to a CS domain. Note that in ICS-VCC it might not even be possible to use CAMEL to translate a VDN to a DTF PSI; instead the VDN has to be used to route a call to the ICS-VCC application directly, hence is used in the same way as the VDI (see Figure 5). This means that the VDN camiot be conmion to all ICS users as in the VCC VDN scenario described above, where the solution relied on a CAMEL translation of the common VDN into a user-specific VDN. Other means to send a user specific VDN are needed for ICS.
In order to provide a mechanism in which the UE can use the VDN and VDI to uniquely identify the session which is transferred between domains by the ICS-VCC or GSC application server, there is provided a per-session dynamic \TDI / VDN concept.
As compared to the VDIJVDN concept in 3GPP Release 7 VCC, which is configured at initial provisioning, a Dynamic VDIIVDN is generated on a per session basis. Session here means a dialogue as specified in RFC 3261 and is identified by "from" tag, "to" tag and call ID.
Dynamic VDI has the following characteristics: * VDIisaSIPUIRI; * VDI can be recognised as a Domain Transfer request in a GSC or ICS-VCC application; * A Dynamic VDI must identify a particular source session for a user with a Public User ID in GSC or in ICS-VCC Application; * The same Dynamic VDI value may be reallocated afler the concerned session is terminated (i.e. Dynamic VDI has the life time until the session expires).
Dynamic VDN (and DTF PSI) has the following characteristics: * VDN is an E. 164 number that is dialled from UE which must be assigned per user and per source session to be transferred. The VDN is translated by an IA into a DTF PSI. VDN and DTF PSI have a one-to-one relationship in ICS-VCC application server.
* VDN (and corresponding DTF PSI) can be recognised as a Domain Transfer request in the ICS-VCC application; A Dynamic VDN (and corresponding DTF PSI) identifies a particular source session of a user with a particular Public User ID in the ICS-VCC Application.
(Note -DTF PSi was also dynamic to identify the target leg in 3GPP Re17, but the dynamic nature introduced here is to identify the particular source session); * The same Dynamic VDN (and corresponding DTF PSI) value is reallocated after the concerned session is terminated (i.e. Dynamic VDN (and corresponding DTF PSI) has a life time until the session expires).
Dynamic VDIIVDN delivery at session establishment In one embodiment, dynamic VDIIVDN is generated and delivered at session establishment. VDIsIVDIs may be delivered to UE within the established session or outside the session. This method is applicable to the first session after registration as well as subsequent sessions after registration. The VDIJVDN is always generated at each session establishment, and this is also true for the target access leg, i.e. the VDI/VDN generated at source access leg is used for handover from a source access leg to a target access leg but not re-used for subsequent handover from the target access leg to a further new access leg.
There arc several alternative methods for VDI/VDN delivery at session establishment, including the following: * Session establishment message * SIP iNFO message * SIP NOTIFY message (dialogue event package) * SIP MESSAGE message Session establishment message As illustrated in Figure 6, VDI/VDN may be delivered and generated using session establishment signalling. If it is an originating case, a 200 OK message delivers VDI/VDN to User Equipment (UE), and if it is terminating case, ACK delivers VDI/VDN to LIE. The VDI/VDN information can be included in the SIP body of either OK or ACK messages using an XML body, or a new SIP Information Element.
If the source access leg is an ICS leg, then a 200 OK message is mapped to an ICS call initiation result message in the ICS protocol between UE and IA, as shown in Figure 7.
In a terminating case, ACK is mapped to ICS incoming call result, as shown in Figure 8, in IA in order to deliver VDL/VDN.
SIP INFO message VDI/VDN may be generated and delivered using a SIP iNFO message, as illustrated in Figure 9. iNFO is a general mechanism to carry application level information during the session. After a session is established, an Application Server (AS) sends VDI/VDN towards the liE using an INFO message. The VDL'VDN information can be included using an XML body, or a new SIP Information Element.
If source access leg is ICS leg, then INFO is mapped to ICS info in an LA in order to deliver \DINDN, as shown in Figure 10.
SIP NOTIFY message VDI/VDN may be generated and delivered using an event notification mechanism and a SIP NOTIFY message, as illustrated in Figure 11. In this case the UE acts as SUBSCRIBER and the AS acts as NOTIFIER. UE is subscribed to a dialogue event package of its own and receives a notification when the session is established.
VDIIVDN information is included in the NOTIFY message. The VDI/VDN information can be included in SIP using an XML body, or a new SIP Information Element.
If the source access leg is an ICS leg, then the NOTIFY message is mapped to ICS notify in IA in order to deliver VDI/VDN, as illustrated in Figure 12.
SIP MESSAGE message As illustrated in Figure 13, a SIP MESSAGE message may be used by a UE to request VDIs/VDNs, and by the network to deliver VDIsIVDNs to the UE. The SIP MESSAGE transaction is not sent over the established SIP session, and the liE therefore includes information that allows the VCC/GSC/ICS application to assign VDIsIVDNs appropriately. Such information includes the calling party ID, the called party ID, and a "transaction reference" that is used end-to-end between the UE and the VCC/GSC/ICS application (i.e. must not be touched by intermediate nodes). This information and the subsequent delivery of VDIs/VDNs may be sent as an XML body, or a new SIP Infonnation Elements.
This solution also allows the UE to request VDIs/VDNs for all ongoing activities in one SIP message transaction. The UE shall then include several "request components" inside the SIP MESSAGE message; one for each session that is to be transferred.
Likewise, the VCC/GSC/ICS application shall include several "VDIIVDN components" in the reply back to the UE.
When the source access leg is from an ICS domain, the SIP MESSAGE message procedure must be mapped onto an ICS procedure, as shown in Figure 14.
Dynamic VDI/VDN delivery at reisfration In an alternative embodiment, VDL/VDN is generated and delivered to UE at registration. The VDIIVDN is reserved for the coming initial session. This method is only applicable to identify the initial session after registration.
A third party registration mechanism is used to inform the AS that registration takes place. A SIP MESSAGE message is used to deliver VDLIVDN towards UE, as illustrated in Figure 15. The VDI/VDN information can be included in a SIP message body using XML or new SIP Information Elements.
If the source access leg is an ICS leg, then a MESSAGE message is mapped to ICS VDINDN delivery in the IA in order to deliver VDIIVDN, as illustrated in Figure 16.
The dynamic VDN/VDI delivery at registration can be combined with the delivery at session establishment as follows: The UE receives a first VDIIVDN during registration. These are valid for the first session that is established by the LIE.
The UE receives a new pair of VDI/VDN at subsequent session establishment. Unless otherwise indicated, the new pair is to be used for the next session (hence the UE keeps a record of at least two pairs).
Note: In case or registration, dc-registration and / or switching off/on IJE, the tiE deletes any previously stored VDI/VDNs.
The invention described herein provides for identification of simultaneous sessions for the same user (Public User Identity), and allows domain transfer to be carried out for all ongoing activities. It also provides dynamic allocation of user-specific VDI/VDN, per session allocation of user-specific VDJIVDN, and subsequent per session allocation of user-specific VDIIVDN

Claims (11)

  1. CLAIMS: 1. A method of operating a node in a communications network,
    the method comprising: receiving a message relating to a client terminal session; generating a domain transfer request indicator and a domain transfer telecommunication number; and sending to the client terminal the generated domain transfer request indicator and domain transfer telecommunication number.
  2. 2. A method of operating a node as claimed in claim 1, wherein the domain transfer request indicator is a Voice Call Continuity Domain Transfer Uniform resource Indicator, and the domain transfer number is a Voice Call Continuity Domain Transfer Number.
  3. 3. A method of operating a node as claimed in claim 1 or 2, comprising sending the domain transfer request indicator and the domain transfer number in a message selected from one of a session establishment message; a Session Initiation Protocol iNFO message; a Session Initiation Protocol NOTIFY message; and a Session Initiation Protocol MESSAGE message.
  4. 4. A method of operating a node as claimed in claim 1, 2 or 3, comprising generating the domain transfer request indicator and the domain transfer telecommunication number in response to receipt of a session establishment message.
  5. 5. A method of operating a node as claimed in claim 1, 2 or 3, comprising generating the domain transfer request indicator and the domain transfer telecommunication number in response to receipt of a registration message.
  6. 6. A node in a communications network comprising: means for receiving a message relating to a client terminal registration or session; means for generating a domain transfer request indicator and a domain transfer telecommunication number; and means for sending to the client terminal the generated domain transfer request indicator and domain transfer telecommunication number.
  7. 7. A node as claimed in claim 6, wherein the domain transfer request indicator is a Voice Call Continuity Domain Transfer Uniform resource Indicator, and the domain transfer number is a Voice Call Continuity Domain Transfer Number.
  8. 8. A node as claimed in claim 6 or 7, comprising means to send the domain transfer request indicator and the domain transfer number in a message selected from one of a session establishment message; a Session Initiation Protocol INFO message; a Session Initiation Protocol NOTIFY message; and a Session Initiation Protocol MESSAGE message.
  9. 9. A method of operating a node as claimed in claim 6, 7 or 8, comprising means to generate the domain transfer request indicator and the domain transfer telecommunication number in response to receipt of a session establishment message.
  10. 10. A method of operating a node as claimed in claim 1, 2 or 3, comprising means to generate the domain transfer request indicator and the domain transfer telecommunication number in response to receipt of a registration message.
  11. 11. A client terminal for use in a telecommunications network, the client terminal comprising: means to receive a domain transfer request indicator and a domain transfer telecommunication number; and means to subsequently use the received domain transfer request indicator and domain transfer telecommunication number to initiate a domain transfer.
GB0621927A 2006-11-03 2006-11-03 Identifying a session to be transferred between communications domains Withdrawn GB2443462A (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
GB0621927A GB2443462A (en) 2006-11-03 2006-11-03 Identifying a session to be transferred between communications domains
PCT/EP2007/061741 WO2008053013A1 (en) 2006-11-03 2007-10-31 Moving between communications domains

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB0621927A GB2443462A (en) 2006-11-03 2006-11-03 Identifying a session to be transferred between communications domains

Publications (2)

Publication Number Publication Date
GB0621927D0 GB0621927D0 (en) 2006-12-13
GB2443462A true GB2443462A (en) 2008-05-07

Family

ID=37547280

Family Applications (1)

Application Number Title Priority Date Filing Date
GB0621927A Withdrawn GB2443462A (en) 2006-11-03 2006-11-03 Identifying a session to be transferred between communications domains

Country Status (2)

Country Link
GB (1) GB2443462A (en)
WO (1) WO2008053013A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100034199A1 (en) * 2006-02-06 2010-02-11 Jae-Seung Song Method for requesting domain transfer and terminal and server thereof
RU2536802C2 (en) * 2008-06-19 2014-12-27 Квэлкомм Инкорпорейтед Transmitting session continuity information in multicomponent communication session

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003001836A1 (en) * 2001-06-20 2003-01-03 Nokia Corporation System, device and method for providing call forwarding in dual subscription mode
WO2005025196A1 (en) * 2003-09-11 2005-03-17 Nokia Corporation Ip-based services for circuit-switched networks
WO2005086458A1 (en) * 2004-03-09 2005-09-15 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for web service handling
US20050243870A1 (en) * 2004-04-14 2005-11-03 Balogh Dan A Method of transferring call transition messages between network controllers of different radio technologies

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003001836A1 (en) * 2001-06-20 2003-01-03 Nokia Corporation System, device and method for providing call forwarding in dual subscription mode
WO2005025196A1 (en) * 2003-09-11 2005-03-17 Nokia Corporation Ip-based services for circuit-switched networks
WO2005086458A1 (en) * 2004-03-09 2005-09-15 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for web service handling
US20050243870A1 (en) * 2004-04-14 2005-11-03 Balogh Dan A Method of transferring call transition messages between network controllers of different radio technologies

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100034199A1 (en) * 2006-02-06 2010-02-11 Jae-Seung Song Method for requesting domain transfer and terminal and server thereof
US8369336B2 (en) * 2006-02-06 2013-02-05 Lg Electronics Inc. Method for requesting domain transfer and terminal and server thereof
US8670413B2 (en) 2006-02-06 2014-03-11 Lg Electronics Inc. Method for requesting domain transfer and terminal and server thereof
RU2536802C2 (en) * 2008-06-19 2014-12-27 Квэлкомм Инкорпорейтед Transmitting session continuity information in multicomponent communication session

Also Published As

Publication number Publication date
WO2008053013A1 (en) 2008-05-08
GB0621927D0 (en) 2006-12-13

Similar Documents

Publication Publication Date Title
US8359015B2 (en) Method of providing a call completion service to a not registered or not available user in a telecommunication network
US9379914B2 (en) Method and system for implementing aggregate endpoints on IMS networks
US10044553B2 (en) Media resource reservation request failure handling for voice over mobile wireless network
KR101078676B1 (en) Call transfer method, system and device
CA2605098C (en) System and method for managing call continuity in ims network environment using sip messaging
US20060018272A1 (en) Instance identification
US20120243481A1 (en) Providing Packet-Based Multimedia Services Via a Circuit Bearer
US8825875B2 (en) Session establishment in a communication network
GB2398458A (en) Converstional bearer negotiation
WO2006111845A2 (en) Session initiation from application servers in an ip multimedia subsystem
US9021300B2 (en) Method of changing over from a primary HSS to a backup HSS in an IP network
WO2012076065A1 (en) Traffic routing across and between networks
EP2119178B1 (en) Method and apparatuses for the provision of network services offered through a set of servers in an ims network
EP2795865B1 (en) Session establishment in an ip multimedia subsystem network
EP2716001B1 (en) Routing of calls in ip multimedia subsystem centralized services networks
EP2446603A1 (en) A method of providing a call completion service to a not registered or not available user in a telecommunication network
KR100703426B1 (en) Method and apparatus for sending and receiving call unregistered user in a ip multimedia subsystem network
GB2443462A (en) Identifying a session to be transferred between communications domains
EP2040508A1 (en) Method, apparatuses and program product for controlling IMS services when user is roaming in CS domain
CN101330638B (en) Method for associating session control path and bearer control path
KR20100003869A (en) A device for routing sip message and routing method
KR101360151B1 (en) Method of sip message transmission between gruu users in ims network, and device of the same
KR101117440B1 (en) A Device And Method For Providing Free Number Service in the IP Multimedia Subsystem
KR101136653B1 (en) Apparatus and method for providing multimedia contents to terminals on early session
JP2017216584A (en) Inter-network control method for matching non-use of optional function of request destination terminal, sip server and program

Legal Events

Date Code Title Description
WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)