CN101137104B - A method and system for realizing resource release - Google Patents

Abstract

The invention discloses a method for realizing resource release. The method includes: after the B2BUA unit of the back-to-back user agent receives the session establishment request message that does not contain the Supported header field with the timer tag, adding the Supported header field with the timer tag in the request message; Negotiation, notify the node devices passed by this session other than the refresher not to initiate a session update request; The device initiates a session update request. The solution of the invention solves the problems of meaningless forwarding of session update requests and message collisions in the session process, and realizes that both the calling terminal and the called terminal do not support the Session Timers protocol, and resources can also be released. The invention also discloses a system for realizing resource release.

Description

A method and system for realizing resource release

technical field

The present invention relates to the field of communication technology, in particular to a method and system for realizing resource release.

Background technique

In recent years, with the development of mobile communication technology, a single voice communication method can no longer fully meet the needs of users, and new multimedia communication methods are constantly emerging. These multimedia communications are not only simple video and audio communications, but also include instant messaging, co-location browsing, collaborative work, streaming media, etc., especially the integration of new communication methods and traditional voice services, which are more accepted by the public. Among the many session control systems based on Internet and telecommunications network convergence, most of the session control systems use Session Initiation Protocol (SIP) as the session control protocol, and the most representative one is Internet Protocol Multimedia Subsystem (IMS).

IMS is a voice and data service system. It can shield users' access methods and control the opening degree of service capabilities according to user data, thereby providing multimedia communication experience. Moreover, IMS, which integrates innovative applications of voice, data and multimedia, can generate demand for new services, such as presence service, multimedia chat, conferencing, push-to-talk and push-to-conferencing.

The main functions in IMS include call control (CSCF) which controls functions such as user registration and session control, and media gateway control function/IMS media gateway function (MGCF/IM-MGW) which realizes intercommunication with the circuit switching network.

The main equipment in the IMS includes an Application Server (AS) that provides various business logic control functions and a Home Subscriber Server (HSS) that is used to centrally manage user subscription data.

Among them, CSCF is divided into according to the function in the network: current location proxy node (P-CSCF), registration home domain service node (S-CSCF) and interrogation node (I-CSCF). The P-CSCF is the user's access point in the IMS system, and all SIP signaling flows from or to the UE must pass through the P-CSCF. The I-CSCF is the point of contact within an operator's network for all users connected to this operator. The S-CSCF is in the core control position in the IMS core network, and it is located in the home network. Responsible for UE registration authentication and session control, perform basic session routing functions for calling and called IMS users, and trigger corresponding rules according to the IMS signed by the user.

The user accesses the IMS through the proxy node P-CSCF of the current location, and the session and service trigger control and the service control interaction with the AS are completed by the home domain service node S-CSCF of the registration location; the IMS uses the SIP protocol as the application layer interaction signaling , the interface protocols between the terminal and the CSCF, between the CSCFs, and between the CSCF and the AS are all SIP protocols. However, the SIP protocol does not define a protocol so that the intermediate node can detect whether the session is active after the session is established, which causes the intermediate node in the IMS system to fail to release resources when the terminal fails to send the release indication message. The Session Timers protocol is a supplement to the SIP protocol for this problem, and is an extension of the SIP protocol. The Session Timers protocol allows a terminal in the session to be responsible for periodically initiating a session update request to ensure that the session is active. If no session update request is received within the period or the session update request fails to be sent, it indicates that the session is already in an inactive state. , then the terminal releases related resources. Intermediate nodes in the IMS system, such as P-CSCF or S-CSCF, directly release the session-related resources after timeout. This ensures the timely release of related resources.

According to the provisions of the Session Timers protocol, it can be conveniently implemented for nodes as proxy servers (PROXY). For example, P-CSCF and S-CSCF are usually only used as PROXY units. But for AS, they are usually used as back-to-back user agent (B2BUA) units. , the Session Timers protocol is not stipulated. If the protocol is directly enforced, the session update request will be forwarded many times meaninglessly or collided during the session, which cannot be realized smoothly. Therefore, the resource release problem of the B2BUA unit has not yet been solved. Nice work out.

FIG. 1A is a schematic flow diagram of meaningless forwarding of a session update request sent by a calling terminal.

Step 100, the calling terminal sends a session establishment request message to the B2BUA1 unit.

The session establishment request message sent by the calling terminal includes a session-expires (Session-Expires) header field, and may also include a time-stamped supported (supported:timer) header field and/or a minimum session-expires (Min_SE) header field.

If there is a PROXY unit between the calling terminal and the B2BUA1, the PROXY unit forwards the received session establishment request message.

Step 101, the B2BUA1 unit receives the session establishment request message and performs related processing specified in the Session Timers protocol.

The user agent server (UAS) side of the B2BUA1 unit checks whether the supported:timer header field is included in the message.

If there is a supported:timer header field in the session establishment request message, and the value of the Session-Expires header field is smaller than the value of the local Min_SE header field, then reply to the calling terminal with a response indicating that the session update interval is too short and include the The value of the local Min_SE header field. After receiving the response, the calling terminal changes the value of the Session-Expires header field to not less than the value of the Min_SE header field and sends it to the B2BUA1 unit again.

If the session establishment request message does not contain the supported:timer header field, and the value of the Session-Expires header field is smaller than the value of the local Min_SE header field, if there is a Min_SE header field in the message, increase the value of the Min_SE header field in the request message It is equal to the value of the local Min_SE header field and used as the value of the Session-Expires header field. If there is no Min_SE header field in the message, the Min_SE header field is inserted in the request message, and its value is the value of the local Min_SE header field, and the The value is used as the value of the Session-Expires header field.

Regardless of whether the session establishment request contains the supported:timer header field, as long as the value of the Session-Expires header field is not less than the value of the local Min_SE header field, the value of Session-Expires may not be modified in any way, or the value of the message Properly reduce the value of the Session-Expires header field on the basis of the value of the Min_SE header field and not less than the value of the local Min_SE header field.

The user agent client (UAC) of the B2BUA1 unit constructs a new session establishment request message according to the session establishment request message processed by the UAS end.

Step 102, the B2BUA1 unit sends the processed session establishment request message to the PROXY unit.

If there are multiple PROXY units, each PROXY unit forwards the session establishment request message; if there is no PROXY unit, B2BUA1 directly sends the session establishment request message to B2BUA2.

Step 103, the PROXY unit sends the received session establishment request message to the AS (B2BUA2 unit).

Step 104, the B2BUA2 unit receives the session establishment request message and performs related processing specified in the Session Timers protocol.

The processing procedure is the same as that of step 101.

Step 105, the B2BUA2 unit sends the processed session establishment request message to the called terminal.

If there is a PROXY unit between the B2BUA2 and the called terminal, the PROXY unit forwards the received session establishment request message.

Step 106, the called terminal sends a 200 response message indicating success to the B2BUA2 unit.

If there is a PROXY unit between the B2BUA2 and the called terminal, the PROXY unit forwards the received 200 response message.

Step 107, the B2BUA2 unit receives the 200 response message and performs related processing specified in the Session Timers protocol.

