Patent Description:
IMS is a framework for delivering IP multimedia services and is utilized to provide voice (e.g., Voice over IP (VoIP)) or other multimedia services on user devices over a packet network. That is, fixed and mobile network operators and service providers deploy an IMS network to deliver services to mobile subscribers. Session Initiation Protocol (SIP) is the signaling protocol selected by the 3rd Generation Partnership Project (3GPP) to create and control multimedia sessions with two or more participants in an IMS network and therefore is a key element in the IMS framework. During network operation, various network entities involved in a session are configured to send information for developing a Call Detail Record (CDR). For example, a Charging Data Function (CDF) can be responsible for generating CDRs. As part of this charging functionality, originated and Terminated counters are important statistics for voice call monitoring. Conventionally, in SIP IMS, it is not possible to automatically identify if a call is mobile originated or mobile terminated. To generate statistics per originated and terminated call and to count the proper number of calls and to produce more relevant analytics, there is a need to identify the call direction. <NPL>, describes an example of voice over long term evolution related procedures in an end-to end manner.

<NPL> discloses charging prototype developed and implemented in C.

The present disclosure relates to call direction detection on.

In various embodiments, the present disclosure relates to systems and methods for call direction detection on Session Initiation Protocol (SIP) Internet Protocol (IP) Multimedia Subsystem (IMS). Specifically, the present disclosure includes monitoring SIP register messages, such as "<NUM> UNAUTHORIZED" messages inside the IMS core, to detect and log the IP addresses of the P-CSCF. With a log of the P-CSCF IP addresses, the present disclosure further includes monitoring SIP INVITE messages and noting the source IP address and destination IP address. A match is performed with the log of the P-CSCF IP addresses to determine the direction of the call, i.e., map the source IP address as the Originated Call (OC) and the destination IP address as the Terminated Call (TC).

The following acronyms are utilized herein:.

<FIG> is a flow diagram of a SIP registration process <NUM>. Specifically, the SIP registration process <NUM> illustrates messages exchanged between a UE, P-CSCF, I-CSCF, HSS, and S-CSCF. Generally, the SIP registration process <NUM> is used to bind a Uniform Resource Indicator (URI) with a SIP user. Examples and details of the SIP registration process are described in RFC <NUM> "Session Initiation Protocol (SIP) Basic Call Flow Examples," December <NUM>, the contents of which are incorporated by reference. Details of SIP are described in RFC <NUM>, "SIP: Session Initiation Protocol," June <NUM>.

The present disclosure includes matching between a log of the P-CSCF IP addresses and the source/destination IP addresses of INVITE messages to determine call direction.

An example of a REGISTER message includes, from RFC <NUM>:.

An example of a <NUM> UNAUTHORIZED message includes, from RFC <NUM>:.

The present disclosure includes detecting and learning all of the P-CSCFs in the network, based on the SIP registration process <NUM>. As is known in the art, the P-CSCF is a SIP proxy that is the first point of contact in the IMS network. The present disclosure includes maintaining a database of the IP addresses of all P-CSCFs. The database is maintained by monitoring SIP registration messages, specifically the <NUM> UNAUTHORIZED messages, to detect the IP addresses.

During the SIP registration process <NUM>, <NUM> UNAUTHORIZED messages <NUM> inside the IMS core contains a cipher key (CK), and this message is always destined to the P-CSCF. Note, the <NUM> UNAUTHORIZED messages <NUM> are inside the IMS core and not the one on the Gm interface (between the UE and the P-CSCF in <FIG>). The cipher key is used in IMS security. The cipher key is also referred to as encryption keys and the like. It is the presence of the keys that indicates the <NUM> UNAUTHORIZED messages <NUM> are destined for the P-CSCF, and this allows the designation of the destination IP address of the <NUM> UNAUTHORIZED messages <NUM> to be used as an IP address of a P-CSCF. That is, based on the presence of the keys in the <NUM> UNAUTHORIZED messages <NUM>, it can be assumed the destination is the P-CSCF.

Accordingly, the present disclosure includes flagging, storing, monitoring, etc. any <NUM> UNAUTHORIZED messages <NUM> in the IMS core having the keys therein, and storing the destination IP address in a database that includes IP addresses of P-CSCFs in the network.

In the SIP registration process <NUM>, the S-CSCF and I-CSCF may be separate from one another and from the P-CSCF, as is shown in <FIG>. In this case, there are multiple <NUM> UNAUTHORIZED messages <NUM> in the IMS core. That is, there are <NUM> UNAUTHORIZED messages <NUM> from the S-CSCF to the I-CSCF and <NUM> UNAUTHORIZED messages <NUM> from the I-CSCF to the P-CSCF. Of note, the <NUM> UNAUTHORIZED messages <NUM> are destined for the P-CSCF, whereas the <NUM> UNAUTHORIZED messages <NUM> are destined for the I-CSCF.

Note, all <NUM> UNAUTHORIZED (<NUM> UNAUTHORIZED messages <NUM>, <NUM> in the example) are destinated to P-CSCF, but only the <NUM> UNAUTHORIZED messages <NUM> have the IP address of the P-CSCF as a destination. Thus, only the <NUM> UNAUTHORIZED messages <NUM> are used to identify the P-CSCF and learn their IP addresses.

It is possible to identify and distinguish the <NUM> UNAUTHORIZED messages <NUM> from the <NUM> UNAUTHORIZED messages <NUM> using VIA headers in the associated <NUM> UNAUTHORIZED messages <NUM>, <NUM>. The <NUM> UNAUTHORIZED messages <NUM> will have exactly two VIA headers. The VIA header identifies the protocol name, protocol version, transport type, IP address of the UAC, and the protocol port used for a request. The <NUM> UNAUTHORIZED messages <NUM> will have exactly two VIA headers therein, such as, e.g.:.

Thus, the present disclosure can include distinguishing the <NUM> UNAUTHORIZED messages <NUM> from the <NUM> UNAUTHORIZED messages <NUM> by the two VIA headers. All of the <NUM> UNAUTHORIZED messages <NUM> can be used to identify the IP addresses of the P-CSCF, and the <NUM> UNAUTHORIZED messages <NUM> can be ignored for this purpose.

The present disclosure can use the destination IP addresses from the <NUM> UNAUTHORIZED messages <NUM> to detect P-CSCFs. These IP addresses are stored in the database for future use, and this process can continue over time to flag new P-CSCFs. Also, existing entries in the database can age out where they are not seen over a period of time, where P-CSCFs change IP addresses or are no longer operational.

<FIG> is a flow diagram of a SIP INVITE process <NUM>. Specifically, the SIP INVITE process <NUM> illustrates messages exchanged between an originated caller, originated P-CSCF, originated S-CSCF, terminating I-CSCF, terminating S-CSCF, terminating P-CSCF, and the terminating caller ("called").

The present disclosure includes flagging, monitoring, and analyzing SIP INVITE messages <NUM> (labeled as SIP INVITE messages 202A, 202B for Alice and Bob, respectively), and this can be for a single call. The IP addresses in the SIP INVITE messages <NUM> can be matched against the database. There can be three results from this matching -.

That is, the direction of the call is determined from the source/destination address in the SIP INVITE message <NUM> matching an address that is known to be a P-CSCF. In the SIP INVITE process <NUM>, for example, a SIP INVITE message 202A from the P-CSCF <NUM> in the IMS core associated with Alice will have a source IP address for the P-CSCF <NUM>. Thus, the Alice side of this call will be marked as OC, i.e., the source IP address in the SIP INVITE message 202A matches a stored address for the P-CSCF <NUM>. A SIP INVITE message 202B to the P-CSCF <NUM> in the IMS core associated with Bob will have a destination IP address for the P-CSCF <NUM>. Thus, the Bob side of this call will be marked as TC, i.e., the destination IP address in the SIP INVITE message 202B matches a stored address for the P-CSCF <NUM>. Note, this approach here is based on monitoring the SIP INVITE messages 202A, 202B in the IMS core (between P-CSCFs). The convention is the opposite when monitoring on the Gm interface. For example, a destination IP address on the Gm interface for a SIP INVITE message matching a P-CSCF would be the OC, and a source IP address on the Gm interface for a SIP INVITE message matching a P-CSCF would be the TC.

This information is used in a CDR to denote the call direction, whether the call is mobile-originated or mobile-terminated, etc..

Note, in an embodiment, the SIP INVITE messages <NUM> are only flagged, monitored, analyzed, etc. in the IMS core, not ones on the Gm interface. Of course, in another embodiment, it is possible to monitor messages on the Gm interface as well. The monitoring aspect is based on where a monitoring system has visibility. The various techniques described herein apply as well to the Gm interface, namely identifying P-CSCFs and their IP addresses and determining call direction based on SIP INVITE messages and the source/destination IP addresses therein.

For identifying P-CSCFs on the Gm interface, the destination IP address in REGISTER messages <NUM> can be saved as identified P-CSCFs. The REGISTER message <NUM> comes after the <NUM> UNAUTHORIZED message and will have an Encapsulating Security Payload (ESP) layer. <FIG> is a flow diagram of the SIP registration process <NUM> illustrating the REGISTER message <NUM>. This step is identical to the identification of P-CSCFs in the IMS core based on the <NUM> UNAUTHORIZED messages <NUM> described above.

Also, the SIP INVITE messages on the Gm interface can be used to detect call direction, as mentioned above.

<FIG> is a flow chart of a call direction detection process <NUM>. The call direction detection process <NUM> contemplates implementation as a method, as instructions stored on a non-transitory computer-readable medium, and via an apparatus such as a processing device <NUM> as described in <FIG>. The call direction detection process <NUM> includes monitoring Session Initiation Protocol (SIP) registration messages (step <NUM>); determining and storing addresses of Proxy-Call Session Control Functions (P-CSCFs) based on the monitoring of the SIP registration messages, wherein P-CSCF addresses are determined from any SIP registration messages having cipher or encryption keys therein (step <NUM>); monitoring SIP INVITE messages (step <NUM>); and, for a specific call associated with a SIP INVITE message, determining a direction of the specific call based on a comparison of address in the SIP INVITE messages with the stored addresses of the P-CSCFs (step <NUM>).

The monitoring steps <NUM>, <NUM> can be in Internet Protocol (IP) Multimedia Subsystem (IMS) core only, excluding messages on a Gm interface. Alternatively, the monitoring steps <NUM>, <NUM> may include the Gm interface, including only the Gm interface.

For monitoring in the IMS core only, the determining the addresses of the P-CSCFs is based on Internet Protocol (IP) addresses in <NUM> UNAUTHORIZED messages of the SIP registration messages, with the cipher or encryption keys therein. The <NUM> UNAUTHORIZED messages of the SIP registration messages used for determining the P-CSCFs include only two VIA headers to distinguish between the <NUM> UNAUTHORIZED messages destined for the P-CSCFs and Interrogating-Call Session Control Functions (I-CSCFs).

The comparison of address in the SIP INVITE messages determines whether a destination address and/or source address match one of the stored addresses of the P-CSCFs, wherein when the destination address matches one of the stored addresses, the specific call is a terminating call, and wherein when the source address matches one of the stored addresses, the specific call is an originating call.

The call direction detection process <NUM> can include marking the specific call as mobile terminating if a destination address in the SIP INVITE message matches one of the stored addresses (step <NUM>); and marking the specific call as mobile originating if a source address in the SIP INVITE message matches one of the stored addresses (step <NUM>).

<FIG> is a block diagram of a processing device <NUM>. The processing device <NUM> may be a digital computer that, in terms of hardware architecture, generally includes a processor <NUM>, input/output (I/O) interfaces <NUM>, a network interface <NUM>, a data store <NUM>, and memory <NUM>. It should be appreciated by those of ordinary skill in the art that <FIG> depicts the processing device <NUM> in an oversimplified manner, and a practical embodiment may include additional components and suitably configured processing logic to support known or conventional operating features that are not described in detail herein. The components (<NUM>, <NUM>, <NUM>, <NUM>, and <NUM>) are communicatively coupled via a local interface <NUM>. The local interface <NUM> may be, for example, but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface <NUM> may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, among many others, to enable communications. Further, the local interface <NUM> may include address, control, and/or data connections to enable appropriate communications among the aforementioned components.

