WO2020002599A1

WO2020002599A1 - Method for remote health monitoring in a sip-based communication network and health monitoring system

Info

Publication number: WO2020002599A1
Application number: PCT/EP2019/067324
Authority: WO
Inventors: Antonio Fernandes; Rodrigo Kaminski BIERMAYR; Amauri CROVADOR
Original assignee: Unify Patente Gmbh & Co. Kg
Priority date: 2018-06-29
Filing date: 2019-06-28
Publication date: 2020-01-02

Abstract

The present invention relates to a method for remote health monitoring in a SIP-based communication network (1) in which a plurality of platforms (2, 4, 5, 6) are connected to each other, each platform (2, 4, 5, 6) comprising at least one SIP server (3, 7, 8, 9), wherein the method comprises the steps of: providing an action manager (13) for a first server (7) located at a first platform (4) of the plurality of platforms (2, 4, 5, 6), preparing, by the action manager (13), an action request to be sent to an action agent (14) provided for a second server (8) at a second platform (5) from the plurality of platforms (2, 4, 5, 6), wherein the action manager (13) uses a SIP OPTIONS message and inserts the action request script into the SIP OPTIONS message body, the action request script comprising instructions for performing health monitoring. Further, the present invention relates to a health monitoring system.

Description

Method for remote health monitoring in a SIP-based communication

network and health monitoring system

Description

The present invention deals with a method for remote health monitoring in a SIP-based communication network and a health monitoring system.

VoIP enterprise communication is becoming more and more popular. For example, the OpenScape Branch (OSB) and OpenScape Session Border Controllers (SBC) are SIP-based servers, which are part of the OpenScape Voice (OSV) solution. Also, these SIP-based servers are deployed in other solutions, like OpenScape 4k, Circuit, and OpenScape Cloud VoIP. In a SIP-based communication network, the SIP-based servers mentioned above have multiple functions, for example, in a VoIP infrastructure, they perform SIP routing, SIP transcoding, SIP survivability, and the like.

However, as these solutions have been deployed on different customer networks, a variety of problems concerning support of the implemented servers have occurred, as they have to be maintained on a regular basis, and in case of problems, have to be repaired or debugged. Alarm and debugging tools are known in prior art, which can be used for checking these servers remotely on a 24/7 live system. However, usually these network elements are deployed deep inside the customer’s main network, which is difficult to access remotely. Moreover, the currently known debug and diagnostic tools are not sufficient to provide a deep analysis in a 24/7 live system.

Namely, the system alarms known in prior art use standard SNMP alarms and other network monitoring protocols. Alarms are monitored by sending traps for a monitoring server (e.g., HiPath FM), or by accessing the Graphical User Interface (GUI) and checking security, access and capacity restrictions. Thus, the customers have to buy a HiPath FM server or have service personnel monitoring the system periodically, and checking it for its health status or alarms.

For other problems which cannot be resolved by an alarm report, usually internal log monitoring and specific health check actions for problem tracking and diagnosis are employed. In some cases, a service staff member located either on site or remotely to the server monitors the latter to take fast action, in case an alarm or a rare issue arises, thus, causing additional costs for the above mentioned systems.

Summarizing the above, retrieving deep internal logs, checking data, analyzing and monitoring a server function by means of the tools known from prior art or by means of appointing special personal for performing these tasks is complex and expensive.

Therefore, it is an object to provide a method for health monitoring in a SIP -based communication network and a health monitoring system according to which health checks and debugging of a server device in a SIP -based network can be performed more easily.

This object is solved according to the present invention by a method for health monitoring in a SIP -based communication network having the features according to claim 1, and a health monitoring system having the features according to claim 7. Preferred embodiments of the invention are specified in the respective dependent claims.

According to the invention, a method for remote health monitoring in a SIP -based communication network, in which a plurality of platforms are connected to each other, each platform comprising at least one SIP server, is provided, wherein the method comprises the steps of:

providing an action manager for a first server located at a first platform of the plurality of platforms,

preparing, by the action manager, an action request to be sent to an action agent provided for a second server at a second platform from the plurality of platforms,

wherein the action manager uses a SIP OPTIONS message and inserts the action request script into the SIP OPTIONS message body, the action request script comprising instructions for performing health monitoring.

By the inventive method, an automatic procedure is provided for remote monitoring and executing actions without having to get a specific authorization for accessing a server to be monitored. Deep logging inspection may be performed, for example, for the OpenScape Branch (OSB), or OpenScape Session Border Controllers (SBC), but the inventive method may also be used for any other SIP server. The use of SSH, SNMP, HTTPS, or any other common monitoring protocols or applications that require the installation of server/client programs within the internet or intranet of a customer so as to provide monitoring, debugging, or action capabilities are superfluous. Rather, according to the present invention, native IP protocol SIP awareness of these systems is used. The inventive method may be applied between all available SIP elements in a SIP -based network. Simply, scripts are encapsulated, are tunneled into a SIP OPTION request messages. The action manager uses“action control” scripts so as to control all OSBs and SBCs in a network by generating“action requests”, as outlined above, and processing the“action responses” as also outlined above. The scripts used are only limited to the script language, which has been used to create them and the permissions to allow them. They can parse the logs, retrieve internal alarms, and get any other deep information directly from the system’s databases without the need to wait for an SNMP alarm trap or a human action. Further, these actions may run continuously during a long time and may also take preventive actions in case of problems, thus, providing proactive action handling. The server health can thereby be maintained, if a problem is detected. The proactive actions may be executed directly by the action agent or remotely by the action manager. Further, one possible step which may be involved in this procedure may be providing corresponding information on a problem to be taken care of to the staff.

According to a preferred embodiment, the action manager receives a 200 OK response from the action agent, the 200 OK response comprising response text to the action request inserted into the 200 OK message body.

According to another preferred embodiment, after receiving the 200OK response, the action manager activates a mechanism, in particular, a hot for decoding, analyzing, and/or performing actions based on the response text comprised in the 200OK response.

According to still another preferred embodiment, the request and response scripts are selected from Lua Script, Shell Script, Bash Scipt, or ANYScript.

The method may be started or initiated by receiving a token at the first server.

Preferably, the action manager is implemented in the first server, or the action manger is a virtual machine. Further, according to the present invention, a health monitoring system is provided, comprising a at least one first platform with a first SIP server and at least one second platform with a second SIP server, the first SIP server and the second SIP server being connected to each other in a SIP -based communication system, wherein an action manager is provided for the first SIP server, and an action agent is provided for the second SIP server, wherein the action manager is adapted to prepare an action request to be sent to the action agent by using a SIP OPTIONS message and inserting the action request script into the SIP OPTIONS message body, wherein the action request script comprising instructions for performing health monitoring at the second SIP server. The health monitoring system according to the present invention provides the advantages already discussed above.

It is advantageous, if the action agent is adapted to prepare an action response to be sent to the action manager by using a 200OK message and inserting the action response script into the 200OK message body, wherein the action response comprises content concerning the result from the action request.

Preferably, the first server is an OSB server, and the second server is an OSB server, respectively implementing OSV.

According to another preferred embodiment, the action manager is embedded in the first server, or is provided as a virtual machine.

According to yet another preferred embodiment, the action manager is adapted to automatically monitor and/or control and/or supervise the second SIP server.

The invention and embodiments thereof will be described below in further detail in connection with the drawing.

Fig. 1 schematically shows a SIP -based communication network according to an embodiment of the invention;

Fig. 2 schematically illustrates various action control request scenarios; Fig. 3 schematically illustrates the configuration of a SIP -based communication network according to an embodiment of the invention;

Fig. 4 shows a flow chart for an action agent generation procedure;

