You can configure endpoints on Cisco IOS SIP TDM gateways, Cisco UBEs, and Cisco Unified CME to register to a primary and a secondary registrar. You can use this setup to register all endpoints to their assigned registrar using authentication details that can be associated with only one domain (or service provider). The drawback is that if the registrar or service provider domain becomes unavailable, users supported on Cisco IOS SIP TDM gateways, Cisco UBEs, and Cisco Unified CME cannot make or receive calls.

The Support for Multiple Registrars on SIP Trunks on a Cisco Unified Border Element, on Cisco IOS SIP TDM Gateways, and on Cisco Unified Communications Manager Express feature provides support for simultaneous registration with multiple registrars for endpoints on Cisco IOS SIP TDM gateways, Cisco UBEs, and Cisco Unified CME. This feature allows outbound and inbound traffic to be distributed across different service providers while simultaneously providing redundancy for users supported on these devices.

Note

In a Cisco UBE multihome environment, all sets of credentials configured under the SIP user agent are sent to all configured registrars, regardless of realm configuration. This means that if a Cisco UBE registers multiple service providers, the credentials for both service providers are sent out to both. While the correct credentials will register, the incorrect sets will fail, possibly resulting in security measures taken by the service provider for failed registration attempts.

The Support for Multiple Registrars on SIP Trunks on a Cisco Unified Border Element, on Cisco IOS SIP TDM Gateways, and on Cisco Unified Communications Manager Express feature is available in Cisco IOS Release 15.0(1)XA and later releases and utilizes the authentication command to allow configuration for specific endpoints and includes the following attributes and enhancements:

• You can configure up to 12 instances of the authentication command for a given endpoint, supporting 12 different realms for a single service provider domain.

• The authentication behavior can handle challenges from different service providers for SIP REGISTER and SIP INVITE/Other messages.

• You can specify a realm, which acts as a unique key for picking up username and password authentication details for each endpoint.

• The system uses authentication details to rebuild SIP Request messages in response to challenges.

• Enhancements introduced by this feature apply at both the dial peer and SIP user agent (UA) level.

The credentials command is used to trigger SIP Register requests wherever registration is required for users who are not part of any POTS dial peers. The Support for Multiple Registrars on SIP Trunks on a Cisco Unified Border Element, on Cisco IOS SIP TDM Gateways, and on Cisco Unified Communications Manager Express feature is available in Cisco IOS Release 15.0(1)XA and later releases and modifies the credentials command to allow configuration for specific endpoints and includes the following attributes and enhancements:

• Credentials behavior supports SIP REGISTER and SIP INVITE/Other message challenges.

• You can use the number keyword to specify an endpoint, the value of which is used to populate the user portion of the To field in outgoing SIP REGISTER messages.

• The number keyword is optional and is used to allow the endpoint number to be different from the username.

• When both number and realm are configured, this pair of values acts as a unique key to pick up the username and password credentials configured for the endpoint.

• A maximum of 12 different realms can be configured for a given endpoint.

When a SIP INVITE or SIP REGISTER request is challenged, the username and password details for authentication are determined in the following order:

Note	Configuring more than one username is not supported--you must remove any currently configured username before configuring a new username.

1. If the realm specified in the challenge matches the realm in the authentication configuration for a POTS dial peer, the system uses the corresponding username and password.

2. If the realm specified in the challenge doesn’t match the configured authentication for the POTS dial peer, then it will check for credentials configured for SIP UA.

3. If the realm specified in the challenge does not match the realm configured for credentials, then it will check for authentication configurations for SIP UA.

4. If the system does not find a matching authentication or credential for the received realm, then the request is terminated.

5. If there is no realm specified for the authentication configuration, then the system uses the username received from the challenge to build the response message.

When the primary and secondary registrar scenario is configured, the registrar address is used to populate the host portion of the From header in outbound SIP INVITE messages. However, when multiple registrars are configured, the only way to determine which registrar address is used to populate the host portion of the From header is to designate a single service provider domain as the preferred localhost name. The following behaviors are the result of using the preferred keyword with the localhost command (or voice-class sip localhost command for individual dial peers) when configuring multiple registrars:

• If the localhost command is enabled with the optional preferred keyword included, then the From header of outgoing SIP INVITE messages is populated with the domain name specified by the localhost command configuration.

• If the localhost command is not enabled or if it is enabled without the optional preferred keyword, then the best local interface address is used to populate the From header of outgoing SIP INVITE messages.

To configure multiple registrars on SIP trunks, use the registrar and authentication commands as described in the following tasks: