WO2019199290A1

WO2019199290A1 - Correlating and analyzing multi-hop sip calls in voip networks

Info

Publication number: WO2019199290A1
Application number: PCT/US2018/026975
Authority: WO
Inventors: Wen Zhang; Longping Guo; Anilkumar Kollipara; Lv Lv
Original assignee: Netscout Systems Texas, Llc
Priority date: 2018-04-10
Filing date: 2018-04-10
Publication date: 2019-10-17

Abstract

A method for analyzing multi-hop messages in a VOIP network includes monitoring a plurality of messages exchanged between a user agent client (UAC) and a user agent server (UAS). A determination is made if one or more of the plurality of monitored messages comprises a multi- hop message by analyzing header fields of the plurality of messages. A determination is made if a node list exists for the one or more multi-hop messages. The node list includes a plurality of network nodes participating in exchanges of corresponding messages between the UAC and UAS. The node list is generated in response to determining the node list does not exist. The node list is updated, in response to determining the node list does exist.

Description

Patent Application For: CORRELATING AND ANALYZING MULTI-HOP SIP CALLS IN YOIP

NETWORKS

Inventor: Wen Zhang, Bill Guo, Anil Kollipara, Lv Lv

LIELD OL THE INVENTION

Embodiments of the present invention relate generally to telecommunications, and specifically to correlating and analyzing multi-hop Session Initiation Protocol (SIP) calls in Voice over IP (VoIP) networks.

BACKGROUND OE THE INVENTION

Voice telecommunications has traditionally been conducted via dedicated telephone networks utilizing telephone switching offices and either wired or wireless connections for transmitting the voice signal between the users' telephones. Such telecommunications, which use the Public Switched Telephone Network (PSTN), may be referred to as circuit committed communications. VoIP network provides an alternative voice telecommunication means which use discrete packets digitized voice information to transmit the voice signals. The packets are transmitted either over the public Internet or within intranets.

Typical VoIP network infrastructure includes gateways, gatekeepers, proxy servers, soft switches, session border controllers, and the like. Due to optimization of network resources and to particular designs, network operators may choose to integrate functionality of the separate components with one another such that multiple infrastructure components can be collocated on one physical component. SIP protocol describes how to set up Internet telephone calls, videoconferences, and other multimedia connections. SIP can establish two-party sessions (ordinary telephone calls), multiparty sessions (where everyone can hear and speak), and multicast sessions (one sender, many receivers). The sessions may contain audio, video, or data. SIP handles call setup, call management, and call termination and may use other protocols to do so, such as Real-time Transport Protocol (“RTP”) for transporting real-time data and providing Quality of Service (“QoS”) feedback, and the Real-Time Streaming Protocol (“RTSP”) for controlling delivery of streaming media. SIP is an application layer protocol and can run over the user datagram protocol (“UDP”) or the transport control protocol (“TCP”), for example.

SIP call setup procedure uses a handshake mechanism between a User Agent Client

(UAC) and a User Agent Server (UAS). However, typically not all messages are routed directly between a client (UAC) and a server (UAS). Some SIP messages may traverse several proxies on either their way from a UAC to a UAS or the reverse route. Yet other messages may bypass the proxies and may be transmitted directly between a UAC and a UAS.

Accordingly, as a result of this bypass behavior, it is desirable to have systems capable of correlating the entire SIP call into a single session and evaluating the performance of the call as a whole. SUMMARY OF THE INVENTION

The purpose and advantages of the illustrated embodiments will be set forth in and apparent from the description that follows. Additional advantages of the illustrated embodiments will be realized and attained by the devices, systems and methods particularly pointed out in the written description and claims hereof, as well as from the appended drawings. In accordance with a purpose of the illustrated embodiments, in one aspect, a method for analyzing multi-hop messages in a VOIP network includes monitoring a plurality of messages exchanged between a user agent client (UAC) and a user agent server (UAS). A determination is made if one or more of the plurality of monitored messages comprises a multi-hop message by analyzing header fields of the plurality of messages. A determination is made if a node list exists for the one or more multi-hop messages. The node list includes a plurality of network nodes participating in exchanges of corresponding messages between the UAC and UAS. The node list is generated in response to determining the node list does not exist. The node list is updated, in response to determining the node list does exist.

In another aspect, a network device for monitoring and analyzing multi-hop messages in a VOIP network is configured to monitor a plurality of messages exchanged between a user agent client (UAC) and a user agent server (UAS). The network device is further configured to determine if one or more of the plurality of monitored messages comprises a multi-hop message by analyzing header fields of the plurality of messages. The network device is also configured to

determine if a node list exists for the one or more multi -hop messages. The node list includes a plurality of network nodes participating in exchanges of corresponding messages between the UAC and UAS. The network device is further configured to generate the node list in response to determining the node list does not exist or update the node list in response to determining the node list does exist.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying appendices and/or drawings illustrate various, non-limiting, examples, inventive aspects in accordance with the present disclosure: FIG. 1 is a block diagram showing aspects of an illustrative operating environment and several software components provided by the embodiments presented herein;

FIG. 2 is a sequence diagram illustrating an exemplary SIP call flow that includes a proxy in a VoIP system;

FIG. 3 is a sequence diagram illustrating an exemplary SIP call flow that includes multiple call setup candidates in a VoIP system;

FIG. 4 is a flowchart illustrating operation of an embodiment of the present invention;

FIG. 5 is a diagram illustrating an exemplary node list generated in accordance with embodiments of the present invention;

FIG. 6 is a diagram illustrating a procedure for generating the exemplary node list of FIG. 5 in accordance with embodiments of the present invention; and

FIG. 7 is a diagram illustrating multiple choice scenario wherein messages are correlated using an exemplary pool of node lists generated in accordance with embodiments of the present invention.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

The present invention is now described more fully with reference to the

accompanying drawings, in which illustrated embodiments of the present invention are shown wherein like reference numerals identify like elements. The present invention is not limited in any way to the illustrated embodiments as the illustrated embodiments described below are merely exemplary of the invention, which can be embodied in various forms, as appreciated by one skilled in the art. Therefore, it is to be understood that any structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative for teaching one skilled in the art to variously employ the present invention. Furthermore, the terms and phrases used herein are not intended to be limiting but rather to provide an understandable description of the invention.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although any methods and materials similar or equivalent to those described herein can also be used in the practice or testing of the present invention, exemplary methods and materials are now described. It must be noted that as used herein and in the appended claims, the singular forms“a”,“an,” and“the” include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to“a stimulus” includes a plurality of such stimuli and reference to“the signal” includes reference to one or more signals and equivalents thereof known to those skilled in the art, and so forth.

It is to be appreciated the embodiments of this invention as discussed below are preferably a software algorithm, program or code residing on computer useable medium having control logic for enabling execution on a machine having a computer processor. The machine typically includes memory storage configured to provide output from execution of the computer algorithm or program.

As used herein, the term“software” is meant to be synonymous with any code or program that can be in a processor of a host computer, regardless of whether the

implementation is in hardware, firmware or as a software computer product available on a disc, a memory storage device, or for download from a remote machine. The embodiments described herein include such software to implement the equations, relationships and algorithms described below. One skilled in the art will appreciate further features and advantages of the invention based on the below-described embodiments. Accordingly, the invention is not to be limited by what has been particularly shown and described, except as indicated by the appended claims. In exemplary embodiments, a computer system component may constitute a“module” that is configured and operates to perform certain operations as described herein below. Accordingly, the term“module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily configured (e.g. programmed) to operate in a certain manner and to perform certain operations described herein.

The following detailed description is directed to technologies for handling early media in a VoIP call with multiple hops. Utilizing the technologies described herein, a calling device may negotiate a VoIP call with one or multiple intermediate devices, perform connectivity checks, establish media connections, and exchange early media, all before the callee answers the call. Once the callee answers the call, the calling device can utilize the media connections already established with the callee device on which the callee answered to exchange content media (audio and/or video).

While the subject matter described herein is presented in the general context of program modules that execute in conjunction with the execution of an operating system and application programs on a computer system, those skilled in the art will recognize that other implementations may be performed in combination with other types of program modules. Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, although many of the embodiments discussed below refer to

communications via the SIP protocol, one of skill in the art may readily apply these systems and methods to communications via similar signaling protocols.

FIG. 1 shows an illustrative operating environment 100 including several software components for supporting SIP-based VoIP communications between a caller's

communication device and a callee communication device, according to embodiments provided herein. As noted above, the SIP is a signaling protocol used by many VoIP devices to perform basic call-control tasks, such as session call setup, tear down, and signaling for features such as call hold, caller ID, conferencing, and call transferring. SIP provides the mechanisms to establish a VoIP call or session between UACs located on two or more communication devices, or“endpoints,” participating in the call.

The environment 100 illustrated in FIG. 1 includes a caller 102 utilizing a VoIP- enabled communication device 104. The caller's communication device 104 may be a computing device running a communication application 106. The communication application 106 may also be embedded in the firmware or operating system of the caller's communication device 104, such as the firmware of an IP telephone set. It will be appreciated that the caller's communication device 104 may be any VoIP-enabled communication device that uses SIP to establish voice or video calls, as will be described in more detail below.

The caller's communication device 104 includes a protocol stack 108 supporting SIP. The protocol stack 108 provides facilities to allow the communication application 106, acting as the UA on the caller's communication device 104, to establish SIP-based VoIP calls with a callee 110 at one of the callee's communication devices 112A-112C over an IP network 114. The IP network 114 may be the Internet or a corporate local area network (“LAN”) or wide- area network (WAN”). The callee's communication devices 112A-112C may include VoIP- enabled devices, such as an IP telephone set 112A or a computer device 112B connected directly to the IP network 114, as well as traditional telephone devices, such as a cellular phone 112C.

The callee's communication devices 112A-112C may also execute a program that acts as a UA to participate in the SIP-based VoIP call. A VoIP call between the caller's communication device 104 (which may include a traditional telephone device) and callee’s communication device, such as the callee's cellular phone 112C, may be facilitated through a UAS 116. As a non-limiting example, the UAS 116 may comprise a VoIP gateway that bridges the IP network 114 with the Public Switched Telephone Network (“PSTN”) 118.

The transfer of SIP signaling to setup the VoIP calls often takes place through one or more SIP proxy servers 120 located on the IP network 114. The SIP proxy server 120 acts as an intermediary between the UAs on the endpoints and the UAS 116, participating in the call to perform various routing functions. The media content (voice and/or video) of the call is exchanged directly between the endpoints participating in a SIP-based VoIP call using different communication channels than the SIP signaling. The exchange of media also utilizes different protocols, such as the RTP. The protocol stack 108 may also include support for these protocols to enable the direct exchange of media content between the caller's communication device 104 and the other endpoints participating in the VoIP call.

The network may also interface with a cellular or other wireless system, such as for example a 3G IMS (IP multimedia subsystem) system, in order to provide multimedia calls between a user or consumer in the household domain (e.g., using a SIP phone or H.323 terminal) and a mobile 3G, 4G or 5G telephone or personal media device (PMD) user via that user's radio access network (RAN).

Advantageously, various embodiments of the present invention contemplate a quality monitoring system that timely and accurately analyzes VoIP communication sessions.

According to an embodiment of the present invention, this quality monitoring system may include, but not limited to, a server for monitoring data communication at various locations or links of the environment 100. A plurality of media communication sessions including data transfer sessions, Voice-over-IP (VoIP) and video communication (including video on demand) and streaming audio and video sessions, such as, but not limited to, interactive video conferencing sessions may be transmitted across the IP network 114. As shown in FIG. 1, a media session quality monitoring system 126 may be communicatively connected to the IP network 114. In an embodiment of the present invention, the media session quality monitoring system 126 may comprise, or otherwise may cooperate with a call monitor software program 124. Call monitor 124 may comprise program instructions stored on one or more computer-readable storage devices, which may include internal storage on the media session quality monitoring system 126. Call monitor 124 may be, for example, a computer program or program component capable of capturing certain quality related information with respect to monitored calls, in real time. The call monitors 124 are hardware, software, firmware or a combination thereof for monitoring data communication at various locations or links of the environment 100. Each of the call monitors 124 may be deployed at certain locations or links of the environment 100 to collect network data packets traversing the locations or links.

