Telephony Application Server [Cisco BTS 10200 Softswitch]

Table Of Contents

Cisco BTS 10200 Softswitch Telephony Application Server Feature Module

Understanding the TAS

Limitations

Origination Processing

Termination Processing

Origination + Routing Processing

Provisioning

Office Provisioning

Subscriber Provisioning

Operations

Cisco BTS 10200 Softswitch Telephony Application Server Feature Module

Revised: March 31, 2008

This document describes the Telephony Application Server (TAS) for Release 6.0 of the Cisco BTS 10200 Softswitch.

Understanding the TAS

The TAS application allows the BTS 10200 to communicate with serving call session control function (S-CSCF) servers over an IP multimedia service control (ISC) interface to provide subscriber calling features. The TAS can perform origination processing and termination processing; it can also route calls if requested by the originating S-CSCF. The TAS and the S-CSCF are both SIP-based applications. (The S-CSCF is external to the BTS 10200.)

Figure 1 shows the TAS interfaces in a typical network.

Figure 1 TAS Interfaces In a Typical Network

Limitations

This section lists limitations (conditions for which the TAS application is not designed to work).

The TAS application has the following limitations:

•It processes only calls originating on ISC trunks.

•For billing purposes, it supports call detail block (CDBs), but not event messages (EMs).

•It does not validate that the second route header refers explicitly to the S-CSCF.

•When ENUM is invoked on an incoming call, the system can terminate the call only to a non-TAS trunk or non-TAS subscriber.

The TAS does not support the following:

•Centrex or multiline hunt group (MLHG) subscribers

•Direct routing of calls between two S-CSCF nodes

•Routing over the ISC interface.

•Call transfer through SIP REFER

•SIP triggers (chaining of application servers)

•Name dialing

•Operator and emergency services—Busy line verification (BLV), operator interrupt (OI) and 911 callback

•The following REQ-URI features: E.164 formatting, dial-around indicator, calling party category, nature of address, and carrier identification code)

•P-Called-Party header

Origination Processing

The TAS application provides origination processing (also called origination services) based on a request it receives from the S-CSCF over the ISC interface. The TAS application processes the origination request from the S-CSCF and then returns the call to the S-CSCF. The S-CSCF determines whether the call requires further processing by the TAS and can send a new request to the TAS.

Figure 2 shows an example of how the TAS responds to an S-CSCF origination request, in this case an origination request with a toll-free dialed DN.

Figure 2 Example of Origination Request—Origination of Toll-Free Call

The process shown in Figure 2 is as follows:

1. The S-CSCF sends the origination request to the TAS, including the public ID of the caller and the dialed DN. The Invite message contains the following routing headers:

–Route: sip:orig@tas;lr

–Route: sip:scscf@scscf:5210;lr

2. The TAS matches the public ID of the caller to a subscriber ID in the BTS 10200 internal database. In addition, the TAS translates the dialed DN digits according to the dial plan provisioned for the originating subscriber and determines the type of call. (The TAS includes the call type in the billing record for the call.)

3. If necessary, the TAS queries the local Domain Name System (DNS) server or external ENUM server in the process of translating the public ID. In addition, the TAS queries the external Service Control Point (SCP) in the process of translating the toll-free DN.

4. The TAS performs class of service (COS) screening to determine whether this subscriber is allowed to initiate this type of call.

–The TAS returns the call, along with the translated digits and COS screening results, to the S-CSCF. The Invite message contains the routing header Route: sip:scscf@scscf:5210;lr.

(The S-CSCF is responsible for continuing with routing and call setup.)

Note The S-CSCF can use the TAS to provide origination processing even if the call does not invoke any specific calling features from the TAS. For example, the S-CSCF might require digit translation for a dialed DN, but no other processing from the TAS.

Table 1 describes the level of support provided to TAS subscribers on originating calls that the BTS 10200 receives on the ISC interface.

Table 1 Support for TAS Subscribers On Originating Calls

