WO2015139414A1

WO2015139414A1 - Method, device, and transmission system for transmitting and receiving remote identification

Info

Publication number: WO2015139414A1
Application number: PCT/CN2014/084553
Authority: WO
Inventors: 邹常乐; 李振东; 游世林; 刘竞翔
Original assignee: 中兴通讯股份有限公司
Priority date: 2014-03-21
Filing date: 2014-08-15
Publication date: 2015-09-24
Also published as: CN104936262B; CN104936262A

Abstract

Provided in the present invention are a method, device, and transmission system for transmitting and receiving a remote identification. The transmission method comprises: an IP multimedia subsystem (IMS) proxy transmits a remote identification to an IMS client, where the IMS client has no remote identification. Employment of said technical solution provided in the present invention solves the technical problem in the related art that an IMS proxy is incapable of identifying a session that needs to execute a service when a signaling path between an IMS client and the IMS proxy is different from an existing session path, thus preventing a service request failure that is caused when a remote user identification is missing and a local session identification cannot be identified by the IMS proxy.

Description

The present invention relates to the field of communications, and in particular, to a method and a device for transmitting and receiving a remote identifier, and a transmission system. BACKGROUND OF THE INVENTION In a 2 generation (2G) and 3 (3G) mobile communication network, such as Global System for Mobile communications (GSM), Universal Mobile Communication System (Universal) The Mobile Telecommunications System (UMTS), which uses the Circuit Switch (CS) to provide voice services, has formed a good coverage. With the development of wireless broadband technology and the development of Internet Protocol (IP) technology, the entire network is evolving toward all-IP. On the one hand, the core network of the communication network to the IP Multimedia Subsystem (IP Multimedia Subsystem, referred to as IMS) evolution, on the other hand, the radio access network develops to packet switching, and carries voice and other services through a packet switching (PS) network, and can directly access the IMS, and the IMS provides communication including voice services. business. IMS is an IP-based network architecture proposed by the 3rd Generation Partnership Project (3GPP). It builds an open and flexible business environment that is independent of access and can support multimedia applications. Users provide rich multimedia services. Due to its non-access-related characteristics, services that are performed through different access networks can be uniformly controlled. For the CS network, IMS Centralized Service (ICS) technology can be used. When the traditional CS network accesses the Mobile Switching Centre (MSC), the MSC initiates registration with the home domain IMS network to directly establish an IMS signaling path, thereby achieving the purpose of IMS unified control of the CS service. There are many development directions for wireless access methods. For example, 3GPP proposes a next-generation network architecture for Long Term Evolution/System Architecture Evolution (LTE/SAE), which uses packet switching technology to provide more The high transmission rate and the shorter transmission delay can carry real-time services including voice services, which can be used as an access method of the IMS network, and the IMS provides services. Each network element in the IMS network uses the Session Initiation Protocol (SIP) to communicate; the Session Description Protocol (SDP) is used to describe the media information, including the IP address of the sending media and the media stream encoding and decoding format. , port number, and more. Among these access methods, the deployment of some access technologies is a gradual process. For example, during the deployment of LTE/SAE, operators may only cover in hot spots in the initial stage. When the user performs voice service in the LTE/SAE coverage area, the user directly accesses the IMS and establishes an IMS session with the 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, and the session anchor function in the IMS is used to maintain the continuity of the call with the remote user, so that the advantages of the CS network coverage can be fully utilized. , to ensure the continuity of business. In the above scenario, the user's mobile device can only access a wireless network while in a call state. For example, for an LTE/SAE user equipment, only the LTE/SAE network can be accessed before the handover, and not simultaneously. CS network; When moving to the CS network coverage area, the wireless connection with LTE/SAE must be disconnected to access the CS network. In this paper, the access mode is single radio access mode switching or single mode switching. FIG. 1 shows a business scenario of voice switching (also referred to as voice continuity) in the above scenario. User equipment