FIG. 2 is a sequence diagram illustrating an exemplary SIP-to-SIP call flow that includes a proxy in a VoIP system. For the purposes of illustration, the source (or originating) endpoint UAC 202 is the communication device 104 and the UAS 206 is the server 116 shown in FIG. 1. The originating UAC 202 initiates a three way handshake procedure by sending an INVITE request signaling message 208,210 to the UAS 206 routing though the proxy 204. The initial request starts an SIP dialog between the originating UAC 202 and a terminating UAC (not shown in FIG. 2), which will typically comprise a number of SIP transactions between the originating UAC 202 and the terminating UAC. A signaling message that complies with the SIP protocol (including the INVITE request 208,210) contains multiple headers. The“From”,“To”, and“Contact” headers relate to the network nodes sending and receiving the signaling message. Each intermediary network node, such as the proxy servers 204, adds a Via header to the retransmitted INVITE request 210. This Via header includes IP address of the intermediary node, such as the proxy server 204, thereby making it possible to mark the path taken by a signaling message within a network. A reply message may then take the same path, in the reverse direction, using the Via headers. Each intermediary node crossed in this manner removes the Via header that pertains to itself.

More specifically, upon receiving the INVITE request 210, the UAS 206 adds its own IP address to the“Contact” header of 200 OK response 212. It should be noted, the UAS 206 routes the response 212 through the same set of proxies traversed by the INVITE request 210 in the reverse order, using the Via headers. When the proxy server 204 gets the 200 OK response 212, the proxy server 204 removes the Via header that includes its IP address from the response 212 before forwarding the response 214 to the UAC 202. However, the 200 OK response 214 forwarded to the UAC 202 still includes the“Contact” header containing the IP address of the UAS 206. Next, the UAC 202 generates an acknowledgment (ACK) message 216 having the mandatory“Request Line” header field set to the IP address of the UAS 206 contained in the“Contact” header field of the response 214. The ACK 216 is used to acknowledge the successful receipt of a message in a transaction. In this case the ACK 216 is sent directly to the UAS 206, bypassing the proxy 204. In the call flow illustrated in FIG. 2, procedures of the same SIP session are associated with three different hops between different source and destination nodes. The first hop 224 is between the proxy server 204 and the UAS 206 and includes the transmission of the INVITE request 210 and the 200 OK response 212. The second hop 226 is between the UAC 202 and the proxy server 204 and includes the transmission of the INVITE request 208 and the 200 OK response 214. The third hop 228 is between the UAC 202 and the UAS 206 and includes the transmission of the ACK message 216, RTP media 218, as well as session termination procedure including the BYE request 220 and the 200 OK response 222. As a result of this proxy server 204 bypass behavior in the multi hop flow illustrated by FIG. 2, it is challenging for the call monitor 124 to correlate the entire SIP call (messages 208-222) into a single session and to evaluate the performance of the call as a whole.

SIP Multiple Choices mechanism is another call flow scenario where one SIP call session behaves as multiple hops between different source and destination nodes. FIG. 3 is a sequence diagram illustrating an exemplary SIP call flow that includes multiple call setup candidates in a VoIP system. In this call scenario, similarly to the scenario illustrated in FIG. 2, the UAC 202 initiates the INVITE request message 310 to a first server 302. However, in this case the first server 302 is unable to proceed with the call setup. In response to receiving the INVITE request message 310, the first server 302 sends back 300 Multiple Choices message 312 indicating a redirection of the call. The 300 Multiple Choices message 312 includes a list of candidate servers that may satisfy the call setup request. In other words, the 300 Multiple Choices message 312 includes several choices, each with its own specific location. The UAC 202 can select a preferred communication node and redirect the INVITE request message to that location. Thus, after sending the acknowledgement message 314 back to the first server 302, the UAC 202 makes another attempt to setup a call by sending second INVITE request message 316 this time to another server selected from received the list of candidates, for example, a second server 304. However, this call setup attempt fails as well.

In this case, the second server 304 sends the 503 Service Unavailable message 318 in response to the received INVITE request message 316. After sending another

acknowledgment message 320 now to the second server 304, the UAC 202 selects yet another candidate from the received list. The candidates may be selected either sequentially or randomly. As shown in FIG. 3, the UAC 202 continues its attempt to setup a call by sending yet another INVITE request message 322 this time to a third server 306. This attempt is successful, since the UAC 202 receives the 200 OK response 324 back from the third server 306. Once the call is established the UAC 202 and the third sever 306 start exchanging RTP Media packets until the session is terminated by the Bye message 328 and the 200 OK message 330 in response.

In the call flow illustrated in FIG. 3, procedures of the same SIP session are also associated with three different hops between different source and destination nodes. The first hop 332 is between the UAC 202 and the first server UAS server 302 and includes the transmission of the INVITE request 310, the 300 Multiple Choices response 312 and the acknowledgement message 314. The second hop 334 is between the UAC 202 and the second server 304 and includes the transmission of the INVITE request 316, the 503 service unavailable response message 318 and the acknowledgement message 320. The third hop 336 is between the UAC 202 and the third server 306 and includes the transmission of the

INVITE request 322, the 200 OK response message 324, ACK message 326, RTP media 327, as well as session termination procedure including the BYE request 328 and the 200 OK response 330.

The call scenario illustrated in FIG. 3 is similar to the scenario illustrated in FIG. 2 since in both cases there are multiple components of the same call that are seen on different interfaces and that have different source/destination nodes at each end of a particular SIP session. It should be noted that in both call flows illustrated in FIGS. 2 and 3 none of the components can independently provide accurate information about the entire call due to having incomplete and/or inaccurate information about all components collectively.

Currently, these multiple components of the same call need to be analyzed manually to accurately understand true performance of the monitored network. However, manual analysis of such information is burdensome, time-consuming, and prone to human error.

Various embodiments of the present invention solve the aforementioned problem of accurate monitoring of SIP calls by automatically correlating all components of each monitored call irrespective of the presence of one or more intermediary nodes. FIG. 4 is a flowchart illustrating operation of an embodiment of the present invention. Before turning to description of FIG. 4, it is noted that the flow diagram shown therein is described, by way of example, with reference to components shown in FIGS. 1-3 and 5-7, although these operational steps may be carried out in any system and are not limited to the scenario shown in the aforementioned figure. Additionally, the flow diagram in FIG. 4 illustrates an example in which operational steps are carried out in a particular order, as indicated by the lines connecting the blocks, but the various steps shown in this diagram can be performed in any order, or in any combination or sub-combination. It should be appreciated that in some embodiments some of the steps described below may be combined into a single step. In some embodiments, one or more additional steps may be included.

At step 402, the call monitor 124 starts monitoring the environment 100 by monitoring particular predefined channels transporting a plurality of signals (e.g., SIP messages) exchanged between UACs and UASes. The exchanged signaling may include signaling utilized for conventional call setup for IP telephony described above. At step 404, the call monitor 124 analyzes header fields of the monitored messages. A signaling message that complies with the SIP protocol typically contains multiple headers. In various embodiments, the call monitor 124 may monitor both conventional header fields and extension header fields. At step 406, the call monitor 124 uses the header field analysis performed at the step 404 to determine if a particular message belongs to multi-hop routing between a plurality of network nodes. For example, at step 406, the call monitor 124 determines if the analyzed message(s) belong(s) to one of the call flow scenarios illustrated in FIGS. 2 and 3.

According to embodiments of the present invention, the call monitor 124 is configured and operable to automatically correlate all components of each monitored call using a data structure for maintaining information related to a flow of a monitored call. This data structure is referred to hereinafter as a node list.

According to embodiments of the present invention, the call monitor 124 generates and maintains node lists based on one or more predefined rules. In one embodiment, the predefined rules may include but are not limited to the following rules:

1) all UAC nodes are associated only with transmission of outbound request messages (e.g., INVITE request signaling message 208) and receipt of inbound response messages (e.g., 200 OK response messages 214);

2) all UAS nodes are associated only with receipt of inbound request messages (e.g., INVITE request signaling message 210) and transmission of outbound response messages

(e.g., 200 OK response message 212);

3) all proxy node servers are associated with both transmission of outbound and receipt of inbound request messages and transmission of outbound and receipt of inbound response messages;

4) all Via headers of messages received by a UAS include IP addresses of all intermediary network nodes traversed by this particular message before arriving at the UAS;

5) all proxy node servers are configured to add a new Via header containing the IP address of that proxy node server for each received request message;

6) all proxy node servers are configured to remove a corresponding Via header from each received response message;

7) number of proxy server nodes can be calculated by subtracting the number of Via headers of the UAC’s outbound Setup invite request message from the number of Via headers of the UAS’s inbound Setup request message; 8) number of proxy server nodes can be calculated by subtracting the number of Via headers of the UAC’s inbound response message from the number of Via headers of the UAS’s outbound response message; and

9) number of bypass nodes can be calculated by subtracting the proxy node number of the acknowledgement message from the proxy node number of the invite request message

(Since SIP ACK will directly be sent from UAC to UAS bypassing all the interim proxies).

It should be noted that with respect to the above rules 5 and 6, the call monitor 124 may encounter outbound request messages and inbound request messages having the same call identifier, message type and command sequence number. For example, referring back to FIG. 2, the INVITE requests 208 and 210 will have the same call identifier, same message type and same command sequence number. However, since the proxy server 204 is configured to insert a new Via header, the number of Via headers in the outbound INVITE request message 210 will be greater than the number of Via headers in the inbound INVITE request message 208 by one header.

Similarly, the call monitor 124 may encounter outbound response messages and inbound response messages having the same call identifier, message type and command sequence number. For example, referring back to FIG. 2 yet again, the 200 OK responses 212 and 214 will have the same call identifier, same message type and same command sequence number. However, since the proxy server 204 is configured to remove a corresponding Via header, the number of Via headers in the outbound response message 214 will be less than the number of Via headers in the inbound response message 212 by one header.

FIG. 5 is a diagram illustrating an exemplary node list generated in accordance with embodiments of the present invention. As shown in FIG. 5, the node list 500 may comprise a plurality of data nodes 502a-n linked together. In one embodiment, the node list 500 is implemented as a linked list that keeps track of network node information for each node traversed by a particular message. Each of the data nodes represents a particular network node which can be identified by an IP address, DNS, hostname, branch id or any other unique identifier in a single call flow. The node list includes a head node 502a as the very first node of the list 500 and a tail node 502n as the last node on the list 500. In one embodiment, the head node 502a represents the UAC 202 while the tail node 502n represents the LIAS 206. One or more nodes 502b 502n-l between the head node 502a and the tail node 502n represent one or more intermediary nodes (e.g., proxy node servers) which can be detected by the call monitor 124 using rules 5 or 6 listed above. In an alternative embodiment, the call monitor 124 can detect one or more intermediary nodes by combining rules 4, 7, 8 and 9 and by comparing the corresponding Via header content information it should be noted that even if the media session quality monitoring system 126 is not configured to perform end-to-end monitoring, the call monitor still may utilize the methodology disclosed by various embodiments presented herein.

According to embodiments of the present invention, in addition to the node list 500, the call monitor 124 may maintain one or more parameters associated with each call flow.

As a non-limiting example, the parameters maintained by the call monitor 124 may include a remote tag value, command sequence (“CSeq”) value, response code value, Ack Received value and first node position value. The remote tag value (“To tag”) is typically assigned by the final recipient of the message or the UAS 206. The UAS 206 puts its tag in the“To” header. So, when the UAS 206 receives a request message and responds back with a response (e.g., 200 OK response 212), it then adds a tag to the“To” header. In one embodiment, the call monitor 124 may use the remote tag value to map acknowledgement messages to corresponding INVITE requests in order to make sure the mapped messages belong to the same call flow and the same dialog. The CSeq value typically serves as a way to identify and order transactions. The call monitor 124 may use the CSeq value to map INVITE request messages to corresponding response messages. The response code value is the final response code from the response to an INVITE message. The first node position value indicates an IP address of the first network node represented by the head data node 502a in the node list 500. At least in some embodiments, it is highly likely that the first node 502a in the node list may contain information associated with the UAC 202, since majority of the SIP call flows originate at the U AC 202. It should be noted that even if the media session quality monitoring system 126 is not configured to perform end-to-end monitoring, the call monitor 124 may maintain a subset of the entire node list 500.

Referring back to FIG. 4, in response to determining that the analyzed message comprises a multi-hop message (decision block 406,“yes” branch), at step 408, the call monitor 124 may check whether a node list corresponding to the analyzed call flow session exists. In response to determining that the corresponding node list 500 does exist (decision block 408,“yes” branch), the call monitor 124 updates the node list 500 (step 410). For example, step 410 may involve the call monitor 124 inserting a new node into the node list 500. However, if the call monitor 124 determines that the corresponding node list 500 does not exist yet (decision block 408,“No” branch), it may generate a new node list 500 (step 412).

FIG. 6 is a diagram illustrating an exemplary node list generated in accordance with embodiments of the present invention. In SIP protocol, the“Call ID” header acts as a unique identifier to group together a series of messages. It must be the same for all requests and responses in a dialog. The generation of the node list is based on Via headers. The Via header indicates the transport used for the transaction and identifies the node where the response is to be sent. In fact, it indicates the path taken by the request so far and indicates the path that should be followed in routing responses. The Via header field value also contains the node's network address, and possibly the port number at which it wishes to receive response. The call monitor 124 builds the node list iteratively by processing monitored messages (e.g., SIP messages). First, the call monitor 124 determines whether the subject message comprises either a request (e.g., INVITE request message) or a response 2l2(e.g., 200 OK response message). According to an embodiment of the present invention, for each request/response message the call monitor 124 may repeat the following sequence of steps:

1) build a VIA list 614, such that the lowest VIA header is represented as the first VIA list element 616 and the highest VIA header is represented by the last VIA list element 618;

2) if the processed message is a request message (e.g., Request Message 602 having a pair of Source IP address 604 and destination IP address 606), replace 610 the highest VIA header 618 with the IP address of the source node 604 and append 612 the destination IP address 606 to the end of the VIA list 614;

3) if the processed message is a response message being routed in the opposite direction, replace the highest VIA header with the IP address of the destination node and append the source IP address to the end of the VIA list 614 (in other words, in this case, the highest VIA list element 618 should contain the IP address 604 of the message destination node);

4) generate the node list 500 based on the generated VIA list 614 as shown in FIG. 6, so that the head node 502a contains the value of the first VIA list element 616 and the tail node 502n contains the value of the source/destination IP address.

According to an embodiment of the present invention, after the node list 500 is generated, the call monitor 124 may update values of the maintained first node position and CSeq parameters. Furthermore, the call monitor 124 may store corresponding values of the remote tag and response code parameters if they were detected within the processed message. According to an embodiment of the present invention, for each analyzed

acknowledgment message the call monitor 124 may repeat the following sequence of steps:

1) compare the remote tag and the CSeq values of the analyzed message with corresponding parameter values (remote tag and CSeq) maintained by the node list 500. If both values match then the node list 500 is the parent list of the analyzed acknowledgment message;

2) check the ACK Received parameter value maintained by the node list 500. If the stored parameter value is indicative of the position of the network node sending the analyzed acknowledgment message 216 then the call monitor 124 does nothing. Otherwise, the call monitor 124 stores the value indicative of the position of the network node sending the analyzed acknowledgment message 216 as the ACK Received parameter maintained by the node list 500.

Referring back to FIG. 4 yet again, after processing all monitored messages, the call monitor 124 may correlate the messages to SIP sessions using the updated node list(s) 500 (step 414). This step may involve adjusting the direction of the message based on the conventional call setup procedure. It should be noted that a node list nodel node2 is different from a node list node2 nodel. The direction of the message (e.g., the 200 OK message 324) matters and can be determined based the corresponding INVITE request message 316. For each analyzed message, the call monitor 124 identifies source

node/destination node pairs and compares the identified pairs with the nodes stored in the node list 500. For each identified source node/destination node pair, if the pair is part of the node list 500 then the call monitor 124 correlates the corresponding message to the same SIP session. Furthermore, if the identified source node/destination node pair is the same with any of the node pairs defined by position information provided by the repeated Acknowledgment Received parameter then the call monitor 124 also correlates the corresponding message to the same SIP session associated with the node list 500. For example, if the node list 500 includes nodes nodel node2 node3 node4, and if the call monitor 124 finds a particular request message having a route nodel node2, node2 node3, node3 node4 and a response message having a route node4 node3, node3 node2, node2 nodel the call monitor 124 correlates these messages to the same SIP session.

FIG. 7 is a diagram illustrating multiple choice scenario wherein messages are correlated using an exemplary pool of node lists generated in accordance with embodiments of the present invention. It should be noted that the multiple choice call scenario is illustrated in FIG. 3. According to an embodiment of the present invention, for a particular multiple choice call scenario the call monitor 124 may generate a pool of node lists 700. This pool of node lists 700 may include a plurality of node lists 500a - 500n that are associated with this particular multiple choice call scenario. According to an embodiment of the present invention, one of the plurality of node lists 500a-500n should have response code parameter value be equal to 3XX (representing, for example, the 300 Multiple Choices message 312 including a list of candidate servers that may satisfy the call setup request). Furthermore, optionally one or more of the plurality of node lists 500a-500n should have response code parameter value be equal to 4XX or 5XX (representing, for example, the 503 Service Unavailable message 318). According to embodiments of the present invention, the pool of node lists 700 may include no more than one of the node lists 500a-500n having the response code parameter value being equal to 2XX (representing, for example, the 200 OK message 324 and the acknowledgement message 326). It is further noted that the value of the CSeq parameter for each of the plurality of node lists 500a-500n should be equal to 1. After processing all monitored messages, the call monitor 124 may correlate the messages to SIP sessions using the updated pool of node lists 700 as described above in conjunction with the step 412. In view of the above, embodiments of the present invention provide more accurate technique of monitoring of SIP calls. More specifically, these embodiments disclose a method enabling automatic correlation of all components (legs) of each monitored call irrespective of the number of nodes participating in the SIP session.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a“circuit,”“module” or“system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN), a wide area network (WAN) or WLAN, or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware -based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

What is claimed is:

1. A method for analyzing multi-hop messages in a VOIP network, the method comprising: monitoring a plurality of messages exchanged between a user agent client (UAC) and a user agent server (UAS); determining if one or more of the plurality of monitored messages comprises a multi-hop message by analyzing header fields of the plurality of messages; determining if a node list exists for the one or more multi-hop messages, the node list including a plurality of network nodes participating in exchanges of corresponding messages between the UAC and UAS; and generating the node list in response to determining the node list does not exist or updating the node list in response to determining the node list exists.

2. The method of claim 1, wherein at least some of the plurality of network nodes included in the node list are associated with different hops of the same call.

3. The method of claim 1, further comprising correlating the plurality of monitored messages to call sessions using the generated node list.

4. The method of claim 1, wherein the node list further includes first node information, command sequence number information, information about received acknowledgement message, response code information and remote tag information.

5. The method of claim 4, wherein the remote tag information indicates association between a request message and a corresponding response message.

6. The method of claim 1, wherein determining if one or more of the plurality of monitored messages comprises a multi-hop message further comprises determining a number of hops by analyzing the header fields of the plurality of messages.

7. The method of claim 5, wherein the response code information comprises a final response code associated with a request message.

8. The method of claim 1, wherein the node list is updated based on one or more predefined rules.

9. The method of claim 1, wherein determining if one or more of the plurality of monitored messages comprises a multi-hop message further comprises determining if one or more of the plurality of monitored messages comprises a message containing a list of candidate network nodes to complete a call setup procedure.

10. The method of claim 9, wherein the step of generating the node list further comprises generating a pool of node lists.

11. A network device for monitoring and analyzing multi-hop messages in a VOIP network, the network device is configured to: monitor a plurality of messages exchanged between a user agent client (UAC) and a user agent server (UAS); determine if one or more of the plurality of monitored messages comprises a multi-hop message by analyzing header fields of the plurality of messages; determine if a node list exists for the one or more multi-hop messages, the node list including a plurality of network nodes participating in exchanges of corresponding messages between the UAC and UAS; and generate the node list in response to determining the node list does not exist or update the node list in response to determining the node list exists.

12. The device of claim 11, wherein at least some of the plurality of network nodes included in the node list are associated with different hops of the same call.

13. The device of claim 11, wherein the network device is further configured to correlate the plurality of monitored messages to call sessions using the generated node list.

14. The device of claim 11, wherein the node list further includes first node information, command sequence number information, information about received acknowledgement message, response code information and remote tag information.

15. The device of claim 14, wherein the remote tag information indicates association between a request message and a corresponding response message.

16. The device of claim 11, wherein the network device configured to determine if one or more of the plurality of monitored messages comprises a multi-hop message is further configured to determine a number of hops by analyzing the header fields of the plurality of messages.

17. The device of claim 15, wherein the response code information comprises a final response code associated with a request message.

18. The device of claim 11, wherein the node list is updated based on one or more predefined rules.

19. The device of claim 11, wherein the network device configured to determine if one or more of the plurality of monitored messages comprises a multi-hop message is further configured to determine if one or more of the plurality of monitored messages comprises a message containing a list of candidate network nodes to complete a call setup procedure.

20. The device of claim 19, wherein the network device configured to generate the node list is further configured to generate a pool of node lists.