WO2008025216A1

WO2008025216A1 - Method and system for realizing release of resource

Info

Publication number: WO2008025216A1
Application number: PCT/CN2007/002314
Authority: WO
Inventors: Weiqiang Yang
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-08-28
Filing date: 2007-08-01
Publication date: 2008-03-06
Also published as: CN101137104A; CN101137104B

Abstract

A method for realizing the release of resource. The method includes: after the back-to-back user agent B2BUA unit receiving the establishing session request message of the Supported head field without the timer label, then adding the Supported head field with timer label into the request message; making refresher treat between the node device, informing the node device through which this session across that do not start the updating session request except the refresher; after establishing the session, determining the node device of the refresher separately to start the updating session request to the node device through which this session across by treating, this session connects to the two sides of itself. By the solution, it solves the matter of the transfer of the meaningless session update request during the session and the message conflict, thereby realizes the calling and the called terminal do not support the session timers protocol, and also can release the resource. The embodiment also discloses a system for realizing the release of resource.

Description

Method and system for realizing resource release

Technical field

The present invention relates to the field of communications technologies, and in particular, to a method and system for implementing resource release. Background technique

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

IMS is a voice and data service system that can shield users' access methods and control the openness of service capabilities according to user data, thus providing a multimedia communication experience. And IMS, which combines innovative voice, data, and multimedia applications, can generate new services such as presence services, multimedia chat, conferencing, push to talk, and push to conference.

The main functions in IMS include call control (CSCF) for controlling user registration, session control, etc., and media gateway control/IMS media gateway function (MGCF I IM-MGW) for interworking with circuit-switched networks.

The main devices in the IMS include an application server (AS) that provides various business logic control functions and a home subscriber server (HSS) for centrally managing user subscription data.

Among them, the CSCF is divided into: a current local proxy node (P-CSCF), a registered home domain service node (S-CSCF), and an information node (I-CSCF) according to functions in the network. The P-CSCF is the access point of the user in the IMS system, and all SIP signaling flows from the UE or to the UE must pass through the P-CSCF.

The I-CSCF is the point of contact for all users connected to this carrier in an operator network.

The S-CSCF is in the core control position in the IMS core network and is located in the home network. Responsible for the UE Registration authentication and session control, performing basic session routing functions for the calling end and the called end IMS user, and triggering corresponding rules according to the IMS signed by the user.

The user accesses the IMS through the current local proxy node P-CSCF, 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 registered place; the IMS uses the SIP protocol as the application layer interaction signaling. The interface protocol between the terminal and the CSCF, between the CSCF, and between the CSCF and the AS is the SIP protocol. However, the SIP protocol does not define a protocol that enables the intermediate node to detect whether the session is active after the session is established. This causes the intermediate node in the IMS system to fail to release the resource when the terminal sends a release indication message. The Session Timers protocol complements the SIP protocol for this issue and is an extension of the SIP protocol. The Session Timers protocol allows a terminal in the session to initiate a session update request periodically to ensure that the session is active. If the session update request is not received within the period or the session update request fails to be sent, the session is already inactive. Then the terminal releases the relevant resources. Intermediate nodes in the IMS system, such as the P-CSCF or S-CSCF, directly release the session-related resources after a timeout. This ensures the timely release of relevant resources.

According to the Session Timers protocol, it is convenient to implement as a proxy server (PROXY). For example, P-CSCF and S-CSCF are usually only used as PROXY units. However, for the AS, which is usually used as a back-to-back user agent (B2BUA) unit, the Session Timers protocol is not specified. If the protocol is directly hardened, the session update request is repeatedly meaninglessly forwarded or collided during the session. It cannot be implemented smoothly, so the resource release problem of the B2BUA unit has not been solved well.

FIG. 1 is a schematic diagram of a process of meaningless forwarding of a session update request 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 header field, and may also include a supported (timer) header field and/or a minimum session termination (Min_SE) header field.

If there is a PROXY unit between the calling terminal and 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 by the Session Timers protocol.

The User Agent Server (UAS) side of the B2BUA1 unit checks if there is a supported :timer header field in the message.

If the session establishment request message has a supported:timer header field and the value of the Session-Expires header field is less than the value of the local Min_SE header field, a response is sent to the calling terminal indicating that the session update interval is too short and is in response With the value of the local Min_SE header field, after receiving the reply response, the calling terminal changes the value of the Session-Expires header field to a value 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 have a 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, when there is an Mm_SE header field in the message, the message will be in the Min_SE The value of the header field is increased to be equal to the value of the local Min_SE header field and is the value of the Session-Expires header field. When 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 local Mm— The value of the SE header field, and this value is used as the value of the Session-Expires header field.

Regardless of whether the session establishment request has a 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 the Session-Expires may not be modified or may be not less than The value of the Min_SE header field in the message is not less than the value of the local Mm_SE header field, and the value of the Session-Expires header field is appropriately reduced.

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.

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 a 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 a Session Timers protocol. The relevant processing.

