- Contents
- Prerequisites
- Restrictions
- Information About SIP Registration
- Adding an Expires-Header to a Register-Message
- Support for Supported Path Under REGISTER Request
- Information About Contact Username Passthrough
- Information About Alternative Contact Rewriting
- Restrictions on Alternative Contact Rewriting
- Configuring Alternative Contact Rewriting
- SIP Fast Registration Example
- SoftSwitch Shielding and Aggregate Registration Configuration Examples
- Registration Monitoring Examples
- Provisional Delegate Registration Examples
- Contact Username Passthrough Examples
- Alternative Contact Rewriting Example
- Registering with Softswitch via Cisco SRP Integrated Access Device (IAD) Examples
Cisco Unified Border Element (SP Edition) Registration Features
Cisco Unified Border Element (SP Edition) supports the SIP Fast Registration, SoftSwitch Shielding, Registration Monitoring, Aggregate Registration, Provisioned Delegate Registration, and Contact Username Passthrough features in the unified model.
SIP Fast Registration addresses the problem where SIP messages to the Network Address Translation (NAT) endpoint are unable to penetrate the NAT and firewalls to establish calls. Using SIP Fast Registration, the NAT endpoints transmit SIP REGISTER requests at a high enough frequency to keep the NAT pinhole alive.
The SoftSwitch Shielding feature allows a lower SIP registration rate on the links to registrars (typically softswitches) than on the links to endpoints. Allowing a lower registration rate shields the softswitch from an undesirably high rate of re-registrations.
Cisco Unified Border Element (SP Edition) supports monitoring events subscription for changes of the registration state with the Registration Monitoring functionality.
Aggregate Registration registers all the endpoints connected to it in a single registration. This functionality enables Cisco Unified Border Element (SP Edition) to support devices that implicitly register multiple endpoints through it.
The Provisioned Delegate Registration feature allows the Cisco Unified Border Element (SP Edition) to support client or end user devices that cannot register themselves in a network where SIP calls are passing through a registrar. Cisco Unified Border Element (SP Edition) is able to register on behalf of such client devices. The Provisioned Delegate Registration feature can support Cisco Telepresence systems where the end user applications cannot send the registration message and Cisco Unified Border Element (SP Edition) does it on their behalf.
The Contact Username Passthrough enhancement enables interoperability with softswitches that require the contact username portion of the Contact URI in SIP REGISTER requests to pass through unchanged.
Cisco Unified Border Element (SP Edition) was formerly known as Integrated Session Border Controller and may be commonly referred to in this document as the session border controller (SBC).
For a complete description of the commands used in this chapter, refer to the Cisco Unified Border Element (SP Edition) Command Reference: Unified Model at:
http://www.cisco.com/en/US/docs/ios/sbc/command/reference/sbcu_book.html .
For information about all Cisco IOS commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or a Cisco IOS master commands list.

