Table Of Contents
Provisioning Session Timers for SIP Subscribers
SIP Timer Values for SIP Subscribers
Diversion Indication for SIP Subscribers
Comparison of SIP-Based Features and MGCP-Based Features
Cisco BTS 10200 Softswitch-Based Features
Call Forwarding Activation and Deactivation
Call Forwarding to an E.164 Number or an Extension Number
Detailed Provisioning Procedure and Feature Description
Calling Name and Number Delivery
Caller ID Delivery Suppression
E.164 and Centrex Dialing Plan (Extension Dialing)
Operator Services (0-, 0+, 01+, and 00 Calls)
Vertical Service Code Features
Planning VSCs In Networks with SIP Subscribers
Supported VSC-Enabled Features for SIP Endpoints
VM Implementation for Centrex Subscribers
Call Transfer (Blind and Attended) with REFER
Distinctive Ringing for Centrex DID Calls
SIP Subscribers
Revised: July 31, 2008, OL-15912-04The Cisco BTS 10200 Softswitch supports SIP subscribers on SIP phones that are compliant with RFC 3261 or RFC 2543. This section describes the support for SIP subscribers and how to provision SIP subscriber features.
In this document:
•
SIP subscriber means a SIP phone that is registered directly to the BTS 10200 and for which the BTS 10200 maintains subscriber information.
•
Note
This section covers the following topics:
•
•
•
•
•
•
•
SIP Phone Initialization
Figure 2-1 shows an example of SIP phone initialization on bootup, that is, how a typical phone might initialize itself and establish its identity with the BTS 10200. (The image shows actions that occur external to the BTS 10200—it does not show how the BTS 10200 controls SIP initialization.) The circled numbers in the image indicate the numerical order in which the sequence occurs.
Figure 2-1 Example of SIP Phone Initialization
Provisioning a SIP Subscriber
To provision a SIP subscriber, see the "SIP Subscribers" section in the Provisioning Guide.
SIP Registration and Security
SIP subscribers use the SIP REGISTER method to record their current locations with the BTS 10200. Registering clients can specify an expiration time for the contacts being registered. However, the BTS 10200 has a minimum and maximum acceptable duration, both of which are configurable.
Note
It is possible to register multiple contacts for a single AOR; however, if multiple contacts are registered for a single subscriber, the BTS 10200 uses only the most recently registered contact to deliver the call to that subscriber. For this reason, multiple contacts are not supported.
Note
When a SIP user attempts to register or set up a call, the BTS 10200 challenges the SIP subscriber based on provisioning in the serving-domain-name table. If the serving-domain-name table indicates that authentication is required, the BTS 10200 challenges the SIP request (Register/INVITE) according to the authentication procedures specified in SIP Protocol RFC 3261. If the BTS 10200 receives valid credentials, the authenticated AOR from the user-auth table identifies the subscriber based on the aor2sub table. (For specific provisioning parameters, see the applicable tables in the Cisco BTS 10200 Softswitch CLI Database.)
Registration creates bindings in the BTS 10200 that associate an AOR with one or more contact addresses.
The registration data is replicated on the standby BTS 10200. The BTS 10200 imposes a minimum registration interval as a provisionable value. If the expiration duration of the incoming registration request is lower than the provisioned minimum, a 423 (Interval Too Brief) response is sent to the registering SIP endpoint.
The BTS 10200 generates a warning event when a request from a client fails authentication. This can indicate a provisioning error or an attempt by an unauthorized client to communicate with the BTS 10200.
The contacts registered for an AOR can be looked up using the status command, as demonstrated by the following example.
CLI> status sip-reg-contact AOR_ID=4695550184@sia-SYS44CA146.ipclab.cisco.comAOR ID -> 4695550184@sia-SYS44CA146.ipclab.cisco.comUSER -> 4695550184HOST -> 10.88.11.237PORT -> 5060USER TYPE -> USER_PHONE_TYPEEXPIRES -> 3600EXPIRETIME -> Thu Jan 22 14:33:36 2004STATUS -> REGISTERED CONTACTReply :Success:Enhanced SIP Registration
SIP Registration ensures that a SIP REGISTER message to the BTS 10200 is from a provisioned endpoint, that is, an endpoint with a provisioned secure fully qualified domain name (FQDN) or IP address. The feature also ensures that the source IP address and contact parameter for all originating calls are from the provisioned SIP endpoint, and that no calls can originate from an unregistered endpoint.
Description
Prior to Release 4.5.1, SIP endpoint registration was based on AOR, user ID, and password; there was no verification of the origination of the REGISTER message. Certain service providers may prefer that the source IP address of SIP requests be verified against a provisioned FQDN of the endpoint to address the possibility of theft of VoIP service.
The BTS 10200 can indicate SECURE_FQDN provisioning for specified SIP term-type subscribers. This indication consists of specifying an FQDN with the subscriber AOR. The FQDN is the address/location of the SIP endpoint and is added to the AOR table. The FQDN does not have a service port.
To enable or disable SECURE_FQDN on a successful registered subscriber:
1.
2.
3.
4.
A subscriber with the secure FQDN feature enabled has the following characteristics:
•
•
•
•
•
•
ExampleThis example presents a case in which a VoIP subscriber (Subscriber 1) uses the following options for the user ID, password, and phone number:
•
•
•
Without security, another VoIP subscriber, Subscriber 2, could access Subscriber 1's information (perhaps by getting a Cisco ATA configuration file with the encryption key in clear text, and then getting the full configuration file with all the data). Subscriber 2 could then register with the BTS 10200 with Subscriber 1's combination of user-id-1, password-1, and phone-no-1, as well as Subscriber 2's own IP address. Without the secure FQDN feature, the Cisco BTS 10200 would accept this information unless specific measures were taken, and Subscriber 2 could steal service and make calls on behalf of Subscriber 1.
Provisioning Commands
This section shows the CLI commands you need to provision a secure FQDN of a SIP endpoint.
Note
The SECURE_FQDN token is present in both the subscriber and aor2sub tables. A non-null value in the field indicates that the SECURE_FQDN validations apply to all SIP messages received from the endpoint associated with that AOR.
•
•
•
The aor2sub records cannot be added or deleted directly. To add aor2sub records, you must specify specify the AOR ID on a subscriber record.
Provision a New SIP Subscriber
Step 1
Note
add subscriber id=sub1; sub-profile-id=subpf1; category=individual; dn1=241-555-1018; term-type=SIP; aor-id=<aor-id of SIP adapter port for sub1>; secure-fqdn=<secure-fqdn of the SIP adapter>;Step 2
add subscriber id=sub2; sub-profile-id=subpf1; category=individual; dn1=241-555-1022; term-type=SIP; aor-id=<aor-id of SIP adapter port for sub2>; secure-fqdn=<secure-fqdn of the SIP adapter>;
Note
Enable or Disable Secure FQDN for an Existing Subscriber
To enable or disable the secure FQDN feature for a successfully registered subscriber, enter the following commands:
Step 1
change aor2sub aor-id=241-555-1018@sia-SYS41CA146.ipclab.cisco.com; status=oos;Step 2
change subscriber id=sub1; secure-fqdn=ata-SYS41CA146.ipclab.cisco.comTo disable the secure FQDN feature for an existing subscriber, enter:
change subscriber id=sub1; secure-fqdn=null
Note
Step 3
change aor2sub aor-id=241-555-1018@sia-SYS41CA146.ipclab.cisco.com; status=ins;Step 4
Operations
The system performs the following checks. If any of the following conditions are not met, the request is rejected, and an alarm is generated.
No Calls to or from an Unregistered Secure-Provision SIP Endpoint
An unregistered secure-provision SIP endpoint cannot originate or receive calls.
Third-Party Registrations for Secure FQDN Endpoint Not Allowed
Third-party registrations for secure FQDN endpoints are not allowed.
BTS 10200 Challenges Registration
On receiving a REGISTER message from a secure-provision SIP endpoint, the BTS 10200 challenges the registration, asking for authentication. Verification of the resend REGISTER message with user ID and Password is as follows, after the user ID and Password are authenticated:
•
•
•
If any of these conditions are not met, registration is rejected and a security event and alarm is generated, indicating that the source of the registration is illegal.
The contact address can verify all subsequent SIP request source IP address of the request from the endpoint until the registration expired or is deregistered.
Registration Expires
If the registration expires or the end point de-registers, the registration process in the "BTS 10200 Challenges Registration" occurs before any new calls are accepted.
Call Originates From or Terminates to a Secure-Provision SIP Endpoint
When a call originates from or terminates to a secure-provision SIP endpoint:
1.
2.
3.
4.
Call Processing
The SIP application in the BTS 10200 implements the secure provisioning feature for all incoming SIP messages (requests and responses) from SIP endpoints.
When a SIP request message is received from a SIP endpoint and Auth_Rqed=Y for the serving domain, the request is challenged. When the request is resubmitted with credentials, the AOR of the authenticated SIP endpoint is used to perform the SECURE_FQDN validation, provided a SECURE_FQDN value is provisioned in the AOR2SUB record. If AUTH_REQD=N, the SECURE_FQDN validation is performed without the request being challenged.
Validation
The validation processing for a SIP request, that comes from a SIP endpoint provisioned with this feature, is as follows:
1.
2.
3.
If the address is incorrect, a 500 Internal Server Error response is returned.
4.
If the address is not identical, a 403 Forbidden response is returned.
5.
If there is not a single contact header, a 403 Forbidden response is returned.
6.
If there is not an unexpired registered contact, a 403 Forbidden response is returned.
7.
If it does not yield the proper address, a 500 Internal Server Error response is returned.
8.
If the addresses are not identical, a 403 Forbidden response is returned.
9.
10.
Received SIP Response Message
When a SIP response message is received from a SIP endpoint, the following occurs:
1.
If the addresses are not identical, the response is dropped. This has the same result as the non-receipt of that response, such as would happen with a call failure.
2.
If the address does not resolve properly, the response is dropped. This has the same result as the non-receipt of that response, such as would happen with a call failure.
3.
Rules for Sending a SIP INVITE Message from the BTS 10200
When a SIP INVITE message is sent to a SIP endpoint, the following occurs:
1.
2.
Note
Validation of ACK Request
When a SIP ACK message is received from a SIP endpoint, the following occurs:
1.
2.
Measurements
The following measurements are supported for secure FQDN violations:
•
•
Note
Events and Alarms
A Warning event is raised when a SIP request or response fails the validation for secure SIP endpoints. The alarm has the following attributes:
Type: SECURITY(6)
DESCRIPTION: Secure SIP Endpoint Validation Failure
SEVERITY: WARNING
Note
SIP User Authentication
The BTS 10200 can act as an authentication server. Authentication is enabled on the serving domain through provisioning.
Whenever a SIP request is received from a SIP subscriber, the request is authenticated to ensure it is indeed from an identified user. Authentication also enables request authorization, because users may be authorized to perform only specific requests.
The following examples are the functional scenarios in which authentication is required:
•
•
•
–
–
–
•
The following tables affect authentication for SIP subscribers:
•
•
•
•
See the Cisco BTS 10200 Softswitch CLI Database for more information about the tables.
Figure 2-2 shows how an incoming request is processed and indicates the role of the Authentication Service in the BTS 10200.
Figure 2-2 Authentication and Processing of an Incoming Request (for Example, INVITE)
The BTS 10200 validates the hostname of the REQURI of every incoming SIP request against the list of names provisioned in the serving-domain-name table. The BTS 10200 hostname used by devices (in the REQURI), when they send requests to the BTS 10200, should be provisioned in the serving-domain-name table of that BTS 10200. If a name is not provisioned (and therefore not found) in the serving-domain-name table, the BTS 10200 rejects the SIP request with a "404 Not Found REQURI Serving Domain" response.
The BTS 10200 authenticates IP phones by using the MD5 digest defined in RFCs 3261 and 2617. The BTS 10200 verifies a user's credentials on each SIP request from the user. For more information, see the User Authorization table in the Cisco BTS 10200 Softswitch CLI Database.
SIP Subscriber Calls
SIP subscribers must present valid credentials on a SIP INVITE message in order to place calls.
The system allows SIP subscribers to call other SIP subscribers or SIP trunks connected to the BTS 10200. The provisioned dial plan determines whom a subscriber can call. A SIP subscriber can receive a call as long as the subscription's registration is current, or a static registration has been provisioned.
Provisioning Session Timers for SIP Subscribers
The system uses session timers to periodically refresh SIP sessions during call processing or in-progress calls. You can enable or disable session timers for calls to and from all SIP subscribers on the BTS 10200 through the SUB_SESSION_TIMER_ALLOWED parameter in the ca-config table. The timers are disabled by default.
Use the commands in this section to provision session timers for SIP subscribers. Session timer defaults for subscribers are preset in the system. The timers can be adjusted through the commands shown in this section.
Note
Step 1
Note
The minimum session duration field value is in seconds with a range of 100 to 1800.
We recommend a value of at least 1800 for each of these fields.add sip_timer_profile id=<timer_profile_id>; session_expires_delta_secs=7200; min-se=1800;Step 2
add ca-config type=SUB_SESSION_TIMER_ALLOWED; datatype=BOOLEAN; value=Y;Step 3
add ca_config type=SIP_TIMER_PROFILE_ID; datatype=STRING; value=<sip_timer_profile_id>;
SIP Timer Values for SIP Subscribers
Note
You can customize SIP timers through the sip-timer-profile table. A record in this table can then be configured to apply to all subscribers switch-wide. The system operates with default SIP protocol timer values, as noted in the SIP specification. These default values are adequate for many installations. If customization is required, a sip-timer-profile table can be provisioned and associated with all calls.
Use the following steps to provision the SIP timer values.
Step 1
add sip-timer-profile id=<timer_profile_id>; timer-t1-milli=500;Step 2
add ca-config type=sip_timer_profile_id; datatype=string; value=<sip_timer_profile_id>;
Diversion Indication for SIP Subscribers
Diversion indication provides supplemental redirection information to the SIP entity receiving a call. The SIP entity uses this information to identify from whom the call was diverted, and why the call was diverted. It also provides information for each redirection if multiple redirections occurred. This is provided in the form of a SIP Diversion header.
Forwarding information allows applications such as SIP voice-mail servers to access the mailbox of the original called party for proper outgoing greeting and message deposit when a forwarded call is received. Billing systems also use the information to determine the charged party of the call where it is the last forwarding party that is billed.
The BTS 10200 supports the Diversion Indication feature according to the specifications in the IETF document draft-levy-sip-diversion-02.txt, Diversion Indication in SIP. For incoming calls, the BTS 10200 uses the party number information from the top-most and bottom-most diversion headers. The BTS 10200 reads the diversion count across all diversion headers to determine the total diversion count. For outgoing calls, The BTS 10200 sends 0, 1, or 2 diversion headers, depending on the forwarding information of the call.
Diversion header parameter support is limited to the diversion counter and the diversion reason. These two parameters in diversion headers are populated for outgoing calls and interpreted on incoming calls.
For INVITEs sent out by the BTS 10200, the following behavior applies:
•
•
•
•
•
•
–
–
Comparison of SIP-Based Features and MGCP-Based Features
Table 2-1 lists the MGCP features available (in the MGCP-Based Feature column) and then describes how the feature differs when it is used as a SIP feature.
Table 2-1 MGCP Features and SIP Support
8XX Toll-Free
8xx
Same as MGCP.
911 Emergency-Service
911
Only E911 support (without the suspend procedure for 45 minutes). Basic 911 with suspend procedure is not supported.
Emergency Call (911) is supported for SIP endpoints with one caveat: If the calling party (SIP subscriber) disconnects the call, the called party control is not available. Otherwise, the call will be released. Expanded emergency service (E911) does not require this, but basic emergency service (911) does. Both 911 and E911 are supported for MGCP endpoints.
The Public Safety Answering Point (PSAP) is selected based on default user location. No mobility is supported.
Anonymous Call Rejection
ACR
Same as MGCP, when provided by the BTS 10200. Also provided by the phone.
Anonymous Call Rejection Activation
ACR_ACT
BTS 10200 functionality is same for SIP subscribers as for MGCP.
ACR_ACT is also supported on some SIP phones. Depending on the specific phone, the feature on the BTS 10200 might work jointly with the feature on the phone.
Anonymous Call Rejection Deactivation
ACR_DEACT
BTS 10200 functionality is same for SIP subscribers as for MGCP.
ACR_DEACT is also supported on some SIP phones. Depending on the specific phone, the feature on the BTS 10200 might work jointly with the feature on the phone.
Automatic Callback
AC
SIP phone users cannot activate the service. MGCP users cannot activate the service toward SIP phone users.
Automatic Callback Activation
AC_ACT
SIP phone users cannot activate the service. MGCP users cannot activate the service toward SIP phone users.
Automatic Callback Deactivation
AC_DEACT
SIP phone users cannot activate the service. MGCP users cannot activate the service toward SIP phone users.
Automatic Recall
AR
SIP phone users cannot activate the service. MGCP users cannot activate the service toward SIP phone users.
Automatic Recall Activation
AR_ACT
SIP phone users cannot activate the service. MGCP users cannot activate the service toward SIP phone users.
Automatic Recall Deactivation
AR_DEACT
SIP phone users cannot activate the service. MGCP users cannot activate the service toward SIP phone users.
Busy Line Verification
BLV
Not supported.
CALEA and LI
—
For information on lawful intercept (LI) and Communications Assistance for Law Enforcement (CALEA), see the "Lawful Intercept and Enhanced CALEA" chapter in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions.
Call Block
CBLK
Same as MGCP.
Call Forward Busy 1
CFB
Same as MGCP.
Call Forward Busy Variable Activation
CFBVA
Single-stage digit collection.
Call Forward Busy Variable Deactivation
CFBVD
Same as MGCP.
Call Forward Busy Interrogation
CFBI
Single-stage digit collection.
Call Forward Combined 1
CFC
Same as MGCP.
Call Forward Combined Activation
CFC_ACT
Single-stage digit collection.
Call Forward Combined Deactivation
CFC_DEACT
Same as MGCP.
Call Forward No Answer 1
CFNA
Same as MGCP.
Call Forward No Answer Variable Deactivation
CFNAVA
Single-stage digit collection.
Call Forward No Answer Variable Deactivation
CFNAVD
Same as MGCP.
Call Forward No Answer Interrogation
CFNAI
Single-stage digit collection.
Call Forward Unconditional 1
CFU
Same as MGCP.
Call Forward Unconditional Activation
CFUA
Single-stage digit collection.
Call Forward Unconditional Deactivation
CFUD
Same as MGCP.
Call Forward Unconditional Interrogation
CFUI
Single-stage digit collection.
Call Hold
CHD
Functionality provided by the phone. The BTS 10200 supports the interface.
Call Park
CPRK
Not supported.
Call Park and Retrieve
CPRK_RET
Not supported.
Call Transfer
CT
For SIP phones, this feature is provided as part of REFER support on the BTS 10200. See the "Call Transfer (Blind and Attended) with REFER" section for details.
Call Waiting
CW
Functionality provided by the phone. The BTS 10200 supports the interface.
Call Waiting Deluxe
CWD
Varies with phone functionality.
Call Waiting Deluxe Activation
CWDA
Varies with phone functionality.
Call Waiting Deluxe Deactivation
CWDD
Varies with phone functionality.
Call Waiting Deluxe Interrogation
CWDI
Varies with phone functionality.
Calling Identity Delivery and Suppression (Delivery) 2
CIDSD
Presentation status from the phone, and single-stage digit collection.
Calling Identity Delivery and Suppression (Suppression) 2
CIDSS
Presentation status from the phone, and single-stage digit collection.
Calling Identity Delivery on Call Waiting
CIDCW
Functionality provided by the phone. Cisco BTS 10200 supports the interface.
Calling Name Delivery 3
CNAM
Same as MGCP.
Calling Name Delivery Blocking
CNAB
Presentation status from the phone, and single-stage digit collection.
Calling Number Delivery 3
CND
The calling party number, if available, is delivered in the From header of the outgoing INVITE from the BTS 10200 to the terminating SIP phone. The number is delivered to the SIP phone even if the CND feature is not provisioned for the subscriber.
Calling Number Delivery Blocking
CNDB
Presentation status from the phone, and single-stage digit collection.
Cancel Call Waiting
CCW
Functionality provided by the phone. Cisco BTS 10200 supports the interface.
Class of Service
COS
CoS screening is supported for SIP subscribers.
For account code and authorization code features on SIP endpoints, the BTS 10200 uses only the Interactive Voice Response (IVR)-based method of prompting, not the tone-based method. For account codes and authorization codes, the system applies IVR-based prompts for SIP endpoints, regardless of the values you provision for the PROMPT_METHOD parameter in the cos-restrict table.
To provision these features, see the "Class of Service Screening" provisioning procedure in the Provisioning Guide.
Custom-Dial-Plan
CDP
Same as MGCP.
Customer Originated Trace
COT
Same as MGCP.
Directed Call Pickup without Barge-in
DPN
Not supported.
Directed Call Pickup with Barge-in
DPU
Not supported.
Distinctive Alerting Call Waiting Indication
DACWI
This feature is provided to Centrex users only.
Provisioning for SIP does not differ from provisioning for MGCP. However, the delivery method for DACWI is different.
The Centrex administrator provisions a list of DNs that are to receive DACWI tones.
In MGCP, the phone plays the tone specified by the BTS 10200 in the protocol message. In SIP, the tone provisioned for the DN is specified by the BTS 10200 in the Alert-Info header of the INVITE as a file URL. A SIP phone, if capable, interprets this header and plays the specified distinctive ringing or call-waiting tone.
Distinctive Ringing Call Waiting
DRCW
Provisioning for SIP does not differ from provisioning for MGCP. However, the delivery method for DRCW is different.
The subscriber provisions a list of DNs to receive DRCW tones.
In MGCP, the phone plays the tone specified by the Cisco BTS 10200 in the protocol message. In SIP, the tone provisioned for the DN is specified by the Cisco BTS 10200 in the Alert-Info header of the INVITE as a file URL. A SIP phone, if capable, can interpret this header and play the specified distinctive ringing or call-waiting tone.
Distinctive Ringing Call Waiting
DRCW_ACT
Same as MGCP.
Do Not Disturb
DND
Same as MGCP, except that the reminder ring cannot be used with SIP devices. For additional information on DND, see the "Do Not Disturb" section.
Do Not Disturb Activation
DND_ACT
Same as MGCP.
Do Not Disturb Deactivation
DND_DEACT
Same as MGCP.
Group Speed Call—1 Digit
GSC1D
Not supported.
Group Speed Call—2 Digit
GSC2D
Not supported.
Hotline
HOTLINE
Not supported.
Hotline Variable
HOTV
Not supported.
Hotline Variable Activation
HOTVA
Not supported.
Hotline Variable Deactivation
HOTVD
Not supported.
Hotline Variable Interrogation
HOTVI
Not supported.
Incoming Simulated Facility Group
ISFG
Same as MGCP.
Local Number Portability
LNP
Same as MGCP.
Multiline Hunt Group
MLHG
MLHG is supported for SIP subscribers. SIP subscriber provisioning is slightly different than MGCP and Network-based Call Signaling (NCS) subscriber provisioning. For the differences between the MGCP-based procedures and the SIP-based procedures see the "Multiline Hunt Group (MLHG)" section in the Network and Subscriber Feature Descriptions document.
Some MLHG features are applied differently for SIP subscribers than for MGCP/NCS subscribers.
•
•
For additional feature details, see the "Multiline Hunt Group (MLHG)" section in the Network and Subscriber Feature Descriptions.
Multiple Directory Number
MDN
Provisioning for SIP does not differ from provisioning for MGCP. However, the delivery methods for distinctive-ringing (a distinctive ring tone for each line of the MDN subscriber), and the distinctive tone on call waiting are different.
You provision distinctive ringing and call waiting tones for each DN of the MDN subscriber in the same manner for MGCP and SIP. In MGCP, the phone plays the tone specified by the Cisco BTS 10200 in the protocol message. In SIP, the tone provisioned for the DN is specified by the Cisco BTS 10200 in the Alert-Info header of the INVITE as a file URL. A SIP phone, if capable, can interpret this header and play the specified distinctive ringing or call waiting tone.
Outgoing Call Barring
OCB
Same as MGCP.
Outgoing Call Barring Activation
OCBA
Single stage digit collection.
Outgoing Call Barring Deactivation
OCBD
Single stage digit collection.
Outgoing Call Barring Interrogation
OCBI
Single stage digit collection.
Outgoing Simulated Facility Group
OSFG
Same as MGCP.
Remote Activation of Call Forwarding
RACF
Same as MGCP.
Remote Activation of Call Forwarding PIN
RACF_PIN
Same as MGCP.
Refer
REFER
This is not for MGCP users. Cisco BTS 10200 supports the SIP REFER interface to enable services such as Call-Transfer (attended, unattended) provided by the phone.
Selective Call Acceptance
SCA
Same as MGCP.
Selective Call Acceptance Activation
SCA_ACT
Same as MGCP.
Selective Call Forwarding
SCF
Same as MGCP.
Selective Call Forwarding Activation
SCF_ACT
Same as MGCP.
Selective Call Rejection
SCR
Same as MGCP.
Selective Call Rejection Activation
SCR_ACT
Same as MGCP.
Speed Call—1 Digit
Speed Call—2 Digit
SC1D
SC2D
Same as MGCP.
Speed Call Activation—1 Digit
Speed Call Activation—2 Digit
SC1D_ACT
SC2D_ACT
Speed call activation is supported for SIP subscribers.
For MGCP and NCS endpoints, subscriber data provisioning (speed call digits and DN) is performed by the end user on the handset. However, for SIP endpoints, handset provisioning is not supported; therefore the service provider should perform this provisioning through the add sc1d and add sc2d CLI commands. For the complete provisioning procedures, see the "Features" chapter of the Provisioning Guide.
Three-Way Calling
TWC
Functionality provided by the phone. The BTS 10200 supports the interface.
Three-Way Call Deluxe
TWCD
Varies with phone functionality.
Usage-Sensitive Three-Way Calling
USTWC
Functionality provided by the phone. The BTS 10200 supports the interface.
Warmline
WARMLINE
Not supported.
1 See additional information on call forwarding features in the "Call Forwarding" section.
2 See additional information on the delivery and suppression feature in the "Caller ID Delivery Suppression" section.
3 See additional information on calling name and calling number in the "Calling Name and Number Delivery" section.
Cisco BTS 10200 Softswitch-Based Features
Softswitch-based features are directly provided by the BTS 10200. SIP phones can provide some features on their own; for information on the features provided by the different SIP phones, see the SIP phone administration guides.
This section describes Softswitch-based features entirely provided by the BTS 10200.
Note
Summary
Table 2-2 lists the most commonly used features; however, it is not an exhaustive list.
Note
s
Call Forwarding
The differences between the feature for SIP and the feature for MGCP are as follows:
•
•
Call Forwarding Activation and Deactivation
Activation and deactivation of call forwarding features use the vertical service code (VSC), also known as a star code.
With SIP support, the call forwarded to number can be a Centrex extension number (only applicable for business users) or an E.164 number.
Note
SIP subscribers do not hear a final dial tone upon completing activation or deactivation. Instead, an announcement plays for the subscriber, indicating that the status of the forwarding feature is being activated or deactivated. This is irrespective of the Final Stage Dial Tone (FDT) flag (Y/N) provisioned for these features.
Call Forwarding to an E.164 Number or an Extension Number
Activation and deactivation are accomplished using single-stage dialing.
Detailed Provisioning Procedure and Feature Description
Additional information on this feature is provided at the following links:
•
•
Calling Name and Number Delivery
Calling number delivery (CND) provides the SIP subscriber endpoint with the calling number of an incoming call. Calling name delivery (CNAM) provides the endpoint with the name of the calling party.
CND
The calling party number, if available, is delivered in the From header of the outgoing INVITE from the BTS 10200 to the terminating SIP phone. The number is delivered to the SIP phone even if the CND feature is not provisioned for the subscriber. The delivered information is as follows:
•
•
•
CNAM
The calling party name is delivered in the outgoing INVITE from the BTS 10200 to the terminating SIP phone only if the CNAM feature is provisioned for the SIP subscriber. The delivered information is as follows:
•
•
•
Additional information on this feature is provided at the following links:
•
•
Caller ID Delivery Suppression
The treatment for caller's identity is based on the presence of "anonymous" in the Display-Name field of the From header in the INVITE message. If the caller's identity is restricted in the incoming SIP INVITE message, the presentation is suppressed.
Caller Identity presentation (allowed/restricted) information for SIP subscribers is not maintained in the the BTS 10200 database. This information is maintained on the individual phones and can be provisioned through the phone softkeys. Permanent restriction on the phone can be overridden if the caller dials a feature (*) code on a per-call basis. This is a single-stage dialing for SIP subscribers.
Additional information on this feature is provided at the following links:
•
•
Customer Access Treatment
Provisioning this feature for SIP is the same as provisioning it for MGCP. The provisioning commands for this feature are shown in the "Centrex Group" section in the Cisco BTS 10200 Softswitch Provisioning Guide.
Direct Inward Dialing
Provisioning Direct Inward Dialing (DID) for SIP is the same as provisioning it for MGCP.
Assign the DID number to the subscriber as DN1 in the Subscriber table.
For information about the operation of this feature, see the "Direct Inward Dialing" section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions.
Direct Outward Dialing
With the Direct Outward Dialing (DOD) service, a station user can place external calls to the exchange network without attendant assistance by:
1.
2.
3.
Access to the DOD feature is subject to station restrictions.
Note
For information about the operation of this feature, see the "DOD for PBX" section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions.
Do Not Disturb
The Do Not Disturb (DND) feature enables a user to block incoming calls to the station on which the feature is activated. If no call forwarding features are activated, calls to the station are routed to busy treatment. This feature should be provisioned and activated on the BTS 10200 because of feature interaction with advanced features like executive override.
This is a single-stage dialing activation feature. The Alert-Info header plays the result of activation/deactivation—Success is a confirmation tone and failure is a failure message.
The reminder ring option (which is available with the DND feature on MGCP-based lines) cannot be used with SIP devices.
For features (such as DND) that can be fully provisioned on the BTS 10200 or on the phone, you can provision either one of the devices to enable the feature.
Caution
Additional information on this feature is provided at the following links:
•
•
E.164 and Centrex Dialing Plan (Extension Dialing)
The system supports E.164 and Centrex Dialing Plan (extension dialing) addressing from SIP subscribers served by the local BTS 10200.
The SIP phone's dial plan must be configured so that it factors in the number of digits in the Centrex group. Centrex dialing can be provisioned within a range of 1 through 7 digits. Each Centrex group should have its own separate dial plan.
Note
A SIP URL with E.164 Addressing would look similar to the following example:
sip:4695550123@rcdn.cisco.com;user=phoneA sip:50603@rcdn.cisco.com;user=phoneAdditional information on this feature is provided at the following links:
•
•
•
Operator Services (0-, 0+, 01+, and 00 Calls)
There is no Cisco BTS 10200 Softswitch subscriber-specific provisioning involved for Operator Services.
Additional information on this feature is provided in the "Operator Services" section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions.
User-Level Privacy
User-level privacy is provisioned in the Subscriber table.
Setting the privacy parameter to user directs the system to apply the user-provided privacy information. This setting (privacy=user) applies only to SIP endpoints that are capable of including privacy information.
Vertical Service Code Features
This section explains how to plan VSCs in a network with SIP subscribers, and lists the VSC-enabled features.
Planning VSCs In Networks with SIP Subscribers
Some features require SIP subscriber to enter a series of numbers and characters on the SIP client or handset. Typically, the subscriber dials VSC digits followed by additional dialing keys representing the parameters for the feature call. For MGCP subscribers, the BTS 10200 sends a response tone or announcement between the VSC code and the additional digits. However, for SIP endpoints, all the digits are dialed at a stretch without waiting for an intervening response tone from the BTS 10200. The following paragraph explains how certain combinations of VSC can cause mismatches between the feature the subscriber is attempting to manage versus the response of the BTS 10200, and how to plan VSCs to avoid these mismatches.
You should not deploy certain combinations of VSCs on networks with SIP endpoints. If you deploy a VSC longer than 2 digits, make sure that the longer VSC does not begin with the same sequence of characters as one of the shorter VSCs. In some cases, the system might match the shorter string even if the subscriber dialed the longer string. Consider the following example, for which the subscriber is expected to dial a VSC followed by a DN.
A SIP subscriber is provisioned with *93 for Feature1 and *938 for Feature2, and dials *938+2135551801 to invoke Feature2. The BTS 10200 receives *9382135551801 in the INVITE message. By default, it takes the first six characters, in this case *93821, and uses this string to look up the feature in the VSC table. There is no match for *93821, therefore the BTS 10200 proceeds as follows. First, it uses *9 to look for a match in the VSC table and it cannot be found. Then it uses *93, finds a match, and delivers Feature1. This is incorrect. The user's intention was to invoke Feature2 and not Feature1. The solution is for the service provider to change one of the two VSCs (either *93 or *938) in the VSC table.
Supported VSC-Enabled Features for SIP Endpoints
The following BTS 10200 Vertical Service Code (VSC) features are supported on SIP endpoints:
•
•
•
•
•
Reminder ringback cannot be enabled for SIP subscribers. If you are turning on the CFU feature for a SIP subscriber, make sure that reminder ring capability is turned off. This should be done at a subscriber level.
Here is the command format at the feature level:
add feature fname=CFU; tdp1=TERMINATION_ATTEMPT_AUTHORIZED; tid1=TERMINATION_ATTEMPT_AUTHORIZED; feature_server_id=FSPTC235; ttype1=R; fname1=CFUA; fname2=CFUD; type1=MCF; value1=Y; type2=RR; value2=N; description=CFU MCF multiple call forwarding allowed, RR ring reminder not allowed;Here is the command format at the subscriber feature level:
add subscriber-feature-data sub_id=sip_sub2; FNAME=CFU; type2=RR; VALUE2=N;•
•
•
Voice Mail
The voice-mail (VM) feature on the BTS 10200 allows subscribers to retrieve waiting voice messages from a VM server. The BTS 10200 receives a message-waiting indication (MWI) from the VM server and forwards the MWI to the subscriber's handset. The subscriber can then retrieve messages from the server. The VM feature is available to individual subscribers and Centrex subscribers.
SIP trunks interconnecting the BTS 10200 to an external VM server must be provisioned as SIP VM trunks. To do that, you set the VM flag (voice-mail-trunk-grp) for these trunks in the Softswitch Trunk Group Profile (softsw-tg-profile) table. (See the "SIP Trunk to Voice-Mail Server" section on page 3-48.)
Note
VM Actions
The following voice mail-related actions are supported in the BTS 10200:
•
VM Deposit
There are two methods for depositing voice mail. In the first, the subscriber dials the pilot number for the VM server, and the call terminates on the voice-mail trunk. The VM system then collects the message for a target mailbox, using IVR prompts to guide the subscriber.
This method of depositing voice mail does not use any special BTS 10200 capabilities; it just requires that the VM SIP trunk is provisioned and the pilot number is added to the dial plan of the subscriber calling the VM system.
In the second (more common) method, the subscriber activates a call forwarding feature on the BTS 10200, such as CFNA, CFU, or CFB, and specifies the forwarding number as the pilot number of the VM server.
MWI Notification
When a SIP phone registers with the BTS 10200, the BTS 10200 sends an unsolicited SIP NOTIFY message to convey the MWI status to the phone. This occurs on every registration, including refreshes.
Whenever a change in VM status occurs for a subscriber (for example, when a VM message is deposited for the subscriber, or when all such messages have been retrieved), the VM server sends an update to the BTS 10200. If the subscriber is on a SIP phone, the BTS 10200 sends an unsolicited SIP Notify message to convey the MWI status to the phone. The number in the NOTIFY message Request URL (which is the assigned subscriber number) identifies the subscriber.
When the BTS 10200 is congested by a flood of registrations (which might occur, for example, when power is restored to a region after an outage), it can automatically suppress the MWI indication to the registering phones, so that registration throughput is not adversely affected.
The BTS 10200 implements draft-ietf-sipping-MWI-01.txt, A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP), with the following caveat: It supports receiving unsolicited NOTIFYs from a VM system; however, it does not support subscribing to these notifications. Further, the BTS 10200 does not support subscriptions for MWI. It sends unsolicited NOTIFYs for MWI to SIP subscribers. No subscription is expected from the SIP phones for the purpose of receiving this notification.
The notification of MWI by the BTS 10200 is enabled by default (VMWI=Y in the Subscriber table). You can disable it by setting VMWI=N.
Tip
For information on setting the MWI and VMWI parameters in the Subscriber table, see the "Message Waiting Indicator (MWI)—Audible and Visual" section in the Cisco BTS 10200 Softswitch Network and Feature Descriptions.
Retrieving VM
To retrieve a VM message, subscribers dial the pilot number for the VM server. The BTS 10200 routes the call to the SIP trunk for VM, based on the provisioned dial plan for the subscriber and the route, destination, and trunk-group entries.
Once the VM message is retrieved, the VM server sends a NOTIFY message to the BTS 10200 to turn off the MWI indicator.
Calling Back a Message Depositor
When subscribers call into a VM server, this feature allows for calling back the person who left the voice-mail message. The feature requires that a Softswitch trunk for the VM server be provisioned in the Cisco BTS 10200 Softswitch with the relevant routes, destination, and dial plans in order to admit VM-originated calls into the BTS 10200.
VM Implementation for Centrex Subscribers
For calls received on SIP VM trunks from the VM server, a subscriber is provisioned and associated as the main sub-ID for each trunk. The subscriber information represents properties of a specific Centrex group and does not represent any particular subscriber. No AOR is provisioned for this subscriber. This information is used for call processing.
Note
VM Within a Single Centrex Group
The following examples show commands for provisioning Centrex VM. Before you perform the following steps, you must already have a Centrex group provisioned on your system. See the procedure in the "Centrex Group" section of the Cisco BTS 10200 Softswitch Provisioning Guide.
Step 1
add destination dest-id=tb16-local; call-type=LOCAL; route-type=SUB;Step 2
add dial-plan-profile id=tb16;add dial-plan id=tb16; digit-string=469-555; dest-id=tb16-local; min-digits=10; max-digits=10Step 3
add softsw-tg-profile id=VM_Profile; protocol-type=SIP; voice_mail_trunk_grp=Y;
Note
Step 4
Note
add trunk-grp id=80032; softsw-tsap-addr=vm.domainname.com:5060; call-agent-id=CA146; tg-type=softsw; tg-profile-id=VM_Profile; dial-plan-id=tb16Step 5
add subscriber id=vmctxg1; CATEGORY=ctxg; BILLING-DN=469-555-0144; DN1=469-555-0144; SUB-PROFILE-ID=Centrex_sp2; TERM-TYPE=TG; ctxg_id=ctxgsip1; tgn_id=80032;Step 6
change trunk-grp; id=80032; main_sub_id=vmctxg1;Step 7
add ext2subscriber CTXG-ID=ctxgsip1; EXT=540144; CAT-CODE=1; SUB-ID=vmctxg1;Step 8
Provisioning Voice Mail Across Multiple Centrex Groups
A VM application server can provide VM service for Centrex subscribers from multiple Centrex groups on the BTS 10200. For the VM server to identify the subscriber and provide service configured for a Centrex group, the BTS 10200 must indicate the Centrex group with which the subscriber is associated.
When the BTS 10200 forwards a call from a Centrex extension to VM, the VM server identifies the Centrex group of the extension to deposit the message in the correct mailbox. Further, when the VM server sends a SIP NOTIFY message to indicate that messages are waiting for a Centrex subscriber on the BTS 10200, it must identify the Centrex group in the request URI of the NOTIFY message sent to the BTS 10200.
For any INVITE sent out a SIP trunk by the BTS 10200 to the VM server, a BTS 10200 proprietary SIP URL parameter bgid is added to the From, To, Diversion, and Request URIs, if the user part of those URLs contains a Centrex extension number format in the user information field. The bgid value is provisioned as the trunk-subgroup-type on the SIP trunk, and identifies the Centrex group.
An example of this parameter syntax follows:
INVITE sip:50001@vm.cisco.com:5060;user=phone;bgid=grpA SIP/2.0From: <sip:50603@bts.cisco.com;user=phone;bgid=grpA>;tag=1_1146_f40077_3jwvTo: <sip:50586@bts.cisco.com;user=phone;bgid=grpA>Diversion: <sip:50586@bts.cisco.com;bgid=grpA>;reason=unconditional;counter=1When the VM server notifies the BTS 10200 of a MWI for a Centrex subscriber, the VM server sends a Notify SIP request to the BTS 10200 with a Centrex number format in the Request URL, and an associated bgid parameter identifying the Centrex group associated with the subscriber. When the VM server initiates a call to a BTS 10200 Centrex subscriber for VM callback functionality, bgid is added to the request URL of the initial INVITE originating from the VM server. This identifies the Centrex group associated with the subscriber.
The BGID parameter in the REQURI of an INVITE originated from the VM server identifies the called subscriber in the targeted Centrex group. For example, the BGID parameter in the REQURI of a NOTIFY message from the VM server to the BTS 10200 identifies the subscriber in the targeted Centrex group whose MWI lamp is turned on or off.
The BTS 10200 does not support extension-dialed calls from one Centrex group to another. Therefore, the bgid parameter has an identical value if it is present in any of the URLs in the From, To, Diversion, and Request URL headers for a given INVITE message. The trunk group configuration includes a trunk subgroup field for specifying the bgid parameter value. One trunk group is provisioned for each Centrex group; the bgid parameter in the trunk group table is unique to the specific Centrex group. Routing tables are configured so that each trunk handles SIP calls to and from the VM server for a specific Centrex group. To qualify a specific trunk for bgid and VM, provision as follows:
•
•
–
–
The following provisioning steps illustrate how to provide VM service for BTS 10200 Centrex subscribers across multiple Centrex groups.
Step 1
add softsw_tg_profile ID=<profile_id>; PROTOCOL_TYPE=SIP; VOICE_MAIL_TRUNK_GRP=Y; TRUNK_SUB_GRP_TYPE=BGID;Step 2
In the following command, be sure to enter a unique business group identifier for each Centrex group, for example, bg1, bg2, and bg3, for the three Centrex groups in this example.
Also, be sure to specify the FQDN and port that the VM server uses for SIP message exchange, for example, vmserver:5060.
add trunk_grp ID=<trk_grp_id1>; TG_TYPE=SOFTSW; TG_PROFILE_ID=<profile_id>; SOFTSW_TSAP_ADDR=vmserver:5060; DIAL_PLAN_ID=dp; TRUNK_SUB_GRP=bg1;add trunk_grp ID=<trk_grp_id2>; TG_TYPE=SOFTSW; TG_PROFILE_ID=<profile_id>; SOFTSW_TSAP_ADDR=vmserver:5060; DIAL_PLAN_ID=dp; TRUNK_SUB_GRP=bg2;add trunk_grp ID=<trk_grp_id3>; TG_TYPE=SOFTSW; TG_PROFILE_ID=<profile_id>; SOFTSW_TSAP_ADDR=vmserver:5060; DIAL_PLAN_ID=dp; TRUNK_SUB_GRP=bg3;Step 3
Jointly Provided Features
Some features are provided jointly by the phone and by the BTS 10200. Here are some examples:
•
•
The sections that follow provide information about these features.
Call Transfer (Blind and Attended) with REFER
The SIP Call Transfer (CT) feature is supported for SIP subscribers. For SIP phones, this feature is provided as part of REFER support on the BTS 10200.
The CT feature requires phone support for sending the SIP REFER message. See the phone documentation for details on the user interface and procedures for effecting a call transfer. Both blind and attended transfers are supported. Attended transfer to a transfer-target is supported only after the target answers; that is, consultative attended transfer is supported. Attended transfer is not possible while the transfer-target is being alerted (ringing state).
The difference between provisioning the feature for SIP and provisioning it for MGCP is as follows:
•
•
Distinctive Ringing
Distinctive ringing uses a special ringing pattern to alert the called user of incoming calls from preselected telephone numbers. This is a CLASS feature and is offered to both business and residential users. There is no difference between provisioning the feature for SIP and provisioning it for MGCP.
You can edit the list of selected numbers though the Screening List Editing (SLE) feature, which requires the configuring of an IVR with the BTS 10200. Distinctive ringing can be assigned to a station and to the group, and it can be applied to users based on the call type/calling number. When assigned to a group, distinctive ringing is applied to users in the group based on the call type. When assigned to the line, distinctive ringing is applied to the user based on the calling number. The BTS 10200 sends an Alert-Info header in the outgoing INVITE message, instructing the SIP phone to play a specific ring tone.
Distinctive ringing depends on the SIP phone's capability to support processing of the information received in an Alert-Info header.
Distinctive Ringing for Centrex DID Calls
The BTS 10200 sends an Alert-Info header in the outgoing INVITE message, instructing the SIP phone to play a specific ring tone. Distinctive ringing depends on the SIP phone's capability to process the information received in the Alert-Info header. There are no differences between provisioning the feature for SIP and provisioning it for MGCP.
Phone-Based Features
The phone provides some features standalone, without BTS 10200 support. If the SIP phone requires provisioning to provide this function, refer to the SIP phone documentation for instructions.
Table 2-3 lists the phone-based features.
.
Table 2-3 SIP Phone-Based Features
Call Hold and Resume
CHD
Call Waiting
CW
Call Waiting Caller ID
CWCID
Cancel Call Waiting
CCW
CODEC Up-Speeding
CODEC1
Do Not Disturb
DND
Three-Way Calling
TWC
1 For feature calls between MGCP and SIP subscribers, the BTS 10200 supports the CODEC up-speeding capability. The SIP phone would also need to support this capability for the up-speeding capability to be fully supported in the call.
For features (such as DND) that are available independently on the phones and the BTS 10200, you can provision either device to enable the feature.
Caution
