CN104936262B

CN104936262B - Method and device for sending and receiving far-end identification and transmission system

Info

Publication number: CN104936262B
Application number: CN201410109717.XA
Authority: CN
Inventors: 邹常乐; 李振东; 游世林; 刘竞翔
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2014-03-21
Filing date: 2014-03-21
Publication date: 2020-02-28
Anticipated expiration: 2034-03-21
Also published as: CN104936262A; WO2015139414A1

Abstract

The invention provides a method and a device for sending and receiving a far-end identifier and a transmission system, wherein the sending method comprises the following steps: the technical scheme provided by the invention solves the technical problems that in the prior art, when the signaling path between the IMS client and the IMS agent is different from the existing session path, the IMS agent cannot identify the session of the service to be executed and the like, thereby avoiding the failure of service request caused by the loss of the remote user identifier and the failure of the local session identifier identified by the IMS agent.

Description

Method and device for sending and receiving far-end identification and transmission system

Technical Field

The present invention relates to the field of communications, and in particular, to a method and an apparatus for transmitting and receiving a remote identifier, and a transmission system.

Background

In 2Generation (2G) and 3G (3G) Mobile communication networks, such as Global System for Mobile communications (GSM), Universal Mobile Telecommunications System (UMTS), voice services are provided in a Circuit Switch (CS) manner, and good coverage is formed. With the development of wireless broadband technology and the development of Internet Protocol (IP) technology, the whole network evolves towards the direction of full IP, on one hand, the core network of the communication network evolves towards an IP Multimedia Subsystem (IMS), on the other hand, the wireless access network evolves towards Packet switching, and carries voice and other services through a Packet Switch (PS) network, and can directly access the IMS, and the IMS provides communication services including voice services.

IMS is an IP-based network architecture proposed by the third Generation Partnership Project (3 rd Generation Partnership Project, 3 GPP), and constructs an open and flexible service environment, which is independent of access, can support multimedia applications, and can provide rich multimedia services to users. Because of the characteristics of the IMS and the independence of access, the method can uniformly control the services performed by different access networks, for the CS network, an IMS Centralized Service (ICS) technology can be used, when a user uses a terminal to access a Mobile Switching Center (MSC) from a traditional CS network, the MSC initiates registration to the IMS network of a home domain, and an IMS signaling path is directly established, thereby realizing the purpose of uniformly controlling the CS Service by the IMS.

There are many development directions of wireless access modes, for example, 3GPP proposes a next generation network Architecture of long term Evolution/System Architecture Evolution (LTE/SAE for short), and adopts a packet switching technology, which can provide a higher transmission rate and a shorter transmission delay, can carry real-time services including voice services, and can be used as an access mode of an IMS network, and the IMS provides services. Each network element in the IMS network communicates using a Session Initiation Protocol (SIP for short); the Session Description Protocol (SDP for short) is used to describe media information, including an IP address, a media stream codec format, a port number, and the like of a transmission media.

In these access modes, some access technology deployments are a gradual process, for example, an operator may only perform coverage in a hot spot area in the early stage during the LTE/SAE deployment process. When the user carries out voice service in the LTE/SAE coverage area, the user directly accesses the IMS and establishes an IMS session with a remote user. When the user moves out of the coverage area, in order to ensure the continuity of the voice service, the CS network is switched to, and the continuity of the conversation with the remote user is kept by utilizing the session anchoring function in the IMS, so that the advantage of good coverage of the CS network can be fully utilized, and the continuity of the service is ensured.

In the above scenario, the mobile device of the user can only access one wireless network in the call state, for example, for the LTE/SAE user equipment, before the handover, only the LTE/SAE network can be accessed, but not the CS network can be accessed at the same time; when moving to the coverage area of the CS network, the wireless connection with LTE/SAE must be disconnected to access the CS network, and the access mode is referred to as single wireless access mode switching or single mode switching.

Fig. 1 shows a service scenario of voice handover (also called voice continuity) in the above scenario. When a User Equipment (User Equipment, abbreviated as UE) 101 performs a voice service in a source radio Access coverage area (e.g. LTE/SAE), it directly accesses to an IMS106 through an Access Transfer Control Function (ATCF) 104, and establishes an IMS session with a Remote User Equipment (Remote UE) 107. When the user moves out of the coverage area, in order to ensure the continuity of the voice service, the CS network is switched to, and the continuity of the conversation with the remote user is kept by utilizing the session anchoring function, so that the advantage of good coverage of the CS network can be fully utilized, and the continuity of the service is ensured. Wherein, a Mobile Switching center Server (MSC Server) 102 includes functions of a Media Gateway 103 (divided into a Media Gateway Control Function (MGCF) of a Control part and a Media Gateway (MGW) of a Media processing part) of the IMS network, and is described as an entity. For simplicity of illustration and description, a Serving-CSCF (S-CSCF) and a Service Consistency and Continuity Application Server (SCCAS) are used as one entity, and Session Initiation Protocol (SIP) is used for communication between the Serving-CSCF and the SCCAS. The ATCF serves as a signaling anchor point during handover, and controls a media Access Gateway (AGW) 105 to anchor media of a session during handover, so as to reduce voice interruption during handover. The ATCF controls the AGW (such as H.248) through a media control protocol, and the two are combined into one entity description.