The processor <NUM> is a hardware device for executing software instructions. The processor <NUM> may be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the processing device <NUM>, a semiconductor-based microprocessor (in the form of a microchip or chipset), or generally any device for executing software instructions. When the processing device <NUM> is in operation, the processor <NUM> is configured to execute software stored within the memory <NUM>, to communicate data to and from the memory <NUM>, and to generally control operations of the processing device <NUM> pursuant to the software instructions. The I/O interfaces <NUM> may be used to receive user input from and/or for providing system output to one or more devices or components. The user input may be provided via, for example, a keyboard, touchpad, and/or a mouse. System output may be provided via a display device and a printer (not shown). I/O interfaces <NUM> may include, for example, a serial port, a parallel port, a Small Computer System Interface (SCSI), a Serial ATA (SATA), a fiber channel, InfiniBand, iSCSI, a PCI Express interface (PCI-x), an Infrared (IR) interface, a Radio Frequency (RF) interface, a Universal Serial Bus (USB) interface, or the like.

The network interface <NUM> may be used to enable the processing device <NUM> to communicate over the network <NUM>, etc. The network interface <NUM> may include, for example, an Ethernet card or adapter or a Wireless Local Area Network (WLAN) card or adapter. The network interface <NUM> may include address, control, and/or data connections to enable appropriate communications on the network. A data store <NUM> may be used to store data. The data store <NUM> may include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, and the like)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, and the like), and combinations thereof. Moreover, the data store <NUM> may incorporate electronic, magnetic, optical, and/or other types of storage media. In one example, the data store <NUM> may be located internal to the processing device <NUM>, such as, for example, an internal hard drive connected to the local interface <NUM> in the processing device <NUM>. Additionally, in another embodiment, the data store <NUM> may be located external to the processing device <NUM>, such as, for example, an external hard drive connected to the I/O interfaces <NUM> (e.g., SCSI or USB connection). In a further embodiment, the data store <NUM> may be connected to the processing device <NUM> through a network, such as, for example, a network-attached file server.

The memory <NUM> may include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.), and combinations thereof. Note that the memory <NUM> may have a distributed architecture, where various components are situated remotely from one another, but can be accessed by the processor <NUM>. The software in memory <NUM> may include one or more software programs, each of which includes an ordered listing of executable instructions for implementing logical functions. The software in the memory <NUM> includes a suitable operating system (O/S) <NUM> and one or more programs <NUM>. The operating system <NUM> essentially controls the execution of other computer programs, such as the one or more programs <NUM>, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services.

The one or more programs <NUM> may be configured to implement the various processes, algorithms, methods, techniques, etc. described herein, such as with respect call direction detection. Generally, the processing device <NUM> is configured to flag, monitor, analyze, store, etc. the messages <NUM>, <NUM>, <NUM>, manage the database of P-CSCF IP addresses, and identify call direction in SIP IMS using the database.

It will be appreciated that some embodiments described herein may include or utilize one or more generic or specialized processors ("one or more processors") such as microprocessors; Central Processing Units (CPUs); Digital Signal Processors (DSPs): customized processors such as Network Processors (NPs) or Network Processing Units (NPUs), Graphics Processing Units (GPUs), or the like; Field-Programmable Gate Arrays (FPGAs); and the like along with unique stored program instructions (including both software and firmware) for control thereof to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the methods and/or systems described herein. Alternatively, some or all functions may be implemented by a state machine that has no stored program instructions, or in one or more Application-Specific Integrated Circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic or circuitry. Of course, a combination of the aforementioned approaches may be used. For some of the embodiments described herein, a corresponding device in hardware and optionally with software, firmware, and a combination thereof can be referred to as "circuitry configured to," "logic configured to," etc. perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. on digital and/or analog signals as described herein for the various embodiments.

Claim 1:
A method (<NUM>) implemented by a monitoring system comprising steps of:
monitoring (<NUM>) Session Initiation Protocol, SIP, registration messages;
determining (<NUM>) and storing in a log Internet Protocol, IP, addresses of Proxy-Call Session Control Functions, P-CSCFs, based on the monitoring of the SIP registration messages, wherein P-CSCF addresses are determined from any SIP registration messages having cipher or encryption keys therein;
monitoring (<NUM>) SIP INVITE messages; and
for a specific call associated with a SIP INVITE message, determining (<NUM>) a direction of the specific call based on a comparison of source and destination IP address in the SIP INVITE messages with the stored IP addresses of the P-CSCFs in the log, the comparison determining whether the destination IP address and/or IP source address match one of the stored addresses of the P-CSCFs,
wherein when the destination address matches one of the stored addresses, the specific call is a terminating call, and
wherein when the source address matches one of the stored addresses, the specific call is an originating call.