Fig. 5 illustrates the processes taken by an active action agent;

Fig. 6 shows an embodiment of an action agent and its components;

Fig. 7 shows the flow of messages to install a script for searching server logs;

Fig. 8 shows an action request using a Lua script;

Fig. 9 shows an action response using a Lua script;

Fig. 10 shows another flow of messages to install a script for searching server logs;

Fig. 11 shows an action request for receiving results from a running action;

Fig. 12 shows an exemplary text of a message body sent to capture results from a running action;

Fig. 13 shows an action response to the action request of Fig. 7; and

Fig. 14 shows a procedure for auto-propagating the SIP OPTION messages with action control scripts.

Fig. 1 shows a SIP -based communication network 1 in which a plurality of platforms are connected to each other. Here, a peer-to-peer topology is implemented. Here, a first platform is an OpenScape Voice (OSV) platform 2 comprising a data center and a routing server 3. Further platforms 4, 5, 6 are connected to the first platform 2, each further platform 4, 5, 6 comprising at least one own OpenScape Branch server OSB1, OSB2, OSB3 indicated by reference numerals 7, 8, 9 and a corresponding gateway 10, 11 , 12. Communication between OSB1 server 7, OSB2 server 8, and OSB3 server 9 is routed via the routing server 3. In the scenario illustrated in Fig. 1, the 0SB1 server 7 comprises the so-called action manager for remotely providing service, as maintenance and monitoring, for the other OSB servers OSB2 8 and OSB3 9. It is noted, that the action agent may monitor or supervise the other OSB servers OSB2 8 and OSB3 9 as to health, and in particular, malfunction, failure or anomaly, and in case of an emergency, analyze the emergency and resolve it. The term“monitoring” also comprises“supervising”, and resolving an emergency comprises, for example, a debug procedure.

Therefore, the action manager, which in this case is implemented in OSB1 server 7, and also indicated by reference numeral 13, in a first step indicated by the number 1 in a circle, prepares a SIP OPTION message to be sent to OSB2 server 8, which in the embodiment shown here is determined to be the so-called action agent, indicated by reference numeral 14. The SIP OPTION message is prepared by the action manager 13 by inserting a predefined action request script into the body of the message as plain text (script text). The script text may comprise instructions for capturing a deep inspection log in the other SIP -based server OSB2 server 8 for, e.g., finding security events buried in the log files, or for retrieving internal alarms, parse the logs, or the like.

In a second step, indicated by the numbers 2 and 3 in a respective circle, the SIP OPTION message with its particular body comprising the inserted action request script, is routed within the SIP -based network 1 by the routing server 3 to the OSB2 server 8. Thus, the action request script comprised in the SIP OPTION message is received by the action agent 14 embedded in the OSB2 server 8, which handles the action request. For example, if the action request relates received relates to checking the remote end point, namely, the server 8, then the action agent 14 will perform the necessary actions for checking the sever 8. In the embodiment described here, the action agent 14 will activate a hot mechanism for retrieving, parsing, and executing the message contained in the SIP OPTION body, and will store the result of the check in a body- text content file. Then, a regular SIP 200OK response is prepared by the action agent 14, with the SIP stack on the OSB2 server 8, whereby the action agent 14 will retrieve and insert the result as action response in the 200OK message body in the form of plain text without affecting the SIP routing headers.

Then, in a fifth step indicated by the number 5 and the number 6 respectively in a circle, the OSB2 server 8 sends the thus prepared 200OK message to the OSB1 server 7, whereby it is routed again by the routing server 3 provided in the OSY platform 2. The routing server 3 forwards the 200OK message comprising the action response without any modifications to the OSB1 server 7.

In a sixth step, upon receipt of the 200OK message by the OSB1 server 7, the embedded action manager 13 is activated, which in turn activates a BOT to decode, analyze, and perform actions based on the data comprised in the action response of the 200OK message.

