CN101030964A - Session controller and controlling method - Google Patents

Abstract

The present invention provides a call session control device and method. The method includes the following steps: Step 702: Trigger a session request to one or more application servers according to the initial filtering rules in the user subscription data, and store all The functional entity and session information related to the session request; and step 704, when releasing the session, release the session according to the stored session information related to the session request. By using the session control device and method provided by the present invention, after receiving the release request information from the application server, it can be judged whether it is necessary to release all triggered sessions with the application server, and if necessary, release all triggered sessions with the application server. The session of the server meets the requirements in practical applications.

Description

Session control device and method

technical field

The present invention relates to a communication device and method, in particular to a session control device and method in a network.

Background technique

Session Initiation Protocol (SIP for short) is a VoIP standard released by the Internet Engineering Task Force (IETF) in March 1999. The Session Initiation Protocol regards telephony as an important application of the Internet (Internet), increases the requirements for telephony signaling and Quality of Service (QoS), and has unique user addressing and positioning functions. The actual role of the session initiation protocol has been far beyond the application of VoIP recently. Session Initiation Protocol is a telephony signaling protocol used to initiate sessions, which can control the establishment and termination of multimedia sessions participated by multiple participants, and can dynamically adjust and modify session attributes, such as session bandwidth requirements, transmission media types (voice, video, data, etc.), media codec format, support for multicast and unicast, etc. Therefore, the Session Initiation Protocol is conducive to the development of value-added services for various applications in combination with the Internet.

The IP Multimedia Core Network Subsystem (IP Multimedia Subsystem, referred to as IMS) is a subsystem superimposed on the packet network by the 3rd Generation Partnership Project ( ^3rd Generation Partnership Project, referred to as 3GPP), using the packet domain as its control signaling and For the bearer channel of media transmission, the Session Initiation Protocol is introduced as the service control protocol. By utilizing the features of the Session Initiation Protocol, which are simple, easy to expand, and convenient for media combination, the service control and bearer control are separated to provide rich multimedia services. The IP multimedia core network subsystem architecture is shown in Figure 1. The main functional entities of the IP multimedia core network subsystem architecture include: Call Session Control Function (CSCF) for controlling functions such as user registration and session control ) 102, Home Subscriber Server (HSS for short) 104 for centralized management of user subscription data, application server (Application Server, AS for short) for providing various business logic control functions, and PSTN/CS domain selection The interrupt gateway control function (BGCF) entity 106 of the network where the interruption occurs, the media gateway control function (MediaGate Control Function, MGCF for short) entity 108 for controlling the intercommunication between the media gateway and the circuit domain/PSTN/softswitch network, and the entity 108 for the control box Multimedia Resource Function Controller (MRFC) 110, Multimedia Resource Function Processor (MRFP) 112, Proxy SCSF (P-CSCF) 114 for processing media stream resources in the packet domain, and subscription for providing the query function of the user subscription home user server Locator Function (SLF) entity 116 . Among them, the Cx interface supports the acquisition of route information between the call session control function entity and the home user server, and uses the Diameter protocol to transmit information between the user and the home user server through the call session control function entity tunnel. The Dx interface is the interface between the call session control functional entity and the subscription locator functional entity, and is used to obtain the address of the home subscriber server that maintains a subscription for a given subscriber. The Gm interface mainly transmits the processes related to registration, user service control, and authentication between the user and the call session control function entity. The Mg interface is an interface between the media gateway control function entity and the call session control function entity, and is based on the 3GPP session initiation protocol. The Mj interface allows the interrupt gateway control function entity to forward the session signaling media gateway control function entity, so as to interact with the PSTN (Public Switched Telephone Network, public switched telephone network), based on the session initiation protocol. The Mk interface allows the call session control function entity to forward session signaling to another interrupt gateway control function entity, based on the session initiation protocol. The Mm interface is an IP interface between the call session control function entity and the IP network, and is used for service control of IP multimedia services, for example, receiving a call request from a VOIP call control server on the IP network or a terminal on the IP network. The Mp interface allows the multimedia resource function controller to control the media stream resources provided by the MRF, fully complying with the H.248 standard and adding 3GPP extensions. The Mr interface allows interaction between the call session control functional entity and the multimedia resource function controller, based on the 3GPP session initiation protocol.

The IP multimedia core network subsystem network uses the session initiation protocol to register, so that users can access the IP multimedia core network subsystem network. During the user registration process, the IP multimedia core network subsystem network authenticates the user's private identity and establishes a secure channel in the access domain. If the user registration is successful, the S-CSCF (Serving-Call Session Control Function, Serving-Call Session Control Function) in the home domain ) entity 102 establishes the relationship between the user's public identity and the user's current location, and the S-CSCF retrieves the user's subscription data from the home user server 104 at the same time.

