Guest

Cisco BTS 10200 Softswitch

Secure SIP Client Configuration

  • Viewing Options

  • PDF (226.3 KB)
  • Feedback
Secure SIP Client Configuration Feature Module

Table Of Contents

Secure SIP Client Configuration Feature Module

Understanding the Secure SIP Client Configuration Feature

Call Flows

Registration

Origination

Mid-call Signaling

Termination

PATH Header

Provisioning

Secure P-CSCF/Edge Proxy Configuration

Trunk Group as Secure P-CSCF/Edge Proxy Configuration


Secure SIP Client Configuration Feature Module


Revised: April 16, 2008

This document describes the Secure Session Initiation Protocol (SIP) Client Configuration feature for Release 5.0 MR2 of the Cisco BTS 10200 Softswitch and explains how to use it.

Understanding the Secure SIP Client Configuration Feature

The Secure Session Initiation Protocol (SIP) Client Configuration feature enables the shielding of the BTS 10200 from external, possibly malignant, traffic. The shielding is enabled by the securing of the client session through use of a session border controller (SBC) and edge proxy (EP). After the initial registration the client session does not need to be challenged when the shielding is enabled.

The SBC and EP adds the path header on the REGISTER transaction and asserts the P-AID header for subsequent session-initiating INVITE transactions from the SIP client. Additionally, the Record-Route header is added by the SBC to every session-initiating INVITE, in either direction to enable the forwarding of the request between the internal and external networks.

For user privacy, the client adds the privacy ID field or, if the client invite is entered as anonymous@anonymous.invalid, the SBC adds the privacy ID field. Subscriber invites are transmitted to the BTS 10200 with the P-AID header.

As shown in Figure 1, the connection between each SIP client and each SBC is protected by a firewall. The SBC is securely connected to the BTS 10200 inside the firewall. The SBC/EP is configured on the BTS 10200 as a soft switch trunk group with ANI-based routing enabled.

Figure 1 Secure SIP Client-to-BTS 10200 Connection

Call Flows

This section contains the following examples of call flows:

Registration

Origination

Mid-call Signaling

Termination

Registration

Figure 2 provides an example of the registration call flow.

Figure 2 Registration Call Flow

Origination

Figure 3 provides an example of the origination call flow.

Figure 3 Origination Call Flow

Mid-call Signaling

Figure 4 provides an example of the mid-call signaling call flow.

Figure 4 Mid-call Signaling Call Flow

Termination

Figure 5 provides an example of the termination call flow.

Figure 5 Termination Call Flow

PATH Header

The following are assumptions concerning the PATH header:

The PATH header is inserted by edge proxy (secure P-CSCF or other) in the REGISTER message.

A client can associate with different edge proxies at different times and registrations; it does not concern the BTS 10200.

The following lists the BTS 10200 behavior when the PATH header is used:

When registration is successful for a SIP subscriber, the BTS 10200 stores the PATH header received in REGISTER, along with the registered contact of the subscriber.

When an INVITE is received from a subscriber who has registered with a PATH header, the INVITE is processed without a challenge which validates the (presumed secure) SIP client.

When the BTS 10200 receives the initial INVITE from the local SIP client, the call is accepted without authentication if the client was associated with the PATH header during registration and has a valid unexpired contact.

If a REGISTER message arrives with a PATH header but without a Supported: path option tag, the BTS 10200 rejects it with a 420 if the BTS 10200 configuration requires rejecting it.

In the 200 OK response to REGISTER, the BTS 10200 echoes the PATH header received in the request (initial as well as refresh Register responses).

When routing is to a local SIP subscriber, if there is a PATH vector stored, the BTS 10200 builds a Route list from it, when sending the initial INVITE to that subscriber. The INVITE is sent to the top-most route (that is the top-most entry from the stored Path header). Subsequent requests sent for that same dialog do not use the preloaded route. They are routed based on any record-routing that occurs during that dialog establishment.

If the BTS 10200 is directly accessible from the external internet and a SIP client registers directly with the BTS 10200, bypassing the proxy (for example, without the PATH header), the BTS 10200 accepts it. In this case, every request from the client is authenticated.

Provisioning

This section explains how to provision and configure the following:

Secure P-CSCF/Edge Proxy Configuration

Trunk Group as Secure P-CSCF/Edge Proxy Configuration


Note For complete CLI information, see the Cisco BTS 10200 Softswitch Command Line Interface Database.


Secure P-CSCF/Edge Proxy Configuration

Before the introduction of this feature, the BTS 10200 supported SIP endpoints directly without any proxy between the BTS 10200 and the client. This behavior is still supported when the SIP client is supported. However in SIP client deployment, it is expected that the P-CSCF/Edge proxy is required to support client behind the NAT (STUN), security, and so forth firewall.

P-CSCF/edge proxy related assumptions are

When a SIP client is successfully registered, P-CSCF stores the P-associated-uri in 200 OK (sent by the BTS 10200) for the REGISTER.

In the SIP client-initiated requests (non-REGISTER), P-CSCF inserts the stored PAID based on stored identity (P-associated-uri) before forwarding the requests to the BTS 10200.

P-CSCF inserts a PATH header in the REGISTER request (detailed later).

The BTS 10200 requirements:

A trunk group corresponding to the P-CSCF must be configured in the BTS 10200 (existing soft switch trunk group).

The BTS 10200 provides service to a SIP client behind an edge proxy (p-cscf or other) only if it is registered and has an associated PATH during registration.

When the request is not through any configured soft switch trunk, the client is considered to be connected directly to the BTS 10200.

The BTS 10200 uses the presence of a PATH header in REGISTER as verification that the SIP client is secure and accepts INVITEs from that client, without a challenge authentication sequence.

Trunk Group as Secure P-CSCF/Edge Proxy Configuration

Use the following steps to configure a trunk group as a secure P-CSCF edge proxy:


Step 1 Enable anti_based_routing for the trunk group.

Step 2 Disable voice_mail_trunk_group in the trunk group profile.

Step 3 Enable use_pai_hdr_for_ani for the trunk group.