Thus, via the OSV of the OSV platform 2, all internal and external SIP entities of the other platforms are able to reach any of the OSB servers 7, 8, 9 of OSB1, OSB2, OSB3 or Session Border Controllers SBC servers (not shown) in the SIP -based communication network 1.

Fig. 2 illustrates the configuration of a SIP -based communication network 1 according to an embodiment of the invention. As can here, a first SIP server 7 of a first OSB platform 4 is connected to a second SIP server 8 of a second OSB platform 5 via the Internet 15 or an Intranet. In this embodiment, the health status of the second SIP server 8 is monitored and controlled by the first SIP server 7 by means of the method using the SIP OPTIONS message. As described above, the action manager 13 which is comprised in the first OSB platform 4 will use the action control scripts to send action request scripts to other components in the network, here to the second SIP server 8, and evaluates the action response messages comprised in the 200OK message to take corresponding actions. Namely, the action manager 13 will send a first round of OPTIONS messages with specific scan information to create the first action agent 14. All usual system resources can be requested (e.g., memory, CPU, and disk status), as well as any key strings on core processes like SipServer, PM and the B2B. Both, the resources information as well as these key words can provide the first level of log inspection and can be used to request more data as a key point to trigger the next level of system inspection. Upon identification of this information, system resources conditions or internal alarms, a next level of debug request will be triggered and can enable a deeper debug on the processes on the affected components (deep log inspection).

With this new level, a new action agent 14 will be created to allow a new deep and precise level of analysis to be carried out. On these conditions, process-specific keywords like“FAIL”, “WRONG”,“RESOURCES”,“FULL” and process-specific resources like childs, queues can be verified and allow a next level of preventive actions that can be triggered. Therefore, in this action level, the action manager 13 will request the creation of a new action agent 14, which can be used to generate a preventive reload of the affected processes, for example, or it will inject and execute a remote control script or even activate a protective system restart when no calls are active, besides the usual alarm rising.

The action agent 14, which here is created in the second OSB platform 5 receives the action request script comprised in the SIP OPTIONS message, and executes the requested actions, as outlined above. It collects data and sends the result content to the first SIP server 7 as a response, wherein plain text concerning the result content is inserted in the message body of the 200OK message.

By the above described procedure, the first SIP server 7 is able to monitor the second SIP server 8 by tunneling scripts between the SIP network elements, here the first SIP server 7 and the second SIP server 8, in their payload without the need to wait for, e.g., an SNMP alarm or manual intervention by a user (i.e., service staff), or a user having to explicitly grant access to the server to be monitored. The method is carried out automatically and continuously.

It is noted that the action manager may be installed in a separate computer, or may be implemented as a virtual machine.

Hereby, a deep inspection mechanism will allow the action manager 13 to create multiple levels of action agent 14 instances to have an active control of the functions: monitor, data and log inspect, and to take preventive actions on remote systems independently of human interference. The logic behind basically consists of three-step-approaches: request, processing, and action.

Fig. 3 schematically illustrates various action control request scenarios. In case A), which corresponds to the scenario illustrated and described with respect to Fig. 2, the action manager 13 is implemented in the OSB1 server 7 and the action agent 14 is implemented in the OSB2 server 8, whereby an action request is sent from the OSB1 server 7 to the OSB2 server 8, as describe above with respect to Fig. 1. In case B), the action manager 13 is implemented in the OSB1 server 7, which sends respective action requests to the OSB2 server 8 comprising an action agent 14 and to the OSB3 server 9, comprising another action agent 14. In case C), the action manager 13 is implemented in the OSB1 server 7, which sends an action request to the OSB2 server 8, which in turn, transmits it to the OSB3 server 9. Fig. 4 shows a flow chart for an action agent generation procedure, wherein the action manager comprises its own action logic. After starting the procedure at step S 1 , an action manager startup procedure is started in step S2. Upon starting the action manager startup procedure, in step S3, an action agent is generated, and in step S4, the OPTION message is created so as to create the agent. In the following step S5, the agent’s results are awaited. If, in step S6 it is decided that the data key is enough, then it is decided in the next step S7, whether action is taken on data. If it is decided in step S6 that data key is not enough, then in step S 8 it is decided, whether a new agent is to be created. If the result is positive, then the procedure returns to step S3, so as to create a new action agent. If the result is negative, then it is returned to step S5 for awaiting the agent’s results. Again, if it is decided that data key is enough, then in step S7, it is decided whether action on the data is to be taken or not. If not, the procedure returns to step S5, to await further results from the agent. If action on the data is to be taken, the procedure either returns to step S8 or to step S3 so as to generate a new action agent. The procedure runs until it is stopped in step S9 and terminated in step S10.

