CN101917429B - Domain switching method, server and control device - Google Patents

Abstract

The invention discloses a domain switching method, a server and a control device, wherein the domain switching method includes: the call session control device receives a call request initiated by a terminal using a session transfer identifier as a called address, and routes the call request to the server, The session transfer identifier is pre-assigned by the server and is used to identify the session and the domain switching of the session; the server learns that the call request is used for the A domain switch is performed on the session, and a corresponding domain switch is performed on the session. The embodiment of the present invention performs domain switching on a session according to a dynamically allocated STID, which can effectively ensure the correctness and effectiveness of domain switching, promote the diversified development of network services, save network resources, and improve domain switching efficiency.

Description

Domain switching method, server and control device

technical field

The invention relates to mobile communication technology, in particular to a domain switching method, server and control device.

Background technique

The Universal Mobile Telecommunications System (hereinafter referred to as: UMTS) core network is based on the Global System for Mobile Communications (Global System for Mobile Communications, hereinafter referred to as: GSM) and the General Packet Radio Service (hereinafter referred to as: GPRS) The Internet Protocol (hereinafter referred to as: IP) backbone network developed on the Internet. It can be logically divided into a circuit-switched (Circuit-Switched, hereinafter referred to as: CS) domain and a packet-switched (Packet-Switched, hereinafter referred to as: PS) domain. The CS domain is the circuit switching core network of UMTS, which is used to support circuit data services; the PS domain is the packet service core network of UMTS, which is used to support packet data services and some multimedia services. In UMTS, signaling control and data transmission are separated.

At present, the mobile communication network is dominated by CS, including GSM, Code Division Multiple Access (Code Division Multiple Access, hereinafter referred to as: CDMA) and so on. At present, each mobile communication network operator has established a relatively complete and rich service platform based on the CS network, in which the mobile switching center (Mobile Switching Center, hereinafter referred to as: MSC) is responsible for call routing and service logic execution. In addition, the MSC can also cooperate with other application servers of the CS network, such as the color ring back tone server, to provide corresponding services. However, since the service provision of the CS network needs the support of the roaming MSC, the development of the service is limited.

The Internet Protocol Multimedia Subsystem (IP Multimedia subsystem, hereinafter referred to as: IMS) is a subsystem superimposed on the PS domain by the 3rd Generation Partnership Project (3rd Generation Partnership Project, hereinafter referred to as: 3GPP), which uses the IP packet domain as its control For the bearer channel of signaling and media transmission, the Session Initial Protocol (SIP) protocol is introduced as a service control protocol. Using the characteristics of SIP's simplicity, easy expansion, and convenient media combination, it realizes service management, session control and bearer The three accesses are separated to provide rich multimedia services. In IMS, since the service provision has nothing to do with the roaming area, it is beneficial to the introduction of new multimedia services. IMS supports terminal access to the IMS network through various packet switching access networks for IMS multimedia services. Currently, the most commonly used molecular switching access network is the IP capability access network (IP capability access network, hereinafter referred to as: IP-CAN). For example: GPRS, that is: IMS is a business platform based on IP-CAN. Compared with the CS network, IP-CAN can provide higher bandwidth and support richer services.

The main functional entities in the IMS include: Call Session Control Function (Call Session Control Function, hereinafter referred to as: CSCF) device for controlling user registration and realizing session control functions, also known as: call session control device for centralized management The home subscriber server (Home Subscriber Server, hereinafter referred to as: HSS) of user subscription data, and the application server (Application Server, hereinafter referred to as: AS) that provides various business logic control functions, and the quality of service (Quality of Service, hereinafter referred to as : Qos) management policy decision function entity (Policy DecisionFunction, hereinafter referred to as: PDF). IMS initial filter standard (hereinafter referred to as: iFC) service trigger architecture has the advantages of simplicity, high processing efficiency, no relationship with specific business logic, simple service combination through serial AS, etc., which strongly supports the core of separation of IMS service and control feature.

At present, researches on next generation network (Next Generation Network, NGN for short) by major standard organizations are all based on IMS. With the deployment of IMS-based NGN, the entire network will have the coexistence of multiple service networks such as IMS, NGN, CS domain, and Internet services. The characteristics of IMS will absorb more services and may eventually replace NGN and CS network. Because the IMS network cannot be completed in a short period of time, and at the same time, it is impossible to replace all CS network user terminals with IMS terminals in a short period of time, the CS network will coexist with the IMS network for a certain period of time. In order to reduce the cost of operating the two service platforms of CS and IMS at the same time, and the cost of rebuilding the two service platforms of CS and IMS when introducing new services, the functions of the CS network service platform can be transferred to the IMS network to realize the integration of the service platform. Unification, the unification of service platforms is also called IMS Centralized Services (IMS Centralized Services, hereinafter referred to as: ICS) control.