The IMS in fig. 1 is located in a home network of a user, and includes network elements such AS a Call session control Function (Call session control Function, abbreviated AS CSCF) and various Application servers (Application servers, abbreviated AS ASs), for example, an SCC AS that provides service consistency and continuity;

a Remote End (Remote End) 107, which establishes an IMS session with a UE, and may be the UE, or may be a server providing services, such as a streaming server;

before a single radio channel handover occurs in fig. 1, UE-a establishes an IMS session with the remote UE-B in the source access network LTE/SAE.

Wherein the signaling path includes:

UE-A to ATCF, ATCF to IMS, called access branch signaling path (before handover);

IMS to remote UE, called remote branch signaling path;

the media path includes:

UE-A to AGW, called access branch media path;

AGW to remote UE, called remote branch media path;

when the UE-A is switched to the CS network, the signaling media path is changed:

the signaling path includes:

UE-A to MSC Server, MSC Server to ATCF, ATCF to IMS, called access branch signaling path (after switching);

the far-end branch signaling path is unchanged;

the media path includes:

UE-A to MGW, MGW to AGW, called access branch media path (after switching);

the far-end branch media path is unchanged.

The signaling is anchored at ATCF before and after switching, and the media is anchored at AGW, so that voice interruption is reduced as much as possible in the switching process, and better user experience is ensured. After switching, MSC executes IMS registration according to UE-A subscription information. The MSC queries a Call session control Function (I-CSCF) addressed to an IMS access point of the UE-a home network according to the domain name analysis, and performs IMS registration with an IMS network element such as an S-CSCF, and details thereof are not described. The registration path does not pass through the ATCF, so the signaling path of the session established after the first handed-over session does not pass through the ATCF, unlike the first one.

Fig. 2 shows a flow of implementing the existing single-mode voice session service continuity. As shown in fig. 2, UE-a establishes a voice session between an IMS domain and a remote UE-B, and when UE-a decides that a session needs to be switched from the IMS domain to a CS domain, UE-a and a network implement the single-mode service continuity process, which is described in detail as follows:

step 201, UE-A establishes a voice session with remote UE in PS network (LTE/SAE), the session is anchored on ATCF/AGW of visited network, wherein ATCF is responsible for signaling part, AGW is responsible for media part; the session is processed by SCC AS of the UE-A home domain, and a remote branch is established with the remote UE; the method comprises the following steps that the network signal intensity changes due to the fact that UE-A moves in position and the like, the UE-A interacts with a PS network, and the PS network determines to initiate a single-mode voice session service continuity process;

the dialogue identifier between the UE-A and the ATCF is D101, the dialogue identifier between the ATCF and the SCC AS is D102, and the dialogue identifier between the SCCAS and the remote UE-B is D103; wherein, ATCF can be associated with D101-D102, SCC AS can be associated with D102-D103, D101 is invisible to SCC AS, D103 is invisible to ATCF or MSC, D101 and D102 are invisible to far-end UE-B.

Step 202, the PS network instructs the MSC Server to perform switching preparation; after the MSCServer finishes the switching preparation, replying a response to the PS network;

step 203a, after step 202, the PS network instructs the UE-A to access the CS network, the UE-A establishes a signaling access branch with the MSC Server, and establishes a media access branch with the MGW;

step 203, step 202, the MSC Server receives the switching instruction of the PS network, initiates an IMS session switching procedure, and initiates a switching message to the ATCF;

step 203 and step 203a may be performed in parallel;

step 204, ATCF replies switching response to MSC Server;

until the step, MSC Server and ATCF set up new access branch (signaling branch) after switching, and MGW and AGW set up new access branch (media branch) at the same time;

step 205, the ATCF sends a switching notification message to the SCC AS;

when the SDP information in the notification message is consistent with the SDP information in the previous session establishment, the IMS remote updating process is not needed; otherwise IMS remote update needs to be performed.

Steps 204 and 205 may be performed concurrently;

step 206, the SCC AS replies a notification response to the ATCF, and the ATCF and the SCC AS establish a switched access branch (signaling);

after the switching, a dialog D201 is generated between the MSC and the ATCF to replace the original D101; and a dialog D202 is generated between the ATCF and the SCC AS instead of the original D102. Wherein, ATCF can be associated with D201-D202, SCC AS can be associated with D202-D103, D201 is invisible to SCC AS, D103 is invisible to ATCF or MSC, D201 and D202 are invisible to far-end UE-B.

Step 207, after the handover is completed, the MSC replaces the UE to perform IMS registration, and the registration path does not pass through the ATCF;

after the above process, a special scenario appears, that is, the signaling path after registration through IMS on the MSC is different from the existing first session, and an IMS full proxy (ATCF) exists in the first session path.

Step 208, MSC initiates a new session establishment request to SCC AS, and establishes a session with third party UE-C;

step 208a, SCC AS establishes a session with UE-C;