The IP multimedia core network subsystem subscription downloaded by the S-CSCF may contain one or more service profiles. The service description includes information such as public identification, core network service authorization, initial filter rule set, and shared initial filter rule set. The initial filtering rules are a set of user service parameters. A business description can contain a list of multiple initial filter rules.

A trigger rule includes the following information: the address of the application server to be triggered, the priority of the trigger rule, the trigger point, default processing, and optional service information.

According to these parameters, the S-CSCF follows the priority of the trigger rule from high to low, and matches the trigger information in the trigger point with the request message received from the Mw interface. If the match is successful, the S-CSCF sends the relevant request to the application server matching the trigger rule through the ISC interface.

If a registration message is received, the S-CSCF sends a third-party registration message to each application server matching the trigger rule.

If it receives another request, the S-CSCF adds special identification and routing information to the message sent to each application server that matches the trigger rule. After processing the business logic, the application server returns the request message to the S-CSCF according to the routing information. The S-CSCF will continue to match the low-priority trigger rules until all the trigger rules in the service description are checked.

In the IP multimedia core network subsystem, the S-CSCF and the application server provide services interactively through the ISC interface, and its architecture is shown in Figure 2. Among them, the application server can be of the following types:

1. Session Initiation Protocol Application Server (SIP AS) 202: can provide certain services, and can influence a Session Initiation Protocol session based on business.

2. IP Multimedia Services Switching Function (IP Multimedia Services Switching Function, referred to as IM SSF) 204: This is a special type of application server, which is used to be responsible for the characteristics of the CAMEL (Service Network Enhanced Logic) network (for example: triggering DP points, Finite state machine for CAMEL service exchange, etc.), which provides a CAP interface.

3. Open Services Access-Service Capability Server (OSA-SCS for short) 206: it provides an interface for the application server (OSA AS) 208 of Open Services Access-Service, which provides a third-party secure access It provides a standard way to enter the IM subsystem. The OSA reference architecture defines an application server entity with open service access, which provides a logical execution environment for client applications through the OSA API (Application Program Interface, application program interface). The definition of the application server for open service access here is different from the definition of the application server providing services for the IP multimedia core network subsystem above, that is, the application server of the IP multimedia core network subsystem is through the internal service control interface (Internal Service Control Interface) , referred to as the ISC interface) interacts with the S-CSCF.

All application servers (including IP Multimedia Services Switching Function (IM-SSF) and service capability servers for open service access) execute a session initiation protocol application server behavior on the ISC interface.

Application servers can use the following models to process session initiation protocol requests.

1. The application server acts as the terminal user agent (User Agent, UA for short)

As shown in FIG. 3, the application server 302 performs a terminating user agent or redirection server role. Under this mode of operation, S-CSCF 304 passes the received session initiation protocol request to application server 302, and application server 302 executes the role of termination user agent or redirection server defined in RFC 3261.

2. The application server acts as a PROXY (proxy)

As shown in FIG. 4, the application server 302 performs the role of a session initiation protocol proxy. Under this mode of operation, S-CSCF 304 proxies the received session initiation protocol request to application server 302, and application server 302 executes the PROXY role defined in IETF RFC 3261, and proxies the request back to S-CSCF 304, and then S- CSCF 304 proxies the message to the destination. During the proxy operation, the application server 302 can add, delete and modify the content of the header field in the SIP request according to the rules of PROXY described in IETF RFC 3261.

Under this model, the application server 302 can also obtain all contact addresses of the user equipment by subscribing to the registration event of the user equipment (UE) at the S-CSCF 304, and initiate a fork (Forking) to the user equipment. Forking is a processing method for Proxy to initiate sessions to multiple terminals serially or in parallel.

3. The application server 302 acts as a Back-to-Back User Agent (B2BUA for short)

As shown in FIG. 5, the application server 302 acts as a routing back-to-back user agent. The application server receives a request from the S-CSCF, terminates the request, and generates a new request based on the received request.

In this mode of operation, the received SIP request is proxied by the S-CSCF 304 to the application server, the application server 302 generates a new SIP request for a different SIP session and sends it to the S-CSCF, and then The S-CSF proxies the request to the destination. Under this model, the Application Server 302 performs the role of a back-to-back user agent for multiple Session Initiation Protocol sessions as described in IETFRFC 3261.