The ICS requires the terminal to establish an IMS call through the CS network carrying voice media, and the AS in the IMS provides the call service. As shown in FIG. 1 , it is a structure diagram of an ICS in the prior art. Among them, the media gateway (Media Gateway, hereinafter referred to as: MGW) or MGW control function (MGW Control Function, hereinafter referred to as: MGWF) device is a device for intercommunication between the CS network and the IMS network, and is used to be responsible for the conversion of signaling and media; IMS circuit switching Control function (IMS CS Control Function, hereinafter referred to as: ICCF) implementation device, also known as: IMS circuit switching control device, used to complete the adaptation between CS domain signaling and IMS domain SIP signaling, and as a user agent , realizing user service control and interaction in the IMS domain. Between the terminal and the ICCF device, the session control message is transmitted through a signaling channel other than the CS call, and the signaling channel is called an IMS circuit control channel (IMS CS Control Channel, hereinafter referred to as: ICCC); The CS call between devices implements the CS network bearer.

Voice Call Continuity (VCC) provides the ability to transfer voice between the CS domain and the IMS domain, and the Voice Call Continuity Application Server (VCC AS) has the anchor function , Domain Selection Function (Domain Selection Function, hereinafter referred to as: DSF) and domain switching function (Domain Transfer Function, hereinafter referred to as: DTF), are used to realize VCC and complete the mutual switching management between the user through the circuit switching domain and IP-CAN .

As shown in Figure 2, it is a flow chart of switching from the PS domain to the CS domain for the prior art 3GPP 23.206 protocol, which includes the following steps:

Step 101, when the terminal intends to switch from the PS domain to the CS domain, obtain from the VCC AS the IP Multimedia Routing Number (IP Multimedia RoutingNumber, hereinafter referred to as: IMRN) for routing the switching request from the CS to the VCC AS;

Step 102, the terminal initiates a call request to the VCC AS through the CS domain, and the call request is routed to the MSC in the CS domain, and the call request carries the IMRN and the VCC Domain Transfer Number (VCDomain Transfer Number, hereinafter referred to as: VDN). VDN is a number used to indicate that domain transfer needs to be initiated. This number is pre-statically allocated to the user identification device and stored in the user identification device. When domain switching is initiated from the CS domain, the VDN needs to be used as the called number;

Step 103, the MSC routes the call request to the MGCF device in the home IMS network according to the IMRN;

Step 104, the MGCF device converts the call request into IMS domain SIP signaling according to the IMRN and sends it to the CSCF;

Step 105, the CSCF forwards the call request to the VCC AS according to the IMRN;

Step 106: After the VCC AS receives the call request, it learns that the call request is a handover request through the VDN carried in it, and the terminal user requests to switch from the PS domain to the CS domain, and updates the signaling from the original session terminal to the ICCF device to CS the access part of the domain;

Step 107: VCC AS releases the original IP-CAN access part.

As shown in Figure 3, it is a flow chart of switching from the CS domain to the PS domain for the prior art 3GPP 23.206 protocol, which includes the following steps:

Step 201, the terminal initiates a call request to the VCC AS through the IP-CAN, and the call request is routed to the CSCF in the home IMS network, and the call request carries a VCC Domain Transfer URI (VCC Domain Transfer URI, hereinafter referred to as: VDI ). VDI is an identifier used to indicate that domain transfer needs to be initiated. The identifier is pre-statically assigned to the user identification device and stored in the user identification device. VDI is an identifier completely independent of VDN. When domain switching is initiated from the PS domain, VDI needs to be used as the called identity;

Step 202, the CSCF forwards the call request to the VCC AS according to the VDI;

Step 203: After the VCC AS receives the call request, it learns that the call request is a handover request through the VDI carried in it, and the terminal user requests to switch from the CS domain to the PS domain, and updates the access part in the original session to the IP-CAN access part;

Step 204, the VCC AS releases the original CS domain access part.

In the process of implementing the present invention, the inventors have found that at least the following problems exist in the handover method between the CS domain and the PS domain in the prior art:

1. Since the VDN and VDI are pre-statically configured in the user identification device, each user identification device stores and only stores a set of VDN and VDI. When the terminal performs domain switching, this VDN or VDI is used as the called number Initiate a call request to the VCC AS, so that when the terminal has sessions with multiple other terminals at the same time, the VCC AS cannot know which session the terminal needs to perform domain switching through the VDN or VDI, so that the correctness and effectiveness of the domain switching cannot be guaranteed In addition, because there is only one set of VDN/VDI, it cannot meet the needs of the terminal to communicate with multiple other terminals at the same time, which limits the diversified development of network services;