The UAC end of the B2BUA2 unit sets the refresher to uac according to the time of the Session-Expires header field in the response message and the refresher (refresher) parameter in the session negotiation, so the UAC end of the B2BUA2 unit starts the session update request timer and the timeout release timer Timer.

The UAS side of the B2BUA2 unit starts the timeout release timer according to the value of the Session-Expires header field.

Session negotiation sets the refresher as uac, so the UAS side of the B2BUA2 unit does not start the timer for sending session update requests.

Step 108, the B2BUA2 unit sends the processed 200 response message to the PROXY unit.

Step 109, the PROXY unit sends the received 200 response message to the AS (B2BUA1 unit).

If there are multiple PROXY units, each PROXY unit forwards the message; if there is no PROXY unit, B2BUA2 directly sends the message to B2BUA1.

Step 110, the B2BUA1 unit receives the 200 response message and performs related processing specified in the Session Timers protocol.

The processing procedure is the same as that of step 107.

Step 111, the B2BUA1 unit sends the processed 200 response message to the calling terminal.

After the calling terminal receives the 200 response message, the session is successfully established, and the session timers are also successfully negotiated. The session update timer of the calling terminal starts timing.

Step 112, according to the parameter refresher determined during negotiation as uac, the calling terminal is responsible for initiating a session update request, then the session update timer of the calling terminal has passed (Session Expires/2) seconds to notify the calling terminal to send a session update to the B2BUA1 unit ask.

Step 113, according to the parameter refresher determined during negotiation as uac, the UAC end of the B2BUA1 unit is responsible for initiating a session update request, and the session update timer of the B2BUA1 unit has passed (SessionExpires/2) seconds to notify the UAC end of the B2BUA1 unit to send a session to the PROXY unit update request.

Step 114, the B2BUA1 unit processes the session update request sent by the calling terminal and sends it to the PROXY unit.

Step 115, the PROXY unit sends the session update request sent by the B2BUA1 unit to the AS (B2BUA2 unit).

Step 116, the PROXY unit sends the session update request sent by the B2BUA1 unit to the AS (B2BUA2 unit).

Step 117, according to the parameter refresher determined during negotiation as uac, the UAC side of the B2BUA2 unit is responsible for initiating a session update request, and the session update timer of the B2BUA2 unit has passed (SessionExpires/2) seconds to notify the B2BUA2 unit to send a session update request to the called terminal .

Step 118, the B2BUA2 unit processes the session update request sent by the PROXY unit and sends it to the called terminal.

Step 119: The B2BUA2 unit processes the session update request sent by the PROXY unit and sends it to the called terminal.

FIG. 1B is a schematic diagram of a collision process in which a calling terminal sends a session update request.

Step 1000, the calling terminal sends a session establishment request message to the B2BUA1 unit.

If there is a PROXY unit between the calling terminal and the B2BUA1, the PROXY unit forwards the received session establishment request message.

Step 1001, the B2BUA1 unit receives the session establishment request message and performs related processing specified in the Session Timers protocol.

The UAS side of the B2BUA1 unit checks whether the message contains the supported:timer header field.

If there is a supported:timer header field in the session establishment request message, and the value of the Session-Expires header field is smaller than the value of the local Min_SE header field, then reply to the calling terminal with a response indicating that the session update interval is too short and include the The value of the local Min_SE header field. After receiving the response, the calling terminal changes the value of the Session-Expires header field to not less than the value of the Min_SE header field and sends it to the B2BUA1 unit again.

If the supported:timer header field is not included in the session establishment request message, it means that the calling terminal does not support the Session Timers protocol, and the value of the Session-Expires header field is smaller than the value of the local Min_SE header field. If there is a Min_SE header field in the message, Increase the value of the Min_SE header field in the request message to be equal to the value of the local Min_SE header field and use it as the value of the Session-Expires header field. If there is no Min_SE header field in the message, insert the Min_SE header field in the request message, and its value is The value of the local Min_SE header field, and use this value as the value of the Session-Expires header field.

Regardless of whether the session establishment request message contains the supported:timer header field, as long as the value of the Session-Expires header field is not less than the value of the local Min_SE header field, the value of Session-Expires may not be modified in any way, or it may be not less than Properly reduce the value of the Session-Expires header field on the basis of the value of the Min_SE header field in the message and not less than the value of the local Min_SE header field.

The UAC side of the B2BUA1 unit constructs a new request message according to the request message processed by the UAS side.

Step 1002, the B2BUA1 unit sends the processed session establishment request message to the PROXY unit.

If there are multiple PROXY units, each PROXY unit forwards the session establishment request message; if there is no PROXY unit, B2BUA1 directly sends the session establishment request message to B2BUA2.

Step 1003, the PROXY unit sends the received session establishment request message to the AS (B2BUA2 unit).

Step 1004, the B2BUA2 unit receives the request message and performs related processing specified in the Session Timers protocol.

The processing procedure is the same as that of step 1001.

Step 1005, the B2BUA2 unit sends the processed session establishment request message to the called terminal.

If there is a PROXY unit between the B2BUA2 and the called terminal, the PROXY unit forwards the received session establishment request message.

Step 1006, the called terminal sends a 200 response message indicating success to the B2BUA2 unit.

If there is a PROXY unit between the B2BUA2 and the called terminal, the PROXY unit forwards the received 200 response message.

Step 1007, the B2BUA2 unit receives the 200 response message and performs the specified related processing.

The UAC side of the B2BUA2 unit sets the refresher between the B2BUA2 and the called terminal as refresher=uac according to the time of the Session-Expires header field in the response message and the refresher parameter in the session negotiation, so the UAC side of the B2BUA2 unit starts the session update timer and Session timeout release timer.

The UAS side of the B2BUA2 unit starts the relevant timer according to the value of the Session-Expires header field and the refresher parameter.

The session negotiation sets the refresher between B2BUA1 and B2BUA2 as refresher=uas, so the UAS side of the B2BUA2 unit starts the session update timer and the session timeout release timer.

Step 1008, the B2BUA2 unit sends the processed 200 response message to the PROXY unit.

Step 1009, the PROXY unit sends the received 200 response message to the AS (B2BUA1 unit).

If there are multiple PROXY units, each PROXY unit forwards the message; if there is no PROXY unit, B2BUA2 directly sends the message to B2BUA1.

Step 1010, the B2BUA1 unit receives the 200 response message and performs related processing specified in the Session Timers protocol.

The UAC side of the B2BUA1 unit starts the relevant timer according to the time in the Session-Expires header field and the refresher parameter in the response message.

The session negotiation sets the refresher between B2BUA1 and B2BUA2 as refresher=uas, so the UAC side of the B2BUA1 unit does not start the session update timer and the session timeout release timer.

The UAS side of the B2BUA1 unit starts the relevant timer according to the value of the Session-Expires header field and the refresher parameter.

The session negotiation sets the refresher between B2BUA1 and B2BUA2 as refresher=uas, so the UAS side of the B2BUA2 unit does not start the session update timer and the session timeout release timer.

