Add_workflow_for_techpubs | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Panel | ||||
---|---|---|---|---|
In this section:
|
Info | ||
---|---|---|
| ||
Related articles: |
The CALEA network solution design requires the CALEA Intercept Access Point (IAP) vendors to implement support for multiple (two instances) regionally deployed SS8 Delivery Function systems.
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Lawful Interception solution has three interfaces between the network element and mediation server. These are used to provide provisioning, call data (signaling), and call content (media) information. These interfaces are created after the connection is established between the mediation server (DF – delivery function) and the network element (AF – access function). The interface from the mediation server to the lawful interception agency is standardized. The interfaces between AF and DF are defined as:
Where, X interface is specified by 3GPP standard while INI is specified by ETSi standard.
P-Com.Session-Info (PCSI) LI solution requires Sonus network elements (EMS, PSX and
Spacevars | ||
---|---|---|
|
Supported Lawful Interception (LI) elements (
, PSX and EMS) with SS8 as the mediation server are required to supported X1 and X3 interface only. X2 interface is not implemented by the Spacevars 0 product
. Spacevars 0 product
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
The
finds the LI information in the policy response and understands that the call has to be intercepted. It uses the correlation ID received in SIP messages as well as X3 transport address received from the PSX to fork the media stream to the appropriate mediation server using the X3 interface. This interface forks the media stream over TCP that is established over a secured IPsec tunnel. Spacevars 0 product
Caption | ||||
---|---|---|---|---|
| ||||
enabled
.The SS8 mediation server is represented as DF (Delivery Function). The EMS and PSX together are represented as AF (Access Function).The LI database operations are performed on the PSX and X1 provisioning interface is implemented on the EMS. For any X1 operation which has impact on PSX LI database operation, EMS uses PIPE interface with the PSX.
This transport connection is with or without TLS depending upon the configuration. The EMS sends the Authentication Request
towards DF with the following IEs when the transport connection is successfully established:
Access Function Identifier
set to zero in Authentication Request
.The EMS accepts Global Info Set Request
coming from DF with the following IE:
It checks that the Access Function Identifier
IE of Generic Message Header
in Global Info Set Request
has non zero value. If Access Function Identifier
is a non-zero value, EMS stores this value and uses it in subsequent EMS generated messages. EMS sends the Transaction Identifier
that it receives in the Global Info Set Request
message. It also accepts the Service Provider Identity
.
Link Options IE is enumerated type with following sub fields, which EMS saves and uses during session maintenance and release procedures:
The EMS checks that data type for all these sub fields is integer and stores their respective values. Timestamp data type for this IE is in time format. If AF (PSX) Provisioning State database is empty, it accepts the zero value of this IE. Any IE received with incorrect data type is rejected with message Operation Result
with IEs.
If Access Function Identifier
is set to zero then the EMS rejects using Operation Result
message with following IEs.
IE | Value |
---|---|
Operation Error Message | ASCII string (optional) |
Operation Result Code | 0x01 - Unknown error |
Request Code | 0x48 - Global info set request |
The EMS supports session maintenance, session release, and database clean up procedures using the timers mentioned below:
For configuring the EMS for this feature, refer Managing Mediation Servers.
The EMS configures the PSX LI DB over PIPE interface. It creates entry for Target Service List
and other parameters. LI DB performs validation of data type for each parameter.
The PSX queries the LI DB based on key Target Service List
received in Warrant Info Get Request
and returns all parameters. If Target Service List
is missing in Warrant Info Get Request
, the query is based on key DF1 ID next Target Service List
in LI DB.
PSX accepts the target URI copied from P-Com.Session-Info, in POL-REQ messages. If POL-REQ is carrying the target URI, PSX performs the LI DB lookup based on exact match of URI and does not check any other AVPs in POL-REQ. If the LI table lookup for the target URI is successful and A
dministrative
status is enabled, PSX provides LI information in POL-RES message to the
Spacevars | ||
---|---|---|
|
The PSX provides the following LI information in POL-RES:
The
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Where P-Com.Session-Info format is:
Code Block | ||
---|---|---|
| ||
P-Com.Session-info = "P-Com.Session-Info" HCOLON= corrID *( SEMI involved-party ) corrID = "corrID" EQUAL word [ "@" word ] involved-party = LAQUOT involved-uri RAQUOT involved-uri = SIP-URI / TEL-URI / SIPS-URI |
SIP-URI / TEL-URI / SIPS-URI is specified and can be in a different format as mentioned in the following table:
ID Type | Subject ID format | Matches |
---|---|---|
U@H | user@hostname | sip:user@hostname sips:user@hostname |
U@I | user@ip_address | sip:user@IP Address sips:user@IP Address Both IPv4 and IPv6 are supported. |
P@H | phone_number@hostname | sip:phone number@hostname sips:phone number@hostname |
P@I | phone_number@ip_address | sip:phone number@IP Address sips:phone number@IP Address |
TEL | phone_number | tel:phone_number |
The
sends URI received in P-Com.Session-Info to the PSX in a POL-REQ message. This header is received in any of the SIP message (Invite/re-INVITE . 200 OK, 18X) from IMS network. Presence of P-Com.Session-Info in SIP response messages like 18x/200OK or in SIP RE_INVITE request triggers a light weight policy dip. The Spacevars 0 product
truncates the Correlation ID (corrID), copied from P-Com.Session-Info, to 16 byte ASCII character (if it is more than 16 byte). If the correlation ID size is less than 16 bytes, the corrID is added with zero. The Spacevars 0 product
replies with 4xx response when Correlation ID (corrID) validations fails. Spacevars 0 product
The
accepts the LI information from the PSX in POL-RES message. The absence of LI information in POL-RES from the PSX to the Spacevars 0 product
means interception is disabled for target URI. The connection towards X3 connection is created when the mediation server state is enabled from the CLI. The checks listed here are to trigger interception of media. Apart from the checks listed here, the IP Address of the mediation server returned in POL-RSP is matched with the address of the mediation server address configured in the CDC configurations. Also, the matched mediation server is ensured to be admin enabled before an interception is triggered. Spacevars 0 product
Note |
---|
IP-Sec is an optional configuration over X3. |
The Mediation Server creates a connection with IPsec over TCP connection towards IP and Port received in LI information of POL-RES and meets the following IPsec requirements:
The Mediation Server IP, port and pre-shared keys for X3 connection are already configured on the
. The Spacevars 0 product
verifies that the configured X3 connection details (IP, type and port) are same under CDC as received in LI information of POL-RES message. Spacevars 0 product
If there is a change in mediation server through X1 interface for a target URI between Invite and Re-INVITE message, the
forks media streams over X3 connection for new mediation server. Spacevars 0 product