2. The functions of VDN and VDI are both used to indicate that the new call request is a domain transfer call request, and their functions are the same. Since traditional terminals can only carry numbers when initiating a call request in the CS domain, they cannot carry characters. Therefore, VDN and VDI are used to indicate that the new call request is a domain transfer call request, but for ICS terminals, ICCC can carry characters to send indication information to the ICCF device, so the functions of VDN and VDI can be fully integrated into the same identification. , the simultaneous allocation of VDN and VDI is redundant, wasting limited VDN and VDI resources;

3. During the handover process from the IMS domain to the CS domain, since the VDN does not have the routing function, the VCCAS needs to dynamically allocate the IMRN for this domain handover in advance, which takes a certain amount of time and reduces the efficiency of the domain handover; The request needs to have both VDN and IMRN numbers, which also wastes number resources;

4. A set of VDN/VDI is statically configured to each user's user identification device, but not every user needs to perform domain switching at any time. Therefore, static configuration of VDN/VDI not only unnecessarily occupies the user identification device The storage space of the network is also wasted.

Contents of the invention

The technical problem to be solved by the present invention is: use the session transfer identifier (Session TransferIdentifier, hereinafter referred to as: STID) that is dynamically allocated to the session by the server when the session is initiated, and identifies the session and its domain switching request, to perform domain switching on the multimedia session. Handover saves network number resources, ensures the correctness and effectiveness of domain switching, enables terminals to have conversations with multiple other terminals at the same time, and promotes the diversified development of network services.

According to one aspect of the present invention, a domain switching method is provided, comprising the following steps:

The call session control device receives the call request initiated by the terminal using the session transfer identifier as the called address, and routes the call request to the server. The session transfer identifier is pre-allocated by the server and is used to identify the session and the domain of the session. switch;

The server learns, according to the session transfer identifier in the call request, that the call request is used to perform domain switching on the session, and performs corresponding domain switching on the session.

According to another aspect of the present invention, a server is provided, including:

The first transceiver module is configured to receive a multimedia session request and a call request, obtain a session transfer identifier carried in the call request for domain switching of the multimedia session, and send the allocated session transfer identifier;

An analysis module, configured to analyze whether the multimedia session is a new session;

An allocation module, configured to allocate a session transfer identifier for identifying the session and domain switching of the session to the new session;

An identification module, configured to identify whether the call request carries a session transfer identifier;

The switching management module is used to implement the multimedia session continuity function, and switch the pair of multimedia sessions between the circuit switched domain and the packet switched domain when the call request carries a session transfer identifier.

According to another aspect of the present invention, a control device is provided, including:

The second transceiver module is used to forward the session transfer identifier, receive the session control signaling and the bearer control signaling, the call request session message and the call request bearer message, and send the call request session message and the call request bearer message for fusion A call request generated later, and a session request generated after the fusion of the session control signaling and the bearer control signaling;

a translation module, configured to implement translation between the session initiation protocol and the connection indication;

A fusion module, configured to fuse the session control signaling with the bearer control signaling to generate a session request, and fuse the call request session message with the call request bearer message to generate a call request.

In this embodiment of the present invention, when a session is initiated, the server assigns a STID that uniquely identifies the session and its domain switching to the terminal that initiates the session request. The handover session can effectively ensure the correctness and effectiveness of domain handover, and can meet the needs of the terminal to communicate with multiple other terminals at the same time, and can promote the diversified development of network services;

Use the same STID to indicate that the call request made by the terminal in the CS domain and the PS domain is a domain switching request. Compared with the implementation through a set of VDN/VDI in the prior art, it avoids number redundancy and saves limited network resources. resources; and, the STID can realize the routing of the domain switching request, without allocating IMRN for the domain switching request, which further saves network resources, and can shorten the domain switching time and improve the domain switching efficiency;

When the session is initiated, the server dynamically allocates the STID to the terminal that initiates the session request without pre-stored in the terminal's user identification module. Compared with the static configuration of VDN/VDI in the prior art, the storage space of the user identification device is saved.

The technical solutions of the present invention will be described in further detail below with reference to the accompanying drawings and embodiments.

Description of drawings

FIG. 1 is a structural diagram of an ICS in the prior art.

Fig. 2 is a flow chart of switching from the PS domain to the CS domain in the prior art 3GPP 23.206 protocol.

FIG. 3 is a flow chart of switching from the CS domain to the PS domain in the prior art 3GPP 23.206 protocol.

FIG. 4 is a flow chart of Embodiment 1 of the domain switching method of the present invention.

FIG. 5 is a flow chart of Embodiment 1 of dynamically allocating STIDs in the present invention.

FIG. 6 is a flow chart of Embodiment 2 of dynamically allocating STIDs in the present invention.

FIG. 7 is a flow chart of Embodiment 3 of dynamically allocating STIDs in the present invention.