Step 1011, the B2BUA1 unit sends the processed 200 response message to the calling terminal.

After the calling terminal receives the 200 response message, the session is successfully established, and the session timers are also successfully negotiated. The session update timer of the calling terminal starts timing.

Step 1012, according to the parameter refresher determined during negotiation, refresher=uac between the calling terminal and B2BUA1, refresher=uas between B2BUA1 and B2BUA2, refresher=uac between B2BUA2 and the called terminal, then the calling terminal is responsible for initiating session update request, the calling terminal's session update timer expires (SessionExpires/2) seconds to notify the calling terminal to send a session update request to the B2BUA1 unit.

Step 1013, the B2BUA1 unit processes the session update request sent by the calling terminal and sends it to the PROXY unit.

Step 1014, the PROXY unit sends the session update request sent by the B2BUA1 unit to the AS (B2BUA2 unit).

Step 1015, the B2BUA2 unit processes the session update request sent by the PROXY unit and sends it to the called terminal.

Step 1016, according to the parameter refresher determined during negotiation, refresher=uac between the calling terminal and B2BUA1, refresher=uas between B2BUA1 and B2BUA2, refresher=uac between B2BUA2 and the called terminal, then the B2BUA2 unit is responsible for initiating a session update request , the B2BUA2 unit's session update timer expires (SessionExpires/2) seconds to notify the B2BUA2 unit to send a session update request to the PROXY unit.

Step 1017, the PROXY unit sends the session update request sent by the B2BUA2 unit to the AS (B2BUA1 unit).

Step 1018, the B2BUA1 unit processes the session update request sent by the PROXY unit and sends it to the calling terminal.

Step 1019, according to the parameter refresher determined during negotiation, refresher=uac between the calling terminal and B2BUA1, refresher=uas between B2BUA1 and B2BUA2, refresher=uac between B2BUA2 and the called terminal, then the B2BUA2 unit is responsible for initiating a session update request , the B2BUA2 unit’s session update timer expires (SessionExpires/2) seconds to notify the B2BUA2 unit to send a session update request to the called terminal.

It can be seen from FIG. 1B that on the B2BUA1 unit, the session update requests in step 1012 and step 1017 collide, and the B2BUA1 unit forwards redundant session update requests.

In the prior art, it is also possible to send a session update request from the called terminal, then refresher=uas between the calling terminal and B2BUA1, refresher=uac between B2BUA1 and B2BUA2, refresher=uas between B2BUA2 and the called terminal, near the B2BUA2 unit Session update requests collide, and the B2BUA2 unit forwards redundant session update requests.

To sum up, in the prior art, if the session is in an inactive state, session resources need to be released, and at least one of the calling terminal or the called terminal is required to support the Session Timers protocol, and the calling terminal or the called terminal that supports the SessionTimers protocol A session update request from an endpoint. If neither the calling terminal nor the called terminal supports the Session Timers protocol, each B2BUA unit will not be able to release the resources allocated for the session.

Moreover, if the session update request is sent by the calling terminal, after each B2BUA unit receives the session update request, it cannot judge whether the current request message is a session update request message or a common service negotiation message, so a new session update request message is generated. request, and send the received session update request and new session update request to the next B2BUA unit through which the session is established until the called terminal. Similarly, if the called terminal sends a session update request, after each B2BUA unit receives the session update request, it will also send the received session update request and the generated new session update request to the calling side until the calling terminal . Therefore, since each B2BUA unit will forward and initiate a session update request, the user terminal will receive a large number of meaningless session update requests in the end. If the B2BUA unit sends a new session update request to both sides after receiving the session update request, it will Will cause a collision of session update requests.

Contents of the invention

The main purpose of the present invention is to provide a method and system for realizing resource release, so that it can realize resource release when the session is in an inactive state when the terminal does not support the Session Timers protocol.

Another object of the present invention is to provide a back-to-back user agent device, which is applied in a resource release system, and can realize resource release if the session is in an inactive state when the terminal does not support the Session Timers protocol.

A method for realizing resource release provided by the present invention includes:

After receiving the session establishment request message, judge whether it contains the Supported header field with the time timer tag, if so, forward the session establishment request message, otherwise, add the Supported header field with the timer tag in the message, and forward the session establishment request message;

During the session establishment process, refresher negotiation is carried out between node devices, and a node device is determined as the refresher;

After the session is established, the node device determined to be the refresher through negotiation sends a session update request to other network nodes.

After the session is established, the method may also include: after each node device receives the session update request, judge whether the session update request contains a Supported header field with a timer label, and if so, send the The next node device through which the session passes sends a session update request.

The refresher negotiation is performed between the node devices, and the step of determining a node device as the refresher may include:

A11. The B2BUA unit adds the refresher parameter in the session termination Session-Expires header field in the session establishment request message forwarded to the node device through which the session is established, and sets the refresher refresher as the user agent client uac to indicate The B2BUA unit is responsible for initiating a session update request to the called terminal;

A12. After the B2BUA unit receives the session establishment response message, it adds a refresher parameter to the Session-Expires header field in the session establishment response message returned to the calling terminal, and sets refresher as the user agent server-side uas for Indicates that the B2BUA unit is responsible for initiating a session update request to the calling terminal.

The refresher negotiation is performed between the node devices, and the step of determining a node device as the refresher may include:

A21, the B2BUA unit sends the session establishment request message to the node device through which the session is established, which contains a Supported header field with a timer label. After each node device receives the session establishment request message, it forwards it to the next node device until called terminal;

A22. After the called terminal receives the session establishment request message, if it determines that it is the refresher, it returns a session establishment response message to the B2BUA through the node device, wherein the Session-Expires header field is uas, and if it determines that it is not the refresher , the node device returns to the B2BUA a session establishment response message that it is not the refresher;

A23. After receiving the session establishment response message, the B2BUA unit judges whether the called terminal is the refresher, if yes, executes step A24, otherwise, takes itself as the refresher, and executes step A24;

A24. The B2BUA unit adds a refresher parameter to the Session-Expires header field in the session establishment response message returned to the calling terminal, and sets refresher as the uas of the user agent server.

In step A22, the session establishment response message that is not the refresher itself may be a session establishment response message that does not contain the Supported header field with the timer tag;

In step A22, the session establishment response message that is not the refresher itself may be a session establishment response message that contains the Supported header field with the timer tag, where the refresher in the Session-Expires header field is uas.

A system for implementing resource release provided by the present invention includes: one or more B2BUA units, wherein each B2BUA unit may include:

The session protocol judging module is used to judge whether the received session establishment request message contains the Supported header field with the timer label, if so, directly forwards the session establishment request message, otherwise, adds the header field with the timer label in the session establishment request message. The Supported header field of the timer tag forwards the session establishment request message;

The resource release module is used to judge whether the session state is normal according to the received session update response message, and release the resources allocated by itself for the session when the session is in an inactive state.

A refresher negotiation module, configured to add a refresher parameter to the Session-Expires header field in the session establishment request message, and determine whether it is a refresher according to the received session establishment response message;