step 209, SCC AS replies to MSC with establishment response;

at this time, the dialogue between the MSC and the SCC AS is D301, and the dialogue between the SCC AS and the UE-C is D302;

the session is established after step 207 so the signaling path does not pass through the ATCF. This process involves a number of different situations, such as:

after the first session handover is completed, the SCC AS further has a session with the UE-C in the source side network, so AS to notify the handover of the second session, in which case the SCC AS instructs the MSC to initiate the handover of the second session before step 208;

or the UE is switched to the CS domain, and the UE establishes a session with the UE-C, and the like;

the session establishment request is only an example, and is an origination procedure, or may be a termination procedure when the UE-C initiates a session establishment procedure towards the UE-a.

In step 210, the MSC initiates a new service request, such as Conference (Conference, abbreviated as CONF) or Call Transfer (Explicit Call Transfer, abbreviated as ECT), through a signaling path.

Taking the example of the CONF service:

the MSC establishes a session with the CONF AS and instructs the CONF to join UE-B, UE-C, respectively, to the conference. The MSC indicates that the method of joining UE-B is to send a REFER message to the CONF AS.

Under normal conditions, the REFER message needs to carry parameters as follows:

request URI (destination address of request): CONF AS URI

refer-to：UE-B URI+D201

The semantics of the REFER message are as follows: the request URI is a target party of the REFER message, after the target party receives the REFER message, the target party sends the INVITE message to the URI according to the information carried in the REFER-to, namely the URI and the conversation identifier, carries the place parameter and sets the conversation identifier, so that a user end receiving the INVITE can understand that the purpose of the INVITE message is to establish a new session and replace the conversation indicated in the place.

The message passes through the SCC AS to the CONF AS. After receiving the request, the CONF AS sends an INVITE message to the UE-B URI, and the INVITE message carries a place parameter with a session identifier needing to be replaced by the UE-B.

Since the UE-B URI cannot inform the MSC after the first session handover, the MSC cannot fill in the UE-B URI in the refer-to, but only in D201.

If no ATCF exists, that is, the MSC and the SCC AS are directly connected through the D201, the SCC AS can associate the D103 through the D201, correctly discover the UE-B, and inform the CONF AS of the UE-B URI and the D103 (replacing the local session D201 with the remote session D103 and also the operation that the B2BUA needs to execute), so that the CONF AS determines that the request target address in the INVITE message is the UE-B URI, and the session identifier that needs to be replaced is the D103, normally completes the session establishment between the CONF AS and the UE-B after being sent to the UE-B through the INVITE message, and replaces the existing session D103.

When the ATCF exists, the following problems arise:

since SCC AS cannot locate the relevant dialog through the remote user identity (UE-B URI missing), and IMS full-proxy ATCF exists, D201 is invisible to SCC AS, SCC AS cannot correctly locate the remote dialog through dialog identity D201 (there are D103 and D302), so SCC AS/CONF AS cannot determine the subsequently initiated INVITE target (UE-B) and the dialog that needs to be replaced (D103), resulting in failure to complete the requested service.

The ECT service is similar to the problem generated by the CONF service, and is not described in detail herein.

Summarizing, the session signaling path between the IMS client (MSC in this example) and the IMS proxy (SCC AS in this example) is different from the existing session (MSC-UE-B), resulting in that the IMS proxy (SCC AS) cannot recognize the dialog identifier (D201) local to the IMS client, thereby causing service failure.

The special scenario described above, that is, the signaling path after registration through IMS on the MSC is different from the already existing first session, and an IMS full proxy (ATCF) exists in the first session path, which is a typical scenario causing this problem. Similar problems may occur in all scenarios that conform to the above-described problem, and are not described in detail herein.

Disclosure of Invention

The invention provides a sending and receiving method and a device of a remote identifier and a transmission system, aiming at the technical problems that in the related art, when a signaling path between an IMS client and an IMS proxy is different from an existing session path, the IMS proxy cannot identify a session needing to execute a service, and the like.

In order to achieve the above object, according to an aspect of the present invention, there is provided a method for transmitting a remote identity, including: the method comprises the steps that an IP Multimedia Subsystem (IMS) agent sends a remote identification to an IMS client, wherein the IMS client has no remote identification.

Preferably, the IMS proxy sends the remote identity to the IMS client, including one of: the IMS proxy modifies the existing message sent to the IMS client, wherein the modified existing message carries the remote end identifier; sending the modified existing message; the IMS agent adds a designated message sent to the IMS client, wherein the designated message carries the remote end identifier; and sending the specified message.

Preferably, the sending the modified existing message includes: the IMS proxy receives a switching message from a network to which the IMS client belongs; and the IMS agent sends a response message of the switching message to the IMS client, wherein the response message carries the far-end identification.

Preferably, the IMS proxy comprises: a first IMS proxy and a second IMS proxy, wherein the first IMS proxy is configured to associate a session between a user equipment and the first IMS proxy and a session between the first proxy IMS and the second IMS proxy; the second IMS proxy is configured to associate a session between a remote end of the user equipment and the second IMS proxy, and a session between the first proxy IMS and the second IMS proxy.

Preferably, the sending the modified existing message includes: a handover notification message sent by the first IMS proxy to the second IMS proxy, wherein the handover notification message is used to notify the second IMS proxy to perform network handover; the first IMS agent receives a response message of the switching notification message from a second IMS agent, wherein the response message carries the far-end identification; the first IMS proxy sends the response message.

Preferably, the sending the specific message includes: the first IMS agent receives the far-end identification actively issued by the second IMS agent; and the first IMS agent sends the specified message to the IMS client, wherein the specified message carries the remote end identification.

Preferably, the sending the modified existing message includes: the IMS agent receives an IMS registration request initiated by the IMS client instead of user equipment; and the IMS agent sends a response message of the registration request to the IMS client, wherein the response message carries the remote end identification.

Preferably, the sending the specific message includes: and the IMS agent sends a notification message to the IMS client, wherein the notification message carries the remote end identifier.

Preferably, the sending the specific message includes: the IMS proxy receives a query message from the IMS client; and the IMS agent replies a response message of the query message to the IMS client, wherein the response message carries the remote identification.

Preferably, the IMS proxy comprises at least one of: an access switching control function (ATCF) entity, a service consistency and continuity application server (SCC AS) and a Call Session Control Function (CSCF) entity; and/or, the IMS client includes one of: a mobile switching center MSC and user equipment UE.

Preferably, the IMS client includes: and when the access network to which the user equipment belongs is changed, the user equipment is to be accessed to a target client in the target access network.

Preferably, the method further comprises: determining that a session signaling path between the IMS client and the IMS proxy is different from an existing session, and that the IMS proxy is unable to recognize a local dialog identification of the IMS client.

In order to achieve the above object, according to still another aspect of the present invention, there is provided a remote identity receiving method, including: the method comprises the steps that an IP Multimedia Subsystem (IMS) client receives a remote identification from an IMS proxy, wherein the IMS client has no remote identification.

In order to achieve the above object, according to still another aspect of the present invention, there is provided a remote identity sending apparatus for use in an IP multimedia subsystem IMS proxy, the apparatus including: and the sending module is used for sending the remote identification to the IMS client, wherein the IMS client has no remote identification.

In order to achieve the above object, according to yet another aspect of the present invention, there is provided a remote identity receiving apparatus for an IP multimedia subsystem IMS client, the apparatus including: and the receiving module is used for receiving the remote identification from the IMS proxy by the IMS client, wherein the IMS client has no remote identification.

In order to achieve the above object, according to yet another aspect of the present invention, there is provided a remote identity transmission system, including an IP multimedia subsystem IMS proxy and an IMS client, the system further including: a sending module, located in the IMS proxy, configured to send the remote identifier to the IMS client, where the IMS client does not have a remote identifier; and the receiving module is positioned in the IMS client and used for receiving the remote identification from the IMS proxy.

By adopting the technical means that the IMS agent informs the IMS client of the remote end identifier, the invention solves the technical problems that the IMS agent cannot identify the dialogue which needs to execute the service and the like when the signaling path between the IMS client and the IMS agent is different from the existing session path in the related technology, thereby avoiding the failure of service request caused by the absence of the remote end user identifier and the failure of the local dialogue identifier identified by the IMS agent.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the invention without limiting the invention. In the drawings:

FIG. 1 is a diagram illustrating an exemplary scenario architecture of a voice handover process according to the related art;

fig. 2 is a signaling flow diagram of a single channel session handover according to the related art;

fig. 3 is a flowchart of a method for transmitting a remote identity according to an embodiment of the present invention;

fig. 4 is a flowchart of a remote identifier receiving method according to an embodiment of the present invention;

fig. 5 is a block diagram of a remote identity transmitting device according to an embodiment of the present invention;

fig. 6 is a block diagram of a remote identity receiving apparatus according to an embodiment of the present invention;

fig. 7 is a block diagram of a remote identity transmission system according to an embodiment of the present invention;

fig. 8 is a flowchart illustrating a transmission method of a remote identifier according to a preferred embodiment 1 of the present invention;

fig. 9 is a flowchart illustrating a transmission method of a remote identifier according to a preferred embodiment 2 of the present invention;

fig. 10 is a flowchart illustrating a transmission method of a remote identifier according to a preferred embodiment 3 of the present invention;

fig. 11 is a flowchart illustrating a transmission method of a remote identifier according to a preferred embodiment 4 of the present invention.

Detailed Description

The invention will be described in detail hereinafter with reference to the accompanying drawings in conjunction with embodiments. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.

Fig. 3 is a flowchart of a method for transmitting a remote identity according to an embodiment of the present invention. As shown in fig. 3, the method includes:

step S302, the IMS agent obtains a far-end identifier;

in step S304, the IP multimedia subsystem IMS proxy sends a remote identity (i.e. a remote user equipment identity) to the IMS client.

Through the processing steps, the IMS proxy can inform the IMS client of the remote identifier, so that the problem caused by the fact that the IMS client cannot acquire the remote identifier can be solved, and particularly the problem that a subsequent service request cannot be executed when a signaling path between the IMS client and the IMS proxy is different from an existing session path and the IMS proxy cannot identify a session needing to execute the service can be solved.

It should be noted that step S302 may be used as an optional step in the implementation process, that is, the processing step may not be executed first.

The application scenario in this embodiment may be, but is not limited to, the following scenario: and determining that a session signaling path between the IMS client and the IMS proxy is different from an existing session, and the IMS proxy cannot identify the local session identifier of the IMS client, so that the user can implement the execution of the subsequent service in the scene based on the steps.

In this embodiment, the IMS client includes, but is not limited to: and when the access network to which the user equipment belongs is changed, the user equipment is to be accessed to a target client in the target access network.

In this embodiment, the remote identity may be used for the IMS client to perform a subsequent service request, but is not limited thereto.

In step S302, there are various ways to obtain the remote identifier, for example, obtaining the remote identifier from a third-party device (including but not limited to receiving the remote identifier from the third-party device and then storing the remote identifier), and may also be set locally, but not limited to this.

In step S304, the remote identifier may be sent by using an existing message, or may be sent by using a message dedicated to sending the remote identifier, specifically, for the first sending method: the IMS agent modifies the existing message sent to the IMS client, wherein the modified existing message carries the remote end identifier; sending the modified existing message; for the second transmission mode: the IMS agent adds a designated message sent to the IMS client, wherein the designated message carries the remote end identifier; and sending the specified message.

In a preferred implementation manner of this embodiment, the first sending method can be implemented in the following ways:

(1) the IMS agent receives a switching message from a network to which an IMS client belongs; the IMS agent sends a response message of the switching message to the IMS client, wherein the response message carries the remote end identifier;

(2) the IMS agent receives an IMS registration request initiated by the IMS client instead of the user equipment; the IMS agent sends a response message of the registration request to the IMS client, wherein the response message carries the remote identification;

(3) when the IMS agent comprises a first IMS agent and a second IMS agent, the first IMS agent sends a switching notification message to the second IMS agent, wherein the switching notification message is used for notifying the second IMS agent of network switching; the first IMS proxy receives a response message of the handover notification message from the second IMS proxy, where the response message carries the remote identifier; and the first IMS proxy sends the response message.

Wherein the first IMS proxy is configured to associate a session between the user equipment and the first IMS proxy and a session between the first proxy IMS and the second IMS proxy; the second IMS proxy is configured to associate a session between the remote end of the ue and the second IMS proxy, and a session between the first proxy IMS and the second IMS proxy.

For the second transmission mode, the following modes can be implemented:

(1) and the IMS agent sends a notification message to the IMS client, wherein the notification message carries the remote identification.

(2) The IMS agent receives a query message from an IMS client; and the IMS agent replies a response message of the query message to the IMS client, wherein the response message carries the remote identification.

(3) When the IMS proxy includes the first IMS proxy and the second IMS proxy, the following steps may be further performed: the first IMS agent receives the remote identification actively issued by the second IMS agent; and the first IMS agent sends the specified message to the IMS client, wherein the specified message carries the remote end identifier.

In this embodiment, the IMS proxy includes at least one of: ATCF entity, SCC AS, CSCF entity; and/or, the IMS client comprises one of: MSC and UE.

In this embodiment, a method for receiving a remote identifier is further provided, as shown in fig. 4, where the method includes:

step S402, the IMS client receives a far-end identification from the IMS agent, wherein the IMS client is a target client to be accessed into a target access network when the access network to which the user equipment belongs is changed, and the far-end identification is an opposite-end identification of the user equipment.

Step S404, the IMS client executes the subsequent service request according to the remote identifier.

Step S404 may be an optional step according to a specific application scenario. Moreover, the preferred implementation in the embodiment shown in fig. 4 corresponds to the implementation in the embodiment shown in fig. 3, and is not described here again.

In this embodiment, there is also provided an apparatus for sending a remote identifier, where the apparatus is located in an IMS proxy, and as shown in fig. 5, the apparatus includes: a sending module 50, configured to send the remote identity to an IMS client, where the IMS client has no remote identity.

In this embodiment, there is also provided a device for receiving a remote identifier, where the device is located in an IMS client, and as shown in fig. 6, the device includes: a sending module 60, configured to send a remote identity to the IMS client, where the IMS client has no remote identity.

In this embodiment, a system for transmitting a remote identity is further provided, as shown in fig. 7, the system includes an IMS proxy 70 and an IMS client 72, where the IMS client 72 may include but is not limited to: when the access network to which the user equipment belongs is changed, a target client in a target access network is to be accessed; a sending module 50, located in the IMS proxy 70, configured to send the remote identifier to the IMS client 72, where the remote identifier is an opposite identifier of the user equipment; the receiving module 60 is located in the IMS client 72, and is configured to receive the remote identity from the IMS proxy.

For a better understanding of the above embodiments, reference is made to the following detailed description of the preferred embodiments.

The following preferred embodiments are illustrated with the following scenarios as examples: when a session signaling path between the IMS client and the IMS proxy is different from an existing session, the IMS proxy cannot identify a local session identifier of the IMS client, so that service failure is caused;