FIG. 8 is a flow chart of Embodiment 4 of dynamically allocating STIDs in the present invention.

FIG. 9 is a flowchart of Embodiment 2 of the domain switching method of the present invention.

FIG. 10 is a flow chart of Embodiment 3 of the domain switching method of the present invention.

FIG. 11 is a schematic structural diagram of Embodiment 1 of the server of the present invention.

FIG. 12 is a schematic structural diagram of Embodiment 2 of the server of the present invention.

Fig. 13 is a schematic structural diagram of Embodiment 1 of the control device of the present invention.

Fig. 14 is a schematic structural diagram of Embodiment 2 of the control device of the present invention.

Detailed ways

In the embodiment of the present invention, when a session is initiated, the server dynamically assigns a STID that uniquely identifies the session and its domain switching to the terminal that initiates the session request, and implements session routing and domain switching according to the STID.

As shown in FIG. 4, it is a flow chart of Embodiment 1 of the domain switching method of the present invention, which includes the following steps:

In step 301, the terminal uses the session transfer identifier as the called address to initiate a call request to the CSCF device. The STID is assigned by the server when the session is initiated and is used to uniquely identify the session and its domain switching.

The server may be referred to as a domain transfer function (Domain Transfering Function, hereinafter referred to as: DTF) device, also known as: a domain transfer server, which can be used to provide multimedia continuity functions including voice, whether it is a master The calling or the called party terminated on the terminal must be anchored in DTF. DTF also appears as a back-to-back user agent (The Back-To-Back UserAgent, hereinafter referred to as: B2BUA) to terminate the signaling of the calling party. And initiate a new call signaling to the called party, and at the same time, DTF can assign and save STID to the user for domain transfer;

Step 302, the CSCF device routes the call request to the DTF according to the saved iFC;

In step 303, the DTF learns from the STID in the call request that the call request is a domain switch request for a session identified by the DTF, and performs a corresponding domain switch for the session.

In this embodiment of the present invention, when a session is initiated, the server assigns a STID that uniquely identifies the session and its domain switching to the terminal that initiates the session request, which can effectively ensure the correctness and effectiveness of the domain switching, and can meet the requirements for the terminal to communicate with multiple The session requirements of other terminals promote the diversified development of network services; only one identifier STID can be used to switch domains for sessions, saving limited network resources; there is no need to store STIDs in the terminal user identification module in advance, saving users Identifies the storage space of the device.

Before the domain switching shown in Figure 4, the DTF needs to dynamically allocate the STID to the terminal. The STID can be composed of numbers and/or character strings. For example: when the terminal user is a CS service user, a digital STID can be assigned to the user, such as: telephone number (hereinafter referred to as: TEL URI); when the terminal user is an ICS user or PS service users, you can assign character STIDs to users, for example: SIP URI.

As shown in FIG. 5, it is a flow chart of Embodiment 1 of dynamically assigning STIDs in the present invention. The terminal initiates a session request and performs signaling transmission through the PS domain. The flow of this embodiment includes the following steps:

Step 401 , the calling party terminal initiates a multimedia session request to the counterpart terminal, ie, the called party terminal, to the CSCF device in the PS domain, requesting to initiate a multimedia session.

Step 402, the CSCF device forwards the session request to the DTF according to the saved iFC;

In step 403, the DTF judges whether the session is a new session request for initiating a new session. If it is a new session request, execute step 404; otherwise, the DTF does not execute the subsequent process of allocating STID to the session.

The specific judging method can be: judge whether the called address in the session request is STID or the user identification or URI of the opposite terminal, if it is the user identification or URI of the other terminal, then identify that the session request is a new session request, if it is STID , it means that the session request is not a new session request.

Step 404, DTF distributes STID used to identify the session and its subsequent domain switching to the calling party terminal, and at the same time, DTF establishes and stores the corresponding relationship information between the STID and the session identifier identified by it; in addition, DTF according to the session request forward the session request to the other terminal.

When DTF allocates STID to the calling party terminal, it first judges the type of terminal user. If the terminal user is a CS service user, it can allocate a digital STID to the user, for example: TEL URI; if the terminal user is an ICS user or PS service user, it can Assign a STID in character form to the user, for example: SIP URI.

Step 405: After receiving the 200 OK response message returned by the other terminal to the calling party terminal, the DTF forwards the STID and the 200 OK response message to the calling party terminal through the CSCF device.

Specifically, the DTF can use the 200 OK response message returned by the other party terminal, or use other response messages, such as: 180 message, 183 message or invitation (Invite) message sent by other user terminals, etc., to send the STID to the calling party terminal .

The STID can be carried by the Contact header of SIP, and an instance of the Contact after writing the STID is: Contact:<STID>;isSTID.

