GigaSMART SIP/RTP Correlation
Required Licenses: SIP/RTP Correlation (and FlowVUE for session-aware load balancing for RTP)
Session Initiation Protocol (SIP) is the dominant method to initiate, maintain, modify,
and terminate voice calls in service provider and enterprise networks. Real-time
Transport Protocol (RTP) is used to manage the real-time transmission of voice
payload across the same networks. Visibility into a subscriber’s voice traffic requires
the ability to understand the subscriber attributes and stateful information contained
within SIP to correlate subscriber-specific RTP traffic so that monitoring tools can
achieve an accurate view of the subscriber’s traffic on the network.
The GigaSMART SIP/RTP correlation application correlates the subscriber-specific
attributes and the endpoint identifiers of the RTP streams where the session is carried,
as well as other SIP-related attributes that are exchanged as part of the control
sessions. Use SIP/RTP correlation to leverage a subscriber-aware monitoring policy on
Gigamon’s Visibility platform and to optimize current tool infrastructure investments by
providing only relevant data to tools while increasing visibility into subscriber traffic.
This helps improve QoE and performance. Carriers gain access to the subscriber’s
traffic by reliably correlating and passing all the identified subscriber’s control and data
sessions to the analytics/monitoring probes and/or billing subsystems for an accurate view of the subscriber’s sessions.
Figure 8 | SIP/RTP Correlation |
SIP is a signaling protocol for VoIP and VoLTE call initiation. It is implemented with RTP to control the payload. GigaSMART SIP/RTP correlation provides customers visibility into VoIP, VoLTE, SMSoLTE, and RCS traffic, and allows them to filter and forward traffic for a subscriber to the tools.
All SIP traffic is sent to all tool ports, as follows:
all SIP packets sent to all ports within a load balancing port group. |
all SIP packets sent to all ports within a GigaStream. |
all SIP packets sent to all tool ports belonging to maps. |
RTP traffic will be sampled and sent to the maps with the rules that match. RTP non-correlated traffic will be sent to the collector.
SIP/RTP correlation can be used for both enterprise and service providers, where ever
there is SIP/RTP traffic, such as in wire-line communications, wireless communications, and packet cable networks. This includes enterprise, IP Multimedia Subsystem (IMS), or fixed network implementations of SIP, as well as any media controlled by SIP, such as voice, text, or streaming media.
In addition, SIP/RTP correlation correlates SIP signaling and RTP payload for all
sessions selected by a SIP User Agent (UA), a caller ID in a forward list, with flow
sampling from 0 to 100%.
The CallerID is tied to the Call-ID and remains constant for the duration of the session:
CallerID (A) <-----(Call-ID)-----> CalleeID (B)
CallerID tracking is based on the initial caller (A) and does not change until the Call-ID changes. Even if the callee, (B), sends a new INVITE during the SIP session, if that INVITE uses the same Call-ID, then the CallerID information in the SIP session display will still identify the initial caller, (A); it will not switch to reflect that (B) is now the caller.
SIP/RTP correlation handles all SIP signaling and RTP/RTCP traffic, including RTCP control traffic, as well as that belonging to a call session.
The following is supported:
Non-tunneled SIP, RTP, and RTCP correlation (all IMS interfaces) |
Tunneled SIP, RTP, and RTCP correlation (SIP/RTP/RTCP in GTP-U, through the GTP tunnel) |
When a packet containing SIP, RTP, or RTCP traffic is received, the SIP/RTP correlation engine looks up the session in the session table for load balancing ports and sampling maps or whitelist map. All SIP/RTP traffic with port or load balancing port group is forwarded based on the session table. The correlation engine load balancing keeps track of both the SIP session and the associated multiple RTP channels.
Each session identifies both sides of media streams (RTP) associated with the session. The SIP session has an aging timer that is configurable.
When a session matches one of the configured flow sampling rules, it is either accepted for sampling or rejected. If it is accepted, all packets belonging to that session are sent to the tool port. Otherwise, all packets belonging to the session are dropped.
To configure SIP/RTP Load balancing, follow these steps:
1. | From the left navigation pane, go to System > GigaSMART >GigaSMART Group and then click New. |
2. | Specify an Alias in the Alias field. |
3. | Select Load Balance in TCP Application Parameters. |
4. | Specify the parameters. The following table explains the parameters for configuring the load balance: |
TCP Application Parameters | Options | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Application |
|
||||||||||||||||||||||||
Load Balance |
|
||||||||||||||||||||||||
TCP Control |
|
RTP traffic will be sampled and sent to the maps with the rules that match. RTP non-correlated traffic will be sent to the collector.
Only one SIP interface type is supported per engine, for example, S5. There is no mixing of interface types, such as S5 GTP-U with SGi.
The SIP whitelist contains caller IDs, callee ID, the range for caller IDs, the range for callee IDs and the IP address. Each forward list entry in a file is a SIP caller ID, callee ID, caller ID range, callee ID range or IP address. The forward list can contain all types of entries.
forward list entries can be alphabetic, IP address, and numeric. For each entry, specify up to 64 alphanumeric characters. Some special characters are also supported.
You can manually add one entry at a time to a whitelist file, or you can upload files in.txt format. You must provide the whitelist caller ID range in numeric. You can also provide multipile entries to the forward list by ID range configuration. Each whitelist file can have up to 20,000 entries. One or more whitelist files can be fetched from a local directory or remote URL using HTTP or SCP.
On GigaVUE‑HC2 nodes, the forward list database supports 500,000 entries. On GigaVUE‑HC3 nodes, the forward list database supports 1 million entries.
Multiple forward list databases can reside on a GigaVUE node, but only one forward list is applied to a GigaSMART group at a time.
Only one whitelist map is supported for a GigaSMART group. The GigaSMART operation does not have any rules for forward listing.
FlowVUE is used for session-aware (stateful) load balancing and forward listing with sampling. Only RTP traffic will be sampled. There is no sampling of SIP traffic.
Up to five flow sample maps per GigaSMART group are supported. Each flow sample map can have 20 rules. Use rules to filter on caller ID. The rules support both alphabetic and numeric characters, up to 64 characters. Some special characters are also supported, such as wildcard characters.
Sampling is based on caller ID only (the from field).
The number of supported SIP and RTP sessions are as follows:
GigaVUE‑HC3—1 million SIP sessions and 4 million concurrent RTP sessions |
GigaVUE‑HC2—500,000 SIP sessions and 2 million concurrent RTP sessions |
Each SIP session can handle two RTP streams in both directions (bidirectional).
The number of supported TCP sessions are as follows:
GigaVUE‑HC3—2 million sessions |
GigaVUE‑HC2—1 million sessions |
SIP is a text-based protocol, which is supported over UDP and TCP. The size of the
SIP message can vary greatly, so fragmentation and segmentation are common and are supported for tunneled SIP and non-tunneled SIP (IMS).
IPv4 and IPv6 are supported as follows:
UDP Fragmentation—in-order packets, out-of-order packets |
TCP Segmentation—in-order packets, out-of-order packets |
The following is not supported:
GTP tunneled packets where the inner IP is fragmented |
IMS packets where the outer IP is fragmented |
Figure 9 | SIP/RTP UDP/TCP Support |
SIP Common Presence and Instant Messaging (CPIM) content masking is supported, but only when the SIP transport is UDP.
The SIP method, MESSAGE, carried over UDP, might contain user-friendly, readable text messages. Use masking to replace these messages with x’s, so they cannot be read.
Note: SIP/RTP correlation cannot mask text messages with a content type other than message/CPIM”, such as plain text.
The following are behaviors for some particular SIP methods:
The SIP method, REGISTER, might not contain a user part. When there is no user part, it will be treated as a parse error. |
The SIP method, OPTIONS, (and response messages) might not contain a user part. When there is no user part, it will be treated as a parse error. |
Note: SIP TCP packets with parse errors are not sent to collector. SIP TCP packets will be sent to the tool and incremented as parse errors in the session table stats.
The forward list (all whitelist files) reside on the leader of the cluster. The member nodes receive a copy of the forward list from the leader. Updates to the forward list are synchronized from the leader to the non-leaders. If a member node leaves the cluster and rejoins, its forward list will be resynchronized.
Use the cluster leader preference command to specify the highest preference for the leader, the second highest preference for the standby node, and lower preferences for the normal nodes in the cluster.
If there are GigaVUE TA Series nodes in the cluster, they will not receive a copy of the forward list.
GigaSMART SIP Correlation engine correlates NAT/PAT enabled SIP/RTP packets. The correlation engine compares the top most "Via" address and the contact address of the device with the Layer 3 network address to find whether the device is configured with NAT.
To enable the NAT support, from the device view:
1. | From the left navigation pane, go to System > GigaSMART >GigaSMART Groups > SIP > SIP NAT. |
2. | Enable the SIP NAT check box. |
The following list is not currently supported by SIP/RTP correlation:
encryption |
filtering based on Codecs |
SRVCC |
roaming |
SIP-I/SIP-T (supports SIP/RTP correlation based on SDP processsing even jf SIP carries SIP-I/SIP-T messages) |
forwarding of emergency calls to specific tools |
engine grouping. Only one engine is used for SIP/RTP correlation. |
Note: SIP/RTP correlation and GTP correlation are not supported on the same GigaSMART engine port.
To display SIP report, do the following:
1. | From the left navigation pane, go to System > GigaSMART >GigaSMART Groups> Report. |
2. | Select Group Type: Flow SIP. |
3. | From the device view, select GigaSMART Group: gsg1 |
4. | Specify Caller ID Pattern. |
5. | Select Any. This return any pattern specified in the Caller ID Pattern field. |
Figure 10 | Generate SIP Report |
6. | Click the Generate button. The SIP Messages Report displays. |
Figure 11 | SIP Report Page |
Map Statistics displays the counts sessions that matched a particular map.
For SIP Flow Sample maps, the counters show how many sessions matched the Caller-ID rule and were either accepted or rejected based on the sampling percentage.
For SIP Whitelist maps, the counter shows how many total entries are in the Whitelist and how many sessions matched those entries. .
To display SIP Map Statistics, do the following:
On the left navigation pane, click on from Traffic select Maps> Statistics. The Statistics page displays a count of the rules that actually matched in a map. |
Figure 12 | SIP Map Statistics |
GigaSMART supports sampling/scaling based on fixed percentages, which remain in effect at all times, regardless of the tool port utilization. However, tool utilization may not be as efficient as not using fixed percentage for every use case. Staring with GigaSMART version 5.4 support for throttling sessions based on the traffic (pps) reaching a tool port is available. This feature helps avoid packets being drops during peak times by allowing users to adjust throttling start and stop levels.
The illustration below is a configuration and Intra Flow for Tool Port Throttling.
Each SIP session comes with RTP streams and each of the RTP stream uses a specific codec for information transfer. We can use this codec information to our advantage and do predictive analysis on how much pps would be generated for a given SIP session.
Based on the outcome of the pps for a given RTP stream codec, admission control module will check this value against the cumulative packet throughput on the destination tool-port to decide if the session will be Accepted or Rejected.
Example: Tool port 1/1/x1 is configured with a threshold of 3k pps.
Time |
Port |
Session |
Codec (pps) |
Cumulative pps |
Throttle pps |
Accepted |
t0 |
1/1/x1
|
0 |
0 |
3000 |
||
t1 |
1/1/x1
|
1 |
500 |
500 |
3000 |
Yes |
t2 |
1/1/x1
|
2 |
1500 |
2000 |
3000 |
Yes |
t3 |
1/1/x1
|
3 |
800 |
2800 |
3000 |
Yes |
t4 |
1/1/x1
|
4 |
500 |
3300 |
3000 |
No |
In software version 5.4 Tool port throttling applies only to SIP sessions for audio and only load balanced ports are supported in tool port throttling. Use case where there are tapping multiple interfaces using multiple engines, one SIP session can be throttled in one engine and not in another.