taking an enhanced single-channel voice service handover scenario (a typical scenario of the present problem) AS an example, a signaling path after registration through an IMS on an MSC after handover is different from an existing first session, an IMS full proxy (ATCF) exists in a first session path, when a CONF or ECT service is initiated, since an SCC AS cannot locate a relevant dialog through a remote user Identifier (remote Resource Identifier (URI)) neither is missing, nor exists an IMS full proxy ATCF, D201 is invisible to the SCC AS nor can a remote dialog be correctly located through a dialog Identifier D201 (there are D103 and D302), and the SCC AS/CONF AS cannot complete the requested service.

The main design idea of the following preferred embodiment is that the IMS full proxy informs the IMS client of the remote URI, and the IMS client carries the remote URI in the subsequent service request, and even if the local session identifier is not identified by the IMS proxy, the remote URI can correctly associate the session requiring the service execution, so as to correctly perform the requested service.

Example one

As shown in fig. 8, UE-a establishes a voice session between the IMS domain and remote UE-B, and when UE-a decides that the session needs to be switched from the IMS domain to the CS domain, UE-a and the network implement the single-mode service continuity procedure, and in this procedure, the URI of remote UE-B is brought to the MSC. The method comprises the following specific steps:

step S802, UE-A establishes a voice conversation with remote UE in PS network (LTE/SAE), the conversation is anchored on ATCF/AGW of visit area network, wherein ATCF is responsible for signaling part, AGW is responsible for media part; the session is processed by SCC AS of the UE-A home domain, and a remote branch is established with the remote UE; the method comprises the following steps that the network signal intensity changes due to the fact that UE-A moves in position and the like, the UE-A interacts with a PS network, and the PS network determines to initiate a single-mode voice session service continuity process;

Step S804, PS network instructs MSC Server to prepare for switching; after the MSC Server completes the switching preparation, the MSC Server replies a response to the PS network;

step S806a, step S804 are finished, PS network instructs UE-A to access CS network, UE-A and MSC Server set up signaling access branch, and media access branch with MGW;

step 806, step 804, the MSC Server receives the switching instruction of the PS network, initiates an IMS session switching procedure, and initiates a switching message to the ATCF;

step S806 and step S806a may be performed in parallel;

step S808, the ATCF replies a switching response to the MSC Server, and the response carries the UE-B URI;

the method for carrying the UE-B URI can comprise the following steps:

adding a header field carrying a UE-B URI in the corresponding message, such as a refer-to header field or a new header field;

adding feature caps, carrying UE-B URI and the like;

step S810, ATCF sends switching notification message to SCC AS;

Steps S808 and S810 may be performed concurrently;

step S812, the SCC AS replies a notification response to the ATCF, and the ATCF and the SCC AS establish a switched access branch (signaling);

Example two

As shown in fig. 9, UE-a establishes a voice session between an IMS domain and a remote UE-B, and when UE-a decides that a session needs to be switched from the IMS domain to a CS domain, UE-a and the network implement the single-mode service continuity procedure, and in this procedure, the URI of remote UE-B is brought to the MSC, which specifically includes the following steps:

step S902, UE-A establishes a voice conversation with remote UE in PS network (LTE/SAE), the conversation is anchored on ATCF/AGW of visit area network, wherein ATCF is responsible for signaling part, AGW is responsible for media part; the session is processed by SCC AS of the UE-A home domain, and a remote branch is established with the remote UE; the method comprises the following steps that the network signal intensity changes due to the fact that UE-A moves in position and the like, the UE-A interacts with a PS network, and the PS network determines to initiate a single-mode voice session service continuity process;

Step S904, the PS network instructs the MSC Server to perform switching preparation; after the MSC Server completes the switching preparation, the MSC Server replies a response to the PS network;

step S906a, step S904, PS network instructs UE-A to access CS network, UE-A establishes signaling access branch with MSC Server, and establishes media access branch with MGW;

step S906 and step S904, the MSC Server receives the switching instruction of the PS network, initiates an IMS session switching process, and initiates a switching message to the ATCF;

step S903 and step S906a may be performed in parallel;

step S904, ATCF sends switching notification message to SCC AS;

Step S910, SCC AS replies notification response to ATCF, and ATCF and SCC AS establish switched access branch (signaling); adding a UE-B URI to the SCC AS in the message;

the method for carrying the UE-B URI can comprise the following steps:

adding feature caps, carrying UE-B URI and the like;

step S912, ATCF replies switching response to MSC Server, the response carries UE-B URI;

The remote UE-B URI may also be carried by:

MSC replaces UE to initiate IMS registration; at this time, if there is a session, the CSCF/SCC AS adds the UE-BURI to the registration response, and carries the method synchronization step S910. This registration response does not go through the ATCF.

EXAMPLE III

Fig. 10 shows a process in which UE-a establishes a voice session in an IMS domain and a remote UE-B, and when UE-a decides that a session needs to be switched from the IMS domain to a CS domain, UE-a and a network implement such single-mode service continuity, and in this process, a URI of remote UE-B is brought to an MSC, specifically including the following steps:

step S1002, UE-A establishes a voice conversation with remote UE in PS network (LTE/SAE), the conversation is anchored on ATCF/AGW of visit area network, wherein ATCF is responsible for signaling part, AGW is responsible for media part; the session is processed by SCC AS of the UE-A home domain, and a remote branch is established with the remote UE; the method comprises the following steps that the network signal intensity changes due to the fact that UE-A moves in position and the like, the UE-A interacts with a PS network, and the PS network determines to initiate a single-mode voice session service continuity process;

Step S1004, the PS network instructs the MSC Server to prepare for switching; after the MSC Server completes the switching preparation, the MSC Server replies a response to the PS network;

step S1006a, step S1004, PS network instructs UE-A to access CS network, UE-A establishes signaling access branch with MSC Server, and establishes media access branch with MGW;

step S1006, step S1004, MSC Server receives PS network switching instruction, initiates IMS session switching flow, and initiates switching message to ATCF;

step S1006 and step S1006a may be performed in parallel;

step S1008, ATCF replies switching response to MSC Server;

step S1010, ATCF sends notification message to MSC Server, carrying UE-B URI;

the message may be:

SIP MESSAGE messages;

or SIP INFO messages, etc.;

step S1012, ATCF sends switching notification message to SCC AS;

Step S1008 and step S1012 may be performed in parallel;

step S1014, the SCC AS replies a notification response to the ATCF, and the ATCF and the SCC AS establish a switched access branch (signaling);

Step S1016-S1018, SCC AS issues UE-B URI; after receiving the information of SCC AS, ATCF sends UE-B URI to MSC;

the message may be:

SIP MESSAGE messages;

or SIP INFO messages, etc.;

step S1020, the MSC executes IMS registration, and the registration path does not pass through the ATCF;

step S1022, CSCF/SCC AS issues UE-B URI;

the message may be:

SIP MESSAGE messages;

or SIP INFO messages, etc.;

example four

Fig. 11 shows a process that UE-a establishes a voice session in the IMS domain and remote UE-B, and when UE-a decides that it needs to switch the session from the IMS domain to the CS domain, UE-a and the network implement such single mode service continuity, and how the MSC obtains a specific description of the URI of remote UE-B, which specifically includes the following steps:

step S1102, UE-A establishes a voice session with remote UE in PS network (LTE/SAE), the session is anchored on ATCF/AGW of visited network, wherein ATCF is responsible for signaling part, AGW is responsible for media part; the session is processed by SCC AS of the UE-A home domain, and a remote branch is established with the remote UE; the method comprises the following steps that the network signal intensity changes due to the fact that UE-A moves in position and the like, the UE-A interacts with a PS network, and the PS network determines to initiate a single-mode voice session service continuity process;

Step S1104, PS network instructs MSC Server to perform switching preparation; after the MSC Server completes the switching preparation, the MSC Server replies a response to the PS network;

step S1106a, step S1104 are finished, PS network instructs UE-A to access CS network, UE-A and MSC Server set up signaling access branch, and media access branch with MGW;

step 1106, step 1104, the MSC Server receives the switching instruction of the PS network, initiates an IMS session switching procedure, and initiates a switching message to the ATCF;

step S1106 and step S1106a may be performed in parallel;

step S1108, the ATCF replies a switching response to the MSC Server;

step S1110, the ATCF sends a switching notification message to the SCC AS;

Steps S1108 and S1110 may be performed in parallel;

step S1112, SCC AS replies notification response to ATCF, ATCF and SCC AS establish switched access branch (signaling);

Step S1114, MSC initiates inquiry to ATCF;

the message may be:

a SIP OPTION message;

or SIP INFO, MESSAGE MESSAGEs, etc.;

step S1116, the ATCF replies a query response, and the UE-B URI is carried;

or after receiving step S1114, the ATCF initiates step S1114a (message similar to step S1114), initiates a query to the SCC AS, and the SCCAS replies to the query response step S1116a, which carries the UE-B URI, and after receiving step S1116a, the ATCF replies step S1108 to the MSC;

step S1118, MSC executes IMS registration, the registration path does not pass ATCF;

step S1120, the MSC initiates a query response, and the message is similar to step S1114;

step S1122, CSCF/SCC AS replies the query response, carrying UE-B URI.

In summary, the embodiments of the present invention achieve the following beneficial effects: based on the embodiment, the service failure caused by the fact that the remote user identification is lost and the local conversation identification is not identified by the corresponding proxy in some special scenes can be avoided.

In another embodiment, a software is provided, which is used to execute the technical solutions described in the above embodiments and preferred embodiments.

In another embodiment, a storage medium is provided, in which the software is stored, and the storage medium includes but is not limited to: optical disks, floppy disks, hard disks, erasable memory, etc.