Step 406, the calling party terminal stores the STID. If the calling party terminal receives the STID, it performs domain switching on the session identified by the STID, or the STID may not exist.

As shown in FIG. 6, it is a flow chart of the second embodiment of dynamically allocating STIDs in the present invention. The terminal terminates the session request and performs signaling transmission through the PS domain. The flow of this embodiment includes the following steps:

In step 501, the other party terminal initiates a session request to the called party terminal in the PS domain to the CSCF device through an Invite message.

Step 502, the CSCF forwards the session request to the DTF according to the saved iFC.

In step 503, the DTF judges whether the session is a new session request for initiating a new session. If it is a new session request, execute step 504; otherwise, the DTF does not execute the subsequent process of allocating STID to the session. The specific judging method can be the same as step 404.

In step 504, the DTF assigns to the session a STID for identifying the session and its subsequent domain switching, and at the same time, the DTF establishes and stores the corresponding relationship information between the STID and the session ID identified.

In step 505, the DTF forwards the Invite message and the STID to the called party terminal through the CSCF device. Specifically, the DTF may use the Invite message sent by the other party terminal, or use other response messages, such as: 180 message, 183 message or 200 Ok response message, etc., to send the STID to the calling party terminal.

Step 506, the called party terminal stores the STID. If the called party terminal receives the STID, it performs domain switching on the session identified by the STID, or the STID may not exist.

As shown in FIG. 7, it is a flow chart of Embodiment 3 of dynamically assigning STIDs in the present invention. The ICS user terminal initiates a session request and performs signaling transmission through the CS domain. The flow of this embodiment includes the following steps:

Step 601 , the calling party terminal in the CS domain initiates a call request to the ICCF device for establishing a CS domain bearer path with the ICCF, and forwards the call request to the MGCF device through the MSC.

In step 602, the MGCF device translates the CS domain signaling into SIP Invite signaling and sends it to the ICCF device. Through steps 601 to 602, a bearer control signaling channel is established.

Step 603, the calling party terminal sends the media information of the other party terminal to the ICCF device with Unstructured Supplementary Service Data (Unstructured Supplementary Service Data, hereinafter referred to as: USSD) through the ICCC for session control. This step generates session control signaling.

In step 604, the ICCF device fuses the bearer control signaling and the session control signaling information, generates a new Invite message to be sent to the opposite terminal, that is, a session request, and sends it to the CSCF device.

Step 605, the CSCF device forwards the session request to the DTF according to the saved iFC;

In step 606, the DTF judges whether the session is a new session request for initiating a new session. If it is a new session request, execute step 607; otherwise, the DTF does not execute the subsequent process of allocating STID to the session.

In step 607, the DTF distributes the STID used to identify the session and its subsequent domain switching to the calling party terminal. At the same time, the DTF establishes and stores the corresponding relationship information between the STID and the session ID identified by it; in addition, the DTF according to the session request forward the Invite message to the other terminal.

Step 608: After receiving the 200 OK response message returned by the other terminal to the calling party terminal, the DTF forwards the STID and the 200 OK response message to the CSCF device.

Specifically, the DTF may use the 200 OK response message returned by the counterpart terminal, or use other response messages, such as: 180 message, 183 message or Invite message sent by other user terminals, to send the STID to the CSCF device.

Step 609, the CSCF device forwards the STID and the 200 OK response message to the ICCF device.

In step 610, the ICCF device translates the STID and 200 OK response message from the SIP message into a USSD message, and sends it to the calling party terminal through the MSC.

Step 611, ICCF generates a new 200 OK message according to the received 200 OK message, and sends it to the MGCF device.

Step 612, the MGCF device parses out the media information of the other terminal from the new 200 OK message, and generates a connection prompt in the CS domain, and sends the connection indication to the calling party terminal through the MSC. Steps 611 to 612 are executed simultaneously with step 610 .

Step 613, the calling party terminal stores the STID. If the calling party terminal receives the STID, it performs domain switching on the session identified by the STID, or the STID may not exist.

In step 608 of the embodiment shown in Fig. 7, DTF writes STID into the 200 OK response message, or sends it to the CSCF device in other response messages, then in step 610, the ICCF device needs to implement SIP signaling to the CS domain The translation of the signaling, that is: parse out the STID value from the Contact header, write it into the USSD, and then send it to the calling party terminal through the MSC.

As shown in FIG. 8 , it is a flow chart of the fourth embodiment of dynamically allocating STIDs in the present invention. The ICS user terminal terminates the session request and performs signaling transmission through the CS domain. The flow of this embodiment includes the following steps:

In step 701, the counterparty terminal initiates a session request Invite message to the called party terminal in the PS domain to the CSCF device through the Invite message.

In step 702, the CSCF forwards the session request to the DTF according to the stored iFC.

In step 703, the DTF judges whether the session is a new session request for initiating a new session. If it is a new session request, execute step 704; otherwise, the DTF does not execute the subsequent process of allocating STID to the session. The specific judging method can be the same as step 404.

In step 704, the DTF assigns to the session a STID for identifying the session and its subsequent domain switching, and at the same time, the DTF establishes and stores the corresponding relationship information between the STID and the session ID identified.

In step 705, the DTF forwards the Invite message and the STID to the ICCF through the CSCF. Specifically, the DTF can use the Invite message sent by the opposite terminal, or use other response messages, such as: 180 message, 183 message, 200 Ok response message or Invite message sent by other terminals, etc., to send the STID to the ICCF device through the CSCF device .

In step 706, the ICCF device translates the SIP message into a USSD message and sends it to the calling party terminal through the MSC.

Step 707, ICCF generates a new Invite message according to the received Invite message, and sends it to the MGCF device.

In step 708, the MGCF device parses out the media information of the other terminal from the new Invite message, generates a call request signaling in the CS domain, and sends the call request signaling in the CS domain to the calling party terminal through the MSC. Steps 707 to 708 are executed simultaneously with step 706.

Step 709, the calling party terminal stores the STID. If the calling party terminal receives the STID, it performs domain switching on the session identified by the STID, or the STID may not exist.

In step 705 of the embodiment shown in Figure 8, the DTF writes the STID into the Invite message, or sends it to the ICCF device in other response messages, then in step 706, the ICCF device needs to parse the STID value from the Contact header, and After it is written into the USSD, it is sent to the calling party terminal through the MSC.

After the DTF dynamically allocates the STID to the terminal, the terminal can use the STID to initiate domain switching of the session identified by the STID.

In the above-mentioned embodiments of dynamically allocating STIDs in the present invention, specifically, in step 404, or in step 504, or in step 607, or in step 704, when the server allocates an STID to a session, it can first information to determine whether the terminal user is a CS service user or an ICS user. If it is a CS service user, the STID in digital form (for example: TEL URI) can be assigned to the session; Allocate the STID in the form of a string (for example: SIP URI), so that the limited digital number network resources can be saved.

As shown in FIG. 9, it is a flow chart of Embodiment 2 of the domain switching method of the present invention. This embodiment switches the session from the PS domain to the CS domain, which includes the following steps:

Step 801: In the CS domain of the ICS, the local terminal initiates a call request session message to the counterpart terminal to the ICCF device through the USSD of the ICCC via the MSC, and the call request session message includes the STID.

In step 802, the ICCF device parses and obtains the STID in the USSD.

In step 803, the own terminal sends a call request bearer message to the ICCF device through the MSC, and the call request bearer message includes the media information of the own terminal, such as: terminal coding type, address, port number and other information. In addition, step 803 may also be executed prior to steps 801 to 802, and may also be executed simultaneously with steps 801 to 802.

In step 804, the ICCF device fuses the call request session message sent in step 802 with the call request bearer message sent in step 803, generates a call request Invite message requesting to initiate a call, and writes the STID into the call request, specifically, It can be written into the request universal resource identifier (hereinafter referred to as: Request URI) message header of the Invite and sent to the CSCF device.

Step 805, the ICCF device sends the call request Invite message written in the STID to the CSCF device.

Step 806, the CSCF device forwards the call request to the DTF according to the stored iFC.

Step 807, the DTF recognizes that the call request is a domain switching request by the STID carried in the Request URI message header of the Invite, generates and sends an update invitation (re-Invite) message to the other party's terminal, and the re-Invite message includes this party's Terminal media information.

Step 808, the other party's terminal returns a 200 OK response message to the DTF, which includes the media information of the other party's terminal in the 200 OK response message, such as: the encoding type, address, port number and other information of the other party's terminal.

Step 809: After receiving the 200 OK response message returned by the other terminal to the own terminal, the DTF forwards the media information of the other terminal to the ICCF device through the CSCF device.

Step 810, the ICCF device generates a new 200 OK message and sends it to the MGCF device according to the received 200 OK message.

Step 811, the MGCF device parses out the media information of the other terminal from the new 200 OK message, and at the same time, translates the SIP message into a CS domain connection indication, and sends the connection indication to the local terminal through the MSC.

Step 812: After receiving the media information of the counterpart terminal, the local terminal establishes a CS bearer with the MGW device, and the MGW establishes a PS bearer with the counterpart terminal. Release the original PS bearer. Specifically, the original PS bearer may be released by the local terminal or the MWG.

As shown in FIG. 10 , it is a flowchart of Embodiment 3 of the domain switching method of the present invention. This embodiment switches the session from the CS domain to the PS domain, which includes the following steps:

In step 901, the own terminal uses the STID as the called address, and initiates a SIP call request Invite message to the CSCF device in the PS domain. The Invite message includes the media information of the own terminal, such as: the encoding type, IP address, Port number and other information.

Step 902, the CSCF device forwards the call request to the DTF according to the saved iFC.

In step 903, the DTF recognizes that the call request is a domain switching request from the STID in the Invite message, generates and sends a re-Invite message to the opposite terminal, and the re-Invite message includes the media information of the own terminal.

Step 904, the other party's terminal returns a 200 OK response message to the DTF, which includes the media information of the other party's terminal in the 200 OK response message, such as: the encoding type, IP address, port number and other information of the other party's terminal.

Step 905, after DTF receives the 200 OK response message returned by the opposite terminal to the own terminal, forwards the media information of the opposite terminal to the own terminal through the CSCF device.

Step 906: After receiving the media information of the counterpart terminal, the local terminal establishes a PS bearer with the counterpart terminal, and releases the original CS bearer with the MGW. Specifically, the original CS bearer between the own terminal and the MGW may be released by the own terminal or the MGW.

As shown in FIG. 11 , it is a schematic structural diagram of the first embodiment of the server of the present invention. The server of this embodiment includes a first transceiver module, an analysis module, and an allocation module connected in sequence, and an identification module connected with the first transceiver module, and connected with the first transceiver module. A handover management module to which the identification module is connected. Wherein, the first transceiver module is used to receive a multimedia session request and a call request, obtain the STID carried in the call request for domain switching of the multimedia session and send it to the identification module, and send the STID assigned by the allocation module to the terminal; analyze The module is used to analyze whether the multimedia session is a new session according to whether the multimedia session request carries STID; the allocation module is used to assign the STID used to identify the session and its domain switching to the new session when the multimedia session request is a new session and send to the first transceiver module. Specifically, the allocation module may select the type of STID allocated to the session according to whether the terminal user is a CS service user or an ICS user, for example: when the terminal user is a CS service user, the STID in digital form is allocated to the user; when the terminal user is an ICS user , the STID in character form can be assigned to the user; the identification module is used to identify whether the call request carries the STID according to whether the first transceiver module obtains the STID from the call request; the switching management module is used to realize the multimedia session continuity function , when the STID is carried in the call request, the multimedia session is switched between the CS domain and the PS domain according to the call request.

As shown in Figure 12, it is a schematic structural diagram of the second embodiment of the server of the present invention. The server of the embodiment shown in Figure 11 may also include a first writing module, which is arranged between the distribution module and the first transceiver module, respectively connected to the distribution modules With the first transceiver module, it is used to write the STID assigned to the new session into the Request URI message header of SIP and send it to the first transceiver module; the transceiver module is used to send the Request URI message written into STID.

Referring to FIG. 12 again, the server in the above embodiments of the present invention may further include a first storage module connected to the distribution module for storing the STID.

Further, the server in the above embodiments of the present invention may further include a second storage module connected to the handover management module for storing the correspondence information between the STID and the multimedia session identifier, so that the handover management module can, according to the correspondence information, The multimedia session that requires domain switching is learned from the STID, as shown in FIG. 12 .

The server shown in FIG. 11 and FIG. 12 can be used as a DTF to implement the above-mentioned STID allocation and domain switching process embodiment of the present invention.

As shown in FIG. 13 , it is a schematic structural diagram of Embodiment 1 of the control device of the present invention. The control device includes a translation module, a second transceiver module and a fusion module connected in sequence. Wherein, the second transceiver module is used for forwarding STID, receiving session control signaling and bearer control signaling, call request session message and call request bearer message, and sending a call request generated by fusing the call request session message and call request bearer message , and send a session request generated by the fusion of session control signaling and bearer control signaling; the translation module is used to translate the STID from a SIP message into a USSD message; the fusion module is used to fuse and generate the session control signaling and bearer control signaling A session request, and generating a call request by fusing the call request session message and the call request bearer message.

Referring to FIG. 14 , it is a schematic structural diagram of Embodiment 2 of the control device of the present invention. The control device of the embodiment shown in FIG. The transceiver module and the fusion module are connected, and are used to write the STID into the Request URI message header of the call request generated after fusion and send it to the second transceiver module.

Further, the control device in the above-mentioned embodiments of the present invention may further include an analysis module, which is arranged between the second transceiver module and the translation module, and is respectively connected to the second transceiver module and the translation module, and is used to receive information received from the second transceiver module. The STID is parsed from the SIP URI message header and sent to the translation module.

In the present invention, when a session is initiated, the server assigns a STID that uniquely identifies the session and its domain switching to the terminal that initiates the session request. When there are multiple sessions between the terminal and other terminals, the server can also prepare to know the domain switching that needs to be performed according to the STID. Session can effectively ensure the correctness and effectiveness of domain switching, and can meet the needs of a terminal to communicate with multiple other terminals at the same time, and can promote the diversified development of network services;