The processing is the same as the processing 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 B2BUA2 and the called terminal, the PROXY unit will receive

200 response message is forwarded.

Step 107: The B2BUA2 unit receives the 200 response message and performs related processing specified by 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 and the refresher parameter in the response message. Therefore, the UAC end of the B2BUA2 unit starts the session update request timer and the timeout release timing. Timer.

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

The session negotiation sets the refresher to uac, so the UAS end of the B2BUA2 unit does not start the send session update request timer.

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 sends the message directly to B2BUA1.

Step 110: The B2BUA1 unit receives the 200 response message for related processing specified by the Session Timers protocol.

The processing is the same as the processing 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 negotiated successfully. The session update timer of the calling terminal starts timing. Step 112: According to the parameter determined by the negotiation, the refresher is uac, and the calling terminal is responsible for initiating the session update request, and then the session update timer of the calling terminal expires (Session Expires / 2) seconds to notify the calling terminal to issue a session update to the B2BUA1 unit. request.

Step 113: According to the parameter determined during negotiation, the refresher is uac, and the UAC end of the B2BUA1 unit is responsible for initiating a session update request, and the session update timer of the B2BUA1 unit expires (SesExpires / 2) seconds to notify the UAC end of the B2BUA1 unit to issue a session to the PROXY unit. Update request.

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

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

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

Step 117: According to the parameter determined by the negotiation, the refresher is uac, and the UAC end of the B2BUA2 unit is responsible for initiating a session update request, and the session update timer of the B2BUA2 unit expires (SessionExpires / 2) seconds to notify the B2BUA2 unit to issue 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 the session update request to the called terminal.

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

FIG. 1B is a schematic diagram of a collision process for issuing a session update request by a calling terminal.

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 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 by the Session Timers protocol.

The UAS end of the B2BUA1 unit checks whether the message has the supported:timer header field.

If the session establishment request message has a supported:timer header field, and Session-Expires If the value of the header field is smaller than the value of the local Min_SE header field, the response is sent to the calling terminal indicating that the session update interval is too short, and the value of the local Min SE header field is brought in the response, and the calling terminal receives the reply response. Change the value of the Session-Expires header field to a value no smaller than the Min_SE header field and send it back to the B2BUA1 unit.

If the session establishment request message does not include the supported:timer header field, it indicates that the calling terminal does not support the Session Timers protocol, and the Session-Expires header i or the threshold is smaller than the local Min SE header field threshold, and there is a Min_SE in the message. In the header field, the value of the Mm_SE header field in the request message is increased to be equal to the value of the local Min SE header field and used as the value of the Session-Expires header field. When there is no Min_SE header field in the message, the request message is inserted. The Min_SE header field, which is the value of the local Min_SE header field, and uses this value as the Session-Expires header; t or ^) value.

Regardless of whether the session establishment request message has a 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 the Session-Expires may not be modified or may be not less than The value of the Min-SE header field in the message is not less than the value of the local Mm_SE header field, and the value of the Session-Expires header field is appropriately reduced.

The UAC end of the B2BUA1 unit constructs a new request message according to the request message processed by the UAS. 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 a 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 by the Session Timers protocol.

The processing is the same as the processing 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 will receive The session establishment request message is forwarded.

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

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

Step 1007: The B2BUA2 unit receives the 200 response message to perform the specified related processing.

The UAC end of the B2BUA2 unit sets the refresher between the B2BUA2 and the called terminal according to the time and session negotiation of the Session-Expires header field in the response message.

Timer.

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

Session negotiation sets the refresher between B2BUA1 and B2BUA2 to refresh=uas, so

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 sends the message directly to B2BUA1.

Step 1010: The B2BUA1 unit receives the 200 response message for related processing specified by the Session Timers protocol.

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

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

The UAS end of the B2BUA1 unit starts the related 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 to refresh=uas, so the UAS end 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 negotiated successfully. The session update timer of the calling terminal starts timing.

Step 1012: According to the parameter refresher determined at the time of negotiation, between the calling terminal and B2BUA1, refresher=uac, between B2BUA1 and B2BUA2, refresher=uas, between B2BUA2 and the called terminal

The calling terminal is responsible for initiating a session update request, and the session update timer of the calling terminal (Session Expires / 2) seconds informs the calling terminal to issue a session update request to the B2BUA1 unit.

Step 1013: The B2BUA1 unit processes and processes the session update request sent by the calling terminal to the PROXY unit.

Step 1014: The PROXY unit sends a 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 the session update request to the called terminal.

Step 1016: According to the parameter refresher determined during the negotiation, the calling terminal reaches the refrers=uac between the B2BUA1, the refresher=uas between the B2BUA1 and the B2BUA2, and the refresher=uac between the B2BUA2 and the called terminal, then the B2BUA2 unit is responsible for initiating the session update request. The session update timer of the B2BUA2 unit expires (SessionExpires / 2) seconds to notify the B2BUA2 unit to issue a session update request to the PROXY unit.