The session update request module is used to initiate a session update request to the network nodes through which the session is established on both sides if it is determined that it is the refresher after the session is established; if it is determined that it is not the refresher, it judges the received session update Whether the request contains the Supported header field with the timer tag, and if so, only send the session update request to the next network node passed by the session.

A back-to-back user agent device provided by the present invention includes:

The session protocol judging module is used to judge whether the received session establishment request message contains the Supported header field with the timer label, if so, directly forwards the session establishment request message, otherwise, adds the header field with the timer label in the session establishment request message. The Supported header field of the timer tag forwards the session establishment request message;

The resource release module is used to judge whether the session state is normal according to the received session update response message, and release the resources allocated by itself for the session when the session is in an inactive state;

A refresher negotiation module, configured to add a refresher parameter to the Session-Expires header field in the session establishment request message, and determine whether it is a refresher according to the received session establishment response message;

The session update request module is used to initiate a session update request to the network nodes through which the session is established on both sides if it is determined that it is the refresher after the session is established; if it is determined that it is not the refresher, it judges the received session update Whether the request contains the Supported header field with the timer tag, and if so, only send the session update request to the next network node passed by the session.

The present invention initiates a session update request to the calling terminal and the called terminal through the B2BUA unit determined through refresher negotiation, and realizes resource release even when neither the calling terminal nor the called terminal supports the Session Timers protocol. Other B2BUA units actively initiate the session update request, and only forward the request after receiving the session update request. The problem of meaningless forwarding and collision of session update requests during the session is avoided.

Description of drawings

FIG. 1A is a schematic flow diagram of meaningless forwarding of a session update request sent by a calling terminal;

FIG. 1B is a schematic flow diagram of a session update request collision in which the calling terminal sends a session update request;

FIG. 2 is a schematic structural diagram of a system for realizing resource release in the present invention;

Fig. 3 is a schematic structural diagram of the B2BUA device of the present invention;

FIG. 4 is a schematic flowchart of a method for realizing resource release in the present invention;

FIG. 5A is a schematic flow diagram of a specific embodiment 1 for realizing the method of the present invention;

FIG. 5B is a schematic flow diagram of a second embodiment of the method of the present invention;

FIG. 6 is a schematic flow diagram of a third embodiment of the method of the present invention;

FIG. 7 is a schematic flowchart of a fourth embodiment of the method of the present invention.

Detailed ways

Aiming at the problem of multiple meaningless forwarding and collisions of session update request information in the implementation of the Session Timers protocol on the B2BUA unit in the current communication technology field, the present invention solves the above problem by removing the function of the B2BUA unit actively initiating a session update request. And during the session establishment process, by changing the B2BUA unit, it can actively initiate a session update request to the calling terminal and the called terminal, so that even if the calling terminal and the called terminal do not support the Session Timers protocol, The Session Timers protocol can be successfully established.

During the session establishment process, after receiving the session establishment request message, the B2BUA unit judges whether the session establishment request message contains the Supported header field with the time timer tag, and if so, sends the session establishment request message directly to the next node The device forwards it; if it does not contain it, add the Supported header field with the timer tag to the session establishment request message, and then forward the session establishment request message with the Supported header field with the timer tag added to the next node device.

During session establishment, refresher negotiation can also be performed between node devices. After the session is established, the refresher determined by the negotiation respectively initiates a session update request to the node devices on both sides of the current session that are connected to itself. After each node device receives the session update request, it sends a session update request upstream or downstream according to the received session update request until the calling terminal and the called terminal; each node device determines that the session is inactive Next, release the resources allocated by itself for the session.

After the session is established, when the B2BUA unit receives the session establishment request message, if it is determined that the message contains the Supported header field with the timer tag, it will no longer generate a session update request, and only send the session update to the next node device passed by the session ask.

FIG. 2 is a schematic structural diagram of a system for implementing resource release in the present invention. As shown in Figure 2, the system of the present invention includes: one or more B2BUA units,

Each B2BUA unit is used to determine whether the session establishment request carries the Supported header field of the timer label after receiving the session establishment request from the previous node device, and if so, forward the session establishment request message to the next node device , otherwise, add a Supported header field with a timer tag in the session establishment request message, and forward the session establishment request message to the next node device; after the session is established, if it is determined that the session is inactive, release itself as the Resources allocated by the session.

After the session is established, if the B2BUA unit receives the session update request, the B2BUA unit is further used to judge whether the Supported header field with the timer tag is included in the session update request. The next network node of the node sends a session update request.

As shown in Fig. 3, the B2BUA unit of the present invention includes: a session protocol judgment module and a resource release module. Wherein, the session agreement judging module is used to judge whether the Supported header field with the timer label is in the session establishment request message received, and if so, forwards the session establishment request message directly; otherwise, adds the session establishment request message in the session establishment request message The Supported header field with the timer tag forwards the session establishment request message; the source release module is used to judge whether the session status is normal according to the received session update response message, and release itself for the session when the session is in an inactive state. Resources allocated by the session.

Of course, in order to perform refresher negotiation, the B2BUA unit may further include: a refresher negotiation module and a session update request module. Wherein, the refresher negotiation module is used to add refresher parameters in the session termination Session-Expires header field in the session establishment request message, and determine whether itself is a refresher according to the session establishment response message received; the session update request module After the session is established, if it is determined that it is the refresher, it is used to initiate a session update request to the network nodes through which the session is established on both sides; if it is determined that it is not the refresher, it is determined whether the received session update request contains The Supported header field of the timer tag, if yes, only send a session update request to the next network node passed by the session.

Fig. 4 is a schematic diagram of the process of realizing resource release in the present invention, taking the first B2BUA unit receiving a session update request as an example. Wherein, the first B2BUA unit is the first B2BUA unit that receives the session establishment request message during the session establishment process, and the rest of the B2BUA units are similar to the first B2BUA unit, and no more examples are given.

Referring to Fig. 4, the method for realizing resource release in the present invention includes:

Step 400, after the first B2BUA unit receives the session establishment request message, it judges whether the message contains the Supported header field with the timer tag, if so, it indicates that the calling terminal supports the Session Timers protocol, and then executes step 401; otherwise, directly The session request is forwarded to the next node device until the called terminal, and step 407 is executed.

Step 401: After the first B2BUA unit receives the session establishment request message, the UAC end of the first B2BUA unit inserts the supported:timer header field into the session establishment request message, and refreshes the session establishment request message in the Session-Expires header field. Set to uac.

Step 402, the first B2BUA unit sends a session establishment request message adding the supported:timer header field to the next B2BUA unit.

Step 403, after receiving the session establishment request message, each B2BUA unit directly sends the session establishment request message to the next node device until the called terminal.

Step 404: After receiving the session establishment request message, the called terminal returns a session establishment response message to the B2BUA unit connected to it. After each B2BUA unit receives the session establishment request message, it only starts the session timeout release timer and sets the session establishment The response message is sent to the upper-level B2BUA unit until the first B2BUA unit.

