Browse Prior Art Database

VoIP/VoLTE: Indirect correlating of SIP and RTP while tapping on 3g and 4g networks Disclosure Number: IPCOM000246252D
Publication Date: 2016-May-19
Document File: 3 page(s) / 74K

Publishing Venue

The Prior Art Database


Probing solution are usually deployed between SGW/PGW (SGSN/GGSN), thus not getting the dedicated VoLTE traffic, but all data generated by customer devices. The main requirement, put by customer, is to account for all transaction made by user device and product KPIs, which can help to outline customer experience, operator core network performance, as well as provide the necessary information to apply various analytics for operator. In particular for VoLTE probing module, probe need to be able to correlate every single RTP packet to its SIP initiator in order to calculate KPIs for the voice call. The main KPIs definitions are coming from customer requirements on getting visibility on over voice call, starting from how call started, how long it went and what was a quality and how finished. The main difficulties with probing solution are the following: - identify the protocols with in data flow - parse the protocol in fast and effective way - correlate all corresponding flows belongs to the - Particular user endpoint, - Particular application on user device - Particular transaction for the application - Particular data flow (UDP/TCP/SCTP) - Provide the solution for data feeds exceeding the 10GBits/sec This article will outline the specific technique used to solve the correlation for VoLTE traffic, presented by SIP/RTP, but it is extendable to any other methods how voice call can be initiated (HTTP. RTSP etc).

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 54% of the total text.

Page 01 of 3

VoIP/VoLTE: Indirect correlating of SIP and RTP while tapping on 3g and 4g networks

Problem definition

   SIP and RTP protocols are used together to deliver audio and voice data over an IP network. It is called VoIP (Voice over IP) or VoLTE (Voice over LTE). SIP acts as signalling protocol and responsible for establishing a call while RTP acts as transport protocol for voice data. Usual SIP/RTP call flow looks like this:

In order to correlate RTP flow with particular SIP/INVITE transaction we need to parse the SDP information from INVITE packet and response packet with 200 OK. Both those packets contain the necessary information for endpoints (A and B, see picture above), such as A and B endpoints, i.e. IP address and UDP port number.

    Once the endpoint information is available - it became easy to associate RTP flow to particular SIP transaction, comparing destination and source IP Addresses and port.

    Without such information it is not possible to reliable recognise UDP stream as RTP flow and associate it to particular call made by User Endpoint (UE further in document). In other words, endpoint information allows to properly classify UDP traffic as RTP, and when calculate necessary KPIs for VoIP calls, such as jitter and MOS score.

Direct correlation method. Requires both parties' endpoint information's.

Page 02 of 3

    However the scenario described above is an ideal case. There are also cases as it is bellow, where voice path has started before 200 OK has been received. In this case part of the RTP traffic cannot be associated with the SIP using method described above.

    There is not always possible to reliable intercept both packets. It is also a performance penalty to store the packets in memory and perform search to correlation SIP transactions to establish RTP Flow. Currently, the data handling requirements are way over 10GBs per single hardware box and with current number of simultaneous user endpoints (over 10M) and wide spread of VoLTE applications it cause a performance impact, which makes VoLTE handling impact with generic

data prohibitive.

The Solution

   The provided solution to correlation problems listed above and in particularly for correlation of every single RTP packet to its SIP initiator without waiting for complete SIP transaction.

    That allows to optimise the overall solution and perform correlation just using first SIP packet and first RTP of transaction.

The method used, we call "indirect correlation method"

There are two stages of correlation in this method.

First step:
Probe is correlating the first SIP packet to particular UE handle (...