Step 1017: The PROXY unit sends a 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 the session update request to the calling terminal.

Step 1019: According to the parameter refresher determined during the negotiation, the calling terminal reaches the refrers=uac between the B2BUA1, the refresher=uas between the B2BUA1 and the B2BUA2, and the refresher=uac between the B2BUA2 and the called terminal, then the B2BUA2 unit is responsible for initiating the session update request. The session update timer of the B2BUA2 unit expires (SessionExpires / 2) seconds to notify the B2BUA2 unit to send a call to the called terminal. Update request.

As can be seen from Figure IB, on the B2BUA1 unit, the session update request of step 1012 and step 1017 collides, and the B2BUA1 unit forwards the redundant session update request.

In the prior art, it is also possible to issue a session update request from the called terminal, and the calling terminal is between resher=uas between B2BUA1, refreshher=uac between B2BUA1 and B2BUA2, and near the resher=uas, B2BUA2 unit between B2BUA2 and the called terminal. The session update request collides, and the B2BUA2 unit forwards the redundant session update request.

In summary, in the prior art, if the session is in an inactive state, the session resource needs to be released, and the calling terminal or the called terminal is required to have at least one session that supports the Session Timers protocol, and the calling terminal that supports the Session Timers protocol is Call a session update request from the terminal. 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, each B2BUA unit receives a session update request, and therefore cannot generate a new session update request because it cannot determine whether the request message is a session update or a normal service negotiation message. And sending the received session update request and the new session update request to the next B2BUA unit of the session establishment path until the called terminal. Similarly, if the session update request is sent by the called terminal, after receiving the session update request, each B2BUA unit also sends 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 forwards and initiates a session update request, the user terminal receives a large number of meaningless session update requests. If the B2BUA unit sends a new session update request to both sides after receiving the session update request, Will cause a collision of session update requests.

Summary of the invention

The main purpose of the embodiments of the present invention is to provide a method and a system for implementing resource release, so that when the terminal does not support the Session Timers protocol, the resource release can be implemented when the session is in an inactive state. Another object of the present invention is to provide a back-to-back user agent device, which is applied to a resource release system. When the terminal does not support the Session Timers protocol, if the session is in an inactive state, resource release can be implemented.

A method for implementing resource release according to an embodiment of the present invention includes:

After receiving the session establishment request message, the back-to-back user agent B2BUA unit determines whether the supported header field with the time timer tag is included. If yes, the session establishment request message is forwarded. Otherwise, the timer tag is added to the message. Supported header field, and forwards the session establishment request message;

The node device performs the refresher negotiation between the node devices to determine that the node device is the refresher. After the session is established, the node devices determined to be the refresher by the negotiation respectively initiate a session update request to the other network nodes.

A system for implementing resource release according to an embodiment of the present invention includes: one or more back-to-back user agent B2BUA units;

Each B2BUA unit is configured to: after receiving the session establishment request message, determine whether the supported header field with the time timer tag is included, and if yes, forward the session establishment request message; otherwise, add a timer to the message. The Supported header field of the label, and forwarding the session establishment request message; performing refresher negotiation with the node device to determine whether it is a refresher; if it is determined that it is a refresher, after the session is established, respectively The network nodes on which the session is routed on both sides of the connection initiate a session update request.

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

The session protocol judging module is configured to: after receiving the session establishment request message, determine whether the received session establishment request message has a Supported header field with a timer tag, and if yes, directly forward the session establishment request message, otherwise, Adding a Supported header field with a timer tag to the session establishment request message, and forwarding the session establishment request message;

a refresher negotiation module, configured to perform a refresher negotiation with the node device to determine whether it is a refresher;

The session update request module is configured to, if it is determined that it is a refresher, initiate a session update request to the network node of the current session on both sides connected to itself after the session is established. In the embodiment of the present invention, the B2BUA unit determined by the refresher negotiation initiates a session update request to the calling terminal and the called terminal, so that the resource release can be realized even if the calling terminal and the called terminal do not support the Session Timers protocol. The behavior of other B2BUA units actively initiating a session update request is cancelled, and only the request is forwarded after receiving the session update request. It avoids the problem of meaningless forwarding and collision of session update requests during the session. DRAWINGS

FIG. 1 is a schematic flowchart of a meaningless forwarding of a session update request issued by a calling terminal; FIG. 1B is a schematic flowchart of a session update request collision of a session update request by a calling terminal; FIG. 2 is a system for releasing resources according to an embodiment of the present invention; Schematic;

3 is a schematic structural diagram of a B2BUA device according to an embodiment of the present invention;

4 is a schematic flowchart of a method for implementing resource release according to an embodiment of the present invention;

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

5B is a schematic flow chart of a specific embodiment 2 of the method for implementing the present invention;

