WO2005114906A1

WO2005114906A1 - Method and system for getting the state of sip network nodes

Info

Publication number: WO2005114906A1
Application number: PCT/CN2005/000690
Authority: WO
Inventors: Himanshoo Kumar Saxena; Haifeng Zhu
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2004-05-20
Filing date: 2005-05-19
Publication date: 2005-12-01
Also published as: CN1700694A; CN100496043C

Abstract

A method and a system for getting the state of SIP network nodes, the method includes: setting the management node of the SIP (session initiation protocol) network; The SIP network management node monitoring the state of other nodes by the standard OPTIONS message; Any node of the SIP network getting the state information of other nodes by subscribing the message from management nodes. For providing maintenance of the state of network nodes, the system includes: At least a authenticity server, for providing the network link; A state management server, for monitoring the state of the network link; At least a authenticity subscribing server, for subscribing the state change notification of the authenticity server node from the state management server. By using the method and system of this invention, it can complete monitoring the state of nodes by using the standard SIP message OPTIONS, reduce the sip network load and increase the running efficiency.

Description

Method and system for acquiring session initial protocol network node status

The present invention relates to the field of network communication technologies, and in particular, to a method and system for acquiring a state of a SIP network node.

Background technique

SIP (Session Initiation Protocol) is a protocol developed by the IETF to control IP-based multimedia communication systems. It defines the signaling process for controlling multimedia sessions, including the establishment, teardown, and modification of sessions. Application layer protocol. A session is an application-level link between two SIP nodes. Specific tasks may be multimedia links, such as Internet phone calls, multimedia broadcasts, multimedia conferences, and so on. The SIP protocol is only responsible for enabling communication. It needs to cooperate with RTP (real-time transmission protocol) and SDP (session description protocol) to complete the communication function.

A SIP node can have multiple working modes, such as UserAgent, Proxy, REGISTRAR, registration server, back-to-back user agent, location server, etc.

There are two types of SIP messages: request and response. The client makes a request and the server responds. Different message headers are used to describe communication details. SIP maintains the common structure of all messages for universal parsing. Requests and responses use a standard, unified format.

The SIP response message has two response states: the temporary response state and the final response state. The final response can be positive or negative. The SIP protocol provides a response mechanism to ensure the reliability of this command-response mode. For example, a simple retransmission command is sent multiple times until a return is received. If a SIP node does not receive a response within the retry times, it can assume that an error response has been received by default, thus ensuring the reliability of the SIP command.

In a SIP network, in order to ensure the reliability of the command, response, and transmission link, the SIP node needs to obtain the application status of the remote SIP node. In terms of transmission, SIP can support UDP (User Datagram Protocol) and TCP (Transmission Control Protocol) protocols. The UDP protocol belongs to the type of "connectionless, unreliable transmission". This protocol is only responsible for receiving and transmitting the messages passed by the upper layer protocol. It does not perform any detection, modification and response. The TCP protocol is a connection-oriented protocol. It provides a corresponding mechanism to maintain the state of the link. When using the TCP protocol, In this case, the SIP node can directly obtain the link status of the remote node. However, this link status does not fully represent the status of the peer SIP entity. It may be just the status of the network link. Therefore, in order to obtain the status of the peer SIP entity, a mechanism needs to be introduced to ensure that the remote SIP node generates a heartbeat message (that is, one node periodically sends a message to another node to notify itself of its status), so that the SIP node can be better To maintain each other's status information.

Currently, the SIP protocol does not provide maintenance links, and it also supports publishing link status. If SIP nodes are required to provide link maintenance, it is usually to use some private protocols that are not commonly used in the SIP protocol to maintain heartbeat messages between the two nodes. For example, in order to monitor the status of SIP node 2, SIP node 1 in FIG. 1 needs to send SIP messages frequently. If node 3 only wants to get the status change message of node 2 and does not care about the status information of node 2, it still needs to adopt a similar mechanism to frequently send SIP messages to node 2 to maintain the heartbeat link with node 2. The above method requires that different nodes must maintain heartbeat messages with each other through a private protocol in order to obtain the status change information of each other, so it will occupy a lot of network resources and affect network performance.

Summary of the invention