Under this model, the application server 302 can perform forwarding processing according to service needs, or initiate a request for multiple IP Multimedia Public Identity (IP Multimedia Public Identity, IMPU for short).

According to 3GPP TS 24.229, the existing session processing method is as follows:

1. The request processing process initiated by the service user:

For a request initiated by a served user, when the S-CSCF receives an initial request for a dialog or a request for an independent session from the serving user or PSI, before forwarding the request, the S-CSCF shall:

1. Check whether the original dialog identifier previously placed by the S-CSCF in the Route header field exists in the top item of the Route header field of the incoming request.

a) If it does not exist, it means that this request is the first time to visit this S-CSCF;

b) If present, it indicates the association with an existing dialog, which was sent from the application server in response to a previously sent request.

2. Take out the initial filtering rule corresponding to the public identity in the P-Asserted-Identity header field in the request message. In order of priority, check whether this initial request matches the next unexecuted initial filter rule. If it matches, the S-CSCF inserts the AS URI to be contacted after its own Uniform Resource Identifier (URI) in the highest item in the Route header field, and forwards the request to that application server. If there is no match, the S-CSCF then checks the matching of the remaining filter rules with lower priority until all the initial filter rules are checked, and then processes the destination address of the request message; before processing the destination address, the S-CSCF may contact a or multiple application servers;

3. If the highest item in the Route header field does not have the original dialog identifier, the S-CSCF saves the icid parameter received from the P-Charging-Vector header field and retains the icid parameter in the P-Charging-Vector header field. Optionally, the S-CSCF may generate a new globally unique icid and insert this new value into the icid parameter of the P-Charging-Vector header field when forwarding this message. If the S-CSCF generates a new icid, it will be responsible for maintaining these two icid values in subsequent communications;

4. When the S-CSCF processes the destination address, if it exists, use the URI in the highest Route header field to determine the destination address, otherwise it will use the Request-URI;

5. If the request is an INVITE request, the S-CSC saves the values of the Contact, Cseq and Record-Route header fields received from the request so that the S-CSCF can release the dialog when necessary.

2. The request processing process terminated by the service user:

When the S-CSCF receives an initial request for a session or a request for an independent transaction addressed to a statically prefabricated PSI or a registered service user, before forwarding the request, the S-CSCF shall:

1. Check whether the original dialog identifier previously placed by the S-CSCF in the Route header field exists in the top item of the Route header field of the incoming request.

a) If it does not exist, it means that this request is the first visit to this S-CSCF, at this time S-CSCF will save the Request-URI of the request;

b) If present, it indicates the association with an existing dialog, which was sent from the application server in response to a previously sent request.

2. If the original dialog identifier in the Route header field exists, check whether the Request-URI is equal to the saved Request-URI. If there is no match, the S-CSCF shall:

a) if the request is an INVITE request, save the Contact, Cseq and Record-Route header fields received from the request so that the S-CSCF can release the dialog if necessary; and

b) Forward the request based on the Request-URI and skip the following steps;

3. Take out the initial filtering rule corresponding to the public identifier in the Request-URI header field in the request message. In order of priority, check whether this initial request matches the next unexecuted initial filter rule. If it matches, the S-CSCF inserts the URI of the AS to be contacted after its own URI in the highest item in the Route header field, and forwards the request to that application server. If there is no match, the S-CSCF then checks the matching of the remaining filter rules with lower priority until all the initial filter rules are checked, and then processes the destination address of the request message; before processing the destination address, the S-CSCF may contact a or multiple application servers;

4. If the highest item in the Route header field does not have the original dialog identifier, the S-CSCF saves the icid parameter received from the P-Charging-Vector header field and retains the icid parameter in the P-Charging-Vector header field.

5. If the request is an INVITE request, the S-CSC saves the values of the Contact, Cseq and Record-Route header fields received from the request so that the S-CSCF can release the dialog when necessary.

3. The service user releases the session processing process:

When the S-CSCF internally instructs session release (for example, registration timer expires, management logout user, etc.), S-CSCF sends CANCEL message according to RFC3261 to cancel the related dialogue being established, or sends BYE to release the established session.

The method of sending BYE is as follows:

1. Construct the first BYE request for the called user according to the saved dialogue information;

2. Construct a second BYE request for the calling user according to the saved dialogue information;

3. If the S-CSCF is on the calling side, treat the first BYE message as a message received from the calling user, send it to the service control, and forward it to the called user according to the result.

4. If the S-CSCF is on the calling side, send the second BYE message directly to the calling user.

5. If the S-CSCF is on the called side, send the first BYE message directly to the called user.

6. If the S-CSCF is on the called side, process the second BYE message as a message received from the called user, send it to the service control, and further forward it to the calling user according to the result.

There are following problems in the prior art:

1. When the network logs out the user, the S-CSCF cannot release all the sessions currently controlled by the user.

2. After receiving the release message from the application server, the S-CSCF cannot determine whether to release all triggered application server sessions controlled by the service.

For example, the service control of a session request is triggered to three application servers in the S-CSCF, wherein the first application server is an IP multimedia service switching function entity, and the user has a service that triggers a new session according to the session release message; the second application server The first application server is IMS-GWF (online charging gateway), which needs to release all the conversations of the current service control at any time according to the user's charging information; the third is an application server with a back-to-back user agent role, and the user has called Take control of the business. After all dialogs for business control are established:

If the home user server manages the logout user, the S-CSCF releases the session according to the existing standard, but all sessions cannot be released due to the business logic of the application server.

If the online charging gateway IMS-GWF needs to release the session due to charging reasons, it sends a BYE message to both sides of the session. According to the existing standard description, S-CSCF sends the release message BYE to the first application server and the third application server, then the first application server and the third application server continue to execute the business according to their own business logic, and cannot released. Obviously, this cannot meet the requirement of IMS-GWF to release all dialogues controlled by the current business.

Contents of the invention

The purpose of the present invention is to provide a call session control device and method, which can release all dialog requirements of current service control.

The device includes: a session establishment module, which triggers a session request to one or more application servers according to the initial filter rule in the user subscription data, and stores all session information related to the session request passing through the call session control function entity; and session release A module configured to release the session according to the stored session information related to the session request when the session is released.

The session release module includes: a first release request construction unit, configured to construct a first release request for each dialog server (UAS), and send the first release request to the dialog server along the path established by the dialog; and The second release request construction unit is configured to construct a second release request for each dialog client (UAC), and send the second release request to the dialog client along the path established by the dialog.

The dialog information is necessary information for releasing the dialog, and the dialog information includes: Call-ID header field, From header field, To header field, Contact header field, Cseq header field, and Record-Route header field in the dialog request.

The method includes: step 702, triggering the session request to one or more application servers according to the initial filter rule in the user subscription data, and storing all session information related to the session request passing through the call session control function entity; and step 704, When the session is released, the session is released according to all stored session information related to the session request.

The dialog information is necessary information for releasing the dialog, and the dialog information includes: Call-ID header field, From header field, To header field, Contact header field, Cseq header field, and Record-Route header field in the dialog request.

Step 704 includes: when the CSCF entity itself or an external entity instructs to release the session, release all sessions according to all stored session information related to the session request.

Releasing all dialogs according to all dialog information related to the session request stored includes: constructing a first release request for each dialog's server (UAS), and sending the path established by the dialog to the dialog's server; and for each dialog The client (UAC) of the dialog constructs a second release request, and sends the path established by the dialog to the client of the dialog.

Step 704 includes: when the application server releases the session, release all or part of the sessions according to the stored session information related to the session request and the release processing instruction.

Wherein, the release processing instruction is: the default processing instruction in the initial filter rule corresponding to the application server in the user subscription data; the release processing instruction added in the initial filter rule of the user subscription data; or configured in the call session control function entity The release processing instructions.

The release processing indication includes: a session continuation indication and a session termination indication. If the release processing instruction does not exist, it will be processed according to the session continuation instruction.

When the indication is a session continuation indication, transmit the release request along the path established by the dialogue, and release the dialogue; Conversation information, release all dialogs on the side where the application server's release request is located.

The process of releasing all dialogs at the side where the release request of the application server comprises: constructing the first release request for the server end (UAS) of the dialog, and sending the first release request to the server end of the dialog along the path established by the dialog; The dialog's client (UAC) constructs a second release request and sends the second release request to the dialog's client along the path established by the dialog.

By using the call session control device and method provided by the present invention, after receiving the release request information from the application server, it is possible to judge whether all triggered dialogs with the application server need to be released according to the stored dialog information and release processing instructions, and Releases all triggered conversations with the application server when needed.

Description of drawings

The accompanying drawings described here are used to provide a further understanding of the present invention and constitute a part of the application. The schematic embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations to the present invention. In the attached picture:

Fig. 1 shows the block diagram of IP multimedia core network subsystem according to the present invention;

Fig. 2 shows the framework diagram that IP multimedia core network subsystem network service provides according to the present invention;

FIG. 3 shows a schematic diagram of an application server performing the role of a terminating user agent or a redirection server according to the present invention;

Fig. 4 shows a schematic diagram of an application server performing a SIP proxy role according to the present invention;

FIG. 5 shows a schematic diagram of the application server according to the present invention as a routing back-to-back user agent performing third-party call control;

Figure 6 shows a block diagram of a call session control device according to the present invention;

Fig. 7 shows the flowchart of the call session control method according to the present invention;

Fig. 8 shows a schematic diagram of a process in which the S-CSCF releases all service control sessions when the network logs out the user according to an embodiment of the present invention; and

Fig. 9 shows a schematic diagram of the process of releasing all service control sessions by the S-CSCF when the application server initiates the session release according to an embodiment of the present invention.

Detailed ways

Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

Fig. 6 shows a block diagram of a call session control device according to the present invention. As shown in FIG. 6, the device 600 includes: a session establishment module 602, which triggers a session request to one or more application servers according to the initial filtering rules in the user subscription data, and stores all calls that pass through the session control function entity and links them with the session request related session information; and a session release module 604, configured to release the session according to the stored session information related to the session request when the session is released.

The session release module 604 includes: a first release request construction unit 604-2, configured to construct a first release request for each dialog server (UAS), and send the first release request to the dialog server along the path established by the dialog end; and a second release request construction unit 604-4, a second release request construction unit configured to construct a second release request for the client (UAC) of each dialog, and send the second release request along the path established by the dialog to the client side of the conversation.

The dialog information is necessary information for releasing the dialog, and the dialog information includes: Call-ID header field, From header field, To header field, Contact header field, Cseq header field, and Record-Route header field in the dialog request.

Fig. 7 shows a flowchart of a call session control method according to the present invention. As shown in Figure 7, the call session control method includes the following steps: step 702, trigger the session request to one or more application servers according to the initial filtering rules in the user subscription data, and store all the call session control function entities and communicate with the session request related session information; and step 704, when releasing the session, release the session according to all stored session information related to the session request.

Wherein, the dialog information is necessary information for releasing the dialog, and the dialog information includes: Call-ID header field, From header field, To header field, Contact header field, Cseq header field, and Record-Route header field in the dialog request.

Step 704 includes: when the CSCF entity itself or an external entity instructs to release the session, release all sessions according to all stored session information related to the session request.

Releasing all dialogs according to all dialog information related to the session request stored includes: constructing a first release request for each dialog's server (UAS), and sending the path established by the dialog to the dialog's server; and for each dialog The client (UAC) of the dialog constructs a second release request, and sends the path established by the dialog to the client of the dialog.

Step 704 includes: when the application server releases the session, release all or part of the sessions according to the stored session information related to the session request and the release processing instruction.

Wherein, the release processing instruction is: the default processing instruction in the initial filter rule corresponding to the application server in the user subscription data; the release processing instruction added in the initial filter rule of the user subscription data; or configured in the call session control function entity The release processing instructions.

The release processing indication includes: a session continuation indication and a session termination indication.

When the indication is a session continuation indication, transmit the release request along the path established by the dialogue, and release the dialogue; Conversation information, release all dialogs on the side where the application server's release request is located.

The process of releasing all dialogs at the side where the release request of the application server comprises: constructing the first release request for the server end (UAS) of the dialog, and sending the first release request to the server end of the dialog along the path established by the dialog; The dialog's client (UAC) constructs a second release request and sends the second release request to the dialog's client along the path established by the dialog.

The process of S-CSCF triggering and releasing the session of network service control is as follows:

A. Session triggering process of service control:

When the S-CSCF receives the session request message, it checks whether the original dialogue identifier previously placed by the S-CSCF in the Route header field exists in the highest item of the Route header field in the request message.

1. If it does not exist, it means that this request is the first time to visit this S-CSCF. If the request is an INVITE request, the S-CSCF saves the Call-ID header field, the tag parameter of the From header field, the tag parameter of the To header field, the Contact header field, the Cseq header field and the Record-Route received from the request. The value of the header field, so that the S-CSCF can release this dialogue when needed.

2. If present, it represents an association with an existing dialog, which was sent from the application server in response to a previously sent request. If the request is an INVITE request, then the S-CSCF judges whether the request message and the request sent to the application server by itself are the same dialog (the Call-ID header field, the tag in the From header field, The tag in the To header field is compared with the Call-ID header field, the tag in the From header field, and the tag in the To header field in the associated request message sent to the application server), if it is found that they are not the same dialog, then S- The CSCF saves the values of the Call-ID header field, the tag of the From header field, the tag of the To header field, the Contact header field, the Cseq header field and the Record-Route header field received from the request, so that the S-CSCF can release the this conversation.