Use the same STID to indicate that the call request made by the terminal in the CS domain and the PS domain is a domain switching request. Compared with the implementation through a set of VDN/VDI in the prior art, it avoids number redundancy and saves limited network resources. resources; and, the STID can realize the routing of the domain switching request, without allocating IMRN for the domain switching request, which further saves network resources, and can shorten the domain switching time and improve the domain switching efficiency;

When the session is initiated, the server dynamically allocates the STID to the terminal that initiates the session request without pre-stored in the terminal's user identification module. Compared with the static configuration of VDN/VDI in the prior art, the storage space of the user identification device is saved.

Finally, it should be noted that: the above examples are only used to illustrate the technical solutions of the present invention, rather than limiting the understanding of the present invention. Although the present invention has been described in detail with reference to the above-mentioned preferred embodiments, those skilled in the art should understand that: it can still modify or replace the technical solution of the present invention, and such modification or replacement does not depart from the technology of the present invention. The spirit and scope of the programme.

Claims (7)

1. A domain switching method, characterized in that, comprising: The server receives the session request forwarded by the call session control device; When the session request is a session request for initiating a new session, the server dynamically allocates a session transfer identifier for identifying the session and its subsequent domain switching to the session requested by the session request; When the server receives the call request carrying the session transfer identifier forwarded by the call session control device, it recognizes that the call request is a domain switching request according to the session transfer identifier, and performs Domain switching. 2. The method according to claim 1, wherein the session request is sent by the terminal to the call session control device, and the session request is used to request to initiate a session to the opposite terminal; When the session request is a session request for initiating a new session, the server dynamically assigning a session transfer identifier for identifying the session and its subsequent domain switching to the session requested by the session request includes: When the server recognizes that the session request is used to initiate a new session, assign the session transfer identifier to the session requested by the session request and store the session transfer identifier, according to the counterparty terminal in the session request send the session request to the counterparty terminal, and send the session transfer identifier to the terminal after receiving a response message returned by the counterparty terminal. 3. The method according to claim 2, wherein the session request is sent to the call session control device by the counterparty terminal, and the session request is used to request to initiate a session to the terminal; When the session request is a session request for initiating a new session, the server dynamically assigning a session transfer identifier for identifying the session and its subsequent domain switching to the session requested by the session request includes: When the server recognizes that the session request is used to initiate a new session, assign the session transfer identifier to the session requested by the session request and store the session transfer identifier, and according to the terminal in the session request A user identifier, sending the session transfer identifier to the terminal. 4. A domain switching method, characterized in that, comprising: The terminal sends a session request to the call session control device, so that the call session control device forwards the session request to the server, so that the server sends the session request to the call session control device when the session request is a session request for initiating a new session The session requested by the session request dynamically allocates a session transfer identifier used to identify the session and its subsequent domain switching; The terminal sends the call request carrying the session transfer identifier to the call session control device, so that the call session control device forwards the call request to the server, so that the server recognizes the call request according to the session transfer identifier For a domain switching request, domain switching is performed on the session identified by the session transfer identifier. 5. A server, characterized in that, comprising: It is used to receive the session request forwarded by the call session control device, and when the session request is a session request for initiating a new session, dynamically assign the session request for identifying the session and its subsequent domain to the session requested by the session request the module identified by the switched session transfer; When the server receives the call request sent by the terminal and forwarded by the call session control device and carries the session transfer identifier, recognizes that the call request is a domain switching request according to the session transfer identifier, and transfers the session Module that identifies the domain switch for the identified session. 6. The server according to claim 5, further comprising at least one of the following modules: When identifying that the session request is used to initiate a new session, assigning the session transfer identifier to the session requested by the session request and storing the session transfer identifier, according to the user identifier of the opposite terminal in the session request , sending the session request to the counterparty terminal, and after receiving a response message returned by the counterparty terminal, sending the session transfer identifier to a module of the terminal; or, When identifying that the session request is used to initiate a new session, assigning the session transfer identifier to the session requested by the session request and storing the session transfer identifier, and according to the terminal user in the session request ID, sending the session transfer ID to the module of the terminal. 7. A terminal, characterized in that, comprising: It is used to send a session request to the call session control device, so that the call session control device forwards the session request to the server, so that the server sends the session request to the call session control device when the session request is a session request for initiating a new session The session requested by the session request dynamically allocates a module for identifying the session and its subsequent domain switching session transfer identifier; is used to send a call request carrying the session transfer identifier to a call session control device, so that the call session control device forwards the call request to a server, so that the server can identify the call request according to the session transfer identifier The request is a domain switching request, and the module performs domain switching on the session identified by the session transfer identifier.

Images