Table Of Contents
Subscriber Features
Introduction
Interoperability
Subscriber Feature List
Call Forwarding Features
Call Forwarding Unconditional (CFU)
CFU Activation (CFUA)
CFU Deactivation (CFUD)
CFU Interrogation (CFUI)
CFU Invocation
Invalid User Actions
CFU Feature Interactions
Feature Provisioning Commands
Call Forwarding Variable for Basic Business Group (CFVBBG)
CFVBBG Description
CFVBBG Activation—CFVABBG
Feature Provisioning Commands
Remote Activation of Call Forwarding (RACF)
Remote Call Forwarding (RCF)
Call Forwarding Busy (CFB)
CFB Variable Activation (CFBVA)
CFB Variable Deactivation (CFBVD)
CFB Interrogation (CFBI)
CFB Invocation
Invalid User Actions
CFB Feature Interactions
Feature Provisioning Commands
Call Forwarding No Answer (CFNA)
CFNA Variable Activation (CFNAVA)
CFNA Variable Deactivation (CFNAVD)
CFNA Interrogation (CFNAI)
CFNA Invocation
Invalid User Actions
CFNA Feature Interactions
Feature Provisioning Commands
Call Forwarding Combination (CFC)
Vertical Service Codes for CFC
Blocking Call Forwarding to Certain Types of DNs
Detailed Feature Description
CFC Activation (CFC_ACT)
CFC Deactivation (CFC_DEACT)
CFC Activation with Directory Number Change (CFC_DN_CHG_ACT)
CFC Interrogation with No Directory Number Verification (CFCI_NO_DN_VRFY)
CFC Interrogation (CFCI)
CFC Invocation (CFC)
Flags Applicable to CFC Activation and Deactivation Subfeatures
Invalid User Actions
CFC Feature Interactions
Feature Provisioning Commands
Call Waiting Features
Limitations
Call Waiting (CW)
CW Activation
CW Deactivation
CW Feature Interactions
Feature Provisioning Commands
Cancel Call Waiting (CCW)
Calling Identity Delivery on Call Waiting (CIDCW)
CIDCW Activation
CIDCW Deactivation
CIDCW Feature Interactions
Feature Provisioning Commands
Call Waiting Deluxe (CWD)
CWD Timers
CWD Activation
CWD Deactivation
CWD Interrogation
CWD Invocation
Invalid User Actions
CWD Feature Interactions
Feature Provisioning Commands
Calling Identity Features
Calling Identity Delivery
Calling Number Delivery (CND)
Calling Name Delivery (CNAM)
Calling Line Identification Presentation (CLIP)
CLIP Feature Description
CLIP Feature Activation and Deactivation
CLIP Feature Interactions
Feature Provisioning Commands
Calling Identity Delivery Blocking (CIDB)
Calling Number Delivery Blocking (CNDB)
Calling Name Delivery Blocking (CNAB)
Calling Identity Delivery and Suppression (CIDSD and CIDSS)
Calling Line Identification Restriction (CLIR)
Calling Identity Presentation Status
Calling Number Delivery Blocking (CNDB)
Calling Name Delivery Blocking (CNAB)
Calling Identity Delivery and Suppression (CIDSD and CIDSS)
CLIR Feature Interactions
Feature Provisioning Commands
Direct Inward/Outward Dialing for PBX
Analog DID for PBX
DOD For PBX
Hostage Negotiation
Multiline Hunt Group (MLHG)
Hunting Sequence
Incoming Call to the Pilot DN
Incoming Call to an Individual DN
Preferential Hunt Lists
Assigning and Activating MLHG Features
MLHG Provisioning Options and Use Cases
Terminal Make Busy and Group Make Busy Features
Special Hunting Treatment for SIP Subscribers
Treatment of Outbound Call Features
Treatment of Inbound Call Features
Billing for MLHG
Basic Provisioning Procedure and CLI Reference
Features for Centrex Subscribers Only
Call Hold (CHD)
Description
Feature Interactions with CHD
Feature Provisioning
Call Park and Call Retrieve
Direct Inward/Outward Dialing for Centrex
Directed Call Pickup (With and Without Barge-In)
Distinctive Alerting/Call Waiting Indication (DA/CWI)
MultiLine Variety Package
Additional Features Applicable to Centrex and POTS
Anonymous Call Rejection (ACR)
Automatic Callback (AC)—Repeat Dialing
Automatic Recall (AR)—Call Return
One-Level Activation of AR
Two-Level Activation of AR
Feature Provisioning Commands
Call Block - Reject Caller (CBLK)
Block All Inbound Calls
Call Transfer (CT)
Feature Provisioning Commands
SIP Call Transfer with REFER and SIP Invite with REPLACES
Change Number (CN)
Customer-Originated Trace (COT)
Do Not Disturb (DND)
Hotline Service
Hotline-Variable Service (HOTV)
Hotline-Variable Feature Description
Hotline-Variable Activation
Hotline-Variable Deactivation
Hotline-Variable Interrogation
Hotline-Variable Invocation
Invalid User Actions
HOTV Feature Interactions
Feature Provisioning Commands
Interactive Voice Response (IVR) Functions
Limited Call Duration Service (Prepaid/Postpaid) with RADIUS Interface to AAA
Network Interfaces
Feature Description
Provisionable Parameters
Feature Interactions
Prerequisites
Restrictions and Limitations
Feature Provisioning Commands
Message Waiting Indicator (MWI)—Audible and Visual
Multiple Directory Numbers (MDN)
No Solicitation Announcement (NSA)
References
NSA Activation, Management, and Control
NSA Invocation
Feature Interactions
Prerequisites
Feature Provisioning Commands
Own Calling Number Announcement (OCNA)
Privacy Screening (Calling Identity with Enhanced Screening)
Privacy Screening Description
Privacy Screening Invocation
Privacy Screening Subscriber Management
Feature Interactions
Feature Provisioning Commands
Seasonal Suspend
Allowed and Disabled Features for Outbound Calls
Treatment of Outbound Calls
Treatment of Inbound Calls
Deactivation of Seasonal Suspend
Feature Interactions
Prerequisites
Limitations
Provisioning Procedure
Speed Call
Speed Call for Individual Subscribers
Group Speed Call
Subscriber-Controlled Services and Screening List Editing (SLE)
Subscriber Access
Selective Call Forwarding (SCF)
Selective Call Acceptance (SCA)
Selective Call Rejection (SCR)
Distinctive Ringing/Call Waiting (DRCW)
10/11-Digit Screening for SLE Features
CORBA Interface
Temporarily Disconnected Subscriber Status and Soft Dial Tone
Provisioning Options and System Behavior
Feature Interactions
Restrictions and Limitations
Feature Provisioning Commands
Three-Way Calling (TWC)
Limitations
Feature Description
TWC Feature Interactions
Feature Provisioning Commands
Three-Way Calling Deluxe (TWCD)
To Begin a Three-Way Call:
Options While on a Three-Way Call with All Three Parties Bridged Together:
TWCD Timers
Invalid User Actions
TWCD Feature Interactions
Feature Provisioning Commands
Usage-Sensitive Three-Way Calling (USTWC)
Limitations
Feature Description
Feature Provisioning Commands
Visual Message Waiting Indicator (VMWI)
Voice Mail (VM) and Voice Mail Always (VMA)
VM Activation, Deactivation, and Invocation
VMA Activation, Deactivation, and Invocation
VM Access
Provisionable Parameters for VM and VMA
Feature Interactions
Warmline Service
Office Service ID and Default Office Service ID
Notes on Bundling Features in Services
Subscriber Features
Revised: July 2, 2009, OL-15337-07
Introduction
The Cisco BTS 10200 Softswitch supports subscriber features, including selected custom local area signaling service (CLASS) features, as described in the following sections. Most of these features are defined in Telcordia LSSGR documents or in corresponding ITU-T documents. In most cases, The BTS 10200 features delivered via gateway clients behave identically to their PSTN counterparts. These features are described in the following sections:
•
Call Forwarding Features
•Call Waiting Features
•Calling Identity Features
•Direct Inward/Outward Dialing for PBX
•Hostage Negotiation
•Multiline Hunt Group (MLHG)
•Features for Centrex Subscribers Only
•Additional Features Applicable to Centrex and POTS
Additional general information is provided in the following sections:
•Office Service ID and Default Office Service ID
•Notes on Bundling Features in Services
Note For network features, see Chapter 1, "Network Features."
For lawful intercept and CALEA, see Chapter 2, "Lawful Intercept and Enhanced CALEA Features."
For outgoing call restrictions see Chapter 4, "Class of Service Restrictions and Outgoing Call Barring Features."
Some features can be accessed and controlled by the subscriber using a handset and vertical service codes (VSCs). VSCs are provisionable by the service provider (any valid unique ASCII string up to five characters long), and the customary values are country specific. The VSC values used throughout this chapter are for illustration purposes. For convenience, some VSC values are preprovisioned in the BTS 10200. The valid formats for VSC ASCII strings are listed in the Vertical Service Code commands in the Cisco BTS 10200 Softswitch CLI Database. To view the current VSC values provisioned on your system, use the show vsc CLI command. To provision VSCs, see the VSC provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Typically, the system responds to user handset actions by providing an appropriate announcement. However, if an announcement is not provisioned or cannot be played, an appropriate tone (confirmation tone or reorder tone) is played. A list of these announcements and tones is provided in Chapter 8, "Cause Codes and Announcement IDs" in the Cisco BTS 10200 Softswitch Provisioning Guide.
Tip For information on provisioning these features, see the Feature Provisioning chapter in the
Cisco BTS 10200 Softswitch Provisioning Guide.
Interoperability
The BTS 10200 interworks with a wide range of network elements (NEs), but there are certain limitations. Cisco recommends that you keep the following caution in mind as you prepare to purchase and use NEs for your network.
Caution Some features involve the use of other network elements (NEs) deployed in the service provider network, for example, gateways, media servers, announcement servers, eMTAs, and SIP phones. See the
"Component Interoperability" section of the
Release Notes for a complete list of the specific peripheral platforms, functions, and software loads that have been used in system testing for interoperability with the BTS 10200 Release 6.0.x software. Earlier or later releases of platform software might be interoperable and it might be possible to use other functions on these platforms. The list in the
Release Notes certifies only that the required interoperation of these platforms, the functions listed, and the protocols listed have been successfully tested with the BTS 10200.
Subscriber Feature List
Table 3-1 lists the subscriber features that are described in this chapter, an industry reference document (if applicable), and the category of subscriber for which this service is available.
Call Forwarding Features
Call forwarding is a group of features allowing incoming calls to a subscriber line to be forwarded to another telephone number, including a cellular phone number, under various circumstances. Call forwarding features allow a subscriber line to be forwarded to a number that itself can be forwarded. This chaining of call forwards is allowed to a maximum of five different stations as long as none of the station numbers appears twice in the forwarding list (in order to prevent loops). Before forwarding a call outside of a zone or off net, the system must determine if the forwarding station already has an active call that has been forwarded to the same destination. If so, forwarding is denied to the second call and a station busy signal is returned to the caller.
The following types of call forwarding features are provided by the Cisco BTS 10200 Softswitch:
•Call Forwarding Unconditional (CFU)
•Call Forwarding Variable for Basic Business Group (CFVBBG)
•Remote Activation of Call Forwarding (RACF)
•Remote Call Forwarding (RCF).
•Call Forwarding Busy (CFB)
•Call Forwarding No Answer (CFNA)
•Call Forwarding Combination (CFC)
•Call Forwarding Redirection (CFR)—This is a SIP-specific feature. With CFR, the SIP endpoint initiates the call forwarding. For a description and provisioning commands, see the "Sending 302 on Call Redirection" section in the Cisco BTS 10200 Softswitch SIP Guide.
Call Forwarding Unconditional (CFU)
The Cisco BTS 10200 Softswitch provides the call forwarding unconditional (CFU) feature. CFU allows the user to forward all calls regardless of the status of the user's line. A typical forwarding address is voice mail, a remote telephone, or an attendant.
Reference documents include:
•LSSGR module FSD 01-02-1401 (GR-580), Call Forwarding Variable
•LSSGR module FSD 01-02-1450 (GR-586), Call Forwarding Subfeatures
•ITU-T Q-732.2
•ITU I-252.4
The service provider can provision the CFU feature to be active immediately on the customer line, or to be activated by the individual subscriber using the handset. The user activates the CFU feature on the local phone, and enters the forward-to phone number where the user wishes to have the calls forwarded. This forward-to directory number (DN) is referred to as the B-number. The allowed types of B-numbers are listed in Table 3-2.
Table 3-2 Allowed Types of B-numbers
Subscriber Type
|
Allowed B-number
|
POTS
|
DN, without extensions
|
Centrex
|
Public access code + external DN, without extensions
|
An extension within the business group
|
The following conditions apply to the CFU feature:
•The CFU feature can be provided to POTS, Centrex, and MLHG subscribers.
•The CFU feature is in the deactivated mode unless activated by the service provider or subscriber.
•Call forwarding hop scenarios are restricted to a maximum of five hops. The call will be completed on the provisioned maximum number of hops.
The CFU feature is composed of four associated features, which are described in the following sections:
•CFU Activation (CFUA)
•CFU Deactivation (CFUD)
•CFU Interrogation (CFUI)
•CFU Invocation
Additional information about this feature is covered in the following sections:
•Invalid User Actions
•CFU Feature Interactions
•Feature Provisioning Commands
CFU Activation (CFUA)
This section discusses how the service provider can customize CFU activation, and the CFU activation procedures available to the handset user.
Blocking Call Forwarding to Certain Types of DNs
The service provider can block call forwarding to certain types of DNs by provisioning the nature of dial (NOD) parameter for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD Restrict List (nod-restrict-list) table. For example, if you provision NOD=TOLL-FREE and NOD=EMG in the nod-restrict-list table, the system will not allow call-forwarding to DNs of those types.
Caution If you want to block call-forwarding to an emergency (EMG) DN, such as 911, you must provision NOD=EMG for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD-RESTRICT-LIST. This is necessary to comply with the rule in Telcordia document GR-580, which says that 911 should not be a permitted "forward to" number.
Tip To provision the CFU feature, see the CFU provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
CFUA Customization Options
The behavior of CFU activation can be customized using the following provisionable options.
•Courtesy call (CC)—The CC flag controls the delivery of a courtesy call while activating CFU.
–A value of N indicates that no courtesy call will be placed.
–A value of ANS or NOANS indicates that a courtesy call will be placed. ANS means that the courtesy call will have to be answered for CFU to be activated. NOANS means that the courtesy call does not have to be answered for CFU to be activated.
•Second stage dial tone (SDT)—The SDT flag controls the delivery of a dial tone after the subscriber enters the vertical service code (VSC) for activation or interrogation of CFU. The permitted values for this flag are:
–NO_TONE
–DIAL_TONE
–STUTTER_DIAL_TONE
–CONFIRMATION_TONE
–CONFIRMATION_DIAL_TONE
Note For SIP phone subscribers, the SDT parameter has no effect. The SDT option is available through the dial plan in the SIP phone.
•Final stage dial tone (FDT)—The FDT flag controls the system response to a successful activation, deactivation, or interrogation of CFU by the subscriber. If FDT is not provisioned, the system provides a success announcement. The permitted values for this flag are the same as for the SDT flag.
Note For SIP phone subscribers, only the success announcements will be provided. The confirmation tone and dial tone will not be provided, even if the FDT flag is set.
•Reminder ring (RR)—When RR is provisioned as Y, a subscriber who has an idle station with CFU activated, receives a reminder ring when incoming calls are forwarded. If the subscriber goes off-hook after hearing the RR, the system ignores the off-hook condition, and does not complete the call to this station; the call is forwarded to the DN provisioned for CFU. A reminder ring is a half-second burst of ringing. The reminder ring is not applied when the forwarding station is off hook.
•Multiple call forwarding (MCF)—When MCF is provisioned as Y, the system allows multiple incoming calls to be forwarded by the subscriber at the same time. If a subscriber already has CFU invoked, additional calls to the subscriber will be forwarded by CFU based on the MCF flag. If the MCF flag is set to N, the system allows only one CFU invocation.
•International call forwarding (INTL)—When the INTL flag is set to N, the system does not allow forwarding to an international number. When INTL is set to Y, the system checks for other restrictions on international calls, and allows forwarding if there are no other restrictions provisioned for the call type and calling number. (Other provisionable restrictions on international calling can be based on the nature of dial [NOD] and the subscriber feature data.)
For detailed information on how to set these parameters, see the following sources:
•To view a list of these feature options for CFU, use the show feature-profile-base fname=cfu% CLI command.
•To view the possible values for each of these feature options, see the Cisco BTS 10200 Softswitch CLI Database. Pull down the Feature Matrix [By Table] menu option, then display the FEATURE_PROFILE list.
•To provision the CFU feature, see the CFU provisioning procedure in the
Cisco BTS 10200 Softswitch Provisioning Guide.
CFUA Handset Procedures
CFU can be activated by the service provider or by the individual user. The procedures are as follows:
•CFU can be activated permanently at subscription time by the service provider. The service provider provisions the forward-to DN as requested by the subscriber. All calls made to the subscriber's line will be forwarded to the single forward-to number that was provisioned.
•CFU can be activated by the user as follows.
Note See the "CFUA Customization Options" section for details of customized features CC, SDT, and FDT.
–The user lifts the handset and listens for dial tone.
–The user presses the VSC applicable to CFU activation (for example, typically *72 in North America and *57* in China). The VSC values are provisionable by the service provider.
–If provisioned for SDT, and if CFU can be activated, the system returns the provisioned dial tone.
–The user enters the B-number (local, long distance, or international) where calls are to be forwarded.
–The user receives an appropriate error announcement if the forward-to number is invalid or restricted, or if the feature cannot be activated.
–If the feature can be activated to the forward-to number entered, the system returns a confirmation tone and attempts to place a courtesy call to the forward-to number (if provisioned for CC).
–If the forwarded-to party answers the courtesy call (when CC is provisioned as ANS), or if CC is provisioned as NOANS, the CFU feature is activated.
Note When CC is provisioned for ANS, and if the forwarded-to line is busy or does not answer, the CFU feature is not activated. The user can still activate CFU by repeating the activation procedure within 2 minutes of the first attempt. No courtesy call is set up during the second attempt. The user hears a confirmation tone. If more than 2 minutes elapse before the second attempt, the second attempt is treated as a first attempt.
–If FDT is provisioned, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone, indicating that activation was successful. If FDT is not provisioned, the user hears a success announcement.
Note FDT and CC are mutually exclusive—The system never provides FDT if a courtesy call is placed during the activation attempt (whether or not the courtesy call is answered). FDT is only provided, if provisioned, when a courtesy call is not involved.
–CFU is now activated, and will stay active until it is deactivated with the appropriate deactivation VSC, or is overridden by the service provider via a CLI command.
CFU Deactivation (CFUD)
CFU can be deactivated by the service provider via a CLI command. Alternatively, CFU can be deactivated by the individual user as follows:
Note See the "CFUA Customization Options" section for details of the customized feature FDT.
•The user lifts the handset and listens for dial tone.
•The user presses the VSC applicable to CFU deactivation (for example, typically *73 in North America and #57# in China). The VSC values are provisionable by the service provider.
•The user receives an appropriate error announcement if the feature cannot be deactivated.
•If deactivation was successful, and if FDT is provisioned, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone. If FDT is not provisioned, the user hears a success announcement.
•CFU is now deactivated, and will stay deactivated until it is activated with the appropriate activation VSC, or is overridden by the service provider via a CLI command.
CFU Interrogation (CFUI)
CFU interrogation allows a user to check whether CFU is activated to a particular phone. The user performs an interrogation as follows.
Note See the "CFUA Customization Options" section for details of customized features SDT and FDT.
•The user lifts the handset and listens for dial tone.
•The user presses the VSC applicable to CFU interrogation (for example, typically *#57* in China). The VSC values are provisionable by the service provider.
•If provisioned for SDT, and if CFU can be interrogated, the system returns the provisioned dial tone. If not provisioned for SDT, no tones are provided.
•The user enters the forward-to number to be interrogated (B-number).
Note The user can follow the B-number with a # to indicate the end of B-number entry.
Note If the user enters a digit string that does not match exactly the B-number against which CFU was activated, the interrogation attempt results in an error announcement.
•The user receives an appropriate error announcement if the CFU feature is not forwarded to the B-number entered, or if the B-number is invalid.
•If FDT is provisioned and the CFU feature is activated to the forward-to number entered, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone.
•If FDT is not provisioned and the CFU feature is activated to the forward-to number entered, the system returns a success announcement.
CFU Invocation
CFU invocation is the actual procedure the system follows to forward the call.
Invalid User Actions
The following user actions are invalid, and the system provides an appropriate error announcement:
•The user enters an invalid directory number (DN) for the B-number.
•The user tries to activate CFU (with CC set to ANS) for the second time within a 2-minute interval to a DN which is different from the one used in the first attempt. (In addition, the history associated with the first attempt will be removed.)
•During CFU activation, the user enters a B-number that is determined by the system to be a type blocked by provisioning in the NOD-RESTRICT-LIST table. For example, if the nature of dial (NOD) for the B-number is set to EMG (emergency), but calls with NOD=EMG are blocked by provisioning in the NOD-RESTRICT-LIST table, the activation to that B-number will be denied.
•The user tries to activate CFU from a DN that has outgoing calls blocked by the OCB feature, or the user enters a B-number, but calls to that DN are blocked by OCB. For example, the call from the user's phone to the B-number would be a domestic long-distance call, but these calls are blocked by setting K=2 against the OCB feature in the SUBSCRIBER-FEATURE-DATA table.
Note The database tables (NOD-RESTRICT-LIST and SUBSCRIBER-FEATURE-DATA) mentioned in the above list are described in the Cisco BTS 10200 Softswitch CLI Database. For information on billing records, see the Cisco BTS 10200 Softswitch Billing Guide. For information on measurements, see the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.
•The user tries to activate CFU from or to a DN for which calls are restricted by the COS feature.
•The user tries to activate CFU when already activated (the B-number is not overwritten).
•The user tries to activate CFU to an international DN, but the service provider has blocked forwarding to international DNs. The service provider can block forwarding to international DNs using the international flag in the FEATURE table.
•The user tries to activate CFU to his or her own extension or DN.
•The user tries to deactivate CFU when already deactivated.
•The user interrogates CFU, but enters a digit string that does not match exactly the B-number against which CFU was activated. For example, if CFU was activated with a 5-digit string corresponding to a Centrex extension, and interrogation is attempted using a 10-digit string of the complete DN, the interrogation attempt will result in an error announcement. (See the complete list of standard Cisco BTS 10200 announcements in the Cisco BTS 10200 Softswitch Provisioning Guide.)
•The user tries to interrogate CFU on a fresh system (a system with no entry in the SUBSCRIBER-FEATURE-DATA table). In this case, the user receives the error announcement immediately after entering the interrogation code (for example, *#57*). The system does not wait for the user to enter the B-number
CFU Feature Interactions
This section describes the interaction of other subscriber features with the CFU feature.
•CLIP, CNAM, and CND (caller ID features)—When a call is forwarded, the forwarded-to party receives the DN of the calling party on the caller ID display.
•OCB—The interaction of CFU and OCB depends upon the sequence in which they are activated:
–If OCB is activated prior to CFU activation—OCB screening is performed on each DN the user enters when attempting to activate CFU. Successful CFU activation depends on the existing OCB K-VALUE and the forward-to DN:
Note If the existing OCB K-VALUE is set to block calls to the forward-to DN, then the system does not allow CFU activation. The user receives an error announcement.
Note If the OCB K-VALUE allows calls to this DN, then the CFU activation process continues. Once the CFU activation attempt to a specific DN is accepted by the system, it is applicable permanently regardless of any future OCB K-VALUE changes. That is, future changes to the OCB K-VALUE have no effect on CFU invocation. CFU to this DN can be deactivated by the user in the normal manner (#57#).
–If CFU is activated prior to OCB activation—The user can activate the OCB feature, or change the OCB K-VALUE, regardless of the existing CFU feature. However, invocation of OCB depends upon the type of call:
Note User-dialed calls—User-dialed calls can be blocked by OCB (depending on the K-VALUE).
Note Forwarded calls—CFU remains active as originally set up by the user, therefore, calls forwarded by the CFU feature cannot be blocked using OCB screening.
•COS—If a call to a DN is restricted by COS screening, CFU cannot be activated or invoked to that DN.
•If a subscriber has CFU activated and the operator attempts to use the BLV or OI functions, the operator will receive a busy tone and will not be able to perform an interrupt on the call.
Feature Provisioning Commands
Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.
Tip To provision this feature, see the CFU provisioning procedure in the
Cisco BTS 10200 Softswitch Provisioning Guide.
Call Forwarding Variable for Basic Business Group (CFVBBG)
This section describes the CFVBBG feature and its associated features—CFVABBG, CFUD, and CFUI.
CFVBBG Description
Call Forwarding Variable for Basic Business Group (CFVBBG) is the CFU variant for BBG subscribers with Centrex service. It has the same behavior as CFU, except that it uses CFVABBG as its associated activation feature. Associating CFVABBG causes different treatment of the courtesy call while activating CFVBBG.
Note The other associated features for CFVBBG are CFUD and CFUI. These associated features behave the same as described in the "CFU Deactivation (CFUD)" and "CFU Interrogation (CFUI)" sections.
Note CFUA is not an allowed associated feature for CFVBBG.
The following limitations and behaviors apply to CFVBBG:
•CFVBBG can be provided to Centrex and MLHG subscribers only.
•All feature interactions for CFVBBG are the same as for CFU.
•CFVBBG logs the billing record as a CFU record.
•CFVBBG generates measurements as CFU measurements.
CFVBBG Activation—CFVABBG
The system provides a BBG feature variant of CFUA called CFVABBG. For BBG subscribers, it is not recommended to deliver a courtesy call to a forwarded-to extension of another internal BBG line while activating forwarding. Other mechanics of operation of this feature are the same for CFVABBG as for CFUA, except that the courtesy call (CC) flag is always turned off.
The following limitations and behaviors apply to CFVABBG.
Note See the "CFUA Customization Options" section for details of the CC flag.
•CFVABBG can only be assigned to Centrex (BBG) subscribers.
•For typical business group call forwarding treatment, it is recommended to set the CC flag to N. In this case, CFVABBG implements the following courtesy call treatment during activation:
–When activated to an extension, no courtesy call is placed.
–When activated to an outside line, a courtesy call is placed. If the forwarded-to party answers the courtesy call, the feature is activated.
Note If the forwarded-to line is busy or does not answer, the feature is not activated. The user can still activate CFVBBG by repeating the activation procedure within 2 minutes of the first attempt. No courtesy call is set up during the second attempt. The user hears a confirmation tone. If more than 2 minutes elapse before the second attempt, the second attempt is treated as a first attempt.
•CFVABBG uses the NOD-RESTRICT-LIST entry for CFU.
•Activating CFVBBG will create a record in the SUBSCRIBER-FEATURE-DATA table with FNAME as CFU.
•All feature interactions for CFVABBG are the same as for CFUA.
•CFVABBG logs the billing record as a CFUA record.
•CFVABBG generates measurements as CFUA measurements.
Note The database tables (NOD-RESTRICT-LIST and SUBSCRIBER-FEATURE-DATA) mentioned in the above list are described in the Cisco BTS 10200 Softswitch CLI Database. For information on billing records, see the Cisco BTS 10200 Softswitch Billing Guide. For information on measurements, see the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.
Feature Provisioning Commands
Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.
Tip To provision this feature, see the CFVBBG provisioning procedure in the
Cisco BTS 10200 Softswitch Provisioning Guide.
Remote Activation of Call Forwarding (RACF)
Remote activation of call forwarding (RACF) permits user s to control their CFU functions when they are away from the phone. The service provider sets up this function for the user, and designates a DN the user should call to access interactive voice response (IVR) functions that control the RACF feature. Once the RACF function is set up, the user can take the following actions from a remote station:
•Activate CFU
•Deactivate CFU
•Change the target DN of CFU
The procedure is similar to making call-forwarding changes at a home or local business phone, but requires the additional step of dialing the remote location:
•The user dials a remote-access DN and is prompted to enter the directory number of the home or local business phone and then the RACF authorization code (a personal identification code, PIN). The PIN can be shared by a group, or can be unique to the individual subscriber.
Note A shared (nonunique) PIN is usually assigned to the subscriber group by the service provider. It can be changed only by the service provider, and not through handset provisioning.
•Upon successful validation of the PIN, the user's current CFU activation status is checked.
–If the CFU feature is currently inactive (calls are not being forwarded), the user is prompted to enter a DN to which calls should be forwarded.
–If the CFU feature is currently active (calls are being forwarded), the user is given the option of deactivating CFU or changing the DN to which call should be forwarded.
Note When the user accesses the RACF function, and enters (or changes) the DN to which calls are forwarded, the system checks the validity of the forwarded number.
•A subscriber with a unique PIN can change the PIN using the VSC function. (A specific VSC, for example *98, is assigned and provisioned by the service provider.) The PIN can only be changed from the base phone.
Tip For more details about the IVR interactions for this feature, see Chapter 6, "Interactive Voice Response Functions."
Tip To provision this feature, see the RACF provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Remote Call Forwarding (RCF)
The Cisco BTS 10200 Softswitch implements the remote call forwarding (RCF) feature as specified in LSSGR module FSD 01-02-1450 (GR-586), Call Forwarding Subfeatures.
RCF allows all incoming calls to be routed automatically to a remote DN, which can be in another region (NANP area for North America). RCF is activated by the service provider at customer request. With the RCF feature, all calls to the specified DN are always forwarded to a remote address. This service is similar to the CFU service with these exceptions:
•Forwarding is always activated and not controlled by the customer. (The forwarded-to number cannot be changed by direct customer action.)
•No local office terminal (physical telephone) is associated with the dialed number from which forwarding occurs.
•Multiple simultaneous calls can be active between the base switching office and the remote RCF terminal.
The billing data produced by the Cisco BTS 10200 Softswitch identifies the invoked feature as CFU and not RCF. The calling party is charged for the call to the RCF DN. The called party (RCF DN) can be charged for the CFU feature usage. The service provider can also charge the called party (RCF DN) for the call from the RCF base DN to the remote DN.
Tip To provision this feature, see the RCF provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Call Forwarding Busy (CFB)
The Cisco BTS 10200 Softswitch provides the call forwarding busy (CFB) feature. CFB allows a user (the called party) to instruct the network to forward calls when the line is busy or unreachable. A typical forwarding number is voice mail. The forwarding station is off hook when the CFB feature is executed, therefore no reminder ring is generated. CFB is set up by the service provider at the subscriber's request.
Note A specific trigger, T_NOT_REACHABLE, must be provisioned for the CFB feature to enable the call forwarding on unreachable condition.
Reference documents include:
•LSSGR module FSD 01-02-1401 (GR-580), Call Forwarding Variable
•LSSGR Module FSD 01-02-1450 (GR-586), Call Forwarding Subfeatures
•ITU-T Q-732.2
•ITU I-252.4
The service provider can provision the CFB feature to be active immediately on the customer line, or to be activated by the individual subscriber using the handset. The user activates the CFB feature on the local phone, and enters the forward-to phone number where the user wishes to have the calls forwarded. This forward-to DN is referred to as the B-number. The allowed types of B-numbers are listed in Table 3-3.
Table 3-3 Allowed Types of B-numbers
Subscriber Type
|
Allowed B-number
|
POTS
|
DN, without extensions
|
Centrex
|
Public access code + external DN, without extensions
|
An extension within the business group
|
The following conditions apply to the CFB feature:
•The CFB feature can be provided to POTS, Centrex, and MLHG subscribers.
•The CFB feature is in the deactivated mode unless activated by the service provider or subscriber.
•Call forwarding hop scenarios are restricted to a maximum of five hops. The call will be completed on the provisioned maximum number of hops.
•Multiple call forwarding (MCF) is a provisionable option that allows multiple incoming calls to be forwarded by the subscriber at the same time. If a subscriber already has CFB invoked, additional calls to the subscriber will be forwarded by CFB based on the MCF flag. If the MCF flag is turned off, only one CFB invocation is allowed.
The CFB feature is composed of four associated features, which are described in the sections that follow:
•CFB Variable Activation (CFBVA)
•CFB Variable Deactivation (CFBVD)
•CFB Interrogation (CFBI)
•CFB Invocation
Additional information about this feature is covered in the following sections:
•Invalid User Actions
•CFB Feature Interactions
•Feature Provisioning Commands
CFB Variable Activation (CFBVA)
This section discusses how the service provider can customize CFBVA, and the CFBVA procedures available to the handset user.
Blocking Call Forwarding to Certain Types of DNs
The service provider can block call forwarding to certain types of DNs by provisioning the nature of dial (NOD) parameter for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD Restrict List (nod-restrict-list) table. For example, if you provision NOD=TOLL-FREE and NOD=EMG in the nod-restrict-list table, the system will not allow call-forwarding to DNs of those types.
Caution If you want to block call-forwarding to an emergency (EMG) DN, such as 911, you must provision NOD=EMG for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD-RESTRICT-LIST. This is necessary to comply with the rule in Telcordia document GR-580, which says that 911 should not be a permitted "forward to" number.
Tip To provision the CFB feature, see the CFB provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
CFBVA Customization Options
The behavior of CFBVA can be customized using the following provisionable options. The detailed provisioning steps for these options are provided in the Cisco BTS 10200 Softswitch Provisioning Guide.
•Courtesy call (CC)—The CC flag controls the delivery of a courtesy call while activating CFB. Although this option can be provisioned, as a practical matter it usually is not provided with CFB service in most markets.
•Second stage dial tone (SDT)—The SDT flag controls the delivery of a dial tone after the subscriber enters the VSC for activation or interrogation of CFB. The permitted values for this flag are:
–NO_TONE
–DIAL_TONE
–STUTTER_DIAL_TONE
–CONFIRMATION_TONE
–CONFIRMATION_DIAL_TONE
Note For SIP phone subscribers, the SDT parameter has no effect. The SDT option is available through the dial plan in the SIP phone.
•Final stage dial tone (FDT)—The FDT flag controls the system response to a successful activation, deactivation, or interrogation of CFB by the subscriber. If FDT is not provisioned, the system provides a success announcement. The permitted values for this flag are the same as for the SDT flag.
Note For SIP phone subscribers, only the success announcements will be provided. The confirmation tone and dial tone will not be provided, even if the FDT flag is set.
•Multiple call forwarding (MCF)—When provisioned as Y, MCF allows multiple incoming calls to be forwarded by the subscriber at the same time. If a subscriber already has CFB invoked, additional calls to the subscriber will be forwarded by CFB based on the MCF flag. If the MCF flag is set to N, only one CFB invocation is allowed.
•International call forwarding (INTL)—When the INTL flag is set to N, forwarding to an international number is not allowed. When INTL is set to Y, the system checks for other restrictions on international calls, and allows forwarding if there are no other restrictions provisioned for the call type and calling number. (Other provisionable restrictions on international calling can be based on the nature of dial (NOD) and the subscriber feature data.)
For detailed information on how to set these parameters, see the following sources:
•To view a list of these feature options for CFU, use the show feature-profile-base fname=cfb% CLI command.
•To view the possible values for each of these feature options, see the Cisco BTS 10200 Softswitch CLI Database. Pull down the Feature Matrix [By Table] menu option, then display the FEATURE_PROFILE list.
•To provision the CFB feature, see the CFB provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
CFBVA Handset Procedures
CFB can be activated by the service provider or by the individual user. The procedures are as follows:
•CFB can be activated permanently at subscription time by the service provider. The service provider provisions the forward-to DN as requested by the subscriber. When the phone is off hook, calls made to the subscriber's line will be forwarded to the single forward-to number that was provisioned.
•CFB can be activated by the user as follows.
Note See the "CFBVA Customization Options" section for details of customized features CC, SDT, and FDT.
–The user lifts the handset and listens for dial tone.
–The user presses the VSC applicable to CFB activation (for example, typically *90 in North America and *40* in China). The VSC values are provisionable by the service provider.
–If provisioned for SDT, and if CFB can be activated, the system returns the provisioned dial tone.
–The user enters the B-number (local, long distance, or international) where calls are to be forwarded.
Note Centrex subscribers can specify a second forwarding number for in-group calls, but they cannot program this forwarding number via handset. The service provider sets this up at the Centrex subscriber's request.
–The user receives an appropriate error announcement if the forward-to number is invalid or restricted, or if the feature cannot be activated.
–If FDT is provisioned, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone, indicating that activation was successful. If FDT is not provisioned, the user hears a success announcement.
–CFB is now activated, and will stay active until it is deactivated with the appropriate deactivation VSC, or is overridden by the service provider via a CLI command.
CFB Variable Deactivation (CFBVD)
CFB can be deactivated by the service provider. via a CLI command. Alternatively, CFB can be deactivated by user as follows.
Note See the "CFBVA Customization Options" section for details of the customized feature FDT.
•The user lifts the handset and listens for dial tone.
•The user presses the VSC applicable to CFB deactivation (for example, typically *91 in North America and #40# in China). The VSC values are provisionable by the service provider.
•The user receives an appropriate error announcement if the feature cannot be deactivated.
•If deactivation was successful, and if FDT is provisioned, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone. If FDT is not provisioned, the user hears a success announcement.
CFB is now deactivated, and will stay deactivated until it is activated with the appropriate activation VSC or is overridden by the service provider via a CLI command.
After deactivation, the incoming calls are not forwarded and are completed on the user's phone. If the user has subscribed to and activated call waiting (CW), the system provides the CW tone, and further CW procedures will apply.
CFB Interrogation (CFBI)
CFB interrogation allows a user to check whether CFB is activated to a particular phone. The user performs an interrogation as follows.
Note See the "CFBVA Customization Options" section for details of customized features SDT and FDT.
•The user lifts the handset and listens for dial tone.
•The user presses the VSC applicable to CFB interrogation (for example, typically *#40* in China). The VSC values are provisionable by the service provider.
•If provisioned for SDT, and if CFB can be interrogated, the system returns the provisioned dial tone. If not provisioned for SDT, no tones are provided.
•The user enters the forward-to number to be interrogated (B-number).
Note The user can follow the B-number with a # to indicate the end of B-number entry.
Note If the user enters a digit string that does not match exactly the B-number against which CFB was activated, the interrogation attempt will result in an error announcement.
•The user receives an appropriate error announcement if the CFB feature is not forwarded to the B-number entered, or if the B-number is invalid.
•If FDT is provisioned and the CFB feature is activated to the forward-to number entered, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone.
•If FDT is not provisioned and the CFB feature is activated to the forward-to number entered, the system returns a success announcement.
CFB Invocation
CFB invocation is the actual procedure the system follows to forward the call.
Invalid User Actions
The following user actions are invalid, and the system provides an appropriate error announcement:
•The user enters an invalid directory number (DN) for the B-number.
•During CFB activation, the user enters a B-number that is determined by the system to be a type blocked by provisioning in the NOD-RESTRICT-LIST table. For example, if the nature of dial (NOD) for the B-number is set to EMG (emergency), but calls with NOD=EMG are blocked by provisioning in the NOD-RESTRICT-LIST table, the activation to that B-number will be denied.
•The user tries to activate CFB from a DN that has outgoing calls blocked by the OCB feature, or the user enters a B-number, but calls to that DN are blocked by OCB. For example, the call from the user's phone to the B-number would be a domestic long-distance call, but these calls are blocked by setting K=2 against the OCB feature in the SUBSCRIBER-FEATURE-DATA table.
Note The database tables (NOD-RESTRICT-LIST and SUBSCRIBER-FEATURE-DATA) mentioned in the above list are described in the Cisco BTS 10200 Softswitch CLI Database. For information on billing records, see the Cisco BTS 10200 Softswitch Billing Guide. For information on measurements, see the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.
•The user tries to activate CFB from or to a DN for which calls are restricted by the COS feature.
•The user tries to activate CFB when already activated (the B-number is not overwritten).
•The user tries to activate CFB to an international DN, but the service provider has blocked forwarding to international DNs. The service provider can block forwarding to international DNs using the international flag in the FEATURE table.
•The user tries to activate CFB to his or her own extension or DN.
•The user tries to deactivate CFB when already deactivated.
•The user interrogates CFB, but enters a digit string that does not match exactly the B-number against which CFB was activated. For example, if CFB was activated with a 5-digit string corresponding to a Centrex extension, and interrogation is attempted using a 10-digit string of the complete DN, the interrogation attempt will result in the applicable announcement. (See the complete list of standard Cisco BTS 10200 announcements in the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.)
•The user tries to interrogate CFB on a fresh system (a system with no entry in the SUBSCRIBER-FEATURE-DATA table). In this case, the user receives the error announcement immediately after entering *#40*. The system does not wait for the user to enter the B-number.
CFB Feature Interactions
This section describes the interaction of other subscriber features with the CFB feature.
CLIP, CNAM, and CND (caller ID features)—When a call is forwarded, the forwarded-to party receives the DN of the calling party on the caller ID display.
OCB—The interaction of CFB and OCB depends upon the sequence in which they are activated:
•If OCB is activated prior to CFB activation—OCB screening is performed on each DN the user enters when attempting to activate CFB. Successful CFB activation depends on the existing OCB K-VALUE and the forward-to DN:
–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.
–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:
–User-dialed calls—User-dialed calls can be blocked by OCB (depending on the K-VALUE).
–Forwarded calls—CFB remains active as originally set up by the user, therefore, calls forwarded by the CFB feature cannot be blocked using OCB screening.
CW (or CWD)—If both CFB and CW (or CWD) are subscribed to and activated by the user, CW (or CWD) takes precedence. An incoming call to a user already on a call with CW (or CWD) activated will be given the CW (or CWD) tone, and further CW (or CWD) procedures will be applied. The following additional conditions apply:
•If a user with CW (or CWD) is already involved in a call, the next incoming call is not forwarded. However, any additional incoming calls will be forwarded.
•If a user with CW (or CWD) has gone off hook but has not yet completed a call or the call is in a ringing state, and there is an incoming call, the call will be forwarded.
COS—If a call to a DN is restricted by COS screening, CFB cannot be activated or invoked to that DN.
AR—If Automatic Recall (AR) is used to call a subscriber with CFB feature, the call is not forwarded when the CFB subscriber is off-hook. Instead, the calling subscriber hears the announcement "The user you are calling is busy. The system will check the line for next 30 minutes, and then you will be notified". Therefore, CFB feature is not activated when AR is used to call an off-hook CFB subscriber. For example, consider a situation where Subscriber A uses the AR feature to call another Subscriber B, who has the CFB feature activated to forward all calls to C. Subscriber B is now off-hook, and Subscriber A calls Subscriber B using AR. In this case, A's call is not forwarded to C. Instead, Subscriber A hears an announcement informing that Subscriber B is busy.
Feature Provisioning Commands
Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.
Tip To provision this feature, see the CFB provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Call Forwarding No Answer (CFNA)
The BTS 10200 provides the call forwarding no answer (CFNA) feature. CFNA allows a user (the called party) to instruct the network to forward incoming calls that are not answered within a specified number of rings. (Five rings is the default setting, but number of rings is configurable.) A typical forwarding number is voice mail. This service can be used with either rotary or dual tone multifrequency (DTMF) equipped customer premises equipment (CPE).
Note The service provider can provision a parameter that determines the timeout (and thus the number of 6-second rings) before a call is forwarded. The timeout can be set at the feature level (in the Feature table) and at the subscriber level (in the Subscriber Feature Data table), and the setting for the subscriber takes precedence over the setting at the feature level.
The CFNA feature affects the called party in specific ways, depending upon whether the called party phone is on hook or off hook when the call comes in:
•If the forwarding phone is on hook when a call comes in, the phone will ring in the normal manner, and then the call will be forwarded when the CFNA timer runs out.
•If the forwarding phone is off hook when the call comes in, no reminder ring is generated. However, if the user has subscribed to and activated CW (or CWD), the CW (or CWD) treatment will be given first, and then the call will be forwarded after the CFNA timer runs out. The forwarding station is ringing when the CFNA feature is executed, therefore no reminder ring is generated.
Reference documents include:
•LSSGR module FSD 01-02-1401 (GR-580), Call Forwarding Variable
•LSSGR Module FSD 01-02-1450 (GR-586), Call Forwarding Subfeatures
•LSSGR module FSD 01-02-2200 (GR-1520), Ring Control
•ITU-T Q-732.2
•ITU I-252.4
The service provider can provision the CFNA feature to be active immediately on the customer line, or to be activated by the individual subscriber using the handset. The user activates the CFNA feature on the local phone, and enters the forward-to phone number where the user wishes to have the calls forwarded. This forward-to DN is referred to as the B-number. The allowed types of B-numbers are listed in Table 3-4.
Table 3-4 Allowed Types of B-numbers
Subscriber Type
|
Allowed B-number
|
POTS
|
DN, without extensions
|
Centrex
|
Public access code + external DN, without extensions
|
An extension within the business group
|
The following conditions apply to the CFNA feature:
•The CFNA feature can be provided to POTS, Centrex, and MLHG subscribers.
•The CFNA feature is in the deactivated mode unless activated by the service provider or subscriber.
•Call forwarding hop scenarios are restricted to a maximum of five hops. The call will be completed on the provisioned maximum number of hops.
•Multiple call forwarding (MCF) is a provisionable option that allows multiple incoming calls to be forwarded by the subscriber at the same time. If a subscriber already has CFNA invoked, additional calls to the subscriber will be forwarded by CFNA based on the MCF flag. If the MCF flag is turned off, only one CFNA invocation is allowed.
The CFNA feature is composed of four associated features, which are described in the sections that follow:
•CFNA Variable Activation (CFNAVA)
•CFNA Variable Deactivation (CFNAVD)
•CFNA Interrogation (CFNAI)
•CFNA Invocation
Additional information about this feature is covered in the following sections:
•Invalid User Actions
•CFNA Feature Interactions
•Feature Provisioning Commands
CFNA Variable Activation (CFNAVA)
This section discusses how the service provider can customize CFNAVA, and the CFNAVA procedures available to the handset user.
Blocking Call Forwarding to Certain Types of DNs
The service provider can block call forwarding to certain types of DNs by provisioning the nature of dial (NOD) parameter for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD Restrict List (nod-restrict-list) table. For example, if you provision NOD=TOLL-FREE and NOD=EMG in the nod-restrict-list table, the system will not allow call-forwarding to DNs of those types.
Caution If you want to block call-forwarding to an emergency (EMG) DN, such as 911, you must provision NOD=EMG for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD-RESTRICT-LIST. This is necessary to comply with the rule in Telcordia document GR-580, which says that 911 should not be a permitted "forward to" number.
Tip To provision the CFNA feature, see the CFNA provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
CFNAVA Customization Options
The behavior of CFNAVA can be customized using the following provisionable options. The detailed provisioning steps for these options are provided in the Cisco BTS 10200 Softswitch Provisioning Guide.
•Courtesy call (CC)—The CC flag controls the delivery of a courtesy call while activating CFNA. Although this option can be provisioned, as a practical matter it usually is not provided with CFNA service in most markets.
•Second stage dial tone (SDT)—The SDT flag controls the delivery of a dial tone after the subscriber enters the VSC for activation or interrogation of CFNA. The permitted values for this flag are:
–NO_TONE
–DIAL_TONE
–STUTTER_DIAL_TONE
–CONFIRMATION_TONE
–CONFIRMATION_DIAL_TONE
Note For SIP phone subscribers, the SDT parameter has no effect. The SDT option is available through the dial plan in the SIP phone.
•Final stage dial tone (FDT)—The FDT flag controls the system response to a successful activation, deactivation or interrogation of CFNA by the subscriber. If FDT is not provisioned, the system provides a success announcement. The permitted values for this flag are the same as for the SDT flag.
Note For SIP phone subscribers, only the success announcements will be provided. The confirmation tone and dial tone will not be provided, even if the FDT flag is set.
•Multiple call forwarding (MCF)—When provisioned as Y, MCF allows multiple incoming calls to be forwarded by the subscriber at the same time. If a subscriber already has CFNA invoked, additional calls to the subscriber will be forwarded by CFNA based on the MCF flag. If the MCF flag is set to N, only one CFNA invocation is allowed.
•International call forwarding (INTL)—When the INTL flag is set to N, forwarding to an international number is not allowed. When INTL is set to Y, the system checks for other restrictions on international calls, and allows forwarding if there are no other restrictions provisioned for the call type and calling number. (Other provisionable restrictions on international calling can be based on the nature of dial (NOD) and the subscriber feature data.)
For detailed information on how to set these parameters, see the following sources:
•To view a list of these feature options for CFU, use the show feature-profile-base fname=cfna% CLI command.
•To view the possible values for each of these feature options, see the Cisco BTS 10200 Softswitch CLI Database. Pull down the Feature Matrix [By Table] menu option, then display the FEATURE_PROFILE list.
•To provision the CFNA feature, see the CFNA provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
CFNAVA Handset Procedures
CFNA can be activated by the service provider or by the individual user. The procedures are as follows:
•CFNA can be activated permanently at subscription time by the service provider. The service provider provisions the forward-to DN as requested by the subscriber. When the phone is not answered, calls made to the subscriber's line will be forwarded to the single forward-to number that was provisioned.
•CFNA can be activated by the user as follows.
Note See the "CFNAVA Customization Options" section for details of customized features CC, SDT, and FDT.
–The user lifts the handset and listens for dial tone.
–The user presses the VSC applicable to CFNA activation (for example, typically *92 in North America and *41* in China). The VSC values are provisionable by the service provider.
–If provisioned for SDT, and if CFNA can be activated, the system returns the provisioned dial tone.
–The user enters the B-number (local, long distance, or international) where calls are to be forwarded.
Note Centrex subscribers can specify a second forwarding number for in-group calls, but they cannot program this forwarding number via handset. The service provider sets this up at the Centrex subscriber's request.
–The user receives an appropriate error announcement if the forward-to number is invalid or restricted, or if the feature cannot be activated.
–If the feature can be activated to the forward-to number entered, the system returns a confirmation tone and attempts to place a courtesy call to the forward-to number (if provisioned for CC).
–If the forwarded-to party answers the courtesy call (when CC is provisioned as ANS), or if CC is provisioned as NOANS, the CFNA feature is activated.
Note When CC is provisioned for ANS, and if the forwarded-to line is busy or does not answer, the CFNA feature is not activated. The user can still activate CFNA by repeating the activation procedure within 2 minutes of the first attempt. No courtesy call is set up during the second attempt. The user hears a confirmation tone. If more than 2 minutes elapse before the second attempt, the second attempt is treated as a first attempt.
•If FDT is provisioned, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone, indicating that activation was successful. If FDT is not provisioned, the user hears a success announcement.
•CFNA is now activated, and will stay active until it is deactivated using the appropriate deactivation VSC, or is overridden by the service provider via a CLI command.
CFNA Variable Deactivation (CFNAVD)
CFNA can be deactivated by the service provider via a CLI command. Alternatively, CFNA can be deactivated by the individual user as follows.
Note See the "CFNAVA Customization Options" section for details of the customized feature FDT.
•The user lifts the handset and listens for dial tone.
•The user presses the VSC applicable to CFNA deactivation (for example, typically *93 in North America and #41# in China). The VSC values are provisionable by the service provider.
•The user receives an appropriate error announcement if the feature cannot be deactivated.
•If deactivation was successful, and if FDT is provisioned, the user hears a confirmation tone for 1 second, followed by the provisioned dial tone. If FDT is not provisioned, the user hears a success announcement.
CFNA is now deactivated, and will stay deactivated until it is activated using the appropriate activation VSC or is overridden by the service provider via a CLI command.
After deactivation, the incoming calls are not forwarded and are completed on the user's phone.
CFNA Interrogation (CFNAI)
CFNA interrogation allows a user to check whether CFNA is activated to a particular phone. The user performs an interrogation as follows.
Note See the "CFNAVA Customization Options" section for details of customized features SDT and FDT.
•The user lifts the handset and listens for dial tone.
•The user presses the VSC applicable to CFNA interrogation (for example, typically *#41* in China). The VSC values are provisionable by the service provider.
•If provisioned for SDT, and if CFNA can be interrogated, the system returns a confirmation tone for one second and then the provisioned dial tone. If not provisioned for SDT, no tones are provided.
•The user enters the forward-to number to be interrogated (B-number).
Note The user can follow the B-number with a # to indicate the end of B-number entry.
Note If the user enters a digit string that does not match exactly the B-number against which CFNA was activated, the interrogation attempt will result in an error announcement.
•The user receives an appropriate error announcement if the CFNA feature is not forwarded to the B-number entered or if the B-number is invalid.
•If FDT is provisioned and the CFNA feature is activated to the forward-to number entered, the user hears a confirmation tone for one second, followed by the provisioned dial tone.
•If FDT is not provisioned and the CFNA feature is activated to the forward-to number entered, the system returns a success announcement.
CFNA Invocation
CFNA invocation is the actual procedure the system follows to forward the call.
Invalid User Actions
The following user actions are invalid, and the system provides an appropriate error announcement:
•The user enters an invalid directory number (DN) for the B-number.
•During CFNA activation, the user enters a B-number that is determined by the system to be a type blocked by provisioning in the NOD-RESTRICT-LIST table. For example, if the nature of dial (NOD) for the B-number is set to EMG (emergency), but calls with NOD=EMG are blocked by provisioning in the NOD-RESTRICT-LIST table, the activation to that B-number will be denied.
•The user tries to activate CFNA from a DN that has outgoing calls blocked by the OCB feature, or the user enters a B-number, but calls to that DN are blocked by OCB. For example, the call from the user's phone to the B-number would be a domestic long-distance call, but these calls are blocked by setting K=2 against the OCB feature in the SUBSCRIBER-FEATURE-DATA table.
Note The database tables (NOD-RESTRICT-LIST and SUBSCRIBER-FEATURE-DATA) mentioned in the above list are described in the Cisco BTS 10200 Softswitch CLI Database. For information on billing records, see the Cisco BTS 10200 Softswitch Billing Guide. For information on measurements, see the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.
•The user tries to activate CFNA from or to a DN for which calls are restricted by the COS feature.
•The user tries to activate CFNA when already activated (the B-number is not overwritten).
•The user tries to activate CFNA to an international DN, but the service provider has blocked forwarding to international DNs. The service provider can block forwarding to international DNs using the international flag in the FEATURE table.
•The user tries to activate CFNA to his or her own extension or DN.
•The user tries to deactivate CFNA when already deactivated.
•The user interrogates CFNA, but enters a digit string that does not match exactly the B-number against which CFNA was activated. For example, if CFNA was activated with a 5-digit string corresponding to a Centrex extension, and interrogation is attempted using a 10-digit string of the complete DN, the interrogation attempt will result in the applicable announcement. (See the complete list of standard Cisco BTS 10200 announcements in the Cisco BTS 10200 Softswitch Provisioning Guide.)
•The user tries to interrogate CFNA on a fresh system (a system with no entry in the SUBSCRIBER-FEATURE-DATA table). In this case, the user receives the error announcement immediately after entering *#41*. The system does not wait for the user to enter the B-number.
CFNA Feature Interactions
This section describes the interaction of other subscriber features with the CFNA feature.
•CLIP, CNAM, and CND (caller ID features)—When a call is forwarded, the forwarded-to party receives the DN of the calling party on the caller ID display.
•COS—If a call to a DN is restricted by COS screening, CFNA cannot be activated or invoked to that DN.
•OCB—The interaction of CFNA and OCB depends upon the sequence in which they are activated:
–If OCB is activated prior to CFNA activation—OCB screening is performed on each DN the user enters when attempting to activate CFNA. Successful CFNA activation depends on the existing OCB K-VALUE and the forward-to DN:
Note If the existing OCB K-VALUE is set to block calls to the forward-to DN, then the system does not allow CFNA activation. The user receives an error announcement.
Note If the OCB K-VALUE allows calls to this DN, then the CFNA activation process continues. Once the CFNA activation attempt to a specific DN is accepted by the system, it is applicable permanently regardless of any future OCB K-VALUE changes. That is, future changes to the OCB K-VALUE have no effect on CFNA invocation. CFNA to this DN can be deactivated by the user in the normal manner (#41#).
–If CFNA is activated prior to OCB activation—The user can activate the OCB feature, or change the OCB K-VALUE, regardless of the existing CFNA feature. However, invocation of OCB depends upon the type of call:
Note User-dialed calls—User-dialed calls can be blocked by OCB (depending on the K-VALUE).
Note Forwarded calls—CFNA remains active as originally set up by the user, therefore, calls forwarded by the CFNA feature cannot be blocked using OCB screening.
•There is an interaction when a Centrex subscriber has all three of the following features assigned and active:
1. Call hold—CHD.
2. Call waiting—CW or CIDCW or both.
3. Call forwarding on no answer—CFNA, VM (or VMA), or any combination of these.
For information on this interaction, see the "CHD with CW/CIDCW and CFNA/VM/VMA" section.
•If CHD is assigned to the subscriber along with CFNA (CFNA active), the following interaction occurs.
–A (the subscriber) and B are on an active call.
–C calls A.
–C hears a busy tone and is not connected. The call from C is not forwarded by the CFNA feature.
•CW or CWD—If both CFNA and CW (or CWD) are subscribed to and activated by the user, the interaction is as follows. If the user is on an active call when a new call comes in, the CW (or CWD) tone will be played. If the user presses the Flash button or hookswitch before the CFNA timer runs out, the user will be connected to the new call, and the call will proceed according to the CW (or CWD) feature. If the user takes no action, and the CFNA timer runs out, the waiting call will be forwarded per the CFNA procedure.
Several provisionable parameters can affect the processing of this call.
–The CW timeout is based on a switch-wide parameter, NO-ANSWER-TMR in the ca-config table (default 185 seconds). There is also a parameter, START-NO-ANSWER-TMR in the ca-config table, to specify whether NO-ANSWER-TMR is to be started or not; default is N.
The CFNA timeout is provisioned via the TYPE1=TO parameter in the Feature table (default 30 seconds).
–If Subscriber A has the default timer settings (that is, CFNA TO=30 seconds and NO-ANSWER-TIMER=185 seconds), and has the START-NO-ANSWER-TMR parameter set to Y (not the default), the call is processed as follows:
[1] A calls B, B answers.
[2] C calls A, A hears the CW tone, C hears ring tone.
[3] If A does not attempt to answer the waiting call (C), and CFNA times out (30 seconds), C is forwarded according to normal CFNA procedures.
However, if the CFNA timeout (TO) is set to a value greater than NO-ANSWER-TMR, when NO-ANSWER-TMR expires, C is disconnected and hears a busy tone, and CFNA is cancelled.
Feature Provisioning Commands
Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.
Tip To provision this feature, see the CFNA provisioning procedure in the Cisco BTS 10200 Softswitch ProvisioningGuide.
Call Forwarding Combination (CFC)
The system supports a set of vertical service codes (VSCs) to activate, deactivate, and interrogate Call Forwarding Combination (CFC). Once activated, CFC forwards incoming calls to the subscriber when the subscriber is either busy or does not answer. This feature combines the functionality of CFB and CFNA.
The forward-to DN is referred to as the B-number. The allowed types of B-numbers are listed in Table 3-5.
Table 3-5 Allowed Types of B-numbers
Subscriber Type
|
Allowed B-number
|
POTS
|
DN, without extensions
|
Centrex
|
Public access code + external DN, without extensions
|
An extension within the business group
|
The following conditions apply to the CFC feature:
•The CFC feature can be provided to POTS, Centrex, and MLHG subscribers.
•The CFC feature is in the deactivated mode unless activated by the service provider or subscriber.
•Call forwarding hop scenarios are restricted to a maximum of five hops. The call will be completed on the provisioned maximum number of hops.
•Multiple call forwarding (MCF) is a provisionable option that allows multiple incoming calls to be forwarded by the subscriber at the same time. If a subscriber already has CFC invoked, additional calls to the subscriber will be forwarded by CFC based on the MCF flag. If the MCF flag is turned off, only one CFC invocation is allowed.
Vertical Service Codes for CFC
The values of the VSCs are provisionable. Typical VSC examples for the CFC subfeatures are as follows:
•*68—CFC_ACT (CFC Activation without change of forward-to DN)
•*88—CFC_DEACT (CFC Deactivation)
•*201—CFC_DN_CHG_ACT (CFC Activation with change of forward-to DN)
•*202—CFCI_NO_DN_VRFY (CFC Interrogation without forward-to DN verification)
•*203—CFCI (CFC Interrogation with forward-to DN verification)
Blocking Call Forwarding to Certain Types of DNs
The service provider can block call forwarding to certain types of DNs by provisioning the nature of dial (NOD) parameter for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD Restrict List (nod-restrict-list) table. For example, if you provision NOD=TOLL-FREE and NOD=EMG in the nod-restrict-list table, the system will not allow call-forwarding to DNs of those types.
Caution If you want to block call-forwarding to an emergency (EMG) DN, such as 911, you must provision NOD=EMG for the call-forwarding features (CFU, CFB, CFNA, and CFC) in the NOD-RESTRICT-LIST. This is necessary to comply with the rule in Telcordia document GR-580, which says that 911 should not be a permitted "forward to" number.
Detailed Feature Description
The CFC feature is composed of six associated features, which are described in the sections that follow:
•CFC Activation (CFC_ACT)
•CFC Deactivation (CFC_DEACT)
•CFC Activation with Directory Number Change (CFC_DN_CHG_ACT)
•CFC Interrogation with No Directory Number Verification (CFCI_NO_DN_VRFY)
•CFC Interrogation (CFCI)
•CFC Invocation (CFC)
Additional information about this feature is covered in the following sections:
•Flags Applicable to CFC Activation and Deactivation Subfeatures
•Invalid User Actions
•CFC Feature Interactions
•Feature Provisioning Commands
CFC Activation (CFC_ACT)
CFC activation allows the end user to activate CFC to a pre-defined DN (which was set up when provisioning the feature). However, the end user cannot change the DN via this feature.
To activate CFC, the subscriber dials the access code for activation. If the final dial tone parameter (FDT) is provisioned, the subscriber hears the provisioned dial tone if the feature is successfully activated. If the feature is not successfully activated, the subscriber hears a reorder tone, or an announcement, if the announcements are provisioned.
If the feature is already active, the subscriber hears a stutter dial tone confirming that the feature is active.
While activating CFC, the pre-defined DN is validated. To be valid, the DN must conform to the dial-plan provisioned in the Call Agent (CA).
Activating CFC has some limitations, including:
•The subscriber cannot activate CFC if the pre-defined DN is the subscriber's own DN or extension.
•The subscriber cannot activate CFC if the pre-defined DN is blocked by Outgoing Call Barring (OCB).
•The subscriber cannot activate CFC if the pre-defined DN has a call-type which is blocked by the CFC nod-restrict-list. Where applicable, all CFC features treat the nod-restrict list as a black list.
The pre-defined DN can be a speed code. However, to be valid, the translated DN must conform to the dial-plan provisioned in the CA.
For CENTREX subscribers, the pre-defined DN can be an extension or a PAC followed by a DN.
CFC Deactivation (CFC_DEACT)
CFC deactivation allows the end user to deactivate the CFC feature. However, even if the feature is deactivated, the forwarding DN for the subscriber is preserved.
To deactivate CFC, the subscriber dials the access code for deactivation. If the FDT parameter is provisioned, the subscriber hears the provisioned dial tone if the feature is successfully deactivated. If the feature is not successfully deactivated, the subscriber hears a reorder tone or an announcement, if announcements are provisioned.
If the feature is already inactive, the subscriber hears a stutter dial tone confirming that the feature is inactive.
For CFC deactivation, the DN validity is not checked. The feature simply deactivates CFC without any checks.
CFC Activation with Directory Number Change (CFC_DN_CHG_ACT)
CFC with directory number change enables the subscriber to activate CFC to a user-defined remote DN, and the end user can change the DN via this feature.
To activate this feature, the subscriber begins by dialing an access code for activation. If the second dial tone parameter (SDT) is provisioned, the subscriber hears the provisioned dial tone, and enters the Forwarding DN. If the FDT parameter is provisioned, the subscriber hears the provisioned dial tone if the feature is successfully activated. If the feature is not successfully activated, the subscriber hears a reorder tone or an announcement, if announcements are provisioned.
If the feature is already active, the subscriber hears a stutter dial tone confirming that the feature is active.
While activating the feature, the user-defined DN is checked for validity. To be valid, the DN must conform to the dial-plan provisioned in the CA.
Activating CFC with Directory Number Change has some limitations, including:
•The subscriber cannot activate CFC if the user-defined DN is the subscriber's own DN or extension.
•The subscriber cannot activate CFC is the user-defined DN is blocked by OCB.
•The subscriber cannot activate CFC is the user-defined DN has a call-type which is blocked by the CFC nod-restrict-list. Where applicable, all CFC features treat the nod-restrict list as a black list.
The user-defined DN can be a speed code. However, to be valid, the translated DN should conform to the dial-plan provisioned in the CA. The feature stores the translated DN as the forwarding number in the database.
For CENTREX subscribers, the pre-defined DN can be an extension or a PAC followed by a DN. If CFC is activated with an extension, the feature stores that extension as the forwarding number in the database.
CFC Interrogation with No Directory Number Verification (CFCI_NO_DN_VRFY)
CFC Interrogation with no directory number verification enables the subscriber to verify (or interrogate) whether CFC is active on the subscriber's line or not.
To use the feature, the subscriber dials a star code. If the FDT parameter is provisioned and CFC is active, the subscriber hears the provisioned dial tone. If CFC is not active, the subscriber hears a reorder tone or an announcement, if announcements are provisioned.
CFC Interrogation (CFCI)
CFC interrogation enables the subscriber to verify (or interrogate) whether CFC is active on the subscriber's line to a certain DN or not.
To use the feature, the subscriber dials the access code for interrogation. If the SDT parameter is provisioned, the subscriber hears the provisioned dial tone, and enters the DN against which to perform the verification. If the FDT parameter is provisioned, and if CFC is active to that DN, the subscriber hears the provisioned dial tone. If CFC is not active, or active to a different DN, the subscriber hears a reorder tone or an announcement, if announcements are provisioned.
The verification is done against the exact DN stored in the database for CFC. The feature does not translate or do any conversion before comparing the numbers (like extension to a DN, or adding a country code if the number is not fully specified by the user, or converting from a speed code to a DN).
CFC Invocation (CFC)
The CFC invocation feature forwards a call coming to the subscriber when the subscriber is either busy or does not answer. CFC checks the nod-restrict-list check for call-types blocked on CFC. Provision the nod-restrict-list with the same fname as CFC.
CFC is considered deactivated unless explicitly activated by the subscriber.
The following flags are provisionable in the feature table, and affect the forwarding behavior of CFC:
•Multiple call forwarding (MCF)—Setting the MCF flag to Y (Yes) allows multiple calls to be forwarded at the same time. Setting the MCF flag to N (No) allows the subscriber to have only one busy or one no-answer call forwarded at a time.
•Timeout (TO)—The TO flag is used for the no-answer timeout for CFC. The default value is 30 seconds.
Flags Applicable to CFC Activation and Deactivation Subfeatures
There are three optional TYPE-VALUE pairs to configure for CFC subfeatures in the feature table. The TYPE-VALUE pairs correspond to the SDT, FDT and CC flags. This section describes the feature behavior based on these flags.
Table 3-6 shows which flags are applicable to each feature, and lists the default values for the flags.
Table 3-6 Flags for CFC Activation and Deactivation Subfeatures
Feature
|
Flag
|
Default Value(s)
|
CFC_DN_CHG_ACT
Note The INTL flag is also applicable to this feature (default N).
|
SDT
|
DIAL_TONE
|
FDT
|
STUTTER_DIAL_TONE
|
CC
|
N
|
CFC_DEACT
|
SDT
|
Feature does not need the flag when executed.
|
FDT
|
STUTTER_DIAL_TONE
|
CC
|
Feature does not need the flag when executed.
|
CFC_ACT
|
SDT
|
Feature does not need the flag when executed.
|
FDT
|
STUTTER_DIAL_TONE
|
CC
|
Feature does not need the flag when executed.
|
CFCI_NO_DN_VRFY
|
SDT
|
Feature does not need the flag when executed.
|
FDT
|
STUTTER_DIAL_TONE
|
CC
|
Feature does not need the flag when executed.
|
CFCI
|
SDT
|
DIAL_TONE
|
FDT
|
STUTTER_DIAL_TONE
|
CC
|
Feature does not need the flag when executed.
|
TYPE-VALUE Pair 1—SDT
The first TYPE-VALUE pair for the second dial tone (SDT) is:
VALUEn=[NO_TONE|DIAL_TONE|STUTTER_DIAL_TONE|CONFIRMATION_TONE|CONFIRMATION_DIAL_TONE]
If provisioned, this pair specify the tone to play just after the subscriber dials the VSC.
The following tones play based on the values set:
•If the VALUE is set to NO_TONE, no tones play.
•If VALUE is set to DIAL_TONE, the dial tone plays.
•If VALUE is set to STUTTER_DIAL_TONE, a stutter dial tone plays.
•If the VALUE is set to CONFIRMATION_DIAL_TONE, a confirmation, followed by the dial tone, plays.
•If the VALUE is set to CONFIRMATION_TONE, a confirmation tone is played.
Note For SIP phone subscribers, the SDT parameter has no effect. The SDT option is available through the dial plan in the SIP phone.
TYPE-VALUE Pair 2—FDT
The second TYPE-VALUE pair for final dial tone (FDT) is:
VALUEn=[NO_TONE|DIAL_TONE|STUTTER_DIAL_TONE|CONFIRMATION_TONE|CONFIRMATION_DIAL_TONE]
If provisioned, the pair dictates what tone to play after the subscriber successfully activates or deactivates the feature.
The following tones play based on the values set:
•If the VALUE is set to NO_TONE and if the announcement server is provisioned, an announcement plays.
•If VALUE is set to DIAL_TONE, a dial tone plays.
•If VALUE is set to STUTTER_DIAL_TONE, a stutter dial tone plays.
•If the VALUE is set to CONFIRMATION_DIAL_TONE, a confirmation, followed by the dial tone, plays.
•If the VALUE is set to CONFIRMATION_TONE, a confirmation tone is played.
Note For SIP phone subscribers, only the success announcements will be provided. The confirmation tone and dial tone will not be provided, even if the FDT flag is set.
TYPE-VALUE Pair 3—CC
The third TYPE-VALUE pair is:
If provisioned, the pair above dictates the feature behavior after the subscriber successfully activates the CFC_DN_CHG_ACT feature.
Note This flag is applicable to only this feature.
The feature behaviors depend on the following values:
•If the VALUE is set to ANS, a courtesy call is placed to a forwarding number entered by the user; CFC is activated to that number only when the remote party answers the call. If the remote party does not answer, or if the subscriber hangs up, the subscriber has two minutes to dial the CFC_DN_CHG_ACT access code, followed by the same number, to force CFC activation to that number. At this point, no courtesy call is placed to the number, and CFC is activated.
•If the value is set to NOANS, a courtesy call is placed to the forwarding number entered by the user, but the remote party need not answer the call to activate CFC. CFC is activated whether the courtesy call is successful, or whether the remote party answered.
•If the VALUE is set to N, no courtesy call is placed when the subscriber successfully activates CFC_DN_CHG_ACT. Instead, the feature looks up the FDT flag for the appropriate treatment.
Additional Provisioning Details
For detailed information on how to set these parameters, see the following sources:
•To view a list of these feature options for CFU, use the show feature-profile-base fname=cfc% CLI command.
•To view the possible values for each of these feature options, see the Cisco BTS 10200 Softswitch CLI Database. Pull down the Feature Matrix [By Table] menu option, then display the FEATURE_PROFILE list.
•To provision the CFC feature, see the CFC provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Invalid User Actions
The following user actions are invalid, and the system provides an appropriate error announcement:
•The user enters an invalid directory number (DN) for the B-number.
•The user tries to activate CFC (with CC set to ANS) for the second time within a 2-minute interval to a DN which is different from the one used in the first attempt. (In addition, the history associated with the first attempt will be removed.)
•During CFC activation, the user enters a B-number that is determined by the system to be a type blocked by provisioning in the NOD-RESTRICT-LIST table. For example, if the nature of dial (NOD) for the B-number is set to EMG (emergency), but calls with NOD=EMG are blocked by provisioning in the NOD-RESTRICT-LIST table, the activation to that B-number will be denied.
•The user tries to activate CFC from a DN that has outgoing calls blocked by the OCB feature, or the user enters a B-number, but calls to that DN are blocked by OCB. For example, the call from the user's phone to the B-number would be a domestic long-distance call, but these calls are blocked by setting K=2 against the OCB feature in the SUBSCRIBER-FEATURE-DATA table.
Note The database tables (NOD-RESTRICT-LIST and SUBSCRIBER-FEATURE-DATA) mentioned in the above list are described in the Cisco BTS 10200 Softswitch CLI Database. For information on billing records, see the Cisco BTS 10200 Softswitch Billing Guide. For information on measurements, see the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.
•The user tries to activate CFC from or to a DN for which calls are restricted by the COS feature.
•The user tries to activate CFC when already activated (the B-number is not overwritten).
•The user tries to activate CFC to an international DN, but the service provider has blocked forwarding to international DNs. The service provider can block forwarding to international DNs using the international flag in the FEATURE table.
•The user tries to activate CFC to his or her own extension or DN.
•The user tries to deactivate CFC when already deactivated.
•The user interrogates CFC, but enters a digit string that does not match exactly the B-number against which CFC was activated. For example, if CFC was activated with a 5-digit string corresponding to a Centrex extension, and interrogation is attempted using a 10-digit string of the complete DN, the interrogation attempt will result in an error announcement. (See the complete list of standard Cisco BTS 10200 announcements in the Cisco BTS 10200 Softswitch Provisioning Guide.)
•The user tries to interrogate CFC on a fresh system (a system with no entry in the SUBSCRIBER-FEATURE-DATA table). In this case, the user receives the error announcement immediately after entering the interrogation code (for example, *68). The system does not wait for the user to enter the B-number
CFC Feature Interactions
This section describes the interaction of other subscriber features with the CFC feature.
•CLIP, CNAM, and CND (caller ID features)—When a call is forwarded, the forwarded-to party receives the DN of the calling party on the caller ID display.
•OCB—The interaction of CFC and OCB depends upon the sequence in which they are activated:
–If OCB is activated prior to CFC activation—OCB screening is performed on each DN the user enters when attempting to activate CFC. Successful CFC activation depends on the existing OCB K-VALUE and the forward-to DN:
Note If the existing OCB K-VALUE is set to block calls to the forward-to DN, then the system does not allow CFC activation. The user receives an error announcement.
Note If the OCB K-VALUE allows calls to this DN, then the CFC activation process continues. Once the CFC activation attempt to a specific DN is accepted by the system, it is applicable permanently regardless of any future OCB K-VALUE changes. That is, future changes to the OCB K-VALUE have no effect on CFC invocation. CFC to this DN can be deactivated by the user in the normal manner (#57#).
–If CFC is activated prior to OCB activation—The user can activate the OCB feature, or change the OCB K-VALUE, regardless of the existing CFC feature. However, invocation of OCB depends upon the type of call:
Note User-dialed calls—User-dialed calls can be blocked by OCB (depending on the K-VALUE).
Note Forwarded calls—CFC remains active as originally set up by the user, therefore, calls forwarded by the CFC feature cannot be blocked using OCB screening.
•CFC_ACT and COS: If a call to a DN is restricted by COS screening, CFC cannot be activated or invoked to that DN.
•CFC Activation/Deactivation and Speed Call/Abbreviated Dial: Subscribers can set their speed call to the CFC Activation/Deactivation access codes. For example, with One-Digit Speed Call, the subscriber can set the speed call for digit "2" to map to "*68" which can be the CFC Activation access code.
•CFC Activation and OCB: CFC Activation to a DN blocked by outgoing call barring (OCB) results in a re-order tone or announcement.
•CFC Activation with DN Change and OCB: CFC Activation with DN Change to a DN blocked by OCB results in a re-order tone or announcement.
•CFC and OCB: Calls are not forwarded by CFC to DNs blocked by OCB for the subscriber.
•CFC and CFU: If a subscriber has both CFC and call forwarding unconditional (CFU) assigned and active, incoming calls are forwarded by CFU.
•CFC and CFB: If a subscriber has both CFC and CFB assigned and active, incoming calls on which the subscriber is busy are forwarded by CFB.
•CFC and CFB, CFB is deactivated: If a subscriber has both CFC and CFB assigned, and CFC active and CFB inactive, incoming calls on which the subscriber is busy are forwarded by CFC.
•CFC and CFNA: If a subscriber has both CFC and CFNA assigned and active, incoming calls on which the subscriber does not answer are forwarded by CFNA.
•CFC and CFNA, CFNA is deactivated: If a subscriber has both CFC and CFNA assigned, and CFC active and CFNA inactive, incoming calls on which the subscriber does not answer are forwarded by CFC.
•CFC and VM: If a subscriber has both CFC and voice mail (VM) assigned and active, and the subscriber is either busy or does not answer, the call is forwarded by CFC.
•CFC and VM, CFC deactivated: If a subscriber has both CFC and VM assigned but CFC is deactivated and VM is active, and the subscriber is either busy or does not answer, the call is terminated to VM.
•CFC and VMA: If a subscriber has both CFC and VMA assigned and active, the call is terminated to VM.
Note Voice Mail (VM) enables the subscriber to forward calls to voice mail when the subscriber is busy or does not answer the phone. Voice Mail Always (VMA) enables the subscriber to forward all calls to voice mail, regardless of the state of the phone.
Feature Provisioning Commands
To provision this feature, see the CFC provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Call Waiting Features
Call waiting features notify a called party, who is already on an active call, that another incoming call is being attempted on the line. The called party has the option of answering or ignoring the new incoming call. This section describes four call waiting features:
•Call Waiting (CW)
•Cancel Call Waiting (CCW)
•Calling Identity Delivery on Call Waiting (CIDCW)
•Call Waiting Deluxe (CWD)
Note CW, CCW, and CIDCW are typically bundled as an integral part of a service package.
Limitations
If your network uses an ISUP variant other than ANSI ISUP, the system supports CWD, but not CW or CIDCW.
Call Waiting (CW)
The BTS 10200 supports the call waiting (CW) feature as specified in LSSGR module FSD 01-02-1201 (TR-NWT-000571), Call Waiting.
CW informs a busy station that another call is waiting through the application of a 300 ms, 440 Hz tone. Ten seconds after the initial tone, a second tone is applied if the waiting call has not been answered. To answer the waiting call and place the original call on hold, the user presses the Flash button or hookswitch. A subsequent flash returns the user to the original call. Additional flashes can be used to toggle between the two calls as long as they are both still connected. The waiting call hears ringing until it is answered.
When a waiting call is accepted, there are two active sessions. To end the currently active session, the user goes on hook. The user's phone will then ring to indicate that the other caller is still holding. The user can pick up the phone to resume that session.
If a media gateway-connected handset is off hook, but no active call yet exists (that is, receiving a dial tone), then an incoming call receives a station busy tone and CW is not activated.
Only one instance of CW can be active for a given subscriber line at any given time. Thus, if a subscriber line were involved in both an active call and a waiting call, then an additional incoming call attempt results in the caller receiving a busy tone or being forwarded (CFB). The user involved in the CW call is not aware of the additional incoming call attempt.
Note For information on the CIDCW feature, see the "Calling Identity Delivery on Call Waiting (CIDCW)" section.
CW, CIDCW, and CWD interaction—CWD has a higher precedence than CIDCW, and CIDCW has a higher precedence than CW.
CW Activation
CW has multiple activation options as follows:
•Activated permanently at subscription time by service provider.
Tip When CW and CIDCW are first provisioned by the service provider, they are active immediately by default. To assign these features in the deactivated state, configure the subscriber-feature-data table for that subscriber to make CW and CIDCW deactivated.
•The feature can be activated by the individual user if the service provider has assigned the call waiting deluxe activation (CWDA) feature. The steps are as follows.
–The user lifts the handset, and listens for a dial tone.
–The user presses the activation VSC (for example, *58). If CW can be activated, the system returns a success announcement. An error announcement, indicating the type of error, is given if activation is unsuccessful.
Note If CW is already activated on this subscriber line, the activation attempt is accepted and processed as a new activation attempt.
–CW is now activated, and will stay active until it is deactivated (see "CW Deactivation" below).
CW Deactivation
CW deactivation options are as follows:
•Service provider deactivation at user request.
•The feature can be deactivated by the individual user if the service provider has assigned the call waiting deluxe deactivation (CWDD) feature. The steps are as follows.
–The user lifts the handset and listens for a dial tone.
–The user presses the deactivation VSC (for example, *59). A success announcement is given on a successful deactivation. An error announcement, indicating the type of error, is given if deactivation is unsuccessful.
Note If CW is already deactivated on this subscriber line, the deactivation attempt is accepted and processed as a new deactivation attempt.
–CW is now deactivated, and will stay inactive until it is activated (see "CW Activation" above).
CW Feature Interactions
•CFNA—If both CW and CFNA are subscribed to and activated by the user, the interaction is as follows. If the user is on an active call when a new call comes in, the CW (or CWD) tone will be played. If the user presses the Flash button or hookswitch before the CFNA timer runs out, the user will be connected to the new call, and the call will proceed according to the CW (or CWD) feature. If the user takes no action, and the CFNA timer runs out, the waiting call will be forwarded per the CFNA procedure.
Several provisionable parameters can affect the processing of this call.
–The CW timeout is based on a switch-wide parameter, NO-ANSWER-TMR in the ca-config table (default 185 seconds). There is also a parameter, START-NO-ANSWER-TMR in the ca-config table, to specify whether NO-ANSWER-TMR is to be started or not; default is N.
The CFNA timeout is provisioned via the TYPE1=TO parameter in the Feature table (default 30 seconds).
–If Subscriber A has the default timer settings (that is, CFNA TO=30 seconds and NO-ANSWER-TIMER=185 seconds), and has the START-NO-ANSWER-TMR parameter set to Y (not the default), the call is processed as follows:
[1] A calls B, B answers.
[2] C calls A, A hears the CW tone, C hears ring tone.
[3] If A does not attempt to answer the waiting call (C), and CFNA times out (30 seconds), C is forwarded according to normal CFNA procedures.
However, if the CFNA timeout (TO) is set to a value greater than NO-ANSWER-TMR, when NO-ANSWER-TMR expires, C is disconnected and hears a busy tone, and CFNA is cancelled.
•VM—If both CW and VM are subscribed to and activated by the user, the following scenarios apply. Several provisionable parameters can affect the processing of this call.
–The CW timeout is based on a switch-wide parameter, NO-ANSWER-TMR in the ca-config table (default 185 seconds). There is also a parameter, START-NO-ANSWER-TMR in the ca-config table, to specify whether NO-ANSWER-TMR is to be started or not; default is N.
The VM timeout is provisioned via the TYPE1=TO parameter in the Feature table (default 4 seconds).
–If Subscriber A has the default timer settings (that is, VM TO=4 seconds and NO-ANSWER-TIMER=185 seconds), and has the START-NO-ANSWER-TMR parameter set to Y (not the default), the call is processed as follows:
[1] A calls B, B answers.
[2] C calls A, A hears the CW tone, C hears ring tone.
[3] If A does not attempt to answer the waiting call (C), and VM times out (4 seconds), C is forwarded according to normal VM forwarding procedures.
However, if the VM timeout (TO) is set to a value greater than NO-ANSWER-TMR, when NO-ANSWER-TMR expires, C is disconnected and hears a busy tone, and VM is cancelled.
•If CHD is assigned to the subscriber along with CW, the following interaction occurs.
–A (the subscriber) and B are on an active call.
–C calls A.
–A hears the CW tone. (C hears ringback.)
–If A presses the Flash button or hookswitch, B is put on hold and A hears a dial tone.
–If A dials *52, A is connected to C.
–If A ignores the CW tone, C continues to hear ringback. The call is not forwarded.
•There is an interaction when a Centrex subscriber has all three of the following features assigned and active:
1. Call hold—CHD.
2. Call waiting—CW or CIDCW or both.
3. Call forwarding on no answer—CFNA, VM (or VMA), or any combination of these.
For information on this interaction, see the "CHD with CW/CIDCW and CFNA/VM/VMA" section.
Feature Provisioning Commands
Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.
Tip To provision this feature, see the CW provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Cancel Call Waiting (CCW)
The Cisco BTS 10200 Softswitch supports cancel call waiting (CCW) feature activation as specified in LSSGR module FSD 01-02-1204 (TR-TSY-000572), Cancel Call Waiting.
CCW allows a user to disable CW, which also disables the CIDCW feature for the duration of a call (see the "Calling Identity Delivery on Call Waiting (CIDCW)" section). CCW is normally included as an integral part of a service package containing the CW and CIDCW features. CCW is useful when the user does not want to be interrupted during an important call or during an outgoing data/fax call.
The user activates and deactivates the CCW feature as follows:
•To make an uninterrupted new call:
–The user lifts the handset, and listens for a dial tone.
–The user enters the CCW VSC (for example, *70). The system responds by disabling the CW/CIDCW features and returning three short beeps and then the dial tone.
–Now CCW is activated for the duration of the call, until the user goes on hook again.
–After the user goes on hook, the CW/CIDCW service will be back in effect automatically.
Note There are exceptions. If a user was involved in a multiparty call, and received a ringback after going on hook, CCW remains active for the call.
•To make a currently active call go uninterrupted:
–The user presses Flash button or hookswitch
–The user enters the CCW VSC (for example, *70). The system responds by disabling the CW/CIDCW features and returning three short beeps and then the dial tone.
–Now CCW is activated for the remainder of the current call, until the user goes on hook again.
–The user presses Flash button or hookswitch to return to the original call.
After the current call is completely released, the CW service will be back in effect automatically.
Note If there is a CA switchover during an active call with CCW invoked, CCW will not be supported on that call after the switchover.
Tip To provision this feature, see the CCW provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Calling Identity Delivery on Call Waiting (CIDCW)
The BTS 10200 supports the calling identity delivery on call waiting (CIDCW) feature as specified in LSSGR module FSD 01-02-1090 (TR-TSY-000575), Calling Identity Delivery on Call Waiting.
CIDCW is a service that enables a called party to receive information about a calling party on a waiting call while off hook on an existing call. CIDCW provides the capability of calling identity delivery (CID) information to the called party on waiting calls. CIDCW is considered an enhancement of the CW feature, and requires the basic CW feature, along with the CND or CNAM feature.
Tip When CW and CIDCW are first provisioned by the service provider, they are active immediately by default. To assign these features in the deactivated state, configure the subscriber-feature-data table for that subscriber to make CW and CIDCW deactivated.
When a called party has been alerted of an incoming call, the called party places the current far-end party on hold by pressing the Flash button or hookswitch to retrieve the waiting call. the Flash button or hookswitch can be used to toggle between the current far-end party and the held party. The details of these functions are as follows:
•A called party currently on a call receives notification, via a short beep repeated 3 times, that another call is coming in.
•The incoming name and/or number is displayed after the first beep.
•The called party can either ignore the new call or can accept it while putting the existing call on hold.
•To ignore the new call, the called party continues uninterrupted on the existing call, and the beep indication will time out after 3 repetitions.
•To accept the new call and put the existing call on hold, the called party presses and releases the Flash button or hookswitch.
•To alternate between the two calls, the called party can press and release the Flash button or hookswitch.
•If either one of the remote stations goes on hook, the remaining remote station continues as a normal session with the called party.
•The called party can end either session by going on hook during the currently active session. This ends the session. The phone will ring to indicate that the other party is still holding. The called party can pick up the phone and the session to that calling party resumes as a normal call.
If the calling party's caller ID is not available (for example, if the caller has blocked caller ID) then the called party's caller ID display will indicate an anonymous call or other unidentified caller message as in the caller ID feature.
CIDCW Activation
CIDCW has multiple activation options as follows:
•Activated permanently at subscription time by service provider.
Tip When CW and CIDCW are first provisioned by the service provider, they are active immediately by default. To assign these features in the deactivated state, configure the subscriber-feature-data table for that subscriber to make CW and CIDCW deactivated.
•The feature can be activated by the individual user if the service provider has assigned the call waiting deluxe activation (CWDA) feature. The steps are as follows.
–The user lifts the handset, and listens for a dial tone.
–The user presses the activation VSC (for example, *58). If CIDCW can be activated, the system returns a success announcement. An error announcement, indicating the type of error, is given if activation is unsuccessful.
Note If CIDCW is already activated on this subscriber line, the activation attempt is accepted and processed as a new activation attempt.
–CIDCW is now activated, and will stay active until it is deactivated (see "CIDCW Deactivation" below).
CIDCW Deactivation
CIDCW deactivation options are as follows:
•Service provider deactivation at user request.
•The feature can be deactivated by the individual user if the service provider has assigned the call waiting deluxe deactivation (CWDD) feature. The steps are as follows.
–The user lifts the handset and listens for a dial tone.
–The user presses the deactivation VSC (for example, *59). A success announcement is given on a successful deactivation. An error announcement, indicating the type of error, is given if deactivation is unsuccessful.
Note If CIDCW is already deactivated on this subscriber line, the deactivation attempt is accepted and processed as a new deactivation attempt.
–CIDCW is now deactivated, and will stay inactive until it is activated (see "CIDCW Activation" above).
CIDCW Feature Interactions
•CW, CIDCW, and CWD interaction—CWD has a higher precedence than CIDCW, and CIDCW has a higher precedence than CW.
•There is an interaction when a Centrex subscriber has all three of the following features assigned and active:
1. Call hold—CHD.
2. Call waiting—CW or CIDCW or both.
3. Call forwarding on no answer—CFNA, VM (or VMA), or any combination of these.
For information on this interaction, see the "CHD with CW/CIDCW and CFNA/VM/VMA" section.
Feature Provisioning Commands
Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.
Tip To provision this feature, see the CIDCW provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Call Waiting Deluxe (CWD)
CWD service informs a busy phone (user on an active call) that another call is waiting through the application of a call-waiting tone. Ten seconds after the initial tone, a second tone is applied if the waiting call has not been answered. To process the waiting call, the called party can take one of the following actions:
•The called party can go on hook to disconnect from the active call. The system will ring the called party, and the called party can take the phone off hook to be connected to the waiting call.
•To process the waiting call, the called party can press the Flash button or hookswitch. The system places the remote party on hold and provides a recall (stutter) dial tone to the called party. After receiving the recall dial tone, the called party can take one of the following actions:
–If the called party presses digit 1, the active call is dropped and a voice connection is established with the waiting party.
–If the called party presses the digit 2, a voice connection is established with the waiting party. From this point the called party can press the Flash button or hookswitch, receive recall dial tone, and press 2 to alternate between the parties.
While on a CWD call with the other two parties, the called party can exercise the following additional options after pressing the Flash button or hookswitch and receiving recall dial tone:
•If the called party presses digit 3 instead of 2, all three parties are conferenced together, and the call proceeds as in the three-way calling deluxe (TWCD) feature. (For more information on this call behavior, see the "Three-Way Calling Deluxe (TWCD)" section.)
•If the called party presses digit 1 instead of 2, the active call is dropped and a voice connection is established with the waiting party.
•If the called party goes on hook to disconnect from the active call, the system will ring the called party. The called party can take the phone off hook to be connected to the waiting call.
Note If a MGW-connected handset is off hook, but no active call exists (that is, receiving a dial tone), then an incoming call receives a busy tone and CWD is not activated.
Only one instance of CWD can be active for a given subscriber line at any given time. Thus, if a subscriber line were involved in both an active call and a waiting call, then an additional incoming call attempt results in the caller receiving a busy tone or being forwarded (CFB). The called party involved in the CWD call is not aware of the additional incoming call attempt.
The following conditions apply to the CWD feature:
•The CWD feature can be provided to POTS, Centrex, and MLHG subscribers.
•The CWD feature is in the deactivated mode unless activated by the subscriber.
The CWD feature is composed of four associated features, which are described in the sections that follow:
•CWD Activation
•CWD Deactivation
•CWD Interrogation
•CWD Invocation
CWD Timers
There are three timers that apply to the CWD feature:
•Call-waiting timeout timer (TO), measured in seconds—This is the time that an incoming call can be held in call-waiting mode. After the timer expires, the waiting call is disconnected. The default value is 15.
•Feature reconnect timer (FEATURE-RECONNECT-TMR), measured in seconds—During the course of using the CWD feature, if the subscriber is connected to a reorder tone or announcement, the subscriber is automatically reconnected to the previous call leg after the specified FEATURE-RECONNECT-TMR timeout period. The default value is 10.
•Reconnect timer (RECONNECT-TMR), measured in seconds—When a subscriber hangs up with another call on hold, the subscriber is rung back. The ringing is applied for the duration of this RECONNECT-TMR. If the subscriber does not answer the call within this time period, the call is torn down. The default value can be provisioned in the CA-CONFIG table. If the timer is not provisioned in the CA-CONFIG table, the preset value 36 is used as default.
CWD Activation
CWD has multiple activation options as follows:
•Activated permanently at subscription time by service provider.
•Activated by user:
–The user lifts the handset, and listens for a dial tone.
–The user presses the activation VSC (for example, *58 in North America and *58# in China). If CWD can be activated, the system returns a success announcement. An error announcement, indicating the type of error, is given if activation is unsuccessful.
–CWD is now activated, and will stay active until it is deactivated (see "CWD Deactivation" below).
CWD Deactivation
CWD deactivation options are as follows:
•Service provider deactivation at user request.
•Deactivated by user:
–The user lifts the handset and listens for a dial tone.
–The user presses the deactivation VSC (for example, *59 in North America and #58# in China). A success announcement is given on a successful deactivation. An error announcement, indicating the type of error, is given if deactivation is unsuccessful.
–CWD is now deactivated, and will stay inactive until it is activated (see "CWD Activation" above).
CWD Interrogation
CWD interrogation allows a user to check whether CWD is activated on his or her local phone. The user enters the VSC for CWD interrogation (for example, *56 in North America and *#58#* in China). A success announcement is given to the user if CWD is activated, and an appropriate announcement is provided if it is deactivated.
CWD Invocation
CWD invocation is the actual set of procedures the system follows when a user (with CWD activated) is already on an active call and receives a call from a third party.
Invalid User Actions
The valid user actions are described in the sections above. The following user actions are invalid, and the system provides an appropriate error announcement:
•The user tries to interrogate CWD on a fresh system (a system with no entry in the SUBSCRIBER-FEATURE-DATA table).
•The user presses the Flash button or hookswitch, receives recall dial tone, and then enters a digit other than 1, 2, or 3.
CWD Feature Interactions
CWD and CFNA Interaction—If both CFNA and CWD are subscribed to and activated by the user, the interaction is as follows. If the user is on an active call when a new call comes in, the CWD tone will be played. The CWD feature does not perform any timing in this case (that is, CWD does not start the call-waiting disconnect timer). If the user presses the hookswitch before the CFNA timer runs out, the user will be connected to the new call, and the call will proceed according to the CWD feature. If the user takes no action, and the CFNA timer runs out, the waiting call will be forwarded per the CFNA procedure.
CWD and CFB Interaction—If both CWD and CFB are activated, CWD has higher precedence than CFB.
CWD and TWCD Interaction—These two feature invocations are mutually exclusive. When one feature is invoked, the other feature is not allowed.
Note During a three-way call, the CWD feature does not work for the party that initiated the three-way call. However, the CWD feature would work normally for the other two (non-initiating) parties.
CWD and CLIP interaction—If the called user is given a call waiting indication, and has subscribed to the CLIP service, then the calling line identification is presented to the user at the time the call waiting indication is given.
CWD, CIDCW, CW Interaction—CWD has a higher precedence than CIDCW, and CIDCW has a higher precedence than CW.
CWD and CCW Interaction—When CCW is activated, CWD will be inhibited. (Note that CCW is a per-call activated feature.)
CWD and DRCW Interaction—If the calling party number is in the DRCW list of the called party, and if DRCW is activated, the called party is given a distinctive call-waiting indication. Otherwise, the regular call-waiting indication is given.
CWD and DACWI Interaction for a CENTREX subscriber—If the DACWI feature is assigned to the called party (CENTREX subscriber), and the incoming call is from outside the CENTREX group, the called party is given a distinctive call-waiting indication. Otherwise, the regular call-waiting indication is given.
CWD and MDN Interaction—If the calling party dials the called party number different from main number, the called party is given a distinctive call-waiting indication. Otherwise, the regular call waiting indication is given.
CWD and DACWI Interaction—If this is a direct inward dialing (DID) call and DACWI feature is assigned, the called party is given a distinctive call-waiting indication. Otherwise, a regular call-waiting indication is given.
Feature Provisioning Commands
Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.
Tip To provision this feature, see the CWD provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Calling Identity Features
Calling identity features include:
•Calling Identity Delivery
–Calling Number Delivery (CND)
–Calling Name Delivery (CNAM)
•Calling Line Identification Presentation (CLIP)
•Calling Identity Delivery Blocking (CIDB)
–Calling Number Delivery Blocking (CNDB)
–Calling Name Delivery Blocking (CNAB)
–Calling Identity Delivery and Suppression (CIDSD and CIDSS)
•Calling Line Identification Restriction (CLIR)
–Calling Number Delivery Blocking (CNDB)
–Calling Name Delivery Blocking (CNAB)
–Calling Identity Delivery and Suppression (CIDSD and CIDSS)
Note The calling identity delivery on call waiting (CIDCW) feature is described in the "Call Waiting Features" section.
Calling Identity Delivery
The identity of the caller is provided in two features, calling number delivery (CND) and calling name delivery (CNAM), as described in the following sections.
Calling Number Delivery (CND)
The BTS 10200 supports the CND feature as specified in the Telcordia LSSGR module FSD 01-02-1051 (TR-NWT-000031), Calling Number Delivery, and GR-30-CORE, Voiceband Data Transmission Interface.
The CND feature provides CPE with the date, time, and DN of an incoming call. When the called subscriber line is on hook, the calling party information is delivered during the long silent interval of the first ringing cycle. Telcordia document GR-30-CORE specifies the generic requirements for transmitting asynchronous voice band data to the CPE.
Tip To provision this feature, see the CND provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Calling Name Delivery (CNAM)
The BTS 10200 supports the CNAM feature as specified in LSSGR module FSD 01-02-1070 (TR-TSY-001188), Calling Name Delivery Generic Requirements.
CNAM is a terminating user feature allowing CPE connected to a switching system to receive a calling party's name, number, and the date and time of the call during the first silent interval. If a private status is assigned with the name, the name will not be delivered and a private indicator code P is sent to the CPE. If the name is not available for delivery, the switch sends an out-of-area/unavailable code O to the CPE. When transferring or forwarding calls internally, the private calling name can be obtained from the Cisco BTS 10200 Softswitch databases and passed on to the internal called user.
Tip To provision this feature, see the CNAM provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Calling Line Identification Presentation (CLIP)
This section describes the calling line identification presentation (CLIP) feature. This feature is available to POTS, Centrex, and MLHG subscribers.
References:
•Telcordia LSSGR, CLASS Feature: Calling Number Delivery, GR-31-CORE
•ITU-T: I.251.3 (08/92) Calling Line Identification Presentation
CLIP Feature Description
CLIP is a supplementary service offered to the called party that displays the calling party DN and the date and time of the call. The calling line identification information is included in the incoming message (for example, SETUP, IAM, R2 digits, SIP, and so forth) from the originating DN. Interoffice application of this service depends on network deployment of signaling methods capable of transmitting the calling line identification.
The Cisco BTS 10200 Softswitch supports this feature for the following types of incoming calls:
•Intraoffice calls—Calls that originate and terminate on lines supported by one Cisco BTS 10200 Softswitch. (The calling party's DN is retrieved from the Cisco BTS 10200 Softswitch memory.)
•Incoming interoffice calls from another Cisco BTS 10200 Softswitch on the packet network.
•Incoming interoffice calls from another stored program controlled switch (SPCS) on the packet network or the connection-oriented network.
The calling party's information can be public, private, or unavailable:
•Public—If the calling line identification information is included in the message from the originating DN, and is not blocked, the Cisco BTS 10200 Softswitch displays it on the called party's display.
•Private (anonymous)—If the calling line DN has been marked to indicate that it is private, the Cisco BTS 10200 Softswitch does not transmit the DN to the called party. Instead, it sends the date, time, and a private indicator, signified by the ASCII letter "P", to the called party in place of the calling line DN.
•Unavailable—If the calling line identification information is not available, the Cisco BTS 10200 Softswitch displays an out-of-area/DN-unavailable indicator, signified by the ASCII letter "O", along with the date and time.
CLIP Feature Activation and Deactivation
CLIP is offered to users on a subscription basis. Once the feature has been successfully assigned, the called party should receive the date, time, and calling number, if available and allowed to be disclosed, for all subsequent incoming calls. If the called party does not subscribe to this feature, the calling party's identity information is not transmitted to the called party's handset.
CLIP Feature Interactions
CFU—When CLIP is subscribed and the user activates CFU, all incoming calls are forwarded at the base phone, and the Cisco BTS 10200 Softswitch forwards the original calling DN to the remote phone.
CFNA—When CLIP is subscribed and the user activates CFNA, all unanswered incoming calls are forwarded at the base phone, and the Cisco BTS 10200 Softswitch forwards the original calling DN to the remote phone.
CFB—When CLIP is subscribed and the user activates CFB, incoming calls are forwarded when the base phone is off hook, and the Cisco BTS 10200 Softswitch forwards the original calling DN to the remote phone.
CLIR—There are no interactions between CLIP and CLIR when active on the same line. Indirect interactions occur between CLIP and CLIR when the calling party subscribes to CLIR and the called party subscribes to CLIP. If the calling party uses any of the CLIR features to make the status of the calling DN private, the terminating SPCS (Cisco BTS 10200 Softswitch) transmits a "P" (indicating private status) to the terminating phone.
CWD—If the called user is given a call waiting indication, and has subscribed to the CLIP service, then the calling line identification is presented to the user at the time the call waiting indication is given.
Feature Provisioning Commands
Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.
Tip To provision this feature, see the CLIP provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Calling Identity Delivery Blocking (CIDB)
The Cisco BTS 10200 Softswitch supports calling identity delivery blocking (CIDB) features as specified in LSSGR module FSD 01-02-1053 (TR-NWT-000391), Calling Identity Delivery Blocking Features
CIDB allows caller to control whether or not their calling identity information is delivered with outgoing calls. Identity includes directory number (DN) and/or name of the caller. CIDB does not affect the presentation of caller's information when making 911 calls.
The CIDB feature affects the presentation status (PS) of the calling identity information. The PS is a flag that lets the network know if it is permissible to deliver the information to the called party. Both the calling number and calling name have PS information associated with them. There are two types of PS flags—permanent and per-call:
•Permanent PS (PPS)—The service provider provisions PPS flags, either public or private, for each subscriber line. These values are defined as follows:
–Public—Calling identity information (calling name and/or calling number) is delivered with outgoing calls. The local switch (BTS 10200) informs the remote switch that it is permissible to deliver the caller's identity information on the remote phone.
–Private (anonymous)—Calling identity information (calling name and/or calling number) is not delivered with outgoing calls. The local switch (BTS 10200) informs the remote switch that it is not permissible to deliver the caller's identity information on the remote phone.
•Per-call PS (PCPS) has significance only to the current outgoing call. On a per-call basis, a caller with the CIDB feature enabled can override the default values for the PS flags. The per-call features are listed in Table 3-7 and described in the "Calling Number Delivery Blocking (CNDB)" section through the "Calling Identity Delivery and Suppression (CIDSD and CIDSS)" section.
Note The vertical service codes (VSCs), also called star codes, listed in Table 3-7 and throughout this section are typical values. The service provider can provision these values with any valid unique ASCII string up to five characters long. For a complete list of valid VSC formats and preprovisioned VSCs, see the VSC table in the Cisco BTS 10200 Softswitch CLI Database.
Table 3-7 Per-Call CIDB Feature Summary
Identity Item
|
Permanent Privacy Status (PPS)
|
Effect Of CNDB (*67)
|
Effect Of CNAB (*95)
|
Effect Of CIDSD (*82)
|
Effect Of CIDSS (*96)
|
Number
|
Name
|
Number PS
|
Name
PS
|
Number PS
|
Name
PS
|
Number PS
|
Name
PS
|
Number PS
|
Name
PS
|
Identity:
Number [CND]
+
Name [CNAM]
|
Public
|
Public
|
Private
|
Private1
|
Public
|
Private
|
Public
|
Public
|
Private
|
Private
|
Public
|
Private
|
Private
|
Private
|
Public
|
Public
|
Public
|
Public
|
Private
|
Private
|
Private
|
Public1
|
Public
|
Public
|
Private
|
Private
|
Public
|
Public
|
Private
|
Private
|
Private
|
Private
|
Public
|
Private
|
Private
|
Private1
|
Public
|
Public
|
Private
|
Private
|
Number:
[CND] only
|
Public
|
n/a
|
Private
|
n/a
|
n/a
|
n/a
|
Public
|
n/a
|
Private
|
n/a
|
Private
|
n/a
|
Public
|
n/a
|
n/a
|
n/a
|
Public
|
n/a
|
Private
|
n/a
|
When a caller goes off hook and does not enter a per-call CIDB code that affect the caller's PS, then the value of the caller's PPS is used as the presentation status for that call. When a CIDB per-call feature is used on a call, only the current call is affected. The PPS is used for future calls (unless the caller enters one of the per-call features again.)
Calling Number Delivery Blocking (CNDB)
Calling number delivery blocking (CNDB) allows the caller to control the status of their caller number privacy on a per-call basis. For all new calls, the privacy status reverts back to the PPS.
To use the CNDB feature, the caller does the following:
•The caller goes off hook and receives a dial tone.
•The caller enters the CNDB VSC (for example, *67). The system responds with a dial tone.
•The caller enters the desired phone number for the remote station. The CNDB function toggles the PPS of the caller's number for this call:
–If the PPS is private, CNDB makes the PS public for this call
–If the PPS is public, CNDB makes the PS private for this call
Note When the number is private, no name query is performed.
Tip To provision this feature, see the CNDB provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Calling Name Delivery Blocking (CNAB)
Calling name delivery blocking (CNAB) allows the caller to control the status of their caller name privacy on a per-call basis. For all new calls, the privacy status reverts back to the PPS.
To use the CNAB feature, the caller does the following:
•The caller goes off hook and receives a dial tone.
•The caller enters the CNAB VSC (for example, *95). The system responds with a dial tone.
•The caller enters the desired phone number for the remote station. The CNAB function toggles the PPS of the caller's name for this call:
–If the PPS is private, CNAB makes the PS public for this call
–If the PPS is public, CNAB makes the PS private for this call
Note When the number is private, no name query is performed.
Note The CNAB feature is not supported over SIP trunks.
Tip To provision this feature, see the CNAB provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Calling Identity Delivery and Suppression (CIDSD and CIDSS)
The BTS 10200 supports the delivery function and the suppression function of calling identity delivery and suppression (CIDSD and CIDSS, respectively). CIDSD and CIDSS are per-call features.
CIDSD and CIDSS allow a caller to explicitly indicate on a per-call basis whether both the calling name and calling number will be treated as private or public. When CIDSD or CIDSS is used, the system does not query the PPS of the caller's DN and name. The following conditions apply:
•CIDS Delivery (CIDSD)—If the caller enters the VSC for CIDSD (for example, *82), the current call is treated as public regardless of the default privacy status permanently associated with the calling name and number.
•CIDS Suppression (CIDSS)—If the caller enters the VSC for CIDSS (for example, *96), the current call is treated as private regardless of the default privacy status permanently associated with the calling name and number.
For all new calls, the privacy status reverts back to the PPS.
To use the CIDSD or CIDSS feature, the caller does the following:
•The caller goes off hook and receives a dial tone.
•The caller enters the VSC for CIDSD or CIDSS (for example, *82 or *96) and receives a dial tone again.
•The caller enters the desired phone number for the remote phone.
•The caller's ID will be displayed or blocked as follows:
–For *82, the caller's ID will be delivered (that is, it will not be blocked) at the remote station, assuming the remote station has the caller ID function.
–For *96, the caller's ID will be blocked at the remote station, assuming the remote station has the caller ID function.
The next time this caller makes a phone call, the default caller ID settings (PPS) will apply, unless the caller again enters the VSC for CIDSD or CIDSS.
Tip To provision these features, see the CIDSD and CIDSS provisioning procedures in the Cisco BTS 10200 Softswitch Provisioning Guide.
Calling Line Identification Restriction (CLIR)
This section describes the calling line identification restriction (CLIR) feature. This feature is available to POTS, Centrex, and MLHG subscribers.
References:
•Telcordia LSSGR, CLASS Feature: Calling Identity Delivery Blocking Features, GR-391-CORE
•ITU-T: I.251.4 (08/92) Calling Line Identification Restriction
CLIR is a supplementary service that allows callers to control whether or not their calling identity information is delivered with outgoing calls. Identity includes directory number (DN) and/or name of the caller. The presentation of calling identity information (at the terminating phone) is described in the "Calling Line Identification Presentation (CLIP)" section.
When provisioned by the service provider, the calling party can restrict the display of his or her DN on either a permanent basis or a per-call basis. The CLIR feature consists of the following per-call associated features:
•Calling Number Delivery Blocking (CNDB)
•Calling Name Delivery Blocking (CNAB)
•Calling Identity Delivery and Suppression (CIDSD and CIDSS)
Calling Identity Presentation Status
The CLIR feature affects the presentation status (PS) of the calling identity information. The PS is a flag that lets the network know if it is permissible to deliver the information to the called party. Both the calling number and calling name have PS information associated with them. There are two types of PS flags—permanent and per-call:
•Permanent PS (PPS)—The service provider provisions PPS flags, either public or private, for each subscriber line. These values are defined as follows:
–Public—Calling identity information (calling name and/or calling number) is delivered with outgoing calls. The local SPCS (Cisco BTS 10200 Softswitch) informs the remote SPCS that it is permissible to deliver the caller's identity information to the remote phone.
–Private (anonymous)—Calling identity information (calling name and/or calling number) is not delivered with outgoing calls. The local SPCS (Cisco BTS 10200 Softswitch) informs the remote SPCS that it is not permissible to deliver the caller's identity information to the remote phone.
•Per-call PS (PCPS) has significance only to the current outgoing call. On a per-call basis, a caller with the CLIR feature enabled can override the default values for the PS flags. The per-call features are listed in Table 3-8 and described in the "Calling Number Delivery Blocking (CNDB)" section through the "Calling Identity Delivery and Suppression (CIDSD and CIDSS)" section.
Note The vertical service codes (VSCs), also called star codes, listed in Table 3-8 and throughout this section are typical values. The service provider can provision these values with any valid unique ASCII string up to five characters long. For a complete list of valid VSC formats and preprovisioned VSCs, see the VSC table specification and VSC appendix in the Cisco BTS 10200 Softswitch CLI Database.
Table 3-8 Per-Call CLIR Feature Summary
Identity Item
|
Permanent Privacy Status (PPS)
|
Effect Of CNDB (*67*)
|
Effect Of CNAB (*95*)
|
Effect Of CIDSD (*82*)
|
Effect Of CIDSS (*96*)
|
Number
|
Name
|
Number PS
|
Name
PS
|
Number PS
|
Name
PS
|
Number PS
|
Name
PS
|
Number PS
|
Name
PS
|
Identity:
Number [CND]
+
Name [CNAM]
|
Public
|
Public
|
Private
|
Private1
|
Public
|
Private
|
Public
|
Public
|
Private
|
Private
|
Public
|
Private
|
Private
|
Private
|
Public
|
Public
|
Public
|
Public
|
Private
|
Private
|
Private
|
Public1
|
Public
|
Public
|
Private
|
Private
|
Public
|
Public
|
Private
|
Private
|
Private
|
Private
|
Public
|
Private
|
Private
|
Private1
|
Public
|
Public
|
Private
|
Private
|
Number:
[CND] only
|
Public
|
n/a
|
Private
|
n/a
|
n/a
|
n/a
|
Public
|
n/a
|
Private
|
n/a
|
Private
|
n/a
|
Public
|
n/a
|
n/a
|
n/a
|
Public
|
n/a
|
Private
|
n/a
|
When a caller goes off hook and does not enter a per-call CLIR code that affect the caller's PS, then the value of the caller's PPS is used as the presentation status for that call. When a CLIR per-call feature is used on a call, only the current call is affected. The PPS is used for future calls (unless the caller enters one of the per-call features again.)
Calling Number Delivery Blocking (CNDB)
The CNDB associated feature affects the PS designation of the caller's DN. CNDB works as follows:
•The caller goes off hook and receives dial tone.
•The caller enters the CNDB VSC (for example, *67*). The system responds with a dial tone.
•The caller enters the desired phone number for the remote phone. The local switch (Cisco BTS 10200 Softswitch) retrieves the PPS value of the DN for the caller's line, and then forwards the opposite of the PS value to the remote switch. Therefore:
–If the PPS of the DN is public, the Cisco BTS 10200 Softswitch sends a PCPS of private.
–If the PPS of the DN is private, the Cisco BTS 10200 Softswitch sends a PCPS of public.
Note When the number is private, no name query is performed.
Tip To provision this feature, see the CNDB provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Calling Name Delivery Blocking (CNAB)
The CNAB associated feature affects the PS designation of the caller's name. CNAB works as follows:
•The caller goes off hook and receives dial tone.
•The caller enters the CNAB VSC (for example, *95*). The system responds with a dial tone.
•The caller enters the desired phone number for the remote phone. The local switch (Cisco BTS 10200 Softswitch) retrieves the PPS value of the name for the caller's line, and then forwards the opposite of the PS value to the remote switch. Therefore:
–If the PPS of the name is public, the Cisco BTS 10200 Softswitch sends a PCPS of private.
–If the PPS of the name is private, the Cisco BTS 10200 Softswitch sends a PCPS of public.
Note When the number is private, no name query is performed.
Note The CNAB feature is not supported over SIP trunks.
Tip To provision this feature, see the CNAB provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Calling Identity Delivery and Suppression (CIDSD and CIDSS)
The BTS 10200 supports the delivery function and the suppression function of calling identity delivery and suppression (CIDSD and CIDSS, respectively). CIDSD and CIDSS are per-call features.
CIDSD and CIDSS allow a caller to explicitly indicate on a per-call basis whether both the calling name and calling number will be treated as private or public. When CIDSD or CIDSS is used, the system does not query the PPS of the caller's DN and name. The following conditions apply:
•CIDS Delivery (CIDSD)—If the caller enters the VSC for CIDSD (for example, *82*), the current call is treated as public regardless of the default privacy status permanently associated with the calling name and number.
•CIDS Suppression (CIDSS)—If the caller enters the VSC for CIDSS (for example, *96*), the current call is treated as private regardless of the default privacy status permanently associated with the calling name and number.
For all new calls, the privacy status reverts back to the PPS.
To use the CIDSD or CIDSS feature, the caller does the following:
•The caller goes off hook and receives a dial tone.
•The caller enters the VSC for CIDSD or CIDSS (for example, *82* or *96*) and receives a dial tone again.
•The caller enters the desired phone number. for the remote phone
•The caller's ID will be displayed or blocked as follows:
–For *82*, the caller's ID will be delivered (that is, it will not be blocked) at the remote station, assuming the remote station has the caller ID function.
–For *96*, the caller's ID will be blocked at the remote station, assuming the remote station has the caller ID function.
The next time this caller makes a phone call, the default caller ID settings (PPS) will apply, unless the caller again enters the VSC for CIDSD or CIDSS.
Tip To provision these features, see the CIDSD and CIDSS provisioning procedures in the Cisco BTS 10200 Softswitch Provisioning Guide.
CLIR Feature Interactions
CLIP—There are no interactions between CLIP and CLIR when active on the same line. Interactions occur between CLIP and CLIR when the calling party subscribes CLIR and the called party subscribes to CLIP. If the calling party uses any of the CLIR features to make the status of the calling DN private, the terminating SPCS (Cisco BTS 10200 Softswitch) transmits a "P" (indicating private status) to the terminating phone.
TWCD—A user with TWCD can press the Flash button or hookswitch and use any of the CLIR per-call restrictions before dialing the next phone number. This allows the user to control the presentation of his or her PS to the third party in the three-way call.
Feature Provisioning Commands
Provisioning commands are available in the Cisco BTS 10200 Softswitch Provisioning Guide.
Tip To provision this feature, see the CLIR provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Direct Inward/Outward Dialing for PBX
The Cisco BTS 10200 Softswitch supports the direct inward dialing (DID) and direct outward dialing (DOD) features for PBX.
Analog DID for PBX
The Cisco BTS 10200 Softswitch supports analog DID for PBX as specified in TIA/EIA-464B, Requirements for Private Branch Exchange (PBX) Switching Equipment, April 1, 1996.
The analog DID one-way feature allows incoming calls to a local PBX network to complete to a specific station without attendant assistance. The station address is provided by the CA that controls an access gateway (AGW) connecting to the PBX. The number of digits to be outpulsed by the AGW to the PBX is configurable in the CA.
Note For guidance in provisioning the CA to support this feature, see the Cisco BTS 10200 Softswitch Operations Manual.
Figure 3-1 shows a typical application, with a residential user (UserA) attempting to call a PBX user station (UserB). UserB is identified by a specific set of extension digits in the PBX. The Cisco BTS 10200 Softswitch uses MGCP signaling to communicate with the AGW, and controls the outpulsing of digits from the AGW to the PBX. A foreign exchange office (FXO) board in the AGW uses reverse battery signaling (per TIA/EIA-464B) to communicate with a DID trunk board in the PBX over an analog DID one-way trunk. When completing a call termination to the PBX, the extension digits for UserB are outpulsed from the AGW toward the PBX. The PBX receives the extension digits and then completes the call to UserB.
Figure 3-1 Example of PBX Analog DID One-Way Application
Tip To provision PBX-DID subscribers, you must use the proper settings in the DN to Subscriber (dn2subscriber) and Subscriber (subscriber) tables. See the IAD Subscriber provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
DOD For PBX
Reference: LSSGR module FSD 04-02-0000 (TR-TSY-000524), Direct Inward Dialing.
The DOD feature allows outgoing calls from a specific station to be completed through the local PBX network without attendant assistance. The CA serving the PBX recognizes the station address and routes the call to the PBX.
Hostage Negotiation
If a BTS 10200 subscriber is involved in a hostage situation, you can provision the hostage negotiation (HN) feature for this subscriber, and this allows the hostage subscriber to make immediate contact with the Law Enforcement Authority (LEA). The feature restricts incoming calls to and outgoing calls from the subscriber hostage. Regardless of the directory number (DN) the hostage subscriber dials, outgoing calls terminate at the hostage-outbound-dn you provision for this subscriber, and this connects the hostage subscriber directly to the LEA.
The HN feature addresses the special problems of hostage negotiation by
•Allowing a subscriber to be defined as a hostage subscriber so calls can receive special handling.
•Restricting incoming and outgoing calls as required by the LEA.
•Restricting certain features which would impede the LEA from effectively handling the hostage situation. (Certain features, such as Selective Call Acceptance [SCA] and Anonymous Call Rejection [ACR], have the potential to impede LEA efforts to contact the hostage.)
Feature Description
The BTS 10200 allows only those inbound calls that originate from a preassigned set of numbers to terminate to the hostage subscriber. The BTS 10200 forwards all inbound calls that you do not specify in the Hostage Negotiation-Selective Call Acceptance (HN-SCA) list to HN-FWD-DN, which is a preassigned LEA number. If you do not specify a value for HN-FWD-DN, the BTS 10200 provides the caller with a busy signal and releases the call. The system supports up to five entries in the HN-SCA list.
The BTS 10200 impedes features that can interrupt the hostage negotiation process, such as SCA and ACR.
Centrex Subscribers
The HN feature does not restrict the Custom Dial Plan (CDP) feature, therefore any hostage subscriber can have an extension or associated Centrex group code as HN-OUTBOUND-DN and HN-FWD-DN. This ensures that the BTS 10200 routes the call from the subscriber hostage within the Centrex group or outside the Centrex group as appropriate.
You can enter an extension, POTS-access, or attendant number as the value for HN-OUTBOUND-DN and HN-FWD-DN. However, you must enter a 10-digit number as the HN-SCA-DN value.
Multiline Hunt Groups
You cannot apply the feature to an entire multiline hung group (MLHG), but you can apply it to individual group members. If there is a hostage situation, the feature impedes hunting for the MLHG subscriber. If a hostage subscriber is busy with any type of call, the BTS 10200 attempts to match any incoming calls to the HN-SCA-LIST. If the system does not find a match for such a call, it forwards the call to HN-FWD-DN.
Feature Interactions
The HN feature is the highest-priority feature in the BTS 10200 unless you give an external feature in the FIM/XML file a higher priority. If you do that, the hostage negotiation feature will no longer work and the subscriber may be able to make regular outgoing calls and receive incoming calls.
The BTS 10200 inhibits all features, both originating and terminating, including 9-1-1, for the hostage subscriber, except call detail block (CDB) generation for billing records. If you provision HN-OUTBOUND-DN or HN-FWD-DN 9-1-1, the BTS 10200 routes the call to the preassigned LEA number.
Restrictions and Limitations
You cannot provision a ported-out subscriber as a hostage subscriber on the BTS 10200, although you can provision HN-OUTBOUND-DN and HN-FWD-DN as ported out numbers.
Cause Codes
The following cause codes are associated with the Hostage Negotiations LEA feature:
•HN_FWD_DN_NOT_PROVISIONED
•HN_OUTBOUND_DN_NOT_PROVISIONED
Multiline Hunt Group (MLHG)
The BTS 10200 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, the system performs a hunt for an idle line; the hunting sequence is provisionable as described in this section.
Reference: LSSGR module FSD 01-02-0802 (GR-569-CORE), Multiline Hunt Service.
Note The MLHG feature is supported for MGCP, NCS, and SIP subscribers, and an MLHG can have a combination of MGCP, NCS, and SIP subscribers.
This section covers the following MLHG topics:
•Hunting Sequence
•Assigning and Activating MLHG Features
•MLHG Provisioning Options and Use Cases
•Terminal Make Busy and Group Make Busy Features
•Special Hunting Treatment for SIP Subscribers
•Treatment of Outbound Call Features
•Treatment of Inbound Call Features
•Billing for MLHG
•Basic Provisioning Procedure and CLI Reference
Hunting Sequence
The system hunts for an idle line by means of a defined search sequence. The sequence is specified by the provisioning of the hunt-type parameter in the MLHG table—regular, circular, or uniform call distribution (UCD). The system also supports preferential hunt lists.
The starting point for the hunt depends upon whether the incoming call is being routed to the group or to the individual. These scenarios are described in the following sections:
•Incoming Call to the Pilot DN
•Incoming Call to an Individual DN
Incoming Call to the Pilot DN
If the dialed digits of the incoming call match the DN for the main-sub-id (the pilot DN), the call is routed to the group. Figure 3-2 illustrates this process.
Figure 3-2 Searching an MLHG—Incoming Call to the Pilot DN (Example)
•A rectangle surrounding a number means the line is busy.
•Regular hunt and circular hunt (the hunting treatment for regular hunt and circular hunt are identical when the pilot DN is dialed)—The incoming call is routed to Terminal 1. If Terminal 1 is busy, the system hunts for the next idle terminal. If none of the terminals (2 through 10) is available, the hunt ends and the system does not answer the call.
•UCD hunt—From previous calls, the system has set the next-free-terminal (NFT) pointer to Terminal 4. Therefore the call is completed to Terminal 4. When the call is completed to Terminal 4, the system sets the NFT pointer to the next idle line (Terminal 2). The system will give the next call to Terminal 2.
Incoming Call to an Individual DN
If the dialed digits of the incoming call match the DN for an individual terminal, the call is routed to that specific terminal. However, if that terminal is busy, the system hunts for an idle line. Figure 3-3 illustrates this process.
Figure 3-3 Searching an MLHG—Incoming Call to an Individual Terminal (Example)
•A rectangle surrounding a number means the line is busy.
•Regular hunt—The incoming call is routed to the terminal with the dialed DN, Terminal 5 in this example. If Terminal 5 is busy, the system hunts for the next idle terminal, Terminal 9 in this example. If none of the terminals (6 through 10) is available, the hunt ends and the system does not answer the call.
•Circular hunt—The incoming call is routed to the terminal with the dialed DN, Terminal 5 in this example. If Terminal 5 is busy, the system hunts for the next idle terminal, Terminal 9 in this example. If none of the terminals (6 through 10) is available, the hunt continues with Terminal 1 through 4. If none of the terminals up to n-1 (where n is the dialed DN) is available, the hunt ends and the system does not answer the call.
•UCD hunt—The incoming call is routed to the terminal with the dialed DN, Terminal 5 in this example. If Terminal 5 is idle, the system completes the call to Terminal 5 and does not attempt to change the NFT pointer. If Terminal 5 is busy, the system completes the call to the NFT. In this example, the system has already set the NFT pointer to Terminal 4. Therefore the call is completed to Terminal 4. When the call is completed to Terminal 4, the system performs a circular hunt for the next idle line, beginning with the terminal that follows the one on which the call was completed. It sets the NFT pointer to the next idle line (Terminal 2 in this example). The system will give the next call to Terminal 2.
•If the terminal associated with the dialed DN of the incoming call is provisioned in the Subscriber table with a mlhg-pref-list-id, the system first hunts according to the process described in the "Preferential Hunt Lists" section. Preferential hunting is supported only if the hunt type is regular or circular (not UCD).
Preferential Hunt Lists
The system supports preferential hunt lists. There can be up to 64 preferential hunt lists per MLHG, and a maximum of 18 terminals are allowed in each list. Preferential hunt works only if the inbound call was dialed to the DN of a specific terminal. If the called DN is busy, and if the terminal associated with that DN is provisioned in the Subscriber table with a mlhg-pref-list-id, the system first searches the preferential hunt list in a specified sequence. The call is given to the first idle member of that preferential hunt list. If all the terminals in the preferential hunt list are busy, the hunting continues in the main MLHG list starting from the terminal after the last terminal in the preferential hunt list. This process is shown in Figure 3-4.
Note The system does not invoke the preference list (preferential hunt) if hunt-type=UCD in the MLHG table.
Figure 3-4 Searching a Preferential Hunt List (Example)
Assigning and Activating MLHG Features
This section explains what causes a feature to be assigned and active on the MLHG main subscriber and MLHG individual.
For features that require activation, individual subscribers typically activate the feature on their own handsets using vertical service codes (VSCs). Activation of a feature for one member of the MLHG does not affect activation for another user. Activation for the main subscriber does not cause activation for any of the individual subscribers, even if the individual subscribers have GRP=Y.
MLHG Main Subscriber
Features are assigned directly to the main subscriber by provisioning the Subscriber Profile or Subscriber Service Profile table. For the main subscriber, a feature is active if it is assigned to the subscriber, and activated by either of the following methods:
•If a terminal is assigned to the main subscriber, the feature can be activated through handset provisioning or through the Subscriber Feature Data table.
•If a terminal is not assigned to the main subscriber (term=none in the Subscriber table), the feature can be activated through the Subscriber Feature Data table.
MLHG Individual
There are two methods of assigning a feature to an MLHG individual:
•Set GRP = Y in the Subscriber table—This causes the MLHG individual to inherit all the features assigned to the main subscriber.
•Set GRP = N in the Subscriber table—In this case, the MLHG individual inherits no features from the main subscriber. Individual features can be assigned directly to the individual subscriber.
Caution If you set GRP = Y for a particular MLHG individual (which causes the MLHG individual to inherit all the features from the MLHG main subscriber), do not directly add any features to the MLHG individual, This could cause unexpected feature interactions.
The system honors the GRP flag only if the term-type of the individual MLHG subscriber and the MLHG main subscriber are the same, either term-type=term or term-type=sip (that is, both are NCS/MGCP or both are SIP). Otherwise the system treats the subscriber as grp=N, even if you have provisioned grp=Y.
Table 3-9 lists the parameters that affect assignment and activation of features on the MLHG individual.
Table 3-9 Parameters Affecting Assignment and Activation of Features on MLHG Individual
Feature Assigned to Main Subscriber
|
MLHG Individual Subscriber
|
Result— Status of the Feature on the MLHG Individual
|
Explanation
|
GRP =
|
Feature Assigned to MLHG Individual
|
Feature Activated on MLHG Individual
|
Y
|
Y
|
N
|
Y
|
Active
|
MLHG individual inherits feature from the main sub.
Feature is activated on the MLHG individual.
|
Y or N
|
N
|
Y
|
Y
|
Active
|
Feature is assigned directly to the MLHG individual.
Feature is activated on the MLHG individual.
|
Y
|
Y
|
N
|
N
|
Not active.
|
MLHG individual inherits feature from the main sub.
Feature is not activated on the MLHG individual.
|
N
|
Y
|
N
|
n/a
|
Not active.
|
The feature is not assigned.
|
Y or N
|
N
|
Y or N
|
N
|
Not active.
|
Regardless of feature assignment, the feature is not activated on the MLHG individual.
|
MLHG Provisioning Options and Use Cases
Table 3-10 explains how provisioning in the Subscriber table affects the behavior of a terminal in the MLHG.
Table 3-10 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-INDIV 1
|
Required
|
Y 2
|
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.
|
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.
Nonhunt terminal—You can provision a MLHG endpoint as a nonhunt terminal through the mlhg_non_hunt_terminal parameter in the Subscriber table. By default, this option is disabled (mlhg_non_hunt_terminal=N). If you set mlhg_non_hunt_terminal=Y, incoming calls to the individual subscriber's DN do not invoke hunting.
Features—The system delivers the same features to the subscriber regardless of how the features are assigned (assigned and activated on the individual subscriber, or inherited from the main subscriber and activated on the individual subscriber).
Feature activation—If a feature requires activation by the user, activation for one user in the MLHG does not affect activation for another user. Activation for the main subscriber does not cause activation for any of the individual subscribers, even if the subscribers have GRP=Y.
Caution For features that require activation by the user, each user has the option of activating the feature, but this does not occur automatically.
Terminal Make Busy and Group Make Busy Features
The Terminal Make Busy (TMB) and Group Make Busy (GMB) features enable the BTS 10200 to give incoming callers the appearance that specific terminals within a MLHG or all members of the MLHG are busy.
TMB—The feature works as follows:
•When the subscriber activates TMB for a specific terminal, the system skips the terminal in the hunting sequence and gives the call to the next idle terminal in the MLHG.
•When the subscriber activates TMB for all terminals in the MLHG, the system automatically gives the call a busy tone or forwards it to voicemail if voicemail is provisioned.
•The subscriber can originate calls from the terminal even if TMB is active.
GMB—The feature works as follows:
•Any subscriber within the MLHG that supports the GMB feature can activate or deactivate the feature.
•When GMB is active, the calling party receives a busy tone when dialing the MLHG pilot DN or main subscriber. None of the members of the MLHG receives the call and the hunt mechanism is disabled. If the main subscriber has forwarding-busy treatments such as Call Forward Busy (CFB) and voicemail activated, the BTS 10200 forwards the calls.
•When GMB is active and the calling party dials the DN of an individual terminal belonging to the MLHG, the system completes the call to the individual terminal if idle; however, if the individual terminal is not idle, the system performs a hunt and completes the call to the next idle line. (If TMB is also active on the line, the calling party receives busy treatment.)
•The subscriber can originate calls from any terminal within the MLHG even if GMB is active.
You can provision the TMB and GMB features for terminals associated with an MLHG by adding the features to the MLHG and specifying the VSC, custom dial plan (for ctxg-mlhg subscribers), and subscriber service. You can assign TMB to individual DNs or extensions within a MLHG, and GMB for the entire MLHG. The system supports the TMB and GMB features for MLHG subscribers provisioned with any of the following categories:
•MLHG
•MLHG-Individual
•MLHG-Pref-Individual
•CTXG-MLHG
The subscriber activates and deactivates the TMB and GMB features by entering a VSC. You can provision the following make-busy activation and deactivation features:
•Terminal Make Busy Activation (TMBA)
•Terminal Make Busy Deactivation (TMBD)
•Group Make Busy Activation (GMBA)
•Group Make Busy Deactivation (GMBD)
The TMB and GMB features interact only with CFB and voicemail features. Table 3-11 and Table 3-12 provide examples of normal interactions between TMB and CFB.
Table 3-11 TMB-CFB Interactions when CFB is Active for Both Pilot DN and Terminal DN
Called Number
|
Condition of Called Number
|
BTS 10200 Action
|
Pilot DN
|
Pilot busy
|
Hunt for next available terminal
|
Pilot and all terminals busy
|
Call forwarded per CFB
|
MLHG terminal
|
MLHG terminal busy
|
Hunt for next available terminal
|
All terminals busy
|
Call forwarded per CFB
|
Table 3-12 TMB-CFB Interactions when CFB is Active for Terminal DN Only
Called Number
|
Condition of Called Number
|
BTS 10200 Action
|
Pilot DN
|
Pilot busy
|
Hunt for next available terminal
|
Pilot and all terminals busy
|
Busy tone
|
MLHG terminal
|
MLHG terminal busy
|
Hunt for next available terminal
|
All terminals busy
|
Call forwarded per CFB
|
With TMB activated, the BTS 10200 provides the calling party with an off-hook busy tone when they activate most features.
The BTS 10200 supports normal behavior for CFB and voicemail when TMB or GMB (or both) are activated.
Special Hunting Treatment for SIP Subscribers
This section explains how the system handles hunting for special cases involving SIP subscribers.
If a SIP endpoint in the MLHG is not registered, the BTS 10200 performs a hunt and delivers the incoming call to an idle line in the MLHG. This treatment is the same for calls to SIP-based individual members of the MLHG as well as calls to the pilot number associated with a SIP-based main subscriber.
Some SIP endpoints can handle multiple calls through the call processing capability on the phone itself (for example, the call waiting feature on the phone). The system tracks the presence of calls on each AOR associated with the SIP subscriber in the MLHG. A provisionable parameter (mlhg_sip_deliver_if_busy in the Subscriber table) allows a call to be delivered to a busy SIP endpoint when all MLHG lines are busy. By default, the delivery of calls to a busy SIP endpoint is disabled (mlhg_sip_deliver_if_busy=N). For SIP endpoints, you can enable it by setting mlhg_sip_deliver_if_busy=Y. If the busy SIP endpoint rejects the incoming call (with a non-200 response to the initial INVITE), the system fails the call with a BUSY cause. This feature is invoked in the following situation:
•The BTS 10200 receives an incoming call, and the dialed DN is the DN of a SIP-based subscriber (the called party). The subscriber could be either the main subscriber or an individual group member.
•The mlhg_sip_deliver_if_busy parameter is set to Y for this subscriber.
•This subscriber is already on a call (busy).
•The system performs a hunt in the normal manner, but all of the lines in the MLHG are currently busy.
•The system attempts to deliver the call to the original called party with the expectation that the call can be connected as an additional call to the busy SIP phone.
Treatment of Outbound Call Features
Temporarily disconnected status—If temporarily-disconnected status is assigned to the subscriber record for the main subscriber (Subscriber table: status=temp-disconnected), the system treats all the lines in the MLHG (that is, all the lines provisioned with the same mlhg-id as the main subscriber) as temporarily disconnected. This is true regardless of the provisioned value for the grp parameter in the Subscriber table.
Call forwarding—When a call is forwarded from a line in the MLHG, the forwarding signaling contains the DN of the subscriber associated with the original dialed number.
Account codes and authorization codes—You can provision the system to collect account codes and authorization codes from members of the MLHG. First, set up a class of service (COS) restriction in the COS-Restrict table for the appropriate account code or authorization code treatment. Then provision the subscribers as follows:
•If you want to assign the COS treatment (including account codes and authorization codes) to all members of the MLHG (that is, to all the lines provisioned with the same mlhg-id as the main subscriber), assign the COS to the main subscriber and provision all members of the MLHG with grp=Y.
•If you provision any individual subscriber with grp=N, that individual does not inherit the COS feature from the main subscriber, However, you can still provision the individual with any desired features, including any available COS.
Speed call:
•Group speed call—To provide the group speed call feature to all members of the MLHG, provision the subscriber record for every member of the MLHG with grp=Y, and provision the main subscriber with the group speed call feature (GSC1D and GSC2D).
•Individual speed call—If you set grp=N for any member of the MLHG, then that member is provided only with the features assigned to the individual subscriber record (including any individual speed call features), and none of the features assigned to the main subscriber.
Treatment of Inbound Call Features
This section explains how the system treats an inbound call when a feature is assigned and active on an MLHG subscriber line. The handling of inbound calls depends on the following factors:
•The dialed directory number (DN)—This is the number dialed by the remote originating party. The dialed DN could be the pilot DN (the DN of the main subscriber of the MLHG) or the individual DN of any MLHG member.
•Active features—The treatment of the call depends on the features that are assigned and activated on the subscriber associated with the dialed DN. If a hunt occurs, the properties (the features and feature activation data) of the dialed DN are applied, not the properties of the hunted terminal.
Note If the hunted terminal goes off-hook to receive the call, the user of the hunted terminal can initiate midcall features (for example, by depressing the hook or pressing the Flash button). The midcall features are based on the properties of the individual hunted terminal.
•Call waiting tone—Call Waiting (CW) and Caller ID on Call Waiting (CIDCW) are disabled for all MLHG subscribers. The CW tone is not applied on the main subscriber or mlhg-individual endpoints under any scenario.
•Temporarily disconnected status—If temporarily-disconnected status is assigned to the subscriber record for the main subscriber (Subscriber table: status=temp-disconnected), the system does not perform any hunting, and it treats all the lines in the MLHG (that is, all the lines provisioned with the same mlhg-id as the main subscriber) as temporarily disconnected. This is true regardless of the provisioned value for the grp parameter in the Subscriber table.
•Typically, a subscriber service contains multiple features, and the system applies the features according to the normal feature precedence as documented in Chapter 5, "Feature Interactions."
•Additional features—The following sections describe the treatment of incoming calls for the features listed below.
–CFB:
Table 3-13, "Treatment of Incoming Call to Pilot DN for CFB Feature"
Table 3-14, "Treatment of Incoming Call to MLHG Individual DN for CFB Feature"
–CFNA:
Table 3-15, "Treatment of Incoming Call to Pilot DN for CFNA Feature"
Table 3-16, "Treatment of Incoming Call to MLHG Individual DN for CFNA Feature"
–CFC or VM:
Table 3-17, "Treatment of Incoming Call to Pilot DN for CFC or VM Feature"
Table 3-18, "Treatment of Incoming Call to MLHG Individual DN for CFC or VM Feature"
–CFU or VMA:
Table 3-19, "Treatment of Incoming Call to Pilot DN for CFU or VMA Feature"
Table 3-20, "Treatment of Incoming Call to MLHG Individual DN for CFU or VMA Feature"
–SCA, SCF, and SCR:
Table 3-21, "Treatment of Incoming Call to Pilot DN for SCA, SCF, or SCR Feature"
Table 3-22, "Treatment of Incoming Call to MLHG Individual DN for SCA, SCF, or SCR Feature"
–DRCW:
Table 3-23, "Treatment of Incoming Call to Pilot DN for DRCW Feature"
Table 3-24, "Treatment of Incoming Call to MLHG Individual DN for DRCW Feature"
CFB
Table 3-13 lists the call treatment for inbound calls to the MLHG pilot number (main subscriber DN) based on the assignment and activation of Call Forwarding Busy (CFB) for that main subscriber.
Table 3-13 Treatment of Incoming Call to Pilot DN for CFB Feature
CFB Assignment and Activation on the Main Subscriber
|
Scenario (Condition When Call Comes In to the Pilot DN)
|
Call Treatment Given to the Inbound Call
|
(For these scenarios, CFB assignment and activation have no effect.)
|
Terminal of the main-sub is busy, or no terminal is assigned to the main-sub.
|
The system hunts for an idle line.
|
Terminal of the main-sub or hunted terminal is idle but does not answer.
|
Ringing on idle line.
|
CFB assigned and activated.
|
All terminals busy.
|
Call forwarded per CFB.
|
CFB assigned but not activated, or CFB not assigned.
|
Busy tone
|
Table 3-14 lists the call treatment for inbound calls to the MLHG individual subscriber DN based on the assignment and activation of CFB for that individual.
Table 3-14 Treatment of Incoming Call to MLHG Individual DN for CFB Feature
CFB Assignment and Activation on the MLHG Individual
|
Scenario (Condition When Call Comes In to DN of the MLHG Individual)
|
Call Treatment Given to the Inbound Call
|
(For these scenarios, CFB assignment and activation have no effect.)
|
Mlhg-individual is busy.
|
The system hunts for an idle line.
|
Mlhg-individual or hunted terminal is idle but does not answer.
|
Ringing on idle line.
|
CFB assigned and activated.
|
All terminals busy.
|
Call forwarded per CFB.
|
CFB assigned but not activated, or CFB not assigned.
|
Busy tone
|
CFNA
Table 3-15 lists the call treatment for inbound calls to the MLHG pilot number (main subscriber DN) based on the assignment and activation of Call Forwarding No Answer (CFNA) for that main subscriber.
Table 3-15 Treatment of Incoming Call to Pilot DN for CFNA Feature
CFNA Assignment and Activation on the Main Subscriber
|
Scenario (Condition When Call Comes In to the Pilot DN)
|
Call Treatment Given to the Inbound Call
|
(For this scenario, CFNA assignment and activation have no effect.)
|
Terminal of the main-sub is busy, or no terminal is assigned to the main-sub.
|
The system hunts for an idle line.
|
CFNA assigned and activated.
|
Terminal of the main-sub or hunted terminal is idle but does not answer.
|
Call forwarded per CFNA.
|
CFNA assigned but not activated, or feature not assigned.
|
Ringing on idle line.
|
(For this scenario, CFNA assignment and activation have no effect.)
|
All terminals busy.
|
Busy treatment.
|
Table 3-16 lists the call treatment for inbound calls to an MLHG individual subscriber DN based on the assignment and activation of CFNA for that individual.
Table 3-16 Treatment of Incoming Call to MLHG Individual DN for CFNA Feature
CFNA Assignment and Activation on the MLHG Individual
|
Scenario (Condition When Call Comes In to DN of the MLHG Individual)
|
Call Treatment Given to the Inbound Call
|
(For this scenario, CFNA assignment and activation have no effect.)
|
Mlhg-individual is busy.
|
The system hunts for an idle line.
|
CFNA assigned and activated.
|
MLHG-individual or hunted terminal is idle but does not answer.
|
Call forwarded per CFNA.
|
CFNA assigned but not activated, or feature not assigned.
|
Ringing on idle line.
|
(For this scenario, CFNA assignment and activation have no effect.)
|
All terminals busy.
|
Busy treatment.
|
CFC or VM
Table 3-17 lists the call treatment for inbound calls to the MLHG pilot number (main subscriber DN) based on the assignment and activation of Call Forwarding Combination (CFC) or Voice Mail (VM) for that main subscriber.
Note Information for the Voice Mail Always (VMA) feature is in Table 3-19 and Table 3-20.
Table 3-17 Treatment of Incoming Call to Pilot DN for CFC or VM Feature
Feature (CFC or VM) Assignment and Activation on the Main Subscriber
|
Scenario (Condition When Call Comes In to the Pilot DN)
|
Call Treatment Given to the Inbound Call
|
(For this scenario, feature assignment and activation have no effect.)
|
Terminal of the main-sub is busy, or no terminal is assigned to the main-sub.
|
The system hunts for an idle line.
|
Feature assigned and activated.
|
Terminal of the main-sub or hunted terminal is idle but does not answer.
|
Call forwarded per CFC or VM.
|
Feature assigned but not activated, or feature not assigned.
|
Ringing on idle line.
|
Feature assigned and activated.
|
All terminals busy.
|
Call forwarded per CFC or VM.
|
Feature assigned but not activated, or feature not assigned.
|
Busy treatment.
|
Table 3-18 lists the call treatment for inbound calls to an MLHG individual subscriber DN based on the assignment and activation of CFC or VM for that individual.
Table 3-18 Treatment of Incoming Call to MLHG Individual DN for CFC or VM Feature
Feature (CFC or VM) Assignment and Activation on the MLHG Individual
|
Scenario (Condition When Call Comes In to DN of the MLHG Individual)
|
Call Treatment Given to the Inbound Call
|
(For this scenario, feature assignment and activation have no effect.)
|
Mlhg-individual is busy.
|
The system hunts for an idle line.
|
Feature assigned and activated.
|
Mlhg-individual or hunted terminal is idle but does not answer.
|
Call forwarded per CFC or VM.
|
Feature assigned but not activated, or feature not assigned.
|
Ringing on idle line.
|
Feature assigned and activated.
|
All terminals busy.
|
Call forwarded per CFC or VM.
|
Feature assigned but not activated, or feature not assigned.
|
Busy treatment.
|
CFU or VMA
Table 3-19 lists the call treatment for inbound calls to the MLHG pilot number (main subscriber DN) based on the assignment and activation of Call Forwarding Unconditional (CFU) or Voice Mail Always (VMA) for that main subscriber.
Note Information for the Voice Mail (VM) feature is in Table 3-17 and Table 3-18.
Table 3-19 Treatment of Incoming Call to Pilot DN for CFU or VMA Feature
Feature (CFU or VMA) Assignment and Activation on the Main Subscriber
|
Scenario (Condition When Call Comes In to the Pilot DN)
|
Call Treatment Given to the Inbound Call
|
Feature assigned and activated.
|
Terminal of the main-sub is busy, or no terminal is assigned to the main-sub.
|
Call forwarded per CFU or VMA.
|
Feature assigned but not activated, or feature not assigned.
|
The system hunts for an idle line.
|
Feature assigned and activated.
|
Terminal of the main-sub is idle.
|
Call forwarded per CFU or VMA.
|
Feature assigned but not activated, or feature not assigned.
|
Terminal of the main-sub is idle but does not answer.
|
Ringing on idle line.
|
Feature assigned and activated.
|
All terminals busy.
|
Call forwarded per CFU or VMA.
|
Feature assigned but not activated, or feature not assigned.
|
Busy treatment.
|
Feature assigned and activated on main subscriber.
|
Special Case—Dialed DN of incoming call is DN of the mlhg-individual, not DN of the main-sub.
|
Call treatment is based on the provisioned properties (features and feature data) of the mlhg-individual.
|
Table 3-20 lists the call treatment for inbound calls to an MLHG individual subscriber DN based on the assignment and activation of CFU or VMA for that individual.
Table 3-20 Treatment of Incoming Call to MLHG Individual DN for CFU or VMA Feature
Feature (CFU or VMA) Assignment and Activation on the MLHG Individual
|
Scenario (Condition When Call Comes In to DN of the MLHG Individual)
|
Call Treatment Given to the Inbound Call
|
Feature assigned and activated.
|
Mlhg-individual is busy.
|
Call forwarded per CFU or VMA.
|
Feature assigned but not activated, or feature not assigned.
|
The system hunts for an idle line.
|
Feature assigned and activated.
|
Terminal of the mlhg-individual is idle.
|
Call forwarded per CFU or VMA.
|
Feature assigned but not activated, or feature not assigned.
|
Mlhg-individual or hunted line is idle but does not answer.
|
Ringing on idle line.
|
Feature assigned and activated.
|
All terminals busy.
|
Call forwarded per CFU or VMA.
|
Feature assigned but not activated, or feature not assigned.
|
Busy treatment.
|
SCA, SCF, and SCR
Table 3-21 lists the call treatment for inbound calls to the MLHG pilot number (main subscriber DN) based on the assignment and activation of Selective Call Acceptance (SCA), Selective Call Forwarding (SCF), or Selective Call Rejection (SCR) for that main subscriber. The system invokes the SCA, SCF, or SCR feature only if the DN of the calling party is included in the screening list of the called party.
Table 3-21 Treatment of Incoming Call to Pilot DN for SCA, SCF, or SCR Feature
Feature (SCA, SCF, or SCR) Assignment and Activation on the Main Subscriber
|
Scenario (Condition When Call Comes In to the Pilot DN)
|
Call Treatment Given to the Inbound Call
|
Feature assigned and activated.
|
Terminal of the main-sub is busy, terminal of main-sub is idle, or no terminal is assigned to the main-sub.
|
SCA (on list)—Hunting; see additional scenarios in this table.
SCA (not on list)—Call is not accepted; SCA announcement.
SCF (on list)—Call forwarded per SCF.
SCF (not on list)—Hunting; see additional scenarios in this table.
SCR (on list)—Call rejected per SCR with SCR announcement.
SCR (not on list)—Hunting; see additional scenarios in this table.
|
Feature assigned but not activated, or feature not assigned.
|
The system hunts for an idle line.
|
Feature assigned and activated.
|
Terminal of the main-sub or hunted terminal is idle but does not answer.
|
SCA (on list)—Ringing on idle line.
SCF (not on list)—Ringing on idle line.
SCR (not on list)—Ringing on idle line.
|
Feature assigned but not activated, or feature not assigned.
|
Ringing on idle line.
|
Feature assigned and activated.
|
All terminals busy.
|
SCA (on list)—Busy treatment.
SCF (not on list)—Busy treatment.
SCR (not on list)—Busy treatment.
|
Feature assigned but not activated, or feature not assigned.
|
Busy treatment.
|
Table 3-22 lists the call treatment for inbound calls to an MLHG individual subscriber DN based on the assignment and activation of SCA, SCF, or SCR for that individual.
Table 3-22 Treatment of Incoming Call to MLHG Individual DN for SCA, SCF, or SCR Feature
Feature (SCA, SCF, or SCR) Assignment and Activation on the MLHG Individual
|
Scenario (Condition When Call Comes In to DN of the MLHG Individual)
|
Call Treatment Given to the Inbound Call
|
Feature assigned and activated.
|
Mlhg-individual is busy, or terminal of mlhg-individual is idle.
|
SCA (on list)—Hunting; see additional scenarios in this table.
SCA (not on list)—Call is not accepted; SCA announcement.
SCF (on list)—Call forwarded per SCF.
SCF (not on list)—Hunting; see additional scenarios in this table.
SCR (on list)—Call rejected per SCR with SCR announcement.
SCR (not on list)—Hunting; see additional scenarios in this table.
|
Feature assigned but not activated, or feature not assigned.
|
The system hunts for an idle line.
|
Feature assigned and activated.
|
Mlhg-individual or hunted terminal is idle but does not answer.
|
SCA (on list)—Ringing on idle line.
SCF (not on list)—Ringing on idle line.
SCR (not on list)—Ringing on idle line.
|
Feature assigned but not activated, or feature not assigned.
|
Ringing on idle line.
|
Feature assigned and activated.
|
All terminals busy.
|
SCA (on list)—Busy treatment.
SCF (not on list)—Busy treatment.
SCR (not on list)—Busy treatment.
|
Feature assigned but not activated, or feature not assigned.
|
Busy treatment.
|
DRCW
Table 3-23 lists the call treatment for inbound calls to the MLHG pilot number (main subscriber DN) based on the assignment and activation of Distinctive Ringing Call Waiting (DRCW) for that main subscriber. The system invokes the DRCW feature only if the DN of the calling party is included in the DRCW screening list of the called party.
Note Call Waiting (CW) and Caller ID on Call Waiting (CIDCW) are disabled for all MLHG subscribers. The CW tone is not applied on the main subscriber or mlhg-individual endpoints under any scenario.
Table 3-23 Treatment of Incoming Call to Pilot DN for DRCW Feature
DRCW Assignment and Activation on the Main Subscriber
|
Scenario (Condition When Call Comes In to the Pilot DN)
|
Call Treatment Given to the Inbound Call
|
(For this scenario, feature assignment and activation have no effect.)
|
Terminal of the main-sub is busy, or no terminal is assigned to the main-sub.
|
The system hunts for an idle line.
|
Feature assigned and activated.
|
Terminal of the main-sub or hunted line is idle.
|
DRCW (on list)—Ringing per DRCW.
DRCW (not on list)—Regular ringing.
|
Feature assigned but not activated, or feature not assigned.
|
Regular ringing.
|
(For this scenario, feature assignment and activation have no effect.)
|
All terminals busy
|
Busy treatment.
|
Table 3-24 lists the call treatment for inbound calls to an MLHG individual subscriber DN based on the assignment and activation of DRCW for that individual.
Table 3-24 Treatment of Incoming Call to MLHG Individual DN for DRCW Feature
DRCW Assignment and Activation on the MLHG Individual
|
Scenario (Condition When Call Comes In to DN of the MLHG Individual)
|
Call Treatment Given to the Inbound Call
|
(For this scenario, feature assignment and activation have no effect.)
|
Mlhg-individual is busy.
|
The system hunts for an idle line.
|
Feature assigned and activated.
|
Mlhg-individual or hunted line is idle.
|
DRCW (on list)—Ringing per DRCW.
DRCW (not on list)—Regular ringing.
|
Feature assigned but not activated, or feature not assigned.
|
Regular ringing.
|
(For this scenario, feature assignment and activation have no effect.)
|
All terminals busy
|
Busy treatment.
|
Billing for MLHG
Billing fields for calls originated by DNs within the MLHG are populated as follows.
Field 23 (originating number):
•The value of the DN1 field of the individual subscriber, if available.
•Otherwise, the value of the DN1 field of the main subscriber.
Field 25 (charge number)
•The value of the billing-dn field of the subscriber if available.
•Otherwise, the value of the billing-dn field of the main subscriber if available.
•Otherwise, the value of the DN1 field of the main subscriber if available.
•Otherwise, the value of the DN1 field of the subscriber.
For complete billing information, see the Billing Guide.
Basic Provisioning Procedure and CLI Reference
For the basic sequence of steps to provision a MLHG, see the MLHG provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
To see a detailed list of all provisionable values for the MLHG, MLHG Terminal, and MLHG Preference List tables, see the applicable tables in the Cisco BTS 10200 Softswitch CLI Database.
Features for Centrex Subscribers Only
The Cisco BTS 10200 Softswitch provides Centrex-group functionality. A Centrex group is an emulation of a PBX by a Class 5 switch, and is typically assigned to a business group. The service provider can provision the values for the main subscriber of the Centrex group, and those properties are applied to the entire Centrex group. The service provider can also provision the parameters for simulated facility group (SFG) control, if SFG is desired. Both the incoming SFG (ISFG) and outgoing SFG (OSFG) are provisionable.
Tip To provision a Centrex group, see the Centrex Group provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
The following features are available to Centrex subscribers only:
•Call Hold (CHD)
•Call Park and Call Retrieve
•Direct Inward/Outward Dialing for Centrex
•Directed Call Pickup (With and Without Barge-In)
•Distinctive Alerting/Call Waiting Indication (DA/CWI)
•MultiLine Variety Package
Call Hold (CHD)
The Cisco BTS 10200 Softswitch supports the call hold (CHD) feature as specified in LSSGR module FSD 01-02-1305 (TR-TSY-000579), Add On Transfer And Conference Calling Features.
Note This feature is available only to Centrex subscribers.
Description
The CHD feature allows the user to temporarily put an active call on hold and then make another call. The user can then return to the original call, and alternate between the two calls.
A party involved in an active call can use the CHD feature as follows:
•The user (the activating party) presses the Flash button or hookswitch and then presses the VSC for CHD (for example, *52).
•The network responds by putting the remote station on hold, providing silent termination. The system also returns a stutter dial tone to the activating party.
•If the activating party does nothing, the network waits 4 seconds, then removes the dial tone. In this case, the activating party can resume the call (recall the held party) by using the Flash button or hookswitch.
•If the activating party dials another remote station, then the system rings that station, and a new call is initiated if the remote station goes off hook.
•The CHD activation procedures (Flash button or hookswitch followed by the CHD VSC *52) can be used to toggle between the two calls. If the activating party disconnects while a party is on hold, the network responds by ringing the activating party's line. If the line is not answered within 6 ring cycles, the held party is disconnected. The held party does not hear an audible ringback during this ringing cycle.
Feature Interactions with CHD
The following feature interactions apply to CHD.
CHD and Emergency Number
There is an interaction when a Centrex subscriber invokes call hold (CHD) and places a call to an emergency number:
•When the emergency operator answers the call, a two-party call is active between the subscriber and the emergency operator. The on-hold party remains on hold.
•When the subscriber presses the Flash button or hookswitch, a three-way call is established among the subscriber, the emergency operator, and the previously on-hold party.
•It is not possible to place the emergency operator on hold.
CHD with CW/CIDCW and CFNA/VM/VMA
There is an interaction when a Centrex subscriber has all three of the following features assigned and active:
1. Call hold—CHD.
2. Call waiting—CW or CIDCW or both.
3. Call forwarding on no answer—CFNA, VM (or VMA), or any combination of these.
The system behavior is illustrated in the following example. In this example, CFNA is assigned and active on subscriber (A) along with CHD and CW.
•A and B are on an active call.
•C calls A.
•A hears the CW tone. (C hears ringback.)
•If A presses the Flash button or hookswitch, B is put on hold and A hears a dial tone.
•If A dials *52, A is connected to C.
•If A ignores the CW tone, C continues to hear ringback until the CFNA timer expires, then the call from C is forwarded per CFNA.
CHD and CFNA
If CHD is assigned to the subscriber (A) along with CFNA (CFNA active), the following interaction occurs.
•A and B are on an active call.
•C calls A.
•C hears a busy tone and is not connected. The call from C is not forwarded by the CFNA feature.
CHD and CW
If CHD is assigned to the subscriber (A) along with CW, the following interaction occurs.
•A and B are on an active call.
•C calls A.
•A hears the CW tone. (C hears ringback.)
•If A presses the Flash button or hookswitch, B is put on hold and A hears a dial tone.
•If A dials *52, A is connected to C.
•If A ignores the CW tone, C continues to hear ringback. The call is not forwarded.
Feature Provisioning
To provision this feature, see the CHD provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Call Park and Call Retrieve
Note This feature is available only to Centrex subscribers.
Call park (CPRK) and call retrieve (CPRK-RET) are defined for a call park subscriber group (CPSG), which is a subset of the Centrex subscriber group who have privileges to park and retrieve calls. Members of the CPSG can park and retrieve calls on a DN within their own CPSG. If desired, this feature can be used to transfer calls from one CPSG member to another.
CPRK allows a user in a business group to park an active call on a designated parking DN, leaving the user free to make other calls. The parked caller is placed on hold. The parking party is periodically reoffered the parked call. If the parking party accepts the reoffer attempt, or if another authorized user in the CPSG retrieves the call, then the call is connected. Otherwise, after three reoffer attempts, the call is released or forwarded as provisioned.
To park an active call:
•The parking party uses the Flash button or hookswitch, receives a recall dial tone, and dials the CPRK Access Code
•The parking party dials the DN of the desired CPSG member (or just hangs up or dials # to park the call against their own DN)
•A confirmation tone is provided to the parking party to confirm that the call is parked
To retrieve a parked call:
•The retrieving party dials the CPRK-RET access code and gets a dial tone
•The retrieving party dials the DN on which the call is parked
•The call is now connected between the calling party and the retrieving party
There is no deactivation procedure for this feature. The parked call is either connected or forwarded as described above.
Tip To provision this feature, see the CPRK provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Direct Inward/Outward Dialing for Centrex
Note This feature is available only to Centrex subscribers.
The Cisco BTS 10200 Softswitch supports the following direct inward/outward dialing features for Centrex systems as specified in LSSGR module FSD 01-01-1000 (TR-TSY-520), Basic Business Group:
•DID, including distinctive alerting and call-waiting tone—DID provides a Centrex group with the ability to receive a call from the PSTN without attendant intervention. The receiving Centrex station appears as a serving line to the CA. To provide a distinctive alerting and call-waiting tone, the service provider assigns the Distinctive Alerting/Call Waiting Indication (DA/CWI) feature to the subscriber.
Note For the distinctive call-waiting tones to be played, either the Call Waiting (CW) feature or the Call Waiting Deluxe (CWD) feature must also be assigned and active on the subscriber line.
•DOD provides a Centrex group with the ability to make a call to the PSTN without attendant intervention. The sending Centrex station appears as a serving line to the CA.
Directed Call Pickup (With and Without Barge-In)
Caution Do not provision this feature for subscribers other than Centrex subscribers. This feature will not work for subscriber other than Centrex Subscribers.
Directed call pickup allows a user in a basic business group (BBG) to answer a call to a telephone from another telephone in the BBG. There are two types of directed call pickup, with and without barge-in, each with its own activation access code. These codes are assigned by the administrator of the BBG, and can range from 2 to 65535.
The procedure for directed call pickup without barge-in (DPN) is as follows:
•The process begins when a telephone rings in the BBG, and a member of the BBG at a remote phone would like to pick up the call from the ringing telephone line
•At the remote telephone line, the user lifts the handset, and listens for a dial tone
•The remote user dials the DPN activation access code *xx (where xx represents the digits assigned for DPN activation in the BBG)
•The system returns a recall dial tone
•The remote user dials the extension associated with the ringing line
•The remote line is connected to the incoming call that actually terminated at the ringing line
•The original called line is now idle and available to originate and to receive calls
•If the incoming call has already been picked up by another member of the BBG, the additional DPN requests are routed to a reorder tone.
The procedure for directed call pickup with barge-in (DPU) is as follows:
•The process begins when a telephone rings in the BBG, is answered by the party, and another member of the BBG at a remote line wants to join the conversation
•At the remote telephone line, the user lifts the handset, and listens for a dial tone
•The remote user dials the DPU activation access code *xx (where xx represents the digits assigned for DPU activation in the BBG)
•The system returns a recall dial tone
•The remote user dials the extension on which the active call is taking place
•The system plays a confirming tone and establishes a three-way call (TWC) between the remote line and the original two parties
•The remote BBG user can press the Flash button or hookswitch to drop the other BBG party related to the original call
•If the remote BBG user goes on hook, the two-way connection will be reestablished between the calling party and the original BBG party
Tip To provision these features, see the DPN and DPU provisioning procedures in the Cisco BTS 10200 Softswitch Provisioning Guide.
Distinctive Alerting/Call Waiting Indication (DA/CWI)
Note This feature is available only to Centrex subscribers.
The distinctive alerting/call waiting indication (DA/CWI) feature is based on the Telcordia document GR-520-CORE, Features Common to Residence and Business Customers I (FSDs 00 to 01-01-1110). DA/CWI provides Centrex users special ringing and CW tones on DID calls. The Centrex administrator can activate this feature for some or all of the business group lines (BGLs) in the basic business group (BBG). Any call terminating at a designated BGL will receive the appropriate distinctive ringing or CW tone. When enabled, the subscriber can receive different ringing patterns (distinctive ringing) and CW alerting as follows.
•Calls originating within the same Centrex (also referred to as inside calls or extension dialing):
–Ringing pattern: 2 seconds of ringing followed by 4 seconds of silence
–CW pattern: 0.3-second beep
•Incoming calls originating outside the Centrex (outside calls, including calls from a different Centrex group):
–Ringing pattern: 800 ms of ringing, 400 ms of silence, 800 ms of ringing, 4 seconds of silence
–CW pattern: 0.1 seconds beep, 0.1 seconds silence, 0.1 seconds beep
Note For the distinctive call-waiting tones to be played, either the Call Waiting (CW) feature or the Call Waiting Deluxe (CWD) feature must also be assigned and active on the subscriber line.
Tip To provision this feature, see the DA/CWI provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
MultiLine Variety Package
The MVP feature allows the creation of a logical grouping of subscribers and enables the provision of Centrex features such as call-hold, call-park/retrieve and extension dialing for the subscribers within the group.
Typically Centrex subscribers dial "9" (or some other access code) to access the PSTN and dial extension numbers to reach other subscribers within the group. However, in the case of small business with fewer lines, it can be expected that most of the originating call traffic will be towards the PSTN and not to within the group.
Using the MVP feature on the BTS 10200 system, the requirement to dial an access code to access a PSTN line can be avoided for the group members.
In addition, the BTS10200 can be configured to use "*" prefixed extensions to reach the subscribers within the group. It is possible to use 1-digit extensions within the range *2-*9 for a smaller group of subscribers (i.e. a group with up to 8 subscribers) or 2-digit extensions within range *20-*49 for a medium size group of subscribers (i.e. a group with up to 30 subscribers). *0 can be assigned to the operator or *0 can be used for Operator or Attendant Access.
Additional Features Applicable to Centrex and POTS
The following additional features are available to both Centrex and POTS subscribers:
•Anonymous Call Rejection (ACR)
•Automatic Callback (AC)—Repeat Dialing
•Automatic Recall (AR)—Call Return
•Call Block - Reject Caller (CBLK)
•Call Block - Reject Caller (CBLK)
•Call Transfer (CT)
•Change Number (CN)
•Customer-Originated Trace (COT)
•Do Not Disturb (DND)
•Hotline Service
•Hotline-Variable Service (HOTV)
•Interactive Voice Response (IVR) Functions
•Limited Call Duration Service (Prepaid/Postpaid) with RADIUS Interface to AAA
•Message Waiting Indicator (MWI)—Audible and Visual
•Multiple Directory Numbers (MDN)
•No Solicitation Announcement (NSA)
•Own Calling Number Announcement (OCNA)
•Privacy Screening (Calling Identity with Enhanced Screening)
•Seasonal Suspend
•Speed Call
•Subscriber-Controlled Services and Screening List Editing (SLE)
–Selective Call Forwarding (SCF)
–Selective Call Acceptance (SCA)
–Selective Call Rejection (SCR)
–Distinctive Ringing/Call Waiting (DRCW)
–10/11-Digit Screening for SLE Features
•Temporarily Disconnected Subscriber Status and Soft Dial Tone
•Three-Way Calling (TWC)
•Three-Way Calling Deluxe (TWCD)
•Usage-Sensitive Three-Way Calling (USTWC)
•Voice Mail (VM) and Voice Mail Always (VMA)
•Warmline Service
Anonymous Call Rejection (ACR)
The BTS 10200 supports the anonymous call rejection (ACR) feature as specified in LSSGR module FSD 01-02-1060 (TR-TSY-000567), Anonymous Call Rejection.
The ACR feature allows users to reject calls from parties that have set their privacy feature to prevent calling number delivery. When ACR is active the called party receives no alerting of incoming calls that are rejected. The incoming call is rerouted to a denial announcement indicating that private numbers are not accepted by the called party. To complete a call to the party with ACR, the calling party must enter the VSC to activate calling identity delivery (for example, *82 for CIDSD) and then place a call to the party with ACR. Incoming calls to the called party with ACR are checked even if the called party is off hook.
If the BTS 10200 does not receive the calling party information in the incoming message, or if it does not receive the privacy setting in the incoming message, or if the privacy setting is unknown, the following process occurs. The system checks a provisionable parameter (PRIVACY-UNKNOWN-TREATMENT) in the Feature Configuration (feature-config) table. This parameter by default is set to PUBLIC, which means the incoming call is treated as public and is not rejected by the ACR feature. The service provider has the option to set this parameter to ANONYMOUS, which means the incoming call is treated as anonymous and is rejected by the ACR feature.
ACR has multiple activation options as follows:
•Activated permanently at subscription time by service provider.
•Activated by user:
–The user lifts the handset, and listens for a dial tone.
–The user presses the activation VSC (for example, typically *77 in North America). If ACR can be activated, the system returns a success announcement.
–ACR is now activated, and will stay active until it is deactivated.
Note If the user tries to activate ACR when it is already active, the system treats the new activation attempt as a new attempt.
ACR deactivation options are as follows:
•Service provider deactivation at user request.
•Deactivated by user:
–The user lifts the handset and listens for a dial tone.
–The user presses the deactivation VSC (for example, typically *87 in North America). The system responds with a success announcement.
–ACR is now deactivated, and will stay inactive until it is activated.
Note If the user tries to deactivate ACR when it is already deactivated, the system accepts and processes the new deactivation attempt as a new attempt.
Tip To provision this feature, see the ACR provisioning procedure in the Cisco BTS 10200 Softswitch Provisioning Guide.
Automatic Callback (AC)—Repeat Dialing
Automatic callback (AC), also called repeat dialing, allows the user to request the system to automatically redial the most recently dialed number. The system will keep attempting to call the number for up to 30 minutes. If the called party is busy when AC is activated, call setup is automatically performed when the called station becomes idle. The system alerts the calling party with distinctive ringing. Up to 20 AC requests can be active at any time. The service provider can set up this service for the user, or the user can access it on a usage-sensitive basis.
Note For intra-office AC with ARAC-TERMINATING-SPCS-SCAN-ALLOW;VALUE=Y, the feature operates as expected during a Feature Server switchover. However, for inter-office AC with the same switchover condition, the feature fails because TCAP is not replicated.
AC is activated as follows:
•The user calls a remote station, receives a busy signal or no answer, and hangs up.
•The user lifts the handset again, and listens for dial tone.
•The user enters the VSC for AC activation (for example, *66). One of the following scenarios will occur:
–Audible ring—Indicates that the call setup is being attempted immediately.
–The delayed proce