Then proceed according to the existing session processing method described above.

B. The service control session release process initiated by the S-CSCF:

When the S-CSCF internally or externally indicates that the session is released (for example, the registration timer expires, the management cancels the user, etc.), the S-CSCF sends a CANCEL message to each transaction of the service control according to RFC3261 to cancel the related dialog being established, or send Both sides of each dialogue controlled by this service send BYE to release the established dialogue.

The method for S-CSCF to send BYE is as follows:

1. Construct the first BYE request for the called side of each dialog according to each dialog information saved by the S-CSCF, and then send the user agent server (UserAgent Server, UAS for short) of the dialog.

2. Construct a second BYE request for the calling side of each dialog according to each dialog information saved by the S-CSCF, and then send the user agent client (User Agent Client, UAC for short) of the dialog.

C. The service control session release process initiated by the application server:

When an application server in the service control process releases a dialog, the S-CSCF needs to judge whether to release only the current dialog or release all dialogs in the service control process. Methods as below:

method one:

When the S-CSCF receives the session release request initiated by the application server from the ISC interface, the S-CSCF checks the default processing instructions of the initial filtering rule corresponding to the application server:

1. If the value of the default processing in the filter rule is "SESSION_CONTINUED", or there is no default processing instruction, the S-CSCF forwards the release message directly according to the path established by the dialog.

2. If the value of the default processing in the filter rule is "SESSION_TERMINATED", the S-CSCF directly forwards the release message according to the path established by the dialog, and releases all the messages on the side where the application server releases the message according to the method described in B. Business control dialogue.

Method Two:

Add a release processing instruction to the initial filter rule in the subscription data of the user, or configure the release processing instruction in the call session control function entity, and its value is:

SESSION_CONTINUED: Indicates that if the application server in the initial filtering rule releases the dialogue, if the dialogues controlled by the application server triggered in other initial filtering rules are not the same dialogue, the S-CSCF will not release these dialogues.

SESSION_TERMINATED: Indicates that if the application server in the initial filtering rule releases the dialog, the S-CSCF must release the dialog controlled by the application server triggered in other initial filtering rules at the same time.

When the S-CSCF receives the dialog release request initiated by the application server from the ISC interface, the S-CSCF checks and triggers the release processing indication of the initial filter rule corresponding to the application server:

1. If the value of the release processing instruction in the filtering rule is "SESSION_CONTINUED", or there is no default processing instruction, the S-CSCF forwards the release message directly according to the path established by the dialog.

2. If the value of the release processing indication in the filter rule is "SESSION_TERMINATED", the S-CSCF forwards the release message directly according to the path established by the dialog, and releases all the messages on the side where the application server releases the message according to the method described in B. Business control dialogue.

If there is no release processing instruction, it will be processed according to SESSION_CONTINUED.

Fig. 8 shows a schematic diagram of a process in which the S-CSCF 304 releases all service control sessions when the network logs out the user according to an embodiment of the present invention. As shown in Figure 8, when the network logs out the user, the S-CSCF releases all service control dialogues including the following steps:

Step 1, S-CSCF 304 receives a session request from the Mw interface, and the dialogue identifiers in the request message are Call-ID1, From tag1 and To tag1.

Step 2, S-CSCF 304 saves the dialog information of the dialog identifier Call-ID1, From tag1 and To tag1 in the message, then takes out the user's subscription data, processes the initial filter rule check, and forwards the request to the corresponding Application Server 1.

Step 3. Application server 1 is a back-to-back user agent. After processing the business logic, the dialog identifiers in the request message sent back are Call-ID2, From tag2 and To tag2.

Step 4, S-CSCF 304 compares the dialogue identification in the sent message that is saved and the dialogue identification in the received message, finds that the two are different, then the dialogue identification in the preservation message is the dialogue information of Call-ID2, From tag2 and To tag2, Then the S-CSCF continues to check the low-priority initial filtering rules, and forwards the request to the corresponding application server 2 after matching a certain rule.

Step 5. The application server 2 is a Proxy. After processing the business logic, the dialog identifiers in the request message sent back are Call-ID2, From tag2 and To tag2.

Step 6, S-CSCF 304 compares the saved dialogue identifier in the sent message with the dialogue identifier in the received message, and finds that the two are the same, then the S-CSCF continues the low-priority initial filter rule check, and after matching a certain rule, forwards Request to the corresponding application server 3.