Note These features are supported in the unified model.
Feature History for Registration Features
Contents
This chapter contains the following sections:
- Prerequisites
- Restrictions
- Information About SIP Registration
- Adding an Expires-Header to a Register-Message
- Support for Supported Path Under REGISTER Request
- Information About Contact Username Passthrough
- Configuring Contact Username Passthrough
- Information About Alternative Contact Rewriting
- Configuring Alternative Contact Rewriting
- Information About SIP Fast Registration
- Configuring SIP Fast Registration
- Information About SoftSwitch Shielding
- Configuring SoftSwitch Shielding
- Information About Registration Monitoring
- Configuring Registration Monitoring
- Information About Per Subscriber Delete
- Configuring Per Subscriber Delete
- Information About Aggregate Registration
- Configuring Aggregate Registration
- Information About Provisioned Delegate Registration
- Provisional Delegate Registration Commands
- Configuration Examples
Prerequisites
The following prerequisite is required to implement SoftSwitch Shielding, Registration Monitoring, Aggregate Registration, and Provisioned Delegate Registration:
Before implementing these features, Cisco Unified Border Element (SP Edition) must already be configured.
Restrictions
SIP Fast Registration has the following restrictions:
- Only UDP is supported.
- REGISTERs with a zero expiry time (“Unregisters”) are always forwarded to the registrar and not fast-pathed, if the SBC matches them to a known registration.
- Minimal parsing of REGISTER requests is performed before a decision is taken to send a fast-path response; this minimizes the load on the SBC. A REGISTER request is only fast-pathed if its expiry interval is not zero and it comes from the same IP address and port as a known subscription.
- Endpoints that send their requests from ephemeral (short-lived) ports do not have their registration requests fast-pathed.
- The “FastReg interval” cannot be higher than the “MinExpiry interval.” If the “MinExpiry interval” is less than twice the “FastReg interval,” fast-pathing is not performed.
Provisioned Delegate Registration has the following restrictions:
Information About SIP Registration
Registration is required if the end user has a dynamic IP address, if the provider does not support static hostnames, or if NAT is used.
In a SIP REGISTER message, the Contact: header contains the URI that identifies the subscriber.
When a device registers in a non-IMS network, Cisco Unified Border Element (SP Edition) takes the SIP REGISTER Contact: header and modifies it by replacing the contact username with a hash to produce a unique contact username. This is the default behavior for a typical registration. This is needed because there may be multiple UNI adjacencies in different VLANS, which have similar contacts. (Note that this does not apply to the IMS P-CSCF profile.) Then, the SBC forwards the REGISTER to the registrar containing this new modified Contact: header. Meanwhile, the SBC will also store a record of the original contact and the modified contact in its internal memory.
When the core network desires to ring that subscriber, the SBC will receive an INVITE containing the modified contact information. The Cisco SBC will check its memory to look up the information, and will swap out the header with the original information, and will direct the call to the appropriate SIP adjacency in the correct customer network.
This means that no explicit call routing detail needs to be configured in the call policy for routing calls from the core to subscribers, since the SBC has its internal memory of registrations.
Note that even though a SIP adjacency may be intended to receive only subscriber (registered) traffic, it is still possible for unregistered callers to initiate calls from that same adjacency. This can be considered useful, because emergency callers therefore may not need to register first.
When the call arrives at the softswitch, it can check if the subscriber has registered or not, and if to allow the call or not.
In the case where softswitch interoperability is desired, you may want to pass through the contact username instead of hashing it. Cisco Unified Border Element (SP Edition) provides a Contact Username Passthrough enhancement for non-IMS networks. See Information About Contact Username Passthrough.
Adding an Expires-Header to a Register-Message
Some registrars or endpoints might fail to understand the Expires parameters configured in the contact URI. To overcome this issue, you can configure the SBC to add an Expires header to the register messages.
In SIP, the expiry time of a registration is specified by registering the endpoints using the following:
- Expires header
- The Expires parameter on the registered contact URI.
- The registrar can choose an expiration period, if no expirations period is specified.
Configuring SBC to Add an Expires-Header
To configure SBC to add an Expires header to the register messages, complete the following steps:
DETAILED STEPS
Support for Supported Path Under REGISTER Request
Starting with Cisco IOS XE Release 2.5, Cisco Unified Border Element (SP Edition) supports the use of the Path extension header field in the Supported field of a REGISTER Request. The Path field provides a way to accumulate and send a list of proxies between a SIP user agent and a registrar. For information on the Path field, see RFC 3327 Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts.
Information About Contact Username Passthrough
The Contact Username Passthrough feature enables interoperability with softswitches that require the contact username portion of the Contact URI in SIP REGISTER requests to pass through unchanged. In certain situations in non-IMS networks, a softswitch may be unable to operate with Cisco Unified Border Element (SP Edition) rewriting or hashing the contact username portion of the Contact URI in SIP REGISTER requests. In these cases, subscribers may not be able to register through the SBC unless you configure the SBC to pass through the contact username.
In a typical SIP registration process, the default behavior is that Cisco Unified Border Element (SP Edition) rewrites the URIs in the Contact headers of REGISTER requests sent by subscribers for the following reasons:
- To remain on the signaling path for requests sent to this subscriber.
- To disambiguate subscribers that register from different devices with the same private username by replacing the username part of the Contact URI with a unique string.
For example, the SBC receives two REGISTER requests, with the following contact URIs using the same username, “bob”:
In each case, the REGISTER contains a Contact URI with the SBC’s address. The SBC replaces or rewrites the username “bob” in each URI with a unique string to disambiguate them.
In Cisco IOS XE Release 2.5 and later, you can choose to configure the SBC to pass through, not rewrite, the contact username on SIP REGISTER requests by ensuring that each contact username associated with a given subscriber uses a different port number. By using unique ports for each contact sent to the registrar, the SBC can uniquely correlate to the registered endpoints without requiring a unique username. This can be configured for each adjacency facing the registrar.
The following is an example of contact username passthrough where the username “bob” is passed through unchanged and the hostport is rewritten with the address of the SBC and a unique port number:
sip:bob@1.1.1.1 ------> sip:bob@192.168.101.1:5060
See the “Contact Username Passthrough Examples” section for more configuration examples.

