cisco - cryptome

Download this

chapter

Download the

complete book

Network and Subscriber Feature Descriptions

Chapter 2 - Lawful Intercept and CALEA

Table Of Contents

Lawful Intercept and Enhanced CALEA

FeaturesGeneral Description of Lawful InterceptImplementation

Lawful Intercept ProvisioningInterfaceLawful Intercept Call DataInterfaceLawful Intercept Call ContentFunction

Enhanced CALEA FeaturesCALEA Enhancement OverviewGeneric CALEA EnhancementsSurveillance for Calls InvolvingMultiple CMSsBTS 10200 CALEA Interaction withSIP EndpointsChanges to Interface between the BTS 10200 andDelivery Function ServerBTS 10200 CALEA Interaction with SIP Triggers FeatureCALEA Backward Compatibility

CALEA Operation Similar to BTS Release 4.5CALEA Operation Similar to BTS Release 4.5 withSIGNAL INSTANCE MessageCALEA Operation According to PacketCable 1.5Specification

Compliance with CALEA Requirements in PKT-SP-EM1.5-I01-050128 Appendix ACompliance with CALEA Requirements in PKT-SP-CMSS1.5-I01-050128 Section 7.7.2

Lawful Intercept and Enhanced CALEA Features

Revised: July 2, 2009, OL-12606-20

This chapter describes the lawful intercept interface supportedby the Cisco BTS 10200 Softswitch, along with enhanced CALEAfeatures that were introduced with Release 5.0.

General Description of Lawful Intercept Implementation

The Cisco BTS 10200 Softswitch supports the call data interfaceand call content function for lawful intercept, along with theprovisioning interface required to configure a wiretap. TheBTS 10200 provides support for lawful intercept using twodifferent, industry-developed architectures: PacketCable and theCisco Service Independent Intercept (SII). Depending on theirnetwork type, service providers may choose to configure theirnetworks consistent with either of these architectures in theireffort to meet their obligations related to lawful intercept. Giventhe constantly evolving nature of industry-developed standards,service providers must recognize that the features and

Network and SubscriberFeature Descriptions

Preface

Chapter 1 - NetworkFeatures

Chapter 2 - LawfulIntercept and CALEA

Chapter 3 - SubscriberFeatures

Chapter 4 - COS andOCB Features

Chapter 5 - FeatureInteractions

Chapter 6 - IVRFeatures

Chapter 2 - LawfulIntercept andCALEA

Network andSubscriber FeatureDescriptions - BookLength PDF(PDF - 4 MB)

Network and Subscriber Feature Descriptions - Chapter 2 - Lawful ... http://www.cisco.com/en/US/docs/voice_ip_comm/bts/5.0/feature/...

1 of 26 3/26/2010 3:00 PM

functionality of the BTS 10200 described below may also besubject to change over time.

Each country controls its own laws applicable to lawful intercept.For example, in the United States, one of the applicable laws isreferred to as the Communications Assistance for LawEnforcement Act (CALEA).

Lawful Intercept Provisioning Interface

The BTS 10200 supports a secure provisioning interface toprocess wiretap requests from law enforcement agenciesthrough a mediation device. The service provider can limitviewing and provisioning of these parameters to selectedauthorized personnel. The applicable parameters (entered viaCLI) include the DN, tap type, and call data channel for datatransmission. The tap type specifies whether the tap order is apen register (outgoing call information), a trap and trace(incoming call information), a pen and trace (incoming andoutgoing call information), or an intercept (bidirectional plus thecall content).

Note To provision this feature, see the CALEA provisioning

procedure in the Cisco BTS 10200 Softswitch Provisioning

Guide.

Lawful Intercept Call Data Interface

The BTS 10200 provides the PacketCable EMS/RADIUS interfacefor the transmission of call identifying information to the lawfulintercept delivery function (DF) server as required by Appendix A,

PCES Support, in PKT-SP-EM1.5-I02-050812, PacketCable

Event Messages Specification (EMS), August 12, 2005.

Full call-identifying information (call data) is shipped to a DFserver from the BTS 10200 for the subject under surveillance forvarious call types (for example, basic call and call forwarding).

Lawful Intercept Call Content Function

The call content function provides for capturing voice in areplicated Real-Time Transport Protocol (RTP) stream. TheBTS 10200 can be configured to operate with simultaneoussupport for PacketCable intercept and Cisco SII, or with Cisco SIIonly.

Simultaneous support for PacketCable intercept and Cisco SII isachieved as follows: During the call-setup phase, the BTS 10200searches for a PacketCable-compliant call-content interceptaccess point (IAP) in the call path. If the BTS 10200 determinesthat there is no such IAP available in the call path, it falls back toCisco SII.

Note An intercept access point (IAP) is a point within acommunication system where some of the communications orcall identifying information of an intercept subject's equipment,facilities, and services are accessed.

Additional information about each type of intercept is providedbelow:

• PacketCable intercept—In PacketCable intercept, a replicated


2 of 26 3/26/2010 3:00 PM

RTP stream is sent to the DF server by an aggregation routeror a trunking gateway upon request from the BTS 10200. TheBTS 10200 requests the relevant IAP (aggregation router ortrunking gateway) to duplicate and transport the RTP streamto a predefined IP address and port number.

The BTS 10200 uses Common Open Policy Service (COPS)protocol when sending the above request to an aggregationrouter, and Media Gateway Control Protocol (MGCP) whensending the request to a trunking gateway.

• Cisco Service Independent Intercept—In Cisco SII, areplicated RTP stream is sent to the DF server by anaggregation router or a trunking gateway upon request fromthe DF server. The DF server uses SNMPv3 as the controlprotocol to send the intercept request to the appropriate IAP.

Enhanced CALEA Features

This document describes enhancements to the CommunicationsAssistance for Law Enforcement Act (CALEA) feature for theBTS 10200 Release 5.0 and contains the following sections:

• CALEA Enhancement Overview

• Generic CALEA Enhancements

• Surveillance for Calls Involving Multiple CMSs

• BTS 10200 CALEA Interaction with SIP Endpoints

• Changes to Interface between the BTS 10200 and DeliveryFunction Server

• BTS 10200 CALEA Interaction with SIP Triggers Feature

• CALEA Backward Compatibility

• Compliance with CALEA Requirements in PKT-SP-EM1.5-I01-050128 Appendix A

• Compliance with CALEA Requirements in PKT-SP-CMSS1.5-I01-050128 Section 7.7.2

CALEA Enhancement Overview

CALEA features were enhanced in Release 5.0 to comply withthe PacketCable specifications. In addition to generic CALEAenhancements as specified in PacketCable specifications, thissection includes clarifications for surveillance functionsperformed by the Cisco BTS 10200 when the subscriber undersurveillance is configured as a SIP endpoint and when the callunder surveillance involves multiple CMSs.

The CALEA feature enhancements comply with the followingPacketCable specifications:

• PacketCable 1.5 Event Message Specification, PKT-SP-EM1.5-I01-050128, January 28, 2005, Cable TelevisionLaboratories, Inc. (Appendix A: EM CALEA RequirementCompliance)

• PacketCable 1.5 Call Management Server Specification,PKT-SP-CMSS1.5- I01-050128, January 28, 2005, CableTelevision Laboratories, Inc. (Section 7.2.2: CMSS CALEARequirement Compliance)

Generic CALEA Enhancements

When an origination or termination attempt is detected for a call


3 of 26 3/26/2010 3:00 PM

under surveillance, the BTS 10200 issues call-data eventmessages to the Delivery Function device to providecall-identifying information. The BTS 10200 follows theprocedural and encoding guidelines specified in PKT-SP-EM1.5-I01-050128 Appendix A for sending these event messages.Table 2-1 lists all the call-data event messages supported by theBTS 10200.


4 of 26 3/26/2010 3:00 PM

Table 2-1 CALEA Call-Data Event Messages

Supported by the BTS 10200

Message Description

SignalingStart

The BTS 10200 generates thismessage whenever an originationattempt or termination attempt isdetected for a call undersurveillance.

MediaReport

The BTS 10200 generates thismessage when SDP information fromboth sides of the call is available forthe call under surveillance.

Call Answer The BTS 10200 generates thismessage whenever a call undersurveillance moves to the answeredstate.

CallDisconnect

The BTS 10200 generates thismessage whenever a call undersurveillance moves to thedisconnected state.

SignalingStop

The BTS 10200 generates thismessage when a call undersurveillance has ended.

ServiceInstance

The BTS 10200 generates thismessage when a feature is invokedby the BTS 10200 for the subjectunder surveillance.

Note The BTS 10200 does not sendthis message if it is not awareof a service invocation (forexample, a Call Waiting at aSIP endpoint).

SignalInstance

The BTS 10200 generates thismessage whenever it receivesinformation from the subject orsends information to the subject.

Note The BTS 10200 cannot (and isnot required to) report somesignals if the tapped user has aSIP endpoint (refer to Table 2-3for detailed information) or forcases in which the BTS10200does not apply the signal itselfto NCS endpoints. Forexample, the Ringback signal isnot applied and not reported tothe DF if the media-gateway ofthe terminating party (C) is ableto provide the remote ringback.

Note This message is new inRelease 5.0.


5 of 26 3/26/2010 3:00 PM

Redirection The BTS 10200 generates thismessage if call forwarding/transfer isinvoked by the BTS 10200 for theassociate of the subscriber undersurveillance.


SurveillanceStop

The BTS 10200 generates thismessage when the surveillancefunction for a call under surveillanceends.


ConferencePartyChange

The BTS 10200 generates thismessage if the subscriber undersurveillance joins two calls (using theThree-way call feature on BTS) andif one of the communicating partiessubsequently leaves the conference.

Note The BTS 10200 does not sendthis message if it is not awareof the three-way call (forexample, a three-way call at aSIP endpoint).


Detailed information about compliance with the requirements inspecification PKT-SP-EM1.5- I01-050128 Appendix A is providedin Table 2-4.

Surveillance for Calls Involving Multiple CMSs

When a call under surveillance spans multiple call managementsystems (CMSs), one CMS might not have access to all callidentifying information or call-content intercept-access points toperform surveillance. RFC-3603 and PKT-SP-CMSS1.5-I01-050128 specify the procedure for a CMS to request otheradjacent CMSs to perform surveillance on its behalf. Accordingto these procedures, a CMS can request a CMST (CMS at theterminating side of the call) or a CMST (CMS at the originatingside of the call) to perform surveillance functions. The CMS usesthe SIP P-DCS-LAES header to make the request.

The Cisco BTS 10200 supports the sending and receiving of theP-DCS-LAES header in various SIP messages using guidelinesspecified in PacketCable specification PKT-SP-CMSS1.5-I01-050128. The detailed compliance with the proceduresspecified in the PKT-SP-CMSS1.5- I01-050128 specification isprovided in Table 3. The following statements describe how theCisco BTS 10200 uses the SIP P-DCS-LAES header toimplement CALEA.

• When the BTS 10200 requires assistance from another CMSto perform the call-data surveillance function or call-data andcall-content surveillance function, it includes the SIP


6 of 26 3/26/2010 3:00 PM

P-DCS-LAES header in a SIP message. Depending on thecall scenario, the following SIP messages can carry theP-DCS-LAES header as an indication of a surveillancerequest sent to the CMST or CMS:

– INVITE (or RE-INVITE) message

– 183 Progress

– 180 Alerting

– 200 OK

– 302 Redirection

• When the BTS 10200 requires the assistance of an adjacentCMS in performing the call-data surveillance function, itincludes BCID, CDC-IP-Address, and CDC-IP-Portinformation in the SIP P-DCS-LAES header.

• When the BTS 10200 requires the assistance of an adjacentCMS to perform the call-data and call-content surveillancefunctions, it includes BCID, CDC-IP-Address, CDC-IP-Port,CCC-ID, CCC-IP-Address, and CCC-IP-Port information in theSIP P-DCS-LAES header.

• When the BTS 10200 receives P-DCS-LAES headerinformation in any of the following SIP messages, it takes onthe surveillance responsibility based on the content of SIPP-DCS-LAES header.

– The BTS 10200 assumes the responsibility of Call-Datasurveillance if the P-DCS-LAES header is included in aSIP message with valid BCID, CDC-IP-Address, andCDC-IP-Port information.

– The BTS 10200 assumes the responsibility of Call-Dataand Call-Content if the P-DCS-LAES header is included ina SIP message with BCID, CDC-IP-Address, CDC-IP-Port,CCC-ID, CCC-IP-Address, and CCC-IP-Port information.

The grammar for the P-DCS-LAES header is specified in twodocuments: PKT-SP-CMSS1.5-I01-050128 Section 7.7.2.1and RFC 3603 Section 8. The BTS 10200 conforms to thegrammar rules specified in PKT-SP-CMSS1.5-I01-050128Section 7.7.2.1 for the encoding and decoding of theP-DCS-LAES header.

P-DCS-Redirect

= "P-DCS-Redirect" HCOLONCalled-ID *(SEMI redir-params)

Called-ID = LDQUOT addr-spec RDQUOT

redir-params = redir-uri-param / redir-count-param /generic-param

redir-uri-param = "redirector-uri" EQUAL Redirector

Redirector = LDQUOT addr-spec RDQUOT

redir-count-param

= "count" EQUAL Redir-count

Redir-count = 1*DIGIT


7 of 26 3/26/2010 3:00 PM

BTS 10200 CALEA Interaction with SIP Endpoints

The BTS 10200 Softswitch follows the guidelines specified inPKT-SP-EM1.5- I01-050128 Appendix A for sendingcall-identifying information to the delivery function for SIPendpoints. While attempting to deliver call-content information,the BTS 10200 notifies the DF server about the unavailability ofcall-content IAP on either the originating side or terminating sideof the call. These packet-cable compliant call-content IAPstypically are not available when the caller and called are SIPendpoints. In order to capture call-content information for thesecases, the Delivery Function Server must use the ServiceIndependent Intercept (SII) architecture and initiate a request forduplication of RTP streams.

Note the following additional clarifications about satisfyingCALEA requirements for SIP endpoints:

• If feature functionality is provided at the endpoint, the BTS10200 does not receive any explicit indication about thefeature provided by the endpoint. Therefore the BTS 10200 isnot required to send Service Instance messages indicatinginvocation of a feature.

• The requirements in PKT-SP-EM1.5- I01-050128 Appendix Athat pertain to sending Signal Instance messages is explicitlydesigned for NCS/MGCP endpoints. If a tapped subscriber isusing SIP endpoints, the BTS 10200 does not instruct theendpoint to play any signals/tones towards the user explicitly.However, the BTS 10200 may send information in SIPmessages that trigger an endpoint to play tone or displayinformation to the user. Table 2-2 defines how the BTS10200behaves with regard to sending Signal Instance messageswhen a tapped subscriber is using a SIP endpoint.


8 of 26 3/26/2010 3:00 PM

Table 2-2 Signals Supported for Signaling

Instance Messages to SIP Endpoints

Signal Type BTS 10200 Behavior

Busy Tone BTS10200 reports SIGNALINSTANCE message withAudible tone = BUSY when itsends a 486 busy towards theSIP endpoint under surveillance.

CallingName/Number

BTS10200 reports SIGNALINSTANCE message withTerminal Display attributecontaining Calling Name, CallingNumber, and Date if they areincluded in the INVITE messagesent toward the subject with SIPendpoint.

Ringing Tone BTS10200 reports SIGNALINSTANCE message withAudible signal = ringing when itreceives a 180 Alerting from thesubject with SIP endpoint.

Note In this case, the SIPEndpoint might haveplayed a call-waiting toneinstead towards the user.

DistinctiveRinging Tone

BTS10200 reports SIGNALINSTANCE message withAudible signal = distinctiveringing when it receives a 180Alerting from the subject withSIP endpoint and the BTS10200included the Alert-Info header inthe SIP INVITE message senttowards the user.

Note In this case, the SIPEndpoint might haveplayed a call-waiting toneor a normal ringing toneinstead towards the user.

Ring back tone BTS10200 reports SIGNALINSTANCE message withAudible signal = ringing aftersending an 180 Alerting to thesubject with SIP endpoint.

Reorder tone BTS 10200 reports SIGNALINSTANCE message withAudible signal = reorder-tonewhen it receives an INVITEmessage that is processed butcannot be routed due to reasonssuch as Invalid destinationnumber, routing failure, etc. The


9 of 26 3/26/2010 3:00 PM

Table 2-3 specifies the SIGNALS that are not reported byBTS10200 when a tapped user is associated with a SIP endpoint.

Table 2-3 Unsupported Signals for Signaling

Instance Messages to SIP Endpoints

Signal Type BTS 10200 Behavior

Stutter Dialtone

BTS10200 does not request theSIP endpoint to play a Stutter Dialtone.

ConfirmationTone

BTS10200 does not request theeSIP endpoint to play a confirmationtone.

Dial tone BTS10200 does not request theSIP endpoint to play Dial tone.

Off-hookwarning tone

BTS10200 does not request SIPendpoint to play off-hook warningtone. Endpoint may decide to playthis tone depending on its owncapability or configuration.

Ring Splash BTS10200 does not request theSIP endpoint to play a Ring splash.

DTMF tones BTS10200 does not sendout-of-band DTMF signals towardsSIP endpoints.

Call Waitingtone

BTS10200 cannot detect when aSIP endpoint plays a call-waitingtone towards the user interface.Call Waiting tone is a SIP endpointfeature.

Changes to Interface between the BTS 10200 and Delivery

Function Server

This section summarizes how the message interface between theBTS 10200 and the Delivery Function server differs from thepreceding BTS 10200 release.

• The BTS 10200 Release 5.0 implements the followingadditional messages along with the associated attributes todeliver call-identifying information towards the Deliveryfunction server. The details of the message and associatedattributes are provided in PKT-SP-EM 1.5-101-050128,Appendix A.

– Signal Instance

– Redirection

– Surveillance Stop

– Conference Party Change

• The BTS 10200 Release 5.0 also implements the Electronic


10 of 26 3/26/2010 3:00 PM

Surveillance Indication attribute in the Signaling Startmessage as defined in PKT-SP-EM 1.5-101-050128,Appendix A. However, this attribute can be used in many callscenarios other than those explicitly presented inpacket-cable specifications. The BTS 10200 implements thisattribute according to the following guidelines:

– The BTS 10200 includes the Electronic SurveillanceIndication attribute in a Signaling Start message sent fromthe forwarded-to party in case the call was already undersurveillance as a result of a wiretap on the partyforwarding the call.

– The BTS 10200 includes the Electronic SurveillanceIndication attribute in a Signaling Start message sent fromthe final terminating party in case surveillanceresponsibility is transferred to the BTS from other partiesinvolved in the call due to their inability to performcomplete surveillance.

– The BTS 10200 includes the Electronic SurveillanceIndication attribute in a Signaling Start message sent froman originating party in case surveillance responsibility istransferred to the BTS from other parties involved in thecall due to their inability to perform complete surveillance.

• The message flows between the BTS 10200 and the DeliveryFunction server have changed for call-forwarding andcall-redirection cases since the preceding release. Thechanges ensure that a common logic can be used at theDelivery Function server without regard to the number ofCMSs and the number of taps involved in the call path. Thefollowing case shows the changes to the interface betweenthe BTS 10200 and delivery function server.

Scenario Example

A@cms1 calls B@cms1. B@cms1 has an active call-forwardingunconditional feature to forward all calls to C@cms1. B is thetapped party in this call scenario.

The BTS 10200 Release 4.5 implementation uses the followingmessages to send call-identifying information to the DeliveryFunction server:

—> DF (BCID-Bt) Signaling Start (Terminating) (Calling: A)(Called: B)

—> DF (BCID-Bo) Signaling Start (Originating) (Calling: A)(Called: C) (ESI Remote-BCID: (BCID-Bt))

—> DF (BCID-Bo) Service Instance (Call Forward)(Related-BCID: BCID-Bt) (Redirected-From: B)(Redirected-To: C)

—> DF (BCID-Bo) Media Report (Open) (CCCID: X)

—> DF (BCID-Bo) Call Answer (Charge Number: B)

----------------- Active Call under surveillance-------------------------------

—> DF (BCID-Bo) Media Report (Close) (CCCID: X)

—> DF (BCID-Bo) Call Disconnect

—> DF (BCID-Bo) Signaling Stop

—> DF (BCID-Bt) Signaling Stop


11 of 26 3/26/2010 3:00 PM

The BTS 10200 Release 5.0 implementation uses the followingmessages to send call-identifying information to the Deliveryfunction server:

—> DF (BCID-Bt) Signaling Start (Terminating) (Calling: A)(Called: B)

—> DF (BCID-Bo) Signaling Start (Originating) (Calling: A)(Called: C) (ESI Remote-BCID: (BCID-Bt))

—> DF (BCID-Bt) Signal Instance (Network Signal) (rs)(Signal-To-Party: B)

—> DF (BCID-Ct) Signaling Start (Terminating) (Calling: A)(Called: C) (ESI Remote-BCID: (BCID-Bo))

—> DF (BCID-Bo) Service Instance (Call Forward)(Related-BCID: BCID-Bt) (Redirected-From: B)(Redirected-To: C)

—> DF (BCID-Ct) Media Report (Open) (CCCID: X)

—> DF (BCID-Ct) Signal Instance (Network Signal) (rg)(Signal-To-Party: C)

—> DF (BCID-Ct) Call Answer (Charge Number: B)

----------------- Active Call under surveillance-------------------------------

—> DF (BCID-Bt) Signaling Stop

—> DF (BCID-Ct) Media Report (Close) (CCCID: X)

—> DF (BCID-Bo) Signaling Stop

—> DF (BCID-Ct) Call Disconnect

—> DF (BCID-Ct) Signaling Stop

—> DF (BCID-Ct) Surveillance Stop (End of Surveillance)

BTS 10200 CALEA Interaction with SIP Triggers Feature

To use the SIP triggers feature functionality (not defined by thePacketCable 1.5 specifications) on the BTS 10200, a call can berouted to an external application server for feature processing.The BTS 10200 supports two types of triggers: OriginatingTrigger and Terminating Trigger. For both types, when a triggeris detected, the BTS 10200 routes the call to the applicationserver through a SIP interface. Typically, the application serverexecutes the feature logic and performs one of the following twooperations to enable the BTS 10200 to route the call to the finaldestination.

• An application server might initiate a new call (by sending anew INVITE message) to the BTS 10200 and include a SIPheader to enable the BTS 10200 to associate the new callwith the original call for which feature logic was invoked.

• An application server might send a 3XX redirect back to theBTS 10200 when feature logic processing is complete.

The rest of this section summarizes how the BTS 10200 operatesand interacts with the application server to perform surveillanceon calls for which the Originating or Terminating Trigger featureis invoked.

When the BTS 10200 detects any origination or terminationattempt, it checks for active surveillance associated with theoriginating or terminating party before routing the call to theapplication server. If the subscriber is under surveillance, the


12 of 26 3/26/2010 3:00 PM

BTS 10200 sends a Signaling Start message to the DeliveryFunction server and performs the call-content surveillancefunction on an available call-content Intercept access point. Inaddition, when the call is being routed to the application server,the BTS 10200:

• Initiates a new Signaling Start message with ElectronicSurveillance Indication attribute containing the billing-correlation-id set to the billing-correlation-id included in theprevious Signaling Start message sent to the DeliveryFunction server.

• Includes a P-DCS-LAES header with a billing-correlation-idassociated with the terminating half of the call.

If the application server redirects the call-back to the BTS 10200,the BTS 10200 forwards the surveillance to the terminating sideof the call. However, if the application server initiates a new call(by sending new INVITE message) to the BTS 10200, the BTS10200 expects the same (unchanged) P-DCS-LAES header (sentearlier on the original call) in the new INVITE message. The BTS10200 performs the following operations when it receives anINVITE message from the application server:

• Initiates a new Signaling Start message with ElectronicSurveillance Indication attribute containing the billing-correlation-id set to the billing-correlation-id included in theprevious Signaling Start message sent to the DeliveryFunction server

• Transfers the surveillance towards the terminating side of thecall

In addition, if the surveillance function cannot be performed onthe terminating side of the call, the BTS 10200 includes a newP-DCS-LAES header in an 18X or 200 response sent back to theapplication server. It is assumed that the application server caninclude the P-DCS-LAES header in a SIP Response messagesent back to the BTS 10200 on the original call.

CALEA Backward Compatibility

The Enhanced CALEA feature in Cisco BTS 10200 Release 5.0implements new messages and attributes defined in newerversions of the PacketCable specifications. In addition, the BTS10200 has enhanced the internal algorithms to select thecall-content IAPs according to the requirements associated withsupport of the P-DCS-LAES header for performing thesurveillance function across multiple CMSs. Theseenhancements required additional development in the DeliveryFunction server so that it could continue performing surveillancefunctions for call-scenarios that include a single CMS or multipleCMSs. For a case in which the event Enhanced Delivery functionserver is not available, the BTS 10200 provides configurationoptions (EM-PROTOCOL-VERSION-MAJOR andEM-PROTOCOL-VERSION-MINOR flags in the ESS table) whichenable the BTS to interoperate with existing software versions ofthe Delivery Function server.

Note By using the configuration options, the BTS 10200 providesbackward compatibility by disabling the new messages andattributes implemented in BTS10200 Release 5.0. However, BTS10200 Release 5.0 does not provide backward compatibility to


13 of 26 3/26/2010 3:00 PM

permit selecting the call-content IAP to generate the duplicatecall-content based on the algorithm implemented in olderreleases of the BTS 10200 software.

Note The BTS 10200 enables use of the version flags that providebackward compatibility for certain requirements (orimplementations) to avoid interoperation problems with thecurrent version of the Delivery Function server. However, the BTS

10200 does not provide control for all of the different versions ofthe PacketCable specifications that describe the use of theseflags.

CALEA Operation Similar to BTS Release 4.5

To configure CALEA to operate as it did for BTS 10200 Release4.5, set the following ESS table tokens as follows:

Option 1

• EM-PROTOCOL-VERSION-MAJOR = 11

• EM-PROTOCOL-VERSION-MINOR = 06

• GENERAL-PURPOSEFLAG = 1

In this configuration, the BTS 10200 does not send theP-DCS-LAES header and ignores the receipt of the P-DCS-LAESheader. The BTS also disables support of all the new messagesimplemented on top of BTS 10200 Release 4.5 (which include,SIGNAL INSTANCE, REDIRECTION, CONFERENCE PARTYCHANGE, SURVEILLANCE STOP). Furthermore, the BTSdisables the Electronic Surveillance Indication attribute in theSignaling Start message. In addition, the BTS 10200 does notattempt to forward the surveillance responsibility towards theterminating party in call-forwarding situations, assuming that theforwarding party remains in the call path for the duration of thecall.

For this option, set the following Softswitch Trunk Group Profiletable tokens as follows:

• ENABLE_P_DCS_LAES_HEADER = N

• SEND_LAES_IN_RESPONSE = N

• ENABLE_ES_EVENTS = N

CALEA Operation Similar to BTS Release 4.5 with SIGNAL

INSTANCE Message

To configure CALEA to operate as it did for BTS 10200 Release4.5, with the addition of SIGNAL INSTANCE MESSAGE support,set the following ESS table tokens as follows:

Option 2:




In this configuration, the BTS 10200 does not send theP-DCS-LAES header and ignores the receipt of the P-DCS-LAESheader. The BTS also disables the sending of all the newmessages defined only in PacketCable 1.5 specifications (whichinclude, REDIRECTION, CONFERENCE PARTY CHANGE,


14 of 26 3/26/2010 3:00 PM

SURVEILLANCE STOP). The BTS also disables the ElectronicSurveillance Indication attribute in the Signaling Start message.Furthermore, the BTS 10200 does not attempt to forward thesurveillance responsibility towards the terminating party incall-forwarding situations, assuming that the forwarding partyremains in the call path for the duration of the call.

For this option, set the following Softswitch Trunk Group Profiletable tokens as follows:

• ENABLE_P_DCS_LAES_HEADER = N

• SEND_LAES_IN_RESPONSE = N

• ENABLE_ES_EVENTS = N

CALEA Operation According to PacketCable 1.5 Specification

To configure the CALEA feature to operate according to thePacketCable 1.5 specifications, set the following ESS tabletokens as follows:

Option 3:




In this configuration, the BTS 10200 sends the P-DCS-LAESheader and processes the receipt of the P-DCS-LAES headerbased on configuration options specified by various flags in theSoftswitch Trunk Group Profile (softsw-tg-profile) table. The BTSalso supports of all the new messages defined only inPacket-cable 1.5 specifications (which include, REDIRECTION,CONFERENCE PARTY CHANGE, SURVEILLANCE STOP). TheBTS also enables support of the Electronic SurveillanceIndication attribute in the Signaling Start message. Furthermore,the BTS 10200 forwards the surveillance responsibility towardsthe terminating party in call-forwarding/transfer situations.

Compliance with CALEA Requirements in PKT-SP-EM1.5-

I01-050128 Appendix A

Table 2-4 describes the requirements included in thePacketCable specification PKT-SP-EM1.5-I01-050128, AppendixA and indicates the level of compliance provided by the CALEAfeature in Cisco BTS 10200, Release 5.0.

Note If the endpoint type is a SIP endpoint, refer to Table 2-1. Thesection "BTS 10200 CALEA Interaction with SIP Endpoints"section identifies caveats that pertain to the operation of CALEAwith SIP endpoints.


15 of 26 3/26/2010 3:00 PM

Table 2-4 Cisco BTS 10200 Release 5.0 Compliance with

PKT-SP-EM 1.5-101-050128, Appendix A

Requirement Description Compliance

REQ2529 The PCES event message sent tothe delivery function (DF) mustnot affect the monotonicallyincreasing sequence-number thatappears in the Event Messageheader sent to the RKS.

Compliant

REQ6108 All PCES event messages musthave the Event Object field in theEM Header attribute set to 1.

Compliant

REQ6109 PCES event messages must notbe sent to the RKS.

Compliant

REQ6110 Intercept Access Points (forexample, CMS, CMTS, and MGC)and DF must support the RadiusProtocol over UDP.

Compliant

REQ6111

REQ6112

If an IAP does not receive anAccounting-Response messagewithin the configured retryinterval, it must continueresending the same Accounting-Request until it receives anacknowledgment from the DF orthe maximum number of retries isreached. The IAP can drop therequest after the maximum retriesis reached.

Compliant

REQ6113 When a DF receives a PCESevent message in a RadiusAccounting-Request messagefrom an IAP, it must send anAccounting-Response messageto the IAP.

Notapplicable

Section A.1, Service Instance Message

REQ2530 If the service (call) is undersurveillance, the Service InstanceEvent Message must begenerated with all the standardrequired parameters and with theadditional required electronicsurveillance parameters.

Compliant

Section A.2, Signaling Start

REQ2534 If the service is under surveillanceas defined in requirement 8, thisevent message must begenerated with all the standardrequired parameters and with theadditional required electronic

Compliant


16 of 26 3/26/2010 3:00 PM

REQ2535 The MGC must generate,timestamp, and send this event tothe DF for a terminating callunder surveillance to a PSTNgateway.

Compliant

REQ2536 The MGC must timestamp thismessage when it sends the SS7IAM message or transmits thedialed digits on an MF-trunk.

Compliant

REQ2537

REQ2538