Step 405, after the first B2BUA unit receives the session establishment response message, if it determines that it is the refresher, it inserts the supported:timer header field in the session establishment response message, and sets the parameter refresher in the Session-Expires header field to refresher=uas, and send the session establishment response message to the calling terminal.

Step 406: After the call is established, the first B2BUA unit initiates a session update request to both parties.

Step 407, after each B2BUA unit receives the session update request, it judges whether the session update request contains the Supported header field with the timer label, and if so, directly forwards the session update request to the next node device, and no new one is generated here For a session update request, go to step 410.

Step 408: After receiving the session establishment request message, the called terminal returns a session establishment response message to the B2BUA unit connected to it. After each B2BUA unit receives the session establishment request message, it only starts the session timeout release timer and sets the session establishment The response message is sent to the upper-level B2BUA unit until the first B2BUA unit.

Step 409: After the call is established, the calling terminal or the called terminal sends a session update request to the connected B2BUA unit, and step 410 is executed.

Step 410, when each B2BUA unit determines that the session is inactive, it releases the resources allocated by itself for the session.

The above steps 401-405 are the refresher negotiation process.

The node device can carry out refresher negotiation according to its own situation, and determine itself as the refresher.

For example, the refresher negotiation process between the first B2BUA unit and the called terminal can be implemented in the following two ways.

The first way:

(1) The B2BUA unit adds the refresher parameter in the Session-Expires header field of the session establishment request message forwarded to the node device through which the session is established, and sets the refresher refresher as the user agent client uac, which is used to indicate the The B2BUA unit is responsible for initiating a session update request to the called terminal;

(2) After receiving the session establishment request message, the called terminal determines that it is not the refresher, and returns a session establishment response message that it is not the refresher to the B2BUA through the node device;

(3) After the B2BUA unit receives the session establishment response message, it determines itself as the refresher, then adds the refresher parameter in the Session-Expires header field in the session establishment response message returned to the calling terminal, and refresher is set to User agent server side uas.

The second way:

(1) The B2BUA unit sends the session establishment request message to the node device through which the session is established, which contains the Supported header field with the timer label, and each node device forwards the session establishment request message to the next node device after receiving the session establishment request message, until the called terminal;

(2) After the called terminal receives the session establishment request message, if it determines that it is the refresher, it returns a session establishment response message to the B2BUA through the node device, wherein the Session-Expires header field is uas, and if it determines that it is not the refresher Otherwise, the node device returns to the B2BUA a session establishment response message that it is not the refresher;

(3) After receiving the session establishment response message, the B2BUA unit judges whether the called terminal is a refresher, if yes, execute step (4), otherwise, use itself as the refresher, and execute step (4);

(4) The B2BUA unit adds a refresher parameter in the Session-Expires header field in the session establishment response message returned to the calling terminal, and sets refresher as the uas of the user agent server.

In order to facilitate the understanding of the present invention, the following specific examples are given to further illustrate the technical solutions of the present invention.

As shown in FIG. 5A, the processing flow for implementing resource release in Embodiment 1 is as follows:

In this embodiment, the refresher is B2BUA1, and B2BUA1 initiates a session update request to the calling and called terminals.

Step 500, the calling terminal sends a session establishment request message to the B2BUA1 unit.

Step 501, when the B2BUA1 unit receives the session establishment request message, the UAS side of the B2BUA1 unit checks whether the message contains the supported:timer header field.

If there is a supported:timer header field in the session establishment request message, skip this process; otherwise, process the message with the Session Timers protocol.

The specific process of processing the message with the Session Timers protocol is as follows:

If the value of the Session-Expires header field is smaller than the value of the local Min_SE header field, if there is a Min_SE header field in the message, increase the value of the Min_SE header field in the message to be equal to the value of the local Min_SE header field and use it as the Session-Expires header The value of the field, if there is no Min_SE header field in the message, insert the Min_SE header field in the request message, its value is the value of the local Min_SE header field, and use this value as the value of Session-Expires.

If the value of the Session-Expires header field is not less than the value of the local Min_SE header field, the processing method is the same as that of the prior art.

The UAC side of the B2BUA1 unit inserts the supported:timer header field into the message according to the session establishment request message processed by the UAS side, and sets the parameter refresher in the Session-Expires header field to referher=uac to construct a new session establishment request message.

Step 502, the B2BUA1 unit sends the processed session establishment request message to the PROXY unit.

Step 503, the PROXY unit sends the received session establishment request message to the AS (B2BUA2) unit.

Step 504, the B2BUA2 unit receives the session establishment request message, and the UAS side of the B2BUA2 unit compares the value of the Session-Expires header field with the value of the local Min_SE header field. If the value of the Session-Expires header field is small, it will reply to the B2BUA1 unit with a response indicating that the session update interval is too short and include the value of the local Min_SE header field in the response, and B2BUA1 will send the value of the Session-Expires header field after receiving the response Change it to the value of the Min_SE header field and send it to the B2BUA2 unit.

If the value of the Session-Expires header field is not less than the value of the local Min_SE header field, the processing method is the same as that of the prior art.

The UAC side of the B2BUA2 unit constructs a new request message according to the session establishment request message processed by the UAS side.

Step 505, the B2BUA2 unit sends the processed session establishment request message to the called terminal.

Step 506, the called terminal sends a 200 response message indicating success to the B2BUA2 unit.

Step 507, when unit B2BUA2 receives the 200 response message, the UAC side of unit B2BUA2 does not start the session timeout release timer and session update timer according to the value of the Session-Expires header field and the refresher parameter in the response message.

The UAS side of the B2BUA2 unit starts the session timeout release timer according to the value of the Session-Expires header field, and does not start the session update timer.

Step 508, the B2BUA2 unit sends the 200 response message sent by the called terminal to the PROXY unit.

Step 509, the PROXY unit sends the received 200 response message to the AS (B2BUA1 unit).

Step 510, when unit B2BUA1 receives a 200 response message, the UAC side of unit B2BUA1 starts a session timeout release timer and a session update timer according to the value of the Session-Expires header field and the refresher parameter in the response message.

The UAS side of the B2BUA1 unit starts the session timeout release timer and the session update timer according to the value of the Session-Expires header field.

The UAS end of the B2BUA1 unit inserts the supported:timer header field into the 200 response message, and sets the parameter refresher in the Session-Expires header field to referher=uas.

Step 511, the B2BUA1 unit sends a 200 response message to the calling terminal. After the calling terminal receives the 200 response message, the session is successfully established, and the Session Timers protocol is also successfully negotiated.

Step 512: According to the parameter refresher=uas determined during the negotiation, the B2BUA1 unit UAS end session update timer expires (SessionExpires/2) seconds to notify the B2BUA1 unit to send a session update request to the calling terminal.

Step 513, the calling terminal receives a session update request, and returns a 200 response message to B2BUA1.

Step 514, unit B2BUA1 receives the 200 response message, and judges whether the session is active according to the rule of the refresher. If the session is active, refresh the session timeout release timer and session update timer, wait until the next (SessionExpires/2) seconds to send a session update request to the calling terminal, until the entire session ends normally, and the Session Timers protection terminates ; If it is in an inactive state, it will actively send an end command, release the resources allocated by itself for the session, and end the connection.