The object of the present invention is to provide a method and system for obtaining the status of a SIP network node, so that the universal SIP protocol supports the monitoring of the status of the network node while reducing the load on the network.

The object of the present invention is achieved by the following technical solutions:

A method for acquiring a state of a SIP network node includes:

A. Set the management node of the session initiation protocol SIP network;

B. The SIP network management node monitors the status of other nodes in the SIP network through standard SIP messages;

C. A node in the SIP network obtains status information of the other nodes by subscribing to a message from the management node.

The method further includes: defining a SIP event packet for transmitting node status information in the SIP network, and the SIP event packet includes: a package name, an event packet parameter, a subscriber body, a subscription interval, and a notification body.

The step B includes:

Bl. Establish a network node status table. B2. The management node and the other nodes establish a SIP heartbeat link through a standard SIP message OPTIONS, and obtain status change information of the other nodes.

B3. Updating the status of the network node according to the obtained status change information of other nodes

-The network node status table includes: a network node identifier and a node status.

The step C includes:

Cl. A node in the SIP network uses a SUBSCRIBE message defined by a SIP protocol standard to subscribe to a message from the management node;

C2. The management node obtains node information to be monitored according to the received SUBSCRIBE message;

C3 When the state of the node to be monitored changes, the node in the SIP network is notified using the command word NOTIFY defined by the SIP protocol standard.

The step C2 further includes: the management node authenticates the message subscriber according to the received SUBSCRIBE message, and confirms whether the subscriber is authorized to subscribe to the message.

The message body format of the defined SIP event packet is adopted in the NOTIFY and SUBSCRIBE messages.

A system for acquiring a state of a network node of a session initial protocol includes:

At least one reliability server, configured to provide a status of a network link;

A state management server, configured to monitor a state of the network link;

At least one reliability subscriber is configured to subscribe to the state management server for notification of a state change of the reliability server node.

The state management server includes:

At least one reliability client device, configured to establish a SIP heartbeat link with the reliability server, and obtain status change information of the reliability server;

At least one reliability notification device is configured to establish a SIP heartbeat notification link with the reliability subscription server, and notify a change in the status of a related reliability server subscribed by the reliability subscription server.

As can be seen from the technical solutions provided by the present invention, the present invention uses standard SIP protocol messages to maintain heartbeat messages, so that the present invention can be widely supported by the network; by using a The SIP node monitors the status of all other SIP nodes. Other nodes only need to subscribe to status messages from the node, and do not need to establish a point-to-multipoint link, which greatly reduces the load on the network and improves the operating efficiency of the network.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a state maintenance method of a SIP network node in the prior art;

2 is a schematic diagram of a state maintenance method of a SIP network node in the method of the present invention;

FIG. 3 is a flowchart of obtaining the status of other nodes by the management node of the SIP network in the method of the present invention;

4 is a flowchart of a process in which a management node of a SIP network notifies other nodes in the method of the present invention;

FIG. 5 is a schematic structural diagram of a system for acquiring a state of a SIP network node according to the present invention;

6 is a schematic diagram of a topology structure of an application example of the present invention in a SIP network;

FIG. 7 is a message flow between nodes in the application example of the present invention shown in FIG. 6. DETAILED DESCRIPTION The core of the present invention is to obtain the link status of SIP network nodes through the universal SIP protocol, that is, to use SIP messages / operations already in the SIP protocol standard to complete this function, so as to ensure the universality of the solution. In addition, a SIP node uses the SIP protocol to subscribe to the status change messages of other nodes and accept the change information, that is, if a SIP node has obtained the status of another SIP node, the status information of the monitored node is notified to the other SIP nodes to reduce the number of network transmissions and SIP messages needed to maintain node status.

Those skilled in the art know that standard SIP messages are based on plain text. The message contains four parts: the start line, the message header, the blank line, and the message body. among them,

The start line is divided into a request line and a status line, which correspond to the request message and response message of the SIP, respectively. The message header is composed of multiple header parameters, and each header parameter has one line. The message header field specifies the caller, called party, and the path of the message. There are a total of 37 message headers, which can be divided into 4 types: general header fields, which are used for request and response messages; entity header fields, which define the message body information, If there is no message body, the resource indicated by the request is defined; the request header field enables the client to transmit the request and the client's own information to the server; the response header field enables the server to transmit the additional information of the response.