Fig. 5 illustrates the processes taken by an active action agent, which again comprises its own action logic. In a first step Sl l, the procedure is started. Then, in a second step S12, named “server configuration”, the server will be prepared by changing the configuration needed such as: log levels, network traces, starting or stopping applications, removing or creating files and so on. In the next blocks or steps, S13,“information scanning”, and S14,“processing data”, these are composed of many plugin blocks of code (see Fig. 6), used to give notes to entities in the server. Finally, in block S 15,“take actions”, the latter will be responsible to join and analyze all the entities and its notes. It will judge based on this information and combinations thereof. The actions are not limited and just one application or the entire server can be restarted.

Some examples of actions are:

Sip server restarts:

®“rejected_calls=l00” and“os_mcmory=80” and“sipscrvcr_mcmory=85”

The sip server is using a lot of memory and causing the calls to be lost due to system resources.

®“completed_calls=75” and“rejected_calls=70”

The sip server can be on overload state by traffic.

Server restart “completed_calls=85” and“sipserver_CPU=70”

The sip server or other applications is/are taking all the recources.

®“os_mcmory=80” and“os_cpu=80”

The system resources are low

®<Eth_name>_errors=50

The network interface is not working.

The OPTIONS and OPTION’S 200OK messages will be changed to follow the examples described below, e.g., in respect of Fig. 7.

Finally, the procedure ends in step S16.

Fig. 6 shows an embodiment of an action agent 14 and its components or units or plugins. Namely, according to this embodiment, the action agent 14 comprises a SipServer log scan unit 16 for scan SIP errors messages, an alarm log scan unit 17 for monitor problems inside applications, digital lines 18 and analog lines 19 for control the external hardware, a network scan unit 20 for detection of physical or driver problems with the network interfaces, a process manager 21 for checking licenses and processes states, a server redundancy unit 23 for monitoring the redundancy health, and an Operating System (OS) monitoring unit 22 for check memory, drivers, file systems and other OS entities. Each of these plugins will fill a data base of entities and notes. E.g.,“os_memory=50”, where 0 means“no problem” and 100 means “major problem”. In this case, the system memory is half full. Another example could be the “ETHl_load=80” and in this case, it will be concluded that ETH1 network interface is almost overloaded.

Below, some entities will be described generated by the above plugins. These entities are just an example of the basic functionalities.

The SipServer log scan unit 16 will generate entities reading the internal logs, some examples are:

- “phone_l92T68.10.10=90!

The phone is losing calls frequently

“gateway_unify.com=80”

The gateway is rejecting many calls by resources limit

“rej ected_calls= 100” Al the calls are rejected

“completed_calls=50”

Half of the calls are not completed

“server_status= 10”

Server is in normal state

The network scan unit 20 will generate entities reading the internal logs and the status variables of each network interface. Some examples are:

<Eth_name>_overload=90

The network is 90 % overloaded

<Eth_name>_errors=50

The network is generating errors constantly

The OS monitoring unit 22 will generate entities reading the internal logs and the system status variables. Some examples are:

“os_mcmory=80”

The system memory is 80 % used

