Cisco Unified Border Element (SP Edition) Configuration Guide: Unified Model

CALEA IRI Interface Support Flow

Figure 58-1 shows the flow of the CALEA IRI Interface Support feature.

Figure 58-1 Flow of the CALEA IRI Interface Support Feature

The steps pertaining to the flow of the CALEA IRI Interface Support feature are as follows:

1. Provisioning of mediation device information and VoIP warrant is done as a combination of SNMPv3 and IOS CLI commands on the Cisco ASR 1000 series router.

2. The calling party originates the call.

3. If a warrant matches the signaling parameters, RADIUS messages are sent to the mediation device. The message contains the unique CCCID generated by the Cisco ASR 1000 series router.

4. The party that was called answers, and the media information starts flowing through the Cisco ASR 1000 series router.

5. The Cisco ASR 1000 series router replicates the media information, and sends it to the mediation device.

SNMP Row Indices

Figure 58-2 represents the SNMP table and rows. There are two independent mediation device rows. The GenericStream and VoIP TAP MIB rows are the children of the IRI MD row. There is a CCIndex field in the VoIP TAP MIB row that captures the relationship with CC MD MIB row. A one-to-one relationship also exists between GenericStream and VoIP TAP MIB rows.

Figure 58-2 SNMP Row Indices

Tap Interfaces

This section describes the following Tap interfaces:

• IRI Interface
• CC Interface

IRI Interface

The PacketCable 1.5 standard specifications for Electronic Surveillance contains the packet definition for all IRI-related messages. Table 58-1 details the supported call event messages that are sent for each Tapped Call.

Call Event Messages

Table 58-2 details the Signaling_Start message attributes that are supported and sent when the SBC has information that the destination is routable and the originating endpoint is allowed to make the call.

The following Signaling_Start message attributes are not included in the message:

• Attribute Name
• Location_Routing_Number
• Intl_Code
• Dial_Around_Code
• Jurisdiction_Information_Parameter
• Ported_In_Calling_Number
• Ported_In_Called_Number
• Called_Party_NP_source
• Calling_Party_NP_source
• Billing_Type
• Electronic_Surveillance_Indication

Table 58-3 details the QoS_Reserve message attributes. This message is generated when the SBC has reserved bandwidth (QoS) on the network. If the reserved bandwidth changes, QoS_Reserve and QoS_Commit messages are generated anew.

Table 58-4 details the Call_Answer message attributes. This message indicates the earliest point at which two-way media is established. The SBC sends the message to the billing servers when the SBC is notified that the called party has answered the call.

Note The FEID attribute is not sent in a Call_Answer message.

Table 58-5 details the QoS_Commit message attributes. This message is sent by the SBC when the gate bandwidth is committed. This message is sent after a QoS_Reserve message that has been sent previously.

The following attributes are not included in the QoS_Commit message:

• QoS_Descriptor
• Media_Session_Desc (attribute ID 254)

Table 58-6 details the Call_Disconnect message attributes. This message is generated by the SBC when a two-way media flow is terminated. This message immediately precedes the QoS_Release and Signaling_Stop messages, and is sent only after the Call_Answer message that has been sent previously.

Table 58-7 details the QoS_Release message attributes. This message is generated by the SBC when the reserved bandwidth is released.

Note The Media_Session_Desc (attribute ID 254) attribute is not sent with the QoS_Release message.

Table 58-8 details the Signaling_Stop message attributes. This message is sent during the following events:

• A terminating signalling request, for example, a SIP BYE, from the party terminating the call is acknowledged by the SBC.
• When the terminating signalling request for the party not terminating the call is sent by the SBC, and acknowledged by that party.

Note The Signaling_Stop message is not sent if the Signaling_Start message for this call is not sent.

Note The FEID attribute of the Signaling_Stop message is not included.

Table 58-9 details the Surveillance_Stop message attributes. This message is sent by SIG to indicate the end of IRI or CC tapping or both. This message means the call has ended.

Note The Electronic_Surveillance_Indication attribute is not included in the Surveillance_Stop message.

Table 58-10 details the Media_Report message attributes. The message is specific to a flow. Therefore, if more than one flow is created at the same time, multiple event messages are sent, one per flow.

A Media_Report message is sent during the following events, when a flow is created, modified, and released:

• A flow is considered Created when the gate bandwidth for the flow is committed. A QoS_Commit message is also sent at the same time.
• A flow is considered Modified when the flow is renegotiated.
• A flow is considered Released when the gate bandwidth for the flow is released. A Qos_Release message is also sent at the same time.