The blank line (CRLF) after the message indicates the end of the message header, which is followed by the message body containing the actual message content.

SIP request messages begin with a request line. The request line includes a request method (method), a request address (Request-URI), and a SIP version number. There are currently six SIP-defined request methods: REGISTER, INVITE, ACK, CANCEL, BYE, and OPTION. Among them, REGISTER is used to register and deregister address binding information; INVITE is used to initiate a call; ACK is used to confirm the establishment of a call; CANCEL is used to cancel the call; BYE is used to terminate the conversation; OPTIONS is used to query the capabilities.

The SIP response message begins with a status line. The status line includes a SIP version (SIP Version), a status code (Status-Code), and a reason description (Reason-Phrase). The SIP version is the same as in the request message. The reason description is a text description of the response status for people to read. The status code consists of three digits and indicates the result of the response. Currently, the status codes defined in RFC 3261 are from lxx to 6xx, lxx is a temporary response (also called an intermediate response), and the others are the final response. Represent the following meanings:

-lxx means the request has been received and is being processed;

-2xx is a successful response, which means that the request has been successfully processed;

3xx is a redirect response, which instructs the call to be re-initiated to the designated entity;

• 4xx is a client error response, which means that the syntax of the request message is incorrect or the server cannot process it;-5xx is a server error response, which means the server cannot process a legitimate request message;-6xx is a global error response, which means that the request cannot be processed by any server .

The above-mentioned temporary response means that when the receiver has received the request, but it takes some time to process, in order to prevent the requestor timer from timing out, this message is used to notify the requester. The result of processing the request is still returned to the requester in the form of a final response.

The present invention is to use the existing SIP messages / operations in the above-mentioned SIP protocol standard to complete the maintenance of the link state of the SIP network node.

In order to enable those skilled in the art to better understand the solution of the present invention, the following is combined with the drawings and the actual implementation. The embodiments further describe the present invention in detail.

Referring to FIG. 2, FIG. 2 is a schematic diagram of a state maintenance method of a SIP network node in the method of the present invention: In this schematic diagram, a communication mechanism exists between node 1 and other nodes ^, but there is no communication mechanism between node 4 and node 2 and node 3 However, node 4 needs to obtain the state change information of node and / or node 3. At this time,

First set the management node of the SIP network (SIP node 1);

The set SIP network management node monitors the status of other nodes (SIP node 2 and SIP node 3) in the network;

Any node (SIP node 4) in the SIP network obtains status information of other nodes by subscribing to the management node (SIP node 1), and the management node notifies the node of status changes of other nodes according to the subscription information. If node 4 only subscribes to the status change information of node 2, the management node only informs node 4 about the status change information of node 2. If node 4 subscribes to the status change information of node 2 and node 3 at the same time, the management node needs to notify node 4 Information about the status changes of node 2 and node 3. That is to say, when the management node sends a message to the subscriber, it sends it based on the subscriber's subscription content.

Figure 3 shows the detailed process of obtaining the status of other nodes in the network by the set SIP network management node.

First, in step 301, a network node status table is established by a set SIP network management node, and the table includes: a network node identifier and a node status; the node status may be respectively represented as "Active" and "Passive", which respectively represent that a network node is in Normal link status and disconnected status.

Then, proceed to step 302, the SIP network management node uses the OPTIONS message defined by the SIP protocol standard to establish a SIP heartbeat link with the monitored node in the network, and obtains the status change information of the monitored node.

After the network management node learns that the status of the monitored node has changed, it needs to proceed to step 303 to update the network node status table according to the obtained status change information of the monitored node.

The detailed process of establishing a SIP heartbeat link is as follows:

The SIP network management node periodically sends OPTIONS messages to the monitored nodes to monitor the status of the corresponding nodes. Under normal circumstances, the monitored node responds to the SIP message sent by the network management node, and can use 2XX defined in the SIP protocol standard as the default return value. This When the state of the network node status table corresponding to the node should be "Active", if the number of times that the monitored node has not responded continuously reaches the predetermined 1 '] limit, the heartbeat between the management node and the monitored node can be determined The link has expired. At this time, the monitored node can also be considered to have expired. At this time, the status corresponding to the node in the network node status table needs to be updated to "Passive".

In order to reduce the network load and improve the operating efficiency of the network, the present invention maintains a "virtual," connection between any node and other nodes by establishing a SIP heartbeat notification link between the network management node and any node. To this end, the present invention The event notification framework in the SIP protocol is used. Based on this framework, the present invention defines an information exchange protocol between a subscriber (any node in the SIP network) and a notifier (a management node in the SIP network). The state of the SIP node is transmitted, that is, a SIP event packet is defined. According to the RFC3265 protocol, an event packet defines additional specifications and status information when the notifier notifies the subscriber. The SIP event packet defined in the present invention includes information: Package name, event package parameters, subscription body, subscription interval, notification body.

Here are the details of the SIP event package:

· Package name

The defined package name is: "heartbeat-notification". According to the specifications of RFC3265 [2], this value will exist in the event headers of the SIP extension messages SUBSCRIBE (subscription) and NOTIFY (notification) requests.

• Event package parameters

This event package fully uses the parameters specified by the existing SIP system. For example, it supports the use of the Accept (Event) header specified in the SIP protocol to specify the format of subsequent NOTIFY messages when subscribing.

• Subscriber

The SUBSCRIBE message needs to provide relevant information so that the reliability notifier can obtain the identity of the SIP node that needs to be monitored.

· Subscription interval

To avoid network overload, you need to define a suitable interval for sending subscription refresh messages.

• Notification body According to the description in RFC3265 [2], the NOTIFY message includes a message body describing the status of the subscription resource. The format of the message body is in the Accept header of the SUBSCRIBE message (if omitted, the default value).

In the event packet, the notification body will include status change information, and the information will indicate the new status and the SIP node identifier of the changed status.

Subscribers who used to inform and need to support a data format by the subscriber and the notifier consultation, the extravagant ^one: "application / heartbeat-notification + xml" data format. The subscription request may include the Accept header field, if the corresponding header field is not present, the system uses the default value "application / heartbeat-notification + xml "; if the corresponding header field is the first field shell ¹ J 'must include "application / heartbeat-notification + xml ".

A "application / heartbeat-notification + xml" type document is a valid XML document that is based on the XML 1.0 standard and uses UTF-8 encoding.

For example: The document of the event package can be in the following format:

<? xml version = "1.0" encoding = "UTF-8"?>

<id>

bob@biloxi.com 〃node IP

</ id>

Machine is up 〃 Corresponding message content

</ information>

</ device>

• Forking requests

When processing the initial SUBSCRIBE message, only one conversation can be established between the subscriber and the notifier. See RFC3265 [2] section 4.4.9 for specific processing methods.

• Notification rate

The RFC3265 [2] protocol specifies the maximum rate at which notifications are sent for each different packet. Notifiers cannot send notifications at a rate greater than every 10s—notifications, because notifications to subscribers are implemented asynchronously. FIG. 4 shows a detailed process of obtaining the status information of other nodes by any node in the above SIP network by subscribing to the network management "point" message:

First, in step 401, a node in a SIP network uses a SUBSCRIBE message defined by the §IP protocol standard to subscribe a message to a management node, and a message body of the SUBSCRIBE message includes the SIP event package defined above.

After receiving the SUBSCRIBE message, the management node first proceeds to step 402 to authenticate the subscriber, that is, to check the node ID of the sender of the SUBSCRIBE according to the information in the SUBSCRIBE message, but this process is not necessary. Usually, a relationship has been established between the subscriber and the notifier. In this case, the HTTP Digest mechanism in the SIP protocol can be used as the authentication method. This method must be supported by all clients and servers. Of course, if such an authentication mechanism is adopted, it is necessary to use this authentication mechanism as a requirement for all SIP compatible components.

If the node does not have subscription rights, then proceed to step 403, and return a 4XX message to the node. If the node has the subscription right, proceed to step 404 to check whether the monitoring node indicated by the subscriber in the SUBSCRIBE message can be monitored.

If the node to be monitored specified in the SUBSCRIBE message cannot support it, then proceed to step 405 and return a 4XX message to the node.

If all the nodes to be monitored specified in the SUBSCRIBE message are supported, then go to step 406 and return a "200 OK" response. The response needs to include all the node ID information that can be monitored.

