Guest

Cisco BTS 10200 Softswitch

Session Initiation Protocol Name Dialing

  • Viewing Options

  • PDF (469.3 KB)
  • Feedback
Session Initiation Protocol Name Dialing Feature Module

Table Of Contents

Session Initiation Protocol Name Dialing Feature Module

Understanding the SIP Name Dialing Feature

Support for one AOR and one DN

Billing

Routing

Features

Calea

Schema

AOR Dialing


Session Initiation Protocol Name Dialing Feature Module


Revised: April 16, 2008

This document describes the Session Initiation Protocol (SIP) Name Dialing feature for Release 5.0 MR1 of the Cisco BTS 10200 Softswitch and explains how to use it.

The benefits of the SIP Name Dialing feature are:

A SIP client end-user can call either a telephone number or an alpha numeric address similar to email address (ex. xxx@yyy.com).

A SIP client end-user only has to register using name to receive calls on both name and DN.

A SIP client end-user can engage in video chats (provided the client has the ability to send and receive video).

A SIP client end-user can use advanced services such as TV Caller ID (SIP triggers).

A SIP client end-user can be tracked based on location of the softclient (PC or laptop) for 911 services. However, the SIP client end-user must initiate the location information.

The following calling modes are available:

On-net only (to other subscribers to the same service such as on a cable network)

On-net and off-net (outbound only)—Can be authorized to make outbound PSTN calls to people not on the network.

On-net and off-net calling—Subscribers can make and receive calls from the PSTN as well as from other people on the network.

Understanding the SIP Name Dialing Feature

The SIP Name Dialing feature enables the BTS 10200 to support Session Initiated Protocol (SIP) clients to dial users based on name in addition to telephone number. The SIP client could be a soft client that may also support video.

The SIP client may or may not have a Directory Number (DN) identified but will have an alphanumeric Address-Of-Record (AOR) as its identity.

Between the SIP client and the BTS 10200, there can be a SIP server (edge proxy (EP), Proxy Call Session Control Function (P-CSCF) or session border controller (SBC)) that can provide Network Address Translation (NAT) transversal and security related functions. To support this configuration, PATH header is required in the BTS 10200 system.

SIP clients can be provisioned in multiple BTS 10200 softswitches in a network and call routing between them is required with calling and called identification passed appropriately.

Figure 1 shows the network with the BTS 10200 and SIP clients.

Figure 1 Network Diagram

The SIP client interfaces with the BTS 10200 either through EP based on configuration in the client (for the SIP communication). When EP is in the network, path header support is provided in the BTS 10200.

Support for one AOR and one DN

The BTS 10200 supports the SIP client as SIP subscriber. The following requirements are assumed:

One Name (AOR) and/or one Directory Number (DN) and are needed for a SIP client

The SIP client may have two user interfaces - Instant Messenger (IM) like Voice Chat, Dial Pad

The SIP client may populate FROM header with SIP AOR or DN for both Dial Pad and Voice Chat initiated calls, although it is likely to be AOR in both cases.

There is no need to distinguish Voice Chat call from Dial Pad call at the BTS 10200, including Calea, billing, etc.

The BTS 10200 behavior:

The enhancements to the BTS 10200 to support SIP client are:

One Directory Number (DN) and one Name (AOR) are associated with a SIP subscriber (SIP client) by provisioning Table Subscriber, and Table AOR2Sub in the BTS 10200. This is the existing provisioning, no change is required. However how the AOR and DN are used has changed.

AOR and user name used in authentication can be different, this is existing behavior.

INVITE can contain AOR or DN in Request URI.

When AOR is in the Request-Uri, the BTS 10200 finds out if that AOR belongs to a subscriber within the BTS 10200.
If Req URI contains DN, existing BTS 10200 behavior prevails.

Routing to external route proxy or directly to terminating BTS 10200 as explained in the Routing section.

The originating BTS 10200 populates PAID with AOR or DN based on whether dialed number is AOR or DN respectively.

The TO header in the INVITE sent by client is not changed by the BTS 10200 for normal calls. Towards the client, the TO header will have AOR if AOR was dialed; It will have DN (DN@bts-contact), if DN was dialed.

Other existing behaviors:

Multiple registrations - The BTS 10200 will use the most recently registered unexpired contact to reach the subscriber. It cannot distinguish if the client device moved to a different contact or multiple devices are registering for the same user. This is existing BTS 10200 behavior and there is no change to this.

Request URI must be SIP URI, the BTS 10200 does not support tel URI. This is existing BTS 10200 behavior, there is no change to this.

SIP Redirection (3xx) from a client is not supported in the BTS 10200. If such message is received, the BTS 10200 will not act on contact information in the message, the call will be treated as failed. This is existing BTS 10200 behavior and there is no change to this. Table 1 lists additional BTS 10200 behaviors.

Table 1 Additional BTS 10200 Behaviors 

Summary
Additional Information

The BTS 10200 acts as the SIP client registrar.

The BTS 10200 supports a single registration process that allows the SIP client to log in and be reachable via a SIP URL (sip:xxx@yyy.net) and a DN (2153204356) within the BTS.

The BTS 10200 provides 911 access to the local PSAP based on current location of the SIP client. The provisioning system will convert the subscriber's location into the proper emergency service routing number (ESRN) for the subscriber that the BTS 10200 will use for routing.

The existing ESRN provisioning is applicable for SIP clients. No new function will be provided.

When an unique DN is not available, PSAP call back is not possible.

The BTS 10200 supports routing of On-Net routing to registered subscribers and Off-Net call routing to the PSTN.

The BTS 10200 supports a multi-POP routing architecture using the expanded functionally of ENUM platform by way of the existing SRP.

The routing of inter-BTS 10200 SIP clients may be through an external route proxy or directly from one BTS to another. For a large system with multiple BTS 10200 systems, routing through an external proxy allows central provisioning to determine the destination BTS 10200 of the called SIP client. The BTS 10200 will also have additional means to route directly to destination the BTS 10200 that may be suitable for smaller systems. When the dialed AOR is not served by the originating the BTS 10200, the following routing options are possible:

Route to external route proxy

Locate terminating BTS based on serving domain and route to that BTS. (Note that this has the limitation of partitioning subscribers to BTS based on domain name, i.e. two different BTS's cannot serve same serving domain)

The BTS 10200 must be able to reach clients behind any type of NAT including symmetric.

This is achieved by using an edge proxy/P-CSCF/SBC.

The BTS 10200 supports a SOAP/XML interface for SIP provisioning (Username, Password, AOR, DN)

The BTS 10200 supports Calea requirements for Off-Net.

When the DN is not available, the event message to DF server will have a Null attribute in the respective attributes.

The BTS10200 supports the creation of Call Logs for On-Net and Off-Net calls with the existing BTS 10200 CDR.

In both originating and terminating BTS 10200 systems, the following CDR field values will be used for the AOR dialed case:

Call type: local
Called number: AOR
Calling Number : AOR
Dialed string: AOR

In CDR, the AOR will be truncated if longer than 64 characters.

The BTS 10200 supports the insertion of DN PAID header during authentication and terminating calls to the PSTN.

PAID is inserted based on dialed number. If a DN is dialed, PAID is DN of the calling SIP client.

If AOR is dialed, PAID is AOR of the SIP client.

During authentication, there is no PAID insertion. If there is an edge proxy/P-cscf, it should store the P-associated-uri sent in 200 OK to Register and insert that as PAID in Invite.

The BTS 10200 supports the SIP client with three types of subscribers.

Type 1) SIP On-Net Only.

Type 2) SIP On-Net and Off-Net (Outbound Only).

Type 3) SIP On-Net and Off-Net (In/Outbound).

The BTS 10200 supports this requirement as stated, however; SIP AORs must contain at least one non-numeric character in order to differentiate between DNs. For example, sip:2153202345a@yyy.com and sip:a2153202345@yyy.com are valid AORs.

Type 1: Subscriber will have only AOR

Type 2: Subscriber will have AOR and a common DN that can be used for outbound call as calling DN

Type 3: Subscriber can have AOR and DN

The BTS 10200 has the capability to allow a SIP client to call only to other SIP clients for Type 1 Subscribers only.

This is achieved by creating a proper dialplan. i.e. a dial plan that has screens for all numbers/DN can be provisioned and used against all SIP clients that should be reachable only by other SIP clients. Note that this means all DN based dialing is blocked, including DN of another SIP cleint, only AOR based dialing will succeed.

The BTS 10200 has the optional capability to allow subscribers to originate outbound calls to PSTN phone numbers (either digitial voice subscribers or general PSTN DNs). The originating identity for these outbound calls must be the main AOR for the client on SIP client to SIP calls; or the DN associated with the SIP client or no DN/general DN for outbound calls to DNs. This refers to Type 2 and Type 3 subscribers.

A dial plan must be set up to allow DN calls and so PSTN calls will be allowed.

A dial plan can be set up to disallow DN calls and so PSTN calls will be disallowed.

Note that allow or disallow is for DN which meets the optional PSTN calling requirement.

A DN is always required for PSTN calling. So individual DN or a specific generic DN can be used.


Billing

AOR is not currently(prior to SIP Name Dialing) recorded in the Call Detail Record (CDR).

In Both originating and terminating BTS 10200, the following CDR field values will be used for AOR dialed case:

Call type: Local

Called number: AOR

Calling Number: AOR

Dialed string: AOR

The size of these fields (64 bytes) will restrict the AOR displayed in CDR.

The BTS 10200 provisioning data associates the subscribers DN and AOR, which can be used by downstream billing devices along with the CDR to identify AOR with a call.

Note that in the terminating BTS 10200, PAID is used to determine wether the calling party is AOR or DN; and populating CDR is same as above.

Table 2 lists the called type (calling type) to AOR or DN association.

Table 2 Called Type (Calling Type) to AOR or DN Association 

Called Type
Calling Type
AOR
Orig BTS 10200 Term BTS 10200
DN
Orig BTS 10200 Term BTS 10200

AOR

Call type

Local

Local

Existing behavior

 

Called number

AOR

AOR

 
 

Calling number

AOR

AOR

 
 

Dialed string

AOR

AOR

 

DN

Call type

Local

Local

Existing behavior

 

Called number

AOR

AOR

 
 

Calling number

DN

DN

 
 

Dialed string

AOR

AOR

 

Event message (EM) billing: Similar to Calea (only applicable fields).

Routing

The routing of inter-BTS 10200 SIP clients may be through external route proxy or directly from one BTS 10200 to another. For a large system with multiple BTS 10200 switches, routing through an external proxy allows central provisioning to determine the destination BTS 10200 of the called client. The BTS 10200 also has additional means to route directly to destination BTS 10200 switches that may be suitable for smaller systems. When the dialed AOR is not served by the originating BTS 10200, the following routing options are possible:

1. Route to external route proxy.

2. Locate the terminating BTS 10200 based on domain and route to that BTS 10200. (Note that this has the limitation of partitioning subscribers to BTS 10200 based on domain name, i.e. two different BTS 10200 switches cannot serve the same serving domain.)

Features

Please refer to the Cisco BTS 10200 Softswitch SIP Feature and Provisioning Guide for supported features. This section details the impact on those features due to name dialing.

When AOR is dialed, the originating BTS 10200 cannot do any features that require called number (e.g. call block - international call). At the terminating BTS 10200, the PAID received from originating BTS 10200 gives the identity of the calling user; the originating BTS 10200 populates PAID with AOR or DN based on whether dialed number is AOR or DN respectively. When PAID is AOR, there are no calling number based features at the terminating BTS 10200 (e.g. selective call forward).

For SIP clients, the BTS 10200 supports the same feature set supported for normal SIP endpoints. Table 3 shows the feature impact due to name dialing.

Table 3 Feature Impact Due to Name Dialing 

The BTS supports the same feature set supported for digital voice, including:

Call-waiting' feature (end point feature)

Call Forwarding Selective *

Call Forwarding Variable *

Caller ID

Caller ID with Call waiting (end point feature)

Call Return #

3-Way Calling (end point feature)

Repeat Dialing #

Speed Dial 8 (end point feature )

Speed Dial 30 (end point feature)

Anonymous Call Rejection *

Call screening *

Call Trace *

Caller ID Blocking Per Call *

Caller ID Blocking Per Line *

Restrict Toll or International Calls

Blocking of Calls to 900/976/700/500 numbers

Blocking of Collect Calls and Bill to Third Party Calls

Voicemail feature *

* If dialed identity is AOR, the feature is not required

# Not supported in BTS for SIP subscribers

When the AOR is dialed none of the listed features will be provided.

When the DN is dialed, the existing BTS 10200 features are applicable

A unique DN per SIP client is needed for forwarding-to a SIP client. (Forwarding to AOR is not possible.)


Calea

Calling Party Tap: In the existing implementation, calling party tap is based on the SUBSCRIBER: DN1 always. So, the same method will be applied when SIP client user dials AOR. The BTS 10200 will make the TAP decision based on the DN1. The information sent to DF server would have following subscriber identity related fields.

Calling Number: DN1

Called Number: NULL

User Input: dialed AOR

When Calling party does not have SUBSCRIBER: DN1, call cannot be tapped.

Called Party Tap: Called party tap should be strictly based on the dialed-string information. Since the CALEA wiretap table contains only DIGITs information, there will be no tapping on the called party for AOR dialed call.

Schema

The schema changes are as follows:

Table CA-CONFIG

Parameter: AOR-Resolve-profile

Type: string (pointer to ENUM-PROFILE)

Default: Null

Table DOMAIN2ROUTE

Parameter: AOR-Resolve-DNS

Type: Boolean

Default: No

AOR Dialing

AOR dialing is supported by passing AOR instead of Directory Number (DN) in called party identified. And the calling party identity also can be AOR in different scenarios. Table 4 shows different call scenarios based on incoming messages (Call-Type) and how calling and called party are populated in SIP messages (Send Invite).

Table 4 Call-Type to Sent Invite Population 

Call-Type
Sent Invite

DN to DN