6 is a schematic flow chart of a third embodiment of a method for implementing the method of the present invention;

7 is a schematic flow chart of a fourth embodiment of a method for implementing the present invention;

FIG. 8 is a schematic structural diagram of a B2BUA device performing a refresher negotiation according to an embodiment of the present invention. detailed description

In the embodiment of the present invention, the B2BUA unit of the refresher actively initiates a session update request, and the B2BUA unit of the refresher actively initiates a session update request. The other B2BUA units do not initiate a session update request, thereby solving the above problem. 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, thereby realizing that both the calling terminal and the called terminal do not support the Session Timers protocol, Successfully established the Session Timers protocol.

During the session establishment process, after receiving the session establishment request message, the B2BUA unit determines the session. Whether the support request header field with the time timer tag is included in the request message, if yes, the session establishment request message is directly forwarded to the next node device; if not, the timer tag is added to the session establishment request message. The Supported header field will be added again. The session establishment request message of the Supported header field with the timer tag is forwarded to the next node device.

During the session establishment process, the refresher negotiation can also be performed between the node devices. After the session is established, the refreshers determined by the negotiation respectively initiate a session update request to other node devices. After receiving the session update request, each node device sends a session update request to the 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 that it has allocated for the session.

After the session is established, after the B2BUA unit receives the session establishment request message, if it determines that the message contains the Supported header field with the timer tag, the session update request is no longer generated, and only the session update is sent to the next node device of the session path. request.

FIG. 2 is a schematic structural diagram of a system for releasing resources according to an embodiment of the present invention. As shown in FIG. 2, the system of the present invention includes: one or more B2BUA units,

Each B2BUA unit is configured to: after receiving the session establishment request from the previous node device, determine whether the session establishment request carries a Supported header field of the timer tag, and if so, forward the session establishment request message to the next node device. Otherwise, a Supported header field with a timer tag is added to the session establishment request message, and the session establishment request message is forwarded to the next node device; after the session is established, if the session is determined to be inactive, the self is released. 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 configured to determine whether the session update request has a Supported header field with a timer tag, and if so, only according to the received session update request to the session. The next network node sends a session update request.

As shown in FIG. 3, the B2BUA unit in the embodiment of the present invention includes: a session protocol determining module and a resource releasing module. The session protocol judging module is configured to determine whether the received session establishment request message has a support header field with a timer tag, and if yes, directly forward the session establishment request message, otherwise, add the session establishment request message. The Supported header field with a timer tag forwards the session establishment request message; the source release module is configured to update the response message according to the received session Determine whether the session state is normal, and release the resources allocated for the session when the session is inactive.

Of course, for the refresher negotiation, the B2BUA unit may further include: a refresher negotiation module and a session update request module. The refresher negotiation module is configured to add a refresher parameter in the session termination 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 After the session is established, if it is determined that it is a refresher, a session update request is initiated to each of the network nodes that have established the session on both sides; if it is determined that it is not a refresher, it is determined whether the received session update request is carried. The Supported header field of the timer tag, if yes, sends a session update request only to the next network node of the session path.

FIG. 4 is a schematic diagram of a process for implementing resource release by using a first B2BUA unit to receive a session update request. The first B2BUA unit is the first B2BUA unit that receives the session establishment request message during the session establishment process, and the other B2BUA units are similar to the first B2BUA unit method, and are not illustrated.

As shown in FIG. 4, the method for implementing resource release in the embodiment of the present invention includes:

Step 400: After receiving the session establishment request message, the first B2BUA unit determines whether the message includes a Supported header field with a timer tag. If yes, indicating that the calling terminal supports the Session Timers protocol, step 401 is performed; otherwise, directly The session is forwarded to the next node device until the called terminal, and step 407 is performed.

Step 401: After receiving the session establishment request message, the first B2BUA unit inserts the supported:timer header field in the session establishment request message, and the refresh-expires header field in the session establishment request message Set to uac.

Step 402: The first B2BUA unit sends a support:timer header field session establishment request message 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 to the B2BUA unit connected thereto. After the session establishment response message is received, each B2BUA unit only starts the session timeout release timer, and sends the session establishment response message to the B2BUA unit to the first B2BUA unit.

Step 405: After receiving the session establishment response message, if the first B2BUA unit determines that it is a refresher, insert a supported:timer header field in the session establishment response message, and set 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 sides.

Step 407: After receiving the session update request, each B2BUA unit determines whether the session update request includes a Supported header field with a timer tag. If yes, and directly forwards the session update request to the next node device, no new session is generated here. For the 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 thereto. After receiving the session establishment request message, each B2BUA unit starts the session timeout release timer and establishes the session. The response message is sent to the B2BUA unit at the first level 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 B2BUA unit connected thereto, and step 410 is performed.

Step 410: When each B2BUA unit determines that the session is in an inactive state, it releases the resources allocated by itself for the session.

The above steps 401 ~ 405 are the process of the refresher negotiation.

The node device can perform refresher negotiation according to its own situation and determine that it is a refresher.

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

The first way:

(1) The B2BUA unit adds a refresher parameter in the Session-Expires header field in the session establishment request message forwarded to the node device of the session establishment path, and sets the refresher refresher as the user agent client uac for indicating the present The B2BUA unit is responsible for initiating a session update request to the called terminal; (2) After the called terminal receives the session establishment request message and determines that it is not the refresher, the node device returns a session establishment response message to the B2BUA that is not the refresher.

(3) After receiving the session establishment response message, the B2BUA unit determines that it is a refresher, and adds a refresher parameter in the Session-Expires header field in the session establishment response message replied to the calling terminal, and sets the refresher to User agent server side uas.

The second way:

(1) The B2BUA unit sends the session establishment request message to the node device in the path establishment session, and the support header field with the timer tag is received. After receiving the session establishment request message, each node device forwards the message to the next node device. Until the called terminal;

(2) After the called terminal receives the session establishment request message, if it determines that it is a refresher, the node device returns a session establishment response message to the B2BUA, where the Session-Expires header field is uas, and if it is determined that it is not refreshed Then, the node device returns a session establishment response message to the B2BUA that is not the refresher.

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

(4) The B2BUA unit adds a refresher parameter in the Session-Expires header field in the session establishment response message replied to the calling terminal, and sets the refresher to the user proxy server side uaS o

In order to facilitate the understanding of the present invention, the technical solutions of the present invention will be further described below by way of specific examples. As shown in FIG. 5A, the process of implementing resource release in the first embodiment is as follows:

In this embodiment, the refresher is B2BUA1, and the 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: The B2BUA1 unit receives the session establishment request message, and the UAS end of the B2BUA1 unit checks whether the message carries the supported:timer header field.

If there is a supported: timer header field in the session establishment request message, the flow is skipped. Otherwise, the message is processed by the Session Timers protocol. The specific process of processing the message by the Session Timers protocol is as follows:

If the value of the Session-Expires header field is less than the value of the local Min-SE header field, it exists in the message.

When the Min SE header field is used, the value of the Min_SE header field in the message is increased to be equal to the value of the local Min_SE header field and used as the value of the Session-Expires header field. When there is no Mm-SE header field in the message, the request is made. Insert the Min_SE header field into the message, which is the value of the local Min_SE header field, and treat the 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 in the prior art.

The UAC end of the B2BUA1 unit is configured according to the session establishment request message processed by the UAS, inserts the supported:timer header field in the message, and sets the parameter refresher in the Session-Expires header field to prefersher=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 end of the B2BUA2 unit compares the value of the Session-Expires header i or the value of the local Min SE header i or. ^ The value of the Session-Expires header field is small, and the response to the B2BUA1 unit indicates that the session update interval is too short and the value of the local Min_SE header field is brought in the response. After the B2BUA1 receives the reply response, the Session-Expires header field is obtained. The value is changed to the value of the Min_SE header field and sent to the B2BUA2 unit.

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

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: The B2BUA2 unit receives the 200 response message, and the UAC end of the B2BUA2 unit does not start the session timeout release timer according to the value of the Session-Expires header field and the refresher parameter in the response message. Session update timer.

The UAS end 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 a 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: The B2BUA1 unit receives the 200 response message, and the UAC end 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 and the refresher parameter in the response message.

The UAS end 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 in the 200 response message, and sets the reference #iefresher殳 in the Session-Expires header field to referenceher=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 negotiated successfully.

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

Step 513: The calling terminal receives the session update request, and returns a 200 response message to the B2BUA1. Step 514: The B2BUA1 unit receives the 200 response message, and determines whether the session is active according to the rules of the refresher. If the session is active, the session timeout release timer and the session update timer are refreshed, and the session update request is sent to the calling terminal until the next session (SesExpires / 2) seconds, until the entire session ends normally, and the Session Timers protection is terminated. If it is inactive, it will automatically send an end instruction, release its own resources allocated for the session, and end the connection.

Step 515: According to the parameter determined during negotiation, refresher = uac, the session update timer of the U2 end of the B2BUA1 unit (SessionExpires / 2) seconds informs the B2BUA1 unit to issue 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 judgment message, which includes a supported: timer header field, performs related processing on the message, and sends the message to the called terminal.

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

Step 518: The called terminal receives the session update request and replies to the B2BUA2 unit with a 200 response message. Step 519: The B2BUA2 unit receives the 200 response message, and determines whether the session is active according to the rules of the proxy server. If the session is active, the session timeout release timer is refreshed; if it is inactive, the resources allocated for the session are directly released, and the connection is terminated.

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 determines whether the session is active according to the rules of the refresher. If the session is active, refresh the session timeout release timer and the session update timer, and wait until the next (Session Expires / 2) seconds to issue a session update request to the PROXY unit until the entire session ends normally. Session Timers protection Termination; if inactive, actively send the session release request to the calling terminal and the PROXY unit, and release the resources allocated for the session, terminate the connection, and the PROXY unit releases the request for the session after receiving the request. The resource is sent to the B2BUA2 unit, and the B2BUA2 unit releases the resource allocated for the session after receiving the request.

As shown in FIG. 5B, the process of implementing resource release in the second embodiment 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: The B2BUA1 unit receives the session establishment request message, and the UAS end of the B2BUA1 unit checks whether the message carries the supported:timer header field.

If there is a supported:timer header field in the session establishment request message, the flow is skipped. Otherwise, the session is processed by 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, when the Min SE header field exists in the message, the value of the Min SE header field in the message is increased to the value of the local Min SE header field. And as the value of the Session-Expires header field, when 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 the value is made The value for Session-Expires.

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

The UAC end of the B2BUA1 unit inserts a supported:timer header field into the message according to the session establishment request message processed by the UAS, 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: The B2BUA2 unit receives the session establishment request message, and the UAS end of the B2BUA2 unit compares the value of the Session-Expires header i or the value of the local Min SE header i or. ^ The value of the Session-Expires header field is small, and the B2BUA1 unit is replied with a response indicating that the session update interval is too short and the value of the local Mm_SE header field is brought in the response. After the B2BUA1 receives the reply response, the Session-Expires header field is received. The value is changed to the value of the Min_SE header field and sent to the B2BUA2 unit.

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

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 a supported: timer header field in the response message, and sets the parameter refresher in the Session-Expires header field to refresher=uas.

Step 5007: The B2BUA2 unit receives the 200 response message, and the UAC end of the B2BUA2 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, and does not update the session timer.

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

Step 5008: The B2BUA2 unit sends a 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: The B2BUA1 unit receives the 200 response message, and the UAC end 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, and does not start the session update timer.

The UAS end 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.

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 negotiated successfully.

Step 5012: According to the parameter refresher=uas set by the refresher, the session update timer of the called terminal passes (SessionExpires / 2) seconds to notify the called terminal to issue a session update request to the B2BUA2 unit.

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

The processing related to 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 determines that the message includes a support:timer header field, performs related processing on the message, and sends the message to the calling terminal.

The processing related to the session update request by the B2BUA1 unit is the same as in the prior art.

Step 5016: The calling terminal receives the session update message and replies to the B2BUA1 unit with a 200 response message. Step 5017: The B2BUA1 unit receives the 200 response message, and determines whether the session is active according to the rules of the proxy server. If the session is active, the session timeout release timer is refreshed; if it is inactive, the resources allocated for the session are directly released, and the connection is terminated.

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: The B2BUA2 unit receives the 200 response message, and determines whether the session is active according to the rules of the proxy server. If the session is active, the session timeout release timer is refreshed; if it is inactive, the resources allocated for the session are directly released, and the connection is terminated.

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

After the called terminal receives the 200 response message, it determines whether the session is active according to the rules of the refresher. If the session is active, the session timeout release timer is refreshed, the Session Timers completes the session update, and the session update request is sent to the B2BUA2 unit after (SessionExpires / 2) seconds, until the entire session ends normally, and the Session Timers protection is terminated; If it is inactive, it sends a session release request to the B2BUA2 unit, and releases the resources allocated for the session. The connection is terminated. After receiving the request, the B2BUA2 unit releases the resources allocated for the session and requests the request. After being sent to the PROXY unit, the PROXY unit releases the resource allocated for the session and sends the request to the B2BUA1 unit. After receiving the request, the B2BUA1 unit releases the resource allocated for the session.

As shown in FIG. 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: The B2BUA1 unit receives the session establishment request message, and the UAS end of the B2BUA1 unit checks whether the message carries the supported:timer header field.

If there is no supported:timer header field in the session establishment request message, the flow is skipped. Otherwise, the message is processed by 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, return the value of the Session-Expires header field to the value of the Min_SE header field after receiving the reply response from the calling terminal to the calling terminal. The B2BUA1 unit sends.

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

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

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 B2BUA2 unit receives the session establishment request message. The UAS end of the B2BUA2 unit checks the value of the Session-Expires header field. ^The value of the Session-Expires header i or less is less than the value of the local Min_SE header field, and the B2BUA1 replies to the calling terminal with a response indicating that the session update interval is too short and brings the locally allowed Min_SE header field in the response. Value, after receiving the reply response, the calling terminal changes the value of the Session-Expires header field to the value of the Min_SE header field and resends it.

Step 605: The B2BUA2 unit sends a session establishment request message to the called terminal.

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

Step 607: The B2BUA2 unit receives the 200 response message, and the UAC end of the B2BUA2 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.

Step 608: The B2BUA2 unit sends a 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: The B2BUA1 unit receives the 200 response message, and the UAC end of the B2BUA1 unit does not start the session timeout release timer according to the value of the Session-Expires header field and the refresher parameter in the response message. Session update timer.

The UAS end 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 negotiated successfully.

Step 612: According to the parameter refresher=uac set by the session negotiation, the session update timer of the calling terminal passes (SessionExpires / 2) seconds to notify the calling terminal to issue a session update request to the B2BUA1 unit.

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

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 determines that the message includes a support: timer header field, performs related processing on the message, and sends the message to the called terminal.

Step 616: The called terminal receives the session update message and replies to the B2BUA2 unit with a 200 response message. Step 617: The B2BUA2 unit receives the 200 response message, and determines whether the session is active according to the rules of the proxy server. If the session is active, the session timeout release timer is refreshed; if it is inactive, the resources allocated for the session are directly released, and the connection is terminated.

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 determines whether the session is active according to the rules of the proxy server. If the session is active, the session timeout release timer is refreshed; if it is inactive, the resources allocated for the session are directly released, and the connection is terminated.

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

After receiving the 200 response message, the calling terminal determines whether the session is active according to the rules of the refresher. If the session is active, the session timeout release timer is refreshed, the Session Timers completes the session update, and waits (SessionExpires / 2) seconds before sending a session update to the B2BUA1 unit. Request, until the entire session ends normally, the Session Timers protection is terminated; if it is inactive, it sends a session release request to the B2BUA1 unit, and releases the resources allocated for the session, and ends the connection. After receiving the request, the B2BUA1 unit receives the request. Release the resource allocated for the session and send the request to the PROXY unit. After receiving the request, the PROXY unit releases the resource allocated for the session and sends the request to the B2BUA2 unit. The B2BUA2 unit releases the request and then releases it. The resources that are themselves allocated for the session.

The embodiment shown in FIG. 6 is to issue a session update request by the calling terminal. The parameter of the refresher is uac during the negotiation, and each B2BUA unit does not start the session update request timer, and does not generate new after receiving the session update request. The session update request avoids the forwarding of redundant session update requests in FIGS. 1A and 1B, while solving the problem of message collision in FIG. 1B.

The embodiment shown in Fig. 7 is to issue a session update request by the called terminal. The parameter of the refresher is uas during negotiation, but only in the direction of sending the request message with FIG.

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

In step 700 to step 711 and step 600 to step 611, in addition to the parameter refresher=uas set in the session negotiation, the called terminal issues a session update request, the B2BUA1 unit and the B2BUA2 unit.

The UAS starts the session timeout release timer. The other steps are the same.

Step 712: According to the parameter refresher=uas set by the session negotiation, the session update timer of the called terminal passes (SessionExpires / 2) seconds to notify the called terminal to issue a session update request to the B2BUA2 unit.

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

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 determines that the message includes a support: timer header field, performs related processing on the message, and sends the message to the calling terminal.

Step 716: The calling terminal receives the session update message and returns a 200 response message to the B2BUA1 unit. Step 717: The B2BUA1 unit receives the 200 response message, and determines the session according to the rules of the proxy server. Is it active? If the session is active, the session timeout release timer is refreshed; if it is inactive, the resources allocated for the session are directly released, and the connection is terminated.

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: The B2BUA2 unit receives the 200 response message, and determines whether the session is active according to the rules of the proxy server. If the session is active, the session timeout release timer is refreshed; if it is inactive, the resources allocated for the session are directly released, and the connection is terminated.

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

As shown in FIG. 8, the B2BUA device provided by the embodiment of the present invention includes: a session protocol determining module, a session update requesting module, and a refresher negotiation module.

The session protocol judging module is configured to: after receiving the session establishment request message, determine whether the received session establishment request message has a Supported header field with a timer tag, and if yes, directly forward the session establishment request message, otherwise, A Supported header field with a timer tag is added to the session establishment request message, and the session establishment request message is forwarded.

The refresher negotiation module is configured to perform a refresher negotiation with the node device to determine whether it is a refresher.

The session update request module is configured to, if it is determined that it is a refresher, initiate a session update request to the network node of the current session on both sides connected to itself after the session is established. Of course, in order to implement resource release, the B2BUA device may further include: a processing module, a forwarding module, and a resource release module.

The forwarding module is configured to: after receiving the session update request, when the session update request includes a Supported header field with a timer tag, send a session update to the next node device of the session path according to the received session update request. Request

The resource release module is configured to release the resource allocated for the session after the session is established, if it is determined that the session is inactive.

The refresher negotiation module may further include: an adding module and a receiving module.

The adding module is configured to add a session refresher parameter in the Session-Expires header field in the session establishment request message received by the session protocol determining module.

The receiving module is configured to determine, according to the received session establishment response message, whether it is a refresher, if the Supported header field with a timer tag in the session establishment response message determines that the self is not a refresher, if the session establishment response message does not The Supported header field of the timer tag determines that it is a refresher.

It is apparent that those skilled in the art can make various modifications and variations to the invention without departing from the spirit and scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of the inventions

