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 806: 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 whitelist, with flow
sampling from 0 to 100%.
CallerID Tracking
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.
Support for SIP, RTP, and RTCP
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) |
SIP/RTP Correlation Engine
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.
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.
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.
SIP Whitelist
The SIP whitelist contains caller IDs, the range for caller IDs and the IP address. Each whitelist entry in a file is a SIP caller ID or callee ID. The whitelist can contain both caller IDs (the from field) and callee IDs (the to field).
Whitelist 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 whitelist 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 and GigaVUE HD Series nodes, the whitelist database supports 500,000 entries. On GigaVUE-HC3 nodes, the whitelist database supports 1 million entries.
Multiple whitelist databases can reside on a GigaVUE node, but only one whitelist 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 whitelisting.
RTP Flow Sampling
FlowVUE is used for session-aware (stateful) load balancing and whitelisting 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).
Support for Sessions
The number of supported SIP and RTP sessions are as follows:
| • | GigaVUE-HC3—1 million SIP sessions and 4 million concurrent RTP sessions |
| • | GigaVUE-HD8, GigaVUE-HD4, and 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-HD8, GigaVUE-HD4, and GigaVUE-HC2—1 million sessions |
Support for IPv4 and IPv6
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 807: SIP/RTP UDP/TCP Support
Support for Content Masking
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.
Behaviors of Some SIP Methods
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.
SIP Whitelisting in a Cluster
The whitelist (all whitelist files) reside on the master node of the cluster. The non-master nodes receive a copy of the whitelist from the master. Updates to the whitelist are synchronized from the master to the non-master nodes. If a non-master node leaves the cluster and rejoins, its whitelist will be resynchronized.
Use the cluster master preference command to specify the highest preference for the master node, 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 whitelist.
Not Supported by SIP/RTP Correlation
The following list is not currently supported by SIP/RTP correlation:
| • | encryption |
| • | filtering based on Codecs |
| • | SRVCC |
| • | roaming |
| • | SIP-I/SIP-T |
| • | 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.
SIP/RTP Load Balancing Example
This is a load balancing configuration example of SIP/RTP.
Figure 808: SIP/RTP UDP/TCP Support
SIP/RTP Minimum Configuration Example
To access GigaSMART within GigaVUE-FM, access a device that has been added to GigaVUE-FM from the GigaVUE-FM interface. GigaSMART appears in the navigation pane of the device view on supported devices. Refer to Access GigaSMART from GigaVUE-FM for details.
Configure ports
To configure a GigaSMART group and associate it with a GigaSMART engine port do the following.
| 1. | From the device view, select GigaSMART > GigaSMART Groups. |
| 2. | Click New. |
| 3. | Type an alias in the Alias field and enter an engine port in the Port List field. |
Figure 809: GigaSMART Group Port Info
| 4. | Click Save. |
| 5. | Scroll drown the page to select SIP Port parameters. |
| 6. | Type parameters for SIP Port and RTP Port. |
| 7. | Enter parameters for SIP Session Timeout and the SIP TCP Idle Timeout. |
Figure 810: SIP Port parameters
| 8. | Click OK. |
Create Virtual Ports
To access GigaSMART within GigaVUE-FM, access a device that has been added to GigaVUE-FM from the GigaVUE-FM interface. GigaSMART appears in the navigation pane of the device view on supported devices. Refer to Access GigaSMART from GigaVUE-FM for details.
To create virtual ports, do the following:
| 1. | From the device view, select GigaSMART > Virtual Ports. |
| 2. | Click New. |
Figure 811: Virtual Ports
| 3. | Enter an alias in the Alias field to identify the virtual port. |
| 4. | In the GigaSMART Groups field, select the GigaSMART Group configured in Step 1: of Configure a GigaSMART Group. |
| 5. | Click Save. |
Configure the GigaSMART Operation
Define a GigaSMART operation to enable SIP Flow Sampling. If combining Flow Sampling with Load Balancing GSOPs, make sure that you select both operations when creating the GigaSMART Operation.
To access GigaSMART within GigaVUE-FM, access a device that has been added to GigaVUE-FM from the GigaVUE-FM interface. GigaSMART appears in the navigation pane of the device view on supported devices. Refer to Access GigaSMART from GigaVUE-FM for details.
To configure the GigaSMART Operation, do the following:
| 1. | From the device view, select GigaSMART > GigaSMART Operations (GSOP). |
| 2. | Click New. On the GigaSMART Operations page, do the following: |
Figure 812: GigaSMART Operations page
| 3. | In the Alias field, enter an alias to help identify this GSOP. |
| 4. | In the GigaSMART Groups field, select the GigaSMART group configured in Step 1: Configure a GigaSMART Group. |
| 5. | In the GigaSMART Operations (GSOP) field, select Flow Sampling for SIP. |
| 6. | Using the GSOP drop down list, select Load Balancing as the next GSOP operation. |
Figure 813: GigaSMART Operations - Load Balancing
Options:
- Stateful
- Stateless
- Enhanced
| 7. | Select Stateful. |
| 8. | For Type, select SIP as the stateful application within a group of GigaSMART operations. |
| 9. | Select Caller ID as the Load Balancing Method. |
| 10. | Click OK. |
Create a first level map.
| 1. | Select Maps > Maps > Maps. |
| 2. | Click New. |
| 3. | Type map-level1 in the Alias field. |
| 4. | Select First Level for Type and By Rule for Subtype. |
| 5. | Select port 1/1/x1 for the Source. |
Figure 814: Create New Map
| 6. | Select virtual port vport1 for the Destination. |
| 7. | Click Add a Rule to add Rule 1 |
| 8. | Click Save. |
Create a second level map for SIP Flow Sampling.
| 1. | Select Maps > Maps > Maps. |
| 2. | Click New. |
| 3. | Type an alias in the Alias field. |
| 4. | Select Second Level for Type and Flow Sample SIP for Subtype. |
| 5. | Select virtual port vport1 for the Source. |
| 6. | Select port group for the Destination. |
| 7. | Select the group from the GSOP list. |
| 8. | Click Add a Rule. |
| 9. | Select SIP for the condition. |
Figure 815: Create Second Level Map
| 10. | Enter 408* for Caller ID. |
| 11. | Enter a percentage for amount the traffic you want to be affected by SIP flow sampling. |
| 12. | Click Add a Rule. |
| 13. | Select SIP for the condition |
| 14. | Enter 6501234* for Caller ID. |
| 15. | Enter a percentage for amount the traffic you want to be affected by SIP flow sampling. |
| 16. | Click Save. |
Create the SIP whitelist
| 1. | From the device view, select GigaSMART > Whitelist. |
| 2. | Click New. |
| 3. | Type an alias in the Alias field. |
| 4. | From the GigaSMART Groups drop-down list, select a .the GigaSMART group. |
| 5. | Load whitelist files from a specified location to populate the SIP whitelist. |
| a. | On the SIP Whitelist page, select Bulk Upload. |
| b. | Select Bulk Entry Operation for Upload Type |
| c. | Select Upload from URL from the Bulk Upload Type list. |
| d. | Enter the URL in the Enter Remote URL field. |
| 6. | Click Save. |
Associate the GigaSMART group to the SIP whitelist.
| 1. | From the device view, select GigaSMART > GigaSMART Groups > GigaSMART Groups. |
| 2. | Select the GigaSMART Group you previously created and click Edit. |
| 3. | From the GigaSMART Groups drop-down list, select a GigaSMART group previously created. |
| 4. | Under SIP Whitelist, click on the SIP Whitelist Alias field and select the alias previously created from the available list. |
| 5. | Click Save. |
Configure the GigaSMART operation for SIP whitelisting
| 1. | From the device view, select GigaSMART > GigaSMART Operations > GigaSMART Operation. |
| 2. | Click New. |
| 3. | Type an alias in the Alias field. |
| 4. | Select the GigaSMART group created in task 1. |
| 5. | From the GigaSMART Operations (GSOP) drop-down list, select the following: |
| • | SIP Whitelist and select Enabled. |
| • | Load Balancing. |
| 6. | For Load Balancing, do the following: |
| a. | Choose: Stateful |
| b. | For Type select: SIP |
7. Click Save.
Configure first level map
| 1. | Select Maps > Maps > Maps. |
| 2. | Click New. |
| 3. | Configure the map: |
| a. | Enter an Alias |
| b. | Type: First Level, Sub Type: By Rule |
| c. | Source: 1/1/g2 |
| d. | Destination: vport |
| 4. | Click Add a Rule. |
| 5. | Click Save. |
Create another second level map for SIP flow whitelist
| 1. | Select Maps > Maps > Maps. |
| 2. | Click New. |
| 3. | Configure the map: |
| a. | Alias: alias name |
| b. | Type: Second Level, Sub Type: Flow Whitelist |
| c. | Source: vport1 |
| d. | Destination: 1/2x23 |
| e. | Select from the GSOP list. |
| 4. | Click Save. |
Displaying SIP/RTP Reports
To display SIP report, do the following:
| 1. | From the device view, select 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 816: Generate SIP Report
| 6. | Click the Generate button. The SIP Messages Report displays. |
Figure 817: SIP Report Page
Displaying SIP Map Statistics
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:
| • | Select Maps> Statistics. The Statistics page displays a count of the rules that actually matched in a map. |
Figure 818: SIP Map Statistics
SIP/RTP Support for Tool Throttling
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.
Admission Control:
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 |
|
0 |
0 |
3000 |
||
|
t1 |
|
1 |
500 |
500 |
3000 |
Yes |
|
t2 |
|
2 |
1500 |
2000 |
3000 |
Yes |
|
t3 |
|
3 |
800 |
2800 |
3000 |
Yes |
|
t4 |
|
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.
MORE INFORMATION 
