About Registrations
For an endpoint to use the Expressway as its SIP registrar or H.323 gatekeeper, the endpoint must first register with the Expressway. The Expressway can be configured to control which devices are allowed to register with it by using the following mechanisms:
-
A device authentication process based on the username and password supplied by the endpoint.
-
A registration restriction policy that uses either Allow Lists or Deny Lists or an external policy service to specify which aliases can and cannot register with the Expressway.
-
Restrictions based on IP addresses and subnet ranges through the specification of subzone membership rules and subzone registration policies.
You can use these mechanisms together. For example, you can use authentication to verify an endpoint’s identity from a corporate directory, and registration restriction to control which of those authenticated endpoints may register with a particular Expressway.
You can also control some protocol-specific behavior, including:
-
The Registration conflict mode and Auto discover settings for H.323 registrations
-
The SIP registration proxy mode for SIP registrations
For specific information about how registrations are managed across peers in a cluster, see the Sharing Registrations Across Peers section.
In a Unified Communications deployment, endpoint registration for SIP devices may be provided by Unified CM. In this scenario, the Expressway provides secure firewall traversal and line-side support for Unified CM registrations. When configuring a domain, you can select whether Cisco Unified Communications Manager or Expressway provides registration and provisioning services for the domain.
Finding an Expressway with Which to Register
Before an endpoint can register with a Expressway, it must determine which Expressway it can or should be registering with. This setting is configured on the endpoint, and the process is different for SIP and H.323.
MCU, Gateway, and Content Server Registration
H.323 systems such as gateways, MCUs and Content Servers can also register with a Expressway. They are known as locally registered services. These systems are configured with their own prefix, which they provide to the Expressway when registering. The Expressway will then know to route all calls that begin with that prefix to the gateway, MCU or Content Server as appropriate. These prefixes can also be used to control registrations.
SIP devices cannot register prefixes. If your dial plan dictates that a SIP device should be reached via a particular prefix, then you should add the device as a neighbor zone with an associated search rule using a pattern match equal to the prefix to be used.
Configuring Registration Restriction Policy
The Registration configuration page (
) is used to control how the Expressway manages its registrations.The Restriction policy option specifies the policy to use when determining which endpoints may register with the Expressway. The options are:
-
None: Any endpoint may register.
-
Allow List: Only those endpoints with an alias that matches an entry in the Allow List may register.
-
Deny List: All endpoints may register, unless they match an entry on the Deny List.
-
Policy service: Only endpoints that register with details allowed by the external policy service may register.
The default is None.
If you use an Allow List or Deny List, you must also go to the appropriate Registration Allow List or Registration Deny List configuration page to create the list.
The Policy service option is used if you want to refer all registration restriction policy decisions out to an external service. If you select this option an extra set of configuration fields appear so that you can specify the connection details of the external service. See Configuring Registration Policy to Use an External Service.
Registering Aliases
After the device authentication process (if required) has been completed, the endpoint will then attempt to register its aliases with the Expressway.
H.323
When registering, the H.323 endpoint presents the Expressway with one or more of the following:
-
one or more H.323 IDs
-
one or more E.164 aliases
-
one or more URIs
Users of other registered endpoints can then call the endpoint by dialing any of these aliases.
-
You are recommended to register your H.323 endpoints using a URI. This facilitates interworking between SIP and H.323, as SIP endpoints register using a URI as standard.
-
You are recommended to not use aliases that reveal sensitive information. Due to the nature of H.323, call setup information is exchanged in an unencrypted form.
SIP
When registering, the SIP endpoint presents the Expressway with its contact address (IP address) and logical address (Address of Record). The logical address is considered to be its alias, and will generally be in the form of a URI.
H.350 directory authentication and registrations
If the Expressway is using an H.350 directory service to authenticate registration requests, the Source of aliases for registration setting is used to determine which aliases the endpoint is allowed to attempt to register with. See "Using an H.350 directory service lookup via LDAP" for more information.
Attempts to register using an existing alias
An endpoint may attempt to register with the Expressway using an alias that is already registered to the system. How this is managed depends on how the Expressway is configured and whether the endpoint is SIP or H.323.
-
H.323: An H.323 endpoint may attempt to register with the Expressway using an alias that has already been registered on the Expressway from another IP address. You can control how the Expressway behaves in this situation by configuring the Registration conflict mode , on the H.323 page ( ).
-
SIP: A SIP endpoint will always be allowed to register using an alias that is already in use from another IP address. When a call is received for this alias, all endpoints registered using that alias will be called simultaneously. This SIP feature is known as "forking".
Blocking registrations
If you have configured the Expressway to use a Deny List, you will have an option to block the registration. This will add all the aliases used by that endpoint to the Deny List.
Removing existing registrations
After a restriction policy has been activated, it controls all registration requests from that point forward. However, any existing registrations may remain in place, even if the new list would otherwise block them. Therefore, you are recommended to manually remove all existing unwanted registrations after you have implemented a restriction policy.
To manually remove a registration, go to Unregister.
, select the registrations you want to remove, and clickIf the registered device is in an active call and its registration is removed (or expires), the effect on the call is dependent on the protocol:
-
H.323: The call is taken down.
-
SIP: The call stays up by default. This SIP behavior can be changed but only via the CLI by using the command
xConfiguration SIP Registration Call Remove
.
Re-registrations
All endpoints must periodically re-register with the Expressway in order to keep their registration active. If you do not manually delete the registration, the registration could be removed when the endpoint attempts to re-register, but this depends on the protocol being used by the endpoint:
-
H.323 endpoints may use "light" re-registrations which do not contain all the aliases presented in the initial registration, so the re-registration may not get filtered by the restriction policy. If this is the case, the registration will not expire at the end of the registration timeout period and must be removed manually.
-
SIP re-registrations contain the same information as the initial registrations so will be filtered by the restriction policy. This means that, after the list has been activated, all SIP registrations will disappear at the end of their registration timeout period.
The frequency of re-registrations is determined by the Registration controls setting for SIP ( ) and the Time to live setting for H.323 ( ).
![]() Note |
By reducing the registration time to live too much, you risk flooding the Expressway with registration requests, which will severely impact performance. This impact is proportional to the number of endpoints, so you should balance the need for occasional quick failover against the need for continuous good performance. |