For an originating call from anMTA or from a PSTN Gateway, ifthe MGC receives signalingnotification from the terminatingCMS that the call is to beintercepted but the terminatingdevice is unable to perform theinterception, the MGC musttimestamp and send an additionalSignaling_Start event message tothe Electronic SurveillanceDelivery Function before itdelivers a response to theoriginating MTA or PSTNgateway.

This Signaling_Start eventmessage must contain theElectronic_Surveillance_Indicationattribute, and the value of theDirection_Indicator attribute mustbe integer 2 (2=Terminating).

Compliant

REQ2539 The CMS must generate,timestamp, and send this event tothe DF if the originating call froman MTA is under surveillance.

Compliant

REQ2540 The CMS must timestamp andsend this event message to theDF after all translation of thedialed digits is complete, whetherthe translation is successful ornot. This includes unroutabledigits reported to the CMS (thatis, partially dialed digits).

Compliant

REQ2541 The CMS must generate,timestamp, and send this event tothe DF for a terminating call to anMTA under surveillance, or for aterminating call undersurveillance to an MTA.

Compliant

REQ2542 The CMS must timestamp andsend this event message to theElectronic Surveillance DeliveryFunction prior to invoking anytermination features.

Compliant


17 of 26 3/26/2010 3:00 PM

REQ2534.13.1 TheElectronic_Surveillance_Indicationattribute must be present inevents sent to the DF forterminating calls that have beenredirected by a surveillancesubject.

Compliant

Section A.3, Signaling Stop

REQ6120 If the service (call) is undersurveillance, this event messagemust be generated with all thestandard required parametersand with the additional requiredelectronic surveillanceparameters.

Compliant

REQ6121 A Signaling_Stop message mustnot be generated unless aSignaling_Start message with thesame BCID has been generatedfor the call.

Compliant

REQ6122 A Signaling_Stop message mustbe generated if a Signaling_Startmessage with the same BCID hasbeen generated for the call (Inexception cases, this may be theresult of a proprietary timeout orcleanup process.)

Compliant

REQ6123 Originating CMS: In thesingle-zone scenario, theoriginating CMS must timestampthis EM message immediatelyupon transmission of theNCS-signaling DLCX message.

Compliant

REQ6124 Originating CMS: In theintradomain or interdomainscenario, the originating CMSmust timestamp this messageupon transmission of the lastsignaling event in the followinglist:

• Transmission of theNCS-signaling DLCX message

• Transmission of theCMSS-signaling BYEmessage or CANCELmessage

Compliant

REQ6125 Terminating CMS: In thesingle-zone scenario, theterminating CMS must timestampthis EM message immediatelyupon transmission of theNCS-signaling DLCX message.

Compliant

Compliance with CALEA Requirements in PKT-SP-CMSS1.5-

I01-050128 Section 7.7.2

Table 2-5 lists the requirements presented in the PacketCablespecification PKTCBL 1.5 CMSS Section 7.7.2, Appendix D and


18 of 26 3/26/2010 3:00 PM

indicates the level of compliance provided by the EnhancedCALEA feature for Cisco BTS 10200 Release 5.0.

Note The BTS 10200 does not originate a REFER message to theother CMS to transfer the call but can process the REFERmessage received from another CMS.


19 of 26 3/26/2010 3:00 PM

Table 2-5 Cisco BTS 10200 Release 5.0

Compliance with PKTCBL 1.5 CMSS

Section 7.7.2, Appendix D

Requirement Description Compliance

Section 7.6.1, Procedures at Originating Exchange(REFER Method)

REQ5025 The CMS originating aREFER must includeadditional headerparameters for P-DCS-Billing-Info, andshould include theadditional headerparameters forP-DCS-LAES, andP-DCS-Redirect, asspecified in Section7.7.

Notapplicable

BTS doesnot originateREFERmessage onCMSStrunk.

Section 7.7.2, P-DCS-LAES

REQ7454

REQ7455

REQ7456

The LAES-BCID fieldmust always bepresent. TheLAES-CCCID fieldmust be present whenthe LAES-Content fieldis present. TheLAES-Key field mustnot be included.

Compliant

REQ7457 When CMSO receivesa 3XX Redirectresponse containing aP-DCS-LAES headerin response to anINVITE, or receives aREFER requestcontaining aP-DCS-LAES headerin the Refer-To headerfor an active dialog, itmust copy the receivedP-DCS-LAES headerinto the subsequentINVITE that isgenerated as a resultof the REFER orRedirect.

Compliant

Section 7.7.2.2.1.1, Redirected Call Ends Early

REQ7458 If CMSO receives aREFER request or 3XXRedirect responsemessage as describedabove, but the call

Compliant


20 of 26 3/26/2010 3:00 PM

then CMSO must senda Surveillance Stopmessage to its localDF containing thefollowing information:

• REQ7458.1—Thelocal BCID alreadyassigned to the call(this is a requiredfield in the eventmessage header)

• REQ7458.2—Theremote BCIDassigned by CMSTand received in theP-DCS-LAESheader

• REQ7458.3—Thecall-data IPaddress and port ofthe remote DF ofCMST received inthe P-DCS-LAESheader

• REQ7458.4—Anindicator specifyingthat both call-dataand call-contentsurveillance are tobe stopped

• REQ7458.5—Anindicator specifyingthat the localsurveillancesession (if active)and remotesurveillancesession are to bestopped