Step 7. The application server 3 is a back-to-back user agent. After processing the business logic, the dialog identifiers in the request message sent back are Call-ID3, From tag3 and To tag3.

Step 8, S-CSCF 304 compares the dialog identification in the sent message and the dialog ID in the received message saved, and finds that the two are different, then the dialog ID in the saved message is the dialog information of Call-ID3, From tag3 and to tag3, Then the S-CSCF continues to check the low-priority initial filtering rules, and if no matching rule is found, the request is forwarded to the Mw interface.

After the session is established, the network logs out the user, and the S-CSCF releases the user's session.

Step 9: S-CSCF 304 first releases dialog 3, and sends a BYE message to the Mw interface to release the called side.

Step 10, S-CSCF 304 sends a BYE message to application server 3 to release the called side, and release the other side of dialogue 3.

Step 11, the S-CSCF 304 releases the dialog 2, and sends a BYE message to the application server 3 interface to release the dialog 2 side.

Step 12, S-CSCF 304 sends a BYE message to application server 2 to release the called side, and release the other side of dialogue 2.

Step 13, the application server 2304 forwards the BYE release message along the path of dialog 2.

Step 14, S-CSCF 304 forwards the BYE release message to application server 1 along the path of dialogue 2.

Step 15, S-CSCF 304 sends a BYE message to application server 1 to release the called side, and release the dialogue 1 side.

Step 16, S-CSCF 304 sends a BYE message to the Mw interface to release the calling side.

Fig. 9 shows a schematic diagram of a process in which the S-CSCF releases all service control sessions when an application server initiates a session release according to an embodiment of the present invention. As shown in Figure 9, when the application server initiates session release, the S-CSCF releases all service control dialogs, including the following steps:

Step 1, S-CSCF 304 receives a session request from the Mw interface, and the dialogue identifiers in the request message are Call-ID1, From tag1 and To tag1.

Step 2, S-CSCF 304 saves the dialog information of the dialog identifier Call-ID1, From tag1 and To tag1 in the message, then takes out the user's subscription data, processes the initial filter rule check, and forwards the request to the corresponding Application Server 1.

Step 3. Application server 1 is a back-to-back user agent. After processing the business logic, the dialog identifiers in the request message sent back are Call-ID2, From tag2 and To tag2.

Step 4, S-CSCF 304 compares the dialogue identification in the sent message that is saved and the dialogue identification in the received message, finds that the two are different, then the dialogue identification in the preservation message is the dialogue information of Call-ID2, From tag2 and To tag2, Then the S-CSCF continues to check the low-priority initial filtering rules, and forwards the request to the corresponding application server 2 after matching a certain rule.

Step 5. The application server 1 is a Proxy. After processing the business logic, the dialog identifiers in the request message sent back are Call-ID2, From tag2 and To tag2.

Step 6, S-CSCF 304 compares the saved dialogue identifier in the sent message with the dialogue identifier in the received message, and finds that the two are the same, then the S-CSCF continues the low-priority initial filter rule check, and after matching a certain rule, forwards Request to the corresponding application server 3.

Step 7. The application server 3 is a back-to-back user agent. After processing the business logic, the dialog identifiers in the request message sent back are Call-ID3, From tag3 and To tag3.

Step 8, S-CSCF 304 compares the dialogue identification in the sent message that is saved and the dialogue identification in the received message, finds that the two are different, then the dialogue identification in the preservation message is the dialogue information of Call-ID3, From tag3 and To tag3, Then the S-CSCF continues to check the low-priority initial filtering rules, and if no matching rule is found, the request is forwarded to the Mw interface.

After the session is established, the application server 3 initiates a session release request.

Step 9: The application server 3 first releases the dialogue 2, and sends a BYE message to the S-CSCF through the ISC interface.

Step 10: After receiving the release message of dialog 2, S-CSCF 304 checks that the release processing indication in the corresponding initial filter rule of application server 3 is SESSION_TERMINATED, and releases dialog 1 on the side of dialog 2 at the same time.

Step 11, S-CSCF 304 forwards the release message BYE of dialogue 2 to application server 2.

Step 12, S-CSCF 304 receives the BYE release message of dialog 2 forwarded by application server 2.

Step 13, S-CSCF 304 forwards the release message BYE of dialogue 2 to application server 1.

Step 14, S-CSCF 304 sends a BYE message to the application server 1 interface to release dialog 1.

Step 15, S-CSCF 304 sends a BYE message to the Mw interface to release the calling side dialogue 1.

Step 16, the application server 3 releases the dialogue 3, and sends a BYE message to the S-CSCF through the ISC interface.

Step 17, S-CSCF 304 sends a BYE message to the called side to release dialogue 3.

The S-CSCF saves all dialog information passing through the S-CSCF. When the network initiates all dialogs for releasing the user's current service control, the S-CSCF can release all dialogs of the triggered application server according to the saved dialog information.

The S-CSCF saves all the dialog information passing through the S-CSCF. When the application server initiates a dialog for releasing user service control, the S-CSCF can trigger the release processing instruction in the initial filtering rule of the application server according to the saved dialog information, Determine whether to release all dialogs controlled by the current service.

The present invention realizes that after the S-CSCF triggers the application server according to the initial filtering rule, when the network initiates all dialogues for releasing the current service control, or when the application server initiates the dialogue for releasing the user service control, the S-CSCF can, according to the saved dialogue information , to release all conversations controlled by the current service.

The above descriptions are only preferred embodiments of the present invention, and are not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and changes. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.

Claims (12)

1. a call session control device is characterized in that, described device comprises:

Module is set up in session, according to the initial filter criteria in the user contracting data session request is triggered to one or more application servers, and stores all through call conversation control function entity and the dialog information relevant with described conversation request; And

The session release module is used for when discharging session, according to all dialog information relevant with described conversation request release dialogues of storage.

2. call session control device according to claim 1 is characterized in that, described session release module comprises:

First discharges the request structural unit, is used to server end (UAS) structure first of each dialogue to discharge request, and discharges request is sent to described dialogue along the path of described session establishment server end with described first; And

Second discharges the request structural unit, is used to client (UAC) structure second of each dialogue to discharge request, and discharges request is sent to described dialogue along the path of described session establishment client with described second.

3. call session control device according to claim 1 and 2, it is characterized in that, described dialog information is for discharging the necessary information of dialogue, and described dialog information comprises: the Call-ID header field in the session request, From header field, To header field, Contact header field, Cseq header field and Record-Route header field.

4. a call session control method is characterized in that, described method comprises:

Step 702 is triggered to one or more application servers according to the initial filter criteria in the user contracting data with the session request, and stores all through call conversation control function entity and the dialog information relevant with described conversation request; And

Step 704 is when discharging session, according to the dialog information release dialogue relevant with described conversation request of storage.

5. call session control method according to claim 4, it is characterized in that, described dialog information is for discharging the necessary information of dialogue, and described dialog information comprises: the Call-ID header field in the session request, From header field, To header field, Contact header field, Cseq header field and Record-Route header field.

6. call session control method according to claim 4 is characterized in that, described step 704 comprises:

When call conversation control function entity itself or external entity indication release session, discharge all dialogues according to all dialog information relevant of storing with described conversation request.

7. call session control method according to claim 6 is characterized in that, discharges all dialogues according to all dialog information relevant with described conversation request of storing and comprises:

Be server end (UAS) the structure first release request of each dialogue, and the path of described session establishment be sent to the server end of described dialogue; And

Be client (UAC) the structure second release request of each dialogue, and the path of described session establishment be sent to the client of described dialogue.

8. call session control method according to claim 4 is characterized in that, described step 704 comprises:

When described application server discharges session, handle indication according to the dialog information relevant and the release of storage with described conversation request, discharge all dialogues or subdialogue.

9. call session control method according to claim 8, it is characterized in that described release is handled indication and is: the default process indication in user contracting data in the initial filter criteria of application server correspondence, the release of adding in the initial filter criteria of user contracting data are handled the release of indicating or disposing and are handled indication in call conversation control function entity.

10. call session control method according to claim 9 is characterized in that, described release is handled indication and comprised: session continues indication and session stops indication.

11. each described call session control method in 10 according to Claim 8 is characterized in that:

When being designated as session and continuing indication or indication and do not exist, transmit the request of release along the path of session establishment, discharge described dialogue; And

When being designated as session termination indication, transmit the request of release along the path of session establishment, the while discharges all dialogues of release request place one side of described application server according to all dialog information relevant with described conversation request of storage.

12. call session control method according to claim 11 is characterized in that, the process of all dialogues that discharges release request place one side of described application server comprises:

Be server end (UAS) the structure first release request of described dialogue, and discharge the server end that request is sent to described dialogue with described first along the path of described session establishment; And

Be client (UAC) the structure second release request of described dialogue, and discharge the client that request is sent to described dialogue with described second along the path of described session establishment.

Images