Page History

Overview

Lawful Interception (LI) is a means of conducting lawfully authorized electronic surveillance of communication against warranted users or subscribers. The SBC Core supports several types of LI processing including one based on the PacketCable 2.0 (PC 2.0) standards. The Ribbon PC 2.0 LI solution provides interfaces and capabilities similar to those provided by the (former GENBAND) Q-series SBC.

Current LI standards such as PacketCable 2.0, require interception of all SIP messages originating from, terminating to, or redirected by a monitored party for a media session or event. The SIP message contents are then encapsulated and sent to a Delivery Function (DF). The DF formats the SIP messages and delivers them to a Law Enforcement Agency (LEA) as call data records. Some electronic surveillance warrants also call for interception of call content. The SBC's PC 2.0 LI supports interception of audio (voice) and DTMF.

You can configure PC 2.0 LI requires both an using either

• Insight EMS + external PSX, or
• SBC (using EMA + ERE).

and an external PSX within the network. EMA/ERE-based configurations are not supported. The EMS is the initial recipient of surveillance provisioning information from authorized LI users. The EMS sends the surveillance information to the PSX to be added to its target database. When the SBC receives an INVITE request or other SIP message for which it makes a policy query to the PSX, the PSX checks for a match in its LI target database. In the event of a match, the PSX indicates in its policy response that the call must be intercepted. The following diagram shows the basic network components and connections, with the SBC running on an SBC 7000 server in this example.

Figure

1

: PC 2.0 LI Network Diagram

Image Removed

Image Added

The PC 2.0 LI solution uses three LI interfaces for interworking between the SBC (acting as an Intercept Access Point) and a third-party DF.
These interfaces, designated as X1, X2, and X3, provide the following functions:

• X1 – A SOAP/XML-based interface for provisioning surveillances between the DF Administrative Function (ADMF) and the Insight EMS. The X1 interface is a Ribbon-specified, open and generic LI-provisioning interface which can be implemented by any third-party DF vendor. Contact your Ribbon representative for specific information on the X1 interface specification for PC 2.0 LI. Refer to Provisioning LI Targets (EMS Documentation) for more information on procedures for sending surveillance information to the Insight EMS.
• X2 – A Diameter-based interface over TCP transport for sending intercepted call data and associated call events from the SBC to the DF. The X2 channel can optionally be configured for IPsec. If the connection to the target DF server is down, the SBC buffers the X2 Diameter messages until the connection is restored.

The PacketCable 2.0 standard defines the X2 interface as an extension of the Diameter base protocol (RFC 6733) incorporating event-based Diameter Accounting messages. The X2 interface transmits the following Diameter messages:

• • Accounting-Request (ACR) - This message is used by the SBC to send surveillance call data to the DF. See Intercept Event Message (IEM) Types for more information on the contents of the ACR messages the SBC sends. 
  • Accounting-Answer (ACA) - This message is sent by the DF to the SBC to acknowledge an Accounting-Request message.

• X3 – A UDP interface for sending intercepted call content from the SBC to the DF. Media interception is optional and is initiated when called for in the surveillance record. The X3 channel can optionally be configured for IPsec.

You can configure up to 16 DF servers for receiving X2 and X3 data. Based on the target configuration, the SBC chooses a realm route to which it sends interception data. If you configure more than one DF with the same realm route, the SBC distributes the traffic among them when it selects the shared realm route as the target for interception data. Note that within configuration, DFs correlate to "mediation server" objects. For each target mediation server you must configure a corresponding Diameter peer and Diameter realm route to specify the Diameter interface between the SBC and the mediation server (DF).

Anchor
IEM IEM

Intercept Event Message (IEM) Types

To meet the required LI standards, the DF must be given sufficient information in the SIP messages to be able to report all required information in the required format to the LEA. The SBC  delivers call data event messages to the DF for any SIP message sent to or received from a target. This includes call-related SIP messages, registrations, and notifications. The contents of the ACR messages sent to the DF is defined in the PC 2.0 standard and includes two PacketCable 2.0 IEMs: "Report Messages" and "Correlate Messages," and a Ribbon-defined "Content-Available" IEM message. All data transported in the ACR message is in the form of attribute-value pairs (AVPs).

Report Message

A Report IEM contains an encapsulated SIP message with any additional information as required by PacketCable, for example: direction, element-type, and so on. The SIP messages are copies of the requests/responses as they are received from the target and sent to the target.

Correlate Message

The Correlate IEM helps provide additional correlation information to the DF when, for example:

• An initial INVITE SIP message is reported.
• There are multiple targets along a signaling path, that is, where one set of event messages is associated with multiple targets.

Content-Available Message

The Content-Available message is a Ribbon-defined message used to notify the DF that call content for an intercepted call will be sent over the X3 interface. This message is sent per media stream to the DF. The Content-Available message includes the Call Content Connection Identifier (CCCID), which can be used by the DF to correlate call content it receives over X3 with the corresponding call data sent over X2, for a given call surveillance.

This message also contains the transport addresses for the call content to be sent between the SBC and DF.  This information can also be used by the DF for correlating X3 call content with the correct X2 call data (for example, if by chance the same CCCID was chosen by multiple Ribbon IAPs (SBCs) during the interception of same or different targets). The Content-Available message is sent to the DF once the SDP offer and answer are exchanged; typically once a 200 OK SIP message is received.