(User Equipment, referred to as UE) 101. When the voice service is performed in the source radio access coverage area (such as LTE/SAE), the access control function (Access Transfer Control Function, ATCF for short) 104 directly accesses the IMS 106. Establishing an IMS session with a remote user equipment (Remote UE) 107. When the user moves out of the coverage area, to ensure the continuity of the voice service, switch to the CS network, and use the session anchor function to maintain the continuity of the call with the remote user, so that the advantage of the CS network coverage can be fully utilized to ensure the service. Continuity. The Mobile Switching Centre Server (MSC Server) 102 includes a media gateway 103 of the IMS network (divided into a Media Gateway Control Function (MGCF) and a Media Processing Part Media Gateway ( The function of Media Gateway (MGW)) is combined into one entity description. To simplify the illustration and description, the Serving Call Session Control Function (Serving-CSCF, S-CSCF for short) and the Service Consistency and Continuity Application Server (SCC AS) are used as one entity. Session Initiation Protocol (SIP) communication is used between the two. The ATCF acts as a signaling anchor point at the time of handover, and controls the media access gateway (Access Gateway, AGW for short) 105 to anchor the media of the session at the time of handover to reduce the voice interruption during handover. The ATCF controls the AGW (such as H.248) through a media control protocol, which are combined into one entity description. The IMS in FIG. 1 is located in the home network of the user, and includes network elements such as a Call Session Control Function (CSCF) and various Application Servers (AS), such as providing service consistency and continuity. The SCC AS; the remote end 107, establishes an IMS session with the UE, which may be a UE, or may be a server providing services, such as a streaming media server; Before the single radio channel handover occurs in Figure 1, the UE-A establishes an IMS session with the remote UE-B in the source access network LTE/SAE. The signaling path includes:

The UE-A to the ATCF, the ATCF to the IMS, is called the access branch signaling path (before the handover); the IMS to the remote UE is called the remote branch signaling path; the media path includes:

The UE-A to the AGW is called an access branch media path; the AGW to the remote UE is called a remote branch media path; when the UE-A switches to the CS network, the signaling media path changes: The signaling path includes :

UE-A to MSC Server MSC Server to ATCF, ATCF to IMS, called access branch signaling path (after handover); remote branch signaling path unchanged; media path includes: UE-A to MGW, MGW to AGW , called the access branch media path (after switching); the remote branch media path is unchanged. Before and after the handover, the signaling is anchored in the ATCF, and the media is anchored in the AGW. The purpose is to minimize the voice interruption during the handover process and ensure a better user experience. After the handover, the MSC performs IMS registration according to the UE-A subscription information. The MSC queries the IMS access point of the UE-A home network to query the call session control function (I-CSCF) according to the domain name analysis, and performs IMS registration with the IMS network element such as the S-CSCF. The details are not described in detail. The registration path does not pass through the ATCF, so the session established after the first switched session does not pass through the ATCF, which is different from the first one. FIG. 2 shows an implementation flow of the existing single mode voice session service continuity. As shown in Figure 2, the UE-A establishes a voice session between the IMS domain and the remote UE-B. After the UE-A decision needs to switch the session from the IMS domain to the CS domain, how does the UE-A and the network implement the ticket? The process of modular business continuity is described as follows: Step 201: The UE-A establishes a voice session with the remote UE in the PS network (LTE/SAE), and the session is anchored on the ATCF/AGW of the visited network, where the ATCF is responsible for the signaling part, and the AGW is responsible for the media part; The session is handled by the SCC AS of the UE-A home domain, and the remote branch is established with the remote UE. The network signal strength changes due to the location movement of the UE-A, and the UE-A interacts with the PS network, and the PS network decides to initiate. Single mode voice session business continuity process;

The session identifier between the UE-A and the ATCF is D101, the session identifier between the ATCF and the SCC AS is D102, and the session identifier between the SCC AS and the remote UE-B is D103; wherein the ATCF can be associated with D101~D102. The SCC AS may associate with D102~D103, and D101 is invisible to the SCC AS, D 103 is not visible to the ATCF or the MSC, and D101 and D102 are invisible to the remote UE-B. Step 202: The PS network instructs the MSC Server to perform handover preparation. After the MSC Server completes the handover preparation, it responds to the PS network. After the 203a and the step 202 are completed, the PS network instructs the UE-A to access the CS network, and the UE-A and the MSC Server Establishing a signaling access branch, establishing a media access branch with the MGW; Step 203: Step 202: The MSC Server receives the handover indication of the PS network, initiates an IMS session handover procedure, and initiates a handover message to the ATCF; Step 203 and Step 203a may Step 204: The ATCF returns a handover response to the MSC Server; until this step, the MSC Server establishes a new access branch (signaling branch) after the handover with the ATCF, and the MGW and the AGW also establish a new access branch. (media branch); Step 205: The ATCF sends a handover notification message to the SCC AS. When the SDP information in the notification message is consistent with the previous session establishment, the IMS remote update process is not required; otherwise, the IMS remote update needs to be performed. Steps 204 and 205 can be performed concurrently. Step 206: The SCC AS replies with a notification response to the ATCF, and the ATCF establishes a switched access branch (signaling) with the SCC AS. After the handover, the MSC-ATCF generates a dialog D201 instead of the original one. D101; A dialogue D202 is generated between the ATCF and the SCC AS, replacing the original D102. ATCF can be associated with D201~D202, SCC AS can In association with D202~D103, D201 is invisible to SCC AS, D 103 is not visible to ATCF or MSC, and D201 and D202 are invisible to remote UE-B. Step 207: After the handover is completed, the MSC performs IMS registration instead of the UE, and the registration path does not pass through the ATCF. After the foregoing process, a special scenario occurs, that is, the signaling path after the IMS is registered by the IMS is different from the existing first session. There is an IMS full proxy (ATCF) in the first session path. Step 208: The MSC initiates a new session establishment request to the SCC AS to establish a session with the third-party UE-C. Step 208a: The SCC AS establishes a session with the UE-C. Step 209: The SCC AS replies to the MSC to establish a response. The dialogue with the SCC AS is D301, and the dialogue between the SCC AS and the UE-C is D302; the above session is established after step 207, so the signaling path does not pass through the ATCF. This process contains a number of different situations, such as:

After the first session handover is completed, the SCC AS also has a session with the UE-C on the source side network, so it is notified to switch the second session. In this case, the SCC AS instructs the MSC to initiate the second session before step 208. Switching; or UE switching to the CS domain, the UE establishes another session with the UE-C, etc.; the above session establishment request is only an example, and is a call-up procedure, and may also be a session initiated by UE-C to UE-A. The establishment process is the final call process. Step 210: The MSC initiates a new service request, such as a conference (referred to as CO F) or an explicit call transfer (ECT). Take the CONF business example:

The MSC establishes a session with the CONF AS, and instructs the CONF to join the UE-B and the UE-C to the conference respectively. The method by which the MSC indicates to join UE-B is to send a REFER message to the CONF AS. In normal circumstances, the REFER message needs to carry the parameters: request URI (requested destination address): CONF AS URI refer-to: UE-B URI + D201 The semantics of the REFER message is as follows: The request URI is the target of the REFER message. After receiving the REFER message, the target sends an INVITE message to the URI according to the information carried in the refer-to, that is, the URI and the session identifier, and carries the replace parameter. Set the dialog ID so that the client receiving the INVITE will understand that the purpose of the INVITE message is to create a new session and replace the dialog specified in replace. The message arrives at the CONF AS via the SCC AS. After receiving the request, the CONF AS sends an INVITE message to the UE-B URI, carrying the replace parameter with the session identifier that requires UE-B replacement. Since the UE-B URI cannot be notified to the MSC after the first session is switched, the MSC cannot fill in the UE-B URI in the refer-to, but can only fill in the D201. If no ATCF exists, that is, the MSC and the SCC AS are directly connected through the D201, the Bay U SCC AS can associate the D103 with the D201, correctly discover the UE-B, and inform the CONF AS of the UE-B URI and D103 (replace the local conversation D201 The remote session D103 is also the operation that the B2BUA needs to perform. Therefore, the CONF AS specifies that the request destination address in the INVITE message is the UE-B URI, and the session identifier to be replaced is D103, and is normally completed after being sent to the UE-B through the INVITE message. The CONF AS establishes a session with UE-B and replaces the existing conversation D 103. When the ATCF exists, the following problems are caused: Since the SCC AS cannot locate the related session through the remote user identity (the UE-B URI is missing), and there is the IMS full proxy ATCF, the D201 is invisible to the SCC AS, so the SCC AS cannot The remote session is correctly located by the dialog identifier D201 (there are D103 and D302), so the SCC AS/CO F AS cannot determine the subsequently initiated INVITE target (UE-B) and the dialog (D103) that needs to be replaced, resulting in the failure to complete the requested business. The ECT service is similar to the problem generated by the CONF service, and will not be repeated here. To sum up, 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 an IMS proxy ( SCC AS) Unrecognized the conversation ID (D201) local to the IMS client, causing the service to fail. The special scenario described above, that is, the signaling path after registration by the IMS on the MSC is different from the existing first session, and the IMS full proxy (ATCF) exists in the first session path, which is a typical scenario that causes the problem. Similar problems may occur in all scenarios that meet the problem described in the previous paragraph. This article will not go into details. SUMMARY OF THE INVENTION In the related art, when the signaling path between the IMS client and the IMS proxy is different from the existing session path, the IMS proxy cannot identify the technical problem such as the conversation that needs to perform the service, and the present invention provides a remote identifier. The transmitting and receiving methods and devices, and the transmission system, to at least solve the above problems. In order to achieve the above object, according to an embodiment of the present invention, a method for transmitting a remote identifier is provided, including: an IP multimedia subsystem IMS proxy sends a remote identifier to an IMS client, where the IMS client is not far away End identification. Preferably, the IMS proxy sends the remote identifier to the IMS client, including one of the following: the IMS proxy modifies an existing message sent to the IMS client, where the modified existing The message carries the remote identifier; the modified existing message is sent; the IMS proxy adds a specified message to the IMS client, where the specified message carries the remote identifier; Send the specified message. Preferably, the sending the modified existing message includes: the IMS proxy receiving a handover message from a network to which the IMS client belongs; and the IMS proxy sending a response message of the handover message to the IMS client The response message carries the remote identifier. Preferably, the IMS proxy comprises: a first IMS proxy and a second IMS proxy, where the first

An 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 the user A session of the remote end of the device with 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, where the handover notification message is used to notify the second IMS proxy to perform The first IMS proxy receives the response message of the handover notification message from the second IMS proxy, where the response message carries the remote identifier; the first IMS proxy sends the response Message. Preferably, the sending the specified message includes: the first IMS proxy receiving the remote identifier sent by the second IMS proxy, and the first IMS proxy sending the identifier to the IMS client The specified message, where the specified message carries the remote identifier. Preferably, the sending the modified existing message includes: the IMS proxy receiving an IMS registration request initiated by the IMS client instead of the user equipment; and the IMS proxy sending the registration request to the IMS client a response message, where the response message carries the remote identifier. Preferably, the sending the specified message includes: sending, by the IMS proxy, a notification message to the IMS client, where the notification message carries the remote identifier. Preferably, the sending the specified message includes: the IMS proxy receiving a query message from the IMS client; the IMS proxy replies to the IMS client with a response message of the query message, where the response message is Carrying the remote identifier. Preferably, the IMS proxy comprises at least one of: an access handover control function ATCF entity, a service consistency and continuity application server SCC AS, a call session control function CSCF entity; and/or the IMS client includes the following One of them: a mobile switching center MSC, a user equipment UE. Preferably, the IMS client includes: a target client to be accessed in the target access network when the access network to which the user equipment belongs changes. Advantageously, the method further comprises determining that the session signaling path between the IMS client and the IMS proxy is different from an existing session, and the IMS proxy is unable to identify the local session identifier of the IMS client. In order to achieve the above object, according to still another embodiment of the present invention, a method for receiving a remote identifier is further provided, including: an IP multimedia subsystem IMS client receiving a remote identifier from an IMS proxy, wherein the IMS client There is no remote identifier on the end. Preferably, the IMS client includes: a target client to be accessed in the target access network when the access network to which the user equipment belongs changes. In order to achieve the above object, according to still another embodiment of the present invention, a remote identifier sending apparatus is further provided, which is applied to an IP multimedia subsystem IMS proxy, where the apparatus comprises: a sending module, configured to be to an IMS client. Sending a remote identifier, where the IMS client has no remote identifier. In order to achieve the above object, according to still another embodiment of the present invention, a remote identifier receiving apparatus is further provided, which is applied to an IP Multimedia Subsystem IMS client, and the apparatus includes: a receiving module, configured to receive from an IMS proxy The remote identifier, where the IMS client has no remote identifier. In order to achieve the above object, according to still another embodiment of the present invention, a remote identification transmission system is provided, including an IP multimedia subsystem IMS proxy and an IMS client, and the system further includes: a sending module, located in the The IMS proxy is configured to send the remote identifier to the IMS client, where the IMS client has no remote identifier; and the receiving module is located in the IMS client, and is configured to receive from the IMS proxy Remote ID. Through the present invention, the IMS agent cannot identify the need when the signaling path between the IMS client and the IMS proxy is different from the existing session path by using the technical means for the IMS proxy to notify the IMS client of the remote identifier. Technical problems such as the execution of a conversation of the service, thereby avoiding the failure of the service request due to the absence of the remote user identity and the fact that the local conversation identifier cannot be recognized by the IMS proxy. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are set to illustrate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 1 is a schematic diagram of a typical application scenario architecture of a voice switching process according to the related art; FIG. 2 is a schematic diagram of a signaling flow of a single channel session switching according to the related art; FIG. 3 is a schematic diagram of a remote end according to an embodiment of the present invention. FIG. 4 is a flowchart of a method for receiving a remote identifier according to an embodiment of the present invention; FIG. 5 is a structural block diagram of a transmitting device for a remote identifier according to an embodiment of the present invention; FIG. 7 is a structural block diagram of a transmission system of a remote identifier according to an embodiment of the present invention; FIG. 8 is a structural diagram of a remote identifier transmission according to a preferred embodiment 1 of the present invention; FIG. 9 is a schematic flowchart of a method for transmitting a remote identifier according to a preferred embodiment 2 of the present invention; FIG. 10 is a schematic flowchart of a method for transmitting a remote identifier according to a preferred embodiment 3 of the present invention; A schematic flowchart of a transmission method of the remote identifier of the preferred embodiment 4. BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict. FIG. 3 is a flowchart of a method for transmitting a remote identifier according to an embodiment of the present invention. As shown in FIG. 3, the method includes: Step S302: The IMS proxy obtains the remote identifier. Step S304: The IP multimedia subsystem IMS proxy sends the remote identifier (ie, the remote user equipment identifier) to the IMS client. Through the above processing steps, since the IMS proxy can inform the IMS client of the remote identifier, the problem caused by the IMS client not being able to learn the remote identifier can be solved, especially the signaling path between the IMS client and the IMS proxy. When the IMS proxy cannot identify the conversation that needs to perform the service when it is different from the existing session path, it can solve the problem that the subsequent service request cannot be executed. It should be noted that step S302 can be used as an optional step in the specific implementation process, that is, the processing step does not need to be performed first. The application scenario in this embodiment may be the following scenario, but is not limited thereto: determining that the session signaling path between the IMS client and the IMS proxy is different from the existing session, and the IMS proxy cannot identify the local session identifier of the IMS client. Based on the above steps, the user can implement the subsequent service in the scenario. In this embodiment, the IMS client includes, but is not limited to: a target client to be accessed in the target access network when the access network to which the user equipment belongs changes. In this embodiment, the remote identifier may be used by the IMS client to perform subsequent service requests, but is not limited thereto. In step S302, the method for obtaining the remote identifier is different, for example, it is obtained from a third-party device (including but not limited to, storing the remote identifier after receiving the remote identifier from the third-party device), and may also be set locally, but is not limited thereto. 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 mode: the IMS proxy modifies the sending to the IMS client. An existing message, where the modified existing message carries the remote identifier; the modified existing message is sent; and for the second sending mode, the IMS proxy adds a specified message to the IMS client. The specified message carries the remote identifier; and the specified message is sent. In a preferred embodiment of the embodiment, the first transmission mode can be implemented in the following manners:

(1) The IMS proxy receives the handover message from the network to which the IMS client belongs; the IMS proxy sends the response message of the handover message to the IMS client, where the response message carries the remote identifier; (2) The IMS proxy receives the IMS registration request initiated by the IMS client in place of the user equipment; the IMS proxy sends a response message to the IMS client to the registration request, where the response message carries the remote identifier;

(3) A handover notification message sent by the first IMS proxy to the second IMS proxy when the IMS proxy includes the first IMS proxy and the second IMS proxy, wherein the handover notification message is used to notify the second IMS proxy to perform network handover The first IMS proxy receives the 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. 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; and the second IMS proxy is configured to associate the foregoing a session between the remote end of the user equipment and the second IMS proxy, and a session between the first proxy IMS and the second IMS proxy. For the second transmission method, it can be implemented in the following ways:

(1) The IMS proxy sends a notification message to the IMS client, where the notification message carries the remote identifier. (2) The IMS proxy receives the query message from the IMS client; the IMS proxy replies to the IMS client with the response message of the query message, where the response message carries the remote identifier.

(3) When the IMS proxy includes the first IMS proxy and the second IMS proxy, the first IMS proxy receives the remote identifier that is actively delivered by the second IMS proxy; The IMS client sends the specified message, where the specified message carries the remote identifier. In this embodiment, the IMS proxy includes at least one of the following: an ATCF entity, an SCC AS, a CSCF entity; and/or, the IMS client includes one of the following: an MSC, a UE. In this embodiment, a method for receiving a remote identifier is also provided. As shown in FIG. 4, the method includes: Step S402: An IMS client receives a remote identifier from an IMS proxy, where the IMS client is a user. When the access network to which the device belongs is changed, the target client to be accessed in the target access network, the remote identifier is the peer identifier of the user equipment. Step S404: The IMS client performs a subsequent service request according to the foregoing remote identifier. Step S404 can be used as an optional step according to a specific application scenario. The preferred embodiment in the embodiment shown in FIG. 4 corresponds to the embodiment in the embodiment shown in FIG. 3, and details are not described herein again. In this embodiment, a remote identifier sending device is further provided, and the device is located in the IMS proxy. As shown in FIG. 5, the device includes: a sending module 50, configured to send a remote identifier to the IMS client, where The IMS client has no remote identifier. In this embodiment, a receiving device for the remote identifier is further provided, and the device is located in the IMS client. As shown in FIG. 6, the device includes: a sending module 60, configured to send a remote identifier to the IMS client, The IMS client has no remote identifier. In this embodiment, a remote identification transmission system is further provided. As shown in FIG. 7, the system includes an IMS proxy 70 and an IMS client 72. The IMS client 72 may include, but is not limited to: at the user equipment. When the access network changes, the target client in the target access network is to be accessed; the sending module 50 is located in the IMS proxy 70, and is configured to send the remote identifier to the IMS client 72, where the remote identifier is The peer end identifier of the foregoing user equipment; the receiving module 60, located in the IMS client 72, is configured to receive the remote identifier from the IMS proxy. In order to better understand the above embodiments, the following detailed description will be given in conjunction with the preferred embodiments. The following preferred embodiment is described by taking the following scenario as an example: when the session signaling path between the IMS client and the IMS proxy is different from the existing session, the IMS proxy cannot identify the session identifier local to the IMS client, which may cause a service failure. For example, the enhanced single-channel voice service switching scenario (a typical scenario in this document) is used. The signaling path after IMS registration on the MSC is different from the existing first session. The IMS is in the first session path. The agent (ATCF), when the CONF or ECT service is initiated, the SCC AS cannot locate the related session through the remote user identifier, that is, the Uniform Resource Identifier (URI) of the UE-B is missing, and the IMS exists. Full proxy ATCF, so D201 is invisible to the SCC AS, and can not correctly locate the remote session (there are D103 and D302) through the dialog identifier D201, 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 notifies the remote identification URI of the IMS client, and the IMS client carries the remote URI in the subsequent service request, even if the local conversation identifier is not identified by the IMS proxy, The end URI is correctly associated with the conversation that needs to be performed to perform the requested service correctly. As shown in FIG. 8, UE-A establishes a voice session in the IMS domain and the remote UE-B. After the UE-A decision needs to switch the session from the IMS domain to the CS domain, UE-A and the network implement this. A process of single-mode service continuity, and in the process, the remote UE-B URI is brought to the MSC. The specific steps are as follows: Step S802: The UE-A establishes a voice session with the remote UE in the PS network (LTE/SAE), and the session is anchored on the ATCF/AGW of the visited network, where the ATCF is responsible for the signaling part, the AGW. Responsible for the media part; the session is handled by the SCC AS of the UE-A home domain, and the remote branch is established with the remote UE; the network signal strength changes due to the UE-A location movement, etc., and the UE-A interacts with the PS network. The PS network decides to initiate a single-mode voice session service continuity process; the session identifier between the UE-A and the ATCF is D101, and the session identifier between the ATCF and the SCC AS is

D102, the conversation identifier between the SCC AS and the remote UE-B is D103; wherein the ATCF can be associated with D101-D102, the SCC AS can be associated with D102~D103, and D101 is invisible to the SCC AS, and the D103 is not visible to the ATCF or the MSC. D101, D102 are not visible to the remote UE-B. Step S804: The PS network instructs the MSC Server to perform handover preparation. After the MSC Server completes the handover preparation, it responds to the PS network. After the step S806a and the step S804 are completed, the PS network instructs the UE-A to access the CS network, UE-A and the MSC.

The server establishes a signaling access branch, and establishes a media access branch with the MGW. In step S806, step S804, the MSC Server receives the handover indication of the PS network, initiates an IMS session handover procedure, and initiates a handover message to the ATCF. Step S806 and step S806a Step S808: The ATCF sends a handover response to the MSC Server, and the UE-B URI is carried in the response. The method of carrying the UE-B URI may include: adding a header field in the corresponding message, and carrying the UE-B URI, Such as refer-to header field or new header field; add feature caps, carry UE-B URI, etc.; until this step, MSC Server and ATCF establish a new access branch (signaling branch) after handover, and MGW and AGW A new access branch (media branch) has also been established; Step S810: The ATCF sends a handover notification message to the SCC AS. When the SDP information in the notification message is consistent with the previous session establishment, the IMS remote update process is not required; otherwise, the IMS remote update needs to be performed. Steps S808 and S810 can be performed concurrently; Step S812, the SCC AS replies to the ATCF with a notification response, and the ATCF establishes a switched access branch (signaling) with the SCC AS; after the handover, the MSC-ATCF generates a dialogue D201, instead of the original D101; A dialogue D202 is generated between the ATCF and the SCC AS, instead of the original D102. The ATCF can be associated with D201 ~ D202, the SCC AS can be associated with D202~D103, and the 0201 is invisible to 3003, the D103 is not visible to the ATCF or the MSC, and the D201 and D202 are invisible to the remote UE-B. Embodiment 2 As shown in FIG. 9, UE-A establishes a voice session in the IMS domain and the remote UE-B. After the UE-A decision needs to switch the session from the IMS domain to the CS domain, UE-A and the network implement this. The process of the single-mode service continuity, and the remote UE-B URI is brought to the MSC in the process, which includes the following steps: Step S902: The UE-A establishes with the remote UE in the PS network (LTE/SAE). a voice session anchored on the ATCF/AGW of the visited network, where the ATCF is responsible for the signaling part and the AGW is responsible for the media part; the session is handled by the SCC AS of the UE-A home domain, establishing a far distance with the remote UE End branch; due to UE-A location movement and other reasons, the network signal strength changes, UE-A interacts with the PS network, and the PS network decides to initiate a single-mode voice session service continuity process; the session identifier between UE-A and ATCF is D101, the dialog between the ATCF and the SCC AS is identified as

D102, the conversation identifier between the SCC AS and the remote UE-B is D103; wherein the ATCF can be associated with D101-D102, the SCC AS can be associated with D102~D103, and D101 is invisible to the SCC AS, and the D103 is not visible to the ATCF or the MSC. D101, D102 are not visible to the remote UE-B. Step S904: The PS network instructs the MSC Server to perform handover preparation. After the MSC Server completes the handover preparation, it responds to the PS network. After the step S904a and the step S904 are completed, the PS network instructs the UE-A to access the CS network, and the UE-A and the MSC.

The server establishes a signaling access branch, and establishes a media access branch with the MGW; In step S906, step S904, the MSC server receives the handover indication of the PS network, initiates an IMS session handover procedure, and initiates a handover message to the ATCF; step S903 and step S906a may be performed in parallel; step S904, the ATCF sends a handover notification message to the SCC AS; When the SDP information in the notification message is consistent with the previous session establishment, the IMS remote update process is not required; otherwise, the IMS remote update needs to be performed. Step S910: The SCC AS replies with the notification response to the ATCF, and the ATCF establishes a handover access branch (signaling) with the SCC AS. In the message, the SCC AS adds the UE-B URI. The method for carrying the UE-B URI may include: Adding a header field to the corresponding message, carrying a UE-B URI, such as a refer-to header field or a new header field; adding feature caps, carrying a UE-B URI, etc.; Step S912, the ATCF returns a handover response to the MSC Server, in response Carrying the UE-B URI; until this step, the MSC Server establishes a new access branch (signaling branch) after the handover with the ATCF, and the MGW and the AGW also establish a new access branch (media branch); A dialogue D201 is generated between the MSC-ATCF to replace the original D101; a dialogue D202 is generated between the ATCF and the SCC AS, instead of the original D102. The ATCF can be associated with D201 ~ D202, the SCC AS can be associated with D202~D103, and the 0201 is invisible to 3003, the D103 is not visible to the ATCF or the MSC, and the D201 and D202 are invisible to the remote UE-B. The remote UE-B URI can also be carried in the following manner: The MSC initiates the IMS registration instead of the UE; if there is a session, the UE-CSCF/SCC AS adds the UE-B URI in the registration response, and the carrying manner is the same as step S910. This registration response does not go through ATCF. Embodiment 3 FIG. 10 shows that UE-A establishes a voice session between the IMS domain and the remote UE-B. After the UE-A decision needs to switch the session from the IMS domain to the CS domain, the UE-A and the network implement the same. The process of the single-mode service continuity, and the remote UE-B URI is brought to the MSC in the process, which includes the following steps: Step S1002: The UE-A establishes a voice session with the remote UE in the PS network (LTE/SAE), and the session is anchored on the ATCF/AGW of the visited network, where the ATCF is responsible for the signaling part, and the AGW is responsible for the media part; The session is handled by the SCC AS of the UE-A home domain, and the remote branch is established with the remote UE. The network signal strength changes due to the location movement of the UE-A, and the UE-A interacts with the PS network, and the PS network decides to initiate. Single mode voice session business continuity process;

The session identifier between the UE-A and the ATCF is D101, the session identifier between the ATCF and the SCC AS is D102, and the session identifier between the SCC AS and the remote UE-B is D103; wherein the ATCF can be associated with D101-D102, SCC The AS can associate D102~D103, and D101 is invisible to the SCC AS, D103 is not visible to the ATCF or MSC, and D101 and D102 are invisible to the remote UE-B. Step S1004: The PS network instructs the MSC Server to perform handover preparation. After the MSC Server completes the handover preparation, it responds to the PS network. After the step S1006a and the step S1004 are completed, the PS network instructs the UE-A to access the CS network, and the UE-A and the MSC Server Establishing a signaling access branch, and establishing a media access branch with the MGW; in step S1006, step S1004, the MSC Server receives the handover indication of the PS network, initiates an IMS session handover procedure, and initiates a handover message to the ATCF; Step S1006 and Step S1006a Step S1008: The ATCF sends a handover response to the MSC Server. Step S1010: The ATCF sends a notification message to the MSC Server, carrying the UE-B URI. The message may be: a SIP MESSAGE message, or a SIP INFO message, etc.; Step S1012 The ATCF sends a handover notification message to the SCC AS. When the SDP information in the notification message is consistent with the previous session establishment, the IMS remote update process is not required; otherwise, the IMS remote update needs to be performed. Step S1008 and step S1012 can be performed in parallel; Step S1014: The SCC AS replies with a notification response to the ATCF, and the ATCF establishes a handover access branch (signaling) with the SCC AS. Until this step, the MSC Server establishes a new access branch (signaling branch) after the handover with the ATCF. At the same time, MGW and AGW also establish a new access branch (media branch); after switching, MSC-ATCF generates dialog D201 instead of the original D101; ATCF and SCC AS generate dialog D202 instead of the original D102. . The ATCF can be associated with D201 ~ D202, the SCC AS can be associated with D202~D103, and the 0201 is invisible to 3003, the D103 is not visible to the ATCF or the MSC, and the D201 and D202 are invisible to the remote UE-B. Steps S1016-S1018: The SCC AS sends the UE-B URI. After receiving the SCC AS message, the ATCF sends the UE-B URI to the MSC. The message may be:

SIP MESSAGE message; or SIP INFO message, etc.; Step S1020, the MSC performs IMS registration, the registration path does not pass through the ATCF; Step S1022, the CSCF/SCC AS sends the UE-B URI; the message may be: SIP MESSAGE message; or SIP INFO message, etc. Embodiment 4 FIG. 11 shows that UE-A establishes a voice session in the IMS domain and the remote UE-B. After the UE-A decision needs to switch the session from the IMS domain to the CS domain, UE-A and The process of implementing the single-mode service continuity of the network and the specific description of how the MSC obtains the remote UE-B URI includes the following steps: Step S1102: UE-A establishes with the remote UE in the PS network (LTE/SAE) A voice session is anchored on the ATCF/AGW of the visited network, where the ATCF is responsible for the signaling part and the AGW is responsible for the media part; the session is handled by the SCC AS of the UE-A home domain, and the session is established with the remote UE. Remote branch; due to UE-A The network signal strength changes due to location movement, etc., UE-A interacts with the PS network, and the PS network decides to initiate a single-mode voice session service continuity process;

The session identifier between the UE-A and the ATCF is D101, the session identifier between the ATCF and the SCC AS is D102, and the session identifier between the SCC AS and the remote UE-B is D103; wherein the ATCF can be associated with D101-D102, SCC The AS can associate D102~D103, and D101 is invisible to the SCC AS, D103 is not visible to the ATCF or MSC, and D101 and D102 are invisible to the remote UE-B. Step S1104: The PS network instructs the MSC Server to perform handover preparation. After the MSC Server completes the handover preparation, it responds to the PS network. After the step S1106a and the step S1104 are completed, the PS network instructs the UE-A to access the CS network, and the UE-A and the MSC Server Establishing a signaling access branch, and establishing a media access branch with the MGW; in step S1106, step S1104, the MSC Server receives the handover indication of the PS network, initiates an IMS session handover procedure, and initiates a handover message to the ATCF; Step S1106 and Step S 1106a may be executed in parallel; Step S1108: The ATCF returns a handover response to the MSC Server; Step S1110: The ATCF sends a handover notification message to the SCC AS. When the SDP information in the notification message is consistent with the previous session establishment, the IMS remote end is not required. Update process; otherwise, IMS remote update is required. Steps S1108 and S1110 may be performed in parallel; Step S1112, the SCC AS replies to the ATCF with a notification response, and the ATCF establishes a switched access branch (signaling) with the SCC AS; until this step, the MSC Server establishes a new switch with the ATCF. Access branch (signaling branch), and MGW and AGW also establish a new access branch (media branch); after switching, MSC-ATCF generates dialog D201 instead of the original D101; ATCF and SCC AS generate Dial D202, replacing the original D102. The ATCF can be associated with D201 ~ D202, the SCC AS can be associated with D202~D103, and the D201 is invisible to the SCC AS, the D103 is not visible to the ATCF or the MSC, and the D201 and D202 are invisible to the remote UE-B. Step S1114: The MSC initiates a query to the ATCF; the message may be:

SIP OPTION message; or SIP INFO, MESSAGE message, etc.; Step S1116, ATCF reply query response, carrying UE-B URI; or ATCF after receiving step S1114, initiating step S1114a (message similar to step S1114), initiating a query to SCC AS The SCCAS reply query response step S1116a, carrying the UE-B URI, the ATCF receiving the step S1116a and then returning the MSC to the step S1108; Step S1118, the MSC performs the IMS registration, the registration path does not pass the ATCF; Step S1120, the MSC initiates the query response, The message is similar to step S1114; Step S1122, CSCF/SCC AS replies to the query response, and carries the UE-B URI. In summary, the embodiments of the present invention achieve the following beneficial effects: Based on the foregoing embodiment, it may be avoided that in some special scenarios, because the remote user identifier is missing, and the local conversation identifier is not identified by the corresponding proxy, the service is caused. failure. In another embodiment, software is also provided for performing the technical solutions described in the above embodiments and preferred embodiments. In another embodiment, a storage medium is provided, the software being stored, including but not limited to: an optical disk, a floppy disk, a hard disk, a rewritable memory, and the like. Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device, such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein. The steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps are fabricated as a single integrated circuit module. Thus, the invention is not limited to any specific combination of hardware and software. The above are only the preferred embodiments of the present invention, and are not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention. INDUSTRIAL APPLICABILITY The technical solution provided by the embodiments of the present invention can be applied to the transmission process of the remote identifier, and the IMS agent is used to notify the IMS client of the remote identification. When the signaling path between the IMS agents is different from the existing session path, the IMS agent cannot identify technical problems such as the dialogue that needs to perform the service, thereby avoiding the situation that the remote user identifier is missing and the local conversation identifier cannot be recognized by the IMS proxy. The resulting business request failed.

Claims

Claim

A method for transmitting a remote identifier, including:

The IP Multimedia Subsystem The IMS proxy sends a remote identifier to the IMS client, where the IMS client has no remote identifier.

2. The method according to claim 1, wherein the IMS proxy sends the remote identifier to the IMS client, including one of the following:

The IMS proxy modifies the existing message sent to the IMS client, where the modified remote message is carried in the modified existing message; and the modified existing message is sent;

The IMS proxy adds a specified message to the IMS client, where the specified message carries the remote identifier; and the specified message is sent.

3. The method according to claim 2, wherein the transmitting the modified existing message comprises: the IMS proxy receiving a handover message from a network to which the IMS client belongs; the IMS proxy to the IMS The client sends a response message of the handover message, where the response message carries the remote identifier.

4. The method according to claim 2, wherein the IMS proxy comprises: a first IMS proxy and a second IMS proxy, wherein the first IMS proxy is configured to associate a user equipment with the first IMS proxy a session between the first proxy IMS and the second IMS proxy; the second IMS proxy is configured to associate a session of the remote end of the user equipment with the second IMS proxy, and A session between the first proxy IMS and the second IMS proxy.

5. The method according to claim 4, wherein the sending the modified existing message comprises:

a handover notification message sent by the first IMS proxy to the second IMS proxy, where the handover notification message is used to notify the second IMS proxy to perform network handover; the first IMS proxy receives from a second IMS proxy The response message of the handover notification message, where the response message carries the remote identifier; the first IMS proxy sends the response message.

The method of claim 4, wherein the sending the specified message comprises: the first IMS proxy receiving the remote identifier that is actively delivered by the second IMS proxy; The first IMS proxy sends the specified message to the IMS client, where the specified message carries the remote identifier.

The method according to claim 2, wherein the sending the modified existing message comprises: receiving, by the IMS proxy, an IMS registration request initiated by the IMS client instead of the user equipment; The IMS client sends a response message to the registration request, where the response message carries the remote identifier.

The method of claim 2, wherein the sending the specified message comprises: sending, by the IMS proxy, a notification message to the IMS client, where the notification message carries the remote identifier.

9. The method of claim 2, wherein the transmitting the specified message comprises: the IMS proxy receiving a query message from the IMS client; the IMS proxy replying the query message to the IMS client The response message, where the response message carries the remote identifier.

The method according to any one of claims 1 to 9, wherein the IMS proxy comprises at least one of: an access handover control function ATCF entity, a service consistency and continuity application server SCC AS, a call session The control function CSCF entity; and/or the IMS client comprises one of the following: a mobile switching center MSC, a user equipment UE.

The method according to any one of claims 1-9, wherein the IMS client comprises: a target client to be accessed in the target access network when the access network to which the user equipment belongs changes.

The method of any of claims 1-9, wherein 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 the IMS proxy cannot identify the local conversation identifier of the IMS client.

13. A method for receiving a remote identifier, comprising:

The IP Multimedia Subsystem The IMS client receives the remote identity from the IMS agent, wherein the IMS client has no remote identity.

The method according to claim 13, wherein the IMS client comprises: a target client to be accessed in the target access network when the access network to which the user equipment belongs changes.

15. A remote identification transmitting device for use in an IP Multimedia Subsystem IMS proxy, the device comprising:

The sending module is configured to send a remote identifier to the IMS client, where the IMS client has no remote identifier.

16. A receiving device for remote identification, applied to an IP Multimedia Subsystem IMS client, the device comprising:

The receiving module is configured to receive a remote identifier from the IMS proxy, where the IMS client has no remote identifier.

17. A remote identification transmission system comprising an IP Multimedia Subsystem IMS Proxy and an IMS Client, the system further comprising:

a sending module, located in the IMS proxy, configured to send the remote identifier to the IMS client, where the IMS client has no remote identifier;

A receiving module, located in the IMS client, is configured to receive a far end identifier from the IMS proxy.