Feedback
Table Of Contents
SIP Protocol Subscriber Features
Cisco BTS 10200 Softswitch-Based Features
Activation and Deactivation of Anonymous Call Rejection
Call Forwarding Activation and Deactivation
Call Forwarding to an E.164 Number or an Extension Number
Calling Name and Number Delivery
Caller ID Delivery Suppression
Called Party Termination is Not Available/Not Reachable
Called Party Termination is Not Registered
Cisco BTS 10200 Supplementary Vertical Service Code Features
E.164 and Centrex Dialing Plan (Extension Dialing)
Incoming and Outgoing Simulated Facility Group
Operator Services (0-, 0+, 01+, 00 Calls)
Remote Activation of Call Forwarding
Calculation of Timer Retransmission Count
Reliable Provisional Responses
Call Transfer (Blind and Attended)
Distinctive Ringing for Centrex DID Calls
SIP Protocol Subscriber Features
Revised: May 3, 2007, OL-5352-12Cisco BTS 10200 supports SIP subscribers such as SIP phones compliant with RFC 3261 or RFC 2543. The SIP protocol support in Cisco BTS 10200 provides the capability to provision subscriber features, and to allow SIP devices to work with the Cisco BTS 10200 Softswitch. This chapter describes the subscriber features.
Note
For quick-reference tables listing the Subscriber features, see Chapter 1.
This section covers the following topics:
•
•
SIP Phone Initialization
Figure 2-1 shows SIP phone initialization on bootup.
The image shows actions that occur external to Cisco BTS 10200—it does not show how Cisco BTS 10200 controls SIP initialization, but rather is representative of how a client may establish its identity with Cisco BTS 10200.
The numbers in the image reference the numerical order in which the sequence would occur.
Figure 2-1 SIP Phone Initialization
SIP Devices
The following Cisco SIP devices, when running a SIP application image, are supported on Cisco BTS 10200:
•
•
•
•
•
•
For more information on provisioning devices, see the Provisioning SIP Devices section in the Cisco BTS 10200 SIP Protocol Provisioning Guide.
You can find the detailed step-by-step administration guide for the Cisco ATA 186/188 adaptors at:
http://www.cisco.com/univercd/cc/td/doc/product/voice/ata/ataadmn/index.htm
You can find the detailed step-by-step administration guide for the Cisco 7905/7912 phones at:
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/english/ipp7905g/addprot/index.htm
You can find the detailed step-by-step administration guide for the Cisco 7940/7960 phones at:
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/sip7960/sadmin31/index.htm
For multiple line SIP phones, each line must be provisioned with a DN/Subscriber entry in the Cisco BTS 10200 Softswitch.
SIP Registration and Security
SIP subscribers use the SIP REGISTER method to record their current locations with Cisco BTS 10200. Registering clients may specify an expiry time for the contacts being registered. However, Cisco BTS 10200 has a minimum and maximum acceptable duration which are configurable.
Note
It is possible to register multiple contacts for a single Address of Record (AOR); however, if multiple contacts are registered for a single subscriber, Cisco 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 Cisco BTS 10200 challenges the SIP subscriber based on the Serving Domain Name table. If the Serving Domain Name Table indicates that authentication is required, the Cisco BTS 10200 challenges the SIP request (Register/INVITE) according to the authentication procedures specified in the SIP Protocol RFC 3261). If the Cisco BTS 10200 receives valid credentials, then the authenticated AOR from the User Authentication table identifies the subscriber based on the Address of Record to Subscriber table.
Registration creates bindings in Cisco BTS 10200 that associate an AOR with one or more contact addresses.
The registration data is replicated on the standby Cisco BTS 10200 Softswitch. The Cisco 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 Cisco BTS 10200 generates a warning event when a request from a client fails authentication. This can be indicative of a provisioning error, or of an attempt by an unauthorized client to communicate with the Cisco BTS 10200.
The contacts registered for an AOR may be looked up using the status command, as demonstrated by the following example.
CLI>status sip-reg-contact AOR_ID=4695551884@sia-SYS44CA146.ipclab.cisco.comAOR ID -> 4695551884@sia-SYS44CA146.ipclab.cisco.comUSER -> 4695551884HOST -> 10.88.11.237PORT -> 5060USER TYPE -> USER_PHONE_TYPEEXPIRES -> 3600EXPIRETIME -> Thu Jan 22 14:33:36 2004STATUS -> REGISTERED CONTACTReply :Success:Enhanced SIP Registration
Enhanced SIP Registration was added to Release 4.5.x to ensure that a SIP REGISTER message to the Cisco 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.
In previous releases, SIP endpoint registration was based on Address of Record (AOR), UserID 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 Cisco BTS 10200 can indicate SECURE_FQDN provisioning for specified SIP term-type subscribers. This indication consists of specifying a Fully Qualified Domain Name (FQDN) with the Subscriber Address of Record (AOR). The FQDN is the address/location of the SIP endpoint and is added to the AOR table. The FQDN will not have a service port.
To enable or disable SECURE_FQDN on a successful registered subscriber:
1.
2.
3.
4.
Note
A subscriber with the secure FQDN feature enabled has the following characteristics:
•
•
•
•
•
•
Example:This example considers a case in which a VoIP subscriber (Subscriber 1) uses 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 to the Cisco 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
In Release 4.5.x, a new field, SECURE_FQDN, was added to 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.
•
•
•
AOR2SUB records cannot be added or deleted directly. AOR2SUB records are added by specifying the AOR ID on a subscriber record.
Operations
The following checks were added to Release 4.5.x. 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 endpoint are not allowed.
Cisco BTS 10200 Challenges Registration
On receiving a REGISTER message from a secure-provision SIP endpoint, the Cisco BTS 10200 challenges the registration asking for authentication. Verification of the resend REGISTER message with UserId and Password is as follows, after the UserId and Password is 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 "Cisco BTS 10200 Challenges Registration" section occurs before any new calls are accepted.
Call Originates From or Terminate to a Secure-Provision SIP Endpoint
When a call originates from or terminates to a secure-provision SIP endpoint, the system:
1.
2.
3.
4.
Call Processing
The SIP Application in Cisco 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, from a SIP endpoint provisioned with this feature, is as follows:
1.
2.
If not, a 500 Internal Server Error response is returned.
3.
If not, a 500 Internal Server Error response is returned.
4.
If not, a 403 Forbidden response is returned.
5.
If not, a 403 Forbidden response is returned.
6.
If not, a 403 Forbidden response is returned.
7.
If not, a 500 Internal Server Error response is returned.
8.
If not, 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 not, the response is dropped. This has the same result as the non-receipt of that response, such as a call failure.
2.
If not, the response is dropped. This has the same result as the non-receipt of that response, such as a call failure.
3.
Rules for Sending a SIP INVITE Message from Cisco 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
This section lists the measurements that are new, modified, or deleted as a result of the features covered by this document. The measurements are grouped into logical categories for easy identification.
Note
The following TMM counters were added to Release 4.5.x:
•
•
Events and Alarms
A Warning event is raised when a SIP a request or response fails the validation for secure SIP endpoints. The alarm has the following attributes:
Component Id: Security
Type: SECURITY(6)
DESCRIPTION: Secure SIP Endpoint Validation Failure
SEVERITY: WARNING
INITIAL RELEASE: 4.5
THRESHOLD: 100
THROTTLE: 0
END-CUSTOMER PERCEPTION: No impact
DATAWORDS:
string: AOR
string: Secure Fqdn
string: Source IP Address
string: Violation Description
SIP User Authentication
The Cisco BTS 10200 Softswitch 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, since users may be authorized to perform only specific requests.
The following examples are the functional scenarios in which authentication is required:
1.
2.
3.
–
–
–
4.
The following new tables have been defined for SIP subscribers, which are pertinent to Authentication:
•
•
•
•
See "Database Tables" for more information about the tables.
Figure 2-2 shows how an incoming request is processed, and the role of the Authentication Service in the Cisco BTS 10200.
Figure 2-2 Authentication and Processing of an Incoming Request (e.g. 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 sending 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 Authentication" section.
Cisco BTS 10200 Softswitch-Based Features
Softswitch-based features are directly provided by the Cisco BTS 10200 Softswitch. SIP phones may 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 Cisco BTS 10200 Softswitch.
For information on MGCP features in previous Cisco BTS 10200 releases, and how they compare with SIP features in Release 4.5.x, see "MGCP Features vs. SIP Features."
Note
Activation and Deactivation of Anonymous Call Rejection
Anonymous Call Rejection (ACR) activation and deactivation is supported through a feature (*) code. It is supported on a SIP endpoint, and supports single-stage dialing.
ACR has multiple activation options as follows:
•
•
–
–
–
Note
ACR deactivation options are as follows:
•
•
–
–
–
Note
For more information, see the Anonymous Call Rejection section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions guide.
Billing
The Cisco BTS 10200 Softswitch provides call data for billing on SIP calls. Specific fields are supported in the call detail data records for calls that originate or terminate on a SIP trunk or subscriber. For detailed information on billing management and data, see the Cisco BTS 10200 Softswitch Billing Interface Guide.
CALEA Call Content
CALEA is not available for SIP subscribers.
Call Forwarding
For more information, see the Call Forwarding Features section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions guide.
Call Forwarding Activation and Deactivation
Activation and deactivation of call forwarding features uses the star code. Alternately, the feature may be activated or deactivated by using the Services key on certain phones.
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
In Release 4.5.x, activation is accomplished using single-stage dialing. This applies to all activation and deactivation.
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:
•
•
•
For more information, see the Calling Number Delivery section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions guide, and the CND and CNAM sections in the Cisco BTS 10200 Softswitch Provisioning Guide.
Caller ID Delivery Suppression
The treatment for caller's identity is based on presence of "anonymous" in the Display-Name field of From header in the INVITE. Caller Identity presentation (allowed/restricted) information for SIP subscribers is not maintained in the Cisco BTS 10200 Softswitch database.
This information is maintained on the individual phones, and can be provisioned through the phones' softkeys. If the caller's identity is restricted in the incoming SIP INVITE message, the presentation is suppressed. You can override permanent restriction on the phone by the caller dialing a feature (*) code on a per-call basis. This is a single-stage dialing for SIP subscribers.
Called Party Termination
Called Party Termination is Not Available/Not Reachable
This feature was introduced in a previous Cisco BTS 10200 Softswitch release. There are no differences when provisioning the feature for SIP.
Called Party Termination is Not Registered
This feature was introduced in a previous Cisco BTS 10200 Softswitch release. There are no differences when provisioning the feature for SIP.
Cisco BTS 10200 Supplementary Vertical Service Code Features
The following Cisco BTS 10200 Vertical Service Code (VSC) features are supported on SIP endpoints:
•
•
•
•
Note
The command format would be as follows at the feature level:
add feature fname=CFU; tdp1=TERMINATION_ATTEMPT_AUTHORIZED;
tid1=TERMINATION_ATTEMPT_AUTHORIZED; ttype1=R; fname1=CFUA;
fname2=CFUD; type1=MCF; value1=Y; type2=RR; value2=N;
description=CFU MCF=multiple call forwarding allowed, RR=ring reminder;
feature_server_id=FSPTC235;
And at the Subscriber feature level:
add subscriber-feature-data
sub_id=sip_sub2;FNAME=CFU;type2=RR;VALUE2=N•
•
•
Note
Customer Access Treatment
This feature was introduced in a previous Cisco BTS 10200 Softswitch release. There are no differences when provisioning the feature for SIP.
Customer-Originated Trace
This feature was introduced in a previous Cisco BTS 10200 Softswitch release. There are no differences when provisioning the feature for SIP.
For more information, see the Customer Originated Trace section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions guide.
Direct Inward Dialing
This feature was introduced in a previous Cisco BTS 10200 Softswitch release. There are no differences when provisioning the feature for SIP.
For more information, see the Direct Inward Dialing section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions guide.
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 more information, see the DOD for PBX section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions guide.
Do Not Disturb
Do Not Disturb (DND) enables a user to temporarily busy out a station when the feature is activated.
If no call forwarding features are activated, calls to the station are routed to busy treatment. Preferably, this feature should be provided on the Cisco BTS 10200 Softswitch 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: confirmation tone and Failure: messages.
For features (such as DND) that can be fully provisioned on the Cisco BTS 10200 Softswitch or on the phone, provision either one of the devices to enable the feature.
Caution
For more information, see the Do Not Disturb section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions guide.
Emergency Call
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.
Note
For more information, see the Emergency Services (911) section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions guide.
E.164 and Centrex Dialing Plan (Extension Dialing)
Cisco BTS 10200 supports E.164 and Centrex Dialing Plan (Extension dialing) addressing from SIP User Agents. AOR addressing is not supported in Release 4.2.
The SIP phone's dial plan must be configured so that it considers the number of digits in the Centrex group. Each Centrex group should have its own separate dial plan.
Example 2-1 A SIP URL with E.164 addressing
sip:4695551234@rcdn.cisco.com;user=phoneA sip:50603@rcdn.cisco.com;user=phoneThe number of digits used for Centrex dialing can be provisioned within a range of 1 through 7 digits.
Incoming and Outgoing Simulated Facility Group
This feature was introduced in a previous Cisco BTS 10200 Softswitch release. There are no differences when provisioning the feature for SIP.
For more information, see the Features for Centrex Subscribers Only section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions guide.
Interworking
Release 4.5.x supports the following interworking combinations between SIP subscribers and:
•
•
•
•
•
Multiple Directory Numbers
This feature was introduced in a previous Cisco BTS 10200 Softswitch release. For information about how MDN works with SIP, see the SIP Endpoint Caveats section.
For more information, see the Multiple Directory Numbers section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions guide.
Operator Services (0-, 0+, 01+, 00 Calls)
This feature was introduced in a previous Cisco BTS 10200 Softswitch release. There are no differences when provisioning the feature for SIP.
For more information, see the Operator Services section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions guide.
Outgoing Call Barring
This feature was introduced in a previous Cisco BTS 10200 Softswitch release. There are no differences when provisioning the feature for SIP.
For more information, see the Outgoing Call Barring (OCB) section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions guide.
Remote Activation of Call Forwarding
This feature was introduced in a previous Cisco BTS 10200 Softswitch release. There are no differences when provisioning the feature for SIP.
For more information, see the Remote Activation of Call Forwarding section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions guide.
SIP Endpoint Caveats
The following Cisco BTS 10200 supported supplementary features have caveats when compared with an MGCP endpoint behavior for the same feature:
•
•
•
•
•
•
•
SIP Subscriber to SIP Calls
SIP subscribers must present valid credentials on a SIP INVITE message in order to place calls.
In Release 4.5.x, Cisco BTS 10200 allows SIP subscribers to call other SIP subscribers or SIP trunks connected to Cisco BTS 10200. The provisioned dial plan determines whom a subscriber may call. A SIP subscriber may receive a call as long as the subscription's registration is current, or a static registration has been provisioned. A SIP subscriber may call any SIP endpoint hosted by a trunk that was provisioned on Cisco BTS 10200.
Type of Service
The SIP Type of Service (ToS) feature provides the ability to configure the Cisco BTS 10200 such that SIP signaling traffic is sent at a desired priority over IP. This is important because SIP messages travel over the same network as the voice traffic. If this network is congested, the voice data may delay the SIP signaling packets, causing unnatural delay when calls are set up. Raising the SIP packets priority in relation to other traffic reduces the delay.
The ToS value for messages sent to SIP subscribers can be set on a system-wide basis—this applies to all subscribers. The policy is selected in the CA-CONFIG table. If the ToS entries are not provisioned in CA-CONFIG table, the following defaults apply:
•
•
•
•
Note
Caution
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.
Voice-Mail Support
Cisco BTS 10200 supports the following voicemail features:
•
•
•
•
Voice-mail systems are configured as SIP trunks in Cisco BTS 10200. For voice-mail operation, see "Voice-Mail Support."
SIM Memory Audit
The SIM memory audit is done periodically for the active feature relationships to clear any stale relationships. Audits on the entire feature relationship table are also performed at a configurable fixed time every day to clean up the orphaned table elements.
SIP Dynamic Memory Audit
Note
The SIP dynamic memory audit checks the resources for call processing and call registration, and maintains those resources through both periodic and scheduled checks.
For example, if a call is connected to a remote endpoint (such as a trunk) and terminates abnormally, or if call connectivity is lost, the Cisco BTS 10200 recovers the resources on a periodic basis (approximately every one to two hours) by running an audit. During the audit, if no signalling has occurred on a call for more than an hour, the liveness of the call is checked by sending a re-INVITE or an UPDATE message to the SIP parties in the call.
The scheduled audit runs daily, and checks any contacts registered with SIP subscribers to ensure they have been refreshed. The SIP phone subscriber registry is expected to refresh regularly; however, if it is not, the Cisco BTS 10200 runs a scheduled audit once a day to reclaim stale resources associated with those registrations.
Note
For provisioning options, see the Session Timers section in the Cisco BTS 10200 Softswitch SIP Protocol Provisioning Guide.
Billing
A new value was added to the Appendix B: Call Termination Cause Codes in the Cisco BTS 10200 Softswitch Billing Guide. The new call termination cause code is called "NE Cause Audit Release" and its value is 901.
Alarms and Events
The following alarms were added or modified due to the SIP audit memory:
AUDIT(10)
DESCRIPTION: Call Data Audit Complete
SEVERITY: INFO
INITIAL RELEASE: 4.5
LAST RELEASE MODIFIED IN: 4.5
THRESHOLD: 100
THROTTLE: 0
END-CUSTOMER PERCEPTION: No impact
DATAWORDS:
Audit Information - STRING [256]
PRIMARY CAUSE:
A memory audit has completed
PRIMARY ACTION:Check if any Call Blocks freed as a result of Audit. An investigation for root cause may be useful.
AUDIT(19)
DESCRIPTION: Recovered Memory of stale call
SEVERITY: WARNING
INITIAL RELEASE: 4.5
LAST RELEASE MODIFIED IN: 4.5
THRESHOLD: 20
THROTTLE: 0
END-CUSTOMER PERCEPTION: Lost or errant billing data
DATAWORDS:
Stale Memory Release Info - STRING [128]
PRIMARY CAUSE:
Loss of communication with originating or terminating side.
PRIMARY ACTION:
Check if adjacent network element is up and having proper communication link with softswitch.
SECONDARY CAUSE:Adjacent network device protocol error.
SECONDARY ACTION:
Check the adjacent network device protocol compatibility.
TERNARY CAUSE:
Internal Software Error.
TERNARY ACTION:
Contact Cisco Support.
AUDIT(20)
DESCRIPTION: Audit Found lost call data record
SEVERITY: MAJOR
INITIAL RELEASE: 4.5
LAST RELEASE MODIFIED IN: 4.5
THRESHOLD: 20
THROTTLE: 0
END-CUSTOMER PERCEPTION: Lost or errant billing data
DATAWORDS:
Error Text - STRING [200]
PRIMARY CAUSE:
Software error - however, the orphaned records are recovered on detection 2d.
PRIMARY ACTION:
Contact Cisco Support
Measurements
The following measurements, found in the Measurement SIA Summary (measurement-sia-summary) table, are affected by the SIP dynamic memory audits.
•
•
•
•
An example of the Measurement SIA Summary (measurement-sia-summary):
report measurement-sia-summary start-time=2003-03-27 06:00:00; end-time=2003-03-2706:30:00; call-agent-id=CA146;output-type=csv;clear measurement-sia-summary call-agent-id=CA146;Phone-Based Features
Phone-based features are provided by the SIP phone, which require provisioning on the phone.
There are some features that the phone provides standalone, without Cisco BTS 10200 support.
For features (such as DND) that are available independently on the phones and the Cisco BTS 10200 Softswitch, you can provision either device to enable the feature.
Caution
The Cisco BTS 10200 Softswitch supports interface requirements (such as Re-INVITE support) that are necessary to operate features from the SIP phones, including but not limited to:
•
•
•
•
•
•
Note
•
Jointly-Provided Features
In addition to the Softswitch-based and phone-based features, Release 4.5.x also offers jointly-provided features. These are features provided jointly by the phone and by the Cisco BTS 10200. To use these features, you must provision both the phone and the Cisco BTS 10200.
These features include:
•
•
•
Session Timers
Release 4.5.x enhances SIP timers and introduces the sip-timer-profile table to provision session timer values. The session timer values are provisioned in the sip-timer-profile table, then the id of the sip-timer-profile table record is specified as the Value for the ca-config record of Type=sip_timer_profile_id.
Note
This SIP extension allows for a periodic refresh of SIP sessions through a SIP re-INVITE or UPDATE request. The refresh allows the Cisco BTS 10200 SIP interface to determine if a SIP session is still active. If the session is inactive, possibly because the session did not end normally, the Cisco BTS 10200 sends a SIP BYE request and cleans up resources dedicated to the session. Stateful SIP proxies and the remote SIP endpoint handling the BYE request can clean up resources dedicated to this session as well.
Cisco BTS 10200 support for this feature follows the specifications described in the IETF draft draft-ietf-sip-session-timer-08. Session durations are configured within a range of 30 minutes to 2 hours. Cisco BTS 10200 does not allow for negotiating a session less than 15 minutes. Cisco BTS 10200 SIP interface does not impose the session timer feature be required on the remote SIP endpoint. This feature does not require the session timer capability on the remote SIP endpoint.
In the unlikely event of a call agent redundancy failover, the session timer is deactivated. This may result in eventual session expiration and call release.
This feature can be enabled or disabled for all SIP subscribers; the feature is disabled by default. Prior to Release 4.5.x, this feature was enabled by provisioning the SUB-SESSION-TIMER-ALLOWED token in the ca-config table.
In Release 4.5.x and later, the session timer values are provisioned through the MIN-SE and SESSION-EXPIRES-DELTA-SECS tokens in the sip-timer-profile table. The id of the sip-timer-profile table record is then specified as the Value for the ca-config record of Type=sip_timer_profile_id.
If the feature is enabled for a SIP subscriber, Cisco BTS 10200 (as UAC) adds, to the initial INVITE message, a supported header with a `timer' value, as well as a Session-Expires header with the Refresher parameter set to `Uac'. Whenever the SIP call is sent from a Cisco BTS 10200 SIP subscriber, Cisco BTS 10200 specifies itself to be the refresher. If Session Timer is not supported on the remote end, the value sent in the Session-Expires header is set for the session duration. A periodic refresh request is sent at half of the negotiated Session-Expires value.
When this feature is enabled for the SIP subscriber and an initial INVITE is received by the Cisco BTS 10200 with a Supported header with `timer' value and a Session-Expires header, it sends a 200 class response with a Require header specifying `timer,' and a Session-Expires header and refresher parameter. The Session-Expires header contains a session duration and refresher value set to whatever was received in the initial INVITE. If refresher parameter is not received in the initial INVITE, Cisco BTS 10200 sets it to `Uas' indicating Cisco BTS 10200 is the refresher. Cisco BTS 10200 sends periodic refresh request at half the negotiated session duration.
When session timer is enabled for the SIP subscriber and an initial INVITE is received by Cisco BTS 10200 without a Supported header with `timer' value or a Session-Expires header, a 200 class response is sent without a Require header with `timer' value, or a Session-Expires header. Cisco BTS 10200 sends periodic refresh request at half the negotiated session duration.
When session timer is disabled on the SIP subscriber and an initial INVITE is sent by Cisco BTS 10200, no Supported header with `timer' value or a Session-Expires header is added, indicating to the remote SIP endpoint that the Cisco BTS 10200 does not support session timer.
When the feature is disabled on the SIP subscriber and an initial INVITE is received by Cisco BTS 10200, any session timer related headers are ignored. The 200 class response does not include a Require header with `timer' value or a Session-Expires header.
Configurable parameters in the sip-timer-profile table allow the user to select the desired session duration (SESSION-EXPIRES-DELTA-SECS) and the minimum tolerable session duration (MIN-SE) if negotiated down by the remote SIP endpoint or proxy. If the parameters are not explicitly specified, the default session duration is 30 minutes and the minimum tolerable session duration allowed is 15 minutes.
A session that is not refreshed at the end of the duration interval results in a call release and session clean-up.
Note
To provision these timers, see the Session Timers section in the Cisco BTS 10200 Softswitch SIP Protocol Provisioning Guide.
SIP Timer Values
Release 4.5.x enhances SIP timers and introduces the sip-timer-profile table to provision SIP timer values. The SIP timer values are provisioned in the sip-timer-profile table, then the id of the sip-timer-profile table record is specified as the Value for the ca-config record of Type=sip_timer_profile_id. If you provision the timer values for a specific trunk (by pointing to a sip-timer-profile in the softsw-tg-profile), that overrides the ca-config default.
Note
To provision these timers, see the SIP Timer Values section in the Cisco BTS 10200 Softswitch SIP Protocol Provisioning Guide.
For more information about these timers, or for common SIP term definitions from this section, see RFC3261.
The following SIP timers are available in Release 4.5.x.
•
•
•
•
•
•
•
•
•
•
•
When a BYE is subsequently sent or received on a call in progress, and timer I is running for that call, it is canceled and restarted for a smaller fixed duration of four seconds to reduce CCB hold time after call completion, and to optimize CCB resource usage.
•
•
This timer is also started if a CANCEL is sent, to clean up the INVITE transaction in case of a final response (487), indicating that the request was canceled, is not received.
The process involving receipt of the 180 response is shown in Figure 2-3.
Figure 2-3 Invite Incomplete Timer Process with 180 Response
•
•
Note
To provision these timers, see the SIP Timer Values section in the Cisco BTS 10200 Softswitch SIP Protocol Provisioning Guide.
Calculation of Timer Retransmission Count
The retransmit count, or number of times the same request or response is retransmitted after the message is sent once to the transport layer, is computed based on RFC3261 recommendations.
INVITE Retransmit Count
If there is no response for the initial INVITE request, then INIVTE requests are retransmitted as shown:
For example, if TIMER-A-MILLI is 500 ms and TIMER-B-SECS is 32 seconds, then there are six retransmissions after the first request, for a total of seven requests from the UAC. The retransmissions occur at intervals of 500 ms, 1s, 2s, 4s, 8s, 16s, and 32s. The invite retransmission process is shown in Figure 2-4.
Figure 2-4 Invite Retransmissions with No Response
Non-INVITE Retransmit Count
If there is no response for the initial non-INVITE request, then INIVTE requests are retransmitted as shown:
For example, if TIMER-E-MILLI is 500 ms, TIMER-T2-SECS is four seconds and TIMER-F-SECS is 32 seconds, then non-INVITE retransmissions occur at intervals of 500 ms, 1s, 2s, 4s, 4s, 4s, 4s, 4s, 4s, 4s. This means that retransmissions occur with an exponentially increasing interval that caps at T2. In this particular scenario, there are total 10 retransmissions which is a total of 11 requests from UAC.
Response Retransmit Count
If no ACK is received for the final response of the INVITE request, the responses are retransmitted. This process is shown in Figure 2-5.
Figure 2-5 Invite Server Transaction Timer Cancelled Upon Receipt of ACK
Reliable Provisional Responses
SIP defines two types of responses, provisional and final. Final responses convey the result of the request processing, and are sent reliably. Provisional responses provide progress information about the request processing, but are not sent reliably in the base SIP protocol. The reliable provisional responses feature provides end-to-end reliability of provisional responses for Cisco BTS 10200 SIP subscribers.
Provisional responses in SIP telephony calls represent backward alerting and progress signaling messages, which are important when interoperating with PSTN networks. Therefore, for SIP-T calls on the Cisco BTS 10200, reliable provisional responses are mandatory. They are optional for regular SIP calls.
Cisco BTS 10200 support for this feature follows the specifications described in RFC 3262. A provisioning flag is provided to enable or disable this feature, and is disabled by default. For SIP trunks provisioned as "SIP-T," the system internally ignores the flag and enables the feature always. In this case, the feature is mandatory. Therefore, the ability to enable or disable the feature applies to regular SIP trunks only. There is one exception: SIP-T trunks receiving SIP-T calls (calls with ISUP attachments) may also receive incoming regular SIP calls. In this case, the feature (enabled or disabled) for that regular SIP call is determined by the provisioning flag on that SIP-T trunk. The provisioning flag (PRACK_FLAG) is a member of the Softswitch Trunk Group profile. For provisioning details, see the Cisco BTS 10200 Softswitch SIP Provisioning Guide.
For calls received on a Cisco BTS 10200 regular SIP trunk, or regular SIP (non-SIP-T) calls received on a SIP-T trunk, the following feature behavior applies:
•
•
•
•
For calls sent out a Cisco BTS 10200 regular SIP trunk, the following feature behavior applies:
•
•
•
•
•
•
For SIP-T calls received on a Cisco BTS 10200 SIP trunk provisioned as SIP-T, the following feature behavior applies:
•
•
•
•
•
•
Text-GUI Features
Cisco BTS 10200 supports SIP client/handset text-based user interface (UI) provisioning for a select set of features. This is in contrast to numerous supplementary features supported natively by the SIP client/handset itself. Some of the features require updating the status on the network database. Cisco BTS 10200 provides complimentary support to SIP clients/handsets to update end user feature access status on the switch network database.
Provisioning in this context refers to feature activation or deactivation, and setting any applicable Directory Numbers (DNs) associated with the feature. If a SIP handset is used, the phone's LCD panel is used as a menu display area to guide the user toward feature provisioning. If a SIP software client is used, the UI display region in the client software is used to guide the user through feature provisioning.
There may be multiple lines on the SIP phone, but currently services configured using softkeys on the phone are only available to one of those lines. The subscriber for that line is provisioned by Cisco BTS 10200 with the MAC address of the phone (see "MAC to Subscriber" section).
Supported Handsets
Cisco BTS 10200 supports any SIP client/handset that supports CallManager XML 3.0.
Supported Features
The following features have SIP client/handset based provisioning support:
•
•
•
•
•
Accessing Features
The following sections describe how to access the features.
SIP Handset
The SIP handset provides a button labeled "Services" or an icon suggesting "Services." Initial access to feature provisioning is through the "Services" button. After initial access, the UI display area provides a menu-driven interface, and follows a menu depending on the feature type selected.
Navigating the menu is accomplished using the "Up" and "Down" arrow buttons or via menu numbers. At any level of navigation, use the "Exit" softkey to go back one step in the menu hierarchy. Select menu items using the "Select" softkey button. The numeric dial is used to enter DN information.
Menu Hierarchy
Feature Options
Call Forwarding
Call-Fwd Busy
Activate/Deactivate Feature
Set/Change Forwarding Number
Number:
Call-Fwd Unconditional
Activate/Deactivate Feature
Set/Change Forwarding Number
Number:
Call-Fwd No Answer
Activate/Deactivate Feature
Set/Change Forwarding Number
Number:
Anonymous Call Rejection
Activate/Deactivate Feature
Do Not Disturb
Activate/Deactivate Feature
SIP Software Clients
The user interface for applicable software clients is similar to a SIP handset.
Call Transfer (Blind and Attended)
The SIP call transfer (CT) feature is supported for SIP subscribers on Cisco BTS 10200 Release 4.5.x. Call transfer in Cisco BTS 10200 requires provisioning the "REFER" feature as an office trigger. See the Cisco BTS 10200 SIP Protocol Provisioning Guide for details.
The call transfer feature requires phone support for sending the SIP REFER message. See the phone documentation for details on the user interface and procedures to effect a call transfer. Both blind and attended transfers are supported.
The following caveats apply when using call transfers:
1.
2.
Distinctive Ringing
Distinctive ringing uses a special ringing pattern to alert the called user of incoming calls from pre-selected telephone numbers. This is a CLASS feature and is offered to both Business and Residential users.
You can edit the list of selected numbers though the Screening List Editing (SLE) feature, which requires configuring an IVR with the Cisco BTS 10200 Softswitch. Distinctive ringing can be assigned to a station and to the group, and 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 Cisco 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 Alert-Info header.
Distinctive Ringing for Centrex DID Calls
The Cisco BTS 10200 Softswitch 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 the information received in Alert-Info header.
Diversion Indication
Diversion indication provides supplemental redirection information to the SIP entity receiving the 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 this feature following the specifications described in the IETF draft draft-levy-sip-diversion-02.txt. For incoming calls, Cisco BTS 10200 uses the party number information from the top-most and bottom-most diversion headers. The Cisco BTS 10200 reads the diversion counter, 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 parameters 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:
•
•
•
•
•
•
–
–