Then, proceed to step 407, and determine whether the status of the node to be monitored has changed according to the network node status table and the status change information of the monitored node obtained in step 302 shown in FIG. 3.

If there is no change, go to step 408, wait for a predetermined time and return to step 407, and continue to determine whether the status of the node to be monitored has changed.

If the status of the monitored node changes, proceed to step 409, and use the command word NOTIFY defined in the SIP protocol standard to notify the message subscribing node. The body of the NOTIFY message includes the SIP event packet defined above. The body of the NOTIFY message must use a value from the list of types defined in the Accept header field of the most recently received SUBSCRIBE request, or The default "application / heartbeat-notification + xml" (in case Accept ^: field does not exist).

After receiving the above-mentioned NOTIFY message, the message subscriber can perform processing according to requirements, for example, operations such as updating the link status.

FIG. 5 is a schematic structural diagram of a system for acquiring a state of a SIP network node according to the present invention:

In this system, a reliability server 501 is shown, which is used to provide the status of a network link to a SIP network; a status management server 500 is used to monitor the status of the network link, that is, to monitor the status of other nodes in the network Status; a reliability subscription server 502, configured to subscribe to the status management server 500 for notification of changes in the status of the reliability server node. The state management server 500 includes: a reliability client device for establishing a SIP heartbeat link with the reliability server to obtain status change information of the reliability server; a reliability notification device for establishing a SIP heartbeat notification link with the reliability subscription server To notify the reliability subscriber that the status of the relevant reliability server to which the subscription is subscribed. When establishing a SIP heartbeat link and establishing a SIP heartbeat notification link, the message words defined by the SIP protocol standard are used to exchange information. The reliability server, status management server, and reliability subscriber server referred to here are all divided from a functional perspective, and can be essentially different functional modules in the same entity.

In this embodiment, although only one reliability server, one state management server, and one reliability subscription server are shown, in a SIP network, multiple nodes may be included. Therefore, there are many networking modes of the system of the present invention. Species. You can choose different system topologies for actual networking. Similarly, if it is necessary to monitor the status of multiple reliability servers, it is necessary to correspond to multiple reliability client devices in the state management server 500; if there are multiple reliability subscribers subscribing information to the state management server 500, it is necessary to perform state management The server 500 corresponds to a plurality of reliability notification devices.

For convenience of explanation, the working process of the system of the present invention is described by taking FIG. 5 as an example.

Reliable client devices need to periodically send OPTIONS messages to those that need to be monitored

SIP node (node 2) to monitor the status of the corresponding node. The device also needs to monitor the response of the OPTIONS message. If the number of times that SIP node 2 has not responded continuously reaches a predetermined threshold, the system can determine that the heartbeat link between SIP node 1 and node 2 has failed. At this time, SIP Node 2 has also failed. For example, you can set the initial retransmission of the OPTIONS message The time is 100 milliseconds and is doubled after each retransmission until 7 retransmissions. If the seventh retransmission still fails, it can be considered that the monitored node's processing of OPTIONS has failed. At this time, the status of the network node status table corresponding to the node needs to be updated to "Passive". If a response from the monitored node is received during the waiting process, the management node can set the retransmission timeout to 500 milliseconds. If it is determined that the monitored node has failed, the management node updates the status corresponding to the node in the network node status table to "Passive".

The reliability server needs to respond to the SIP message sent by the reliability client. The present invention proposes "2XX" as the default return value. If the reliability server receives the OPTIONS message from the reliability client, it needs to return a "2XX" response and wait for the OPTION message to be resent. The waiting time for resending messages is configurable (see the contents of the SIP event packet described above), and the recommended time is 60s. If the retransmitted OPTIONS message is not received between timeouts, it can be considered that the reliability client device has failed, but the reliability server needs to continue to wait for the OPTIONS message using the same timeout setting.

When the reliability subscription device needs to obtain the status information of other nodes, it uses the event notification framework in the SIP protocol. The reliability subscriber server sends a SUBSCRIBE message to the reliability notification device to subscribe to the notification of the status change of the reliability server node. For the body definition of the SUBSCRIBE message, refer to the SIP event packet described earlier.