Originating Feature

Abbreviation

Support for TAS Subscribers

Vertical Service Codes (VSCs):

•Activation, deactivation, and interrogation features, including the use of VSCs, for example CBLK, CFUA, CFBI, CNAB, CNDB, DND_ACT, and DND_DEACT.

•VSCs dialed to access feature management functions, for example PS_MANAGE, PS_O, CIDSD, CIDSS, VM_ACCESS.

(various)

For MGCP and NCS endpoints, the system collects digits in two stages.

For SIP-based endpoints (including TAS subscribers), the VSC and any additional digits (such as a forward-to DN) are collected by the S-CSCF. The S-CSCF aggregates the VSC and all of the additional collected digits, and then presents them to the TAS at a single event during call setup.

Toll Free

8xx

Origination processing is supported for TAS subscribers.

Emergency Service

911

Only E911 support (without called-party control) is provided. Basic 911 with suspend procedure is not supported.

Automatic Callback

AC

Not supported for TAS subscribers.

Automatic Recall

AR

Not supported for TAS subscribers.

Class of Service

COS

Origination processing is supported for TAS subscribers. However account and authorization code functions are not supported.

Customer Originated Trace

COT

Not supported for TAS subscribers.

Call Transfer

CT

This is a SIP endpoint feature, not a feature of TAS.

Hotline

HOTLINE

Not supported for TAS subscribers.

Hotline Variable

HOTV

Not supported for TAS subscribers.

Limited Call Duration

LCD

Not supported for TAS subscribers.

Outgoing Call Barring

OCB

Origination processing is supported for TAS subscribers.

Speed Call - 1 /2 digit

SC1D

SC2D

Not supported for TAS subscribers.

Three Way Call

TWC

This is a SIP endpoint feature, not a feature of TAS.

Three Way Call Deluxe

TWCD

This is a SIP endpoint feature, not a feature of TAS.

Usage Sensitive Three Way Call

USTWC

This is a SIP endpoint feature, not a feature of TAS.

Warmline

WARMLINE

Not supported for TAS subscribers.

Termination Processing

The TAS application provides termination processing (also called termination services) based on a request it receives from the S-CSCF over the ISC interface. The TAS application processes each termination request from the S-CSCF and then returns the call to the S-CSCF. The S-CSCF determines whether the call requires further processing by the TAS and can send a new request to the TAS

If a terminating subscriber has a call-forwarding feature (for example, CFU, CFB, CFNA, or CFC) active on the subscriber line, the TAS application does not automatically attempt to route the call to the forward-to DN. Instead, the TAS returns the subscriber termination information (including the call-forwarding data) to the S-CSCF for processing. Subsequently, the S-CSCF has the option of sending a new origination request to the TAS based on the forward-to DN.

Figure 3 shows an example of how the TAS responds to an S-CSCF termination request, in this case the termination of an incoming call to a busy line with CFB assigned and active.

Figure 3 Example of Termination Request—Termination of Incoming Call to Busy Line

The process shown in Figure 3 is as follows:

1. The S-CSCF sends the termination request to TAS, including the public ID of the called party (the terminating subscriber line). The Invite message contains the routing header Route: sip:scscf@scscf:5210;lr.

2. The TAS matches the public ID of the called party to a subscriber ID in the BTS 10200 internal database.

3. If necessary, the TAS queries the local DNS server or external ENUM server in the process of translating the public ID.

4. The TAS returns the call to the S-CSCF with the public ID unchanged.

5. The S-CSCF attempts to terminate the call to the called party. However, the called party is busy, and the call cannot be completed.

6. The S-CSCF sends a 486 message (Busy Here) to the TAS.

7. The TAS determines that the subscriber has CFB assigned and active to a specific forward-to DN, and looks up the public ID associated with the forward-to DN.

8. The TAS sends the call back to the S-CSCF with this new public ID. The TAS also sends the original SIP headers that were part of the incoming call.

The S-CSCF is responsible for continuing with routing and call setup. For example, the S-CSCF might return the call to the TAS as a new originating request directed to the forward-to DN.

The TAS includes an acknowledgement of the CFB treatment in the billing record for the call.

Note The S-CSCF can use the TAS to provide termination processing even if the call does not invoke any specific calling features from the TAS.

Table 2 describes the level of support provided to TAS subscribers on terminating calls.

Table 2 Support for TAS Subscribers On Terminating Calls

Terminating Feature

Abbreviation

Support for TAS Subscribers

Anonymous Call Rejection

ACR

Termination processing is supported for TAS subscribers.

Busy Line Verification

BLV

Not supported for TAS subscribers.

Call-Forwarding-Busy/
Call-Forward-No-Answer/
Call Forwarding Combined/
Call-Forwarding-Unconditional -
Invocation

CFB/CFNA/
CFC/CFU

Invocation

Termination processing is supported for TAS subscribers.

Calling Identity Delivery on Call Waiting

CIDCW

This is a SIP endpoint feature, not a feature of TAS.

Calling Name Delivery

CNAM

Termination processing is supported for TAS subscribers. ¹

Calling Number Delivery

CND

The the calling number is always delivered to the application server, even if the CND feature is disabled for the subscriber; this treatment is provided because the application server is a trusted entity. However, if CNAM is disabled for the subscriber, the system does not send the calling name nor the calling number.

Call Waiting

CW

This is a SIP endpoint feature, not a feature of TAS.²

Call Waiting Deluxe

CWD

This is a SIP endpoint feature, not a feature of TAS.2

Distinctive Alerting Call Waiting Indication

DACWI

This is a SIP endpoint feature, not a feature of TAS.2

Do Not Disturb

DND

Termination processing is supported for TAS subscribers.

Distinctive Ringing Call Waiting

DRCW

Termination processing of the ringing part is supported for TAS subscribers. The TAS sends a unique alerting indication to the SIP endpoint. The endpoint plays the ring tone if it is capable of interpreting the alerting indication from the TAS.

For the call-waiting scenario, the TAS processes the alerting request. Some SIP endpoints are capable of delivering the distinctive call-waiting tone, and others are not.

Local Number Portability

LNP

Termination processing is supported for TAS subscribers. The TAS performs an LNP query if the dialed number matches a digit string provisioned in the ported_office_code table.

Multiple Directory Number

MDN

Termination processing of the ringing part is supported for TAS subscribers. The TAS informs the S-CSCF of the specific ring type to apply. You provision the ring types in the bts-public-id table.

Call waiting is not applicable to TAS.

No Solicitation Announcement

NSA

Not supported for TAS subscribers.

Privacy Screening

PS

Not supported for TAS subscribers.

Remote Activation of Call Forwarding

RACF

Termination processing is supported for TAS subscribers. You must provision a UAN domain name for this feature in the feature_config table.

Remote Call Forwarding

RCF

Not supported for TAS subscribers.

Selective Call Acceptance/
Selective Call Forwarding/
Selective Call Rejection

SCA/SCF/SCR

Termination processing is supported for TAS subscribers.

¹See the CNAM rules in Table 3.

²Call waiting function is not supported for TAS calls.

The CNAM rules for calls terminating to TAS subscribers are shown in Table 3. In this table, TAS action refers to the SIP headers that appear in the incoming and outgoing INVITE. Pass through means that the values are preserved from the incoming to the outgoing INVITEs.

Table 3 CNAM Rules for Terminating Calls

TAS Mode

Name Available

TAS Action

Orig or Orig+Route

N

Pass through the From and PAID¹ headers.

Orig or Orig+Route

Y

Pass through the From and PAID headers.

Term

N

Mark From hostname as anonymous, delete From user part, display name and PAID header in their entirety.

Term

N (but forwarding has occurred)

Pass through the user name and PAID header in their entirety.

Term

Y

Pass through user name and host on the From and PAID headers. Set Display name on From and PAID based on the CNAM feature.

¹PAID = P-Asserted Identity

Origination + Routing Processing

If the S-CSCF requests the TAS to perform origination + routing processing, the TAS provides origination processing, then routes the call according to the dial plan provisioned for the originating line.

Figure 4 shows how the TAS responds to an S-CSCF origination + routing request, in this case an origination + routing request with OCB screening.

Figure 4 Example of Origination + Routing Request—Call with OCB Screening

The process shown in Figure 4 is as follows. Note that Steps 1 through 3 are the same as Steps 1 through 3 in the "Origination Processing" section.

1. The S-CSCF sends the origination request to the TAS, including the public ID of the caller and the dialed DN.

2. The TAS matches the public ID of the caller to a subscriber ID in the BTS 10200 internal database. In addition, the TAS translates the dialed DN digits according to the dial plan provisioned for the originating subscriber and determines the type of call. (The TAS includes the call type in the billing record for the call.)

3. If necessary, the TAS queries the local Domain Name System (DNS) server or external ENUM server in the process of translating the public ID. In addition, the TAS queries the external Service Control Point (SCP) in the process of translating the toll-free DN.

4. The TAS performs COS and OCB screening to determine whether this subscriber is allowed to initiate this type of call.

5. The TAS routes the call according to the dial plan provisioned for the originating line. Examples are shown in Figure 4 for

–Path labeled 5A—If the terminating party is served by the same S-CSCF as the originating line, the TAS routes the call over the ISC interface to the S-CSCF.

–Path labeled 5B—If the terminating party is on another network, the TAS routes the call over a SIP trunk connected to an external media gateway controller (MGC) component or a call management server (CMS) component. The MGC and/or CMS can run on a separate BTS 10200 system.

Certain SIP messaging takes place when the TAS routes a call. The TAS operates as a B2BUA. It receives the call from the S-CSCF on the ISC interface. The top-most Route header must correspond to the TAS and there must be one other Route header (corresponding to the next entity to which the S-CSCF requests the call to be routed). If these headers are not present, the TAS fails the call with 403 Forbidden.

Figure 5 shows an alternate (optional) configuration in which the routing request is handled internally in the BTS 10200. This method can be used if the CMS and MGC applications are located on the same BTS 10200 hardware as the TAS application.

Figure 5 Routing Internal to BTS 10200—TAS, CMS, and MGC Collocated (Optional)

Provisioning

This section explains how to provision TAS interfaces and subscribers.

Note If the origination information in the incoming S-CSCF SIP message does not match the allowed (provisioned) values in the BTS 10200 database, the BTS 10200 fails the call with a 403 response.

Some of the values shown in this section, such as phone numbers and TSAP addresses, are intended as illustrative examples. You should use values appropriate for your network. In addition, you might need to enter values for some additional optional parameters (not shown here), depending on the requirements of your network. For a complete list and definitions for all parameters, see the Cisco BTS 10200 Softswitch CLI Database.

This procedure assumes that you have provisioned several prerequisite tables, such as call-agent and point of presence (POP), as well as routing and dial-plan tables,

Office Provisioning

Step 1 Add the isc-profile tables for the three types of TAS processing.
add isc_profile isc_user_part_route_header=orig; service_type=ORIG_TAS;
add isc_profile isc_user_part_route_header=term; service_type=TERM_TAS;
add isc_profile isc_user_part_route_header=orig+rt; 
service_type=ORIG_TAS_PLUS_ROUTE;
Step 2 Add a SIP-based trunk group profile.

The system default value for use_pai_hdr_for_ani is N, so be sure to set it to Y as shown in this example.
add softsw_tg_profile id=SS_PRO_1; protocol_type=SIP; trunk_sub_grp_type=TGID; 
auto_p_a_id=N; use_pai_hdr_for_ani=Y;
Step 3 Add a SIP element for the TAS.
add sip_element tsap_addr=sia-SYS16CA146.ipclab.cisco.com:5060;
Step 4 Add a cause code map profile and a cause code map for the TAS. This map links the standard release code 27 with a 404 release code so that the TAS release code behavior is consistent with RFC 3398.
add cause_code_map_profile id=TAS_MAP;
add cause_code_map id=TAS_MAP; recv_cause_code=27; cause_code_type=STD; 
send_cause_code=404; action=release;
Step 5 Add the trunk group and link it to the SIP-based trunk group profile.

Be sure to set tg_type=SOFTSW and poi=ISC_TG as shown. Setting poi=isc-tg causes TAS processing to take precedence over all other call-processing features for this trunk group.

You must also add the cause_code_map_id to reference the applicable cause code map (TAS_MAP in this example).
add trunk_grp id=6997; call_agent_id=CA146; tg_type=SOFTSW; 
softsw_tsap_addr=sia-SYS16CA146.ipclab.cisco.com:5060; dial_plan_id=tb92; 
tg_profile_id=SS_PRO_1; pop_id=tb92; poi=ISC_TG; trunk_sub_grp=for_tas; 
cause_code_map_id=TAS_MAP;
Step 6 Add serving domain names for the local TAS and local SIP address.
add serving_domain_name DOMAIN_NAME=tas-tb92.ipclab.cisco.com; 
AUTH_REALM_ID=tb92-ciscolab; AUTH_REQD=N;
add serving_domain_name DOMAIN_NAME=sia-SYS92CA146.ipclab.cisco.com; 
AUTH_REALM_ID=tb92-ciscolab; AUTH_REQD=N;
Step 7 Control the trunk group in service.
control trunk_grp id=6997; mode=FORCED; target_state=ins;
Step 8 Control the SIP element in service.
control sip_element tsap_addr=sia-SYS16CA146.ipclab.cisco.com:5060; 
target_state=INS;
Step 9 If you want to use the LNP feature, enter the applicable digit string.
add ported_office_code digit_string=216-555;
Step 10 If you want to use the RACF feature, enter the applicable UAN domain name. The value must match the host part of the public_id parameter in the bts_public_id table for this subscriber (see Step 2 in "Subscriber Provisioning" section).
add feature_config fname=RACF; type=uan_domain_name; datatype=string; 
value=sia-SYS16CA146.ipclab.cisco.com;
Subscriber Provisioning

Note The system does not use the dn2subscriber table for TAS subscribers. You do not need to provision this table.

Step 1 Add subscribers with term-type=tas. You must enter a DN for the subscriber ID.
add subscriber id=216-555-2905; sub_profile_id=tb92; term_type=TAS;
Step 2 Link the subscriber ID to the subscriber public ID. You can also assign a specific ring type to the subscriber.
add bts_public_id sub_id=216-555-2905; 
public_id=2165552905@sia-SYS16CA146.ipclab.cisco.com; ring_type=R1;
Operations

For a call that involves TAS services, the billing record contains

•The TAS-mode service ID with feature data values indicating origination, termination, or origination + routing processing.

•The IMS Charging Identifier (ICID) in the call detail block. The ICID value is the one that was received in the Invite message of the call.

For detailed billing field descriptions, see the Billing Guide.

CCDE, CCENT, Cisco Eos, Cisco StadiumVision, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn is a service mark; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0803R)
Copyright © 2008 Cisco Systems, Inc. All rights reserved.

Hierarchical Navigation

Cisco BTS 10200 Softswitch

Telephony Application Server

Downloads

Table Of Contents

Cisco BTS 10200 Softswitch Telephony Application Server Feature Module

Understanding the TAS

Limitations

Origination Processing

Termination Processing

Origination + Routing Processing

Provisioning

Office Provisioning

Subscriber Provisioning

Operations

All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0803R)

Copyright © 2008 Cisco Systems, Inc. All rights reserved.