Claims

Rights request

A method for implementing resource release, the method comprising:

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

The node device determined to be the refresher by negotiation and the node device receiving the session update request release the resources allocated for the session after determining that the session is in an inactive state.

The method according to claim 1, wherein after the node device determined to be the refresher by the negotiation initiates the session update request to the other network node, the method further includes:

After receiving the session update request, each node device sends a session update request to the next node device of the session path according to the received session update request when the session update request includes a Supported header field with a timer tag.

The method according to claim 1, wherein the session establishment request message is sent by the calling terminal to the B2BUA unit, or is sent by the calling terminal to the B2BUA unit via the node device.

The method according to claim 1, wherein the step of performing refresher negotiation between the node devices to determine that a node device is a refresher comprises:

All, the B2BUA unit adds a refresher parameter in the session termination Session-Expires header field in the session establishment request message forwarded to the node device of the session establishment path, and sets the refresher refresher as the user proxy client uac for indicating The B2BUA unit is responsible for initiating a session update request to the called terminal;

A12. After receiving the session establishment request message, the called terminal determines that it is not a refresher, and then passes the The node device returns a session establishment response message to the B2BUA that is not itself a refresher;

A 13. After receiving the session establishment response message, the B2BUA unit determines that it is a refresher, and adds a refresher parameter in the Session-Expires header field in the session establishment response message replied to the calling terminal, and sets the refresher to User agent server side uas.

A 21. The B2BUA unit sends the session establishment request message to the node device in the session establishment path, where the support header field with the timer tag is received, and after receiving the session establishment request message, each node device forwards the message to the next node device. Until the called terminal;

A22. After receiving the session establishment request message, if the called terminal determines that it is a refresher, the node device returns a session establishment response message to the B2BUA, where the Session-Expires header field is uas, and if it is determined that it is not a refresher And returning, by the node device, a session establishment response message to the B2BUA that is not a refresher;

A23, after receiving the session establishment response message, the B2BUA unit determines whether the called terminal is a refresher, if yes, executing step A24, otherwise, using itself as a refresher, performing step A24;

A24. The B2BUA unit adds a refresher parameter in the Session-Expires header field in the session establishment response message replied to the calling terminal, and sets the refresher to the user proxy server side uaS o

The method according to claim 6, wherein, in step A22, the session establishment response message that is not itself a refresher is a session establishment response message that does not include a Supported header field with a timer tag;

In step A22, the session establishment response message of the refresher is a session establishment response message containing a Supported header field with a timer tag, where the refresher of the Session-Expires header field is uas.

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

Each B2BUA unit is configured to: after receiving the session establishment request message, determine whether the supported header field with the time timer tag is included, and if yes, forward the session establishment request message. Go, otherwise, add a Supported header field with a timer tag to the message, and forward the session establishment request message; perform a refresher negotiation with the node device to determine whether it is a refresher; if it is determined to be a refresher Then, after the session is established, a session update request is initiated to the network node that is connected to the session on both sides of the session.

The method according to claim 8, wherein the session establishment request message is sent by the calling terminal to the B2BUA unit, or is sent by the calling terminal to the B2BUA unit via the node device.

The system according to claim 8, wherein the B2BUA unit comprises: a session protocol determining module, configured to: after receiving the session establishment request message, determine whether the received session establishment request message carries a timer tag The Supported header field, if yes, forwards the session establishment request message directly, otherwise, adds a Supported header field with a timer tag in the session establishment request message, and forwards the session establishment request message;

The session update request module is configured to initiate a session update request to the network node of the session in which the session is connected to each other after the session is established, if it is determined to be the refresher.

The system according to claim 8, wherein the B2BUA unit further comprises:

a forwarding module, configured to: after receiving the session update request, when the session update request includes a Supported header field with a timer tag, send a session update request to the next node device of the session path according to the received session update request;

12. The system according to claim 8, wherein the refresher negotiation module further comprises:

An adding module, configured to add a refresher parameter in a Session Ending Session-Expires header field in the session establishment request message; a receiving module, configured to determine, according to the received session establishment response message, whether it is a refresher, if the Supported header field with a timer tag in the session establishment response message determines that it is not a refresher, if the session establishes a response The Supported header field without the timer tag in the message determines that it is the refresher.

13. A back-to-back user agent device, the device comprising:

14. The apparatus of claim 13, wherein the back-to-back user agent B2BUA device further comprises:

The device according to claim 13, wherein the refresher negotiation module further comprises:

Adding a module, configured to add a refresher parameter in a Session Ending Session-Expires header field in the session establishment request message;

a receiving module, configured to determine, according to the received session establishment response message, whether it is a refresher, if the Supported header field with a timer tag in the session establishment response message determines that it is not a refresher, if the session establishes a response The Supported header field without the timer tag in the message determines that it is a brush

tUZOO/LOOZSiD/IDd OAV