“sipscrvcr_mcmory=85”

The memory used by the sip server is high

“sipserver_CPU=70”

The sip server CPU usage is high

- “os_cpu=80”

The system CPU usage is high

Fig. 7 shows an example for a flow of messages to install a script for searching server logs for an embodiment, in which the SIP OPTION message is sent from a first server (e.g. SIP server 7 shown in Fig. 2) to a second server (e.g. SIP server 7 shown in Fig. 2), whereby the second server sends an immediate response message by using the 200OK message to the first server. The procedure is started, as soon as a temporary TOKEN is received as a kind of access key needed to enable the feature to work in that client, with this token, the execution of the scripts and actions from the messages are allowed. Further, it is noted that the token is used to protect and authenticate the above described feature and avoids hacking. By default, the token will have a limited time to live. Now, the client application will create an OPTION message, to be sent to the second server. As mentioned above, in the upper rectangle, the content to be inserted into the message body of the OPTION message for sending an action request to the second server is illustrated. The action response is depicted in the lower rectangle, which represents the corresponding content concerning the result which is inserted into the body of the 200OK message and which is sent back from the second server to the first server.

Fig. 8 shows an action request using a Lua script, which is inserted by an action manager into the SIP OPTION message body, and which is then sent to an action agent, according to the procedure depicted in Fig. 3. The SIP OPTION message comprising this script is sent from a first server to a second server to obtain a deep inspection log in a SIP server log system running at a remote SIP server destination.

Fig. 9 shows an action response using a Lua script, which is received in response to the action request shown in Fig. 4, and which is inserted into the 200OK message body, so as to be sent from the second server to the first server.

Fig. 10 shows another flow of messages to install a script for searching server logs, wherein in contrast to the example shown in Fig. 8, here, the response is not executed immediately, but after a certain time period has elapsed. Namely, in the upper rectangle, the message flow is shown which is created by the action manager at a first SIP server, which serves as diagnosis server, and which inserts the script into the message body of the SIP OPTION message and sends it to the action agent at a second SIP server to be monitored. The second server or its action agent then inserts the script shown in the second rectangle below the uppermost rectangle, which shows the text to be inserted into the 200OK message body. After the action manger has received this 200OK message, a certain time period elapses, and the next SIP OPTION message is prepared by inserting the script shown in the rectangle right below the second rectangle as an action request to the action agent at the second server. Again, the action agent collects the results accordingly, and sends an action response to the action manager by inserting the script in the lowermost rectangle into another 200OK message, which is sent to the first server.

Fig. 11 shows an action request for receiving results from a running action. The text is an example for a SIP OPTION message body, which is sent to obtain results from a second server which is monitored by a first server from a running action. Fig. 12 shows an exemplary text of a message body sent to capture results from a running action.

Fig. 13 shows an exemplary text for a response sent in the 200OK messages. For example, this is an action response to the action request of Fig. 7, whereby the text shown is inserted into the 200OK message body. As the action request includes an option to keep it running, only the text already produced is returned and a new check will provide more data. This sequence of messages can be used for any type of logic in the action script.

Fig. 14 shows a procedure for auto-propagating the SIP OPTION messages with action control scripts. Again, after getting a temporary TOKEN and the internet/ intranet IP of access the server over configuration, the action manager at a first SIP server creates an action request for making an availability check by using the SIP OPTION message, inserting the script in the uppermost rectangle into the message body. The SIP OPTION message is sent to a second server, whereby a corresponding action agent prepares an action response according to the procedure outlined above, and sends it back to the first server using the 200OK message. However, since the SIP OPTION message is a request made to perform an availability check in the SIP network (e.g., like the ICMP PING message), it can be sent constantly after a preset or preconfigured time. The results are used in the SIP network to perform actions and to declare the destination, for example, as being unreachable. This approach is based on the native use of the SIP OPTION message building a“tunnel” between two SIP peers and thereby allowing a flexible and native communication for status check, long time monitoring and remote actions without affecting, for example, the customer network.