Section 7.7.2.2.1.2, P-DCS-LAES Header CannotBe Included in Subsequent INVITE

Section 7.7.2.2.1.2.1, CMSO Chooses to PerformRequested Surveillance

REQ7459 If CMSO chooses toperform the requestedcall-data surveillancefunction, it must senda Signaling-Startmessage to its localDF containing thefollowing information:

• REQ7459.1—Thelocal BCID already

Compliant


21 of 26 3/26/2010 3:00 PM

assigned to the call(this is a requiredfield in the eventmessage header)

• REQ7458.6—Theremote BCIDassigned by CMSTand received in theP-DCS-LAESheader

• REQ7459.2—Thecall-data IPaddress and port ofthe remote DF ofCMST received inthe P-DCS-LAESheader

REQ7460 If CMSO is alreadymonitoring the call (forexample, due to anoutstanding lawfullyauthorized surveillanceorder on theoriginating subscriber)when it receives aP-DCS-LAES header,it must send a secondSignaling-Startmessage to its localDF, containing theappropriateparameters asspecified in thepreceding item(REQ7459).

Compliant

REQ7461 If the P-DCS-LAESheader received in the3XX Redirect responseor REFER request alsoindicates that callcontent surveillance isto be performed (inaddition to call datasurveillance), thenCMSO must allocate alocal CCCID for thecall and request theCMTS of theoriginating line (or MGof the originating trunkif the originator isoff-net) to provide acopy of the callcontent to the localDF.

Compliant


22 of 26 3/26/2010 3:00 PM

REQ7462 In addition to thecall-data informationspecified in REQ7459,CMSO must includethe following data inthe Signaling-Startmessage to the localDF:

• REQ7462.1—Thelocal CCCIDassigned to thecall.

• REQ7462.2—Theremote CCCIDassigned by CMSTand received in theP-DCS-LAESheader.

• REQ7462.3—Thecall-content IPaddress and port ofthe remote DF ofCMST received inthe P-DCS-LAESheader.

•REQ7462.4—Whenthe call ends,CMSO must send aSurveillance-Stopmessage to its localDF containing thelocal BCID andindicating that bothlocal and remotecall-data andcall-contentsurveillance are tobe stopped.

Compliant

Section 7.7.2.2.1.2.2, CMSO Chooses to PerformCall-Data but Not Call-Content

REQ7463 If the P-DCS-LAESheader received in the3XX Redirect responseor REFER requestindicates that bothcall-data andcall-contentsurveillance are to beperformed, but CMSOchooses to supportonly call-data (and notcall-content), CMSOmust send aSignaling-Start

Compliant


23 of 26 3/26/2010 3:00 PM

message to its localDF containing thecall-data informationspecified in Section7.7.2.2.1.2.1.

REQ7464 CMSO must send aSurveillance-Stopmessage containingthe followinginformation:

• REQ7464.1—Thelocal BCIDassigned by CMSOto the call. (ThisBCID was bound tothe remotesurveillancesession by thepreviousSignaling-Startmessage.)

• REQ7464.2—Anindicator specifyingthat only theremote surveillancesession is to bestopped. (Thisallows a localsurveillancesession that maybe in progress onthe originatingendpoint tocontinue.)

• REQ7464.3—Anindicator specifyingthat (only)call-contentsurveillance is to bestopped. (Thisallows the remotecall-datasurveillance tocontinue.)

Compliant

7.7.2.2.1.2.3 CMSO Chooses Not to Perform theRequested Surveillance

REQ7465 If CMSO chooses notto perform any of therequested surveillancefunctions, it must senda Surveillance-Stopmessage to its localDF containing thefollowing information:

Notapplicable

No scenariois identifiedwhereCMSO (ifBTS)chooses not


24 of 26 3/26/2010 3:00 PM

• REQ7465.1—Thelocal BCIDassigned by CMSOto the call. (Eventhough the localBCID is a requiredparameter, it doesnot convey anyuseful informationin this case,because the localBCID was notbound to theremote surveillancesession by apreviousSignaling-Startmessage.)

• REQ7465.2—Theremote BCIDassigned by CMSTand received in theP-DCS-LAESheader.

• REQ7465.3—Thecall-data IPaddress and port ofthe remote DF ofCMST received inthe P-DCS-LAESheader.

• REQ7465.4—Anindicator specifyingthat only theremote surveillancesession is to bestopped. (Thisallows a localsurveillancesession that maybe in progress onthe originatingendpoint tocontinue.)

to performtherequestedsurveillance.

REQ7466 An indicator specifyingthat both call-data andcall-contentsurveillance are to bestopped.

Notapplicable

No scenariois identifiedwhereCMSO (ifBTS)chooses notto performtherequestedsurveillance.

1 The BTS 10200 does not support sending a REFER message.

Feedback: Help us help you

Please rate thisdocument. Excellent Poor

This document solvedmy problem. Yes No Just Browsing


25 of 26 3/26/2010 3:00 PM

Suggestions toimprove thisdocument.(512 characters)

If you have provided asuggestion, pleaseenter your full nameand e-mail address.This information isoptional and allows usto contact you ifnecessary.

Name

E-mail

© 1992-2010 Cisco Systems, Inc. All rights reserved. Terms & Conditions |

Privacy Statement | Cookie Policy | Trademarks of Cisco Systems, Inc.


26 of 26 3/26/2010 3:00 PM

cisco - cryptome

Documents