Network and Subscriber Feature Descriptions
Chapter 3 - Subscriber Features
Downloads: This chapterpdf (PDF - 1.61MB) The complete bookPDF (PDF - 4.68MB) | Feedback

Subscriber Features

Table Of Contents

Subscriber Features

Interoperability

Subscriber Feature List

Call Forwarding Features

Call Forwarding Unconditional (CFU)

CFU Activation (CFUA)

CFU Deactivation (CFUD)

CFU Interrogation (CFUI)

CFU Invocation

Invalid User Actions

CFU Feature Interactions

Feature Provisioning Commands

Call Forwarding Variable for Basic Business Group (CFVBBG)

CFVBBG Description

CFVBBG Activation—CFVABBG

Feature Provisioning Commands

Remote Activation of Call Forwarding (RACF)

Remote Call Forwarding (RCF)

Call Forwarding Busy (CFB)

CFB Variable Activation (CFBVA)

CFB Variable Deactivation (CFBVD)

CFB Interrogation (CFBI)

CFB Invocation

Invalid User Actions

CFB Feature Interactions

Feature Provisioning Commands

Call Forwarding No Answer (CFNA)

CFNA Variable Activation (CFNAVA)

CFNA Variable Deactivation (CFNAVD)

CFNA Interrogation (CFNAI)

CFNA Invocation

Invalid User Actions

CFNA Feature Interactions

Feature Provisioning Commands

Call Forwarding Combination (CFC)

Vertical Service Codes for CFC

Blocking Call Forwarding to Certain Types of DNs

Detailed Feature Description

CFC Activation (CFC_ACT)

CFC Deactivation (CFC_DEACT)

CFC Activation with Directory Number Change (CFC_DN_CHG_ACT)

CFC Interrogation with No Directory Number Verification (CFCI_NO_DN_VRFY)

CFC Interrogation (CFCI)

CFC Invocation (CFC)

Flags Applicable to CFC Activation and Deactivation Subfeatures

Invalid User Actions

CFC Feature Interactions

Feature Provisioning Commands

Call Waiting Features

Limitations

Call Waiting (CW)

CW Activation

CW Deactivation

CW Feature Interactions

Feature Provisioning Commands

Cancel Call Waiting (CCW)

Calling Identity Delivery on Call Waiting (CIDCW)

CIDCW Activation

CIDCW Deactivation

CIDCW Feature Interactions

Feature Provisioning Commands

Call Waiting Deluxe (CWD)

CWD Timers

CWD Activation

CWD Deactivation

CWD Interrogation

CWD Invocation

Invalid User Actions

CWD Feature Interactions

Feature Provisioning Commands

Calling Identity Features

Calling Identity Delivery

Calling Number Delivery (CND)

Calling Name Delivery (CNAM)

Calling Line Identification Presentation (CLIP)

CLIP Feature Description

CLIP Feature Activation and Deactivation

CLIP Feature Interactions

Feature Provisioning Commands

Calling Identity Delivery Blocking (CIDB)

Calling Number Delivery Blocking (CNDB)

Calling Name Delivery Blocking (CNAB)

Calling Identity Delivery and Suppression (CIDSD and CIDSS)

Calling Line Identification Restriction (CLIR)

Calling Identity Presentation Status

Calling Number Delivery Blocking (CNDB)

Calling Name Delivery Blocking (CNAB)

Calling Identity Delivery and Suppression (CIDSD and CIDSS)

CLIR Feature Interactions

Feature Provisioning Commands

Direct Inward/Outward Dialing for PBX

Analog DID for PBX

DOD For PBX

Seasonal Suspend

Seasonal Suspend Feature for Release 5.0 MR1 and Earlier

Understanding the Seasonal Suspend Feature, MR1 and Earlier

Feature Interactions

Prerequisites

Limitations

Restrictions

Provisioning

Seasonal Suspend Feature for Release 5.0 MR1.1 and Later

Understanding the Seasonal Suspend Feature, MR1.1 and Later

Feature Interactions

Prerequisites

Limitations

Restrictions

Provisioning

Terminal and Group Make Busy Services

TMB

GMB

Feature Interactions

TMB

GMB

Configuring

Features for Centrex Subscribers Only

Call Hold (CHD)

Description

Feature Interactions with CHD

Feature Provisioning

Call Park and Call Retrieve

Direct Inward/Outward Dialing for Centrex

Directed Call Pickup (With and Without Barge-In)

Distinctive Alerting/Call Waiting Indication (DA/CWI)

Additional Features Applicable to Centrex and POTS

Anonymous Call Rejection (ACR)

Automatic Callback (AC)—Repeat Dialing

Automatic Recall (AR)—Call Return

One-Level Activation of AR

Two-Level Activation of AR

Feature Provisioning Commands

Call Block - Reject Caller (CBLK)

Block All Inbound Calls

Call Transfer (CT)

Feature Provisioning Commands

SIP Call Transfer with REFER and SIP Invite with REPLACES

Change Number (CN)

Customer-Originated Trace (COT)

Do Not Disturb (DND)

Hotline Service

Hotline-Variable Service (HOTV)

Hotline-Variable Feature Description

Hotline-Variable Activation

Hotline-Variable Deactivation

Hotline-Variable Interrogation

Hotline-Variable Invocation

Invalid User Actions

HOTV Feature Interactions

Feature Provisioning Commands

Interactive Voice Response (IVR) Functions

Limited Call Duration Service (Prepaid/Postpaid) with RADIUS Interface to AAA

Network Interfaces

Feature Description

Provisionable Parameters

Feature Interactions

Prerequisites

Restrictions and Limitations

Feature Provisioning Commands

Message Waiting Indicator (MWI)—Audible and Visual

Multiline Hunt Group (MLHG)

Hunting Sequence

Preferential Hunt Lists

MLHG Provisioning Options and Use Cases

Treatment of Outbound Call Features

Treatment of Inbound Call Features

Billing for MLHG

Basic Provisioning Procedure and CLI Reference

Multiline Variety Package

Provisioning Procedure

Multiple Directory Numbers (MDN)

No Solicitation Announcement (NSA)

References

NSA Activation, Management, and Control

NSA Invocation

Feature Interactions

Prerequisites

Feature Provisioning Commands

Own Calling Number Announcement (OCNA)

Privacy Screening (Calling Identity with Enhanced Screening)

Privacy Screening Description

Privacy Screening Invocation

Privacy Screening Subscriber Management

Feature Interactions

Feature Provisioning Commands

Speed Call

Speed Call for Individual Subscribers

Group Speed Call

Subscriber-Controlled Services and Screening List Editing (SLE)

CORBA Interface

User Access

Selective Call Forwarding (SCF)

Selective Call Acceptance (SCA)

Selective Call Rejection (SCR)

Distinctive Ringing/Call Waiting (DRCW)

Temporarily Disconnected Subscriber Status and Soft Dial Tone

Provisioning Options and System Behavior

Feature Interactions

Restrictions and Limitations

Feature Provisioning Commands

Three-Way Calling (TWC)

Limitations

Feature Description

TWC Feature Interactions

Feature Provisioning Commands

Three-Way Calling Deluxe (TWCD)

To Begin a Three-Way Call:

Options While on a Three-Way Call with All Three Parties Bridged Together:

TWCD Timers

Invalid User Actions

TWCD Feature Interactions

Feature Provisioning Commands

Usage-Sensitive Three-Way Calling (USTWC)

Limitations

Feature Description

Feature Provisioning Commands

Visual Message Waiting Indicator (VMWI)

Voice Mail (VM) and Voice Mail Always (VMA)

VM Activation, Deactivation, and Invocation

VMA Activation, Deactivation, and Invocation

VM Access

Provisionable Parameters for VM and VMA

Feature Interactions

Warmline Service

Office Service ID and Default Office Service ID

Notes on Bundling Features in Services


Subscriber Features


Revised: March 24, 2011, OL-12606-21

The Cisco BTS 10200 Softswitch supports subscriber features, including selected custom local area signaling service (CLASS) features, as described in the following sections. Most of these features are defined in Telcordia LSSGR documents or in corresponding ITU-T documents. In most cases, The BTS 10200 features delivered via gateway clients behave identically to their PSTN counterparts. These features are described in the following sections:

Call Forwarding Features

Call Waiting Features

Calling Identity Features

Direct Inward/Outward Dialing for PBX

Features for Centrex Subscribers Only

Additional Features Applicable to Centrex and POTS

Additional general information is provided in the following sections:

Office Service ID and Default Office Service ID

Notes on Bundling Features in Services


Note For network features, see Chapter 1, "Network Features." For outgoing call restriction options (Class of Service and Outgoing Call Barring), see Chapter 4, "Class of Service Restrictions and Outgoing Call Barring Features."


Some features can be accessed and controlled by the subscriber using a handset and vertical service codes (VSCs). VSCs are provisionable by the service provider (any valid unique ASCII string up to five characters long), and the customary values are country specific. The VSC values used throughout this chapter are for illustration purposes. For convenience, some VSC values are preprovisioned in the BTS 10200. The valid formats for VSC ASCII strings are listed in the Vertical Service Code commands in the Cisco BTS 10200 Softswitch CLI Database. To view the current VSC values provisioned on your system, use the show vsc CLI command. To provision VSCs, see the VSC provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.

Typically, the system responds to user handset actions by providing an appropriate announcement. However, if an announcement is not provisioned or cannot be played, an appropriate tone (confirmation tone or reorder tone) is played. A list of these announcements and tones is provided in Appendix A - Cause Code to Announcement ID Mappings" in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip For information on provisioning these features, see the Feature Provisioning chapter in the Cisco BTS 10200 Softswitch Provisioning Guide.


Interoperability

The BTS 10200 interworks with a wide range of network elements (NEs), but there are certain limitations. Cisco recommends that you keep the following caution in mind as you prepare to purchase and use NEs for your network.


Caution Some features involve the use of other network elements (NEs) deployed in the service provider network, for example, gateways, media servers, announcement servers, eMTAs, and SIP phones. See the "Component Interoperability" section of the Release Notes for a complete list of the specific peripheral platforms, functions, and software loads that have been used in system testing for interoperability with the Cisco BTS 10200 Softswitch Release 5.0 software. Earlier or later releases of platform software might be interoperable and it might be possible to use other functions on these platforms. The list in the Release Notes certifies only that the required interoperation of these platforms, the functions listed, and the protocols listed have been successfully tested with the Cisco BTS 10200 Softswitch.

Subscriber Feature List

Table 3-1 lists the subscriber features that are described in this chapter, an industry reference document (if applicable), and the category of subscriber for which this service is available.

Table 3-1 Subscriber Features 

Feature Description
Industry Reference Document
Subscriber Category

Call Forwarding Unconditional (CFU)

FSD 01-02-1401
GR-580

Centrex

POTS

Call Forwarding Variable for Basic Business Group (CFVBBG)

FSD 01-02-1450
GR-586

Centrex

POTS

Remote Activation of Call Forwarding (RACF)

 

Centrex

POTS

Remote Call Forwarding (RCF)

FSD 01-02-1450
GR-586

Centrex

POTS

Call Forwarding Busy (CFB)

FSD 01-02-1450
TR-TSY-000586

Centrex

POTS

Call Forwarding No Answer (CFNA)

FSD 01-02-1450
TR-TSY-000586

FSD 01-02-2200
TR-TSY-001520

Centrex

POTS

Call Forwarding Combination (CFC)

 

Centrex

POTS

Call Waiting Features

Call Waiting (CW)

FSD 01-02-1201
TR-NWT-000571

Centrex

POTS

Cancel Call Waiting (CCW)

FSD 01-02-1204
TR-TSY-000572

Centrex

POTS

Calling Identity Delivery on Call Waiting (CIDCW)

FSD 01-02-1090
TR-NWT-000575

Centrex

POTS

Call Waiting Deluxe (CWD)

 

Centrex

POTS

Calling Identity Delivery

Calling Number Delivery (CND)

Calling Name Delivery (CNAM)

FSD 01-02-1051
GR-31-CORE

FSD 01-02-1070
TR-NWT-001188

Centrex

POTS

Calling Line Identification Presentation (CLIP)

FSD 01-02-1051
GR-31-CORE
and
ITU-T Recommendation I.251.3 (08/92)

Centrex

POTS

Calling Identity Delivery Blocking (CIDB)

Calling Number Delivery Blocking (CNDB)

Calling Name Delivery Blocking (CNAB)

Calling Identity Delivery and Suppression (CIDSD and CIDSS)

FSD 01-02-1053
GR-391-CORE

Centrex

POTS

Calling Line Identification Restriction (CLIR)

Calling Number Delivery Blocking (CNDB)

Calling Name Delivery Blocking (CNAB)

Calling Identity Delivery and Suppression (CIDSD and CIDSS)

FSD 01-02-1053 GR-391-CORE
and
ITU-T Recommendation I.251.4 (08/92)

Centrex

POTS

Seasonal Suspend (Not available for Centrex and MLHG subscribers)

   

Terminal and Group Make Busy Services

   

Analog DID for PBX

TIA/EIA-464B

POTS only

DOD For PBX

FSD 04-02-0000
TR-TSY-000524

POTS only

Call Hold (CHD)

FSD 01-02-1305
TR-TSY-000579

Centrex only

Call Park and Call Retrieve

FSD 01-02-2400 GR-2913-CORE

Centrex only

Direct Inward/Outward Dialing for Centrex

FSD 01-01-1000

TR-TSY-000520

Centrex only

Directed Call Pickup (With and Without Barge-In)

FSD 01-02-2800
TR-TSY-000590

Centrex only

Distinctive Alerting/Call Waiting Indication (DA/CWI)

FSD 01-01-1110 GR-520-CORE

Centrex only

Anonymous Call Rejection (ACR)

FSD 01-02-1060 TR-TSY-000567

Centrex

POTS

Automatic Callback (AC)—Repeat Dialing

GR-215-CORE

Centrex

POTS

Automatic Recall (AR)—Call Return

GR-227-CORE

Centrex

POTS

Call Block - Reject Caller (CBLK)

 

Centrex

POTS

Call Transfer (CT)

FSD 01-02-1305
TR-TSY-000579

Centrex

POTS

Customer-Originated Trace (COT)

FSD 01-02-1052 GR-216-CORE

Centrex

POTS

Do Not Disturb (DND)

FSD 01-02-750 SR-504

Centrex

POTS

Hotline Service
(See also "Hotline-Variable Service (HOTV)" and "Warmline Service")

 

Centrex

POTS

Hotline-Variable Service (HOTV)

 

Centrex

POTS

Interactive Voice Response (IVR) Functions

 

Centrex

POTS

Limited Call Duration Service (Prepaid/Postpaid) with RADIUS Interface to AAA

 

POTS

Message Waiting Indicator (MWI)—Audible and Visual

 

Centrex

POTS

Multiline Hunt Group (MLHG)

FSD 01-02-0802
TR-TSY-000569

Centrex

POTS

Multiline Variety Package

 

Centrex

POTS

Multiple Directory Numbers (MDN)

 

POTS only

No Solicitation Announcement (NSA)

 

Centrex

POTS

Privacy Screening (Calling Identity with Enhanced Screening)

 

Centrex

POTS

Speed Call

Speed Call for Individual Subscribers

Group Speed Call (Centrex and MLHG only)

FSD 01-02-1101
TR-TSY-000570

Centrex

POTS

Subscriber-Controlled Services and Screening List Editing (SLE)

Selective Call Forwarding (SCF)

Selective Call Acceptance (SCA)

Selective Call Rejection (SCR)

Distinctive Ringing/Call Waiting (DRCW)

FSD 30-28-1000
GR-220-CORE

FSD 01-02-1410
TR-TSY-000217

FSD 01-02-0760 TR-TSY-000218

FSD 01-01-1110 TR-TSY-000219

Centrex

POTS

Temporarily Disconnected Subscriber Status and Soft Dial Tone

 

Centrex

POTS

Three-Way Calling (TWC)

FSD 01-02-1301
TR-TSY-000577

Centrex

POTS

Three-Way Calling Deluxe (TWCD)

 

Centrex

POTS

Usage-Sensitive Three-Way Calling (USTWC)

FSD 01-02-1304
TR-TSY-000578

Centrex

POTS

Visual Message Waiting Indicator (VMWI)

GR-2942-CORE

Centrex

POTS

Voice Mail (VM) and Voice Mail Always (VMA)

 

Centrex

POTS

Warmline Service
(See also "Hotline Service")

 

Centrex

POTS


Call Forwarding Features

Call forwarding is a group of features allowing incoming calls to a subscriber line to be forwarded to another telephone number, including a cellular phone number, under various circumstances. Call forwarding features allow a subscriber line to be forwarded to a number that itself can be forwarded. This chaining of call forwards is allowed to a maximum of five different stations as long as none of the station numbers appears twice in the forwarding list (in order to prevent loops). Before forwarding a call outside of a zone or off net, the system must determine if the forwarding station already has an active call that has been forwarded to the same destination. If so, forwarding is denied to the second call and a station busy signal is returned to the caller.

The following types of call forwarding features are provided by the Cisco BTS 10200 Softswitch:

Call Forwarding Unconditional (CFU)

Call Forwarding Variable for Basic Business Group (CFVBBG)

Remote Activation of Call Forwarding (RACF)

Remote Call Forwarding (RCF).

Call Forwarding Busy (CFB)

Call Forwarding No Answer (CFNA)

Call Forwarding Combination (CFC)

Call Forwarding Redirection (CFR)—This is a SIP-specific feature. With CFR, the SIP endpoint initiates the call forwarding. For a description and provisioning commands, see the "Sending 302 on Call Redirection" section in the Cisco BTS 10200 Softswitch SIP Feature and Provisioning Guide.

Call Forwarding Unconditional (CFU)

The Cisco BTS 10200 Softswitch provides the call forwarding unconditional (CFU) feature. CFU allows the user to forward all calls regardless of the status of the user's line. A typical forwarding address is voice mail, a remote telephone, or an attendant.

Reference documents include:

LSSGR module FSD 01-02-1401 (GR-580), Call Forwarding Variable

LSSGR module FSD 01-02-1450 (GR-586), Call Forwarding Subfeatures

ITU-T Q-732.2

ITU I-252.4

The service provider can provision the CFU feature to be active immediately on the customer line, or to be activated by the individual subscriber using the handset. The user activates the CFU feature on the local phone, and enters the forward-to phone number where the user wishes to have the calls forwarded. This forward-to directory number (DN) is referred to as the B-number. The allowed types of B-numbers are listed in Table 3-2.

Table 3-2 Allowed Types of B-numbers

Subscriber Type
Allowed B-number

POTS

DN, without extensions

Centrex

Public access code + external DN, without extensions

An extension within the business group


The following conditions apply to the CFU feature:

The CFU feature can be provided to POTS, Centrex, and MLHG subscribers.

The CFU feature is in the deactivated mode unless activated by the service provider or subscriber.

Call forwarding hop scenarios are restricted to a maximum of five hops. The call will be completed on the provisioned maximum number of hops.

The CFU feature is composed of four associated features, which are described in the following sections:

CFU Activation (CFUA)

CFU Deactivation (CFUD)

CFU Interrogation (CFUI)

CFU Invocation

Additional information about this feature is covered in the following sections:

Invalid User Actions

CFU Feature Interactions

Feature Provisioning Commands

CFU Activation (CFUA)

This section discusses how the service provider can customize CFU activation, and the CFU activation procedures available to the handset user.

Blocking Call Forwarding to Certain Types of DNs

The service provider can block call forwarding to certain types of DNs by provisioning the nature of dial (NOD) parameter for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD Restrict List (nod-restrict-list) table. For example, if you provision NOD=TOLL-FREE and NOD=EMG in the nod-restrict-list table, the system will not allow call-forwarding to DNs of those types.


Caution If you want to block call-forwarding to an emergency (EMG) DN, such as 911, you must provision NOD=EMG for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD-RESTRICT-LIST. This is necessary to comply with the rule in Telcordia document GR-580, which says that 911 should not be a permitted "forward to" number.


Tip To provision the CFU feature, see the CFU provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


CFUA Customization Options

The behavior of CFU activation can be customized using the following provisionable options.

Courtesy call (CC)—The CC flag controls the delivery of a courtesy call while activating CFU.

A value of N indicates that no courtesy call will be placed.

A value of ANS or NOANS indicates that a courtesy call will be placed. ANS means that the courtesy call will have to be answered for CFU to be activated. NOANS means that the courtesy call does not have to be answered for CFU to be activated.

Second stage dial tone (SDT)—The SDT flag controls the delivery of a dial tone after the subscriber enters the vertical service code (VSC) for activation or interrogation of CFU. The permitted values for this flag are:

NO_TONE

DIAL_TONE

STUTTER_DIAL_TONE

CONFIRMATION_TONE

CONFIRMATION_DIAL_TONE


Note For SIP phone subscribers, the SDT parameter has no effect. The SDT option is available through the dial plan in the SIP phone.


Final stage dial tone (FDT)—The FDT flag controls the system response to a successful activation, deactivation, or interrogation of CFU by the subscriber. If FDT is not provisioned, the system provides a success announcement. The permitted values for this flag are the same as for the SDT flag.


Note For SIP phone subscribers, only the success announcements will be provided. The confirmation tone and dial tone will not be provided, even if the FDT flag is set.


Reminder ring (RR)—When RR is provisioned as Y, a subscriber who has an idle station with CFU activated, receives a reminder ring when incoming calls are forwarded. If the subscriber goes off-hook after hearing the RR, the system ignores the off-hook condition, and does not complete the call to this station; the call is forwarded to the DN provisioned for CFU. A reminder ring is a half-second burst of ringing. The reminder ring is not applied when the forwarding station is off hook.

Multiple call forwarding (MCF)—When MCF is provisioned as Y, the system allows multiple incoming calls to be forwarded by the subscriber at the same time. If a subscriber already has CFU invoked, additional calls to the subscriber will be forwarded by CFU based on the MCF flag. If the MCF flag is set to N, the system allows only one CFU invocation.

International call forwarding (INTL)—When the INTL flag is set to N, the system does not allow forwarding to an international number. When INTL is set to Y, the system checks for other restrictions on international calls, and allows forwarding if there are no other restrictions provisioned for the call type and calling number. (Other provisionable restrictions on international calling can be based on the nature of dial [NOD] and the subscriber feature data.)

To view a list of these feature options for CFU in the Cisco BTS 10200 Softswitch CLI Database, use the show feature-profile-base fname=cfu CLI command.To provision the CFU feature, see the CFU provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.

CFUA Handset Procedures

CFU can be activated by the service provider or by the individual user. The procedures are as follows:

CFU can be activated permanently at subscription time by the service provider. The service provider provisions the forward-to DN as requested by the subscriber. All calls made to the subscriber's line will be forwarded to the single forward-to number that was provisioned.

CFU can be activated by the user as follows.


Note See the "CFUA Customization Options" section for details of customized features CC, SDT, and FDT.


The user lifts the handset and listens for dial tone.

The user presses the VSC applicable to CFU activation (for example, typically *72 in North America and *57* in China). The VSC values are provisionable by the service provider.

If provisioned for SDT, and if CFU can be activated, the system returns the provisioned dial tone.

The user enters the B-number (local, long distance, or international) where calls are to be forwarded.

The user receives an appropriate error announcement if the forward-to number is invalid or restricted, or if the feature cannot be activated.

If the feature can be activated to the forward-to number entered, the system returns a confirmation tone and attempts to place a courtesy call to the forward-to number (if provisioned for CC).

If the forwarded-to party answers the courtesy call (when CC is provisioned as ANS), or if CC is provisioned as NOANS, the CFU feature is activated.


Note When CC is provisioned for ANS, and if the forwarded-to line is busy or does not answer, the CFU feature is not activated. The user can still activate CFU by repeating the activation procedure within 2 minutes of the first attempt. No courtesy call is set up during the second attempt. The user hears a confirmation tone. If more than 2 minutes elapse before the second attempt, the second attempt is treated as a first attempt.


If FDT is provisioned, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone, indicating that activation was successful. If FDT is not provisioned, the user hears a success announcement.


Note FDT and CC are mutually exclusive—The system never provides FDT if a courtesy call is placed during the activation attempt (whether or not the courtesy call is answered). FDT is only provided, if provisioned, when a courtesy call is not involved.


CFU is now activated, and will stay active until it is deactivated with the appropriate deactivation VSC, or is overridden by the service provider via a CLI command.

CFU Deactivation (CFUD)

CFU can be deactivated by the service provider via a CLI command. Alternatively, CFU can be deactivated by the individual user as follows:


Note See the "CFUA Customization Options" section for details of the customized feature FDT.


The user lifts the handset and listens for dial tone.

The user presses the VSC applicable to CFU deactivation (for example, typically *73 in North America and #57# in China). The VSC values are provisionable by the service provider.

The user receives an appropriate error announcement if the feature cannot be deactivated.

If deactivation was successful, and if FDT is provisioned, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone. If FDT is not provisioned, the user hears a success announcement.

CFU is now deactivated, and will stay deactivated until it is activated with the appropriate activation VSC, or is overridden by the service provider via a CLI command.

CFU Interrogation (CFUI)

CFU interrogation allows a user to check whether CFU is activated to a particular phone. The user performs an interrogation as follows.


Note See the "CFUA Customization Options" section for details of customized features SDT and FDT.


The user lifts the handset and listens for dial tone.

The user presses the VSC applicable to CFU interrogation (for example, typically *#57* in China). The VSC values are provisionable by the service provider.

If provisioned for SDT, and if CFU can be interrogated, the system returns the provisioned dial tone. If not provisioned for SDT, no tones are provided.

The user enters the forward-to number to be interrogated (B-number).


Note The user can follow the B-number with a # to indicate the end of B-number entry.



Note If the user enters a digit string that does not match exactly the B-number against which CFU was activated, the interrogation attempt results in an error announcement.


The user receives an appropriate error announcement if the CFU feature is not forwarded to the B-number entered, or if the B-number is invalid.

If FDT is provisioned and the CFU feature is activated to the forward-to number entered, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone.

If FDT is not provisioned and the CFU feature is activated to the forward-to number entered, the system returns a success announcement.

CFU Invocation

CFU invocation is the actual procedure the system follows to forward the call.

Invalid User Actions

The following user actions are invalid, and the system provides an appropriate error announcement:

The user enters an invalid directory number (DN) for the B-number.

The user tries to activate CFU (with CC set to ANS) for the second time within a 2-minute interval to a DN which is different from the one used in the first attempt. (In addition, the history associated with the first attempt will be removed.)

During CFU activation, the user enters a B-number that is determined by the system to be a type blocked by provisioning in the NOD-RESTRICT-LIST table. For example, if the nature of dial (NOD) for the B-number is set to EMG (emergency), but calls with NOD=EMG are blocked by provisioning in the NOD-RESTRICT-LIST table, the activation to that B-number will be denied.

The user tries to activate CFU from a DN that has outgoing calls blocked by the OCB feature, or the user enters a B-number, but calls to that DN are blocked by OCB. For example, the call from the user's phone to the B-number would be a domestic long-distance call, but these calls are blocked by setting K=2 against the OCB feature in the SUBSCRIBER-FEATURE-DATA table.


Note The database tables (NOD-RESTRICT-LIST and SUBSCRIBER-FEATURE-DATA) mentioned in the above list are described in the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide. For information on billing records, see the Cisco BTS 10200 Softswitch Billing Reference Guide. For information on measurements, see the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.


The user tries to activate CFU from or to a DN for which calls are restricted by the COS feature.

The user tries to activate CFU when already activated (the B-number is not overwritten).

The user tries to activate CFU to an international DN, but the service provider has blocked forwarding to international DNs. The service provider can block forwarding to international DNs using the international flag in the FEATURE table.

The user tries to activate CFU to his or her own extension or DN.

The user tries to deactivate CFU when already deactivated.

The user interrogates CFU, but enters a digit string that does not match exactly the B-number against which CFU was activated. For example, if CFU was activated with a 5-digit string corresponding to a Centrex extension, and interrogation is attempted using a 10-digit string of the complete DN, the interrogation attempt will result in an error announcement. (See the complete list of standard Cisco BTS 10200 announcements in the Cisco BTS 10200 Softswitch Provisioning Guide.)

The user tries to interrogate CFU on a fresh system (a system with no entry in the SUBSCRIBER-FEATURE-DATA table). In this case, the user receives the error announcement immediately after entering the interrogation code (for example, *#57*). The system does not wait for the user to enter the B-number

CFU Feature Interactions

This section describes the interaction of other subscriber features with the CFU feature.

CLIP, CNAM, and CND (caller ID features)—When a call is forwarded, the forwarded-to party receives the DN of the calling party on the caller ID display.

OCB—The interaction of CFU and OCB depends upon the sequence in which they are activated:

If OCB is activated prior to CFU activation—OCB screening is performed on each DN the user enters when attempting to activate CFU. Successful CFU activation depends on the existing OCB K-VALUE and the forward-to DN:


Note If the existing OCB K-VALUE is set to block calls to the forward-to DN, then the system does not allow CFU activation. The user receives an error announcement.



Note If the OCB K-VALUE allows calls to this DN, then the CFU activation process continues. Once the CFU activation attempt to a specific DN is accepted by the system, it is applicable permanently regardless of any future OCB K-VALUE changes. That is, future changes to the OCB K-VALUE have no effect on CFU invocation. CFU to this DN can be deactivated by the user in the normal manner (#57#).


If CFU is activated prior to OCB activation—The user can activate the OCB feature, or change the OCB K-VALUE, regardless of the existing CFU feature. However, invocation of OCB depends upon the type of call:


Note User-dialed calls—User-dialed calls can be blocked by OCB (depending on the K-VALUE).



Note Forwarded calls—CFU remains active as originally set up by the user, therefore, calls forwarded by the CFU feature cannot be blocked using OCB screening.


COS—If a call to a DN is restricted by COS screening, CFU cannot be activated or invoked to that DN.

If a subscriber has CFU activated and the operator attempts to use the BLV or OI functions, the operator will receive a busy tone and will not be able to perform an interrupt on the call.

Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the CFU provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Call Forwarding Variable for Basic Business Group (CFVBBG)

This section describes the CFVBBG feature and its associated features—CFVABBG, CFUD, and CFUI.

CFVBBG Description

Call Forwarding Variable for Basic Business Group (CFVBBG) is the CFU variant for BBG subscribers with Centrex service. It has the same behavior as CFU, except that it uses CFVABBG as its associated activation feature. Associating CFVABBG causes different treatment of the courtesy call while activating CFVBBG.


Note The other associated features for CFVBBG are CFUD and CFUI. These associated features behave the same as described in the "CFU Deactivation (CFUD)" and "CFU Interrogation (CFUI)" sections.



Note CFUA is not an allowed associated feature for CFVBBG.


The following limitations and behaviors apply to CFVBBG:

CFVBBG can be provided to Centrex and MLHG subscribers only.

All feature interactions for CFVBBG are the same as for CFU.

CFVBBG logs the billing record as a CFU record.

CFVBBG generates measurements as CFU measurements.

CFVBBG Activation—CFVABBG

The system provides a BBG feature variant of CFUA called CFVABBG. For BBG subscribers, it is not recommended to deliver a courtesy call to a forwarded-to extension of another internal BBG line while activating forwarding. Other mechanics of operation of this feature are the same for CFVABBG as for CFUA, except that the courtesy call (CC) flag is always turned off.

The following limitations and behaviors apply to CFVABBG.


Note See the "CFUA Customization Options" section for details of the CC flag.


CFVABBG can only be assigned to Centrex (BBG) subscribers.

For typical business group call forwarding treatment, it is recommended to set the CC flag to N. In this case, CFVABBG implements the following courtesy call treatment during activation:

When activated to an extension, no courtesy call is placed.

When activated to an outside line, a courtesy call is placed. If the forwarded-to party answers the courtesy call, the feature is activated.


Note If the forwarded-to line is busy or does not answer, the feature is not activated. The user can still activate CFVBBG by repeating the activation procedure within 2 minutes of the first attempt. No courtesy call is set up during the second attempt. The user hears a confirmation tone. If more than 2 minutes elapse before the second attempt, the second attempt is treated as a first attempt.


CFVABBG uses the NOD-RESTRICT-LIST entry for CFU.

Activating CFVBBG will create a record in the SUBSCRIBER-FEATURE-DATA table with FNAME as CFU.

All feature interactions for CFVABBG are the same as for CFUA.

CFVABBG logs the billing record as a CFUA record.

CFVABBG generates measurements as CFUA measurements.


Note The database tables (NOD-RESTRICT-LIST and SUBSCRIBER-FEATURE-DATA) mentioned in the above list are described in the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide. For information on billing records, see the Cisco BTS 10200 Softswitch Billing Reference Guide. For information on measurements, see the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.


Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the CFVBBG provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Remote Activation of Call Forwarding (RACF)

Remote activation of call forwarding (RACF) permits user s to control their CFU functions when they are away from the phone. The service provider sets up this function for the user, and designates a DN the user should call to access interactive voice response (IVR) functions that control the RACF feature. Once the RACF function is set up, the user can take the following actions from a remote station:

Activate CFU

Deactivate CFU

Change the target DN of CFU

The procedure is similar to making call-forwarding changes at a home or local business phone, but requires the additional step of dialing the remote location:

The user dials a remote-access DN and is prompted to enter the directory number of the home or local business phone and then the RACF authorization code (a personal identification code, PIN). The PIN can be shared by a group, or can be unique to the individual subscriber.


Note A shared (nonunique) PIN is usually assigned to the subscriber group by the service provider. It can be changed only by the service provider, and not through handset provisioning.


Upon successful validation of the PIN, the user's current CFU activation status is checked.

If the CFU feature is currently inactive (calls are not being forwarded), the user is prompted to enter a DN to which calls should be forwarded.

If the CFU feature is currently active (calls are being forwarded), the user is given the option of deactivating CFU or changing the DN to which call should be forwarded.


Note When the user accesses the RACF function, and enters (or changes) the DN to which calls are forwarded, the system checks the validity of the forwarded number.


A subscriber with a unique PIN can change the PIN using the VSC function. (A specific VSC, for example *98, is assigned and provisioned by the service provider.) The PIN can only be changed from the base phone.


Tip For more details about the IVR interactions for this feature, see Chapter 6, "Interactive Voice Response Functions."



Tip To provision this feature, see the RACF provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Remote Call Forwarding (RCF)

The Cisco BTS 10200 Softswitch implements the remote call forwarding (RCF) feature as specified in LSSGR module FSD 01-02-1450 (GR-586), Call Forwarding Subfeatures.

RCF allows all incoming calls to be routed automatically to a remote DN, which can be in another region (NANP area for North America). RCF is activated by the service provider at customer request. With the RCF feature, all calls to the specified DN are always forwarded to a remote address. This service is similar to the CFU service with these exceptions:

Forwarding is always activated and not controlled by the customer. (The forwarded-to number cannot be changed by direct customer action.)

No local office terminal (physical telephone) is associated with the dialed number from which forwarding occurs.

Multiple simultaneous calls can be active between the base switching office and the remote RCF terminal.

The billing data produced by the Cisco BTS 10200 Softswitch identifies the invoked feature as CFU and not RCF. The calling party is charged for the call to the RCF DN. The called party (RCF DN) can be charged for the CFU feature usage. The service provider can also charge the called party (RCF DN) for the call from the RCF base DN to the remote DN.


Tip To provision this feature, see the RCF provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Call Forwarding Busy (CFB)

The Cisco BTS 10200 Softswitch provides the call forwarding busy (CFB) feature. CFB allows a user (the called party) to instruct the network to forward calls when the line is busy or unreachable. A typical forwarding number is voice mail. The forwarding station is off hook when the CFB feature is executed, therefore no reminder ring is generated. CFB is set up by the service provider at the subscriber's request.


Note A specific trigger, T_NOT_REACHABLE, must be provisioned for the CFB feature to enable the call forwarding on unreachable condition.


Reference documents include:

LSSGR module FSD 01-02-1401 (GR-580), Call Forwarding Variable

LSSGR Module FSD 01-02-1450 (GR-586), Call Forwarding Subfeatures

ITU-T Q-732.2

ITU I-252.4

The service provider can provision the CFB feature to be active immediately on the customer line, or to be activated by the individual subscriber using the handset. The user activates the CFB feature on the local phone, and enters the forward-to phone number where the user wishes to have the calls forwarded. This forward-to DN is referred to as the B-number. The allowed types of B-numbers are listed in Table 3-3.

Table 3-3 Allowed Types of B-numbers

Subscriber Type
Allowed B-number

POTS

DN, without extensions

Centrex

Public access code + external DN, without extensions

An extension within the business group


The following conditions apply to the CFB feature:

The CFB feature can be provided to POTS, Centrex, and MLHG subscribers.

The CFB feature is in the deactivated mode unless activated by the service provider or subscriber.

Call forwarding hop scenarios are restricted to a maximum of five hops. The call will be completed on the provisioned maximum number of hops.

Multiple call forwarding (MCF) is a provisionable option that allows multiple incoming calls to be forwarded by the subscriber at the same time. If a subscriber already has CFB invoked, additional calls to the subscriber will be forwarded by CFB based on the MCF flag. If the MCF flag is turned off, only one CFB invocation is allowed.

The CFB feature is composed of four associated features, which are described in the sections that follow:

CFB Variable Activation (CFBVA)

CFB Variable Deactivation (CFBVD)

CFB Interrogation (CFBI)

CFB Invocation

Additional information about this feature is covered in the following sections:

Invalid User Actions

CFB Feature Interactions

Feature Provisioning Commands

CFB Variable Activation (CFBVA)

This section discusses how the service provider can customize CFBVA, and the CFBVA procedures available to the handset user.

Blocking Call Forwarding to Certain Types of DNs

The service provider can block call forwarding to certain types of DNs by provisioning the nature of dial (NOD) parameter for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD Restrict List (nod-restrict-list) table. For example, if you provision NOD=TOLL-FREE and NOD=EMG in the nod-restrict-list table, the system will not allow call-forwarding to DNs of those types.


Caution If you want to block call-forwarding to an emergency (EMG) DN, such as 911, you must provision NOD=EMG for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD-RESTRICT-LIST. This is necessary to comply with the rule in Telcordia document GR-580, which says that 911 should not be a permitted "forward to" number.


Tip To provision the CFB feature, see the CFB provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


CFBVA Customization Options

The behavior of CFBVA can be customized using the following provisionable options. The detailed provisioning steps for these options are provided in the Cisco BTS 10200 Softswitch Provisioning Guide.

Courtesy call (CC)—The CC flag controls the delivery of a courtesy call while activating CFB. Although this option can be provisioned, as a practical matter it usually is not provided with CFB service in most markets.

Second stage dial tone (SDT)—The SDT flag controls the delivery of a dial tone after the subscriber enters the VSC for activation or interrogation of CFB. The permitted values for this flag are:

NO_TONE

DIAL_TONE

STUTTER_DIAL_TONE

CONFIRMATION_TONE

CONFIRMATION_DIAL_TONE


Note For SIP phone subscribers, the SDT parameter has no effect. The SDT option is available through the dial plan in the SIP phone.


Final stage dial tone (FDT)—The FDT flag controls the system response to a successful activation, deactivation, or interrogation of CFB by the subscriber. If FDT is not provisioned, the system provides a success announcement. The permitted values for this flag are the same as for the SDT flag.


Note For SIP phone subscribers, only the success announcements will be provided. The confirmation tone and dial tone will not be provided, even if the FDT flag is set.


Multiple call forwarding (MCF)—When provisioned as Y, MCF allows multiple incoming calls to be forwarded by the subscriber at the same time. If a subscriber already has CFB invoked, additional calls to the subscriber will be forwarded by CFB based on the MCF flag. If the MCF flag is set to N, only one CFB invocation is allowed.

International call forwarding (INTL)—When the INTL flag is set to N, forwarding to an international number is not allowed. When INTL is set to Y, the system checks for other restrictions on international calls, and allows forwarding if there are no other restrictions provisioned for the call type and calling number. (Other provisionable restrictions on international calling can be based on the nature of dial (NOD) and the subscriber feature data.)

Detailed information on how to set these parameters is provided in the following documents:

The "Valid Features" appendix in the Cisco BTS 10200 Softswitch Command Line Interface Guide for Call Processing lists all of the TYPE/VALUE pairs that are valid for each feature, including FDT, SDT, CC, and so forth.

The "Feature Profile Base" section in the "Valid Features" appendix of the Cisco BTS 10200 Softswitch Command Line Interface Guide for Call Processing provides descriptions of the TYPE/VALUE pairs.

The CFU provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide lists the provisioning commands to use with these parameters.

CFBVA Handset Procedures

CFB can be activated by the service provider or by the individual user. The procedures are as follows:

CFB can be activated permanently at subscription time by the service provider. The service provider provisions the forward-to DN as requested by the subscriber. When the phone is off hook, calls made to the subscriber's line will be forwarded to the single forward-to number that was provisioned.

CFB can be activated by the user as follows.


Note See the "CFBVA Customization Options" section for details of customized features CC, SDT, and FDT.


The user lifts the handset and listens for dial tone.

The user presses the VSC applicable to CFB activation (for example, typically *90 in North America and *40* in China). The VSC values are provisionable by the service provider.

If provisioned for SDT, and if CFB can be activated, the system returns the provisioned dial tone.

The user enters the B-number (local, long distance, or international) where calls are to be forwarded.


Note Centrex subscribers can specify a second forwarding number for in-group calls, but they cannot program this forwarding number via handset. The service provider sets this up at the Centrex subscriber's request.


The user receives an appropriate error announcement if the forward-to number is invalid or restricted, or if the feature cannot be activated.

If FDT is provisioned, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone, indicating that activation was successful. If FDT is not provisioned, the user hears a success announcement.

CFB is now activated, and will stay active until it is deactivated with the appropriate deactivation VSC, or is overridden by the service provider via a CLI command.

CFB Variable Deactivation (CFBVD)

CFB can be deactivated by the service provider. via a CLI command. Alternatively, CFB can be deactivated by user as follows.


Note See the "CFBVA Customization Options" section for details of the customized feature FDT.


The user lifts the handset and listens for dial tone.

The user presses the VSC applicable to CFB deactivation (for example, typically *91 in North America and #40# in China). The VSC values are provisionable by the service provider.

The user receives an appropriate error announcement if the feature cannot be deactivated.

If deactivation was successful, and if FDT is provisioned, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone. If FDT is not provisioned, the user hears a success announcement.

CFB is now deactivated, and will stay deactivated until it is activated with the appropriate activation VSC or is overridden by the service provider via a CLI command.

After deactivation, the incoming calls are not forwarded and are completed on the user's phone. If the user has subscribed to and activated call waiting (CW), the system provides the CW tone, and further CW procedures will apply.

CFB Interrogation (CFBI)

CFB interrogation allows a user to check whether CFB is activated to a particular phone. The user performs an interrogation as follows.


Note See the "CFBVA Customization Options" section for details of customized features SDT and FDT.


The user lifts the handset and listens for dial tone.

The user presses the VSC applicable to CFB interrogation (for example, typically *#40* in China). The VSC values are provisionable by the service provider.

If provisioned for SDT, and if CFB can be interrogated, the system returns the provisioned dial tone. If not provisioned for SDT, no tones are provided.

The user enters the forward-to number to be interrogated (B-number).


Note The user can follow the B-number with a # to indicate the end of B-number entry.



Note If the user enters a digit string that does not match exactly the B-number against which CFB was activated, the interrogation attempt will result in an error announcement.


The user receives an appropriate error announcement if the CFB feature is not forwarded to the B-number entered, or if the B-number is invalid.

If FDT is provisioned and the CFB feature is activated to the forward-to number entered, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone.

If FDT is not provisioned and the CFB feature is activated to the forward-to number entered, the system returns a success announcement.

CFB Invocation

CFB invocation is the actual procedure the system follows to forward the call.

Invalid User Actions

The following user actions are invalid, and the system provides an appropriate error announcement:

The user enters an invalid directory number (DN) for the B-number.

During CFB activation, the user enters a B-number that is determined by the system to be a type blocked by provisioning in the NOD-RESTRICT-LIST table. For example, if the nature of dial (NOD) for the B-number is set to EMG (emergency), but calls with NOD=EMG are blocked by provisioning in the NOD-RESTRICT-LIST table, the activation to that B-number will be denied.

The user tries to activate CFB from a DN that has outgoing calls blocked by the OCB feature, or the user enters a B-number, but calls to that DN are blocked by OCB. For example, the call from the user's phone to the B-number would be a domestic long-distance call, but these calls are blocked by setting K=2 against the OCB feature in the SUBSCRIBER-FEATURE-DATA table.


Note The database tables (NOD-RESTRICT-LIST and SUBSCRIBER-FEATURE-DATA) mentioned in the above list are described in the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide. For information on billing records, see the Cisco BTS 10200 Softswitch Billing Reference Guide. For information on measurements, see the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.


The user tries to activate CFB from or to a DN for which calls are restricted by the COS feature.

The user tries to activate CFB when already activated (the B-number is not overwritten).

The user tries to activate CFB to an international DN, but the service provider has blocked forwarding to international DNs. The service provider can block forwarding to international DNs using the international flag in the FEATURE table.

The user tries to activate CFB to his or her own extension or DN.

The user tries to deactivate CFB when already deactivated.

The user interrogates CFB, but enters a digit string that does not match exactly the B-number against which CFB was activated. For example, if CFB was activated with a 5-digit string corresponding to a Centrex extension, and interrogation is attempted using a 10-digit string of the complete DN, the interrogation attempt will result in the applicable announcement. (See the complete list of standard Cisco BTS 10200 announcements in the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.)

The user tries to interrogate CFB on a fresh system (a system with no entry in the SUBSCRIBER-FEATURE-DATA table). In this case, the user receives the error announcement immediately after entering *#40*. The system does not wait for the user to enter the B-number.

CFB Feature Interactions

This section describes the interaction of other subscriber features with the CFB feature.

CLIP, CNAM, and CND (caller ID features)—When a call is forwarded, the forwarded-to party receives the DN of the calling party on the caller ID display.

OCB—The interaction of CFB and OCB depends upon the sequence in which they are activated:

If OCB is activated prior to CFB activation—OCB screening is performed on each DN the user enters when attempting to activate CFB. Successful CFB activation depends on the existing OCB K-VALUE and the forward-to DN:


Note If the existing OCB K-VALUE is set to block calls to the forward-to DN, then the system does not allow CFB activation. The user receives an error announcement.



Note If the OCB K-VALUE allows calls to this DN, then the CFB activation process continues. Once the CFB activation attempt to a specific DN is accepted by the system, it is applicable permanently regardless of any future OCB K-VALUE changes. That is, future changes to the OCB K-VALUE have no effect on CFB invocation. CFB to this DN can be deactivated by the user in the normal manner (#40#).


If CFB is activated prior to OCB activation—The user can activate the OCB feature, or change the OCB K-VALUE, regardless of the existing CFB feature. However, invocation of OCB depends upon the type of call:


Note User-dialed calls—User-dialed calls can be blocked by OCB (depending on the K-VALUE).



Note Forwarded calls—CFB remains active as originally set up by the user, therefore, calls forwarded by the CFB feature cannot be blocked using OCB screening.


CW (or CWD)—If both CFB and CW (or CWD) are subscribed to and activated by the user, CW (or CWD) takes precedence. An incoming call to a user already on a call with CW (or CWD) activated will be given the CW (or CWD) tone, and further CW (or CWD) procedures will be applied. The following additional conditions apply:

If a user with CW (or CWD) is already involved in a call, the next incoming call is not forwarded. However, any additional incoming calls will be forwarded.

If a user with CW (or CWD) has gone off hook but has not yet completed a call or the call is in a ringing state, and there is an incoming call, the call will be forwarded.

COS—If a call to a DN is restricted by COS screening, CFB cannot be activated or invoked to that DN.

AR—If Automatic Recall (AR) is used to call a subscriber with CFB feature, the call is not forwarded when the CFB subscriber is off-hook. Instead, the calling subscriber hears the announcement "The user you are calling is busy. The system will check the line for the next 30 minutes, and then you will be notified". Therefore, CFB feature is not activated when AR is used to call an off-hook CFB subscriber.

For example, consider a situation where Subscriber A uses the AR feature to call Subscriber B, who has the CFB feature activated to forward all calls to C.

Subscriber B is now off-hook, and Subscriber A calls Subscriber B using AR. Here, A's call is not forwarded to C. Instead, Subscriber A hears an announcement informing that Subscriber B is busy.

Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the CFB provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Call Forwarding No Answer (CFNA)

The BTS 10200 provides the call forwarding no answer (CFNA) feature. CFNA allows a user (the called party) to instruct the network to forward incoming calls that are not answered within a specified number of rings. (Five rings is the default setting, but number of rings is configurable.) A typical forwarding number is voice mail. This service can be used with either rotary or dual tone multifrequency (DTMF) equipped customer premises equipment (CPE).


Note The service provider can provision a parameter that determines the timeout (and thus the number of 6-second rings) before a call is forwarded. The timeout can be set at the feature level (in the Feature table) and at the subscriber level (in the Subscriber Feature Data table), and the setting for the subscriber takes precedence over the setting at the feature level.


The CFNA feature affects the called party in specific ways, depending upon whether the called party phone is on hook or off hook when the call comes in:

If the forwarding phone is on hook when a call comes in, the phone will ring in the normal manner, and then the call will be forwarded when the CFNA timer runs out.

If the forwarding phone is off hook when the call comes in, no reminder ring is generated. However, if the user has subscribed to and activated CW (or CWD), the CW (or CWD) treatment will be given first, and then the call will be forwarded after the CFNA timer runs out. The forwarding station is ringing when the CFNA feature is executed, therefore no reminder ring is generated.

Reference documents include:

LSSGR module FSD 01-02-1401 (GR-580), Call Forwarding Variable

LSSGR Module FSD 01-02-1450 (GR-586), Call Forwarding Subfeatures

LSSGR module FSD 01-02-2200 (GR-1520), Ring Control

ITU-T Q-732.2

ITU I-252.4

The service provider can provision the CFNA feature to be active immediately on the customer line, or to be activated by the individual subscriber using the handset. The user activates the CFNA feature on the local phone, and enters the forward-to phone number where the user wishes to have the calls forwarded. This forward-to DN is referred to as the B-number. The allowed types of B-numbers are listed in Table 3-4.

Table 3-4 Allowed Types of B-numbers

Subscriber Type
Allowed B-number

POTS

DN, without extensions

Centrex

Public access code + external DN, without extensions

An extension within the business group


The following conditions apply to the CFNA feature:

The CFNA feature can be provided to POTS, Centrex, and MLHG subscribers.

The CFNA feature is in the deactivated mode unless activated by the service provider or subscriber.

Call forwarding hop scenarios are restricted to a maximum of five hops. The call will be completed on the provisioned maximum number of hops.

Multiple call forwarding (MCF) is a provisionable option that allows multiple incoming calls to be forwarded by the subscriber at the same time. If a subscriber already has CFNA invoked, additional calls to the subscriber will be forwarded by CFNA based on the MCF flag. If the MCF flag is turned off, only one CFNA invocation is allowed.

The CFNA feature is composed of four associated features, which are described in the sections that follow:

CFNA Variable Activation (CFNAVA)

CFNA Variable Deactivation (CFNAVD)

CFNA Interrogation (CFNAI)

CFNA Invocation

Additional information about this feature is covered in the following sections:

Invalid User Actions

CFNA Feature Interactions

Feature Provisioning Commands

CFNA Variable Activation (CFNAVA)

This section discusses how the service provider can customize CFNAVA, and the CFNAVA procedures available to the handset user.

Blocking Call Forwarding to Certain Types of DNs

The service provider can block call forwarding to certain types of DNs by provisioning the nature of dial (NOD) parameter for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD Restrict List (nod-restrict-list) table. For example, if you provision NOD=TOLL-FREE and NOD=EMG in the nod-restrict-list table, the system will not allow call-forwarding to DNs of those types.


Caution If you want to block call-forwarding to an emergency (EMG) DN, such as 911, you must provision NOD=EMG for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD-RESTRICT-LIST. This is necessary to comply with the rule in Telcordia document GR-580, which says that 911 should not be a permitted "forward to" number.


Tip To provision the CFNA feature, see the CFNA provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


CFNAVA Customization Options

The behavior of CFNAVA can be customized using the following provisionable options. The detailed provisioning steps for these options are provided in the Cisco BTS 10200 Softswitch Provisioning Guide.

Courtesy call (CC)—The CC flag controls the delivery of a courtesy call while activating CFNA. Although this option can be provisioned, as a practical matter it usually is not provided with CFNA service in most markets.

Second stage dial tone (SDT)—The SDT flag controls the delivery of a dial tone after the subscriber enters the VSC for activation or interrogation of CFNA. The permitted values for this flag are:

NO_TONE

DIAL_TONE

STUTTER_DIAL_TONE

CONFIRMATION_TONE

CONFIRMATION_DIAL_TONE


Note For SIP phone subscribers, the SDT parameter has no effect. The SDT option is available through the dial plan in the SIP phone.


Final stage dial tone (FDT)—The FDT flag controls the system response to a successful activation, deactivation or interrogation of CFNA by the subscriber. If FDT is not provisioned, the system provides a success announcement. The permitted values for this flag are the same as for the SDT flag.


Note For SIP phone subscribers, only the success announcements will be provided. The confirmation tone and dial tone will not be provided, even if the FDT flag is set.


Multiple call forwarding (MCF)—When provisioned as Y, MCF allows multiple incoming calls to be forwarded by the subscriber at the same time. If a subscriber already has CFNA invoked, additional calls to the subscriber will be forwarded by CFNA based on the MCF flag. If the MCF flag is set to N, only one CFNA invocation is allowed.

International call forwarding (INTL)—When the INTL flag is set to N, forwarding to an international number is not allowed. When INTL is set to Y, the system checks for other restrictions on international calls, and allows forwarding if there are no other restrictions provisioned for the call type and calling number. (Other provisionable restrictions on international calling can be based on the nature of dial (NOD) and the subscriber feature data.)

Detailed information on how to set these parameters is provided in the following documents:

Detailed information on how to set these parameters is provided in the following documents:

The "Valid Features" appendix in the Cisco BTS 10200 Softswitch Command Line Interface Guide for Call Processing lists all of the TYPE/VALUE pairs that are valid for each feature, including FDT, SDT, CC, and so forth.

The "Feature Profile Base" section in the "Valid Features" appendix of the Cisco BTS 10200 Softswitch Command Line Interface Guide for Call Processing provides descriptions of the TYPE/VALUE pairs.

The CFNA provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide lists the provisioning commands to use with these parameters.

CFNAVA Handset Procedures

CFNA can be activated by the service provider or by the individual user. The procedures are as follows:

CFNA can be activated permanently at subscription time by the service provider. The service provider provisions the forward-to DN as requested by the subscriber. When the phone is not answered, calls made to the subscriber's line will be forwarded to the single forward-to number that was provisioned.

CFNA can be activated by the user as follows.


Note See the "CFNAVA Customization Options" section for details of customized features CC, SDT, and FDT.


The user lifts the handset and listens for dial tone.

The user presses the VSC applicable to CFNA activation (for example, typically *92 in North America and *41* in China). The VSC values are provisionable by the service provider.

If provisioned for SDT, and if CFNA can be activated, the system returns the provisioned dial tone.

The user enters the B-number (local, long distance, or international) where calls are to be forwarded.


Note Centrex subscribers can specify a second forwarding number for in-group calls, but they cannot program this forwarding number via handset. The service provider sets this up at the Centrex subscriber's request.


The user receives an appropriate error announcement if the forward-to number is invalid or restricted, or if the feature cannot be activated.

If the feature can be activated to the forward-to number entered, the system returns a confirmation tone and attempts to place a courtesy call to the forward-to number (if provisioned for CC).

If the forwarded-to party answers the courtesy call (when CC is provisioned as ANS), or if CC is provisioned as NOANS, the CFNA feature is activated.


Note When CC is provisioned for ANS, and if the forwarded-to line is busy or does not answer, the CFNA feature is not activated. The user can still activate CFNA by repeating the activation procedure within 2 minutes of the first attempt. No courtesy call is set up during the second attempt. The user hears a confirmation tone. If more than 2 minutes elapse before the second attempt, the second attempt is treated as a first attempt.


If FDT is provisioned, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone, indicating that activation was successful. If FDT is not provisioned, the user hears a success announcement.

CFNA is now activated, and will stay active until it is deactivated using the appropriate deactivation VSC, or is overridden by the service provider via a CLI command.

CFNA Variable Deactivation (CFNAVD)

CFNA can be deactivated by the service provider via a CLI command. Alternatively, CFNA can be deactivated by the individual user as follows.


Note See the "CFNAVA Customization Options" section for details of the customized feature FDT.


The user lifts the handset and listens for dial tone.

The user presses the VSC applicable to CFNA deactivation (for example, typically *93 in North America and #41# in China). The VSC values are provisionable by the service provider.

The user receives an appropriate error announcement if the feature cannot be deactivated.

If deactivation was successful, and if FDT is provisioned, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone. If FDT is not provisioned, the user hears a success announcement.

CFNA is now deactivated, and will stay deactivated until it is activated using the appropriate activation VSC or is overridden by the service provider via a CLI command.

After deactivation, the incoming calls are not forwarded and are completed on the user's phone.

CFNA Interrogation (CFNAI)

CFNA interrogation allows a user to check whether CFNA is activated to a particular phone. The user performs an interrogation as follows.


Note See the "CFNAVA Customization Options" section for details of customized features SDT and FDT.


The user lifts the handset and listens for dial tone.

The user presses the VSC applicable to CFNA interrogation (for example, typically *#41* in China). The VSC values are provisionable by the service provider.

If provisioned for SDT, and if CFNA can be interrogated, the system returns a confirmation tone for one second and then the provisioned dial tone. If not provisioned for SDT, no tones are provided.

The user enters the forward-to number to be interrogated (B-number).


Note The user can follow the B-number with a # to indicate the end of B-number entry.



Note If the user enters a digit string that does not match exactly the B-number against which CFNA was activated, the interrogation attempt will result in an error announcement.


The user receives an appropriate error announcement if the CFNA feature is not forwarded to the B-number entered or if the B-number is invalid.

If FDT is provisioned and the CFNA feature is activated to the forward-to number entered, the user hears a confirmation tone for one second, followed by the provisioned dial tone.

If FDT is not provisioned and the CFNA feature is activated to the forward-to number entered, the system returns a success announcement.

CFNA Invocation

CFNA invocation is the actual procedure the system follows to forward the call.

Invalid User Actions

The following user actions are invalid, and the system provides an appropriate error announcement:

The user enters an invalid directory number (DN) for the B-number.

During CFNA activation, the user enters a B-number that is determined by the system to be a type blocked by provisioning in the NOD-RESTRICT-LIST table. For example, if the nature of dial (NOD) for the B-number is set to EMG (emergency), but calls with NOD=EMG are blocked by provisioning in the NOD-RESTRICT-LIST table, the activation to that B-number will be denied.

The user tries to activate CFNA from a DN that has outgoing calls blocked by the OCB feature, or the user enters a B-number, but calls to that DN are blocked by OCB. For example, the call from the user's phone to the B-number would be a domestic long-distance call, but these calls are blocked by setting K=2 against the OCB feature in the SUBSCRIBER-FEATURE-DATA table.


Note The database tables (NOD-RESTRICT-LIST and SUBSCRIBER-FEATURE-DATA) mentioned in the above list are described in the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide. For information on billing records, see the Cisco BTS 10200 Softswitch Billing Reference Guide. For information on measurements, see the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.


The user tries to activate CFNA from or to a DN for which calls are restricted by the COS feature.

The user tries to activate CFNA when already activated (the B-number is not overwritten).

The user tries to activate CFNA to an international DN, but the service provider has blocked forwarding to international DNs. The service provider can block forwarding to international DNs using the international flag in the FEATURE table.

The user tries to activate CFNA to his or her own extension or DN.

The user tries to deactivate CFNA when already deactivated.

The user interrogates CFNA, but enters a digit string that does not match exactly the B-number against which CFNA was activated. For example, if CFNA was activated with a 5-digit string corresponding to a Centrex extension, and interrogation is attempted using a 10-digit string of the complete DN, the interrogation attempt will result in the applicable announcement. (See the complete list of standard Cisco BTS 10200 announcements in the Cisco BTS 10200 Softswitch Provisioning Guide.)

The user tries to interrogate CFNA on a fresh system (a system with no entry in the SUBSCRIBER-FEATURE-DATA table). In this case, the user receives the error announcement immediately after entering *#41*. The system does not wait for the user to enter the B-number.

CFNA Feature Interactions

This section describes the interaction of other subscriber features with the CFNA feature.

CLIP, CNAM, and CND (caller ID features)—When a call is forwarded, the forwarded-to party receives the DN of the calling party on the caller ID display.

COS—If a call to a DN is restricted by COS screening, CFNA cannot be activated or invoked to that DN.

OCB—The interaction of CFNA and OCB depends upon the sequence in which they are activated:

If OCB is activated prior to CFNA activation—OCB screening is performed on each DN the user enters when attempting to activate CFNA. Successful CFNA activation depends on the existing OCB K-VALUE and the forward-to DN:


Note If the existing OCB K-VALUE is set to block calls to the forward-to DN, then the system does not allow CFNA activation. The user receives an error announcement.



Note If the OCB K-VALUE allows calls to this DN, then the CFNA activation process continues. Once the CFNA activation attempt to a specific DN is accepted by the system, it is applicable permanently regardless of any future OCB K-VALUE changes. That is, future changes to the OCB K-VALUE have no effect on CFNA invocation. CFNA to this DN can be deactivated by the user in the normal manner (#41#).


If CFNA is activated prior to OCB activation—The user can activate the OCB feature, or change the OCB K-VALUE, regardless of the existing CFNA feature. However, invocation of OCB depends upon the type of call:


Note User-dialed calls—User-dialed calls can be blocked by OCB (depending on the K-VALUE).



Note Forwarded calls—CFNA remains active as originally set up by the user, therefore, calls forwarded by the CFNA feature cannot be blocked using OCB screening.


There is an interaction when a Centrex subscriber has all three of the following features assigned and active:

1. Call hold—CHD.

2. Call waiting—CW or CIDCW or both.

3. Call forwarding on no answer—CFNA, VM (or VMA), or any combination of these.

For information on this interaction, see the "CHD with CW/CIDCW and CFNA/VM/VMA" section.

If CHD is assigned to the subscriber along with CFNA (CFNA active), the following interaction occurs.

A (the subscriber) and B are on an active call.

C calls A.

C hears a busy tone and is not connected. The call from C is not forwarded by the CFNA feature.

CW or CWD—If both CFNA and CW (or CWD) are subscribed to and activated by the user, the interaction is as follows. If the user is on an active call when a new call comes in, the CW (or CWD) tone will be played. If the user presses the Flash button or hookswitch before the CFNA timer runs out, the user will be connected to the new call, and the call will proceed according to the CW (or CWD) feature. If the user takes no action, and the CFNA timer runs out, the waiting call will be forwarded per the CFNA procedure.

Several provisionable parameters can affect the processing of this call.

The CW timeout is based on a switch-wide parameter, NO-ANSWER-TMR in the ca-config table (default 185 seconds). There is also a parameter, START-NO-ANSWER-TMR in the ca-config table, to specify whether NO-ANSWER-TMR is to be started or not; default is N.

The CFNA timeout is provisioned via the TYPE1=TO parameter in the Feature table (default 30 seconds).

If Subscriber A has the default timer settings (that is, CFNA TO=30 seconds and NO-ANSWER-TIMER=185 seconds), and has the START-NO-ANSWER-TMR parameter set to Y (not the default), the call is processed as follows:

[1] A calls B, B answers.

[2] C calls A, A hears the CW tone, C hears ring tone.

[3] If A does not attempt to answer the waiting call (C), and CFNA times out (30 seconds), C is forwarded according to normal CFNA procedures.

However, if the CFNA timeout (TO) is set to a value greater than NO-ANSWER-TMR, when NO-ANSWER-TMR expires, C is disconnected and hears a busy tone, and CFNA is cancelled.

Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the CFNA provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Call Forwarding Combination (CFC)

The system supports a set of vertical service codes (VSCs) to activate, deactivate, and interrogate Call Forwarding Combination (CFC). Once activated, CFC forwards incoming calls to the subscriber when the subscriber is either busy or does not answer. This feature combines the functionality of CFB and CFNA.

The forward-to DN is referred to as the B-number. The allowed types of B-numbers are listed in Table 3-5.

Table 3-5 Allowed Types of B-numbers

Subscriber Type
Allowed B-number

POTS

DN, without extensions

Centrex

Public access code + external DN, without extensions

An extension within the business group


The following conditions apply to the CFC feature:

The CFC feature can be provided to POTS, Centrex, and MLHG subscribers.

The CFC feature is in the deactivated mode unless activated by the service provider or subscriber.

Call forwarding hop scenarios are restricted to a maximum of five hops. The call will be completed on the provisioned maximum number of hops.

Multiple call forwarding (MCF) is a provisionable option that allows multiple incoming calls to be forwarded by the subscriber at the same time. If a subscriber already has CFC invoked, additional calls to the subscriber will be forwarded by CFC based on the MCF flag. If the MCF flag is turned off, only one CFC invocation is allowed.

Vertical Service Codes for CFC

The values of the VSCs are provisionable. Typical VSC examples for the CFC subfeatures are as follows:

*68—CFC_ACT (CFC Activation without change of forward-to DN)

*88—CFC_DEACT (CFC Deactivation)

*201—CFC_DN_CHG_ACT (CFC Activation with change of forward-to DN)

*202—CFCI_NO_DN_VRFY (CFC Interrogation without forward-to DN verification)

*203—CFCI (CFC Interrogation with forward-to DN verification)

Blocking Call Forwarding to Certain Types of DNs

The service provider can block call forwarding to certain types of DNs by provisioning the nature of dial (NOD) parameter for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD Restrict List (nod-restrict-list) table. For example, if you provision NOD=TOLL-FREE and NOD=EMG in the nod-restrict-list table, the system will not allow call-forwarding to DNs of those types.


Caution If you want to block call-forwarding to an emergency (EMG) DN, such as 911, you must provision NOD=EMG for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD-RESTRICT-LIST. This is necessary to comply with the rule in Telcordia document GR-580, which says that 911 should not be a permitted "forward to" number.

Detailed Feature Description

The CFC feature is composed of six associated features, which are described in the sections that follow:

CFC Activation (CFC_ACT)

CFC Deactivation (CFC_DEACT)

CFC Activation with Directory Number Change (CFC_DN_CHG_ACT)

CFC Interrogation with No Directory Number Verification (CFCI_NO_DN_VRFY)

CFC Interrogation (CFCI)

CFC Invocation (CFC)

Additional information about this feature is covered in the following sections:

Flags Applicable to CFC Activation and Deactivation Subfeatures

Invalid User Actions

CFC Feature Interactions

Feature Provisioning Commands

CFC Activation (CFC_ACT)

CFC activation allows the end user to activate CFC to a pre-defined DN (which was set up when provisioning the feature). However, the end user cannot change the DN via this feature.

To activate CFC, the subscriber dials the access code for activation. If the final dial tone parameter (FDT) is provisioned, the subscriber hears the provisioned dial tone if the feature is successfully activated. If the feature is not successfully activated, the subscriber hears a reorder tone, or an announcement, if the announcements are provisioned.

If the feature is already active, the subscriber hears a stutter dial tone confirming that the feature is active.

While activating CFC, the pre-defined DN is validated. To be valid, the DN must conform to the dial-plan provisioned in the Call Agent (CA).

Activating CFC has some limitations, including:

The subscriber cannot activate CFC if the pre-defined DN is the subscriber's own DN or extension.

The subscriber cannot activate CFC if the pre-defined DN is blocked by Outgoing Call Barring (OCB).

The subscriber cannot activate CFC if the pre-defined DN has a call-type which is blocked by the CFC nod-restrict-list. Where applicable, all CFC features treat the nod-restrict list as a black list.

The pre-defined DN can be a speed code. However, to be valid, the translated DN must conform to the dial-plan provisioned in the CA.

For CENTREX subscribers, the pre-defined DN can be an extension or a PAC followed by a DN.

CFC Deactivation (CFC_DEACT)

CFC deactivation allows the end user to deactivate the CFC feature. However, even if the feature is deactivated, the forwarding DN for the subscriber is preserved.

To deactivate CFC, the subscriber dials the access code for deactivation. If the FDT parameter is provisioned, the subscriber hears the provisioned dial tone if the feature is successfully deactivated. If the feature is not successfully deactivated, the subscriber hears a reorder tone or an announcement, if announcements are provisioned.

If the feature is already inactive, the subscriber hears a stutter dial tone confirming that the feature is inactive.

For CFC deactivation, the DN validity is not checked. The feature simply deactivates CFC without any checks.

CFC Activation with Directory Number Change (CFC_DN_CHG_ACT)

CFC with directory number change enables the subscriber to activate CFC to a user-defined remote DN, and the end user can change the DN via this feature.

To activate this feature, the subscriber begins by dialing an access code for activation. If the second dial tone parameter (SDT) is provisioned, the subscriber hears the provisioned dial tone, and enters the Forwarding DN. If the FDT parameter is provisioned, the subscriber hears the provisioned dial tone if the feature is successfully activated. If the feature is not successfully activated, the subscriber hears a reorder tone or an announcement, if announcements are provisioned.

If the feature is already active, the subscriber hears a stutter dial tone confirming that the feature is active.

While activating the feature, the user-defined DN is checked for validity. To be valid, the DN must conform to the dial-plan provisioned in the CA.

Activating CFC with Directory Number Change has some limitations, including:

The subscriber cannot activate CFC if the user-defined DN is the subscriber's own DN or extension.

The subscriber cannot activate CFC is the user-defined DN is blocked by OCB.

The subscriber cannot activate CFC is the user-defined DN has a call-type which is blocked by the CFC nod-restrict-list. Where applicable, all CFC features treat the nod-restrict list as a black list.

The user-defined DN can be a speed code. However, to be valid, the translated DN should conform to the dial-plan provisioned in the CA. The feature stores the translated DN as the forwarding number in the database.

For CENTREX subscribers, the pre-defined DN can be an extension or a PAC followed by a DN. If CFC is activated with an extension, the feature stores that extension as the forwarding number in the database.

CFC Interrogation with No Directory Number Verification (CFCI_NO_DN_VRFY)

CFC Interrogation with no directory number verification enables the subscriber to verify (or interrogate) whether CFC is active on the subscriber's line or not.

To use the feature, the subscriber dials a star code. If the FDT parameter is provisioned and CFC is active, the subscriber hears the provisioned dial tone. If CFC is not active, the subscriber hears a reorder tone or an announcement, if announcements are provisioned.

CFC Interrogation (CFCI)

CFC interrogation enables the subscriber to verify (or interrogate) whether CFC is active on the subscriber's line to a certain DN or not.

To use the feature, the subscriber dials the access code for interrogation. If the SDT parameter is provisioned, the subscriber hears the provisioned dial tone, and enters the DN against which to perform the verification. If the FDT parameter is provisioned, and if CFC is active to that DN, the subscriber hears the provisioned dial tone. If CFC is not active, or active to a different DN, the subscriber hears a reorder tone or an announcement, if announcements are provisioned.

The verification is done against the exact DN stored in the database for CFC. The feature does not translate or do any conversion before comparing the numbers (like extension to a DN, or adding a country code if the number is not fully specified by the user, or converting from a speed code to a DN).

CFC Invocation (CFC)

The CFC invocation feature forwards a call coming to the subscriber when the subscriber is either busy or does not answer. CFC checks the nod-restrict-list check for call-types blocked on CFC. Provision the nod-restrict-list with the same fname as CFC.

CFC is considered deactivated unless explicitly activated by the subscriber.

The following flags are provisionable in the feature table, and affect the forwarding behavior of CFC:

Multiple call forwarding (MCF)—Setting the MCF flag to Y (Yes) allows multiple calls to be forwarded at the same time. Setting the MCF flag to N (No) allows the subscriber to have only one busy or one no-answer call forwarded at a time.

Timeout (TO)—The TO flag is used for the no-answer timeout for CFC. The default value is 30 seconds.

Flags Applicable to CFC Activation and Deactivation Subfeatures

There are three optional TYPE-VALUE pairs to configure for CFC subfeatures in the feature table. The TYPE-VALUE pairs correspond to the SDT, FDT and CC flags. This section describes the feature behavior based on these flags.

Table 3-6 shows which flags are applicable to each feature, and lists the default values for the flags.

Table 3-6 Flags for CFC Activation and Deactivation Subfeatures

Feature
Flag
Default Value(s)

CFC_DN_CHG_ACT

Note The INTL flag is also applicable to this feature (default N).

SDT

DIAL_TONE

FDT

STUTTER_DIAL_TONE

CC

N

CFC_DEACT

SDT

Feature does not need the flag when executed.

FDT

STUTTER_DIAL_TONE

CC

Feature does not need the flag when executed.

CFC_ACT

SDT

Feature does not need the flag when executed.

FDT

STUTTER_DIAL_TONE

CC

Feature does not need the flag when executed.

CFCI_NO_DN_VRFY

SDT

Feature does not need the flag when executed.

FDT

STUTTER_DIAL_TONE

CC

Feature does not need the flag when executed.

CFCI

SDT

DIAL_TONE

FDT

STUTTER_DIAL_TONE

CC

Feature does not need the flag when executed.


TYPE-VALUE Pair 1—SDT

The first TYPE-VALUE pair for the second dial tone (SDT) is:

TYPEn=SDT;
VALUEn=[NO_TONE|DIAL_TONE|STUTTER_DIAL_TONE|CONFIRMATION_TONE|CONFIRMATION_DIAL_TONE]

If provisioned, this pair specify the tone to play just after the subscriber dials the VSC.

The following tones play based on the values set:

If the VALUE is set to NO_TONE, no tones play.

If VALUE is set to DIAL_TONE, the dial tone plays.

If VALUE is set to STUTTER_DIAL_TONE, a stutter dial tone plays.

If the VALUE is set to CONFIRMATION_DIAL_TONE, a confirmation, followed by the dial tone, plays.

If the VALUE is set to CONFIRMATION_TONE, a confirmation tone is played.


Note For SIP phone subscribers, the SDT parameter has no effect. The SDT option is available through the dial plan in the SIP phone.


TYPE-VALUE Pair 2—FDT

The second TYPE-VALUE pair for final dial tone (FDT) is:

TYPEn=FDT;
VALUEn=[NO_TONE|DIAL_TONE|STUTTER_DIAL_TONE|CONFIRMATION_TONE|CONFIRMATION_DIAL_TONE]

If provisioned, the pair dictates what tone to play after the subscriber successfully activates or deactivates the feature.

The following tones play based on the values set:

If the VALUE is set to NO_TONE and if the announcement server is provisioned, an announcement plays.

If VALUE is set to DIAL_TONE, a dial tone plays.

If VALUE is set to STUTTER_DIAL_TONE, a stutter dial tone plays.

If the VALUE is set to CONFIRMATION_DIAL_TONE, a confirmation, followed by the dial tone, plays.

If the VALUE is set to CONFIRMATION_TONE, a confirmation tone is played.


Note For SIP phone subscribers, only the success announcements will be provided. The confirmation tone and dial tone will not be provided, even if the FDT flag is set.


TYPE-VALUE Pair 3—CC

The third TYPE-VALUE pair is:

TYPEn=CC;
VALUEn=[ANS|NOANS|N]

If provisioned, the pair above dictates the feature behavior after the subscriber successfully activates the CFC_DN_CHG_ACT feature.


Note This flag is applicable to only this feature.


The feature behaviors depend on the following values:

If the VALUE is set to ANS, a courtesy call is placed to a forwarding number entered by the user; CFC is activated to that number only when the remote party answers the call. If the remote party does not answer, or if the subscriber hangs up, the subscriber has two minutes to dial the CFC_DN_CHG_ACT access code, followed by the same number, to force CFC activation to that number. At this point, no courtesy call is placed to the number, and CFC is activated.

If the value is set to NOANS, a courtesy call is placed to the forwarding number entered by the user, but the remote party need not answer the call to activate CFC. CFC is activated whether the courtesy call is successful, or whether the remote party answered.

If the VALUE is set to N, no courtesy call is placed when the subscriber successfully activates CFC_DN_CHG_ACT. Instead, the feature looks up the FDT flag for the appropriate treatment.

Additional Provisioning Details

To view a list of these feature options for CFC in the Cisco BTS 10200 Softswitch CLI Database, use the show feature-profile-base fname=cfc CLI command.To provision the CFU feature, see t he CFC provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.

Invalid User Actions

The following user actions are invalid, and the system provides an appropriate error announcement:

The user enters an invalid directory number (DN) for the B-number.

The user tries to activate CFC (with CC set to ANS) for the second time within a 2-minute interval to a DN which is different from the one used in the first attempt. (In addition, the history associated with the first attempt will be removed.)

During CFC activation, the user enters a B-number that is determined by the system to be a type blocked by provisioning in the NOD-RESTRICT-LIST table. For example, if the nature of dial (NOD) for the B-number is set to EMG (emergency), but calls with NOD=EMG are blocked by provisioning in the NOD-RESTRICT-LIST table, the activation to that B-number will be denied.

The user tries to activate CFC from a DN that has outgoing calls blocked by the OCB feature, or the user enters a B-number, but calls to that DN are blocked by OCB. For example, the call from the user's phone to the B-number would be a domestic long-distance call, but these calls are blocked by setting K=2 against the OCB feature in the SUBSCRIBER-FEATURE-DATA table.


Note The database tables (NOD-RESTRICT-LIST and SUBSCRIBER-FEATURE-DATA) mentioned in the above list are described in the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide. For information on billing records, see the Cisco BTS 10200 Softswitch Billing Reference Guide. For information on measurements, see the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.


The user tries to activate CFC from or to a DN for which calls are restricted by the COS feature.

The user tries to activate CFC when already activated (the B-number is not overwritten).

The user tries to activate CFC to an international DN, but the service provider has blocked forwarding to international DNs. The service provider can block forwarding to international DNs using the international flag in the FEATURE table.

The user tries to activate CFC to his or her own extension or DN.

The user tries to deactivate CFC when already deactivated.

The user interrogates CFC, but enters a digit string that does not match exactly the B-number against which CFC was activated. For example, if CFC was activated with a 5-digit string corresponding to a Centrex extension, and interrogation is attempted using a 10-digit string of the complete DN, the interrogation attempt will result in an error announcement. (See the complete list of standard Cisco BTS 10200 announcements in the Cisco BTS 10200 Softswitch Provisioning Guide.)

The user tries to interrogate CFC on a fresh system (a system with no entry in the SUBSCRIBER-FEATURE-DATA table). In this case, the user receives the error announcement immediately after entering the interrogation code (for example, *68). The system does not wait for the user to enter the B-number

CFC Feature Interactions

This section describes the interaction of other subscriber features with the CFC feature.

CLIP, CNAM, and CND (caller ID features)—When a call is forwarded, the forwarded-to party receives the DN of the calling party on the caller ID display.

OCB—The interaction of CFC and OCB depends upon the sequence in which they are activated:

If OCB is activated prior to CFC activation—OCB screening is performed on each DN the user enters when attempting to activate CFC. Successful CFC activation depends on the existing OCB K-VALUE and the forward-to DN:


Note If the existing OCB K-VALUE is set to block calls to the forward-to DN, then the system does not allow CFC activation. The user receives an error announcement.



Note If the OCB K-VALUE allows calls to this DN, then the CFC activation process continues. Once the CFC activation attempt to a specific DN is accepted by the system, it is applicable permanently regardless of any future OCB K-VALUE changes. That is, future changes to the OCB K-VALUE have no effect on CFC invocation. CFC to this DN can be deactivated by the user in the normal manner (#57#).


If CFC is activated prior to OCB activation—The user can activate the OCB feature, or change the OCB K-VALUE, regardless of the existing CFC feature. However, invocation of OCB depends upon the type of call:


Note User-dialed calls—User-dialed calls can be blocked by OCB (depending on the K-VALUE).



Note Forwarded calls—CFC remains active as originally set up by the user, therefore, calls forwarded by the CFC feature cannot be blocked using OCB screening.


CFC_ACT and COS: If a call to a DN is restricted by COS screening, CFC cannot be activated or invoked to that DN.

CFC Activation/Deactivation and Speed Call/Abbreviated Dial: Subscribers can set their speed call to the CFC Activation/Deactivation access codes. For example, with One-Digit Speed Call, the subscriber can set the speed call for digit "2" to map to "*68" which can be the CFC Activation access code.

CFC Activation and OCB: CFC Activation to a DN blocked by outgoing call barring (OCB) results in a re-order tone or announcement.

CFC Activation with DN Change and OCB: CFC Activation with DN Change to a DN blocked by OCB results in a re-order tone or announcement.

CFC and OCB: Calls are not forwarded by CFC to DNs blocked by OCB for the subscriber.

CFC and CFU: If a subscriber has both CFC and call forwarding unconditional (CFU) assigned and active, incoming calls are forwarded by CFU.

CFC and CFB: If a subscriber has both CFC and CFB assigned and active, incoming calls on which the subscriber is busy are forwarded by CFB.

CFC and CFB, CFB is deactivated: If a subscriber has both CFC and CFB assigned, and CFC active and CFB inactive, incoming calls on which the subscriber is busy are forwarded by CFC.

CFC and CFNA: If a subscriber has both CFC and CFNA assigned and active, incoming calls on which the subscriber does not answer are forwarded by CFNA.

CFC and CFNA, CFNA is deactivated: If a subscriber has both CFC and CFNA assigned, and CFC active and CFNA inactive, incoming calls on which the subscriber does not answer are forwarded by CFC.

CFC and VM: If a subscriber has both CFC and voice mail (VM) assigned and active, and the subscriber is either busy or does not answer, the call is forwarded by CFC.

CFC and VM, CFC deactivated: If a subscriber has both CFC and VM assigned but CFC is deactivated and VM is active, and the subscriber is either busy or does not answer, the call is terminated to VM.

CFC and VMA: If a subscriber has both CFC and VMA assigned and active, the call is terminated to VM.


Note Voice Mail (VM) enables the subscriber to forward calls to voice mail when the subscriber is busy or does not answer the phone. Voice Mail Always (VMA) enables the subscriber to forward all calls to voice mail, regardless of the state of the phone.


Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the CFC provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Call Waiting Features

Call waiting features notify a called party, who is already on an active call, that another incoming call is being attempted on the line. The called party has the option of answering or ignoring the new incoming call. This section describes four call waiting features:

Call Waiting (CW)

Cancel Call Waiting (CCW)

Calling Identity Delivery on Call Waiting (CIDCW)

Call Waiting Deluxe (CWD)


Note CW, CCW, and CIDCW are typically bundled as an integral part of a service package.


Limitations

If your network uses an ISUP variant other than ANSI ISUP, the system supports CWD, but not CW or CIDCW.

Call Waiting (CW)

The BTS 10200 supports the call waiting (CW) feature as specified in LSSGR module FSD 01-02-1201 (TR-NWT-000571), Call Waiting.

CW informs a busy station that another call is waiting through the application of a 300 ms, 440 Hz tone. Ten seconds after the initial tone, a second tone is applied if the waiting call has not been answered. To answer the waiting call and place the original call on hold, the user presses the Flash button or hookswitch. A subsequent flash returns the user to the original call. Additional flashes can be used to toggle between the two calls as long as they are both still connected. The waiting call hears ringing until it is answered.

When a waiting call is accepted, there are two active sessions. To end the currently active session, the user goes on hook. The user's phone will then ring to indicate that the other caller is still holding. The user can pick up the phone to resume that session.

If a media gateway-connected handset is off hook, but no active call yet exists (that is, receiving a dial tone), then an incoming call receives a station busy tone and CW is not activated.

Only one instance of CW can be active for a given subscriber line at any given time. Thus, if a subscriber line were involved in both an active call and a waiting call, then an additional incoming call attempt results in the caller receiving a busy tone or being forwarded (CFB). The user involved in the CW call is not aware of the additional incoming call attempt.


Note For information on the CIDCW feature, see the "Calling Identity Delivery on Call Waiting (CIDCW)" section.


CW, CIDCW, and CWD interaction—CWD has a higher precedence than CIDCW, and CIDCW has a higher precedence than CW.

CW Activation

CW has multiple activation options as follows:

Activated permanently at subscription time by service provider.


Tip When CW and CIDCW are first provisioned by the service provider, they are active immediately by default. To assign these features in the deactivated state, configure the subscriber-feature-data table for that subscriber to make CW and CIDCW deactivated.


The feature can be activated by the individual user if the service provider has assigned the call waiting deluxe activation (CWDA) feature. The steps are as follows.

The user lifts the handset, and listens for a dial tone.

The user presses the activation VSC (for example, *58). If CW can be activated, the system returns a success announcement. An error announcement, indicating the type of error, is given if activation is unsuccessful.


Note If CW is already activated on this subscriber line, the activation attempt is accepted and processed as a new activation attempt.


CW is now activated, and will stay active until it is deactivated (see "CW Deactivation" below).

CW Deactivation

CW deactivation options are as follows:

Service provider deactivation at user request.

The feature can be deactivated by the individual user if the service provider has assigned the call waiting deluxe deactivation (CWDD) feature. The steps are as follows.

The user lifts the handset and listens for a dial tone.

The user presses the deactivation VSC (for example, *59). A success announcement is given on a successful deactivation. An error announcement, indicating the type of error, is given if deactivation is unsuccessful.


Note If CW is already deactivated on this subscriber line, the deactivation attempt is accepted and processed as a new deactivation attempt.


CW is now deactivated, and will stay inactive until it is activated (see "CW Activation" above).

CW Feature Interactions

CFNA—If both CW and CFNA are subscribed to and activated by the user, the interaction is as follows. If the user is on an active call when a new call comes in, the CW (or CWD) tone will be played. If the user presses the Flash button or hookswitch before the CFNA timer runs out, the user will be connected to the new call, and the call will proceed according to the CW (or CWD) feature. If the user takes no action, and the CFNA timer runs out, the waiting call will be forwarded per the CFNA procedure.

Several provisionable parameters can affect the processing of this call.

The CW timeout is based on a switch-wide parameter, NO-ANSWER-TMR in the ca-config table (default 185 seconds). There is also a parameter, START-NO-ANSWER-TMR in the ca-config table, to specify whether NO-ANSWER-TMR is to be started or not; default is N.

The CFNA timeout is provisioned via the TYPE1=TO parameter in the Feature table (default 30 seconds).

If Subscriber A has the default timer settings (that is, CFNA TO=30 seconds and NO-ANSWER-TIMER=185 seconds), and has the START-NO-ANSWER-TMR parameter set to Y (not the default), the call is processed as follows:

[1] A calls B, B answers.

[2] C calls A, A hears the CW tone, C hears ring tone.

[3] If A does not attempt to answer the waiting call (C), and CFNA times out (30 seconds), C is forwarded according to normal CFNA procedures.

However, if the CFNA timeout (TO) is set to a value greater than NO-ANSWER-TMR, when NO-ANSWER-TMR expires, C is disconnected and hears a busy tone, and CFNA is cancelled.

VM—If both CW and VM are subscribed to and activated by the user, the following scenarios apply. Several provisionable parameters can affect the processing of this call.

The CW timeout is based on a switch-wide parameter, NO-ANSWER-TMR in the ca-config table (default 185 seconds). There is also a parameter, START-NO-ANSWER-TMR in the ca-config table, to specify whether NO-ANSWER-TMR is to be started or not; default is N.

The VM timeout is provisioned via the TYPE1=TO parameter in the Feature table (default 4 seconds).

If Subscriber A has the default timer settings (that is, VM TO=4 seconds and NO-ANSWER-TIMER=185 seconds), and has the START-NO-ANSWER-TMR parameter set to Y (not the default), the call is processed as follows:

[1] A calls B, B answers.

[2] C calls A, A hears the CW tone, C hears ring tone.

[3] If A does not attempt to answer the waiting call (C), and VM times out (4 seconds), C is forwarded according to normal VM forwarding procedures.

However, if the VM timeout (TO) is set to a value greater than NO-ANSWER-TMR, when NO-ANSWER-TMR expires, C is disconnected and hears a busy tone, and VM is cancelled.

If CHD is assigned to the subscriber along with CW, the following interaction occurs.

A (the subscriber) and B are on an active call.

C calls A.

A hears the CW tone. (C hears ringback.)

If A presses the Flash button or hookswitch, B is put on hold and A hears a dial tone.

If A dials *52, A is connected to C.

If A ignores the CW tone, C continues to hear ringback. The call is not forwarded.

There is an interaction when a Centrex subscriber has all three of the following features assigned and active:

1. Call hold—CHD.

2. Call waiting—CW or CIDCW or both.

3. Call forwarding on no answer—CFNA, VM (or VMA), or any combination of these.

For information on this interaction, see the "CHD with CW/CIDCW and CFNA/VM/VMA" section.

CW and DACWI Interaction for a CENTREX subscriber—If the DACWI feature is assigned to the called party (CENTREX subscriber), and the incoming call is from outside the CENTREX group, the called party is given a distinctive call-waiting indication. If the incoming call is from within the CENTREX group, the called party is not given a distinctive call-waiting indication, but a regular call-waiting indication is given.

Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the CW provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Cancel Call Waiting (CCW)

The Cisco BTS 10200 Softswitch supports cancel call waiting (CCW) feature activation as specified in LSSGR module FSD 01-02-1204 (TR-TSY-000572), Cancel Call Waiting.

CCW allows a user to disable CW, which also disables the CIDCW feature for the duration of a call (see the "Calling Identity Delivery on Call Waiting (CIDCW)" section). CCW is normally included as an integral part of a service package containing the CW and CIDCW features. CCW is useful when the user does not want to be interrupted during an important call or during an outgoing data/fax call.

The user activates and deactivates the CCW feature as follows:

To make an uninterrupted new call:

The user lifts the handset, and listens for a dial tone.

The user enters the CCW VSC (for example, *70). The system responds by disabling the CW/CIDCW features and returning three short beeps and then the dial tone.

Now CCW is activated for the duration of the call, until the user goes on hook again.

After the user goes on hook, the CW/CIDCW service will be back in effect automatically.


Note There are exceptions. If a user was involved in a multiparty call, and received a ringback after going on hook, CCW remains active for the call.


To make a currently active call go uninterrupted:

The user presses Flash button or hookswitch

The user enters the CCW VSC (for example, *70). The system responds by disabling the CW/CIDCW features and returning three short beeps and then the dial tone.

Now CCW is activated for the remainder of the current call, until the user goes on hook again.

The user presses Flash button or hookswitch to return to the original call.

After the current call is completely released, the CW service will be back in effect automatically.


Note If there is a CA switchover during an active call with CCW invoked, CCW will not be supported on that call after the switchover.



Tip To provision this feature, see the CCW provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Calling Identity Delivery on Call Waiting (CIDCW)

The BTS 10200 supports the calling identity delivery on call waiting (CIDCW) feature as specified in LSSGR module FSD 01-02-1090 (TR-TSY-000575), Calling Identity Delivery on Call Waiting.

CIDCW is a service that enables a called party to receive information about a calling party on a waiting call while off hook on an existing call. CIDCW provides the capability of calling identity delivery (CID) information to the called party on waiting calls. CIDCW is considered an enhancement of the CW feature, and requires the basic CW feature, along with the CND or CNAM feature.


Tip When CW and CIDCW are first provisioned by the service provider, they are active immediately by default. To assign these features in the deactivated state, configure the subscriber-feature-data table for that subscriber to make CW and CIDCW deactivated.


When a called party has been alerted of an incoming call, the called party places the current far-end party on hold by pressing the Flash button or hookswitch to retrieve the waiting call. The Flash button or hookswitch can be used to toggle between the current far-end party and the held party. The details of these functions are as follows:

A called party currently on a call receives notification, via a short beep repeated 3 times, that another call is coming in.

The incoming name and/or number is displayed after the first beep.

The called party can either ignore the new call or can accept it while putting the existing call on hold.

To ignore the new call, the called party continues uninterrupted on the existing call, and the beep indication will time out after 3 repetitions.

To accept the new call and put the existing call on hold, the called party presses and releases the Flash button or hookswitch.

To alternate between the two calls, the called party can press and release the Flash button or hookswitch.

If either one of the remote stations goes on hook, the remaining remote station continues as a normal session with the called party.

The called party can end either session by going on hook during the currently active session. This ends the session. The phone will ring to indicate that the other party is still holding. The called party can pick up the phone and the session to that calling party resumes as a normal call.

If the calling party's caller ID is not available (for example, if the caller has blocked caller ID) then the called party's caller ID display will indicate an anonymous call or other unidentified caller message as in the caller ID feature.

CIDCW Activation

CIDCW has multiple activation options as follows:

Activated permanently at subscription time by service provider.


Tip When CW and CIDCW are first provisioned by the service provider, they are active immediately by default. To assign these features in the deactivated state, configure the subscriber-feature-data table for that subscriber to make CW and CIDCW deactivated.


The feature can be activated by the individual user if the service provider has assigned the call waiting deluxe activation (CWDA) feature. The steps are as follows.

The user lifts the handset, and listens for a dial tone.

The user presses the activation VSC (for example, *58). If CIDCW can be activated, the system returns a success announcement. An error announcement, indicating the type of error, is given if activation is unsuccessful.


Note If CIDCW is already activated on this subscriber line, the activation attempt is accepted and processed as a new activation attempt.


CIDCW is now activated, and will stay active until it is deactivated (see "CIDCW Deactivation" below).

CIDCW Deactivation

CIDCW deactivation options are as follows:

Service provider deactivation at user request.

The feature can be deactivated by the individual user if the service provider has assigned the call waiting deluxe deactivation (CWDD) feature. The steps are as follows.

The user lifts the handset and listens for a dial tone.

The user presses the deactivation VSC (for example, *59). A success announcement is given on a successful deactivation. An error announcement, indicating the type of error, is given if deactivation is unsuccessful.


Note If CIDCW is already deactivated on this subscriber line, the deactivation attempt is accepted and processed as a new deactivation attempt.


CIDCW is now deactivated, and will stay inactive until it is activated (see "CIDCW Activation" above).

CIDCW Feature Interactions

CW, CIDCW, and CWD interaction—CWD has a higher precedence than CIDCW, and CIDCW has a higher precedence than CW.

There is an interaction when a Centrex subscriber has all three of the following features assigned and active:

1. Call hold—CHD.

2. Call waiting—CW or CIDCW or both.

3. Call forwarding on no answer—CFNA, VM (or VMA), or any combination of these.

For information on this interaction, see the "CHD with CW/CIDCW and CFNA/VM/VMA" section.

Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the CIDCW provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Call Waiting Deluxe (CWD)

CWD service informs a busy phone (user on an active call) that another call is waiting through the application of a call-waiting tone. Ten seconds after the initial tone, a second tone is applied if the waiting call has not been answered. To process the waiting call, the called party can take one of the following actions:

The called party can go on hook to disconnect from the active call. The system will ring the called party, and the called party can take the phone off hook to be connected to the waiting call.

To process the waiting call, the called party can press the Flash button or hookswitch. The system places the remote party on hold and provides a recall (stutter) dial tone to the called party. After receiving the recall dial tone, the called party can take one of the following actions:

If the called party presses digit 1, the active call is dropped and a voice connection is established with the waiting party.

If the called party presses the digit 2, a voice connection is established with the waiting party. From this point the called party can press the Flash button or hookswitch, receive recall dial tone, and press 2 to alternate between the parties.

While on a CWD call with the other two parties, the called party can exercise the following additional options after pressing the Flash button or hookswitch and receiving recall dial tone:

If the called party presses digit 3 instead of 2, all three parties are conferenced together, and the call proceeds as in the three-way calling deluxe (TWCD) feature. (For more information on this call behavior, see the "Three-Way Calling Deluxe (TWCD)" section.)

If the called party presses digit 1 instead of 2, the active call is dropped and a voice connection is established with the waiting party.

If the called party goes on hook to disconnect from the active call, the system will ring the called party. The called party can take the phone off hook to be connected to the waiting call.


Note If a MGW-connected handset is off hook, but no active call exists (that is, receiving a dial tone), then an incoming call receives a busy tone and CWD is not activated.


Only one instance of CWD can be active for a given subscriber line at any given time. Thus, if a subscriber line were involved in both an active call and a waiting call, then an additional incoming call attempt results in the caller receiving a busy tone or being forwarded (CFB). The called party involved in the CWD call is not aware of the additional incoming call attempt.

The following conditions apply to the CWD feature:

The CWD feature can be provided to POTS, Centrex, and MLHG subscribers.

The CWD feature is in the deactivated mode unless activated by the subscriber.

The CWD feature is composed of four associated features, which are described in the sections that follow:

CWD Activation

CWD Deactivation

CWD Interrogation

CWD Invocation

CWD Timers

There are three timers that apply to the CWD feature:

Call-waiting timeout timer (TO), measured in seconds—This is the time that an incoming call can be held in call-waiting mode. After the timer expires, the waiting call is disconnected. The default value is 15.

Feature reconnect timer (FEATURE-RECONNECT-TMR), measured in seconds—During the course of using the CWD feature, if the subscriber is connected to a reorder tone or announcement, the subscriber is automatically reconnected to the previous call leg after the specified FEATURE-RECONNECT-TMR timeout period. The default value is 10.

Reconnect timer (RECONNECT-TMR), measured in seconds—When a subscriber hangs up with another call on hold, the subscriber is rung back. The ringing is applied for the duration of this RECONNECT-TMR. If the subscriber does not answer the call within this time period, the call is torn down. The default value can be provisioned in the CA-CONFIG table. If the timer is not provisioned in the CA-CONFIG table, the preset value 36 is used as default.

CWD Activation

CWD has multiple activation options as follows:

Activated permanently at subscription time by service provider.

Activated by user:

The user lifts the handset, and listens for a dial tone.

The user presses the activation VSC (for example, *58 in North America and *58# in China). If CWD can be activated, the system returns a success announcement. An error announcement, indicating the type of error, is given if activation is unsuccessful.

CWD is now activated, and will stay active until it is deactivated (see "CWD Deactivation" below).

CWD Deactivation

CWD deactivation options are as follows:

Service provider deactivation at user request.

Deactivated by user:

The user lifts the handset and listens for a dial tone.

The user presses the deactivation VSC (for example, *59 in North America and #58# in China). A success announcement is given on a successful deactivation. An error announcement, indicating the type of error, is given if deactivation is unsuccessful.

CWD is now deactivated, and will stay inactive until it is activated (see "CWD Activation" above).

CWD Interrogation

CWD interrogation allows a user to check whether CWD is activated on his or her local phone. The user enters the VSC for CWD interrogation (for example, *56 in North America and *#58#* in China). A success announcement is given to the user if CWD is activated, and an appropriate announcement is provided if it is deactivated.

CWD Invocation

CWD invocation is the actual set of procedures the system follows when a user (with CWD activated) is already on an active call and receives a call from a third party.

Invalid User Actions

The valid user actions are described in the sections above. The following user actions are invalid, and the system provides an appropriate error announcement:

The user tries to interrogate CWD on a fresh system (a system with no entry in the SUBSCRIBER-FEATURE-DATA table).

The user presses the Flash button or hookswitch, receives recall dial tone, and then enters a digit other than 1, 2, or 3.

CWD Feature Interactions

CWD and CFNA Interaction—If both CFNA and CWD are subscribed to and activated by the user, the interaction is as follows. If the user is on an active call when a new call comes in, the CWD tone will be played. The CWD feature does not perform any timing in this case (that is, CWD does not start the call-waiting disconnect timer). If the user presses the hookswitch before the CFNA timer runs out, the user will be connected to the new call, and the call will proceed according to the CWD feature. If the user takes no action, and the CFNA timer runs out, the waiting call will be forwarded per the CFNA procedure.

CWD and CFB Interaction—If both CWD and CFB are activated, CWD has higher precedence than CFB.

CWD and TWCD Interaction—These two feature invocations are mutually exclusive. When one feature is invoked, the other feature is not allowed.


Note During a three-way call, the CWD feature does not work for the party that initiated the three-way call. However, the CWD feature would work normally for the other two (non-initiating) parties.


CWD and CLIP interaction—If the called user is given a call waiting indication, and has subscribed to the CLIP service, then the calling line identification is presented to the user at the time the call waiting indication is given.

CWD, CIDCW, CW Interaction—CWD has a higher precedence than CIDCW, and CIDCW has a higher precedence than CW.

CWD and CCW Interaction—When CCW is activated, CWD will be inhibited. (Note that CCW is a per-call activated feature.)

CWD and DRCW Interaction—If the calling party number is in the DRCW list of the called party, and if DRCW is activated, the called party is given a distinctive call-waiting indication. Otherwise, the regular call-waiting indication is given.

CWD and DACWI Interaction for a CENTREX subscriber—If the DACWI feature is assigned to the called party (CENTREX subscriber), and the incoming call is from outside the CENTREX group, the called party is given a distinctive call-waiting indication. Otherwise, the regular call-waiting indication is given.

CWD and MDN Interaction—If the calling party dials the called party number different from main number, the called party is given a distinctive call-waiting indication. Otherwise, the regular call waiting indication is given.

CWD and DACWI Interaction—If this is a direct inward dialing (DID) call and DACWI feature is assigned, the called party is given a distinctive call-waiting indication. Otherwise, a regular call-waiting indication is given.

Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the CWD provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Calling Identity Features

Calling identity features include:

Calling Identity Delivery

Calling Number Delivery (CND)

Calling Name Delivery (CNAM)

Calling Line Identification Presentation (CLIP)

Calling Identity Delivery Blocking (CIDB)

Calling Number Delivery Blocking (CNDB)

Calling Name Delivery Blocking (CNAB)

Calling Identity Delivery and Suppression (CIDSD and CIDSS)

Calling Line Identification Restriction (CLIR)

Calling Number Delivery Blocking (CNDB)

Calling Name Delivery Blocking (CNAB)

Calling Identity Delivery and Suppression (CIDSD and CIDSS)


Note The calling identity delivery on call waiting (CIDCW) feature is described in the "Call Waiting Features" section.


Calling Identity Delivery

The identity of the caller is provided in two features, calling number delivery (CND) and calling name delivery (CNAM), as described in the following sections.

Calling Number Delivery (CND)

The BTS 10200 supports the CND feature as specified in the Telcordia LSSGR module FSD 01-02-1051 (TR-NWT-000031), Calling Number Delivery, and GR-30-CORE, Voiceband Data Transmission Interface.

The CND feature provides CPE with the date, time, and DN of an incoming call. When the called subscriber line is on hook, the calling party information is delivered during the long silent interval of the first ringing cycle. Telcordia document GR-30-CORE specifies the generic requirements for transmitting asynchronous voice band data to the CPE.


Tip To provision this feature, see the CND provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Calling Name Delivery (CNAM)

The BTS 10200 supports the CNAM feature as specified in LSSGR module FSD 01-02-1070 (TR-TSY-001188), Calling Name Delivery Generic Requirements.

CNAM is a terminating user feature allowing CPE connected to a switching system to receive a calling party's name, number, and the date and time of the call during the first silent interval. If a private status is assigned with the name, the name will not be delivered and a private indicator code P is sent to the CPE. If the name is not available for delivery, the switch sends an out-of-area/unavailable code O to the CPE. When transferring or forwarding calls internally, the private calling name can be obtained from the Cisco BTS 10200 Softswitch databases and passed on to the internal called user.


Tip To provision this feature, see the CNAM provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Calling Line Identification Presentation (CLIP)

This section describes the calling line identification presentation (CLIP) feature. This feature is available to POTS, Centrex, and MLHG subscribers.

References:

Telcordia LSSGR, CLASS Feature: Calling Number Delivery, GR-31-CORE

ITU-T: I.251.3 (08/92) Calling Line Identification Presentation

CLIP Feature Description

CLIP is a supplementary service offered to the called party that displays the calling party DN and the date and time of the call. The calling line identification information is included in the incoming message (for example, SETUP, IAM, R2 digits, SIP, and so forth) from the originating DN. Interoffice application of this service depends on network deployment of signaling methods capable of transmitting the calling line identification.

The Cisco BTS 10200 Softswitch supports this feature for the following types of incoming calls:

Intraoffice calls—Calls that originate and terminate on lines supported by one Cisco BTS 10200 Softswitch. (The calling party's DN is retrieved from the Cisco BTS 10200 Softswitch memory.)

Incoming interoffice calls from another Cisco BTS 10200 Softswitch on the packet network.

Incoming interoffice calls from another stored program controlled switch (SPCS) on the packet network or the connection-oriented network.

The calling party's information can be public, private, or unavailable:

Public—If the calling line identification information is included in the message from the originating DN, and is not blocked, the Cisco BTS 10200 Softswitch displays it on the called party's display.

Private (anonymous)—If the calling line DN has been marked to indicate that it is private, the Cisco BTS 10200 Softswitch does not transmit the DN to the called party. Instead, it sends the date, time, and a private indicator, signified by the ASCII letter "P", to the called party in place of the calling line DN.

Unavailable—If the calling line identification information is not available, the Cisco BTS 10200 Softswitch displays an out-of-area/DN-unavailable indicator, signified by the ASCII letter "O", along with the date and time.

CLIP Feature Activation and Deactivation

CLIP is offered to users on a subscription basis. Once the feature has been successfully assigned, the called party should receive the date, time, and calling number, if available and allowed to be disclosed, for all subsequent incoming calls. If the called party does not subscribe to this feature, the calling party's identity information is not transmitted to the called party's handset.

CLIP Feature Interactions

CFU—When CLIP is subscribed and the user activates CFU, all incoming calls are forwarded at the base phone, and the Cisco BTS 10200 Softswitch forwards the original calling DN to the remote phone.

CFNA—When CLIP is subscribed and the user activates CFNA, all unanswered incoming calls are forwarded at the base phone, and the Cisco BTS 10200 Softswitch forwards the original calling DN to the remote phone.

CFB—When CLIP is subscribed and the user activates CFB, incoming calls are forwarded when the base phone is off hook, and the Cisco BTS 10200 Softswitch forwards the original calling DN to the remote phone.

CLIR—There are no interactions between CLIP and CLIR when active on the same line. Indirect interactions occur between CLIP and CLIR when the calling party subscribes to CLIR and the called party subscribes to CLIP. If the calling party uses any of the CLIR features to make the status of the calling DN private, the terminating SPCS (Cisco BTS 10200 Softswitch) transmits a "P" (indicating private status) to the terminating phone.

CWD—If the called user is given a call waiting indication, and has subscribed to the CLIP service, then the calling line identification is presented to the user at the time the call waiting indication is given.

Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the CLIP provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Calling Identity Delivery Blocking (CIDB)

The Cisco BTS 10200 Softswitch supports calling identity delivery blocking (CIDB) features as specified in LSSGR module FSD 01-02-1053 (TR-NWT-000391), Calling Identity Delivery Blocking Features

CIDB allows caller to control whether or not their calling identity information is delivered with outgoing calls. Identity includes directory number (DN) and/or name of the caller. CIDB does not affect the presentation of caller's information when making 911 calls.

The CIDB feature affects the presentation status (PS) of the calling identity information. The PS is a flag that lets the network know if it is permissible to deliver the information to the called party. Both the calling number and calling name have PS information associated with them. There are two types of PS flags—permanent and per-call:

Permanent PS (PPS)—The service provider provisions PPS flags, either public or private, for each subscriber line. These values are defined as follows:

Public—Calling identity information (calling name and/or calling number) is delivered with outgoing calls. The local switch (BTS 10200) informs the remote switch that it is permissible to deliver the caller's identity information on the remote phone.

Private (anonymous)—Calling identity information (calling name and/or calling number) is not delivered with outgoing calls. The local switch (BTS 10200) informs the remote switch that it is not permissible to deliver the caller's identity information on the remote phone.

Per-call PS (PCPS) has significance only to the current outgoing call. On a per-call basis, a caller with the CIDB feature enabled can override the default values for the PS flags. The per-call features are listed in Table 3-7 and described in the "Calling Number Delivery Blocking (CNDB)" section through the "Calling Identity Delivery and Suppression (CIDSD and CIDSS)" section.


Note The vertical service codes (VSCs), also called star codes, listed in Table 3-7 and throughout this section are typical values. The service provider can provision these values with any valid unique ASCII string up to five characters long. For a complete list of valid VSC formats and preprovisioned VSCs, see the VSC table specification and VSC appendix in the Cisco BTS 10200 Softswitch CLI Reference Guide.


Table 3-7 Per-Call CIDB Feature Summary 

Identity Item
Permanent Privacy Status (PPS)
Effect Of CNDB (*67)
Effect Of CNAB (*95)
Effect Of CIDSD (*82)
Effect Of CIDSS (*96)
Number
Name
Number PS
Name
PS
Number PS
Name
PS
Number PS
Name
PS
Number PS
Name
PS

Identity:

Number [CND]

+

Name [CNAM]

Public

Public

Private

Private1

Public

Private

Public

Public

Private

Private

Public

Private

Private

Private

Public

Public

Public

Public

Private

Private

Private

Public1

Public

Public

Private

Private

Public

Public

Private

Private

Private

Private

Public

Private

Private

Private1

Public

Public

Private

Private

Number:

[CND] only

Public

n/a

Private

n/a

n/a

n/a

Public

n/a

Private

n/a

Private

n/a

Public

n/a

n/a

n/a

Public

n/a

Private

n/a

1 When the number is private, no name query is performed.


When a caller goes off hook and does not enter a per-call CIDB code that affect the caller's PS, then the value of the caller's PPS is used as the presentation status for that call. When a CIDB per-call feature is used on a call, only the current call is affected. The PPS is used for future calls (unless the caller enters one of the per-call features again.)

Calling Number Delivery Blocking (CNDB)

Calling number delivery blocking (CNDB) allows the caller to control the status of their caller number privacy on a per-call basis. For all new calls, the privacy status reverts back to the PPS.

To use the CNDB feature, the caller does the following:

The caller goes off hook and receives a dial tone.

The caller enters the CNDB VSC (for example, *67). The system responds with a dial tone.

The caller enters the desired phone number for the remote station. The CNDB function toggles the PPS of the caller's number for this call:

If the PPS is private, CNDB makes the PS public for this call

If the PPS is public, CNDB makes the PS private for this call


Note When the number is private, no name query is performed.



Tip To provision this feature, see the CNDB provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Calling Name Delivery Blocking (CNAB)

Calling name delivery blocking (CNAB) allows the caller to control the status of their caller name privacy on a per-call basis. For all new calls, the privacy status reverts back to the PPS.

To use the CNAB feature, the caller does the following:

The caller goes off hook and receives a dial tone.

The caller enters the CNAB VSC (for example, *95). The system responds with a dial tone.

The caller enters the desired phone number for the remote station. The CNAB function toggles the PPS of the caller's name for this call:

If the PPS is private, CNAB makes the PS public for this call

If the PPS is public, CNAB makes the PS private for this call


Note When the number is private, no name query is performed.



Note The CNAB feature is not supported over SIP trunks.



Tip To provision this feature, see the CNAB provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Calling Identity Delivery and Suppression (CIDSD and CIDSS)

The BTS 10200 supports the delivery function and the suppression function of calling identity delivery and suppression (CIDSD and CIDSS, respectively). CIDSD and CIDSS are per-call features.

CIDSD and CIDSS allow a caller to explicitly indicate on a per-call basis whether both the calling name and calling number will be treated as private or public. When CIDSD or CIDSS is used, the system does not query the PPS of the caller's DN and name. The following conditions apply:

CIDS Delivery (CIDSD)—If the caller enters the VSC for CIDSD (for example, *82), the current call is treated as public regardless of the default privacy status permanently associated with the calling name and number.

CIDS Suppression (CIDSS)—If the caller enters the VSC for CIDSS (for example, *96), the current call is treated as private regardless of the default privacy status permanently associated with the calling name and number.

For all new calls, the privacy status reverts back to the PPS.

To use the CIDSD or CIDSS feature, the caller does the following:

The caller goes off hook and receives a dial tone.

The caller enters the VSC for CIDSD or CIDSS (for example, *82 or *96) and receives a dial tone again.

The caller enters the desired phone number for the remote phone.

The caller's ID will be displayed or blocked as follows:

For *82, the caller's ID will be delivered (that is, it will not be blocked) at the remote station, assuming the remote station has the caller ID function.

For *96, the caller's ID will be blocked at the remote station, assuming the remote station has the caller ID function.

The next time this caller makes a phone call, the default caller ID settings (PPS) will apply, unless the caller again enters the VSC for CIDSD or CIDSS.


Tip To provision these features, see the CIDSD and CIDSS provisioning procedures in the Cisco BTS 10200 Softswitch Provisioning Guide.


Calling Line Identification Restriction (CLIR)

This section describes the calling line identification restriction (CLIR) feature. This feature is available to POTS, Centrex, and MLHG subscribers.

References:

Telcordia LSSGR, CLASS Feature: Calling Identity Delivery Blocking Features, GR-391-CORE

ITU-T: I.251.4 (08/92) Calling Line Identification Restriction

CLIR is a supplementary service that allows callers to control whether or not their calling identity information is delivered with outgoing calls. Identity includes directory number (DN) and/or name of the caller. The presentation of calling identity information (at the terminating phone) is described in the "Calling Line Identification Presentation (CLIP)" section.

When provisioned by the service provider, the calling party can restrict the display of his or her DN on either a permanent basis or a per-call basis. The CLIR feature consists of the following per-call associated features:

Calling Number Delivery Blocking (CNDB)

Calling Name Delivery Blocking (CNAB)

Calling Identity Delivery and Suppression (CIDSD and CIDSS)

Calling Identity Presentation Status

The CLIR feature affects the presentation status (PS) of the calling identity information. The PS is a flag that lets the network know if it is permissible to deliver the information to the called party. Both the calling number and calling name have PS information associated with them. There are two types of PS flags—permanent and per-call:

Permanent PS (PPS)—The service provider provisions PPS flags, either public or private, for each subscriber line. These values are defined as follows:

Public—Calling identity information (calling name and/or calling number) is delivered with outgoing calls. The local SPCS (Cisco BTS 10200 Softswitch) informs the remote SPCS that it is permissible to deliver the caller's identity information to the remote phone.

Private (anonymous)—Calling identity information (calling name and/or calling number) is not delivered with outgoing calls. The local SPCS (Cisco BTS 10200 Softswitch) informs the remote SPCS that it is not permissible to deliver the caller's identity information to the remote phone.

Per-call PS (PCPS) has significance only to the current outgoing call. On a per-call basis, a caller with the CLIR feature enabled can override the default values for the PS flags. The per-call features are listed in Table 3-8 and described in the "Calling Number Delivery Blocking (CNDB)" section through the "Calling Identity Delivery and Suppression (CIDSD and CIDSS)" section.


Note The vertical service codes (VSCs), also called star codes, listed in Table 3-8 and throughout this section are typical values. The service provider can provision these values with any valid unique ASCII string up to five characters long. For a complete list of valid VSC formats and preprovisioned VSCs, see the VSC table specification and VSC appendix in the Cisco BTS 10200 Softswitch CLI Reference Guide.


Table 3-8 Per-Call CLIR Feature Summary 

Identity Item
Permanent Privacy Status (PPS)
Effect Of CNDB (*67*)
Effect Of CNAB (*95*)
Effect Of CIDSD (*82*)
Effect Of CIDSS (*96*)
Number
Name
Number PS
Name
PS
Number PS
Name
PS
Number PS
Name
PS
Number PS
Name
PS

Identity:

Number [CND]

+

Name [CNAM]

Public

Public

Private

Private1

Public

Private

Public

Public

Private

Private

Public

Private

Private

Private

Public

Public

Public

Public

Private

Private

Private

Public1

Public

Public

Private

Private

Public

Public

Private

Private

Private

Private

Public

Private

Private

Private1

Public

Public

Private

Private

Number:

[CND] only

Public

n/a

Private

n/a

n/a

n/a

Public

n/a

Private

n/a

Private

n/a

Public

n/a

n/a

n/a

Public

n/a

Private

n/a

1 When the number is private, no name query is performed.


When a caller goes off hook and does not enter a per-call CLIR code that affect the caller's PS, then the value of the caller's PPS is used as the presentation status for that call. When a CLIR per-call feature is used on a call, only the current call is affected. The PPS is used for future calls (unless the caller enters one of the per-call features again.)

Calling Number Delivery Blocking (CNDB)

The CNDB associated feature affects the PS designation of the caller's DN. CNDB works as follows:

The caller goes off hook and receives dial tone.

The caller enters the CNDB VSC (for example, *67*). The system responds with a dial tone.

The caller enters the desired phone number for the remote phone. The local switch (Cisco BTS 10200 Softswitch) retrieves the PPS value of the DN for the caller's line, and then forwards the opposite of the PS value to the remote switch. Therefore:

If the PPS of the DN is public, the Cisco BTS 10200 Softswitch sends a PCPS of private.

If the PPS of the DN is private, the Cisco BTS 10200 Softswitch sends a PCPS of public.


Note When the number is private, no name query is performed.



Tip To provision this feature, see the CNDB provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Calling Name Delivery Blocking (CNAB)

The CNAB associated feature affects the PS designation of the caller's name. CNAB works as follows:

The caller goes off hook and receives dial tone.

The caller enters the CNAB VSC (for example, *95*). The system responds with a dial tone.

The caller enters the desired phone number for the remote phone. The local switch (Cisco BTS 10200 Softswitch) retrieves the PPS value of the name for the caller's line, and then forwards the opposite of the PS value to the remote switch. Therefore:

If the PPS of the name is public, the Cisco BTS 10200 Softswitch sends a PCPS of private.

If the PPS of the name is private, the Cisco BTS 10200 Softswitch sends a PCPS of public.


Note When the number is private, no name query is performed.



Note The CNAB feature is not supported over SIP trunks.



Tip To provision this feature, see the CNAB provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Calling Identity Delivery and Suppression (CIDSD and CIDSS)

The BTS 10200 supports the delivery function and the suppression function of calling identity delivery and suppression (CIDSD and CIDSS, respectively). CIDSD and CIDSS are per-call features.

CIDSD and CIDSS allow a caller to explicitly indicate on a per-call basis whether both the calling name and calling number will be treated as private or public. When CIDSD or CIDSS is used, the system does not query the PPS of the caller's DN and name. The following conditions apply:

CIDS Delivery (CIDSD)—If the caller enters the VSC for CIDSD (for example, *82*), the current call is treated as public regardless of the default privacy status permanently associated with the calling name and number.

CIDS Suppression (CIDSS)—If the caller enters the VSC for CIDSS (for example, *96*), the current call is treated as private regardless of the default privacy status permanently associated with the calling name and number.

For all new calls, the privacy status reverts back to the PPS.

To use the CIDSD or CIDSS feature, the caller does the following:

The caller goes off hook and receives a dial tone.

The caller enters the VSC for CIDSD or CIDSS (for example, *82* or *96*) and receives a dial tone again.

The caller enters the desired phone number. for the remote phone

The caller's ID will be displayed or blocked as follows:

For *82*, the caller's ID will be delivered (that is, it will not be blocked) at the remote station, assuming the remote station has the caller ID function.

For *96*, the caller's ID will be blocked at the remote station, assuming the remote station has the caller ID function.

The next time this caller makes a phone call, the default caller ID settings (PPS) will apply, unless the caller again enters the VSC for CIDSD or CIDSS.


Tip To provision these features, see the CIDSD and CIDSS provisioning procedures in the Cisco BTS 10200 Softswitch Provisioning Guide.


CLIR Feature Interactions

CLIP—There are no interactions between CLIP and CLIR when active on the same line. Interactions occur between CLIP and CLIR when the calling party subscribes CLIR and the called party subscribes to CLIP. If the calling party uses any of the CLIR features to make the status of the calling DN private, the terminating SPCS (Cisco BTS 10200 Softswitch) transmits a "P" (indicating private status) to the terminating phone.

TWCD—A user with TWCD can press the Flash button or hookswitch and use any of the CLIR per-call restrictions before dialing the next phone number. This allows the user to control the presentation of his or her PS to the third party in the three-way call.

Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the CLIR provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Direct Inward/Outward Dialing for PBX

The Cisco BTS 10200 Softswitch supports the direct inward dialing (DID) and direct outward dialing (DOD) features for PBX.

Analog DID for PBX

The Cisco BTS 10200 Softswitch supports analog DID for PBX as specified in TIA/EIA-464B, Requirements for Private Branch Exchange (PBX) Switching Equipment, April 1, 1996.

The analog DID one-way feature allows incoming calls to a local PBX network to complete to a specific station without attendant assistance. The station address is provided by the CA that controls an access gateway (AGW) connecting to the PBX. The number of digits to be outpulsed by the AGW to the PBX is configurable in the CA.


Note For guidance in provisioning the CA to support this feature, see the Cisco BTS 10200 Softswitch Operations Manual.


Figure 3-1 shows a typical application, with a residential user (UserA) attempting to call a PBX user station (UserB). UserB is identified by a specific set of extension digits in the PBX. The Cisco BTS 10200 Softswitch uses MGCP signaling to communicate with the AGW, and controls the outpulsing of digits from the AGW to the PBX. A foreign exchange office (FXO) board in the AGW uses reverse battery signaling (per TIA/EIA-464B) to communicate with a DID trunk board in the PBX over an analog DID one-way trunk. When completing a call termination to the PBX, the extension digits for UserB are outpulsed from the AGW toward the PBX. The PBX receives the extension digits and then completes the call to UserB.

Figure 3-1 Example of PBX Analog DID One-Way Application


Tip To provision PBX-DID subscribers, you must use the proper settings in the DN to Subscriber (dn2subscriber) and Subscriber (subscriber) tables. See the IAD Subscriber provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


DOD For PBX

Reference: LSSGR module FSD 04-02-0000 (TR-TSY-000524), Direct Inward Dialing.

The DOD feature allows outgoing calls from a specific station to be completed through the local PBX network without attendant assistance. The CA serving the PBX recognizes the station address and routes the call to the PBX.

Seasonal Suspend

The Seasonal Suspend feature is available in Release 5.0, MR1. In Release 5.0, MR1.1, changes were made to enhance the usability of this feature. (MR1,1 simplifies the steps for putting a subscriber in seasonal suspend status.) This document is divided into separate parts for the two maintenance releases. Make sure that you use the section that applies to the release (MR1 and earlier, or MR1.1 and later) you are running on your system:

"Seasonal Suspend Feature for Release 5.0 MR1 and Earlier" section

"Seasonal Suspend Feature for Release 5.0 MR1.1 and Later" section

This document includes references to specific CLI database tables and parameters. For a complete listing of all tables and parameters, see the Cisco BTS 10200 Softswitch CLI Database.

Seasonal Suspend Feature for Release 5.0 MR1 and Earlier

Use this section if your system is running Release 5.0, MR1 or earlier.

Understanding the Seasonal Suspend Feature, MR1 and Earlier

The Seasonal Suspend feature allows subscribers to suspend their telephone service (instead of disconnecting it) while they are away for the off-season. This feature affects both inbound and outbound calls on the subscriber line.


Note In this document, "inbound calls" means calls that are intended to be terminated on the seasonal suspend subscriber line. "Outbound calls" means calls that are originated by a user on the seasonal suspend line.


Allowed and Disabled Features for Outbound Calls

During the suspension period, outbound calls are treated as follows:

Allowed features—Emergency (911), toll-free customer service numbers such as repair (611), and voice mail. The subscriber can retrieve messages and access voice-mail functions by dialing the voice-mail pilot number.

Disabled features—All domestic and international inbound and outbound calling, operator services, directory assistance, caller ID blocking, vertical service codes (VSCs), midcall and hookflash-based features, and all calling features other than the allowed features listed above.

Treatment of Outbound Calls

You can provision the system (through the feature-configuration table) to provide special handling for outbound calls that are blocked by seasonal suspend. You can provide either of the following treatments:

Route outbound calls to a standard announcement indicating that seasonal suspend is active on the subscriber line. This is the default behavior.

Route outbound calls to a customer support line. (You provision the support line directory number [DN] in the feature-configuration table.)

Treatment of Inbound Calls

The system provides special handling for inbound calls that are rejected due to seasonal suspend status. You can provide either of the following treatments:

Play a generic seasonal suspend announcement. This is the default behavior.

Play a seasonal suspend announcement that includes a DN at which the subscriber can be reached. This DN is provisionable in the subscriber-feature-data table.

If the Voice Mail Always (VMA) feature is provisioned and active on the subscriber line prior to the time you set the subscriber status to seasonal suspend, VMA continues to function during the seasonal suspend period and takes precedence over Seasonal Suspend features for inbound calls.

Deactivation of Seasonal Suspend

At the request of the subscriber, the service provider deactivates the Seasonal Suspend feature by resetting two parameters in the Subscriber table:

Set status=active.

Set cos-restrict-id to the same value it had prior to the start of seasonal suspend.


Note You can set the subscriber status to active, or to any other valid status other than seasonal-suspend, by provisioning the status parameter in the Subscriber table.


Feature Interactions

This section describes interactions of this feature with other telephony features.

VMA for inbound calls to the subscriber line—By design, VMA (if provisioned, activated, and available) takes precedence over any inbound call routing for seasonal suspend. In this case, the system provides VMA to all inbound calls, and not seasonal suspend.

Other calling features—If you assign seasonal suspend status to a subscriber, the system does not provide any other features for this subscriber except those listed below. You must provision these options through a special Class of Service (CoS) restriction.

Calls allowed in the seasonal suspend cos-restrict table, which can include repair, a customer service number, and a voice-mail pilot number if provisioned

Calls provisioned with the trigger-nod-escape-list command

The subscriber line can be used to make calls to a limited number of DNs, such as emergency services, customer service or repair service, voice-mail pilot number, or to other DNs allowed in the national-wb-list. During such a call, if an operator attempts to perform Busy Line Verification (BLV), the call from the operator receives the same treatment as that provisioned for any other incoming call to this subscriber, that is, forwarding to VMA or forwarding to a seasonal suspend announcement.

Billing treatment—The system generates the following billing cause codes for this feature:

Outbound calls that are blocked due to seasonal suspend result in billing cause code SERVICE_DENIED. Outbound calls that are redirected to the customer service number result in normal billing record events.

Inbound calls that are blocked or redirected due to seasonal suspend result in the billing cause code CALL_REJECTED.

Prerequisites

This section lists requirements that must be met before the feature can work.

Announcements

The appropriate announcements must be provisioned and available on the system, including announcements for generic seasonal suspend and DN referral. See release cause codes 1272 through 1275 and the associated announcements in the "Cause Code to Announcement ID Mappings" section of the Cisco BTS 10200 Softswitch Provisioning Guide. Routing to the announcement server must be working properly.


Note For features requiring an audible DN readout, such as seasonal suspend, the BTS 10200 has been tested for interoperability with the ThinkEngine Networks announcement server, Models 500X and 4000X.


VMA Treatment of Inbound Calls

This prerequisite applies if you are provisioning a customer with VMA treatment (instead of seasonal suspend treatment) for inbound calls.

The subscriber must have VMA activated and provisioned through the interactive voice response (IVR) provisioning system before you set the subscriber status to seasonal-suspend. If VMA is assigned and active, inbound calls to this subscriber are given VMA treatment instead of seasonal suspend treatment. However, outbound calls receive seasonal-suspend treatment if status=seasonal-suspend.


Caution VMA, if assigned and active, takes precedence over the Seasonal Suspend feature. In this case, incoming calls do not receive seasonal suspend treatment. The incoming calls go directly to voice mail, and not to a seasonal suspend message, even if a seasonal suspend message is provisioned. Therefore, if the end user wishes to have seasonal suspend treatment for inbound calls, make sure that VMA is deactivated before setting status=seasonal-suspend.

Limitations

This section lists limitations for the Seasonal Suspend feature. These are conditions for which the Seasonal Suspend feature is not designed to work or works in a limited manner.

This feature is not available to Centrex or multiline hunt group (MLHG) subscribers.

The BTS 10200 does not support start and end timing for this feature.

Restrictions

This section lists restrictions. These are conditions that might cause this feature to fail or work improperly.

VMA Option

VMA, if provisioned and active, takes precedence over the Seasonal Suspend feature for treatment of inbound calls. The customer can call the VMA access DN (voice-mail pilot number) from any phone to use the voice-mail system. However, the following restrictions apply to calls placed from the seasonal subscriber line to the voice-mail pilot number:

The customer can reach the voice-mail pilot number from the seasonal suspend phone only by calling the pilot number directly. The customer cannot use a vertical service code (VSC) for this purpose, because VSCs do not work on a seasonal suspend line.

If you want the customer to be able to dial the voice-mail pilot number, you must provision this pilot DN for white list treatment in the national-wb-list table and link this DN to the seasonal suspend cos-restrict table. See the applicable steps in the "Office Provisioning" section of "Seasonal Suspend Provisioning for MR1 and Earlier" section in Cisco BTS 10200 Softswitch Provisioning Guide.

DN Readout by Announcement Server

Cisco has tested the ability of certain announcement servers to interwork with the BTS 10200 to provide DN-readout announcements. See the "Component Interoperability" section of the Cisco BTS 10200 Softswitch Release Notes for information on the capable announcement servers. Other announcement servers might also work, but might not have been tested for interoperability by Cisco.

Restoring COS Restrictions

When you provision a subscriber for seasonal suspend, you must create a special CoS restriction and assign it to the subscriber. This CoS restriction (cos-restrict-id in the Subscriber table) replaces the cos-restriction-id value that was originally assigned to this subscriber. The system does not track the original setting. Therefore, you must have a method of retaining a record of the original cos-restrict-id for each subscriber so you can restore it at the end of the seasonal suspend period.

Provisioning

Refer to the "Seasonal Suspend Provisioning for MR1 and Earlier" section in the Cisco BTS 10200 Softswitch Provisioning Guide.

Seasonal Suspend Feature for Release 5.0 MR1.1 and Later

Use this section if your system is running Release 5.0, MR1.1 or later.

Understanding the Seasonal Suspend Feature, MR1.1 and Later

The Seasonal Suspend feature allows subscribers to suspend their telephone service (instead of disconnecting it) while they are away for the off-season. This feature affects both inbound and outbound calls on the subscriber line.


Note In this document, inbound calls means calls that are intended to be terminated on the seasonal suspend subscriber line. Outbound calls means calls that are originated by a user on the seasonal suspend line.


Allowed and Disabled Features for Outbound Calls

During the suspension period, outbound calls are treated as follows. (The exact treatment depends on several provisioned values as described in this document.)

Allowed features—Emergency (911), toll-free customer service numbers such as repair (611), and voice mail. The subscriber can retrieve messages and access voice-mail functions by dialing the voice-mail pilot number.

Disabled features—All domestic and international inbound and outbound calling, operator services, directory assistance, caller ID blocking, vertical service codes (VSCs), midcall and hookflash-based features, and all calling features other than the allowed features listed above.

Treatment of Outbound Calls

You can provision the system (through the feature-configuration table) to provide special handling for outbound calls that are blocked by seasonal suspend. You can provide either of the following treatments:

Route outbound calls to a standard announcement indicating that seasonal suspend is active on the subscriber line. This is the default behavior.

Route outbound calls to a customer support line. (You provision the support line directory number [DN] in the feature-configuration table.)

Treatment of Inbound Calls

The system provides special handling for inbound calls that are rejected due to seasonal suspend status. You can provide either of the following treatments:

Play a generic seasonal suspend announcement. This is the default behavior.

Play a seasonal suspend announcement that includes a DN at which the subscriber can be reached. This DN is provisionable in the subscriber-feature-data table.

If the Voice Mail Always (VMA) feature is provisioned and active on the subscriber line prior to the time you set the subscriber status to seasonal suspend, VMA continues to function during the seasonal suspend period, and takes precedence over Seasonal Suspend features for inbound calls.

Deactivation of Seasonal Suspend

At the request of the subscriber, you can deactivate the Seasonal Suspend feature by setting status=active (or any status other than seasonal-suspend).


Note You can set the subscriber status to active, or to any other valid status other than seasonal-suspend, by provisioning the status parameter in the Subscriber table.


Feature Interactions

This section describes interactions of this feature with other telephony features.

VMA for inbound calls to the subscriber line—By design, VMA (if provisioned, activated, and available) takes precedence over any inbound call routing for seasonal suspend. In this case, the system provides VMA to all inbound calls, and not seasonal suspend.

Other calling features—If you assign seasonal suspend status to a subscriber, the system does not provide any other features for this subscriber except those listed below. You must provision these options through a special class of service (CoS) restriction for seasonal suspend. When you set the subscriber status to seasonal-suspend, the system automatically uses this system-wide seasonal suspend CoS restriction, and not the CoS restriction that is assigned individually to the subscriber. As described in the "Seasonal Suspend Provisioning MR1.1 and Later" section in the Cisco BTS 10200 Softswitch Provisioning Guide you can allow the following types of calls for subscribers in seasonal suspend status:

Calls with call type EMG (emergency calls)

Calls allowed in the seasonal suspend cos-restrict table, which can include repair, a customer service number, and a voice-mail pilot number if provisioned

Calls provisioned with the trigger-nod-escape-list command

The subscriber line can be used to make calls to a limited number of DNs, such as emergency services, customer service or repair service, voice-mail pilot number, or to other DNs allowed in the national-wb-list. During such a call, if an operator attempts to perform Busy Line Verification (BLV), the call from the operator receives the same treatment as that provisioned for any other incoming call to this subscriber, that is, forwarding to VMA or forwarding to a seasonal suspend announcement.

Billing treatment—The system generates the following billing cause codes for this feature:

Outbound calls that are blocked due to seasonal suspend result in the billing cause code SERVICE_DENIED. Outbound calls that are redirected to the customer service number result in normal billing record events.

Inbound calls that are blocked or redirected due to seasonal suspend result in billing cause code CALL_REJECTED.

Prerequisites

This section lists requirements that must be met before the feature can work.

Announcements

The appropriate announcements must be provisioned and available on the system, including announcements for generic seasonal suspend and DN referral. See release cause codes 1272 through 1275 and the associated announcements in the "Cause Code to Announcement ID Mappings" section of the Cisco BTS 10200 Softswitch Provisioning Guide. Routing to the announcement server must be working properly.


Note For features requiring an audible DN readout, such as seasonal suspend, the BTS 10200 has been tested for interoperability with the ThinkEngine Networks announcement server, Models 500X and 4000X.


VMA Treatment of Inbound Calls

This prerequisite applies if you are provisioning a customer with VMA treatment (instead of seasonal suspend treatment) for inbound calls.

The subscriber must have VMA activated and provisioned through the interactive voice response (IVR) provisioning system before you set the subscriber status to seasonal-suspend. If VMA is assigned and active, inbound calls to this subscriber are given VMA treatment instead of seasonal suspend treatment. However, outbound calls receive seasonal suspend treatment if status=seasonal-suspend.


Caution VMA, if assigned and active, takes precedence over the Seasonal Suspend feature. In this case, incoming calls do not receive seasonal suspend treatment. The incoming calls go directly to voice mail, and not to a seasonal suspend message, even if a seasonal suspend message is provisioned. Therefore, if the end user wishes to have seasonal suspend treatment for inbound calls, make sure that VMA is deactivated before setting status=seasonal-suspend.

Limitations

This section lists limitations for the Seasonal Suspend feature. These are conditions for which the Seasonal Suspend feature is not designed to work or works in a limited manner.

This feature is not available to Centrex or multiline hunt group (MLHG) subscribers.

The BTS 10200 does not support start and end timing for this feature.

Restrictions

This section lists restrictions. These are conditions that might cause this feature to fail or work improperly.

VMA Option

VMA, if provisioned and active, takes precedence over the Seasonal Suspend feature for treatment of inbound calls. The customer can call the VMA access DN (voice-mail pilot number) from any phone to use the voice-mail system. However, the following restrictions apply to calls placed from the seasonal subscriber line to the voice-mail pilot number:

The customer can reach the voice-mail pilot number from the seasonal suspend phone only calling the pilot number directly. The customer cannot use a vertical service code (VSC) for this purpose, because VSCs do not work on a seasonal suspend line.

If you want the customer to be able to dial the voice-mail pilot number, you must provision this pilot DN for white list treatment in the national-wb-list table and link this DN to the seasonal suspend cos-restrict table. See the applicable steps in the "Seasonal Suspend Provisioning for MR1.1 and Later" section in Cisco BTS 10200 Softswitch Provisioning Guide.

DN Readout by Announcement Server

Cisco has tested the ability of certain announcement servers to interwork with the BTS 10200 to provide DN-readout announcements. See the "Component Interoperability" section of the Cisco BTS 10200 Softswitch Release Notes for information on the capable announcement servers. Other announcement servers might also work, but might not have been tested for interoperability by Cisco.

Provisioning

For details on provisioning the "Seasonal Suspend feature for MR1.1 and Later", refer to Cisco BTS 10200 Softswitch Provisioning Guide.

Terminal and Group Make Busy Services

The Terminal Make Busy (TMB) and Group Make Busy (GMB) features enable the Cisco BTS 10200 Softswitch to give incoming callers the impression that specific terminals within a multiline hunt group (MLHG) or all members of the MLHG are busy. When you activate TMB or GMB, the BTS 10200 provides incoming callers with:

A busy signal when the called directory number (DN) is associated with an MLHG when TMB is activated

or

The next available number in the hunt sequence when a specific terminal DN within an MLHG is called and GMB is activated.

You can activate TMB for individual DNs or extensions within an MLHG, and you can activate GMB for the entire hunt group.

The BTS 10200 supports the following make busy services:

Terminal Make Busy Activation (TMBA)

Terminal Make Busy Deactivation (TMBD)

Group Make Busy Activation (GMBA)

Group Make Busy Deactivation (GMBD)

You activate and deactivate the TMB and GMB features by entering a vertical service code (VSC).

The BTS 10200 supports the TMB and GMB features for MLHG subscribers provisioned as any of the following subscriber types:

MLHG

MLHG-Individual

MLHG-Pref-Individual

CTXG-MLHG

For descriptions and definitions of the MLHG categories listed above, refer to Multiline Hunt Group (MLHG) in the Cisco BTS 10200 Softswitch Network and Feature Descriptions Guide.

TMB

You can assign the TMB feature to individual terminals associated with an MLHG by adding the feature to the MLHG and specifying the VSC, custom dial plan, and subscriber service. The subscriber activates and deactivates the feature by entering the appropriate vertical service codes.

When the subscriber activates TMB for a specific terminal, the BTS 10200 skips the terminal in the hunting sequence and gives the call to the next nonbusy terminal in the MLHG.

When the subscriber activates TMB for all terminals in the MLHG, the call is automatically given a busy tone or forwarded to voicemail if voicemail is provisioned.

The subscriber can originate calls from the terminal even if TMB is active.

GMB

Any subscriber within the MLHG that supports the GMB feature can activate or deactivate the feature. When GMB is active, the calling party receives a busy tone when dialing the MLHG pilot DN or main subscriber. None of the members of the MLHG receives the call and the hunt mechanism is disabled. If the subscriber has forwarding busy treatments such as Call Forward Busy (CFB) and voicemail activated, the BTS 10200 forwards the calls even with GMB activated.

The subscriber can originate calls from any terminal within the MLHG even if GMB is active.

Feature Interactions

The TMB and GMB features interact only with the CFB and voicemail features.

TMB

When TMB is activated for the subscriber, the BTS 10200 provides the calling party with an off-hook busy tone when they activate most features. The BTS 10200 disables Call Waiting (CW) and Caller ID on Call Waiting (CIDCW) for all MLHG customers. The system does not apply the CW tone on the pilot DN or MLHG terminals any time TMB is activated.

The BTS 10200 supports normal behavior for CFB and voicemail when TMB is activated. Refer to Multiline Hunt Group (MLHG) for additional information about MLHG features.

Table 3-9 and Table 3-10 provide examples of normal interactions between TMB and CFB.

CFB Is Active for Pilot DN And Terminals

Table 3-9 TMB—CFB Conditions and Actions: Pilot and Terminals

Called Number
Condition of Called Number
BTS 10200 Action

Pilot DN

Pilot busy

Hunt for next available terminal

Pilot and all terminals busy

Call forwarded per CFB

MLHG terminal

MLHG terminal busy

Hunt for next available terminal

All terminals busy

Call forwarded per CFB


CFB Is Active for Terminals Only

Table 3-10 TMB—CFB Conditions and Actions: Terminal Only

Called Number
Condition of Called Number
BTS 10200 Action

Pilot DN

Pilot busy

Hunt for next available terminal

Pilot and all terminals busy

Busy tone

MLHG terminal

MLHG terminal busy

Hunt for next available terminal

All terminals busy

Call forwarded per CFB


GMB

The BTS 10200 supports normal behavior for CFB and voicemail when GMB is activated.

Configuring

For details on configuring the TMB and GMB features, refer to Cisco BTS 10200 Softswitch Provisioning Guide.

Features for Centrex Subscribers Only

The Cisco BTS 10200 Softswitch provides Centrex-group functionality. A Centrex group is an emulation of a PBX by a Class 5 switch, and is typically assigned to a business group. The service provider can provision the values for the main subscriber of the Centrex group, and those properties are applied to the entire Centrex group. The service provider can also provision the parameters for simulated facility group (SFG) control, if SFG is desired. Both the incoming SFG (ISFG) and outgoing SFG (OSFG) are provisionable.


Tip To provision a Centrex group, see the Centrex Group provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


The following features are available to Centrex subscribers only:

Call Hold (CHD)

Call Park and Call Retrieve

Direct Inward/Outward Dialing for Centrex

Directed Call Pickup (With and Without Barge-In)

Distinctive Alerting/Call Waiting Indication (DA/CWI)

Call Hold (CHD)

The Cisco BTS 10200 Softswitch supports the call hold (CHD) feature as specified in LSSGR module FSD 01-02-1305 (TR-TSY-000579), Add On Transfer And Conference Calling Features.


Note This feature is available only to Centrex subscribers.


Description

The CHD feature allows the user to temporarily put an active call on hold and then make another call. The user can then return to the original call, and alternate between the two calls.

A party involved in an active call can use the CHD feature as follows:

The user (the activating party) presses the Flash button or hookswitch and then presses the VSC for CHD (for example, *52).

The network responds by putting the remote station on hold, providing silent termination. The system also returns a stutter dial tone to the activating party.

If the activating party does nothing, the network waits 4 seconds, then removes the dial tone. In this case, the activating party can resume the call (recall the held party) by using the Flash button or hookswitch.

If the activating party dials another remote station, then the system rings that station, and a new call is initiated if the remote station goes off hook.

The CHD activation procedures (Flash button or hookswitch followed by the CHD VSC *52) can be used to toggle between the two calls. If the activating party disconnects while a party is on hold, the network responds by ringing the activating party's line. If the line is not answered within 6 ring cycles, the held party is disconnected. The held party does not hear an audible ringback during this ringing cycle.

Feature Interactions with CHD

The following feature interactions apply to CHD.

CHD and Emergency Number

There is an interaction when a Centrex subscriber invokes call hold (CHD) and places a call to an emergency number:

When the emergency operator answers the call, a two-party call is active between the subscriber and the emergency operator. The on-hold party remains on hold.

When the subscriber presses the Flash button or hookswitch, a three-way call is established among the subscriber, the emergency operator, and the previously on-hold party.

It is not possible to place the emergency operator on hold.

CHD with CW/CIDCW and CFNA/VM/VMA

There is an interaction when a Centrex subscriber has all three of the following features assigned and active:

1. Call hold—CHD.

2. Call waiting—CW or CIDCW or both.

3. Call forwarding on no answer—CFNA, VM (or VMA), or any combination of these.

(Prior to Release 5.0 Maintenance Release 1.1) In this case, the system does not invoke forwarding for any incoming calls. If the subscriber wants to have the call-waiting features (CW or CIDCW) and call-forwarding features (CFNA, VM, or VMA) active simultaneously, the service provider should not assign the CHD feature to that subscriber.

(Release 5.0 MR1.1 and later) The system behavior is illustrated in the following example. In this example, CFNA is assigned and active on subscriber (A) along with CHD and CW.

A and B are on an active call.

C calls A.

A hears the CW tone. (C hears ringback.)

If A presses the Flash button or hookswitch, B is put on hold and A hears a dial tone.

If A dials *52, A is connected to C.

If A ignores the CW tone, C continues to hear ringback until the CFNA timer expires, then the call from C is forwarded per CFNA.

CHD and CFNA

If CHD is assigned to the subscriber (A) along with CFNA (CFNA active), the following interaction occurs.

A and B are on an active call.

C calls A.

C hears a busy tone and is not connected. The call from C is not forwarded by the CFNA feature.

CHD and CW

If CHD is assigned to the subscriber (A) along with CW, the following interaction occurs.

A and B are on an active call.

C calls A.

A hears the CW tone. (C hears ringback.)

If A presses the Flash button or hookswitch, B is put on hold and A hears a dial tone.

If A dials *52, A is connected to C.

If A ignores the CW tone, C continues to hear ringback. The call is not forwarded.

Feature Provisioning

To provision this feature, see the CHD provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.

Call Park and Call Retrieve


Note This feature is available only to Centrex subscribers.


Call park (CPRK) and call retrieve (CPRK-RET) are defined for a call park subscriber group (CPSG), which is a subset of the Centrex subscriber group who have privileges to park and retrieve calls. Members of the CPSG can park and retrieve calls on a DN within their own CPSG. If desired, this feature can be used to transfer calls from one CPSG member to another.

CPRK allows a user in a business group to park an active call on a designated parking DN, leaving the user free to make other calls. The parked caller is placed on hold. The parking party is periodically reoffered the parked call. If the parking party accepts the reoffer attempt, or if another authorized user in the CPSG retrieves the call, then the call is connected. Otherwise, after three reoffer attempts, the call is released or forwarded as provisioned.

To park an active call:

The parking party uses the Flash button or hookswitch, receives a recall dial tone, and dials the CPRK Access Code

The parking party dials the DN of the desired CPSG member (or just hangs up or dials # to park the call against their own DN)

A confirmation tone is provided to the parking party to confirm that the call is parked

To retrieve a parked call:

The retrieving party dials the CPRK-RET access code and gets a dial tone

The retrieving party dials the DN on which the call is parked

The call is now connected between the calling party and the retrieving party

There is no deactivation procedure for this feature. The parked call is either connected or forwarded as described above.


Tip To provision this feature, see the CPRK provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Direct Inward/Outward Dialing for Centrex


Note This feature is available only to Centrex subscribers.


The Cisco BTS 10200 Softswitch supports the following direct inward/outward dialing features for Centrex systems as specified in LSSGR module FSD 01-01-1000 (TR-TSY-520), Basic Business Group:

DID, including distinctive alerting and call-waiting tone—DID provides a Centrex group with the ability to receive a call from the PSTN without attendant intervention. The receiving Centrex station appears as a serving line to the CA. To provide a distinctive alerting and call-waiting tone, the service provider assigns the Distinctive Alerting/Call Waiting Indication (DA/CWI) feature to the subscriber.


Note For the distinctive call-waiting tones to be played, either the Call Waiting (CW) feature or the Call Waiting Deluxe (CWD) feature must also be assigned and active on the subscriber line.


DOD provides a Centrex group with the ability to make a call to the PSTN without attendant intervention. The sending Centrex station appears as a serving line to the CA.

Directed Call Pickup (With and Without Barge-In)


Caution Do not provision this feature for subscribers other than Centrex subscribers. This feature will not work for subscriber other than Centrex Subscribers.

Directed call pickup allows a user in a basic business group (BBG) to answer a call to a telephone from another telephone in the BBG. There are two types of directed call pickup, with and without barge-in, each with its own activation access code. These codes are assigned by the administrator of the BBG, and can range from 2 to 65535.

The procedure for directed call pickup without barge-in (DPN) is as follows:

The process begins when a telephone rings in the BBG, and a member of the BBG at a remote phone would like to pick up the call from the ringing telephone line

At the remote telephone line, the user lifts the handset, and listens for a dial tone

The remote user dials the DPN activation access code *xx (where xx represents the digits assigned for DPN activation in the BBG)

The system returns a recall dial tone

The remote user dials the extension associated with the ringing line

The remote line is connected to the incoming call that actually terminated at the ringing line

The original called line is now idle and available to originate and to receive calls

If the incoming call has already been picked up by another member of the BBG, the additional DPN requests are routed to a reorder tone.

The procedure for directed call pickup with barge-in (DPU) is as follows:

The process begins when a telephone rings in the BBG, is answered by the party, and another member of the BBG at a remote line wants to join the conversation

At the remote telephone line, the user lifts the handset, and listens for a dial tone

The remote user dials the DPU activation access code *xx (where xx represents the digits assigned for DPU activation in the BBG)

The system returns a recall dial tone

The remote user dials the extension on which the active call is taking place

The system plays a confirming tone and establishes a three-way call (TWC) between the remote line and the original two parties

The remote BBG user can press the Flash button or hookswitch to drop the other BBG party related to the original call

If the remote BBG user goes on hook, the two-way connection will be reestablished between the calling party and the original BBG party


Tip To provision these features, see the DPN and DPU provisioning procedures in the Cisco BTS 10200 Softswitch Provisioning Guide.


Distinctive Alerting/Call Waiting Indication (DA/CWI)


Note This feature is available only to Centrex subscribers.


The distinctive alerting/call waiting indication (DA/CWI) feature is based on the Telcordia document GR-520-CORE, Features Common to Residence and Business Customers I (FSDs 00 to 01-01-1110). DA/CWI provides Centrex users special ringing and CW tones on DID calls. The Centrex administrator can activate this feature for some or all of the business group lines (BGLs) in the basic business group (BBG). Any call terminating at a designated BGL will receive the appropriate distinctive ringing or CW tone. When enabled, the subscriber can receive different ringing patterns (distinctive ringing) and CW alerting as follows.

Calls originating within the same Centrex (also referred to as inside calls or extension dialing):

Ringing pattern: 2 seconds of ringing followed by 4 seconds of silence

CW pattern: 0.3-second beep

Incoming calls originating outside the Centrex (outside calls, including calls from a different Centrex group):

Ringing pattern: 800 ms of ringing, 400 ms of silence, 800 ms of ringing, 4 seconds of silence

CW pattern: 0.1 seconds beep, 0.1 seconds silence, 0.1 seconds beep


Note For the distinctive call-waiting tones to be played, either the Call Waiting (CW) feature or the Call Waiting Deluxe (CWD) feature must also be assigned and active on the subscriber line.



Tip To provision this feature, see the DA/CWI provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Additional Features Applicable to Centrex and POTS

The following additional features are available to both Centrex and POTS subscribers:

Anonymous Call Rejection (ACR)

Automatic Callback (AC)—Repeat Dialing

Automatic Recall (AR)—Call Return

Call Block - Reject Caller (CBLK)

Call Transfer (CT)

Change Number (CN)

Customer-Originated Trace (COT)

Do Not Disturb (DND)

Hotline Service

Hotline-Variable Service (HOTV)

Interactive Voice Response (IVR) Functions

Limited Call Duration Service (Prepaid/Postpaid) with RADIUS Interface to AAA

Message Waiting Indicator (MWI)—Audible and Visual

Multiline Hunt Group (MLHG)

Multiline Variety Package

Multiple Directory Numbers (MDN)

No Solicitation Announcement (NSA)

Own Calling Number Announcement (OCNA)

Privacy Screening (Calling Identity with Enhanced Screening)

Speed Call

Subscriber-Controlled Services and Screening List Editing (SLE)

Selective Call Forwarding (SCF)

Selective Call Acceptance (SCA)

Selective Call Rejection (SCR)

Distinctive Ringing/Call Waiting (DRCW)

Temporarily Disconnected Subscriber Status and Soft Dial Tone

Three-Way Calling (TWC)

Three-Way Calling Deluxe (TWCD)

Usage-Sensitive Three-Way Calling (USTWC)

Voice Mail (VM) and Voice Mail Always (VMA)

Warmline Service

Anonymous Call Rejection (ACR)

The BTS 10200 supports the anonymous call rejection (ACR) feature as specified in LSSGR module FSD 01-02-1060 (TR-TSY-000567), Anonymous Call Rejection.

The ACR feature allows users to reject calls from parties that have set their privacy feature to prevent calling number delivery. When ACR is active the called party receives no alerting of incoming calls that are rejected. The incoming call is rerouted to a denial announcement indicating that private numbers are not accepted by the called party. To complete a call to the party with ACR, the calling party must enter the VSC to activate calling identity delivery (for example, *82 for CIDSD) and then place a call to the party with ACR. Incoming calls to the called party with ACR are checked even if the called party is off hook.

If the BTS 10200 does not receive the calling party information in the incoming message, or if it does not receive the privacy setting in the incoming message, or if the privacy setting is unknown, the following process occurs. The system checks a provisionable parameter (PRIVACY-UNKNOWN-TREATMENT) in the Feature Configuration (feature-config) table. This parameter by default is set to PUBLIC, which means the incoming call is treated as public and is not rejected by the ACR feature. The service provider has the option to set this parameter to ANONYMOUS, which means the incoming call is treated as anonymous and is rejected by the ACR feature.

ACR has multiple activation options as follows:

Activated permanently at subscription time by service provider.

Activated by user:

The user lifts the handset, and listens for a dial tone.

The user presses the activation VSC (for example, typically *77 in North America). If ACR can be activated, the system returns a success announcement.

ACR is now activated, and will stay active until it is deactivated.


Note If the user tries to activate ACR when it is already active, the system treats the new activation attempt as a new attempt.


ACR deactivation options are as follows:

Service provider deactivation at user request.

Deactivated by user:

The user lifts the handset and listens for a dial tone.

The user presses the deactivation VSC (for example, typically *87 in North America). The system responds with a success announcement.

ACR is now deactivated, and will stay inactive until it is activated.


Note If the user tries to deactivate ACR when it is already deactivated, the system accepts and processes the new deactivation attempt as a new attempt.



Tip To provision this feature, see the ACR provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Automatic Callback (AC)—Repeat Dialing

Automatic callback (AC), also called repeat dialing, allows the user to request the system to automatically redial the most recently dialed number. The system will keep attempting to call the number for up to 30 minutes. If the called party is busy when AC is activated, call setup is automatically performed when the called station becomes idle. The system alerts the calling party with distinctive ringing. Up to 20 AC requests can be active at any time. The service provider can set up this service for the user, or the user can access it on a usage-sensitive basis.


Note For intra-office AC with ARAC-TERMINATING-SPCS-SCAN-ALLOW;VALUE=Y, the feature operates as expected during a Feature Server switchover. However, for inter-office AC with the same switchover condition, the feature fails because TCAP is not replicated.


AC is activated as follows:

The user calls a remote station, receives a busy signal or no answer, and hangs up.

The user lifts the handset again, and listens for dial tone.

The user enters the VSC for AC activation (for example, *66). One of the following scenarios will occur:

Audible ring—Indicates that the call setup is being attempted immediately.

The delayed processing announcement—This announcement is given to indicate that the line the customer is calling is busy and that the system will attempt to complete the call when the called line is idle.

A short term denial announcement, such as "We are sorry. Your AC request cannot be processed at this time. Please try again later or dial directly."

A long term denial announcement, such as "The number you are trying to reach cannot be handled by AC. Please dial directly."

A denial announcement, such as "The called party has a call rejection feature active and is not accepting calls from you."

AC is deactivated as follows:

The user goes off hook, receives a dial tone, and dials the deactivation code (for example, *86).

Once the deactivation code is dialed the user hears an announcement stating that all outstanding AC requests have been deactivated.


Note The AC feature can be made available to all subscribers lines connected to a BTS 10200 using the default office service ID, or to all subscribers in a specific POP using the office service ID. See the "Office Service ID and Default Office Service ID" section for a general description of this provisionable service.



Tip To provision this feature, see the AC provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Automatic Recall (AR)—Call Return

Automatic Recall (AR), also called call return, allows the user to request the system to automatically redial the DN of the last incoming call (that is, the station that called the user). The AR subscriber does not need to know the telephone number or the calling party of the last incoming call. If the remote party is busy when AR is activated, the system continues attempting to call the number for up to 30 minutes, and automatically performs call setup when the called station becomes idle. The system alerts the calling party (the party that initiated the AR) with distinctive ringing. Up to 20 AR requests can be active at any time.

The service provider can set up the AR feature on a system-wide or POP-wide basis, or the user can access it on a usage-sensitive basis.

There are two variants of AR feature activation, one-level and two-level. With one-level activation, the user activates the AR feature without knowing the last calling party number. With two-level AR activation, the user hears a voice announcement of the last incoming calling party number, the date and time when the call was received, and a voice instruction for activating an AR call to that party.

Reference: LSSGR module FSD 01-02-1260 (GR-227-CORE), Automatic Recall.


Note For intra-office AR with ARAC-TERMINATING-SPCS-SCAN-ALLOW;VALUE=Y, the feature operates as expected during a Feature Server switchover. However, for inter-office AR with the same switchover condition, the feature fails because TCAP is not replicated.


One-Level Activation of AR

One-level AR is activated as follows:

The user receives a call (ringing) from a remote station, but does not pick up.

The user lifts the handset and listens for dial tone.

The user enters the VSC for activation (for example, *69). One of the following scenarios will occur:

Audible ring—Indicates that the call setup is being attempted immediately.

The delayed processing announcement—This announcement is given to indicate that the line the customer is calling is busy and that the system will attempt to complete the call once the called line is idle.

A short term denial announcement, such as "We are sorry. Your AR request cannot be processed at this time. Please try again later or dial directly."

A long term denial announcement, such as "The number you are trying to reach cannot be handled by AR. Please dial directly."

A denial announcement, such as "The called party has a call rejection feature active and is not accepting calls from you."

AR is deactivated as follows:

The user goes off hook, receives a dial tone, and dials the deactivation code (for example, *89).

Once the deactivation code is dialed the user hears an announcement stating that all outstanding AR requests have been deactivated.

Two-Level Activation of AR

Two-Level AR activation is an extension of the one-level AR feature. It requires communications with an IVR server, which delivers the voice readout of the calling-party number, provides appropriate voice prompts, and collects the user's response.

First stage—The user dials the activation code (for example, *69) and hears a voice announcement of the last incoming calling party number, the date and time when the call was received, and a voice instruction for activating an AR call to that party. The user can hang up to discontinue AR activation toward that party.

Second stage—If the subscriber follows the instruction and presses "1", the system activates the AR call.


Note During the second stage, the system automatically checks for invalid digits and timeouts.


The deactivation procedure for two-level AR is the same as for one-level AR.


Note The AR feature can be made available to all subscribers lines connected to a BTS 10200 using the default office service ID, or to all subscribers in a specific POP using the office service ID. See the "Office Service ID and Default Office Service ID" section for a general description of this provisionable service.



Tip For more details about the IVR interactions for this feature, see Chapter 6, "Interactive Voice Response Functions."


Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the AR provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Call Block - Reject Caller (CBLK)

The call block (CBLK) feature, also referred to as the reject-caller feature, allows the user to block incoming calls from the DN of the last received call. For the call block feature to work, the user must already be subscribed to the selective call rejection (SCR) feature. Once call block is activated against a specified DN, that DN remains in the SCR list of the subscriber. A subscriber who wishes to block callers (like sales calls, etc.) but does not know the caller's DN, can use this feature. Call block can be provided to POTS, Centrex, and MLHG subscribers.

Provisioning call block includes the following CLI operations:

Configuring the feature table for call block

Provisioning a two-digit star code (*xx) for call block activation:

Adding a star code entry in the VSC table (for POTS subscribers)

Adding a star code entry in the custom dial plan table (for Centrex subscribers)

Creating a service with call block and SCR

Assigning the service to the subscriber via the subscriber service profile table

An idle user (if subscribed to SCR) can dial the call block activation code indicating that the last incoming caller's DN is to be added to their SCR list.

A confirmation tone is given to indicate successful activation. In cases of error or the user not subscribed to call block, a reorder tone is given. If the user is trying to activate call block while on an active call, the user is reconnected to the original call.

The user can deactivate call block for this DN by removing the DN from their SCR list. This is done by using the screen list editing (SLE) function of the SCR feature.


Note For details of the SCR feature, see the "Selective Call Rejection (SCR)" section.



Tip To provision this feature, see the CBLK provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Block All Inbound Calls

If the subscriber has blocked all the inbound calls, the calling party hears an announcement stating that called party has chosen to deny all inbound calls.


Note A personalized announcement can be provided by provisioning an announcement ID specifically defined for the subscriber. Use the announcement ID 800 through 899 for custom announcements.



Tip To provision this feature, see the Block All Inbound Calls provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Call Transfer (CT)

The Cisco BTS 10200 Softswitch supports the call transfer (CT) feature as specified in LSSGR module FSD 01-02-1305 (TR-TSY-000579), Add On Transfer And Conference Calling Features.

CT allows a user to add a third party or second call to an existing two-party call. CT also allows the user to hang up while involved in the two calls and connect the remaining two parties in a two-way connection.

To activate a CT call, a user (A) involved in a stable two-way call (with B) takes the following steps:

User A (the initiating party) presses the Flash button or hookswitch. This places the remote end (B) on hold and returns a recall dial tone.

User A dials the DN of the third party (C).


Note If A presses the Flash button or hookswitch before completing dialing, the original two-way connection is reestablished between A and B.


When C answers, only A and C can hear and talk. This allows A to speak privately with C before sending the second flash.

If A presses the Flash button or hookswitch after successfully dialing C, a three-way conference is established regardless of whether C answers the call.

The following scenarios occur, depending upon the actions of the parties in the call:

If A hangs up after successfully dialing C (C is ringing), a two-way call is established between B and C, regardless of whether C answers the call. User A is billed for a call transfer and is also billed for the duration that the other two parties are on the call.

If A waits until C answers the call, and then A hangs up, a two-way call is established between B and C. User A is billed for a call transfer and is also billed for the entire duration starting from the time A initiated the TWC until B and C hang up.

Feature Provisioning Commands

To provision this feature, see the CT provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.

SIP Call Transfer with REFER and SIP Invite with REPLACES

Call transfer is performed by SIP systems through the following features:

SIP call transfer with REFER

SIP Invite with REPLACES

For information on these features, see the "SIP Call Transfer with REFER and SIP Invite with REPLACES" section in the Cisco BTS 10200 Softswitch SIP Feature and Provisioning Guide.

Change Number (CN)

The change number (CN) feature, also refered to as the call referral feature, enables the service provider to change the directory number of a subscriber. In addition, the Change Number feature provides a mechanism to track the last time and date a call referral number change announcement was activated or requested in association with a subscriber phone number change or disconnect. This allows the service provider to query the subscriber number changed status in the BTS 10200 system in order to find out how long the number changed announcement (call referral) has been active for the subscriber. The call referral announcement is activated when a phone number is disconnected or changed. An announcement is played when someone calls the number indicating that the number has been disconnected or; if changed, indicating that the new number is xxx-xxx-xxxx. If there is no new phone number, a generic announcement is played indicating only that the number has changed or has been disconnected. Either type of announcement will be played until disabled by the service provider. To change the directory number of a subscriber and to setup and disable the call referral announcements, refer to the "Managing Subscribers" section of the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.

Customer-Originated Trace (COT)

Customer-originated trace (COT) allows users who have been receiving harassing or prank calls to activate an immediate trace of the last incoming call, without requiring prior approval or manual intervention by telephone company personnel.

After a harassing or prank call is terminated, a user who wishes to trace the call goes off hook, receives a dial tone, and dials the COT activation code (for example, *57). When the trace has been completed, the user receives a COT success tone or announcement, such as, "You have successfully traced your last incoming call. Please contact your telephone company for further assistance." (Information about a traced call is made available to the telephone company or to a telephone company-designated agency, usually law enforcement, but not to the user who initiated the trace). Because COT is activated on a per-call basis, the service is deactivated when the user goes on hook.

If the trace cannot be performed, an appropriate tone or announcement is played. COT is inhibited on the following subscriber categories:

PBX

RACF

IVR

CTXG_TG


Note For an incoming call to be traced, the incoming call must have been answered by the called party.


All COT trace records are stored in the EMS of the BTS 10200 for retrieval purposes. A maximum of 10,000 traces are stored in a circular file format (oldest record overwritten).


Note The COT feature can be made available to all subscribers lines connected to a BTS 10200 using the default office service ID, or to all subscribers in a specific POP using the office service ID. See the "Office Service ID and Default Office Service ID" section for a general description of this provisionable service.



Tip To provision this feature, see the COT provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Do Not Disturb (DND)

The do not disturb (DND) feature, when activated, blocks all incoming calls to the subscriber line. This feature can be activated and deactivated by the individual user via the handset. DND routes incoming calls (calls destined for the user's DN) to a DND announcement. When a call comes in to a line on which DND is active, the called party receives a reminder ring (provided the service provider has provisioned the DND feature with reminder ring enabled). The user is not able to receive the call. A user can enter the activation code (for example, *78) on the handset to enable this service, and the deactivation code (for example, *79) to disable the service.


Note The reminder ring cannot be used with SIP devices.



Tip To provision this feature, see the DND provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Hotline Service

Hotline service is a dedicated private line between a subscriber phone and a predetermined DN. The service is activated by the service provider at the request of the subscriber. When the hotline user picks up the phone, the Cisco BTS 10200 Softswitch rings the predetermined DN instantly.

An exclusive telephone DN is required for the hotline feature, and certain limitations apply to its use:

Certain limitations apply to the use of the hotline feature:

An exclusive telephone DN is required for the hotline feature.

None of the VSC star (*) features are available on this line

Only the service provider can deactivate hotline service.


Note See also the "Warmline Service" section. Warmline service is a combination of hotline service and regular phone service.



Tip To provision this feature, see the Hotline provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Hotline-Variable Service (HOTV)

This section describes the hotline-variable feature.

Hotline-Variable Feature Description

Hotline-variable service allows the user to go off hook, receive dial tone, and let the system call a specified DN automatically after a dial-tone timeout. The service provider provisions the hotline-variable dial-tone timeout for the system (default is 4 seconds) and assigns the hotline-variable feature to individual subscribers. The user activates the hotline-variable service on his or her line and specifies the remote DN using the handset. Once activated, the service works as follows:

Use of hotline-variable for regular calling—The user takes the handset off hook, receives dial tone, and starts dialing a regular call before the dial-tone timeout expires.

Use of hotline-variable as a hotline—The user takes the handset off hook, receives dial tone, but does not dial any digits. After the dial-tone timeout expires, the system automatically calls the user-specified DN.


Caution The HOTV feature operates only with MGWs that are compliant with MGCP1.0 (per IETF document RFC 2705) or higher. It is not supported on MGCP0.1 MGWs.

The following conditions and limitations apply to the hotline-variable feature:

The hotline-variable feature can be provided to POTS, Centrex, and MLHG subscribers.

The hotline-variable feature is in the deactivated mode unless activated by the subscriber. Once activated, the feature remains in the activated mode until deactivated.

None of the VSC star (*) features are available on this line, other than the VSC codes for hotline-variable activation, deactivation, and interrogation.

This remote DN is referred to as the B-number. The allowed types of B-numbers are listed in Table 3-11.

Table 3-11 Allowed Types of B-numbers

Subscriber Type
Allowed B-number

POTS

DN, without extensions

Centrex

Public access code + external DN, without extensions

An extension within the business group


The hotline-variable feature is composed of four associated features, which are described in the sections that follow:

Hotline-Variable Activation

Hotline-Variable Deactivation

Hotline-Variable Interrogation

Hotline-Variable Invocation

Hotline-Variable Activation

Hotline-variable activation allows a user to activate the hotline function on his or her local phone. The user does this by going off hook and receiving dial tone, then dialing *52*B-number#, where:

*52* is an example of the activation VSC for HOTV (VSCs are provisionable by the service provider)

B-number is the remote DN that the user wants to reach via hotline calling

# is a trailing symbol that identifies the end of B-number digits

A success announcement is given on a successful activation, and an error announcement indicating the type of error is given if activation is unsuccessful.

The system screens the DN entered for the B-number, and denies the activation attempt if any of the following conditions apply:

1. The call type is restricted in the NOD-RESTRICT-LIST table for HOTV

2. The call is restricted for the subscriber by the OCB feature

3. HOTV is already activated

A successful activation results in overwriting the previous DN recorded for hotline-variable.

Hotline-Variable Deactivation

Hotline-variable deactivation allows a user to deactivate hotline-variable on his or her local phone. An example of a dial string for hotline-variable deactivation is #52#. A success announcement is given on a successful deactivation, and an error announcement, indicating the type of error, is given if deactivation is unsuccessful.

Hotline-Variable Interrogation

Hotline-variable interrogation allows a user to check whether hotline-variable is activated to a particular remote phone. An example of a dial string for hotline-variable interrogation is *#52*B-number#. A success announcement is given to the user if hotline-variable is activated to the B-number. If hotline-variable is not activated, or if hotline-variable is activated to a different phone, an appropriate error announcement will be provided to the user. If the user has hotline-variable activated to the B-number, a success announcement is provided. Otherwise an error announcement is provided.


Note If the user enters a digit string that does not match exactly the B-number against which hotline-variable was activated, the interrogation attempt will result in an error announcement.


Hotline-Variable Invocation

Hotline-variable invocation is the actual procedure the system follows when the user goes off hook, provided that the feature is subscribed and activated. If the user begins dialing digits before the dial-tone timeout period expires, the system attempts to complete the call to the dialed DN. If the user dials no digits until the dial-tone timeout period expires, the system automatically calls the predetermined hotline destination B-number.

Invalid User Actions

The valid user actions are described in the sections above. The following user actions are invalid, and the system provides an appropriate error announcement:

The user enters an invalid directory number (DN) for the B-number.

During HOTV activation, the user enters a B-number that is determined by the FS to be a call type blocked by provisioning in the NOD-RESTRICT-LIST table. For example, the nature of dial (NOD) from the user's phone to the B-number is an emergency call, but emergency calls are blocked by provisioning in the NOD-RESTRICT-LIST table.

The user tries to activate hotline-variable from a DN that has outgoing calls blocked by the OCB feature, or the user enters a B-number, but calls to that DN are blocked by OCB. For example, the call from the user's phone to the B-number would be a domestic long distance call, but these calls are blocked by setting K=2 against the OCB feature in the SUBSCRIBER-FEATURE-DATA table.

The user tries to activate hotline-variable to an international DN, but the service provider has blocked forwarding to international DNs. The service provider can block forwarding to international DNs using the OCB feature.

The user tries to activate hotline-variable when already activated (the B-number is not overwritten).

The user tries to activate hotline-variable to his or her own extension or DN.

The user tries to deactivate hotline-variable when already deactivated.

The user interrogates hotline-variable, but enters a digit string that does not match exactly the B-number against which hotline-variable was activated. For example, if hotline-variable was activated with a 5-digit string corresponding to a Centrex extension, and interrogation is attempted using a 10-digit string of the complete DN, the interrogation attempt will result in the applicable announcement. (See the complete list of standard Cisco BTS 10200 announcements in the Cisco BTS 10200 Softswitch Provisioning Guide.)

The user tries to interrogate hotline-variable on a fresh system (a system with no entry in the SUBSCRIBER-FEATURE-DATA table). In this case, the user receives the error announcement immediately after entering the VSC (for example, *#52*). The system does not wait for the user to enter the B-number.

HOTV Feature Interactions

HOTVA and OCB—If the user tries to activate hotline-variable to a DN, but calls to that DN are blocked by OCB, the activation is denied, and the user receives an error announcement.

HOTV and OCB—If the user has already activated hotline-variable successfully to a DN, and then restricts calls to this DN via the OCB feature, future hotline-variable calls will be denied, and an error announcement will be provided to the user.

Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the HOTV provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Interactive Voice Response (IVR) Functions

The system supports interactive voice response (IVR) functions through an external IVR server deployed in the service provider network. IVR functions are used with several of the subscriber features, including RACF, two-level AR, SCA, SCF, SCR, and NSA.

To begin an IVR session for the subscriber, the BTS 10200 establishes an RTP connection between the IVR server and the incoming gateway (a MGW or integrated access device, IAD). This connection is illustrated in Figure 3-2.

Figure 3-2 IVR Connections

Following is the call scenario for IVR.


Note During this process, the Feature Server (FS) and Call Agent (CA) exchange IVR instructions as needed.


1. The incoming call arrives at the incoming gateway (MGW or IAD).

2. The CA sets up an RTP connection between the IVR server and the incoming gateway.

3. The IVR server communicates with the gateway and sends the IVR result to the CA.

4. The CA stops the IVR connection.

The following limitations apply to IVR functions:

The feature is not supported for SS7, H.323, or SIP endpoints.

The BTS 10200 does not support local IVR capability. Instead it relies on IVR capabilities provided from an external IVR server supporting the MGCP BAU package.

For IVR trunk groups, LOCAL-TRUNK-SELECTION is not used.

The IVR-based COS feature (used for account and authorization codes) is supported only for ISDN PRI trunks and only in the North American market. For details of this application, see the "Account Codes and Authorization Codes" section on page 4-7.

The IVR operations for each subscriber feature are described in Chapter 6, "Interactive Voice Response Functions."

The system provides Multi-Lingual Support (MLS) for IVR and announcement services. This allows subscribers to select a preferred language (English, French, or Spanish) in which to hear the IVR prompts. See the "Multi-Lingual Support Feature" section on page 6-45.

To set options for IVR prompts, see the Class of Service (COS) provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.

To provision IVR support for features that use the IVR functionality, see the applicable feature provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.

Limited Call Duration Service (Prepaid/Postpaid) with RADIUS Interface to AAA

This section describes the BTS 10200 support for the Limited Call Duration (LCD) feature, including both prepaid and postpaid services. This support includes interfaces to an authentication, authorization, and accounting (AAA) server. The LCD feature can be assigned to any BTS 10200 subscriber with any phone type, including Media Gateway Control Protocol (MGCP)-based, Session Initiation Protocol (SIP)-based, and network-based call signaling (NCS)-based phones.

This section also lists the interactions of this feature with other subscriber features.

Network Interfaces

The BTS 10200 uses the following signaling interfaces for this feature:

RADIUS-based interface to an AAA server. The feature uses RADIUS Access Request and Account Request messages.

Additional interfaces for call-control signaling, including communications with MGCP-based and TGCP-based media gateways (MGWs), IP Transfer Points (ITPs) via SIGTRAN (for SS7), and PacketCable-based CMTSs and eMTAs.

SFTP interfaces to external third-party billing servers for transfer of billing records, and RADIUS interfaces to external record keeping servers (RKSs) for transfer of PacketCable-based event messages (EMs).

Feature Description

The LCD feature supports both prepaid and postpaid services for subscribers.

Fixed-prepaid (debit) service is an outgoing call management feature that allows a subscriber to pay for call charges in advance. Each time the subscriber makes a call, the charges for the call are deducted from the balance of the advance payment. If the subscriber uses up all of the advance payment, the BTS 10200 blocks all further calls from this subscriber (until more money is added to the account).

Postpaid-with-limit (credit) service is an outgoing call management feature that limits the calls originated from the subscriber so that total outstanding balance of charges for all the calls originated from the subscriber is less than a predefined limit. If the subscriber reaches the predefined limit, the BTS 10200 blocks all further calls from this subscriber (until money is paid on the account or the limit is increased).

When a subscriber with the LCD feature originates a call, the BTS 10200 contacts a designated prepaid AAA server via a RADIUS interface, and requests authorization to provide service for the subscriber. If the subscriber is allowed to make the call, the AAA server sends a success response to the BTS 10200. The response includes the call duration quota and the billing model of the subscriber (credit or debit). The BTS 10200 uses normal routing mechanisms to route the call. If the call continues beyond the allocated quota, the BTS 10200 tries to reauthorize the call with the AAA server. The call continues until it is either released by the calling or called party, or an attempt to reauthorize fails. If a reauthorization attempt fails, the BTS 10200 attempts to send a warning tone to the calling subscriber just before it is forcibly released.

If the AAA server rejects the authorization or authentication of the call, the system takes appropriate action depending on the value of the return code received from AAA server. If the system cannot authorize/authenticate a call due to a failure of communication with the AAA server, the call is released with an announcement.

The system applies LCD screening (authorization/authentication) to all nonemergency calls originated by a subscriber with the LCD feature assigned, unless the service provider has specifically provisioned the type of call to be excluded from screening.

The system never applies LCD screening to emergency calls (calls to numbers that are set to call-type=EMG in the Destination table) even if the LCD feature is assigned to the subscriber. LCD subscribers will be allowed to make calls to emergency numbers regardless of the balance in their account.

Provisionable Parameters

A new provisionable subscriber feature, Limited Call Duration (LCD), is added in this release to support prepaid features. It generates a trigger, LCD_TRIGGER, at the COLLECTED_INFORMATION trigger-detection point.

Feature Interactions

Calls to emergency numbers will not be authenticated even if the LCD feature is assigned to the subscriber. Therefore, LCD subscribers will be able to make emergency calls regardless of the balance in their account. From the implementation perspective, the system will not generate an LCD trigger if the call-type is emergency (EMG).


Note If you are using separate directory numbers (DNs) for ambulance, fire, and police service (typically applies to networks outside the United States), Cisco strongly recommends that you provision these as call-type=EMG and call-subtype=<AMBULANCE or FIRE or POLICE> in the Destination table. This is the only way to be sure that calls to these DNs will be given the priority treatment of the EMG call-type for all features.


All nonemergency calls, including toll-free calls, originated by a subscriber with the LCD feature will undergo authorization/authentication unless explicitly provisioned not to do so in the Trigger Nature of Dial Escape List (trigger-nod-escape-list) table.

LCD will have a higher precedence than Local Number Portability (LNP).

All types of forwarded calls (CFU, CFNA, CFB, and CFC) from the LCD subscriber will undergo the authorization/authentication and will be subject to the maximum available quota. However, the system does not perform authentication for calls redirected from the subscriber to the voice-mail application server.

If the subscriber has an Outgoing Call Barring (OCB) feature and LCD feature, the authorization/authentication will be done only if the call is not blocked; that is, OCB takes precedence over LCD.

Class of Service restriction will take precedence over the LCD feature.

Hotline/Warmline/HOTV features will undergo the authorization/authentication and will be subject to the maximum available quota.

Speed Call/Abbreviated Dial calls originated by the subscriber with the LCD feature will undergo the authorization/authentication and will be subject to the maximum available quota.

Each leg of the call originated by the LCD subscriber in a TWC and TWC Deluxe will undergo the authorization/authentication and will be subject to the maximum available quota.

Each leg of the call originated by the LCD subscriber during call transfer will undergo the authorization/authentication and will be subject to the maximum available quota.

The Call Waiting feature will be supported for the LCD subscriber. This includes scenarios where both the calls are terminating calls to the LCD subscriber and a scenario where only one of the calls is the terminating call to the LCD subscriber.

Authorization/authentication will not be done for Vertical Service Code (VSC) features, except when a courtesy call is required for certain VSC features, such as Call Forwarding Unconditional Activation (CFUA) and Call Forwarding Variable for Basic Business Group Activation (CFVABBG).

Authorization/authentication will not be done for Centrex subscriber originating calls; that is, the LCD feature is not supported for Centrex subscribers.

The system does not perform authorization/authentication for calls sent to the interactive voice response (IVR) server.

The system does not perform authentication for calls sent from the privacy screening (PS) application server to the subscriber.

Prerequisites

The implementation of the LCD feature in the BTS 10200 is based on the standards listed below. To interwork with the BTS 10200, the external AAA server must support these same interface requirements.

All the standard attributes used in this implementation conform to the Internet Engineering Task Force (IETF) documents RFC 2865, 2866, and 2869. (The system is capable of accepting additional RADIUS attributes that conform to these RFC documents, but does not process these attributes.)

All of the vendor-specific attributes (VSAs) used in this implementation conform to the definitions in the RADIUS VSA Voice Implementation Guide at the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/vapp_dev/vsaig3.pdf


Note If you need a complete compliance matrix, contact your Cisco account team for details.


Restrictions and Limitations

If a reauthorization attempt fails, the BTS 10200 attempts to send a warning tone to the calling subscriber just before it is forcibly released. However, the system may not be able to send the warning tone if the subscriber is using a SIP phone.

The LCD feature is not supported for H.323 subscribers in this release.


Note The LCD functionality of the BTS 10200 has been tested with the MIND C.T.I. iPhonEX as the AAA RADIUS server.


Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the LCD provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Message Waiting Indicator (MWI)—Audible and Visual

The BTS 10200 supports both audible message waiting indicator (MWI), also called stutter dial tone (SDT), and visual message waiting indicator (VMWI). These indicators are associated with voice mail service. When a call is forwarded to a voice mail system, and the caller leaves a message or retrieves all pending messages, the voice mail server sends a message to the Cisco BTS 10200 Softswitch with voice mail status information. In response to this, the Cisco BTS 10200 Softswitch notifies the voice mail status (on/off) to the called party (subscriber) by sending the appropriate signaling message to the MGCP/NCS residential gateway.

If the MWI feature is enabled for the subscribe (as configured in the SDT-MWI field in the SUBSCRIBER table), a SDT is delivered when the phone goes off hook and the subscriber has unretrieved voice mails.

If the VMWI feature is enabled for the subscriber (as configured in the VMWI field in the SUBSCRIBER table), and the subscriber has unretrieved voice mails, the telephone indicator light turns on. After the subscriber retrieves all voice mails, the indicator light turns off.


Note For the MWI feature to be enabled for the subscriber and deliver the SDT when the phone goes off hook, MWI must be enabled at the MGW profile level (MGCP-MWI-SUPP field in the MGW-PROFILE table) and SDT must be enabled at the subscriber level (SDT-MWI field in the SUBSCRIBER table).

Similarly, for VMWI to be enabled for the subscriber and turn the indicator light on, the VMWI feature must be enabled at the MGW profile level (MGCP-VMWI-SUPP field in the MGW-PROFILE table) and the subscriber level (VMWI field in the SUBSCRIBER table).


The signaling details are as follows:

For MWI, the BTS 10200 sends the RQNT message to the MGW containing S:L/mwi when the subscriber goes off hook and a message is waiting for the subscriber.

For VMWI, the BTS 10200 sends the RQNT message to the MGW containing S:L/vmwi(+) when a message is left for the subscriber. This message is sent regardless of whether the phone is off hook or on hook.

After the subscriber retrieves all voice mail messages, the BTS 10200 sends the RQNT message to MGW with S:L/vmwi(-).

The service provider can display and reset a subscriber's MWI status through the use of CLI commands. The status subscriber command displays the current MWI status, and the control subscriber command can be used to turn the MWI status on or off.


Tip For information on provisionable options for customer access to voice mail, see the "Voice Mail (VM) and Voice Mail Always (VMA)" section.


Multiline Hunt Group (MLHG)

The Cisco BTS 10200 Softswitch supports multiline hunt group (MLHG) features. An MLHG is a collection of lines organized into a group with a single pilot DN (also referred to as the group DN or the main-subscriber DN). Optionally, individual DNs can be assigned to some or all of the lines in the group. Each line in an MLHG has a terminal number that identifies its position in the group. When there is an incoming call, if the first line in the MLHG is busy, the next line is hunted and so on until an idle line is found.

Reference: LSSGR module FSD 01-02-0802 (GR-569-CORE), Multiline Hunt Service.


Note The MLHG feature is supported only for MGCP and NCS subscribers.


Hunting Sequence

The system hunts for an idle line by means of a defined search sequence. The sequence is specified by the provisioning of the hunt-type parameter in the MLHG table—regular, circular, or uniform call distribution (UCD). The system also supports preferential hunt lists.

The starting point for the hunt depends upon whether the incoming call is being routed to the group or to the individual. These scenarios are described in the following sections:

Incoming Call to the Pilot DN

Incoming Call to an Individual DN

Incoming Call to the Pilot DN

If the dialed digits of the incoming call match the DN for the main-sub-id (the pilot DN), the call is routed to the group. Figure 3-3 illustrates this process.

Figure 3-3 Searching an MLHG—Incoming Call to the Pilot DN (Example)

Notes for Figure 3-3

A rectangle surrounding a number means the line is busy.

Regular hunt and circular hunt (the hunting treatment for regular hunt and circular hunt are identical when the pilot DN is dialed)—The incoming call is routed to Terminal 1. If Terminal 1 is busy, the system hunts for the next idle terminal. If none of the terminals (2 through 10) is available, the hunt ends and the system does not answer the call.

UCD hunt—From previous calls, the system has set the next-free-terminal (NFT) pointer to Terminal 4. Therefore the call is completed to Terminal 4. When the call is completed to Terminal 4, the system sets the NFT pointer to the next idle line (Terminal 2). The system will give the next call to Terminal 2.

Incoming Call to an Individual DN

If the dialed digits of the incoming call match the DN for an individual terminal, the call is routed to that specific terminal. However, if that terminal is busy, the system hunts for an idle line. Figure 3-4 illustrates this process.

Figure 3-4 Searching an MLHG—Incoming Call to an Individual Terminal (Example)

Notes for Figure 3-4

A rectangle surrounding a number means the line is busy.

Regular hunt—The incoming call is routed to the terminal with the dialed DN, Terminal 5 in this example. If Terminal 5 is busy, the system hunts for the next idle terminal, Terminal 9 in this example. If none of the terminals (6 through 10) is available, the hunt ends and the system does not answer the call.

Circular hunt—The incoming call is routed to the terminal with the dialed DN, Terminal 5 in this example. If Terminal 5 is busy, the system hunts for the next idle terminal, Terminal 9 in this example. If none of the terminals (6 through 10) is available, the hunt continues with Terminal 1 through 4. If none of the terminals up to n-1 (where n is the dialed DN) is available, the hunt ends and the system does not answer the call.

UCD hunt—The incoming call is routed to the terminal with the dialed DN, Terminal 5 in this example. If Terminal 5 is idle, the system completes the call to Terminal 5 and does not attempt to change the NFT pointer. If Terminal 5 is busy, the system completes the call to the NFT. In this example, the system has already set the NFT pointer to Terminal 4. Therefore the call is completed to Terminal 4. When the call is completed to Terminal 4, the system performs a circular hunt for the next idle line, beginning with the terminal that follows the one on which the call was completed. It sets the NFT pointer to the next idle line (Terminal 2 in this example). The system will give the next call to Terminal 2.

If the terminal associated with the dialed DN of the incoming call is provisioned in the Subscriber table with a mlhg-pref-list-id, the system first hunts according to the process described in the "Preferential Hunt Lists" section. Preferential hunting is supported only if the hunt type is regular or circular (not UCD).

Preferential Hunt Lists

The system supports preferential hunt lists. There can be up to 64 preferential hunt lists per MLHG, and a maximum of 18 terminals are allowed in each list. Preferential hunt works only if the inbound call was dialed to the DN of a specific terminal. If the called DN is busy, and if the terminal associated with that DN is provisioned in the Subscriber table with a mlhg-pref-list-id, the system first searches the preferential hunt list in a specified sequence. The call is given to the first idle member of that preferential hunt list. If all the terminals in the preferential hunt list are busy, the hunting continues in the main MLHG list starting from the terminal after the last terminal in the preferential hunt list. This process is shown in Figure 3-5.


Note The system does not invoke the preference list (preferential hunt) if hunt-type=UCD in the MLHG table.


Figure 3-5 Searching a Preferential Hunt List (Example)

MLHG Provisioning Options and Use Cases

Table 3-12 explains how provisioning in the Subscriber table affects the behavior of a terminal in the MLHG.

Table 3-12 Impact of Provisioning CATEGORY, MLHG-ID, and GRP Parameters in the Subscriber Table 

Provision CATEGORY (default=INDIVIDUAL) As
MLHG-ID Required?
Provision GRP (default=N) As
Telephony Features Provided by the System
and Hunt Scenario

MLHG

Required

(no effect)

This is the main subscriber for the MLHG.

It is optional to assign a term-id to this subscriber.

MLHG-INDIVIDUAL
or
MLHG-PREF-INDIV1

Required

Y

The individual subscriber inherits all of the features of the main subscriber. The individual cannot be provided with any additional features.


Caution Do not attempt to assign individual features to a subscriber when grp=y. The system will not honor these features for this subscriber.

This subscriber must have a term-id that matches a term-id in the mlhg-terminal table. This terminal is included in the hunt when the pilot number is called. It can also receive calls directly to an individual DN if provisioned in the subscriber table.

MLHG-INDIVIDUAL
or
MLHG-PREF-INDIV

Required

N

The individual subscriber does not inherit any of the features of the main subscriber. The individual can be provided with features through regular subscriber and feature provisioning.

This subscriber must have a term-id that matches a term-id in the mlhg-terminal table. This terminal is included in the hunt when the pilot number is called. It can also receive calls directly to an individual DN if provisioned in the subscriber table.

INDIVIDUAL

Not required (no effect)

(no effect)

The individual can be provided with features through regular subscriber and feature provisioning.

If the term-id of this subscriber matches a term-id in the mlhg-terminal table, this line is included in the hunt when the pilot number is called. However, when the DN of this individual line is called directly, no hunting treatment is offered, even if the line is busy.

1 For individual members of the MLHG, you can provision the category parameter in the subscriber table as mlhg-individual or mlhg-pref-indiv. The system treats these settings identically.


Main subscriber—Each MLHG has a single main-sub-id, also referred to as the group ID. The main-sub-id identifies a subscriber record that contains parameters for the group, including the pilot DN. In the Subscriber table, you must assign category=mlhg (or ctxg-mlhg) to this main subscriber. Also in the Subscriber table, you can assign a term-id to this subscriber (optional).

Subscribers—Any termination reachable through an individual DN must be set up as a subscriber (provisioned with a value for DN1 in the Subscriber table), and any termination to physical line must be defined with a unique term-id (the same term-id in both the Subscriber and MLHG-Terminal tables). Any termination that can originate calls must be set up as a subscriber.

Terminals—Each line in an MLHG must have a terminal number that identifies its position in the group. You must provision a terminal number in the MLHG-Terminal table for every line in the MLHG. During a multiline hunt, the terminals are attempted in numerical order, from lowest to highest.

Features—The system delivers the same features to the subscriber regardless of how the features are assigned (assigned and activated on the individual subscriber, or inherited from the main subscriber and activated on the individual subscriber).

Feature activation—If a feature requires activation by the user, activation for one user in the MLHG does not affect activation for another user. Activation for the main subscriber does not cause activation for any of the individual subscribers, even if the subscribers have GRP=Y.


Caution For features that require activation by the user, each user has the option of activating the feature, but this does not occur automatically.

Treatment of Outbound Call Features

Temporarily disconnected status—If temporarily-disconnected status is assigned to the subscriber record for the main subscriber (Subscriber table: status=temp-disconnected), the system treats all the lines in the MLHG (that is, all the lines provisioned with the same mlhg-id as the main subscriber) as temporarily disconnected. This is true regardless of the provisioned value for the grp parameter in the Subscriber table.

Call forwarding—When a call is forwarded from a line in the MLHG, the forwarding signaling contains the DN of the subscriber associated with the original dialed number.

Account codes and authorization codes—You can provision the system to collect account codes and authorization codes from members of the MLHG. First, set up a class of service (COS) restriction in the COS-Restrict table for the appropriate account code or authorization code treatment. Then provision the subscribers as follows:

If you want to assign the COS treatment (including account codes and authorization codes) to all members of the MLHG (that is, to all the lines provisioned with the same mlhg-id as the main subscriber), assign the COS to the main subscriber and provision all members of the MLHG with grp=Y.

If you provision any individual subscriber with grp=N, that individual does not inherit the COS feature from the main subscriber, However, you can still provision the individual with any desired features, including any available COS.

Speed call:

Group speed call—To provide the group speed call feature to all members of the MLHG, provision the subscriber record for every member of the MLHG with grp=Y, and provision the main subscriber with the group speed call feature (GSC1D and GSC2D).


Note When both speed call and group speed call features are assigned to the main subscriber, both the features are inherited by all members of the group (having GRP=Y in subscriber table). When a member subscriber attempts to invoke speed call feature, the individual speed calling takes precedence over group speed-calling. The group-speed-call feature is not invoked in such scenarios.


Individual speed call—If you set grp=N for any member of the MLHG, then that member is provided only with the features assigned to the individual subscriber record (including any individual speed call features), and none of the features assigned to the main subscriber.

Treatment of Inbound Call Features

This section explains how the system treats an inbound call when a feature is assigned and active on an MLHG subscriber line. The handling of inbound calls depends on the following factors:

The dialed directory number (DN)—This is the number dialed by the remote originating party. The dialed DN could be the pilot DN (the DN of the main subscriber of the MLHG) or the individual DN of any MLHG member.

Active features—The treatment of the call depends on the features that are assigned and activated on the subscriber associated with the dialed DN. If a hunt occurs, the properties (the features and feature activation data) of the dialed DN are applied, not the properties of the hunted terminal.


Note If the hunted terminal goes off-hook to receive the call, the user of the hunted terminal can initiate midcall features (for example, by depressing the hook or pressing the Flash button). The midcall features are based on the properties of the individual hunted terminal.


Call waiting tone—Call Waiting (CW) and Caller ID on Call Waiting (CIDCW) are disabled for all MLHG subscribers. The CW tone is not applied on the main subscriber or mlhg-individual endpoints under any scenario.

Temporarily disconnected status—If temporarily-disconnected status is assigned to the subscriber record for the main subscriber (Subscriber table: status=temp-disconnected), the system does not perform any hunting, and it treats all the lines in the MLHG (that is, all the lines provisioned with the same mlhg-id as the main subscriber) as temporarily disconnected. This is true regardless of the provisioned value for the grp parameter in the Subscriber table.

Typically, a subscriber service contains multiple features, and the system applies the features according to the normal feature precedence as documented in Chapter 5, "Feature Interactions."

Assigning and Activating Features

This section explains what causes a feature to be assigned and active on the MLHG main subscriber and MLHG individual.

For features that require activation, individual subscribers typically activate the feature on their own handset using vertical service codes (VSCs). Activation of a feature for one member of the MLHG does not affect activation for another user. Activation for the main subscriber does not cause activation for any of the individual subscribers, even if the individual subscribers have GRP=Y.

MLHG Main Subscriber

Features are assigned directly to the main subscriber by provisioning the Subscriber Profile or Subscriber Service Profile table. For the main subscriber, a feature is active if it is assigned to the subscriber, and activated by either of the following methods:

If a terminal is assigned to the main subscriber, the feature can be activated through handset provisioning or through the Subscriber Feature Data table.

If a terminal is not assigned to the main subscriber (term=none in the Subscriber table), the feature can be activated through the Subscriber Feature Data table.

MLHG Individual

There are two methods of assigning a feature to an MLHG individual:

Set GRP = Y in the Subscriber table—This causes the MLHG individual to inherit all the features assigned to the main subscriber.

Set GRP = N in the Subscriber table—In this case, the MLHG individual inherits no features from the main subscriber. Individual features can be assigned directly to the individual subscriber.


Caution If you set GRP = Y for a particular MLHG individual (which causes the MLHG individual to inherit all the features from the MLHG main subscriber), do not directly add any features to the MLHG individual, This could cause unexpected feature interactions.

Table 3-13 lists the parameters that affect assignment and activation of features on the MLHG individual.

Table 3-13 Parameters Affecting Assignment and Activation of Features on MLHG Individual 

Feature Assigned to Main Subscriber
MLHG Individual Subscriber
Result— Status of the Feature on the MLHG Individual
Explanation
GRP =
Feature Assigned to MLHG Individual
Feature Activated on MLHG Individual

Y

Y

N

Y

Active

MLHG individual inherits feature from the main sub.

Feature is activated on the MLHG individual.

Y or N

N

Y

Y

Active

Feature is assigned directly to the MLHG individual.

Feature is activated on the MLHG individual.

Y

Y

N

N

Not active.

MLHG individual inherits feature from the main sub.

Feature is not activated on the MLHG individual.

N

Y

N

n/a

Not active.

The feature is not assigned.

Y or N

N

Y or N

N

Not active.

Regardless of feature assignment, the feature is not activated on the MLHG individual.


Treatment of Incoming Calls for Specific Features

The treatment of incoming calls is described for the features listed below.

CFB:

Table 3-14, "Treatment of Incoming Call to Pilot DN for CFB Feature"

Table 3-15, "Treatment of Incoming Call to MLHG Individual DN for CFB Feature"

CFNA:

Table 3-16, "Treatment of Incoming Call to Pilot DN for CFNA Feature"

Table 3-17, "Treatment of Incoming Call to MLHG Individual DN for CFNA Feature"

CFC or VM:

Table 3-18, "Treatment of Incoming Call to Pilot DN for CFC or VM Feature"

Table 3-19, "Treatment of Incoming Call to MLHG Individual DN for CFC or VM Feature"

CFU or VMA:

Table 3-20, "Treatment of Incoming Call to Pilot DN for CFU or VMA Feature"

Table 3-21, "Treatment of Incoming Call to MLHG Individual DN for CFU or VMA Feature"

SCA, SCF, and SCR:

Table 3-22, "Treatment of Incoming Call to Pilot DN for SCA, SCF, or SCR Feature"

Table 3-23, "Treatment of Incoming Call to MLHG Individual DN for SCA, SCF, or SCR Feature"

DRCW:

Table 3-24, "Treatment of Incoming Call to Pilot DN for DRCW Feature"

Table 3-25, "Treatment of Incoming Call to MLHG Individual DN for DRCW Feature"

CFB

Table 3-14 lists the call treatment for inbound calls to the MLHG pilot number (main subscriber DN) based on the assignment and activation of Call Forwarding Busy (CFB) for that main subscriber.

Table 3-14 Treatment of Incoming Call to Pilot DN for CFB Feature 

CFB Assignment and Activation on the Main Subscriber
Scenario (Condition When Call Comes In to the Pilot DN)
Call Treatment Given to the Inbound Call

(For these scenarios, CFB assignment and activation have no effect.)

Terminal of the main-sub is busy, or no terminal is assigned to the main-sub.

The system hunts for an idle line.

Terminal of the main-sub or hunted terminal is idle but does not answer.

Ringing on idle line.

CFB assigned and activated.

All terminals busy.

Call forwarded per CFB.

CFB assigned but not activated, or CFB not assigned.

Busy tone


Table 3-15 lists the call treatment for inbound calls to the MLHG individual subscriber DN based on the assignment and activation of CFB for that individual.

Table 3-15 Treatment of Incoming Call to MLHG Individual DN for CFB Feature 

CFB Assignment and Activation on the MLHG Individual
Scenario (Condition When Call Comes In to DN of the MLHG Individual)
Call Treatment Given to the Inbound Call

(For these scenarios, CFB assignment and activation have no effect.)

Mlhg-individual is busy.

The system hunts for an idle line.

Mlhg-individual or hunted terminal is idle but does not answer.

Ringing on idle line.

CFB assigned and activated.

All terminals busy.

Call forwarded per CFB.

CFB assigned but not activated, or CFB not assigned.

Busy tone


CFNA

Table 3-16 lists the call treatment for inbound calls to the MLHG pilot number (main subscriber DN) based on the assignment and activation of Call Forwarding No Answer (CFNA) for that main subscriber.

Table 3-16 Treatment of Incoming Call to Pilot DN for CFNA Feature 

CFNA Assignment and Activation on the Main Subscriber
Scenario (Condition When Call Comes In to the Pilot DN)
Call Treatment Given to the Inbound Call

(For this scenario, CFNA assignment and activation have no effect.)

Terminal of the main-sub is busy, or no terminal is assigned to the main-sub.

The system hunts for an idle line.

CFNA assigned and activated.

Terminal of the main-sub or hunted terminal is idle but does not answer.

Call forwarded per CFNA.

CFNA assigned but not activated, or feature not assigned.

Ringing on idle line.

(For this scenario, CFNA assignment and activation have no effect.)

All terminals busy.

Busy treatment.


Table 3-17 lists the call treatment for inbound calls to an MLHG individual subscriber DN based on the assignment and activation of CFNA for that individual.

Table 3-17 Treatment of Incoming Call to MLHG Individual DN for CFNA Feature 

CFNA Assignment and Activation on the MLHG Individual
Scenario (Condition When Call Comes In to DN of the MLHG Individual)
Call Treatment Given to the Inbound Call

(For this scenario, CFNA assignment and activation have no effect.)

Mlhg-individual is busy.

The system hunts for an idle line.

CFNA assigned and activated.

MLHG-individual or hunted terminal is idle but does not answer.

Call forwarded per CFNA.

CFNA assigned but not activated, or feature not assigned.

Ringing on idle line.

(For this scenario, CFNA assignment and activation have no effect.)

All terminals busy.

Busy treatment.


CFC or VM

Table 3-18 lists the call treatment for inbound calls to the MLHG pilot number (main subscriber DN) based on the assignment and activation of Call Forwarding Combination (CFC) or Voice Mail (VM) for that main subscriber.


Note Information for the Voice Mail Always (VMA) feature is in Table 3-20 and Table 3-21.


Table 3-18 Treatment of Incoming Call to Pilot DN for CFC or VM Feature 

Feature (CFC or VM) Assignment and Activation on the Main Subscriber
Scenario (Condition When Call Comes In to the Pilot DN)
Call Treatment Given to the Inbound Call

(For this scenario, feature assignment and activation have no effect.)

Terminal of the main-sub is busy, or no terminal is assigned to the main-sub.

The system hunts for an idle line.

Feature assigned and activated.

Terminal of the main-sub or hunted terminal is idle but does not answer.

Call forwarded per CFC or VM.

Feature assigned but not activated, or feature not assigned.

Ringing on idle line.

Feature assigned and activated.

All terminals busy.

Call forwarded per CFC or VM.

Feature assigned but not activated, or feature not assigned.

Busy treatment.


Table 3-19 lists the call treatment for inbound calls to an MLHG individual subscriber DN based on the assignment and activation of CFC or VM for that individual.

Table 3-19 Treatment of Incoming Call to MLHG Individual DN for CFC or VM Feature 

Feature (CFC or VM) Assignment and Activation on the MLHG Individual
Scenario (Condition When Call Comes In to DN of the MLHG Individual)
Call Treatment Given to the Inbound Call

(For this scenario, feature assignment and activation have no effect.)

Mlhg-individual is busy.

The system hunts for an idle line.

Feature assigned and activated.

Mlhg-individual or hunted terminal is idle but does not answer.

Call forwarded per CFC or VM.

Feature assigned but not activated, or feature not assigned.

Ringing on idle line.

Feature assigned and activated.

All terminals busy.

Call forwarded per CFC or VM.

Feature assigned but not activated, or feature not assigned.

Busy treatment.


CFU or VMA

Table 3-20 lists the call treatment for inbound calls to the MLHG pilot number (main subscriber DN) based on the assignment and activation of Call Forwarding Unconditional (CFU) or Voice Mail Always (VMA) for that main subscriber.


Note Information for the Voice Mail (VM) feature is in Table 3-18 and Table 3-19.


Table 3-20 Treatment of Incoming Call to Pilot DN for CFU or VMA Feature 

Feature (CFU or VMA) Assignment and Activation on the Main Subscriber
Scenario (Condition When Call Comes In to the Pilot DN)
Call Treatment Given to the Inbound Call

Feature assigned and activated.

Terminal of the main-sub is busy, or no terminal is assigned to the main-sub.

Call forwarded per CFU or VMA.

Feature assigned but not activated, or feature not assigned.

The system hunts for an idle line.

Feature assigned and activated.

Terminal of the main-sub is idle.

Call forwarded per CFU or VMA.

Feature assigned but not activated, or feature not assigned.

Terminal of the main-sub is idle but does not answer.

Ringing on idle line.

Feature assigned and activated.

All terminals busy.

Call forwarded per CFU or VMA.

Feature assigned but not activated, or feature not assigned.

Busy treatment.

Feature assigned and activated on main subscriber.

Special Case—Dialed DN of incoming call is DN of the mlhg-individual, not DN of the main-sub.

Call treatment is based on the provisioned properties (features and feature data) of the mlhg-individual.


Table 3-21 lists the call treatment for inbound calls to an MLHG individual subscriber DN based on the assignment and activation of CFU or VMA for that individual.

Table 3-21 Treatment of Incoming Call to MLHG Individual DN for CFU or VMA Feature 

Feature (CFU or VMA) Assignment and Activation on the MLHG Individual
Scenario (Condition When Call Comes In to DN of the MLHG Individual)
Call Treatment Given to the Inbound Call

Feature assigned and activated.

Mlhg-individual is busy.

Call forwarded per CFU or VMA.

Feature assigned but not activated, or feature not assigned.

The system hunts for an idle line.

Feature assigned and activated.

Terminal of the mlhg-individual is idle.

Call forwarded per CFU or VMA.

Feature assigned but not activated, or feature not assigned.

Mlhg-individual or hunted line is idle but does not answer.

Ringing on idle line.

Feature assigned and activated.

All terminals busy.

Call forwarded per CFU or VMA.

Feature assigned but not activated, or feature not assigned.

Busy treatment.


SCA, SCF, and SCR

Table 3-22 lists the call treatment for inbound calls to the MLHG pilot number (main subscriber DN) based on the assignment and activation of Selective Call Acceptance (SCA), Selective Call Forwarding (SCF), or Selective Call Rejection (SCR) for that main subscriber. The system invokes the SCA, SCF, or SCR feature only if the DN of the calling party is included in the screening list of the called party.

Table 3-22 Treatment of Incoming Call to Pilot DN for SCA, SCF, or SCR Feature 

Feature (SCA, SCF, or SCR) Assignment and Activation on the Main Subscriber
Scenario (Condition When Call Comes In to the Pilot DN)
Call Treatment Given to the Inbound Call

Feature assigned and activated.

Terminal of the main-sub is busy, terminal of main-sub is idle, or no terminal is assigned to the main-sub.

SCA (on list)—Hunting; see additional scenarios in this table.

SCA (not on list)—Call is not accepted; SCA announcement.

SCF (on list)—Call forwarded per SCF.

SCF (not on list)—Hunting; see additional scenarios in this table.

SCR (on list)—Call rejected per SCR with SCR announcement.

SCR (not on list)—Hunting; see additional scenarios in this table.

Feature assigned but not activated, or feature not assigned.

The system hunts for an idle line.

Feature assigned and activated.

Terminal of the main-sub or hunted terminal is idle but does not answer.

SCA (on list)—Ringing on idle line.

SCF (not on list)—Ringing on idle line.

SCR (not on list)—Ringing on idle line.

Feature assigned but not activated, or feature not assigned.

Ringing on idle line.

Feature assigned and activated.

All terminals busy.

SCA (on list)—Busy treatment.

SCF (not on list)—Busy treatment.

SCR (not on list)—Busy treatment.

Feature assigned but not activated, or feature not assigned.

Busy treatment.


Table 3-23 lists the call treatment for inbound calls to an MLHG individual subscriber DN based on the assignment and activation of SCA, SCF, or SCR for that individual.

Table 3-23 Treatment of Incoming Call to MLHG Individual DN for SCA, SCF, or SCR Feature 

Feature (SCA, SCF, or SCR) Assignment and Activation on the MLHG Individual
Scenario (Condition When Call Comes In to DN of the MLHG Individual)
Call Treatment Given to the Inbound Call

Feature assigned and activated.

Mlhg-individual is busy, or terminal of mlhg-individual is idle.

SCA (on list)—Hunting; see additional scenarios in this table.

SCA (not on list)—Call is not accepted; SCA announcement.

SCF (on list)—Call forwarded per SCF.

SCF (not on list)—Hunting; see additional scenarios in this table.

SCR (on list)—Call rejected per SCR with SCR announcement.

SCR (not on list)—Hunting; see additional scenarios in this table.

Feature assigned but not activated, or feature not assigned.

The system hunts for an idle line.

Feature assigned and activated.

Mlhg-individual or hunted terminal is idle but does not answer.

SCA (on list)—Ringing on idle line.

SCF (not on list)—Ringing on idle line.

SCR (not on list)—Ringing on idle line.

Feature assigned but not activated, or feature not assigned.

Ringing on idle line.

Feature assigned and activated.

All terminals busy.

SCA (on list)—Busy treatment.

SCF (not on list)—Busy treatment.

SCR (not on list)—Busy treatment.

Feature assigned but not activated, or feature not assigned.

Busy treatment.


DRCW

Table 3-24 lists the call treatment for inbound calls to the MLHG pilot number (main subscriber DN) based on the assignment and activation of Distinctive Ringing Call Waiting (DRCW) for that main subscriber. The system invokes the DRCW feature only if the DN of the calling party is included in the DRCW screening list of the called party.


Note Call Waiting (CW) and Caller ID on Call Waiting (CIDCW) are disabled for all MLHG subscribers. The CW tone is not applied on the main subscriber or mlhg-individual endpoints under any scenario.


Table 3-24 Treatment of Incoming Call to Pilot DN for DRCW Feature 

DRCW Assignment and Activation on the Main Subscriber
Scenario (Condition When Call Comes In to the Pilot DN)
Call Treatment Given to the Inbound Call

(For this scenario, feature assignment and activation have no effect.)

Terminal of the main-sub is busy, or no terminal is assigned to the main-sub.

The system hunts for an idle line.

Feature assigned and activated.

Terminal of the main-sub or hunted line is idle.

DRCW (on list)—Ringing per DRCW.

DRCW (not on list)—Regular ringing.

Feature assigned but not activated, or feature not assigned.

Regular ringing.

(For this scenario, feature assignment and activation have no effect.)

All terminals busy

Busy treatment.


Table 3-25 lists the call treatment for inbound calls to an MLHG individual subscriber DN based on the assignment and activation of DRCW for that individual.

Table 3-25 Treatment of Incoming Call to MLHG Individual DN for DRCW Feature 

DRCW Assignment and Activation on the MLHG Individual
Scenario (Condition When Call Comes In to DN of the MLHG Individual)
Call Treatment Given to the Inbound Call

(For this scenario, feature assignment and activation have no effect.)

Mlhg-individual is busy.

The system hunts for an idle line.

Feature assigned and activated.

Mlhg-individual or hunted line is idle.

DRCW (on list)—Ringing per DRCW.

DRCW (not on list)—Regular ringing.

Feature assigned but not activated, or feature not assigned.

Regular ringing.

(For this scenario, feature assignment and activation have no effect.)

All terminals busy

Busy treatment.


Billing for MLHG

Billing fields for calls originated by DNs within the MLHG are populated as follows.

Field 23 (originating number):

The value of the DN1 field of the individual subscriber, if available.

Otherwise, the value of the DN1 field of the main subscriber.

Field 25 (charge number)

The value of the billing-dn field of the subscriber if available.

Otherwise, the value of the billing-dn field of the main subscriber if available.

Otherwise, the value of the DN1 field of the main subscriber if available.

Otherwise, the value of the DN1 field of the subscriber.

For complete billing information, see the Cisco BTS 10200 Softswitch Billing Guide.

Basic Provisioning Procedure and CLI Reference

For the basic sequence of steps to provision a MLHG, see the MLHG provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.

To see a detailed list of all provisionable values for the MLHG, MLHG Terminal, and MLHG Preference List tables, see the applicable tables in the Cisco BTS 10200 Softswitch CLI Database.

Multiline Variety Package

The MVP feature allows the creation of a logical grouping of subscribers and enables the provision of Centrex features such as call-hold, call-park/retrieve and extension dialing for the subscribers within the group.

Typically Centrex subscribers dial "9" (or some other access code) to access the public switched telephone network (PSTN) and dial extension numbers to reach other subscribers within the group. However, in the case of small businesses with fewer lines, it can be expected that most of the originating call traffic will be towards the PSTN and not within the group.

Using the MVP feature on the BTS 10200 system (as explained in the provisioning steps described in next section), the requirement to dial an access code to access a PSTN line can be avoided for the group members.

In addition, the BTS10200 can be configured to use "*" prefixed extensions to reach the subscribers within the group. It is possible to use 1-digit extensions within the range *2-*9 for a smaller group of subscribers (that is, a group with up to 8 subscribers) or 2-digit extensions within range *20-*49 for a medium size group of subscribers (that is, a group with up to 30 subscribers). *0 can be assigned to the operator or *0 can be used for Operator or Attendant Access.

Provisioning Procedure

For information on the provisioning procedure for the MVP feature, refer to Cisco BTS 10200 Softswitch Provisioning Guide.

Multiple Directory Numbers (MDN)

Multiple directory numbers (MDN) service is also known as teen service. It enables one primary DN and multiple secondary DNs to be assigned to a single line termination. A specific unique ringing pattern is assigned to each DN, so that each incoming call can be individually identified. A distinctive CW tone is also assigned to each DN so that each incoming call can be individually identified when the line is busy.

Billing for this service is charged to the primary telephone number (or to the number designated as the billing DN). If DRCW is activated, MDN is inhibited. For calls originating from a MDN line, the primary DN is used as caller-ID, if an ID is offered to the called party.


Note The MDN feature is available to POTS users only.



Tip To provision this feature, see the MDN provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


No Solicitation Announcement (NSA)

The NSA feature allows subscribers to play a message telling callers that they do not accept solicitation (telemarketing) calls. The feature does not forcibly release the call, but the expectation is that any solicitation caller will hang up. The subscriber can manage a number of NSA parameters via the handset, including activation/deactivation of the feature, time-of-day activation options, a list of directory numbers (DNs) for which the announcement will be bypassed, and a private identification number (PIN) for access to management options.

During the setup process for the incoming call, if the NSA feature has been assigned by the service provider and the called party (subscriber) has the feature activated, the NSA announcement is played to the caller. (However, the announcement is bypassed if the subscriber has included the DN of the incoming caller on their NSA bypass list.) The announcement also notifies the caller to press a specific key on the handset (default is 1) to bypass the announcement and connect to the subscriber. If the caller waits until the announcement completes, the call is connected to the subscriber.

The NSA feature requires support from an interactive voice response (IVR) server in the network, and from the BTS 10200 screening list editing (SLE) feature. The BTS 10200 establishes a Real-Time Transport Protocol (RTP) connection between the incoming media gateway (MGW) or integrated access device (IAD) and the IVR server.


Tip For more details about the IVR interactions for this feature, see Chapter 6, "Interactive Voice Response Functions."


References

The following standards are available:

PacketCable document PKT-SP-ASP-I02-010620, PacketCable Audio Server Protocol Specification

PacketCable document PKT-TR-VOIPERF-R01-000831, Extended Residential Feature Descriptions for PacketCable-Based VOIP Services, Section 2.1.9 (No Solicitation Announcement)

Telcordia document GR-220-CORE, Screening List Editing

NSA Activation, Management, and Control

The service provider assigns the NSA feature to subscribers. The feature is in the deactivated mode when assigned, unless activated by the service provider or subscriber.


Note The system allows the service provider to provision these features for the subscriber, but typically these features are provisioned from the subscriber handset via a connection to an IVR server.


The feature supports the following management and control procedures for the subscriber:

Establish a pass code (required to access the management menu):

The subscriber must enter a PIN for authentication purposes when accessing the IVR system to change the NSA settings. The subscriber is allowed to choose the PIN when the service provider initially assigns the feature. After that, the subscriber cannot change the PIN unless the service provider resets it. The service provider can enable (or disable) the PIN authentication step by setting the AUTH-ENABLED token to Y (or N) in the Feature Configuration (feature-config) table. The default value is Y.

Create and edit a list of directory numbers (DNs) for bypassing the NSA announcement:

The subscriber can provision a list of calling DNs that are allowed to bypass the NSA announcement and go directly to the subscriber line. The list can contain full DNs, partial DNs, and extension numbers (if the subscriber is in a Centrex group). By default, the system allows subscribers to program up to 31 DNs in the NSA bypass list. The service provider can reset the limit of DNs to any number from 2 to 31 by tuning the value of the SLE-LIST-SIZE token in the Call Agent Configuration (ca-config) table.

For each DN entry, the system accepts up to 16 digits (and ignores any additional digits entered by the handset user). The system checks that the digit string represents a valid calling number before storing it in the database. If the digit string does not represent a valid calling number, the system plays a denial announcement to the handset user.

When DN-TYPE=FDN, the system normalizes the number before storing it in the database. Normalization means that the system performs the digit manipulation provisioned in the Digit Manipulation (digman) table. For example, if a user enters 19725551212, the digman table might normalize to 9725551212.

The system allows DN-TYPE=EXTENSION only if the subscriber line is a Centrex line. The system checks that the digit string entered by the handset user is a valid extension for the local Centrex group.

When DN-TYPE=PARTIAL, the system accepts any digit string up to 16 digits.


Tip To activate the NSA service, the subscriber must enter at least one DN on the NSA bypass list. This is consistent with the requirements of GR-220. If the subscriber would like to play the NSA announcement to every caller, the subscriber must enter one DN, which should be a number that is generally not used (for example, 555-555-5555).


Specify the schedule (time slots) when NSA service will be active:

This setting allows the subscriber or the service provider to set the time slots when the NSA service will be active. The provisioning by the service provider can be at the office level or the subscriber level. The values provisioned by or for the subscriber take precedence over the values provisioned at the office level. The subscriber may provision the time slots (days of the week and time of day) when the service will be active. At all times other than the provisioned time slots, the service is deactivated. During NSA nonservice hours, the following apply:

There is no announcement, and calls go directly to the subscriber line.

The NSA bypass list and other settings for the subscriber are preserved.

The service provider can enable or disable the handset-based schedule management via options in the feature-config table.

Toggle a parameter to turn NSA on or off.


Tip For information on the feature-config and ca-config tables, seethe Cisco BTS 10200 Softswitch CLI Database, and use the show feature-config and show ca-config commands.


NSA Invocation

NSA invocation refers to the implementation of the NSA feature by the system during call setup. The NSA feature works in conjunction with the network IVR server to prompt the caller and control the invocation process.

For callers calling an NSA subscriber during the time period configured as active by the subscriber, and not on the subscriber's NSA bypass list, the NSA feature plays an announcement similar to "You have reached a number that does not accept phone solicitations. If you are a solicitor, please add this number to your do-not-call list and hang up now. Otherwise, please press 1, or stay on the line." The caller may then take any of the following actions:

Stay on the line, or press 1—In this case, the subscriber is rung and the call is connected to the subscriber.

Hang up—In this case, the system does not ring the subscriber.

Press a digit other than 1—In this case, the NSA announcement is replayed to the caller. When the number of replay attempts exceeds a provisioned threshold, the subscriber will be rung and the caller will be connected to the subscriber.

Feature Interactions

Feature interactions are as follows:

NSA and Anonymous Call Rejection (ACR):
If the subscriber gets an anonymous call and has both NSA and ACR features active, the incoming call is given the ACR feature. ACR has a higher priority than NSA even for anonymous callers who are on the NSA priority caller list.

NSA and Privacy Screening (PS):
If the subscriber receives an anonymous call and has both PS and NSA features active, the subscriber is given the PS feature. For nonanonymous callers, the subscriber is given the NSA feature.

NSA and Selective Call Rejection (SCR):
If a subscriber receives a call from a caller whose DN is in the SCR list for the subscriber, the caller hears the SCR announcement and is blocked by SCR. If the subscriber is not on the SCR list, the subscriber is given the NSA announcement.

NSA and Call Forwarding Unconditional (CFU):
If the subscriber has CFU and NSA active, an incoming call is given the NSA feature. If the caller chooses to continue with the call and if the subscriber has CFU active, the call will be forwarded by CFU.

NSA and VM:
If the subscriber has VM and NSA active, an incoming call will be given the NSA feature. If the caller chooses to continue with the call and if the subscriber has VM active, the call will be forwarded by VM.

NSA and Call Forwarding Busy (CFB):
If the subscriber has both NSA and CFB active, the caller will first hear the NSA announcement. If the caller chooses to continue with the call and if the subscriber is busy and has CFB active, the call will be forwarded by CFB.

NSA and Call Forwarding No Answer (CFNA):
If the subscriber has both NSA and CFNA active, the caller will first hear the NSA announcement. If the caller chooses to continue with the call and if the subscriber does not answer and has CFNA active, the call will be forwarded by CFNA.

NSA and Do Not Disturb (DND):
If the subscriber has both NSA and DND assigned and active, the caller will be rejected by DND.

NSA and Selective Call Acceptance (SCA):
If the subscriber receives an anonymous call from a caller whose DN is not in the SCA list for the subscriber, the call will be blocked by SCA.

NSA and Selective Call Forwarding (SCF):
If the subscriber receives a call from a caller whose DN is in the SCF list for the subscriber, the call will be forwarded by SCF.

NSA and Distinctive Ringing/Call Waiting (DRCW):
If the subscriber receives a call from a caller whose DN is in the DRCW list for the subscriber, the call will be completed by DRCW.

NSA and Busy Line Verification (BLV):
If the subscriber has both NSA and BLV assigned and active, when BLV is invoked, NSA is inhibited.


Note Several of the items below use the term hookflash. In this document, hookflash means to press the Flash button (on phones that have a Flash button) or depress the hookswitch. This is the action that a subscriber typically performs to invoke a multiparty feature in the middle of a call.


NSA_ACT and Call Waiting (CW):
NSA Activation (NSA_ACT) does not interact with CW. The subscriber can be subscribed to both features, but may not use them simultaneously. When a subscriber is accessing NSA_ACT, CW tones are inhibited, and if the subscriber hookflashes, this ends the NSA_ACT session.

NSA and Call Waiting (CW):
If the subscriber is busy and does not have the CW feature, the caller will hear the NSA announcement before hearing the busy tone.

NSA_ACT and Hookflash:
Hookflash during a NSA_ACT session will cause the NSA activation session to end. The hookflash moves the caller back to the original call and reconnects to the held party. If the customer is subscribed to one of the multiple-party features (for example, TWC, CT, or CHD), the call is simply reconnected.

NSA and Hookflash:
If Subscriber A is on a call, then hookflashes and calls an NSA Subscriber B, receives the NSA announcement from Subscriber B, then Subscriber A hookflashes again during the NSA announcement, the following behaviors apply:

If Subscriber A and Subscriber B are on the same BTS 10200, the system ignores the second hookflash by Subscriber A, and the NSA treatment continues.

If Subscriber A is on a BTS 10200 and Subscriber B is on different switch, the system honors the second hookflash by Subscriber A.


Note If Subscriber B is on a different switch, the BTS 10200 honors the second hookflash because it assumes the call has been answered by Subscriber B.



Note See Chapter 5, "Feature Interactions," for a complete list of feature interactions.


Prerequisites

This feature requires connection to a network media server with IVR capabilities. The media server must support the Media Gateway Control Protocol (MGCP) basic audio (BAU) package. A voice path must be set up between the subscriber (who is using the handset) and the IVR server to allow the subscriber to activate and manage the NSA feature.

The process of creating and editing the NSA bypass list on the IVR server requires that the screening list editing (SLE) feature be provisioned on the BTS 10200. The SLE provisioning information is included in this document.


Note The SLE feature used with NSA is provisioned separately from the SLE feature used with the BTS 10200 SCA, SCF, SCR, and DRCW features. However, to the subscriber, the IVR handset operations are very similar.


Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the NSA provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Own Calling Number Announcement (OCNA)

The OCNA feature enables the BTS 10200 to play an announcement with the calling number when a specific pilot number is dialed. The announcement is simply the dialed digits of the calling number, and the announcement is played if the calling party is a subscriber. Calls originating outside the system are released with cause code CA_CCITT_NE_CAUSE_UNALLOCATED_NUM.

For Multiline Hunt Group (MLHG) and Centrex subscribers (INDIVIDUAL, MLHG_INDIVIDUAL, and CTXG_INDIVIDUAL), the announcement heard is the number from the directory number (DN)1 field of the Subscriber table. For all other types of subscribers, the announcement played is the calling number, if available.

The applicable cause code is 1306, OWN_CALLING_NUM. The Cisco Announcement Server ID is 903, and the ThinkEngine Networks Announcement Server ID is 92.

In Release 5.0, MR1, the handset user can activate the feature through a vertical service code (VSC). You can continue to activate the OCNA feature by provisioning a dial plan and destination.

The following limitations apply:

The OCNA is only played if the calling party is a subscriber. Non-subscriber calls are released with cause code CA_CCITT_NE_CAUSE_UNALLOCATED_NUM.

The OCNA feature is used during line installation/turn-up. The feature invocation occurs when a DN is not already involved in a call and will not be provided if attempted after a hookflash from a DN already involved in a call.


Tip To provision this feature, see the OCNA provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Privacy Screening (Calling Identity with Enhanced Screening)

The Privacy Screening feature enables a subscriber to accept or reject an anonymous call based on a short message recorded by the caller. This feature allows the caller to:

Record a short message—After listening to the message, the subscriber can accept or reject the incoming call or forward it to voice mail.

Enter a private identification number (PIN)—Entering the correct PIN rings the subscriber, and the call becomes a regular call.

Privacy Screening works in conjunction with a ThinkEngine Networks Privacy Screening Application Server (AS) and Media Server (MS) capable of interactive voice response (IVR functionality), as shown in Figure 3-6.

Figure 3-6 Example of Privacy Screening Configuration


Tip For more details about the IVR interactions for this feature, see Chapter 6, "Interactive Voice Response Functions."


Privacy Screening Description

The Privacy Screening feature is composed of the following two subfeatures:

Privacy Screening Invocation

Privacy Screening Subscriber Management

Privacy Screening Invocation

The Privacy Screening feature is implemented when the BTS 10200 reroutes an incoming anonymous call to the Application Server (AS) via a SIP trunk. The Cisco BTS 10200  Softswitch handles call processing for the call to the AS and for the call from the AS to the subscriber. The AS accepts the incoming call and performs the remaining functions, for example, connecting to the Media Server (MS), collecting the PIN, and recording the message.

The AS determines the active/inactive status of the Privacy Screening feature. All anonymous calls to a Privacy Screening subscriber will terminate on the AS even when the feature is inactive for the subscriber. If the Privacy Screening feature is inactive, the AS forwards the call to the subscriber.


Note If the AS is not reachable, incoming anonymous calls for the subscriber will be terminated on the subscriber.


The Privacy Screening feature is invoked using the following steps:

1. Caller A places an anonymous call to Subscriber B. Subscriber B has activated the Privacy Screening feature.

2. The call is intercepted by the Privacy Screening feature, which plays an announcement asking Caller A to either enter a PIN or wait to record a short message to be delivered to Subscriber B.

3. If Caller A enters the correct PIN, the call is forwarded to Subscriber B and becomes a regular call from this point forward. If Caller A enters an incorrect PIN, they are prompted to reenter the PIN for a maximum number of times.

4. If Caller A waits, they hear an announcement asking then to record a short message, usually their name.

5. Caller A records the message and is placed on hold.

6. A call is placed to Subscriber B to play the recorded message. Subscriber B has the following choices:

Review the caller name

Accept the call

Forward the call to voice mail, if the user subscribes to the voice mail feature

Play the not available announcement

Play the no solicitation announcement

Replay this menu

7. The call is connected or disconnected according to the choice made by Subscriber B.


Privacy Screening Subscriber Management

The BTS 10200 determines if the subscriber is subscribed to the Privacy Screening feature and, if so, reroutes the call to the AS. The AS accepts the incoming call from the subscriber and performs management functions, including collecting the PIN, changing the PIN, and changing the active/inactive status.

Synchronization of Privacy Screening Status

The BTS 10200 processes Privacy Screening feature status updates, regardless of whether the feature is active or inactive due to star code or Digital Voice Portal processing on the AS.

If Privacy Screening is deactivated, the BTS 10200 does not relay the call to the Privacy Screening AS, and it invokes other features in the feature sequence.

If the Privacy Screening feature status is activated, the BTS 10200 relays the call to the ThinkEngine Networks AS for Privacy Screening handling.

Feature Interactions

This section describes the interaction of other subscriber features with the Privacy Screening feature.

Privacy Screening and ACR

If a subscriber has the Privacy Screening feature, calls will not receive the Anonymous Call Rejection (ACR) treatment, even if Privacy Screening is inactive. Privacy Screening and ACR are mutually exclusive features.

Privacy Screening and NSA

If a subscriber has both the Privacy Screening and No Solicitation Announcement (NSA) features assigned and active and receives an anonymous call, the Privacy Screening feature will be activated. If they receive a nonanonymous call, the NSA feature will be activated.

Privacy Screening and Caller-ID

On a call received by the subscriber from the AS, "PRIVACY SCREENING" or the AS directory number (DN) will be displayed.

Privacy Screening and Distinctive Ringing

A distinctive ringing tone is played for calls received by the subscriber.

Privacy Screening and CW/CIDCW/CWD

If a subscriber is on a call and receives a call placed by the Privacy Screening AS, the subscriber receives a distinctive call waiting tone. If the subscriber has the CIDCW feature active, the caller ID will display "PRIVACY SCREENING" or the AS DN.

Privacy Screening and Voice Mail

If a subscriber has Voice Mail Always (VMA) active, Privacy Screening calls will be forwarded to voice mail.

If the subscriber is busy on another call or does not answer and has VM active, a Privacy Screening call will be forwarded to voice mail.

Privacy Screening and CFU/CFB/CFNA

If a subscriber has Call Forwarding Unconditional (CFU) active, an incoming anonymous call will receive Privacy Screening and, if the caller records his or her name or enters a correct PIN, CFU forwards the call to the forward-to DN.

If the forwarded-to number is busy and the subscriber has Call Forwarding Busy (CFB) active, CFB forwards the call to the forward-to DN.

If the subscriber has Call Forwarding No Answer (CFNA) active and does not answer, CFNA forwards the call to the forward-to DN.

Privacy Screening and DND

If a subscriber has both Privacy Screening and Do Not Disturb (DND) assigned and activated, an incoming anonymous call is assigned to the DND feature.

Privacy Screening and SCR

If a subscriber receives an anonymous call from a caller whose DN is in the subscriber's Selective Call Rejection (SCR) list, SCR blocks the call. If the caller's DN is not in the SCR list and the subscriber has Privacy Screening activated, the call receives Privacy Screening.

Privacy Screening and SCA

If a subscriber receives an anonymous call from a caller whose DN is not in the Selective Call Acceptance (SCA) list, SCA blocks the call. If the caller's DN is in the SCA list and the subscriber has Privacy Screening active, the call receives Privacy Screening.

Feature Precedence

If a subscriber has Privacy Screening and DND features active, the following precedence chain will be implemented:

SCR>SCA>SCF>DRCW>Privacy Screening>ACR>CFU>DND>NSA

Feature Provisioning Commands


Tip To provision this feature, see the Privacy Screening provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Speed Call

The speed call feature is based on LSSGR module FSD 01-02-1101 (TR-TSY-000570), Speed Calling.

Speed Call for Individual Subscribers

The speed call feature allows a user to program the phone line so that they can dial selected or frequently called numbers using just one or two digits. After programming the line from their handset, the user can enter the one- or two-digit number, followed by the # symbol or a four-second delay, and the system automatically dials the applicable DN. The programming data is stored in the SC1D (one-digit) or SC2D (two-digit) table of the Cisco BTS 10200 Softswitch. These tables can also be programmed by the service provider via CLI commands.

To program the line, the user listens for a dial tone, then enters the VSC for one-digit or two-digit speed dial. VSCs are provisionable by the service provider. The VSCs listed below are examples:

*74 is used for one-digit speed call, which accommodates up to 8 numbers (2 through 9)

*75 is used for two-digit speed call, which accommodates up to 30 numbers (20 through 49)

After entering the service code, the user can either enter the end-of-dialing signal (#) or wait 4 seconds to receive the recall dial tone (stutter tone). After receiving recall dial tone, the user enters the appropriate one-digit or two-digit speed code followed by the complete phone number (including any prefixes such as 1 and the area code). A confirmation tone is then returned to the user, followed by a delay of one to 2 seconds, and then regular dial tone. Changes to existing programmed speed codes are also made in the manner described above.

After the speed code is programmed, the user can speed call as follows:

1. Go off hook and enter the one- or two-digit speed code instead of the phone number.

2. Press the # symbol or wait for 4 seconds.

3. The system automatically places the call to the DN associated with the speed code.


Tip To provision this feature, see the Speed Call provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Group Speed Call

The group speed call feature allows members of a Centrex group or multiline hunt group (MLHG) to program a list so that they can select and dial frequently called numbers using one or two digits. The group speed call provisioning process is similar to provisioning for individual subscribers, but also involves provisioning of the custom dial plan table. A handset user is allowed both one- and two-digit speed calling. In the case of shared lists for group speed calling, only one of the users sharing the list can have the user-changeable option. The switch is able to provide a given line with both a shared list and an individual list with the requirement that one must be a one-digit list and the other a two-digit list.

If speed calling is assigned to a multiline hunt group, all members of that group have access to the shared group speed call list. If, however, a line in the group also has individual speed calling, then the individual speed calling takes precedence over the group speed calling.


Note When both speed call and group speed call features are assigned to the main subscriber, both features are inherited by all members of the group (having GRP=Y in subscriber table). When a member subscriber attempts to invoke speed call feature, the individual speed calling takes precedence over group speed-calling. The group-speed-call feature is not invoked in such scenarios.



Tip To provision this feature, see the Group Speed Call provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Subscriber-Controlled Services and Screening List Editing (SLE)

Subscriber-controlled services allow individual users to screen and manage their incoming calls. The user can specify lists of DNs for which incoming calls are to be screened and given any of the following treatments—Selective Call Forwarding (SCF), Selective Call Acceptance (SCA), Selective Call Rejection (SCR), and Distinctive Ringing/Call Waiting (DRCW). The user can create screening lists, add DNs to the lists, and edit the lists, via the screening list editing (SLE) function as described in the Telcordia document GR-220-CORE, Screening List Editing.

CORBA Interface

The Cisco BTS 10200 Softswitch provides the necessary CORBA interface for service providers interested in building web-based applications that permit users to perform these SLE functions via the web. A web CORBA software development kit (SDK) is provided as part of the Cisco BTS 10200 Softswitch product.

User Access

The user accesses the SLE functions, including activation/deactivation of the services, via VSCs. Each VSC connects the user to the appropriate interactive voice response (IVR) media server functions. The VSCs are preprovisioned in the Cisco BTS 10200 Softswitch as listed below.


Note For each feature, a pair of preprovisioned VSCs is listed. Either VSC in the pair can be used to access the IVR server to perform all review, edit, activation, and deactivation functions. The service provider has the option of reprovisioning VSCs as desired.


Selective Call Forwarding (SCF)—*63/*83

Selective Call Acceptance (SCA)—*64/*84

Selective Call Rejection (SCR)—*60/*80

Distinctive Ringing/Call Waiting (DRCW)—*61/*81

The individual features are described in the sections that follow.


Tip For more details about the IVR interactions for this feature, see Chapter 6, "Interactive Voice Response Functions."



Tip To provision these features, see the Screening List Editing (SCF, SCA, SCR, DRCW) provisioning procedures in the Cisco BTS 10200 Softswitch Provisioning Guide.


Selective Call Forwarding (SCF)

The selective call forwarding (SCF) feature screens each incoming call to determine whether the DN is on a list of DNs, provisioned by the user (called party), to receive automatic forwarding treatment. The user also sets the forward-to number. Any incoming calls from DNs that are on the SCF screening list are forwarded to the designated number. Any incoming calls from DNs not on the SCF screening list receive regular treatment (they are not forwarded).


Note The service provider can provision a reminder ring for the SCF feature. For a description of reminder ring, see the "CFU Activation (CFUA)" section.


The user accesses and controls the SCF properties from their handset via a VSC and IVR interaction. The user can add or delete DNs on the screening list, change the forward-to number, review the screening list, and activate or deactivate SCF. As a convenience, the system allows the user to add or delete the last caller's number to the screening list by entering 01 at the prompt. The system recognizes the "01" command and translates it into the last-received DN.

The following conditions apply to the use of the SCF feature:

TWC and CW are disabled while the user is editing the list or activating/deactivating the SCF feature.

If SCF is active, it takes precedence over all other call forwarding features including CW and DRCW. It does not take precedence over SCR.

The forward-to number defined in SCF can be the same number used by other call forwarding features, or it can be different.

Once the SCF feature is activated, it remains active until it is deactivated.

Selective Call Acceptance (SCA)

The selective call acceptance (SCA) feature screens each incoming call to determine whether the DN is on a list of DNs, provisioned by the user (called party), to be accepted. Any incoming calls from DNs on the SCA screening list are accepted, but any incoming calls from DNs not on the SCA screening list are blocked (receive terminating treatment).

The user accesses and controls the SCA properties from their handset via a VSC and IVR interaction. The user can add or delete DNs on the screening list, review the screening list, and activate or deactivate SCA. As a convenience, the system allows the user to add or delete the last caller's number to the screening list by entering 01 at the prompt. The system recognizes the 01 command and translates it into the last-received DN.

The following conditions apply to the use of the SCA feature:

TWC and CW are disabled while the user is editing the list or activating/deactivating the SCA feature.

Once the SCA feature is activated, it remains active until it is deactivated.

Selective Call Rejection (SCR)

The selective call rejection (SCR) feature screens each incoming call to determine whether the DN is on a list of DNs, provisioned by the user (called party), to be blocked. The blocked caller is connected to an announcement stating that their call is not presently being accepted by the called party. Any incoming calls from DNs not on the SCR screening list receive regular treatment (they are not blocked).

The user accesses and controls the SCR properties from their handset via a VSC and IVR interaction. The user can add or delete DNs on the screening list, review the screening list, and activate or deactivate SCR. As a convenience, the system allows the user to add or delete the last caller's number to the screening list by entering 01 at the prompt. The system recognizes the 01 command and translates it into the last-received DN.

The following conditions apply to the use of the SCR feature:

TWC and CW are disabled while the user is editing the list or activating/deactivating the SCR feature.

If SCR is active, it takes precedence over all call forwarding features including CW and DRCW.

Once the SCR feature is activated, it remains active until it is deactivated.


Note The call block/reject caller feature (see "Call Block - Reject Caller (CBLK)" section) provides another way for the user to selectively reject calls from the last caller.


Distinctive Ringing/Call Waiting (DRCW)

The distinctive ringing/call waiting (DRCW) feature screens each incoming call to determine whether the DN is on a list of DNs, provisioned by the user (called party), to receive special ringing or CW alerting treatment. If the incoming DN is on the DRCW screening list, the system alerts the user with a special ring or a special CW tone. Any incoming calls from DNs not on the DRCW screening list receive regular treatment (regular ringing and CW alerting tones).

The user accesses and controls the DRCW properties from their handset via a VSC and IVR interaction. The user can add or delete DNs on the screening list, review the screening list, and activate or deactivate DRCW. As a convenience, the system allows the user to add or delete the last caller's number to the screening list by entering 01 at the prompt. The system recognizes the 01 command and translates it into the last-received DN.

Once the DRCW feature is activated, it remains active until it is deactivated.


Note The DRCW feature is only for playing a distinctive ringing or distinctive call-waiting tone, and does not affect the activation of the call-waiting features (CW, CWD, or CIDCW). A subscriber must have CW, CWD, or CIDCW provisioned and activated in order to receive call-waiting treatment.


Temporarily Disconnected Subscriber Status and Soft Dial Tone

This feature allows the service provider to assign a status of temporarily disconnected (TDISC) to specific subscribers, and restrict incoming and outgoing calls for those subscribers. Using this feature, the service provider can block subscribers with delinquent accounts from making any outbound calls to numbers other than (for example) emergency, repair services, or billing department. Incoming calls disconnected due to TDISC hear an appropriate generic announcement.

This feature is applicable to POTS and Centrex subscribers. For Centrex applications, the service provider can provision the TDISC feature at the individual subscriber level and at the main-subscriber level.


Note The system never attempts to perform COS screening on call types EMG (including 911), EXTENSION, or VSC. There is no provisioning option to allow COS screening to occur on these call types.


Provisioning Options and System Behavior

This section describes the system behavior for subscribers in the TDISC state, which is dependent on certain parameters provisioned in the database.

Scenario 1, total service denial—This option prohibits all calls, both incoming and outgoing. No dial tone and no emergency service are available for a subscriber in this state. To set this option (total service denial), provision STATUS=TEMP-DISCONNECTED in the subscriber table, and TEMP-DISC-SERVICE-ALLOWED=N in the pop table.


Note The system checks the value of the TEMP-DISC-SERVICE-ALLOWED token in the main-subscriber pop table only if the STATUS token in the subscriber table is set to TEMP-DISCONNECTED.


Scenario 2, limited service (soft dial tone)—This option prohibits all calls, both incoming and outgoing, except for calls to/from emergency services (for example, 911) and other specific DNs, such as repair (611) or other numbers configured by the service provider. To set this option, provision as follows:

Provision STATUS=TEMP-DISCONNECTED in the subscriber table.

Provision TEMP-DISC-SERVICE-ALLOWED=Y in the main-subscriber pop table. This setting causes the system to provide only those services consistent with the provisioning of the COS restrictions identified in the TEMP-DISC-COS-RESTRICT-ID token in the pop table.

Provision TEMP-DISC-COS-RESTRICT-ID=<ID of the applicable cos-restrict table> in the pop table. The system screens calls dialed by the TDISC subscriber according to this cos-restrict table.

Provision the applicable cos-restrict table to provide only the intended services, for example, emergency (such as 911), repair, and billing. This process may also include provisioning other tables such as the nod-wb-list table.


Note In the POP table, TEMP-DISC-COS-RESTRICT-ID is a mandatory field if TEMP-DISC-SERVICE-ALLOWED is set to Y. The value provisioned for TEMP-DISC-COS-RESTRICT-ID must match the ID of a valid COS-RESTRICT table, otherwise the system will not allow the command to go through.


Provision TEMP-DISC-ROUTE and CUSTOMER-SUPPORT-DN in the main-subscriber POP table to provide the desired treatment to the call.


Tip You can provision the trigger-nod-escape-list table to exclude specific call types from sending triggers at specific trigger ID points in the call. COS screening (at the COS-TRIGGER point in the call) can be bypassed for specific call types if provisioned appropriately in this table.


Feature Interactions

The following features interactions occur when the subscriber is in TDISC status.

Interaction of TDISC and BLV

The system does not allow busy line verification (BLV) on lines that are in TDISC status. A BLV attempt returns the same tone to the Operator as for the "BLV line not allowed" condition.

Interaction of TDISC and MIDCALL Features

All hookflash features (MIDCALL features) are blocked for a subscriber in TDISC status. Therefore, these users cannot initiate third-party calls. If the TDISC user wants to dial a call (even if it is an emergency/911 call) while on a basic call, the user will have to hang-up the basic call and then dial the next number separately.

Interaction of TDISC and VSC-Activated Features

The vertical service code (VSC) capability is blocked for a TDISC subscriber. Features such as the customer originated trace (COT) will not work for a subscriber in TDISC status.

Restrictions and Limitations

The following restrictions and limitations apply to the TDISC feature:

A subscriber trying to reach a TDISC subscriber normally hears an announcement that the terminating side is temporarily disconnected. However this announcement cannot be played if the terminating side is an ISDN subscriber and the route to reach that subscriber was anything other than subscriber routing in the Cisco BTS 10200 Softswitch. The routing used to reach the terminating subscriber's DN1 under these conditions must be subscriber routing.

Trunk-grp routing for TDISC is not supported.

Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the Temporary Disconnect provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Three-Way Calling (TWC)

The Cisco BTS 10200 Softswitch supports the three-way calling (TWC) feature as specified in LSSGR module FSD 01-02-1301 (TR-TSY-000577), Three-Way Calling.

Limitations

If your network uses an ISUP variant other than ANSI ISUP, the system supports TWCD, but not TWC or USTWC.

Feature Description

TWC is a feature provisioned by the service provider in response to a request from the subscriber. TWC allows a subscriber to add a third party to an existing two party conversation.

To activate a TWC, a user involved in a stable two-way call takes the following steps:

The user presses the Flash button or hookswitch. This places the remote end on hold.

The user hears the recall dial tone (three tones and then a dial tone), indicating the system is ready to receive the DN for the third party.

The user dials the DN of the third party.


Note If the user presses the Flash button or hookswitch before completing dialing, the original two-way connection is reestablished.


When the third party answers, only the user (who initiated the TWC) and the third party can hear and talk. This allows the user to speak privately with the third party before sending the second flash.

If the user presses the Flash button or hookswitch after successfully dialing the third party number, a three-way conference is established.

If either of the called parties (the two stations remote from the initiating party) hangs up, the call continues as a single-call session.

When in a TWC, the last party added can be disconnected by using the Flash button or hookswitch.

If the initiating party hangs up during a TWC, all parties are disconnected, unless the initiating party is also subscribed to CT (see the "TWC Feature Interactions" section).


Note During a TWC, the CW feature does not work for the party that initiated the TWC, but does work for the two called parties.


TWC Feature Interactions

When the TWC-initiating party hangs up during a TWC, and the TWC-initiating party is not subscribed to call transfer (CT), all parties are disconnected.

However, if the TWC-initiating party is also subscribed to CT (as provisioned in the subscriber-feature-profile table), the two remaining parties stay connected. The following scenarios occur, depending upon the actions of the parties in the call. In these scenarios, User A is subscribed to both CT and TWC and is the TWC-initiating party, B is the party in the initial established call with A, and C is the third party:

User A is in a stable call with B, places B on hold and dials C.

If A hangs up after successfully dialing C (C is ringing), a two-way call is established between B and C, regardless of whether C answers the call. User A is billed for a call transfer, but is not billed for the time that the other two parties are on the call.

If A waits until C answers the call, and then A hangs up, a two-way call is established between B and C. User A is billed for a call transfer and is also billed for the entire duration starting from the time A initiated the TWC until B and C hang up.

Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the TWC provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Three-Way Calling Deluxe (TWCD)

TWCD allows a user to add a third party to an existing two party conversation without operator assistance. The user subscribed to TWCD can use this feature regardless of which party originated the two-party call. The following conditions apply to the TWCD feature:

The TWCD feature can be provided to POTS, Centrex, and MLHG subscribers.

The TWCD feature is activated by the service provider at the request of the subscriber, and remains active unless deactivated by the service provider.

In the detailed process descriptions that follow, the initiating user (User "A") has the option of pressing 1, 2 or 3 after receiving recall (stutter) dial tone. In general, the system responds as follows:

If User "A" presses digit 1, the remote party currently connected with User "A" is dropped.

If User "A" presses digit 2, the remote party currently connected with User "A" is placed on hold, and User "A" is connected to the other remote party.

If User "A" presses digit 3, all three parties are immediately bridged into a single voice session (a three-way call).

To Begin a Three-Way Call:

To begin a three-way call, a user involved in a stable two-way call takes the following steps:

The user (User "A") presses the Flash button or hookswitch. The system places the remote party (User "B") on hold and provides a recall (stutter) dial tone to User "A".

After receiving the recall dial tone, User "A" dials the DN of a third party (User "C"). If User "C" answers the call, User "A" and User "C" can talk privately, and User "B" remains on hold.


Note If the user presses the Flash button or hookswitch before completing dialing, the original two-way connection is reestablished.



Note If User "C" cannot be reached, or does not answer the call, the system provides the applicable busy tone, error tone, or error message to User "A". However, the system leaves User "B" on hold regardless of the treatment given to User "A" and User "C".


To bridge all three parties, User "A" presses the Flash button or hookswitch. This places User "C" on hold (and User "B" remains on hold also) and provides a recall dial tone to User "A". If User "A" presses the digit 3, all three parties are immediately bridged into a single voice session (a three-way call).

Options While on a Three-Way Call with All Three Parties Bridged Together:

While on a three-way call with all three parties bridged together, User "A" can take one of the following actions:

To drop User "C" and return to the original conversation with User "B", User "A" presses the Flash button or hookswitch. This places both of the other parties on hold and provides a recall dial tone to User "A". If User "A" presses the digit 1, User "C" is dropped and the original call between User "A" and User "B" is reestablished.

To drop User "B" and return to the conversation with User "C", User "A" presses the Flash button or hookswitch. This places both of the other parties on hold and provides a recall dial tone to User "A". If User "A" presses the digit 2, User "C" is placed on hold, and the original call between User "A" and User "B" is reestablished. User "A" can then drop User "B" using Flash and digit 1, and the call between User "A" and User "C" is reestablished.

To alternate conversations with User "B" and User "C", User "A" presses the Flash button or hookswitch. This places both of the other parties on hold and provides a recall dial tone to User "A". If User "A" presses the digit 2, User "C" is placed on hold and the original call between User "A" and User "B" is reestablished. From this point User "A" can press the Flash button or hookswitch, receive recall dial tone, and press 2 to alternate between the parties. This is the same function as for call waiting deluxe (CWD).


Note During a three-way call, the CWD feature does not work for the party that initiated the three-way call (that is, if a fourth party attempts to reach User "A"). User "A" would not be aware of the additional incoming call attempt. However, CWD would work normally for the two called parties (User "B" and User "C").


To Drop User "C" and Return to the Original Call with User "B":

To speak with User "C" and then drop User "C" and return to the original call with User "B", User "A" (while involved in a stable two-way call) takes the following steps:

The user (User "A") presses the Flash button or hookswitch. The system places the remote party (User "B") on hold and provides a recall (stutter) dial tone to User "A".

After receiving the recall dial tone, User "A" dials the DN of a third party (User "C"). If User "C" answers the call, User "A" and User "C" can talk privately, and User "B" remains on hold.


Note If User "C" cannot be reached, or does not answer the call, the system provides the applicable busy tone, error tone or error message to User "A". However, the system leaves User "B" on hold regardless of the treatment given to User "A" and User "C".


To drop User "C" and return to the original conversation with User "B", User "A" presses the Flash button or hookswitch. This places User "C" on hold (and User "B" remains on hold also) and provides a recall dial tone to User "A". If User "A" presses the digit 1, User "C" is dropped and the original call between User "A" and User "B" is reestablished.

To Put User "C" on Hold and Return to the Original Call with User "B":

To speak with User "C", and then put User "C" on hold and return to the original call with User "B", User "A" (while involved in a stable two-way call) takes the following steps:

The user (User "A") presses the Flash button or hookswitch. The system places the remote party (User "B") on hold and provides a recall (stutter) dial tone to User "A".

After receiving the recall dial tone, User "A" dials the DN of a third party (User "C"). If User "C" answers the call, User "A" and User "C" can talk privately, and User "B" remains on hold.


Note If User "C" cannot be reached, or does not answer the call, the system provides the applicable busy tone, error tone or error message to User "A". However, the system leaves User "B" on hold regardless of the treatment given to User "A" and User "C".


To put User "C" on hold and return to the original conversation with User "B", User "A" presses the Flash button or hookswitch. This places User "C" on hold (and User "B" remains on hold also) and provides a recall dial tone to User "A". If User "A" presses the digit 2, User "C" is placed on hold and the original call between User "A" and User "B" is reestablished. From this point User "A" can press the Flash button or hookswitch, receive recall dial tone, and press 2 to alternate between the parties.

To Drop User "B" and Continue the Call with User "C":

To speak with User "C", and then drop User "B" and continue the call with User "C", User "A" (while involved in a stable two-way call to User "B") takes the following steps:

The user (User "A") presses the Flash button or hookswitch. The system places the remote party (User "B") on hold and provides a recall (stutter) dial tone to User "A".

After receiving the recall dial tone, User "A" dials the DN of a third party (User "C"). If User "C" answers the call, User "A" and User "C" can talk privately, and User "B" remains on hold.


Note If User "C" cannot be reached, or does not answer the call, the system provides the applicable busy tone, error tone or error message to User "A". However, the system leaves User "B" on hold regardless of the treatment given to User "A" and User "C".


To put User "C" on hold and return to the original conversation with User "B", User "A" presses the Flash button or hookswitch. This places User "C" on hold (and User "B" remains on hold also) and provides a recall dial tone to User "A". If User "A" presses the digit 2, User "C" is placed on hold and the original call between User "A" and User "B" is reestablished.

To drop User "B" and return to the conversation with User "C", User "A" presses the Flash button or hookswitch. This places User "B" on hold (and User "C" remains on hold also) and provides a recall dial tone to User "A". If User "A" presses the digit 1, User "B" is dropped and the call between User "A" and User "C" is reestablished.

TWCD Feature Behavior When a Party Disconnects:

When a three-way call has been established with all three parties bridged together, the following actions take place when one of the parties disconnects (hangs up):

If User "A" (the TWCD-initiating party) disconnects, all connections are dropped, unless User "A" is also subscribed to CT (see the "TWCD Feature Interactions" section).

If User "B" disconnects, a two-way call continues between User "A" and User "C".

If User "C" disconnects, a two-way call continues between User "A" and User "B".


Note When User "B" or User "C" disconnects, and User "A" is in a two-way call with the remaining party, User "A" can initiate a new three-way call using the procedures described above.


TWCD Timers

There are two timers that apply to the TWCD feature:

Feature reconnect timer (FEATURE-RECONNECT-TMR), measured in seconds—During the course of using the TWCD feature, if the subscriber is connected to a reorder tone or announcement, the subscriber is automatically reconnected to the previous call leg after the specified FEATURE-RECONNECT-TMR timeout period. The default value is 10.

Reconnect timer (RECONNECT-TMR), measured in seconds—When a subscriber hangs up with another call on hold, the subscriber is rung back. The ringing is applied for the duration of this RECONNECT-TMR. If the subscriber does not answer the call within this time period, the call is torn down. The default value can be provisioned in the CA-CONFIG table. If the timer is not provisioned in the CA-CONFIG table, the preset value 36 is used as default.

Invalid User Actions

The valid user actions are described in the sections above. The following user actions are invalid, and the system provides an appropriate error announcement:

The user presses the Flash button or hookswitch, receives recall dial tone, and then enters a DN that is invalid.

The user presses the Flash button or hookswitch, receives recall dial tone, and then enters a digit other than 1, 2, or 3.

TWCD Feature Interactions

TWCD and TWC interaction

When TWCD and TWC are assigned to the same line, TWCD has higher precedence than TWC.

TWCD and CT Interaction

If TWCD and CT are assigned to the same line, CT has higher precedence than TWCD.

When the TWCD-initiating party hangs up during a TWCD, and the TWCD-initiating party is not subscribed to call transfer (CT), all parties are disconnected.

However, if the TWCD-initiating party is also subscribed to CT (as provisioned in the subscriber-feature-profile table), the two remaining parties stay connected. The following scenarios occur, depending upon the actions of the parties in the call. In these scenarios, User A is subscribed to both CT and TWCD and is the TWC-initiating party, B is the party in the initial established call with A, and C is the third party:

User A is in a stable call with B, places B on hold and dials C.

If A hangs up after successfully dialing C (C is ringing), a two-way call is established between B and C, regardless of whether C answers the call. User A is billed for a call transfer, but is not billed for the time that the other two parties are on the call.

If A waits until C answers the call, and then A hangs up, a two-way call is established between B and C. User A is billed for a call transfer and is also billed for the entire duration starting from the time A initiated the TWC until B and C hang up.

TWCD and CWD Interaction

The invocation of these two features is mutual exclusive. When one feature is invoked, the other feature is not allowed.


Note During a three-way call, the CWD feature does not work for the party that initiated the three-way call. However, the CWD feature would work normally for the other two (non-initiating) parties.


TWCD and OCB Interaction

When TWCD and OCB are assigned to the same line, and if OCB is activated, when the user presses the Flash button or hookswitch to make a second call, the second call is subject to OCB screening.

Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the TWCD provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Usage-Sensitive Three-Way Calling (USTWC)

The Cisco BTS 10200 Softswitch supports usage-sensitive three-way calling (USTWC) feature as specified in LSSGR module FSD 01-02-1304 (TR-TSY-000578), Usage-Sensitive Three-Way Calling.

Limitations

If your network uses an ISUP variant other than ANSI ISUP, the system supports TWCD, but not TWC or USTWC.

Feature Description

USTWC allows a user to add a third party to an existing two party conversation. It provides all the functionality of TWC (see the "Three-Way Calling (TWC)" section) without requiring the user to subscribe to the service. The service provider may charge differently for the use of this service. The usage-sensitive features can be enabled/inhibited per user by turning on/off the usage-sensitive option for the user.

The user activates and uses this service in the same manner as TWC.


Note The USTWC feature can be made available to all subscribers lines connected to a BTS 10200 using the default office service ID, or to all subscribers in a specific POP using the office service ID. See the "Office Service ID and Default Office Service ID" section for a general description of this provisionable service.


Feature Provisioning Commands

Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision this feature, see the USTWC provisioning procedure in the Cisco BTS 10200 Softswitch documentation set.


Visual Message Waiting Indicator (VMWI)

See the "Message Waiting Indicator (MWI)—Audible and Visual" section.

Voice Mail (VM) and Voice Mail Always (VMA)

The BTS 10200 supports Voice Mail (VM) and Voice Mail Always (VMA) features for individual, Centrex, and MLHG subscribers. These features allow subscribers to:

Forward calls to voice mail when subscribers are busy, or when subscribers do not answer the phone. This is referred to as VM.

Forward all calls to voice mail regardless of the subscriber's phone status and without attempting to ring the subscriber's phone. This is referred to as VMA.

Dial designated VSC codes to activate/deactivate the feature, and dial a dedicated DN (or use a designated VSC) to access the voice mail server to retrieve their messages. If activated, the VSC serves as a shortcut to voice mail.

VM and VMA have interactions with all of the other call-forwarding features (CFU, CFB, CFNA, and CFC). The following interactions apply for these features when activated:

If activated, CFU takes precedence over both VM and VMA.

If activated, CFB, CFNA, and CFC all take precedence over VM.

VMA takes precedence over CFB, CFNA, and CFC.

Some caveats apply to the above list of interactions. See the "Feature Interactions" section.


Note The system does not support VM or VMA managed by the GUI Feature Server for IP phones in this release.


VM Activation, Deactivation, and Invocation

This section describes VM activation, deactivation, and invocation.

VM Activation

The subscriber activates VM on the phone by:

1. Picking up the phone, and hearing a dial tone.

2. Dialing the VM Activation access code.

The subscriber hears an appropriate announcement depending on whether the activation was successful or not.

The activation attempt fails for the following scenarios. In these cases, the subscriber hears an appropriate error announcement if:

VM is not assigned to the subscriber.

VM is already active.

A success activation attempt results in a confirmation announcement.


Note When assigned, VM is considered activated unless explicitly deactivated by either the subscriber or the operator.


VM Deactivation

The subscriber deactivates VM on the phone by:

1. Picking up the phone, and hearing a dial tone.

2. Dialing the VM Deactivation access code.

The subscriber hears an appropriate announcement based on whether the deactivation was successful or not. The deactivation attempt fails for the following scenarios; in these cases, the subscriber hears an appropriate error announcement:

VM is not assigned to the subscriber.

VM is already deactivated.

A success deactivation attempt results in a confirmation announcement.

VM Invocation

If the subscriber is either busy or does not answer the phone, incoming calls to a subscriber who has VM activated are forwarded to a voice mail server where the caller is guided to leave a message. The subscriber can later retrieve the message.

VMA Activation, Deactivation, and Invocation

This section describes VMA activation, deactivation, and invocation.

VMA Activation

The subscriber activates VMA on the phone by:

1. Picking up the phone, and hearing a dial tone.

2. Dialing the VMA Activation access code.

The subscriber hears an appropriate announcement depending on whether the activation was successful or not.

The activation attempt fails for the following scenarios. In these cases, the subscriber hears an appropriate error announcement if:

VMA is not assigned to the subscriber.

VMA is already active.

A success activation attempt results in a confirmation announcement.


Note When assigned, VMA is considered deactivated unless explicitly activated by either the subscriber or the operator.


VMA Deactivation

The subscriber deactivates VMA on the phone by:

1. Picking up the phone, and hearing a dial tone.

2. Dialing the VMA Deactivation access code.

The subscriber hears an appropriate announcement based on whether the deactivation was successful or not. The deactivation attempt fails for the following scenarios; in these cases, the subscriber hears an appropriate error announcement:

VMA is not assigned to the subscriber.

VMA is already deactivated.

A success deactivation attempt results in a confirmation announcement.

VMA Invocation

Incoming calls to a subscriber who has VMA activated are forwarded to a voice mail server where the caller is guided to leave a message. The subscriber can later retrieve the message.

VM Access

The VM Access subfeatures allow the subscriber to retrieve messages by dialing the VM Access code. The procedure is as follows:

1. If the subscriber has a new message waiting, the system plays a stutter dial tone when the phone goes off-hook. Alternatively, if the subscriber has the visual message waiting indicator (VMWI) function assigned and active, the indicator light goes on.

2. The subscriber picks up the phone and dials the VM Access code. If successful, subscriber is guided through a menu to manage the messages.

Access can fail for the following scenarios. In these cases, the subscriber hears an appropriate error announcement.

The subscriber is not assigned the VM Access subfeature.

The service provider has not assigned an Access Code for the VM Access subfeature.


Tip For information on message waiting indicators, typically used in conjunction with VM and VMA, see the "Message Waiting Indicator (MWI)—Audible and Visual" section.


Provisionable Parameters for VM and VMA

This section provides information on several tables and parameters that affect the behavior of the VM and VMA features.

Feature Table

VM and VMA are implemented by provisioning the following features in the feature table:

VM

VM_ACT

VM_DEACT

VMA

VMA_ACT

VMA_DEACT

VM_ACCESS

The feature table contains two parameters that affect VM/VMA behavior:

Multiple call forwarding (MCF) parameter (applicable to both VM and VMA)—There can be multiple voice mail sessions active on a subscriber at one time based on the MCF flag. If the MCF flag is set to Y (default value), multiple concurrent sessions to voice mail are allowed. If the MCF flag is set to N, the system rejects subsequent sessions to voice mail, and the caller hears a busy tone or a busy announcement. The Voice Mail Application Server can support multiple incoming calls for the same subscriber.

Timeout (TO) parameter (applicable to VM only)—TO denotes the number of seconds the system waits for the subscriber to answer an incoming call before forwarding the call to voice mail. The default value for TO is 30 seconds (approximately 6 rings). Although the system does not block provisioning a higher TO value, the recommended range for TO is from 6 to 180 seconds.


Note There is also a TO parameter in the subscriber-feature-data table. If both the subscriber-feature-data and feature tables have the TO value provisioned, the system uses the value provisioned in the subscriber-feature-data table.


VSC Provisioning

The Vertical Service Code (VSC) is provisionable and can be any unique valid string of ASCII characters; for example, *222.

VM Forwarding Directory Number

There are two directory numbers (DNs) provisioned in the Application Server (app-server) table:

APP-SERVER-DN—This is the voice-mail directory number (DN), and is used to forward an incoming call to the voice mail server.

APP-SERVER-ACCESS-DN—This is the DN used when the subscriber accesses the VM/VMA management features to change the VM settings. If this token is not provisioned, it defaults to the value provisioned for APP-SERVER-DN.


Note Subscribers cannot set or change the DNs for the application server or application server access.


Additional features of the app-server table are as follows:

The APP-SERVER-TYPE token must be set to VM to identify this server as a voice-mail server.

The system can be provisioned to access multiple VM servers.

The ID of the app-server table is indexed (as the VOICE-MAIL-ID token) in the Subscriber (subscriber), Subscriber Profile (subscriber-profile), and POP (pop) tables. The system applies the following rules when selecting the specific app-server table applicable to a particular subscriber:

If the subscriber and subscriber-profile tables are indexed to different app-server IDs (VOICE-MAIL-ID token), the app-server in the subscriber table is used.

If the subscriber-profile and pop tables are indexed to different app-server IDs, the entry pointed to by the subscriber-profile table is used.

If the pop and ca-config tables are indexed to different app-server IDs, the entry pointed to by the pop table is used.

If the app-server ID (VOICE-MAIL-ID token) is not provisioned at any level (subscriber, subscriber-profile, or pop), the system uses the switch-level default app-server ID (TYPE=DEFAULT-VOICE-MAIL-ID) provisioned in the Call Agent Configuration (ca-config) table.

Feature Provisioning Procedure

Provisioning procedures are available in the Cisco BTS 10200 Softswitch Provisioning Guide.


Tip To provision the VM and VMA features, see the VM provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Feature Interactions

The following interactions between features is implemented as a part of this feature development.

CFU, CFB and CFNA:

Table 3-26 summarizes these interactions.

.

Table 3-26 VM and VMA Interactions with Call-Forwarding 

Voice Mail Features Active
Forwarding Features Active
Interaction

VM

CFU

Call is forwarded by CFU.

VM

CFB

Calls on which the subscriber is busy are forwarded by CFB.

Calls on no answer from the subscriber are forwarded by VM.

VM

CFNA

Calls when subscriber is away from the phone are forwarded by CFNA. This is true even if the CFNA timeout is greater than the VM timeout.

Calls when the subscriber is busy are forwarded by VM.

VM

CFU and (CFB or/and CFNA)

Call is forwarded by CFU.

VMA

CFU

Call is forwarded by CFU.

VMA

CFB or/and CFNA

Call is forwarded by VMA

VMA

CFU and (CFB or/and CFNA)

Call is forwarded by CFU.

VM and VMA

CFU

Call is forwarded by CFU.

VM and VMA

CFB or/and CFNA

Call is forwarded by VMA.


Selective Call Acceptance/Rejection Features (SCA, SCR)

If the call is accepted by SCA or not rejected by SCR, then the call is forwarded by VM if the subscriber is busy or does not answer within the VM timeout. Also, if accepted by SCA/SCR, the call is forwarded to voice mail if the subscriber has VMA active. If the call is not accepted by SCA or rejected by SCR, the call does not go to voice mail.

Selective Call Forwarding

If an incoming call is not selectively forwarded (i.e., the call terminates on the subscriber's phone), the call is forwarded by VM if the subscriber is busy or does not answer within the VM timeout. Also, if an incoming call is not selectively forwarded (i.e., the call terminates on the subscriber's phone), the call is forwarded to voice mail if the subscriber has VMA active. If the call is selectively forwarded, it does not go to voice mail.

Do Not Disturb

If a subscriber has DND and VM assigned and active, the call is redirected by VM.

If a subscriber has DND and VMA assigned and active, the call is redirected by VMA.

Anonymous Call Rejection

If the call is accepted ACR, then it is forwarded by VM if the subscriber is busy or does not answer within the VM timeout. Also, if the call is accepted by ACR, then it is forwarded by VMA if the subscriber has VMA active. If the call is rejected, it does not go to voice mail.

Abbreviated Dialing/Speed Call

The subscriber can provision the speed call or abbreviated dial to the VM/VMA activation, deactivation or access codes. The subscriber can then invoke any of these features by dialing the speed code or the abbreviated dial numbers.

Voice Mail and CW/CIDCW/CWD

The subscriber can send calls to voice mail if already on a call. If the subscriber has CW/CIDCW/CWD and does not answer an incoming call, the call is redirected by VM/VMA if active.

It is important to be aware of several provisionable parameters that can further affect the processing of this call.

The CW timeout is based on a switch-wide parameter, NO-ANSWER-TMR in the ca-config table (default 185 seconds). There is also a parameter, START-NO-ANSWER-TMR in the ca-config table, to specify whether NO-ANSWER-TMR is to be started or not; default is N.

The VM timeout is provisioned via the TYPE1=TO parameter in the Feature table (default 4 seconds).

If Subscriber A has the default timer settings (that is, VM TO=4 seconds and NO-ANSWER-TIMER=185 seconds), and has the START-NO-ANSWER-TMR parameter set to Y (not the default), the call is processed as follows:

[1] A calls B, B answers.

[2] C calls A, A hears the CW tone, C hears ring tone.

[3] If A does not attempt to answer the waiting call (C), and VM times out (4 seconds), C is forwarded according to normal VM forwarding procedures.

However, if the VM timeout (TO) is set to a value greater than NO-ANSWER-TMR, when NO-ANSWER-TMR expires, C is disconnected and hears a busy tone, and VM is cancelled.

There is an interaction when a Centrex subscriber has all three of the following features assigned and active:

1. Call hold—CHD.

2. Call waiting—CW or CIDCW or both.

3. Call forwarding on no answer—CFNA, VM (or VMA), or any combination of these.

For information on this interaction, see the "CHD with CW/CIDCW and CFNA/VM/VMA" section.

Hotline/Warmline/HOTV

The subscriber cannot provision hotline or warmline/HOTV features to the VM/VMA activation, deactivation or access codes.

COS/OCB and Voice Mail

The system does not apply COS or OCB screening to calls which are redirected to voice mail or when the subscriber accesses the voice mail.

Warmline Service

Warmline service is a combination of hotline service (see the "Hotline Service" section) and regular phone service on the same line. The service is activated by the service provider at the request of the subscriber. The service provider provisions a timeout parameter in the FEATURE table (default is 4 seconds), and the warmline service uses that timeout value as follows:

Use of warmline for regular phone service—The user takes the handset off hook, receives dial tone, and starts dialing a regular call before the timeout expires.

Use of warmline as a hotline—The user takes the handset off hook, receives dial tone, but does not dial any digits. After the timeout expires, the system automatically calls the predetermined DN.


Note This timeout is a switch-level timeout common to all subscribers, and normally not changed on a per-subscriber basis.



Note This variable timeout feature operates with MGWs that are compliant with MGCP1.0 (per IETF document RFC 2705) or higher. For MGWs compliant with MGCP0.1 only, the timeout is not variable.


Certain limitations apply to the use of the warmline feature:

An exclusive telephone DN is required for the warmline feature.

None of the VSC star (*) features are available on this line

Only the service provider can deactivate warmline service


Tip To provision this feature, see the Warmline provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Office Service ID and Default Office Service ID

One service ID (the office service ID) is reserved for provisioning of POP-based features. These office-based features can include certain network features and certain usage-sensitive features, as described below. The service provider provisions the individual features, enters a unique ID in the service table, and provisions this service ID in the POP table. All of the subscribers within the POP are provided with this service (and this set of features).

One service ID (the default office service ID) is reserved for provisioning of switch-based features. The service provider provisions the individual features, enters a unique ID in the service table, and provisions this service ID in the CA-Config table. All of the subscribers on the switch are provided with this service (and this set of features).


Note If the office-service-id is provisioned in the POP table, the system uses this value.
However, if the office-service-id is not provisioned in the POP table, the system uses the default-office-service-id provisioned in the CA-Config table.



Caution The system does not validate or restrict the provisioning of features on the office service ID. However, entries other than the ones listed below will have undefined results. Do not enter features other than the ones listed below.

The following features can be provisioned with the office-service-id (POP table) and the default-office-service-id (CA-Config table):

USTWC (For three-way-calling, note that USTWC is the feature that can be included in the office service ID, and TWC is the feature that can be assigned to individual subscribers.)

COT

AR_ACT (or AR, if umbrella feature was created)

AR_DEACT (not needed if umbrella feature AR was created)

AC_ACT (or AC, if umbrella feature was created)

AC_DEACT (not needed if umbrella feature AC was created)

8XX

LNP

911

BLV

REFER—Valid for SIP subscribers only

REPLACES—Valid for SIP subscribers only


Tip To provision the office service ID, see the Office Service ID provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.


Notes on Bundling Features in Services

The service provider can bundle features and services as follows:

Associated features can be bundled with their primary feature (for example, the call waiting deluxe (CWD) associated features CWD activation, CWD deactivation, and CWD interrogation, can all be bundled with the CWD feature)

Groups of features can be bundled into service packages (services)

Provisioning procedures for features and services are presented in the Cisco BTS 10200 Softswitch Provisioning Guide.