The following table (table 1) shows various types of scripts to be used in the SIP OPTION and 200OK message bodies with corresponding robots and actions for the scenarios described above. As body MML types, the Lua script can be used, for example, for deep log inspection. The hot used will run for a log period and checks, if log exists and its corresponding action will be triggering an alarm and return a text to be analyzed. The advantage of using this configuration is that the request will run continuously, until the deep log is found. As further options, the Shell script, Bash script, and an ANY multi-logic approach are listed, with their corresponding hots and actions, as well as advantages. It is noted that the ANY multi-logic approach action command script has the capability to be sent to remote SIP servers so as to create further action commands. Table 1:

Reference numerals

1 SIP -based communication network

2 OSV platform

3 routing server

4, 5, 6 platforms

7, 8, 9 OSB servers

10, 11, 12 gateways

13 action manager

14 action agent

15 Intemet/Intranet

16 sipserver log scan unit

17 alarm log scan unit

18 digital lines

19 analog lines

20 network scan unit

21 process manager

22 OS monitoring unit

23 server redundancy unit

Claims

1. Method for remote health monitoring in a SIP -based communication network (1) in which a plurality of platforms (2, 4, 5, 6) are connected to each other, each platform (2, 4, 5, 6) comprising at least one SIP server (3, 7, 8, 9), wherein the method comprises the steps of:

providing an action manager (13) for a first server (7) located at a first platform (4) of the plurality of platforms (2, 4, 5, 6),

preparing, by the action manager (13), an action request to be sent to an action agent (14) provided for a second server (8) at a second platform (5) from the plurality of platforms (2, 4, 5, 6),

wherein the action manager (13) uses a SIP OPTIONS message and inserts the action request script into the SIP OPTIONS message body, the action request script comprising instructions for performing health monitoring.

2. Method according to claim 1, wherein the action manager (13) receives a 200 OK response from the action agent (14), the 200 OK response comprising response text to the action request inserted into the 200 OK message body.

3. Method according to claim 2, wherein after receiving the 200OK response, the action manager (13) activates a mechanism, in particular, a hot for decoding, analyzing, and/or performing actions based on the response text comprised in the 200OK response.

4. Method according to any one of claims 1 to 3, wherein the request and response scripts are selected from Lua script, Shell script, Bash scipt, or ANY.

5. Method according to any one of claims 1 to 4, wherein the method is started by receiving a token at the first server (7).

6. Method according to any one of the preceding claims, wherein the action manager (13) is implemented in the first server (7), or the action manger (13) is a virtual machine.

7. Health monitoring system, comprising a at least one first platform (4) with a first SIP server (7) and at least one second platform (5) with a second SIP server (8), the first SIP server (7) and the second SIP server (8) being connected to each other in a SIP -based communication network (1), wherein an action manager (13) is provided for the first SIP server (7), and an action agent (14) is provided for the second SIP server (8), wherein the action manager (13) is adapted to

prepare an action request to be sent to the action agent (14) by using a SIP OPTIONS message and inserting the action request script into the SIP OPTIONS message body, wherein the action request script comprising instructions for performing health monitoring at the second SIP server (8).

8. System according to claim 7, wherein the action agent (14) is adapted to

prepare an action response to be sent to the action manager (13) by using a 200OK message and inserting the action response script into the 200OK message body, wherein the action response comprises content concerning the result from the action request.

9. System according to claim 7 or claim 8, wherein the first server (7) is an OSB server, and the second server (8) is an OSB server, respectively implementing OSV.

10. System according to any one of claims 7 to 9, wherein the action manager (13) is embedded in the first server (7), or is provided as a virtual machine.

11. System according to any one of claims 7 to 10, wherein the action manager (13) is adapted to automatically monitor and/or control and/or supervise the second SIP server (8).