Note This feature has no effect in IMS deployments where the SBC does not rewrite contact usernames.
Configuring Contact Username Passthrough
You can use the registration contact username passthrough and the signaling-port commands in the (config-sbc-sbe-adj-sip) configuration mode to configure the Contact Username Passthrough feature.
The registration contact username command with the passthrough option allows you to specify that the contact username in the SIP REGISTER request should be passed through unchanged when rewriting contacts. This option should be enabled on the registrar-facing adjacency. The passthrough option disambiguates subscribers that register from different devices with the same private username by using a unique local port number when multiple contact URIs are registered for the same public ID. The range of valid signaling ports are configured with the signaling-port command on a registrar-facing adjacency.
If you do not specify the max-port-num option in the signaling-port command on this adjacency, then the SBC is not able to disambiguate subscribers that register from different devices with the same username.
The default is the rewrite option which allows the username to be changed when rewriting contacts.

Note If the contact username is longer than 32 characters, then it is not passed through and is replaced with a hash as is the case when the default rewrite option is chosen.
The following example configures the SBC to specify that the contact username is passed through unchanged.
SUMMARY STEPS
4. adjacency sip adjacency-name
6. registration contact username {passthrough | rewrite}
DETAILED STEPS
Information About Alternative Contact Rewriting
In a User-to-Network Interface (UNI) deployment scenario, the endpoint registers to registrar, softswitch, or proxy through the SBC. The SBC rewrites the received contact header to use its own signaling address and keeps itself in the call signaling flow. The SBC maintains the mapping between the received and forwarded contact information. This ensures that the contacts received from the multiple devices are unique, and provides anonymity to the subscribers.
Prior to Cisco IOS XE Release 3.3S. the SBC would rewrite the contact by replacing the entire contact with an alphanumeric string generated by hashing the received contact information. However, registrars can determine that the multiple registrations are for the same Address of Record (AOR) by comparing an initial section of the user-info in the contact header. For example, they determine that the two contacts for 02083661177-abc@sbc.com and 02083661177-xyz@sbc.com are for the same endpoint.
From Cisco IOS XE Release 3.3S, the SBC rewrites the contact header in the following two methods:
- Hashed value of hexadecimal characters—<DN> + "-" + <hashed_value>, the <hashed_value> is a randomly generated value and is unique for a specific endpoint, so that the softswitch can identify those endpoints and initiate forking. Forking is an multiple calls attempt to the endpoints for a single AoR.
- Username of rewritten contact Uniform Resource Identifier (URI) only includes numeric hashed value.
Delegate Registration
When a delegate subscriber is configured on a preset-access adjacency, the contact header sent to the registrar is rewritten similar to the contact header received on a REGISTER message. Therefore, the Alternative Contact Rewriting feature applies to a delegate registration also. The original contact provided to the user on exit and used to generate the rewritten contact is the contact that is configured using the sip-contact contact uri command under the SBE Subscriber Entry mode.
Configuring Alternative Contact Rewriting
This task explains how to configure the Alternative Contact Rewriting feature.
SUMMARY STEPS
4. adjacency { sip | h323 } adjacency-name
5. registration contact username rewrite [ numeric | userid-and-numeric ]
DETAILED STEPS
The following example show the output of the show sbc sbe adjacencies detail command:
Information About SIP Fast Registration
SIP Fast Registration performs the following functions:
- Prompts endpoints to register frequently with Cisco Unified Border Element (SP Edition), causing NAT/Firewall pinholes to remain open.
- Protects internal network elements from the large number of REGISTER messages arising from endpoint registration.
- Allows Cisco Unified Border Element (SP Edition) to do minimal processing of REGISTER messages, which improves performance. This is particularly important when dealing with significant oversubscription—where there typically may be 10 times more subscribers than active calls.
When Cisco Unified Border Element (SP Edition) faces the customer premise side and the customer on the network edge deploys Network Address Translation (NAT) and firewalls, SIP INVITEs to the NAT endpoint are unable to penetrate the NAT to establish calls. To overcome the problem, the endpoints transmit SIP REGISTER requests at a high enough frequency to keep the NAT pinhole alive. The SIP Fast Registration feature off loads the processing from the registrar for a large number of endpoints and generates SIP REGISTER replies from the data plane (forwarding services provided by Cisco QuantumFlow Processor (QFP)). This also limits the impact on the router’s CPU load. The QFP processes the expected SIP re-register messages by short-cutting the REGISTER messages and quickly turning them around.
Typically the registrar responds to the first SIP REGISTER message asking the end-point to send its next SIP REGISTER message within 3600 seconds (configurable). With the SIP Fast Registration feature, Cisco Unified Border Element (SP Edition) intercepts this Reply and informs the end-point to REGISTER every 30 seconds to keep the NAT open. The Route Processor (RP) programs a SIP Fast Registration (SFX) entry with a fast expiry times parameter in seconds. When the fast expiry times parameter expires, the QFP punts the SIP REGISTER message to the RP to update the state before forwarding it to the registrar.
Fast registration is configured per SIP adjacency, on the endpoint-facing adjacency, that is, the adjacency which receives the incoming REGISTER request. After an endpoint has registered using fast registration through an adjacency, all subsequent registration requests from the same endpoint are responded to by Cisco Unified Border Element (SP Edition), without notifying the softswitch, until the registration interval has almost expired.
The following shows a fast registration configuration example:
In the example above, Cisco Unified Border Element (SP Edition) performs fast registrations at 60 second intervals, and will send registrations towards the registrar/softswitch at intervals of 480 seconds. This is calculated by a hard-coded algorithm of (3 x fast-register-interval) + (reg-min-expiry), plus taking into account the expiry time in the inbound registration from the endpoint.
In the above example, Softswitch Shielding is not enabled. Thus if incoming expiry time from the endpoint is 400 seconds, which is less than 480 seconds, then the incoming registration interval to the registrar/softswitch is calculated as 480 seconds. However, if the incoming expiry time from the endpoint is 600 seconds, which is larger than 480 seconds, then the incoming registration interval to the registrar/softswitch is calculated as 600 seconds.
On the other hand, when Softswitch Shielding is enabled, then the Softswitch Shielding timer takes precedence and is always used as the incoming registration interval to the registrar/softswitch. See the “Information About SoftSwitch Shielding” section.
When fast registration is enabled, the incoming registration time should not be less than the fast-register-interval. Otherwise, the SBC will reject the registration with error message 423 (Interval Too Brief). The SBC compares incoming registration time with the interval set in fast-register-interval, instead of the interval in reg-min-expiry. If fast registration is disabled, then the incoming registration time should not be less than the reg-min-expiry time. Otherwise, the SBC will reject the registration with response code 423 (Interval Too Brief).
For information on commands, such as fast-register-interval and reg-min-expiry, see the Cisco Unified Border Element (SP Edition) Command Reference: Unified Model.
SIP Fast Registration is not enabled by default. You must configure it with the inherit profile preset-access command, either as a global configuration or per adjacency.
Once SIP Fast Registration is configured, fast-pathing is on by default on an adjacency. You can then disable Fast Registration using the fast-register disable command.
REGISTER messages are rejected by Cisco Unified Border Element (SP Edition) with a 423 Interval Too Brief response code under the following conditions:
- If Fast Registration is enabled and the Expires header in the REGISTER message is less than the inbound adjacency’s “ fast-register-interval .”
The fast-register-interval command controls the recommended rate at which endpoints send REGISTER requests. The lower this value, the more frequently endpoints re-register, thus keeping a NAT/firewall pinhole open. Therefore, we recommend configuring this to a slightly lower value than the pinhole timeout, if that is known.
- If Fast Registration is not enabled and the Expires header in the REGISTER messages is less than the inbound adjacency’s “ reg-min-expiry .”
The reg-min-expiry command controls the rate at which REGISTER requests are sent from the SBC to the SIP registrar. The lower this value, the greater the potential register load on the softswitch. If fast-pathing is not enabled for an adjacency, SBC rejects any REGISTER requests with a shorter expiry interval than the reg-min-expiry command.
Figure 22-1 illustrates where network elements are located in a network configured with Fast Registration, SoftSwitch Shielding, and Aggregate Registration.
Figure 22-1 Voice Network Elements in a Fast Registration, SoftSwitch Shielding, and Aggregate Registration Network

Restrictions for SIP Fast Registration
The restrictions for SIP Fast Registration are the following:
- Only UDP is supported.
- REGISTERs with a zero expiry time (“Unregisters”) are always forwarded to the registrar and not fast-pathed, if the SBC matches them to a known registration.
- Minimal parsing of REGISTER requests is performed before a decision is taken to send a fast-path response; this minimizes the load on the SBC. A REGISTER request is only fast-pathed if its expiry interval is not zero and it comes from the same IP address and port as a known subscription.
- Endpoints that send their requests from ephemeral (short-lived) ports do not have their registration requests fast-pathed.
- The fast-register-interval cannot be higher than the reg-min-expiry (minimum expiry value). If the minimum expiry value is less than twice the fast-register-interval, fast-pathing is not performed.
Configuring SIP Fast Registration
This task configures a basic SIP Fast Registration on an adjacency.
SUMMARY STEPS
4. adjacency { sip | h323 } adjacency-name
5. inherit profile { preset-access | preset-core | preset-ibcf-ext-untrusted | preset-ibcf-external | preset-ibcf-internal | preset-p-cscf-access | preset-p-cscf-core | preset-peering | preset-standard-non-ims}
DETAILED STEPS
Information About SoftSwitch Shielding
Cisco Unified Border Element (SP Edition) supports the SoftSwitch Shielding feature that allows a lower SIP registration rate on the links to registrars (typically softswitches) than on the links to endpoints. In a network where endpoints frequently refresh their SIP registrations to a softswitch, allowing a lower registration rate shields the softswitch from an undesirably high rate of re-registrations while ensuring the softswitch still has accurate knowledge of registered endpoints.
For example, if endpoints are sending REGISTER messages to inform the proxy server of the callee address location every 15 minutes, Cisco Unified Border Element (SP Edition) can be configured to only forward REGISTER messages to the softswitch every 12 hours, unless there is a change to the contact being registered. Using SoftSwitch Shielding reduces the load on the softswitch and the network. On the other hand, if an endpoint stops sending REGISTER messages, Cisco Unified Border Element (SP Edition) detects the change within the endpoint’s expiry interval and removes the subscriber state, thus preventing calls to or from this endpoint.
The SoftSwitch Shielding feature gives Cisco Unified Border Element (SP Edition) the capability to shield the softswitch from a large portion of the registration processing. You are also able to simultaneously configure the SIP Fast Registration feature and the SoftSwitch Shielding feature. In addition, if the REGISTER message contains an Authorization header, Cisco Unified Border Element (SP Edition) forwards the REGISTER message to the softswitch registrar.
Use the registration outgoing timer command to enable SoftSwitch Shielding and set the time interval during which the SBC forwards REGISTER messages to the softswitch before timing out.
Figure 22-2 illustrates a SoftSwitch Shielding call flow.
Figure 22-2 SoftSwitch Shielding Call Flow

SUMMARY STEPS
4. adjacency { sip | h323 } adjacency-name
5. registration outgoing timer sec
6. registration rewrite-register
7. inherit profile { preset-access | preset-core | preset-ibcf-ext-untrusted | preset-ibcf-external | preset-ibcf-internal | preset-p-cscf-access | preset-p-cscf-core | preset-peering | preset-standard-non-ims}
DETAILED STEPS
Information About Registration Monitoring
Cisco Unified Border Element (SP Edition) supports creating event subscriptions for changes of registration state. Event subscriptions are generally network-initiated de-registrations. This is a requirement of the IP Multimedia Subsystem (IMS) specifications for Proxy-Call Session Control Function (P-CSCF), a SIP proxy server. For more information, refer to 3rd Generation Partnership Project (3GPP) TS 24.229 v7.5.1.
This support is configured on a per-adjacency basis through the registration monitor field of the Adjacency Table. If this field is set, then Cisco Unified Border Element (SP Edition) creates an event subscription with the registrar for each registered subscriber situated on the adjacency.
The registrar uses the event subscription to provide active indications of changes to the state of the registration. Based on these indications, Cisco Unified Border Element (SP Edition) adds, removes, or updates subscriber state, as appropriate. For more information on event subscriptions, refer to RFC 3680.
Cisco Unified Border Element (SP Edition) does not clean up fast register configuration in the event of a network-initiated de-registration. In this case, the user equipment (UE) is not able to re-register with the registrar until the fast register time period expires.
Cisco Unified Border Element (SP Edition) sets the duration of the monitoring subscription to be the maximum expired interval of the subscriber’s contacts plus a configurable constant. The default monitoring subscription duration is 32 seconds.
Cisco Unified Border Element (SP Edition) only re-subscribes to the Serving-Call Session Control Function’s (S-CSCF) monitoring state when the UE sends a re-register through the SBC. Cisco Unified Border Element (SP Edition) does not follow the 3GPP model of refreshing subscriptions 600 seconds before they expire. The SBC implementation reduces the load on the P-CSCF and S-CSCF, both SIP servers, while ensuring that the subscription lifetime exceeds the registration lifetime, which ensures that network-initiated de-registrations are always detected.
Use the registration monitor command to enable monitoring of event subscriptions for registration state changes.
Configuring Registration Monitoring
This task configures how to monitor event subscriptions as a result of registration state changes.
DETAILED STEPS
Information About Per Subscriber Delete
The Per Subscriber Delete feature provides a mechanism for manually deleting individual subscribers, and associated registered contacts or other subscriber state if any, from the database. This feature works on both manually created subscriber entries and dynamically created entries during the standard registration process. It does not cause the SBC to signal either the subscriber or the registrar; it only removes the internal state from the SBC associated with that subscriber.
Use the clear sbc sbe sip subscriber aor command to clear the stuck registrations on Cisco ASR 1000 Series Routers.
SUMMARY STEPS
1. show sbc sbc-name sbe sip subscribers
2. clear sbc sbc-name sbe sip subscriber aor address-of-record
Information About Aggregate Registration
A registrar is typically a registration server in a SIP network, but outside of the Cisco Unified Border Element (SP Edition) device. The registrar accepts and processes registration requests that register one or more IP addresses to a specific URI, usually a "sip:" address. Because SIP endpoints need to know each others IP address, the registrar acts as a location service. More than one user agent can register at the same IP address. When a call is placed to that IP address, all the registered user agents will ring.
Cisco Unified Border Element (SP Edition) supports Aggregate Registration where a single registration is implemented that causes the registrar to implicitly register multiple IP addresses. The SBC performs aggregate registration for endpoints connected to it. Thus Cisco Unified Border Element (SP Edition) can support devices that implicitly registers multiple endpoints through it. This way of registering all endpoints connected to it in a single registration can be compared to what is commonly done by an IP-PBX device.
The Aggregate Registration feature allows single registration on behalf of multiple endpoints and implicit registration of single endpoints behind the Internet Protocol Private Branch eXchange (IP-PBX).
Aggregate registration is configured on a per-adjacency basis and is configured under an adjacency. All end user clients attached to the adjacency can perform aggregate registration.
When an adjacency has aggregate registration support enabled, the SBC behaves as follows:
- On receiving a REGISTER message, the SBC caches the top Via header and stores it with the normal registration details.
- On receiving an INVITE or out-of-dialog request on the adjacency, Cisco Unified Border Element (SP Edition) attempts to look up the registration using the top Via header, not the Contact and From headers. This ensures that the SBC routes the call to the registrar correctly.
- On receiving an INVITE or out-of-dialog request to the adjacency, Cisco Unified Border Element (SP Edition) overwrites the Request URI as follows:
– The username is overwritten with the username in the P-Called-Party-Id header if present, or the To header if not.
– The hostname is overwritten with the hostname that was present on the Contact header that the PBX registered.
Use the registration aggregate command to enable Aggregate Registration support from an adjacency.
SUMMARY STEPS
4. adjacency { sip | h323 } adjacency-name
5. registration rewrite-register
6. inherit profile { preset-access | preset-core | preset-ibcf-ext-untrusted | preset-ibcf-external | preset-ibcf-internal | preset-p-cscf-access | preset-p-cscf-core | preset-peering | preset-standard-non-ims}
8. header-name [contact [add [tls-param]] | from{ passthrough} | to{ passthrough} ]
DETAILED STEPS
Information About Provisioned Delegate Registration
In a SIP network, some third-party client or end user devices are unable to register themselves with a registrar. A registrar is a server that resides outside the SBC device. These end users or clients are generally the applications running on systems used by people. The application may be a softphone application running on your PC or a messaging device in your IP phone. For example, the softphone application generates a request when you try to call another person over the network and sends the request to a server. The generated request is a register message or registration.
End users register their locations or addresses to a registrar server. By registering or sending a special message to a registrar server, the registrar server maintains updated locations of end users in a SIP network. The client then sends the request to a proxy server because when the request is generated, the address of the recipient or callee is not known. The registration is sent to inform a proxy server of the location of the callee address.
Cisco Unified Border Element (SP Edition) can be configured to register any client devices that cannot register themselves. Using the Provisioned Delegate Registration feature, you can set up delegate registration for individual client devices. The client device can make and receive calls as though it had registered normally. Additionally, you can specify individual parameters for each client device, such as registering the client device to a specified registrar server.
Provisioned Delegate Registration is done by provisioning Cisco Unified Border Element (SP Edition) with enough information about a client device so that it can originate a registration for the device itself. Cisco Unified Border Element (SP Edition) can perform end user registration for up to several hundred to a thousand end user clients or delegate clients.
Provisioned Delegate Registration supports the following functionalities:
- Cisco Unified Border Element (SP Edition) can be configured to register with a SIP registrar on behalf of another SIP network entity – the delegate client.
- Users can configure the following information per delegate client:
– The registrar where the end user client is registered.
– The registrar facing adjacency if the user wants to bypass normal routing.
– The adjacency facing the delegate client.
– The expiration time of the registration.
– The refresh time of the registration.
– The contact Uniform Resource Identifier (URI) information of the delegate client. Depending on the adjacency configuration, the URI may be rewritten on messages going to the registrar to force calls to the delegate client to be routed through the SBC.
– The next hop to the delegate client (for calls coming from the registrar).
– The address of record (AoR) of the delegate client.
– The number of attempts and frequency of registration retries when a failure is received.
– the entity identified in the Service-Route header if present on the registration response, or
- Calls to the delegate client must have the Request URI rewritten to indicate the delegate client, and forwarded out of the adjacency facing it.
Provisioned Delegate Registration Call Flow Description
When an end user client is brought up, Cisco Unified Border Element (SP Edition) builds a REGISTER message on behalf of the client, and sends it to the specified registrar. The REGISTER message contains all the contact Uniform Resource Identifier (URI) information that have been configured on the end user client.
If the registrar responds positively to the REGISTER message, Cisco Unified Border Element (SP Edition) stores this fact. Calls to and from the end user client is treated by the SBC exactly as if the client has registered itself.
If the registrar responds negatively to the REGISTER message. For example, if Cisco Unified Border Element (SP Edition) receives error response 423—Interval too brief, the SBC retries building a REGISTER message after the configured retry interval. Cisco Unified Border Element (SP Edition) repeats this process the configured number of times. If the end user client has still failed to be registered, a log is made and the subscriber operating status is changed to OPER_ACT_FAILED.
Before the registration time of the end user client expires, Cisco Unified Border Element (SP Edition) performs the registration processing again to refresh the callee/recipient address location through registration.
See “Provisional Delegate Registration Commands” section for more information on configuration steps and commands.
Configuring Delegate Registration Profile
Cisco Unified Border Element (SP Edition) requires a configured subscriber for each end user client upon whose behalf the SBC performs registration. The user may configure retry counts, retry intervals, duration, and the refresh buffer time for each configured subscriber, also called “delegated subscriber.” Several subscribers may all share the same nondefault values for the fields in the Delegate Registrations (amb_mw_sudb_subscriber) table. Instead of requiring configuration for each subscriber separately, Cisco Unified Border Element (SP Edition) allows the user to configure a subscriber profile that can be applied to one or more subscribers.
Use the delegate-profile profile-name command to configure a profile for a delegate registration subscriber.
Provisional Delegate Registration Commands
When the AdminStatus of the Delegate Registrations table is set to AdminStatusUp, Cisco Unified Border Element (SP Edition) attempts to register with the registrar. If the registration is successful, the delegate/client device is treated the same as all other subscribers. Cisco Unified Border Element (SP Edition) registers the device for the length of time specified. Cisco Unified Border Element (SP Edition) renews the registration before it expires, with the specified configurable buffer time.
If a registration (or re-registration) fails, Cisco Unified Border Element (SP Edition) retries registration after the configured delay time. Cisco Unified Border Element (SP Edition) retries the specified number of times. If registration still fails, Cisco Unified Border Element (SP Edition) logs the failure and sets the subscriber operating status to failed.
The following commands are used to configure Provisional Delegate Registration:
- Use the delegate-profile command to configure a delegate client registration profile that can be applied to a delegate subscriber. After a delegate profile is configured, profile parameters that specify duration, retry-count, retry-interval, and refresh-buffer may optionally be configured.
- Use the subscriber aor command to define the address of record for the subscriber and define the unique subscriber for whom you want to configure delegate registration. The subscriber must have one or more SIP contacts/URIs associated with it.
- Use the sip-contact uri command to configure a SIP contact URI for a subscriber. The contact information is used to provision Cisco Unified Border Element (SP Edition) with client device information, so the SBC can register the device. For every delegate registration configured with the delegate-registration hostname command, one or more SIP contacts/URIs must be configured in the SIP Contacts table (amb_mw_sudb_local_id).
- Use the delegate-registration hostname command to configure a delegate registration for a delegate client.
- Use the profile command to apply a delegate registration profile to a delegate registration subscriber
- Use the show sbc sbc name sbe sip subscribers command to display subscribers for whom Provisioned Delegate Registration has been provisioned.
- Use the show sbc sbc name sbe sip delegate-profiles command to display subscriber profiles for whom Provisioned Delegate Registration has been configured.
Configuring Provisional Delegate Registration
This task configures in order: a profile for a delegate registration subscriber; delegate registration for a specified subscriber associated with an individual client device; delegate registration for a specified client/delegate device; and displays subscribers and subscriber profiles for whom delegate registration have been configured.
SUMMARY STEPS
4. delegate-profile profile name
6. retry-count #times to retry
7. retry-interval retry time in secs
8. refresh-buffer timeout in secs
14. delegate registration hostname
DETAILED STEPS
Configuration Examples
This section has the following configuration examples:
- SIP Fast Registration Example
- SoftSwitch Shielding and Aggregate Registration Configuration Examples
- Registration Monitoring Examples
- Provisional Delegate Registration Examples
- Contact Username Passthrough Examples
- Alternative Contact Rewriting Example
- Registering with Softswitch via Cisco SRP Integrated Access Device (IAD) Examples
SIP Fast Registration Example
Use the show platform hardware qfp active feature sbc sfx command to display the QFP SIP Fast-Register (SFX) counters. Information about how SIP fast-register (SFX) messages are processed, including which SIP REGISTER request packets are punted to the Route Processor (RP) or dropped, may help explain why call rates are low and why the RP CPU load is high.
The following example shows information about the parsing of SIP fast-register (SFX) messages in the Cisco QuantumFlow Processor (QFP):
SoftSwitch Shielding and Aggregate Registration Configuration Examples
The following is a configuration example showing that Aggregate Registration and SoftSwitch Shielding are configured:
The following example configures SoftSwitch Shielding on adjacency “SoftSwitch:”
The following example shows detailed output for adjacency SoftSwitch, including the “Register Out Timer:” field that shows the time interval in seconds when the SBC forwards the next REGISTER messages to the softswitch.
The following example enables Aggregate Registration on adjacency Cary-IP-PBX, which has a preset access profile specified because it faces an access device on a UNI network. The last three commands in the configuration, entered in the correct order, enable the aggregate registration call routing to work.
The following example displays detailed output for adjacency Cary-IP-PBX, including the “Register Aggregate:” field that shows Aggregate Registration is “Enabled.”
Registration Monitoring Examples
The following example shows how monitoring of event subscriptions as a result of registration state changes is enabled:
The following example displays detailed output for adjacency Cary-IP-PBX, including the “Registration Monitor:” field that shows Registration Monitoring is “Enabled:”
Provisional Delegate Registration Examples
The following example configures a delegate registration profile that can be applied to a delegate registration subscriber.
The following example configures a SIP contact for a subscriber, for whom a subscriber detail table exists, and for whom, after the SIP contact is configured, delegate registration can be configured:
The following example configures a delegate registration for a specified client device address location, after the SIP contact information has been configured:
The following show example displays subscribers for which delegate registration have been configured. The delegate keyword displays the associated URI contact information for subscribers.
The following show example displays subscriber profiles for subscribers for whom delegate registration has been configured.
Contact Username Passthrough Examples
The following is an example with a single contact showing that the username part of the contact is passed through unchanged:
The following is an example flow of multiple registrations for the same subscriber; the example illustrates how a sequence of REGISTER requests registering multiple contacts behaves. This example assumes all headers are omitted from the requests, apart from Contact headers, and that the registrar-facing adjacency has a signaling-port range from 5060 to 5063 (this means 4 local ports are available).
Step 1 A REGISTER is received registering two contact addresses for the number 5551234.
Step 2 The SBC forwards this REGISTER to the registrar having rewritten the contact address and port.
Step 3 Another REGISTER is received for the number 5551234, registering another endpoint with a duplicate username of “bob.”
Step 4 The SBC forwards this to the registrar, again passing the username through unchanged.
Step 5 A third endpoint registers for the same number. This endpoint provides a very long contact name in the contact field.
Step 6 The SBC forwards this request to the registrar and rewrites the username because it is over the maximum passthrough length (32).
Alternative Contact Rewriting Example
The following example shows how to configure the Alternative Contact Rewriting feature on the SBC:
Registering with Softswitch via Cisco SRP Integrated Access Device (IAD) Examples
The following example shows how to register a subscriber with Softswitch, using the Cisco SRP Integrated Access Device (IAD).
This example uses IP realms in the adjacency. See IP Realm Support for information on IP Realms.