Step 515: According to the parameter refresher=uac determined during the negotiation, the session update timer on the UAC side of the B2BUA1 unit has expired (SessionExpires/2) seconds to notify the B2BUA1 unit to send a session update request to the PROXY unit.

Step 516, the PROXY unit sends the received session update request to the AS (B2BUA2 unit).

Step 517, the B2BUA2 unit receives the session update request and judges that the supported:timer header field is included in the message, performs related processing on the message and sends the message to the called terminal.

The relevant processing of the session update message by the B2BUA2 unit is the same as in the prior art.

Step 518, the called terminal returns a 200 response message to the B2BUA2 unit upon receipt of the session update request.

Step 519, unit B2BUA2 receives the 200 response message, and judges whether the session is active according to the rules of the proxy server. If the session is active, refresh the session timeout release timer; if it is inactive, directly release the resources allocated by itself for the session, and end the connection.

Step 520, the B2BUA2 unit sends the received 200 response message to the PROXY unit.

Step 521, the PROXY unit sends the received 200 response message to the AS (B2BUA1 unit).

Step 522, the UAC end of the B2BUA1 unit receives the 200 response message, and judges whether the session is in an active state according to the rules of the refresher. If the session is active, refresh the session timeout release timer and session update timer, wait until the next (Session Expires/2) seconds and then send a session update request to the PROXY unit, until the entire session ends normally, Session Timers protection Termination; if it is in an inactive state, it will actively send a session release request to the calling terminal and the PROXY unit, and release the resources allocated by itself for the session, and end the connection. After receiving the request, the PROXY unit releases the resources allocated for the session by itself resources and send the request to the B2BUA2 unit, and the B2BUA2 unit releases the resources allocated for the session after receiving the request.

As shown in FIG. 5B , the processing flow for implementing resource release in Embodiment 2 is as follows:

In this embodiment, the refresher is the called terminal, and the called terminal initiates a session update request.

Step 5000, the calling terminal sends a session establishment request message to the B2BUA1 unit.

Step 5001, when the B2BUA1 unit receives the session establishment request message, the UAS side of the B2BUA1 unit checks whether the message contains the supported:timer header field.

If there is a supported:timer header field in the session establishment request message, skip this process; otherwise, process the message with the Session Timers protocol.

The steps for processing the Session Timers protocol include:

If the value of the Session-Expires header field is smaller than the value of the local Min_SE header field, if there is a Min_SE header field in the message, increase the value of the Min_SE header field in the message to be equal to the value of the local Min_SE header field and use it as the Session-Expires header The value of the field, if there is no Min_SE header field in the message, insert the Min_SE header field in the request message, its value is the value of the local Min_SE header field, and use this value as the value of Session-Expires.

If the value of the Session-Expires header field is not less than the value of the local Min_SE header field, the processing method is the same as that of the prior art.

The UAC end of the B2BUA1 unit inserts the supported:timer header field into the message according to the session establishment request message processed by the UAS end, and constructs a new session establishment request message.

Step 5002, the B2BUA1 unit sends the processed session establishment request message to the PROXY unit.

Step 5003, the PROXY unit sends the received session establishment request message to the AS (B2BUA2 unit).

Step 5004, when the B2BUA2 unit receives the session establishment request message, the UAS side of the B2BUA2 unit compares the value of the Session-Expires header field with the value of the local Min_SE header field. If the value of the Session-Expires header field is small, it will reply to the B2BUA1 unit with a response indicating that the session update interval is too short and include the value of the local Min_SE header field in the response, and B2BUA1 will send the value of the Session-Expires header field after receiving the response Change it to the value of the Min_SE header field and send it to the B2BUA2 unit.

If the value of the Session-Expires header field is not less than the value of the local Min_SE header field, the processing method is the same as that of the prior art.

The UAC side of the B2BUA2 unit constructs a new session establishment request message according to the session establishment request message processed by the UAS side.

Step 5005, the B2BUA2 unit sends the processed session establishment request message to the called terminal.

Step 5006, the called terminal sends a 200 response message indicating success to the B2BUA2 unit, and inserts the supported:timer header field into the response message, and sets the parameter refresher in the Session-Expires header field as refresher=uas.

Step 5007, when unit B2BUA2 receives the 200 response message, the UAC side of unit B2BUA2 starts the session timeout release timer and does not update the session timer according to the value of the Session-Expires header field and the refresher parameter in the response message.

The UAS side of the B2BUA2 unit does not start the session timeout release timer and session update timer according to the value of the Session-Expires header field.

Step 5008, the B2BUA2 unit sends the 200 response message sent by the called terminal to the PROXY unit.

Step 5009, the PROXY unit sends the received 200 response message to the AS (B2BUA1 unit).

Step 5010, when the B2BUA1 unit receives the 200 response message, the UAC side of the B2BUA1 unit starts the session timeout release timer according to the value of the Session-Expires header field and the refresher parameter in the response message, but does not start the session update timer.

The UAS side of the B2BUA1 unit does not start the session timeout release timer and session update timer according to the value of the Session-Expires header field.

Step 5011, the B2BUA1 unit sends a 200 response message to the calling terminal. After the calling terminal receives the 200 response message, the session is successfully established, and the Session Timers protocol is also successfully negotiated.

Step 5012, according to the parameter refresher=uas set by the refresher through negotiation, the called terminal notifies the called terminal to send a session update request to the B2BUA2 unit after the session update timer of the called terminal expires (SessionExpires/2) seconds.

Step 5013: After receiving the session update request, the B2BUA2 unit judges that the message contains the support:timer header field, performs related processing on the message, and sends the message to the PROXY unit.

The relevant processing of the session update request by the B2BUA2 unit is the same as in the prior art.

Step 5014, the PROXY unit sends the received session update request to the AS (B2BUA1 unit).

Step 5015, after receiving the session update request, the B2BUA1 unit judges that the message contains the support:timer header field, performs related processing on the message, and sends the message to the calling terminal.

The relevant processing of the session update request by the B2BUA1 unit is the same as that in the prior art.

Step 5016, the calling terminal returns a 200 response message to the B2BUA1 unit after receiving the session update message.

Step 5017, the B2BUA1 unit receives the 200 response message, and judges whether the session is active according to the rules of the proxy server. If the session is active, refresh the session timeout release timer; if it is inactive, directly release the resources allocated by itself for the session, and end the connection.

Step 5018, the B2BUA1 unit sends the received 200 response message to the PROXY unit.

Step 5019, the PROXY unit sends the received 200 response message to the AS (B2BUA2 unit).

Step 5020, unit B2BUA2 receives the 200 response message, and judges whether the session is active according to the rules of the proxy server. If the session is active, refresh the session timeout release timer; if it is inactive, directly release the resources allocated by itself for the session, and end the connection.

Step 5021, the B2BUA2 unit sends the received 200 response message to the called terminal.

After receiving the 200 response message, the called terminal judges whether the session is active according to the rules of the refresher. If the session is in an active state, the session timeout release timer is refreshed, and the Session Timers complete the session update, and then send a session update request to the B2BUA2 unit after (SessionExpires/2) seconds until the entire session ends normally, and the Session Timers protection terminates; If it is in an inactive state, it will actively send a session release request to the B2BUA2 unit, and release the resources allocated by itself for the session, and end the connection. Send it to the PROXY unit. After receiving the request, the PROXY unit releases the resources allocated by itself for the session and sends the request to the B2BUA1 unit. After receiving the request, the B2BUA1 unit releases the resources allocated by itself for the session.

As shown in Figure 6, the processing flow of the third embodiment is as follows:

Step 600, the calling terminal sends a session establishment request message to the B2BUA1.

Step 601, when the B2BUA1 unit receives the session establishment request message, the UAS side of the B2BUA1 unit checks whether the message contains the supported:timer header field.

If there is no supported:timer header field in the session establishment request message, skip this process; otherwise, process the message with the Session Timers protocol.

The steps for processing the Session Timers protocol include:

If the value of the Session-Expires header field is less than the value of the local Min_SE header field, a response indicating that the session update interval is too short is sent to the calling terminal and the value of the locally allowed Min_SE header field is included in the response, and the calling terminal receives After replying the response, change the value of the Session-Expires header field to the value of the Min_SE header field, and send it to the B2BUA1 unit again.

If the value of the Session-Expires header field is not less than the value of the local Min_SE header field, the processing method is the same as that of the prior art.

The UAC side of the B2BUA1 unit constructs a new session establishment request message according to the session establishment request message processed by the UAS side.

Step 602, the B2BUA1 unit sends the processed session establishment request message to the PROXY unit.

Step 603, the PROXY unit sends the received session establishment request message to the AS (B2BUA2 unit).

Step 604, the UAS end of the B2BUA2 unit receives the session establishment request message and checks the value of the Session-Expires header field. If the value of the Session-Expires header field is less than the value of the local Min_SE header field, the B2BUA1 will reply to the calling terminal with a response indicating that the session update interval is too short and include the value of the locally allowed Min_SE header field in the response, and the calling terminal After receiving the response, change the value of the Session-Expires header field to the value of the Min_SE header field and send it again.

If the value of the Session-Expires header field is not less than the value of the local Min_SE header field, the processing method is the same as that of the prior art.

The UAC side of the B2BUA2 unit constructs a new session establishment request message according to the session establishment request message processed by the UAS side.

Step 605, the B2BUA2 unit sends the session establishment request message to the called terminal.

Step 606: If the called terminal agrees to send the request message sent by the B2BUA2 unit, it sends a 200 response message indicating success to the B2BUA2 unit.

Step 607, when unit B2BUA2 receives a 200 response message, the UAC side of unit B2BUA2 does not start the session timeout release timer and session update timer according to the value of the Session-Expires header field and the refresher parameter in the response message.

The UAS side of the B2BUA2 unit starts the session timeout release timer according to the value of the Session-Expires header field, and does not start the session update timer.

Step 608, the B2BUA2 unit sends the 200 response message sent by the called terminal to the PROXY unit.

Step 609, the PROXY unit sends a 200 response message to the AS (B2BUA1 unit).

Step 610, when the B2BUA1 unit receives the 200 response message, the UAC side of the B2BUA1 unit does not start the session timeout release timer and the session update timer according to the value of the Session-Expires header field and the refresher parameter in the response message.

The UAS side of the B2BUA1 unit starts the session timeout release timer according to the value of the Session-Expires header field, and does not start the session update timer.

Step 611, the B2BUA1 unit sends the 200 response message sent by the PROXY unit to the calling terminal. After the calling terminal receives the 200 response message, the session is successfully established, and the session timers are also successfully negotiated.

Step 612 , according to the parameter refresher=uac set in session negotiation, the calling terminal's session update timer expires (SessionExpires/2) seconds to notify the calling terminal to send a session update request to the B2BUA1 unit.

Step 613: After receiving the session update request, the B2BUA1 unit judges that the message contains the support:timer header field, performs related processing on the message, and sends the message to the PROXY unit.

The relevant processing of the session update request by the B2BUA1 unit is the same as that in the prior art.

Step 614, the PROXY unit sends the received session update request to the AS (B2BUA2 unit).

Step 615: After receiving the session update request, the B2BUA2 unit judges that the message contains the support:timer header field, performs related processing on the message, and sends the message to the called terminal.

The relevant processing of the session update request by the B2BUA2 unit is the same as in the prior art.

Step 616, the called terminal returns a 200 response message to the B2BUA2 unit after receiving the session update message.

Step 617, unit B2BUA2 receives the 200 response message, and judges whether the session is active according to the rules of the proxy server. If the session is active, refresh the session timeout release timer; if it is inactive, directly release the resources allocated by itself for the session, and end the connection.

Step 618, the B2BUA2 unit sends the received 200 response message to the PROXY unit.

Step 619, the PROXY unit sends the received 200 response message to the AS (B2BUA1 unit).

Step 620, the B2BUA1 unit receives the 200 response message, and judges whether the session is active according to the rules of the proxy server. If the session is active, refresh the session timeout release timer; if it is inactive, directly release the resources allocated by itself for the session, and end the connection.

Step 621, the B2BUA1 unit sends the received 200 response message to the calling terminal.

After receiving the 200 response message, the calling terminal judges whether the session is active according to the rules of the refresher. If the session is in an active state, the session timeout release timer is refreshed, and the Session Timers complete the session update, and then send a session update request to the B2BUA1 unit after (SessionExpires/2) seconds until the entire session ends normally, and the Session Timers protection terminates; If it is in an inactive state, it will actively send a session release request to the B2BUA1 unit, and release the resources allocated by itself for the session, and end the connection. After receiving the request, the B2BUA1 unit releases the resources allocated for the session by itself and sends the request Send it to the PROXY unit. After receiving the request, the PROXY unit releases the resources allocated by itself for the session and sends the request to the B2BUA2 unit. After receiving the request, the B2BUA2 unit releases the resources allocated by itself for the session.

In the embodiment shown in Figure 6, the calling terminal sends a session update request, and the refresher parameter is uac during negotiation, and each B2BUA unit will not start the session update request timer, and will not generate a new session update request after receiving the session update request. session update request, thereby avoiding the forwarding of redundant session update requests in FIG. 1A and FIG. 1B , and solving the problem of message collision in FIG. 1B at the same time.

In the embodiment shown in FIG. 7 , the called terminal sends a session update request, and the refresher parameter is uas during negotiation, but the direction of sending the request message is changed from that in FIG. 6 .

As shown in Figure 7, the processing flow of the fourth embodiment is as follows:

In steps 700 to 711 and steps 600 to 611, except the parameter refresher=uas set in the session negotiation, the called terminal sends a session update request, and the UAS ends of the B2BUA1 and B2BUA2 units start the session timeout release timer, and other steps same.

Step 712: According to the parameter refresher=uas set in the session negotiation, the called terminal notifies the called terminal to send a session update request to the B2BUA2 unit after the session update timer of the called terminal expires (SessionExpires/2) seconds.

Step 713: After receiving the session update request, the B2BUA2 unit judges that the message contains the support:timer header field, performs related processing on the message, and sends the message to the PROXY unit.

The relevant processing of the session update request by the B2BUA2 unit is the same as in the prior art.

Step 714, the PROXY unit sends the received session update request to the AS (B2BUA1 unit).

Step 715: After receiving the session update request, the B2BUA1 unit judges that the message contains the support:timer header field, performs related processing on the message, and sends the message to the calling terminal.

The relevant processing of the session update request by the B2BUA1 unit is the same as that in the prior art.

Step 716, the calling terminal returns a 200 response message to the B2BUA1 unit after receiving the session update message.

Step 717, the B2BUA1 unit receives the 200 response message, and judges whether the session is active according to the rules of the proxy server. If the session is active, refresh the session timeout release timer; if it is inactive, directly release the resources allocated by itself for the session, and end the connection.

Step 718, the B2BUA1 unit sends the received 200 response message to the PROXY unit.

Step 719, the PROXY unit sends the received 200 response message to the AS (B2BUA2 unit).

Step 720, unit B2BUA2 receives the 200 response message, and judges whether the session is active according to the rules of the proxy server. If the session is active, refresh the session timeout release timer; if it is inactive, directly release the resources allocated by itself for the session, and end the connection.

Step 721, the B2BUA2 unit sends the received 200 response message to the called terminal.

After receiving the 200 response message, the called terminal judges whether the session is active according to the rules of the refresher. If the session is in an active state, the session timeout release timer is refreshed, and the Session Timers complete the session update, and then send a session update request to the B2BUA2 unit after (SessionExpires/2) seconds until the entire session ends normally, and the Session Timers protection terminates; If it is in an inactive state, it will actively send a session release request to the B2BUA2 unit, and release the resources allocated by itself for the session, and end the connection. Send it to the PROXY unit. After receiving the request, the PROXY unit releases the resources allocated by itself for the session and sends the request to the B2BUA1 unit. After receiving the request, the B2BUA1 unit releases the resources allocated by itself for the session.

Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalent technologies, the present invention also intends to include these modifications and variations.

Claims (7)

1. A method for implementing resource release, the method comprising:

after receiving the request message for establishing the session, judging whether the request message contains a Supported head domain with a time timer label, if so, forwarding the request message for establishing the session, otherwise, adding the Supported head domain with the time timer label in the message, and forwarding the request message for establishing the session;

in the session establishment process, carrying out refresher negotiation between node devices, and determining one node device as a refresher;

after the session is established, the node device determined by the negotiation to be the refresher sends a session update request to the other network node.

2. The method of claim 1, wherein after the session is established, the method further comprises:

after each node device receives the session updating request, whether the session updating request contains a Supported head field with a timer label is judged, and if yes, the session updating request is sent to the next node device where the session is routed according to the received session updating request.

3. The method of claim 1, wherein a refresher negotiation is performed between the node devices, and wherein the step of determining a node device as a refresher comprises:

a11, back-to-back user agent device B2BUA unit adds refresher parameter in Session termination Session-Expires header field in the Session establishment request message forwarded to the node equipment where the Session is established, and sets refresher as user agent client uac for indicating that the B2BUA unit is responsible for initiating Session update request to the called terminal;

a12, after receiving the request message, the called terminal determines that it is not a refresher, and returns a response message for establishing the session to the B2BUA through the node device;

after the a13 and the B2BUA unit receive the Session establishment response message, determine that the self is a refresher, add a refresher parameter in the Session-Expires header field in the Session establishment response message replied to the calling terminal, and set refresher as the uas of the user agent server.

4. The method of claim 1, wherein a refresher negotiation is performed between the node devices, and wherein the step of determining a node device as a refresher comprises:

the A21, B2BUA unit sends the request message of establishing conversation to the node equipment that the conversation establishes the way, contain the Supported head field with timer label, after every node equipment receives the request message of establishing conversation, forward to the next node equipment, until the called terminal;

a22, after the called terminal receives the request message for establishing the conversation, if the called terminal determines itself to be a refresher, a response message for establishing the conversation is returned to the B2BUA through the node device, wherein the Session-Expires header field is uas, if the called terminal determines itself not to be a refresher, the response message for establishing the conversation which itself is not a refresher is returned to the B2BUA through the node device;

a23, after receiving the response message of session establishment, the B2BUA unit judges whether the called terminal is refresher, if yes, the step A24 is executed, otherwise, the B2BUA unit takes itself as refresher and executes the step A24;

the A24, the B2BUA unit adds refresh parameter in Session-Expires header field in Session establishment response message replied to the calling terminal, and sets refresh as user agent server end uas.

5. The method according to claim 4, wherein the session setup response message that is not itself a refresher in step A22 is a session setup response message that does not contain a Supported header field with a timer label;

the Session establishment response message that is not itself a refresher in step a22 is a Session establishment response message containing a Supported header field with a timer label, where refresh of the Session-Expires header field is uas.

6. A system for implementing resource release, the system comprising: one or more back-to-back user agent device B2BUA units;

each B2BUA unit comprises a session protocol judging module, a resource releasing module, a refresher negotiation module and a session updating request module; wherein,

a session protocol judging module, configured to judge whether a received session establishment request message contains a Supported head domain with a timer label, and if so, directly forward the session establishment request message, otherwise, add the Supported head domain with the timer label to the session establishment request message, and forward the session establishment request message;

the resource releasing module is used for judging whether the session state is normal according to the received session updating response message, and releasing the resources which are distributed for the session when the session is in the inactive state;

a refresher negotiation module, configured to add a refresher parameter to a Session-Expires header field in the Session establishment request message, and determine whether the refresher parameter is a refresher according to the received Session establishment response message;

the session updating request module is used for respectively initiating session updating requests to network nodes where the session is established at two sides if the session is established and the session is determined to be a refresher; if the network node is determined not to be a refresher, judging whether the received session updating request contains a Supported head field with a timer label, if so, only sending the session updating request to the next network node where the session is routed.

7. A back-to-back user agent apparatus, comprising:

a session protocol judging module, configured to judge whether a received session establishment request message contains a Supported head domain with a timer label, and if so, directly forward the session establishment request message, otherwise, add the Supported head domain with the timer label to the session establishment request message, and forward the session establishment request message;

the resource releasing module is used for judging whether the session state is normal according to the received session updating response message, and releasing the resources which are distributed for the session when the session is in the inactive state;

a refresher negotiation module, configured to add a refresher parameter to a Session-Expires header field in the Session establishment request message, and determine whether the refresher parameter is a refresher according to the received Session establishment response message;

the session updating request module is used for respectively initiating session updating requests to network nodes where the session is established at two sides if the session is established and the session is determined to be a refresher; if the network node is determined not to be a refresher, judging whether the received session updating request contains a Supported head field with a timer label, if so, only sending the session updating request to the next network node where the session is routed.

Images