The 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.
• SIP ANI-based subscriber means a SIP phone that communicates with the BTS 10200 over a SIP
trunk.
NoteFor quick-reference tables listing the subscriber features, see the “Comparison of SIP-Based Features
and MGCP-Based Features” section on page 2-13.
This section covers the following topics:
• SIP Phone Initialization, page 2-2
• Provisioning a SIP Subscriber, page 2-2
• SIP Registration and Security, page 2-2
• SIP User Authentication, page 2-9
• SIP Subscriber Calls, page 2-10
• Provisioning Session Timers for SIP Subscribers, page 2-11
• SIP Timer Values for SIP Subscribers, page 2-11
• Diversion Indication for SIP Subscribers, page 2-12
• Comparison of SIP-Based Features and MGCP-Based Features, page 2-13
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. Instead, it shows how a client can establish its identity with the BTS 10200.
The circled numbers in the image indicate the numerical order in which the sequence occurs.
Figure 2-1Example of SIP Phone Initialization
Chapter 2 SIP Subscribers
DHCP
IP_Addr,
Gateway,
TFTP Srv & Files
2
TFTP
Who am I?
1
Config File,
Image, SIP Info
4
Help me
boot
3
Provisioning a SIP Subscriber
To provision a SIP subscriber, see the “SIP Subscriber Provisioning” chapter in the Provisioning Guide.
Cisco BTS
10200 IP
Address?
5
IP
DNS
Cisco BTS
10200's
IP_Addr
6
REGISTER
7
Cisco BTS 10200
Softswitch
8
200 OK
87899
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.
NoteThird-party registration is not supported.
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.
NoteOnly one contact should be registered for an AOR.
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 the SIP Protocol RFC 3261. If the BTS 10200 receives valid
credentials, the authenticated AOR from the User Authorization table identifies the subscriber based on
the Address of Record to Subscriber 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.
AOR ID -> 4695551884@sia-SYS44CA146.ipclab.cisco.com
USER -> 4695551884
HOST -> 10.88.11.237
PORT -> 5060
USER TYPE -> USER_PHONE_TYPE
EXPIRES -> 3600
EXPIRETIME -> Thu Jan 22 14:33:36 2004
STATUS -> REGISTERED CONTACT
Reply :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
Description
Prior to Release 4.5.1, SIP endpoint registration was based on 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 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.
SIP endpoint, and that no calls can originate from an unregistered endpoint.
To enable or disable SECURE_FQDN on a successful registered subscriber
1. Take AOR out of service to remove all registered contact.
2. Enable or disable SECURE_FQDN for the subscriber.
3. Bring AOR back In-Service.
4. Reboot the ATA.
A subscriber with the secure FQDN feature enabled has the following characteristics:
• One and only one AOR is associated with the endpoint.
• Does not have any static-contact associated with it.
• UserId and Password Authentication are supported.
• One FQDN (specified without service port).
• The DNS lookup of the FQDN should result in one and only one IP address.
• Cannot place or receive a call unless successfully registered.
Example
This example presents a case in which a VoIP subscriber (Subscriber 1) uses the following options for
the user ID, password, and phone number:
• user-id-1
Chapter 2 SIP Subscribers
• password-1
• phone-no-1
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 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 fully qualified domain name
(FQDN) of a SIP endpoint.
NoteUse this procedure to provision subscribers on the BTS 10200. The procedure does not cover the security
of configuration files provisioned on the SIP adapter (for example, an ATA), which are the responsibility
of the service provider.
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 SECURE_FQDN value can be specified on a subscriber only if the AOR for the subscriber is
OOS. When an AOR is taken administratively OOS, its registered contacts are deleted.
• A static contact cannot be specified for a SECURE_FQDN subscriber. Any existing static contact
record for an AOR must be deleted before the subscriber can be made a SECURE_FQDN SIP
endpoint.
• The SECURE_FQDN in the AOR2SUB table is stored both in the ORACLE database and the shared
memory.
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 1To provision a new SIP subscriber with the secure FQDN feature, enter the following command.
NoteThis command automatically adds a corresponding entry in the AOR2SUB table.
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(Optional) To provision an additional subscriber on the same SIP adapter, enter the following command:
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>;
SIP Registration and Security
NoteIf there are multiple subscribers on a single SIP adapter (such as an ATA), these subscribers
might share the same IP address. Therefore, you can provision all of these subscriber records
with a single secure-fqdn, and in the DNS, this FQDN can point to the applicable IP address.
The id, dn1, and aor-id tokens must have unique values for each subscriber.
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 1Take the AOR out of service (OOS). This command removes all registered contact.
Step 4Reboot the adapter device (such as ATA) for this subscriber.
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.
Chapter 2 SIP Subscribers
Cisco 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 UserId
and Password is as follows, after the UserId and Password are authenticated:
• Ensure that there is only one contact in the contact header.
• Ensure that the source IP address of the REGISTER message is the same IP address of the
provisioned FQDN for that endpoint.
• Ensure that the IP address or the FQDN of the contact is the same as the provisioned FQDN for that
endpoint.
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 on page 2-6 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
2-6
1. The system authenticates the user ID and password on all messages requiring authentication.
2. If the Contact header is available, the system ensures that only one contact is present, and that it has
the same IP address or FDQN of the provisioned endpoint.
3. All messages sent by the endpoint and the source IP address of the message must be the same as the
internal cache contact address (for example, the cache contact address is the contact obtained during
registration).
4. Response from an endpoint that has a contact header must conform to the second item in this list.
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.
The validation processing for a SIP request, that comes from a SIP endpoint provisioned with this
feature, is as follows:
1. The SECURE_FQDN validation occurs on every request (including CANCEL/ACK).
2. The SECURE_FQDN is verified to have a DNS resolution, if it is a domain name. If there is no DNS
resolution, a 500 Internal Server Error response is returned.
3. The DNS resolution for the SECURE_FQDN is verified to yield a single IP address Secure-IP1.
If the address is incorrect, a 500 Internal Server Error response is returned.
4. The Source IP address of the packet is verified as identical to Secure-IP1.
If the address is not identical, a 403 Forbidden response is returned.
5. If the Request is a Register, it is verified to have a single Contact header.
If there is not a single contact header, a 403 Forbidden response is returned.
6. If the SIP request is an initial INVITE (including an INVITE resubmitted with credentials), it is
verified that there is an unexpired registered contact for the AOR.
If here is not an unexpired registered contact, a 403 Forbidden response is returned.
7. When a Contact header is present, the Contact FQDN/IP address of the request is verified to yield a
single IP address Secure-IP1.
If it does not yield the proper address, a 500 Internal Server Error response is returned.
8. The IP address of the Contact host is verified as identical to the IP address Secure-IP1 of the
SECURE_FQDN.
If the addresses are not identical, a 403 Forbidden response is returned.
9. The provisioning of a static contact on a AOR is not disabled, but any provisioned value is ignored
because of the SECURE_FQDN validation rules. A static contact is irrelevant for SECURE_FQDN
AORs, since the SIP request is denied if no registered contact exists.
10. The To and From header URLs in a REGISTER are verified to be identical, for SECURE_FQDN
subscribers. This is to block third-party registration.
Received SIP Response Message
When a SIP response message is received from a SIP endpoint, the following occurs:
1. The Source IP address of the packet is verified to be identical with the IP address of the Secure-IP1.
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. When a Contact header is present on a reliable 1xx or 2xx response, the Contact FQDN/IP address
of the response is verified to resolve to the Secure-IP1.
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. The response for a BYE sent by Cisco BTS 10200 is not validated. This is the least likely point in a
call for theft.
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. The INVITE is sent to the registered contact of the endpoint. If there is no registered contact or if
the registered contact has expired, the INVITE is not sent and the call is declined.
2. Any static contact provisioned for the subscriber is ignored.
NoteProvisioning of static contact is not allowed for secure SIP endpoints; therefore, this is merely due
diligence.
Chapter 2 SIP Subscribers
Validation of ACK Request
When a SIP ACK message is received from a SIP endpoint, the following occurs:
1. The ACK for a 200-class response is validated like any other SIP request.
2. The ACK for a failure response (3xx or higher) is not validated.
Measurements
The following TMM counters are supported for secure FQDN violations:
• A SIA-SECURE_FQDN-VIOLATION-REQ counter is incremented when a SIP request fails the
validation for secure SIP endpoints.
• A SIA-SECURE_FQDN-VIOLATION-RESP counter is incremented when a SIP response fails the
validation for secure SIP endpoints.
NoteFor a full list of measurements, see the Cisco BTS 10200 Softswitch Operations and Maintenance Guide.
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:
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:
1. When a SIP user registers a contact with the BTS 10200 Registrar using a REGISTER request.
2. When a SIP user initiates a call using an INVITE request.
3. When a SIP user sends any request in an ongoing call. Examples include
–
Re-negotiation of the call parameters using a re-INVITE
–
Terminating the call using a BYE
–
Initiating a call transfer using a REFER
4. When a SIP user sends a request outside a dialog. Example: OPTIONS.
The following tables affect authentication for SIP subscribers:
• AOR
SIP User Authentication
• Serving Domain
• Auth-Realm
• User-Auth
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-2Authentication and Processing of an Incoming Request (for Example, INVITE)
Cisco BTS 10200
SIP Phone 1
IPIP
Invite
401
ACK
Invite
200
ACK
BYE
200
Softswitch
Invite
ACK
BYE
BYE
SIP Phone 2
200
401
200
87898
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.
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. They are disabled
by default.
Use the commands in this section to provision session timers for SIP subscribers. Session timer defaults
for subscribers are defined by internal defaults. They can be adjusted through the commands shown in
this section.
NoteFor a detailed description of session timers, see “SIP Session Timers” section on page 4-7
Step 1Adjust the session timer values in the sip-timer-profile table.
NoteThe session duration field value is in seconds with a range of 100 to 7200.
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.
NoteThis section describes how to provision SIP timer values for SIP subscribers. For a comprehensive listing
of SIP timers, see Chapter 4, “SIP System Features.”
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.
OL-12397-13
Step 1Adjust the SIP timer values in the sip-timer-profile table if necessary (example shown).