Local to Local (called AOR's user part is DN and From header user-part is DN)

Calling (Local User)

AOR = 9726712300@xyz.net

Called (Local USER)

AOR = 9726712400@xyz.net

Serving Domain = xyz.net

Aor2Sub Entries

9726712300@xyz.net -> Subscriber1

9726712400@xyz.net -> Subscriber2

Dn2Sub Entries

9726712300 -> Subscriber1

9726712400 -> Subscriber2

ReqURI: 9726712400@contact-addr

From: 9726712300@sia.bts.com

To: 9726712400@xyz.net

Paid: 9726712300@sia.bts.com

EXISTING BEHAVIOR

DN to AOR

Local to Local (called AOR's user part is not DN but From header User-part is DN)

Calling (Local User)

AOR = 9726712300@xyz.net

Called (Local USER)

AOR = john@xyz.net

Serving Domain = xyz.net

Aor2Sub Entries

9726712300@xyz.net -> Subscriber1

john@xyz.net -> Subscriber2

Dn2Sub Entries

9726712300 -> Subscriber1

9726712400 -> Subscriber2

The AOR (john@xyz.net and Dn 9726712400 both point to Sub 2)

ReqURI: john@contact-addr

From: 9726712300@xyz.net

To: john@xyz.net

Paid: 9726712300@xyz.net

AOR to DN

Local to Local (called AOR's user part is DN Calling user's From header user part is not DN)

Calling (Local User)

AOR = bob@xyz.net

Called (Local USER)

AOR = 9726712400@xyz.net

Serving Domain = xyz.net

Aor2Sub Entries

bob@xyz.net -> Subscriber1

9726712400@xyz.net -> Subscriber2

Dn2Sub Entries

9726712300 -> Subscriber1

9726712400 -> Subscriber2

ReqURI: 9726712400@contact-addr

From: 9726712300@sia.bts.com

To: 9726712400@xyz.net

EXISTING BEHAVIOR

|AOR to AOR

Local to Local (called AOR's user part is not DN and From Header's User-part is not DN)

Calling (Local User)

AOR = bob@xyz.net

Called (Local USER)

AOR = john@xyz.net

Serving Domain = xyz.net

Aor2Sub Entries

bob@xyz.net -> Subscriber1

john@xyz.net -> Subscriber2

Dn2Sub Entries

9726712300 -> Subscriber1

9726712400 -> Subscriber2

The AOR (john@xyz.net and Dn 9726712400 both point to Sub 2.

Also bob@xyz.net and Dn

9726712300 both point to Sub 1.

ReqURI: john@contact-addr

From: bob@xyz.net

To: john@xyz.net

Paid: bob@xyz.net

DN to DN

Local to Remote BTS 10200 (called AOR's user part is DN and From header user part is DN)

Calling (Local User)

AOR = 9726712300@xyz.net

Called (Remote USER)

AOR = 9726712400@xyz.net

Serving Domain = xyz.net

Aor2Sub Entries

9726712300@xyz.net -> Subscriber1

Dn2Sub Entries

9726712300 -> Subscriber1

ReqURI: 9726712400@tg-idx2-tsap

From: 9726712300@sia.bts.com

To: 9726712400@tg-idx2-tsap

Paid: 9726712300@sia.bts.com

EXISTING BEHAVIOR

DN to AOR

Local to Remote (called AOR's user part is not DN but From header User-part is DN)

Calling (Local User)

AOR = 9726712300@xyz.net

Called (Remote USER)

AOR = john@xyz.net

Serving Domain = xyz.net

Aor2Sub Entries

9726712300@xyz.net -> Subscriber1

Dn2Sub Entries

9726712300 -> Subscriber1

ReqURI: john@xyz.net

From: 9726712300@xyz.net

To: john@xyz.net

Paid: 9726712300@xyz.net

AOR to DN

Local to Remote (called AOR's user part is DN Calling user's From header user part is not DN)

Calling (Local User)

AOR = bob@xyz.net

Called (Remote USER)

AOR = 9726712400@xyz.net

Serving Domain = xyz.net

Aor2Sub Entries

bob@xyz.net -> Subscriber1

Dn2Sub Entries

9726712300 -> Subscriber1

ReqURI: 9726712400@tg2-tsap

From: 9726712300@sia.bts.com

To: 9726712400@tg2-tsap

EXISTING BEHAVIOR

AOR to AOR

Local to Remote (called AOR's user part is not DN and From Header's User-part is not DN)

Calling (Local User)

AOR = bob@xyz.net

Called (Local USER)

AOR = john@xyz.net

Serving Domain = xyz.net

Aor2Sub Entries

bob@xyz.net -> Subscriber1

Dn2Sub Entries

9726712300 -> Subscriber1

bob@xyz.net and Dn

9726712300 both point to Sub 1.

ReqURI: john@xyz.net

From: bob@xyz.net

To: john@xyz.net

Paid: bob@xyz.net

IP routed out of TG2

DN to DN

Remote to Local (called AOR's user part is DN and from header user-part is DN)

Calling (Remote User)

AOR = 9726712300@xyz.net

Called (Local USER)

AOR = 9726712400@xyz.net

Serving Domain = xyz.net

Aor2Sub Entries

9726712400@xyz.net -> Subscriber2

Dn2Sub Entries

9726712400 -> Subscriber2

ReqURI: 9726712400@contact-addr

From: 9726712300@sia.bts.com

To: 9726712400@xyz.net

Paid: 9726712300@sia.bts.com

EXISTING BEHAVIOR

DN to AOR

Remote to Local (called AOR's user part is not DN but From header User-part is DN)

Calling (Remote User)

AOR = 9726712300@xyz.net

Called (Local USER)

AOR = john@xyz.net

Serving Domain = xyz.net

Aor2Sub Entries

john@xyz.net -> Subscriber2

Dn2Sub Entries

9726712400 -> Subscriber2

The AOR (john@xyz.net and Dn 9726712400 both point to Sub 2.

ReqURI: john@contact-addr

From: 9726712300@xyz.net

To: john@xyz.net

Paid: 9726712300@xyz.net

AOR to DN

(This shld not happen when call comes over TG) Remote to Local (called AOR's user part is DN Calling user's From header user part is not DN)

Calling (Local User)

AOR = bob@xyz.net

Called (Local USER)

AOR = 9726712400@xyz.net

Serving Domain = xyz.net

Aor2Sub Entries

bob@xyz.net -> Subscriber1

9726712400@xyz.net -> Subscriber2

Dn2Sub Entries

9726712300 -> Subscriber1

9726712400 -> Subscriber2

ReqURI: 9726712400@contact-addr

From: 9726712300@sia.bts.com

To: 9726712400@xyz.net

EXISTING BEHAVIOR

AOR to AOR

Remote to Local (called AOR's user part is not DN and From Header's User-part is not DN)

Calling (Remote User)

AOR = bob@xyz.net

Called (Local USER)

AOR = john@xyz.net

Serving Domain = xyz.net

Aor2Sub Entries

john@xyz.net -> Subscriber2

Dn2Sub Entries

9726712400 -> Subscriber2

The AOR (john@xyz.net and Dn 9726712400 both point to Sub 2).

ReqURI: john@contact-addr

From: bob@xyz.net

To: john@xyz.net

Paid: bob@xyz.net