It will be apparent to those skilled in the art that the modules or steps of the present invention described above may be implemented by a general purpose computing device, they may be centralized on a single computing device or distributed across a network of multiple computing devices, and alternatively, they may be implemented by program code executable by a computing device, such that they may be stored in a storage device and executed by a computing device, and in some cases, the steps shown or described may be performed in an order different than that described herein, or they may be separately fabricated into individual integrated circuit modules, or multiple ones of them may be fabricated into a single integrated circuit module. Thus, the present invention is not limited to any specific combination of hardware and software.

The above is only a preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes will occur to those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for sending a remote identity, comprising:

the method comprises the steps that an IP Multimedia Subsystem (IMS) agent sends a remote identifier to an IMS client, wherein the IMS client has no remote identifier;

wherein the IMS proxy sends the remote identity to the IMS client, including one of:

the IMS proxy modifies the existing message sent to the IMS client, wherein the modified existing message carries the remote end identifier; sending the modified existing message;

the IMS agent adds a designated message sent to the IMS client, wherein the designated message carries the remote end identifier; sending the specified message;

wherein the IMS proxy comprises: a first IMS proxy and a second IMS proxy,

the first IMS proxy is used for associating a session between a user equipment and the first IMS proxy and a session between the first IMS proxy and the second IMS proxy;

the second IMS proxy is used for associating a session between a remote end of the user equipment and the second IMS proxy and a session between the first IMS proxy and the second IMS proxy;

wherein the existing message comprises one of: a response message of a handover message from a network to which the IMS client belongs; a response message to the handover notification message sent to the second IMS proxy; sending a response message of a registration request to the IMS client;

wherein the designation message includes one of: a notification message, a response message to the query message from the IMS client.

2. The method of claim 1, wherein a handover notification message is used to notify the second IMS proxy of the network handover.

3. The method of claim 1, wherein sending the specified message comprises:

the first IMS agent receives the far-end identification actively issued by the second IMS agent;

and the first IMS agent sends the specified message to the IMS client, wherein the specified message carries the remote end identification.

4. The method of any of claims 1-3, wherein the IMS proxy comprises at least one of: an access switching control function (ATCF) entity, a service consistency and continuity application server (SCC AS) and a Call Session Control Function (CSCF) entity; and/or, the IMS client includes one of: a mobile switching center MSC and user equipment UE.

5. The method according to any of claims 1-3, wherein the IMS client comprises: and when the access network to which the user equipment belongs is changed, the user equipment is to be accessed to a target client in the target access network.

6. The method according to any one of claims 1-3, further comprising: determining that a session signaling path between the IMS client and the IMS proxy is different from an existing session, and that the IMS proxy is unable to recognize a local dialog identification of the IMS client.

7. A method for receiving a remote identity, comprising:

an IP Multimedia Subsystem (IMS) client receives a remote identifier from an IMS agent, wherein the IMS client has no remote identifier;

wherein the IMS client receives a remote identity from the IMS proxy, including one of: the IMS client receives the existing message modified by the IMS agent, wherein the modified existing message carries the remote end identifier; the receiving IMS client receives a designated message sent by the IMS agent, wherein the designated message carries the remote end identifier;

wherein the IMS proxy comprises: a first IMS proxy and a second IMS proxy,

wherein the first IMS proxy is configured to associate a session between a user equipment and the first IMS proxy, and a session between the first IMS proxy and the second IMS proxy;

8. The method of claim 7, wherein the IMS client comprises: and when the access network to which the user equipment belongs is changed, the user equipment is to be accessed to a target client in the target access network.

9. An apparatus for sending a remote identity, which is applied in an IP multimedia subsystem IMS proxy, the apparatus comprising:

the system comprises a sending module, a receiving module and a sending module, wherein the sending module is used for sending a remote identifier to an IMS client, and the IMS client has no remote identifier;

wherein the sending module is further configured to perform one of the following steps:

an existing message sent to the IMS client, wherein the modified existing message carries the remote identifier; sending the modified existing message;

adding a designated message sent to the IMS client, wherein the designated message carries the remote identifier; sending the specified message;

wherein the IMS proxy comprises: a first IMS proxy and a second IMS proxy,

10. A device for receiving a remote identity, applied to an IP multimedia subsystem IMS client, the device comprising:

a receiving module, configured to receive, by an IMS client, a remote identifier from an IMS proxy, where the IMS client has no remote identifier;

wherein the receiving module is further configured to perform one of the following steps:

receiving an existing message modified by the IMS proxy, wherein the modified existing message carries the remote end identifier;

receiving a designated message sent by the IMS agent, wherein the designated message carries the remote end identifier;

wherein the IMS proxy comprises: a first IMS proxy and a second IMS proxy,

11. A transmission system of remote identity, comprising an IP multimedia subsystem, IMS, proxy and an IMS client, characterized in that the system further comprises:

a sending module, located in the IMS proxy, configured to send the remote identifier to the IMS client, where the IMS client does not have a remote identifier;

a receiving module, located in the IMS client, for receiving the remote identifier from the IMS proxy; wherein the receiving module is further configured to perform one of the following steps: receiving the existing message modified by the IMS proxy; receiving the designated message sent by the IMS proxy;

wherein the IMS proxy comprises: a first IMS proxy and a second IMS proxy,