The function of the reliability notification device is to inform the reliability subscriber of the status information (mainly whether it is available) of a node. The device receives the SUBSCRIBE message from the reliability subscriber, and monitors the status changes of other nodes subscribed by the subscription server. If the status changes, it sends a NOTIFIY event notification to the reliability subscriber. The body definition of the NOTIFIY message refers to the SIP event packet described above.

In order to enable those skilled in the art to better understand the present invention, the topology structure and working process of the system of the present invention will be described in detail through an application example of the present invention.

Referring to the topology structure of the application example of the present invention in a SIP network shown in FIG. 6:

The network includes a "manager" and multiple "nodes". The network will also include a certain number of softswitch devices (supporting the SIP protocol). All nodes (including all network nodes and softswitch equipment) are interconnected through an IP network. Only "managers" in this network need to monitor all The state of the softswitch device. If a node wants to obtain the status of the softswitch device, this node needs to send a SUBSCRIBE message to the "manager" subscription.

Figure 7 illustrates the possible message flow among managers, nodes and softswitch devices. as the picture shows:

Step 1: The administrator creates a reliable client for softswitch device 1, and also creates another reliable client for softswitch device 2. These clients send OPTIONS messages to the corresponding softswitch devices. After receiving the OPTIONS message, the softswitch device sends a 200OK response message. When the reliability client receives the 200 OK message, the system considers that the corresponding soft switching device is up and running normally.

Step 2: When node 1 sends a SUBSCRIBE message to subscribe to the status information of soft switching device 1, the manager sends 200OK to node 1 as a response message to the SUBSCRIBE message, and then sends a NOTIFY message to notify node 1 that the status of soft switching device 1 is " Active ".

Step 3: The manager sends an OPTIONS message, and at the same time does not receive a response from the softswitch device 1 within the timeout period, the manager changes the status of the softswitch device 1 from "Active" to "Passive", and sends a NOTIFY message to change the information Notify node 1.

As a follow-up process, the manager continuously sends OPTIONS messages to the softswitch device 1 periodically.

In the fourth step: the manager receives the response information of the softswitch device 1, and accordingly the manager changes the status of the softswitch device 1 from "Passive" to "Active", and notifies node 1 of this information through a NOTIFY message.

Although the present invention is described through the embodiments, those skilled in the art know that the present invention has many variations and changes without departing from the spirit of the present invention, and it is expected that the appended claims include these variations and changes without departing from the spirit of the present invention.

Claims

Rights request

1. A method for acquiring a state of a network node of a session initial protocol, comprising:

A. Set the management node of the session initiation protocol SIP network;

2. The method for obtaining the status of a session initiation protocol network node according to claim 1, further comprising: defining a SIP event packet for transmitting node status information in the SIP network, and the SIP event The package includes: package name, event package parameters, subscription body, subscription interval, and notification body.

3. The method for acquiring a state of a network node of a session initiation protocol according to claim 1 or 2, wherein the step B comprises:

Bl. Establish a network node status table.

B2, the management node and the other nodes are established through a standard SIP message OPTIONS

A SIP heartbeat link to obtain status change information of the other nodes;

B3. The network node status table is updated according to the obtained status change information of other nodes.

4. The method for obtaining a status of a network node of a session initiation protocol according to claim 3, wherein the network node status table comprises: a network node identifier and a node status.

5. The method for acquiring a status of a network node of a session initiation protocol according to claim 1 or 2, wherein the step C comprises:

C2. The management node receives the SUBSCRIBE message, and obtains node information that needs to be monitored;

C3. When the state of the node to be monitored changes, the node in the SIP network is notified using the command word NOTIFY defined by the SIP protocol standard.

6. The method for acquiring the status of a session initiation protocol network node according to claim 5, wherein The feature is that the step C2 further includes: the management node authenticates the message subscriber according to the received SUBSCRIBE message, and confirms whether the subscriber is authorized to subscribe to the message.

7. The method for obtaining a status of a network node of a session initiation protocol according to claim 5, wherein a message body format of the defined SIP event packet is used in the NOTIFY and SUBSCRIBE messages.

8. A system for obtaining a status of a network node of a session initial protocol, comprising: at least one reliability server, configured to provide a status of a network link;

A state management server, configured to monitor a state of the network link;

9. The system for acquiring the status of a session initiation protocol network node according to claim 8, wherein the state management server comprises: