System Description Release 4.4
Ch04-Subscriber Features

Table Of Contents

Subscriber Features

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

Special CFU-Related Functions

Call Forwarding Variable for Basic Business Group (CFVBBG)

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

Call Forwarding No Answer (CFNA)

CFNA Variable Activation (CFNAVA)

CFNA Variable Deactivation (CFNAVD)

CFNA Interrogation (CFNAI)

CFNA Invocation

Invalid User Actions

CFNA Feature Interactions

Call Waiting Features

Limitations

Call Waiting (CW)

CW Activation

CW Deactivation

CW Feature Interactions

Cancel Call Waiting (CCW)

Calling Identity Delivery on Call Waiting (CIDCW)

CIDCW Activation

CIDCW Deactivation

CIDCW Feature Interactions

Call Waiting Deluxe (CWD)

CWD Timers

CWD Activation

CWD Deactivation

CWD Interrogation

CWD Invocation

Invalid User Actions

CWD Feature Interactions

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

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

Direct Inward/Outward Dialing for PBX

Analog DID for PBX

DOD For PBX

Features for Centrex Subscribers Only

Call Hold (CHD)

Call Park and Call Retrieve

Direct Inward/Outward Dialing for Centrex

DID for Centrex with Distinctive Ringing

DOD 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

Call Block (Reject Caller)

Call Transfer (CT)

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

Interactive Voice Response (IVR) Functions

Multiline Hunt Group (MLHG)

Hunting Sequence

Preferential Hunt Lists

MLHG Provisioning Options and Use Cases

Billing for MLHG

Basic Provisioning Procedure and CLI Reference

Multiple Directory Numbers (MDN)

Speed Call

Speed Call for Individual Subscribers

Group Speed Call

Subscriber-Controlled Services and Screening List Editing

Selective Call Forwarding (SCF)

Selective Call Acceptance (SCA)

Selective Call Rejection (SCR)

Distinctive Ringing/Call Waiting (DRCW)

Three-Way Calling (TWC)

Limitations

Feature Description

TWC Feature Interactions

Three-Way Calling Deluxe (TWCD)

TWCD Timers

Invalid User Actions

TWCD Feature Interactions

Usage-Sensitive Three-Way Calling (USTWC)

Limitations

Feature Description

Visual Message Waiting Indicator (VMWI)

Warmline Service

Default Office Service ID

Notes on Bundling Features in Services


Subscriber Features


Revised: March 19, 2007, OL-5906-14

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, Cisco BTS 10200 Softswitch 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:

Default Office Service ID

Notes on Bundling Features in Services


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


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 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 Cisco BTS 10200 Softswitch. (These values are listed in the Vertical Service Code appendix of the Cisco BTS 10200 Softswitch Command Line Interface Reference 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 the appendix of the Cisco BTS 10200 Softswitch Provisioning Guide.

Subscriber Feature List

Table 4-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 4-1 Subscriber Features 

Feature Description
Industry Reference Document
Subscriber Category

Call Forwarding Unconditional (CFU)

Special CFU-Related Functions

Call Forwarding Variable for Basic Business Group (CFVBBG)

Remote Activation of Call Forwarding (RACF)

Remote Call Forwarding (RCF)

FSD 01-02-1401
GR-580


FSD 01-02-1450
GR-586


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 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

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)

 

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

Multiline Hunt Group (MLHG)

FSD 01-02-0802
TR-TSY-000569

Centrex

POTS

Multiple Directory Numbers (MDN)

 

POTS only

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

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

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

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)

Special CFU-Related Functions


Note The Special CFU-Related Functions section includes information on Call Forwarding Variable for Basic Business Group (CFVBBG), Remote Activation of Call Forwarding (RACF), and Remote Call Forwarding (RCF).


Call Forwarding Busy (CFB)

Call Forwarding No Answer (CFNA)

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 4-2.

Table 4-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 hopping 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

CFU Activation (CFUA)

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

CFUA Customization Options

The behavior of CFU activation 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 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.


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.


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. If the SDT flag is set to Y, the system provides a second dial tone. If SDT is set to N, the system does not provide a second dial tone.


Note For SIP phone subscribers, this dial tone will not be provided, even if the SDT flag is set.


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 the FDT flag is set to Y, the system provides a confirmation tone for one second, followed by a dial tone. If FDT is set to N, the system provides a success announcement.


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.)

Example—Using the Customization Options

The typical North America and China variants of the CFUA flags can be provided by configuring the options as follows:

China—CC=N; SDT=N; FDT=N

North America—CC=ANS; SDT=Y; FDT=Y

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 a stutter 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 a 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 a 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 a stutter 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 a 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 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 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, Maintenance, and Troubleshooting 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—COS takes precedence over CFU activation (CFUA and CFVABBG) and CFU invocation (CFU and CFVBBG). 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.

Special CFU-Related Functions

The Cisco BTS 10200 Softswitch supports the following special CFU-related functions:

Call Forwarding Variable for Basic Business Group (CFVBBG)—This feature is a special variant of CFU available only to BBGs with Centrex service. CFVBBG implements the following courtesy call treatment during activation:

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

When CFVBBG is activated to an outside line, a courtesy call is placed.

Remote Activation of Call Forwarding (RACF)—This feature allows the user to access an interactive voice response (IVR) system to activate CFU from a remote station.

Remote Call Forwarding (RCF)—This feature is set up by the service provider at customer request. It allows all incoming calls to a specified DN to be forwarded automatically to a forward-to DN. It is not controlled by the user with a handset.

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. 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, Maintenance, and Troubleshooting 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.

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.

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 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.

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 usually set up by the service provider at the subscriber's request.

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


Note When endpoint monitoring is disabled and the eMTA powered down, calls to subscribers on that eMTA are not forwarded to voicemail. Those calls are released with a release cause of 41 (Temporary Failure). If endpoint monitoring is enabled, call forwarding to voicemail works as expected. (This note does not apply to SIP subscribers; for SIP subscribers, calls can be forwarded when the SIP endpoint is unreachable or unregistered.)


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 4-3.

Table 4-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 hopping 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

CFB Variable Activation (CFBVA)

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

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. If the SDT flag is set to Y, the system provides a second dial tone. If SDT is set to N, the system does not provide a second dial tone.


Note For SIP phone subscribers, this dial tone will not be provided, even if the SDT flag is set.


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 the FDT flag is set to Y, the system provides a confirmation tone for one second, followed by a dial tone. If FDT is set to N, the system provides a success announcement.


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.)

Example—Using the Customization Options

The typical North America and China variants of the CFBVA flags can be provided by configuring the options as follows:

China—CC=N; SDT=N; FDT=N

North America—CC=N; SDT=Y; FDT=Y

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 a stutter 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 a 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 a 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 a stutter 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 a 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 Feature Server (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 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, Maintenance, and Troubleshooting 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, Maintenance, and Troubleshooting 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—COS takes precedence over CFB activation (CFBVA) and CFB invocation (CFB). If a call to a DN is restricted by COS screening, CFB cannot be activated or invoked to that DN.

Call Forwarding No Answer (CFNA)

The Cisco BTS 10200 Softswitch 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 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.


Note 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 4-4.

Table 4-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 hopping 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

CFNA Variable Activation (CFNAVA)

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

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. If the SDT flag is set to Y, the system provides a second dial tone. If SDT is set to N, the system does not provide a second dial tone.


Note For SIP phone subscribers, this dial tone will not be provided, even if SDT flag is set.


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 the FDT flag is set to Y, the system provides a confirmation tone for 1 second, followed by a dial tone. If FDT is set to N, the system provides a success announcement.


Note For SIP phone subscribers, only the success announcements will be provided. The confirmation tone and dial tone will not be provided, even if 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.)

Example—Using the Customization Options

The typical North America and China variants of the CFNAVA flags can be provided by configuring the options as follows:

China—CC=N; SDT=N; FDT=N

North America—CC=N; SDT=Y; FDT=Y

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 a stutter 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 a 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 a 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 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 a 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 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 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, Maintenance, and Troubleshooting 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.

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.

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 CFNA active simultaneously, the service provider should not assign the CHD feature to that subscriber.

COS—COS takes precedence over CFNA activation (CFNAVA) and CFNA invocation (CFNA). If a call to a DN is restricted by COS screening, CFNA cannot be activated or invoked to that DN.

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. The CW (or CWD) feature does not perform any timing in this case. 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.

CW—If both CFNA and CW 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 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.

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 Cisco BTS 10200 Softswitch 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 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 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.

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.

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 CFNA active simultaneously, the service provider should not assign the CHD feature to that subscriber.

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 If a user was involved in a multiparty call, and received a ringback after going on hook, CCW remains active for the call.



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.


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.

Calling Identity Delivery on Call Waiting (CIDCW)

The Cisco BTS 10200 Softswitch 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.

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 CFNA active simultaneously, the service provider should not assign the CHD feature to that subscriber.

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.

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 Cisco BTS 10200 Softswitch 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.

Calling Name Delivery (CNAM)

The Cisco BTS 10200 Softswitch 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.

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.

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 (Cisco BTS 10200 Softswitch) 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 (Cisco BTS 10200 Softswitch) 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 4-5 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 4-5 and throughout this section are typical values. The service provider can provision these values with any unique ASCII string up to five characters long. For a complete list of preprovisioned VSCs, see the VSC appendix in the Cisco BTS 10200 Softswitch CLI Reference Guide.


Table 4-5 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.


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.


Calling Identity Delivery and Suppression (CIDSD and CIDSS)

The Cisco BTS 10200 Softswitch 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.

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 4-6 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 4-6 and throughout this section are typical values. The service provider can provision these values with any unique ASCII string up to five characters long. For a complete list of preprovisioned VSCs, see the VSC appendix in the Cisco BTS 10200 Softswitch CLI Reference Guide.


Table 4-6 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.


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.

Calling Identity Delivery and Suppression (CIDSD and CIDSS)

The Cisco BTS 10200 Softswitch 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.

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.

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 4-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 4-1 Example of PBX Analog DID One-Way Application

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.

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.

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.


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.

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.

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 CFNA active simultaneously, the service provider should not assign the CHD feature to that subscriber.

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.

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 hears either music-on-hold or silence. 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.

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 ringing for DID

DOD

DID for Centrex with Distinctive Ringing

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.

The Cisco BTS 10200 Softswitch supports distinctive ringing for DID. The service provider can provision the distinctive ringing feature for Centrex customers. When enabled (da-cwi=yes in the centrex-grp table), the customers within the Centrex group will be able to 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)

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 Incoming calls originating from a different Centrex are treated as outside calls.


DOD for Centrex

The Cisco BTS 10200 Softswitch supports the DOD feature. 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)


Note This feature is available only to 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

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.

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)

Call Transfer (CT)

Customer-Originated Trace (COT)

Do Not Disturb (DND)

Hotline Service

Hotline-Variable Service (HOTV)

Interactive Voice Response (IVR) Functions

Multiline Hunt Group (MLHG)

Multiple Directory Numbers (MDN)

Speed Call

Subscriber-Controlled Services and Screening List Editing

Selective Call Forwarding (SCF)

Selective Call Acceptance (SCA)

Selective Call Rejection (SCR)

Distinctive Ringing/Call Waiting (DRCW)

Three-Way Calling (TWC)

Three-Way Calling Deluxe (TWCD)

Visual Message Waiting Indicator (VMWI)

Warmline Service

Anonymous Call Rejection (ACR)

The Cisco BTS 10200 Softswitch 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 offhook.

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.


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.

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.

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.

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.

Call Block (Reject Caller)

The call block (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.


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, 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.

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.


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 Cisco BTS 10200 Softswitch for retrieval purposes. A maximum of 10,000 traces are stored in a circular file format (oldest record overwritten).

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.

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:

None of the VSC star (*) features are available on this line

The user cannot originate additional outgoing calls by pressing the Flash button or hookswitch. Therefore, the user will not be able to originate multiparty or conference calls from the hotline phone.

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.


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 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.

Certain limitations apply to hotline calls:

None of the VSC star (*) features are available on this line, other than the VSC codes for hotline-variable activation, deactivation, and interrogation.

The user cannot originate additional outgoing calls by pressing the Flash button or hookswitch. Therefore, the user will not be able to originate multiparty or conference calls from the hotline phone.

This remote DN is referred to as the B-number. The allowed types of B-numbers are listed in Table 4-7.

Table 4-7 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.

Interactive Voice Response (IVR) Functions

The Cisco BTS 10200 Softswitch supports interactive voice response (IVR) functions for activation of remote call forwarding (RACF) and screening list editing (SLE) features. To use the RACF feature, the user dials a specified DN (assigned by the service provider) and is connected to the appropriate IVR media server. The user enters a personal ID number (PIN) to access the IVR functions, and follows the voice prompts of the IVR server to activate/deactivate or edit their RACF options. To use the SLE feature, the user dials one of several VSC (*xx) numbers and is connected to the appropriate IVR media server. The user follows the voice prompts to edit their screening lists.

For additional details of these features, refer to the following sections:

Remote Activation of Call Forwarding (RACF)

Subscriber-Controlled Services and Screening List Editing

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 4-2 illustrates this process.

Figure 4-2 Searching an MLHG—Incoming Call to the Pilot DN (Example)

Notes for Figure 4-2

A rectangle surrounding a number means the line is busy.

Regular hunt and circular hunt—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 4-3 illustrates this process.

Figure 4-3 Searching an MLHG—Incoming Call to an Individual Terminal (Example)

Notes for Figure 4-3

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.

Special case for UCD (not shown in the drawing)—If the dialed DN is idle and receives the call, the system checks whether this terminal already has the NFT pointer. If so, the system performs a hunt for the next idle terminal and assigns the NFT to that idle terminal.

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 4-4.


Note The system does not invoke the preference list (preferential hunt) if hunt-type=UCD in the MLHG table.


Figure 4-4 Searching a Preferential Hunt List (Example)

MLHG Provisioning Options and Use Cases

Table 4-8 explains how provisioning in the Subscriber table affects the behavior of a terminal in the MLHG.

Table 4-8 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 subscriber::category 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.

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.

Call forwarding—If call forwarding busy (CFB) is assigned and active for the main subscriber, and if all terminals in the MLHG are busy, an incoming call to the pilot number receives CFB treatment. However, if the incoming call is to an individual DN, and that DN is busy, the treatment depends on the provisioning for that individual subscriber record:

If the individual subscriber record has grp=Y, and the main subscriber has CFB assigned and active, the call receives CFB treatment. (The individual subscriber inherits the CFB feature from the main subscriber.)

If the individual subscriber has grp=N, but has CFB assigned as an individual feature, the call receives CFB treatment as provisioned for the individual.

If CFB is not assigned to this subscriber, either by inheritance or by individual assignment, the incoming call receives busy treatment without forwarding.

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).

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.

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 "Multiline Hunt Group" chapter of the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.

Multiple Directory Numbers (MDN)

Multiple directory numbers (MDN) service is also known as teen service. It enables one primary DN and one or two 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.


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 offhook 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.

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.

Subscriber-Controlled Services and Screening List Editing

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)

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. The user performs the SLE functions, and activates/deactivates the services, via VSCs. Each VSC connects the user to the appropriate 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 following sections.

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.

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)" 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 SCR 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.


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.

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.

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.

Visual Message Waiting Indicator (VMWI)

The visual message waiting indicator (VMWI) is associated with the voice mail service. When a call is forwarded to a voice mail system, and the caller leaves a message, the voice mail system sends the Cisco BTS 10200 Softswitch an MWI signal via SIP. The Cisco BTS 10200 Softswitch forwards a VMWI signal to the called party, and the called party's telephone indicator light turns on. When the called party retrieves the message, the voice mail system signals the Cisco BTS 10200 Softswitch to clear the VMWI indicator, and the light on the telephone turns off.

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.


An exclusive telephone DN is required for the warmline feature, and certain limitations apply to its use:

None of the VSC star (*) features are available on this line

The user cannot originate additional outgoing calls by pressing the Flash button or hookswitch. Therefore, the user will not be able to originate multiparty or conference calls from the warmline phone.

Only the service provider can deactivate warmline service

Default Office Service ID

One service ID (the default office service ID) is reserved for provisioning of switch-based features. These switch-based features can include certain network features and certain usage-sensitive features, as described below. The service provider enters a unique ID (DEFAULT-OFFICE-SERVICE-ID) in the CA-CONFIG table, provisions this service ID in the SERVICE table, and defines these features in the FEATURE table.


Note Refer to the Cisco BTS 10200 Softswitch Provisioning Guide for specific feature provisioning requirements.



Caution The system does not validate or restrict the provisioning of features on this 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.

Network features—When provisioned, the system makes these features available for all subscriber lines:


Note See "Network Features" for details of these network features.


Local network portability (LNP)

Toll-free services (8XX)

Emergency services (911)

Busy line verification (BLV)

Usage-sensitive features—When provisioned, the system makes these features available to all subscribers without the need to actually subscribe these features to individual lines:


Note These features can also be assigned to individual subscribers using other service IDs.


Usage-sensitive three-way calling (USTWC)

Customer originated trace (COT)

Automatic callback activation and deactivation—AC_ACT and AC_DEACT (or AC, if the AC umbrella feature was created)

Automatic recall activation and deactivation—AR_ACT and AR_DEACT) (or AR, if the AR umbrella feature was created)

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.