Table 58-11 details the Redirection message attributes. This message is sent by the SBC when a call has been transferred either due to a 3XX redirect response or a SIP REFER request.

CC Interface

The PacketCable 1.5 standard specifications contain the packet header format for replicated voice content packets.

Figure 58-3 shows a replicated packet. The first three rows of the packet are the outer Layer2, Layer3, and Layer4 information. This information consists of destination IP and UDP port of the Mediation Device, and the source IP and UDP port of the Cisco ASR 1000 series router. The fourth row of the packet is the CCC ID that is used to correlate the signaling and media information. The last four rows of the packet are the original media packet that is being TAPed. It starts from Layer 3 IP, and is followed by UDP, RTP, and media payload.

Figure 58-3 Packet Format

Configuring LI

To see the SNMPv3 and SNMP View configuration information pertaining to the LI TAP definitions, see the How to Configure Lawful Intercept section in the Cisco IOS and NX-OS Software Lawful Intercept Architecture feature guide at:

http://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/sec_lawful_intercept.html#wp1077988

Use the following commands provided in the Cisco IOS and NX-OS Software Lawful Intercept Architecture feature guide to configure LI:

• snmp-server view view-name MIB-name included —Defines an SNMPv2 MIB view, and includes a MIB family in the view.
• snmp-server group group-name v3 auth read view-name write view-name —Defines a read and write view for a group using the User Security Model (SNMPv3) and the authNoPriv Security Level.
• snmp-server user user-name group-name v3 auth md5 auth-password —Defines an authentication password for a user by using the HMAC MD5 algorithm for authentication and V3 security model.

The following example shows how to enable the mediation device to access the lawful intercept MIBs. It creates an SNMP view (tapV) that includes three LI MIBs (CISCO-VoIp-Tap-MIB, CISCO-TAP2-MIB, and CISCO-IP-TAP-MIB). It also creates a user group that has read, write, and notify access to MIBs in the tapV view.

Configuring VoIP LI SNMP

SNMP provisioning is done using the SNMP research tools available for Sun workstations. However, you can use any tool that uses the SNMPv3 protocol.

The setany commands listed here are executed using the SNMP application. Note that these commands are not Cisco IOS CLI commands. It is assumed that SNMP has been configured on your routing device. A secure K9 image is required for the MIBs to work.

There are four parts to the following example:

• Adding the Mediation Device Information
• Adding the VoIP User Warrant
• Retrieving the Mediation Device and VoIP User Warrant Information
• Removing the VoIP User Warrant and Mediation Device Information

Adding the Mediation Device Information

Perform the following steps to add the mediation device information:

Step 1 Configure the mediation device IP, RADIUS receiving port, transport type, and shared RADIUS Key to receive Voice signaling information from the SBC through the PacketCable1.5 Event Messages.

The following example shows how to create the TAP2 MD Row for IRI, with an IP address of 101.10.7.61, UDP port of 1813, and RADIUS key of "cisco":

Step 2 Configure the mediation device IP, Call Content (CC) receiving port, and transport type to receive Voice CC from the SBC.

The following example shows how to create the TAP2 Mediation Device Row for a CC, with an IP address of 101.10.7.61, and UDP port of 45000:

Adding the VoIP User Warrant

Perform the following steps to add the VoIP user warrant:

Step 1 Configure the VoIP user warrant.

The following example shows how to create the VoIP TAP SNMP Row with a matching username for "712020" and type "Intercept":

Step 2 The following example shows how to configure an associated generic stream for VoIP, and enable generic stream:

Retrieving the Mediation Device and VoIP User Warrant Information

Perform the following steps to retrieve the mediation device and VoIP user warrant information:

Step 1 The following example shows how to retrieve the MD TAP2 SNMP row:

Step 2 The following example shows how to retrieve the VoIP TAP SNMP row:

Removing the VoIP User Warrant and Mediation Device Information

Perform the following steps to remove the VoIP user warrant and mediation device information:

Step 1 Disable and delete the generic stream, and delete the VoIP User TAP row:

Step 2 Remove the mediation device RADIUS receiving port:

Step 3 Remove the MD CC receiving Port:

Configuring the SBC for CALEA IRI Interface Support

This section details the steps involved in overriding the default match-order.

SUMMARY STEPS

1. configure terminal

2. sbc sbc-name

3. sbe

4. adjacency sip | h323 adjacency-name

5. warrant match-order [ source | destination | diverted-by ]

6. exit

DETAILED STEPS

The following example shows how to configure the SBC to override the default match-order: