Registering devices to Pexip Infinity

Pexip Infinity can act as a SIP registrar and H.323 gatekeeper, which means that you can register SIP and H.323 endpoints directly to Pexip Infinity. This allows Pexip Infinity to route calls to those registered devices without having to go via an external SIP proxy or H.323 gatekeeper, or rely on DNS.

Pexip Connect desktop apps can also register to Pexip Infinity Conferencing Nodes. This allows these devices to receive calls via Pexip Infinity and use directory lookup services.

Devices can only register to Pexip Infinity with a permitted alias and by supplying valid credentials (if authentication is required). Allowed aliases and their associated credentials can be configured manually, or they can be bulk provisioned from directory information contained in a Windows Active Directory LDAP server, or any other LDAP-accessible database.

Additionally, Connect desktop apps support Active Directory (AD) Single Sign-On (SSO) services, meaning users can register to Pexip Infinity and authenticate their clients using their AD credentials.

Note that devices do not need to be registered in order to make calls to Pexip Infinity. However, you can configure your deployment so that only registered devices can make gateway calls, thus preventing potential for toll fraud.

For instructions on how to register the Connect app, see Registering and provisioning the Connect desktop app.

Configuration summary for enabling registrations

To configure Pexip Infinity to accept registrations and route calls to registered devices you must:

  1. Ensure that the Pexip Infinity's registrar service is enabled (Services > Registrar).
  2. Configure the aliases that devices are allowed to register to Pexip Infinity (Users & Devices > Device aliases).
  3. Consider if authentication is required, what form that authentication should take, and whether to provision individual users with their registration details, and then configure the appropriate services and credentials.
  4. Configure appropriate Call Routing Rules (Services > Call routing). Rules are required in all cases except for when using Manual routing to add a participant to a conference.

Each step is described in more detail below, after the explanation of how Pexip Infinity manages registered devices.

How it works

Registering devices

The registrar service on Pexip Infinity is enabled by default. However, a device can only register to Pexip Infinity if the alias it wants to register has been added to Pexip Infinity's list of allowed device aliases (Users & Devices > Device aliases).

Device registrations can optionally also be subject to authentication. To enforce authentication, username and password credentials must be specified for each alias that is added to Pexip Infinity's list of allowed device aliases (unless you are using Connect apps with SSO services). When credentials are specified, the device's registration request is challenged and the device is only allowed to register with that alias if it provides matching credentials. Pexip Infinity supports Digest authentication only.

A device can register to any Conferencing Node. Pexip Infinity supports H.323 alternate gatekeeper registrations for nodes in the same system location, but does not apply any other form of registration load balancing or failover. Multiple devices can register with the same alias. After a device has registered it must periodically refresh that registration.

SIP and H.323 devices

You can register SIP and H.323 devices to Pexip Infinity:

  • To register a SIP device, use the IP address or FQDN of a local Conferencing Node as the SIP proxy.

    For the registration of endpoints, it is important to know how the individual endpoint reacts to different environments. Some devices respect the weight and priority values returned in SRV queries, such that configuring them with the SIP URI and correct SIP domain works very well; other devices may read only the first FQDN returned in an SRV query and never attempt to re-resolve until its SIP settings are changed or the endpoint rebooted. Please contact your your Pexip authorized support representative for further guidance.

  • To register an H.323 device, use the IP address or FQDN of a local Conferencing Node as the H.323 gatekeeper.

    All of the device aliases presented in an H.323 registration request must be in the list of allowed device aliases. If any alias is not present, none of the aliases will be allowed to register. Additionally, if device authentication is being used, all of the device aliases in the request must be configured with the same credentials.

If your endpoint supports both SIP and H.323, you should register it to Pexip Infinity over just one protocol, either SIP or H.323, but not both.

Connect app registrations

To register a Connect app, ensure that either the IP address or FQDN of a local Conferencing Node is used as the configured Registration Host address. Alternatively, you can specify a domain if you have set up the appropriate DNS records. Connect apps register over the WebRTC protocol.

  • Connect apps can register in one of two ways: non-SSO, which can optionally include a username and password for authentication, or using SSO, which uses a Single Sign On service (SSO) such as AD FS for authentication. For any given alias, we recommend that you enable Connect app registrations for just one of these methods, not both. This is particularly important if you have enabled non-SSO registrations but have not also configured username and password authentication credentials.
  • You can provision individual users with their registration details and automatically apply those registration settings to their Connect app. See Registering and provisioning the Connect desktop app for more information.
  • When your Connect app is registered, as well as being able to receive calls, you can filter and lookup the contact details (phone book / directory) of other devices or VMRs that are set up on the Pexip Infinity platform. See Directory (phone book) of devices and VMRs for registered Connect apps for more information.

Calling registered devices

Whenever Pexip Infinity needs to place a call it follows the Call routing logic shown in the diagram below. If the alias it is trying to place the call to is currently registered, then Pexip Infinity will place the call to that registered device instead of attempting to find it via other means such as call control or DNS.

When calling a registered device:

  • the Conferencing Node to which the device is registered will place the call to the device (media may flow through other nodes, as per the platform's standard distributed conferencing behavior)
  • the outbound call is always placed to the registered device over the same protocol that it used to make the registration
  • if multiple devices are registered with the same alias, Pexip Infinity will place a call to each device, i.e. it will fork the call.

Requirement for Call Routing Rules

In most cases, you must also configure a suitable Call Routing Rule that instructs Pexip Infinity to place the outbound call to the device. A Call Routing Rule is required when:

  • making a call to another device or system via the Infinity Gateway
  • using Automatic routing when adding a participant to a conference.

A Call Routing Rule is not required when:

  • using Manual routing when adding a participant to a conference.

When configuring rules you must define:

  • whether the rule applies only to incoming gateway calls, or only to outgoing calls placed from within a Pexip Infinity conference (where Automatic routing has been selected), or to both incoming gateway calls and outgoing calls from conferences
  • the destination aliases to be matched — this needs to match the pattern of the registered device aliases
  • whether to route the call to Registered devices only (in which case the call will fail if the device is not currently registered), or to Registered device or external system which will route the call to a matching registered device if it is currently registered, otherwise it will attempt to route the call via an external system.

This table shows the rule settings you need to use for the different calling scenarios between, to, and from registered devices:

Purpose Incoming gateway calls Outgoing calls from a conference Match incoming calls from registered devices only Match <protocol> Destination alias regex match Call target Protocol
Enable calls between two registered devices

 

Limit to the selected source (caller) protocols e.g. SIP, H.323, WebRTC, MS-SIP (Skype for Business) as required As appropriate for your registered device aliases e.g.
.+@<Infinity domain>
Registered devices only n/a
Allow calls to registered devices (direct or from a VMR)

  Registered devices only n/a
Allow calls from registered devices to an external system

 

Typically, aliases that are not in the Pexip Infinity domain e.g.
(?!.*@<Infinity domain>$).*
Registered device or external system Select as required (needs a separate rule per protocol)

Avoiding call looping

Call Routing Rules that are intended to route calls to devices registered to Pexip Infinity (e.g. Connect apps) could, depending upon DNS configuration, result in call looping if the destination device alias is not currently registered.

This can occur if the Call Routing Rule handling those calls has its Call target set to Registered device or external system. In this case, if the alias is not currently registered, Pexip Infinity will attempt to place the call via DNS or a call control system. This could result in the call being routed back to Pexip Infinity which would then match the same Call Routing Rule and result in a loop.

To avoid this, we recommend that you configure a Call target of Registered devices only for your Call Routing Rules that match those device aliases that you expect to be registered. This ensures that the call will fail cleanly without looping if the device is not currently registered.

Note that in earlier versions of Pexip Infinity before the availability of the Registered devices only option, we previously recommended configuring a SIP proxy with an address of nowhere.invalid. This workaround will still avoid the call looping issue, but if you have any existing rules that use this method, we recommend modifying them to use a Call target of Registered devices only instead.

Call routing logic

The stage in Pexip Infinity's call routing logic where it checks whether the device that is being called is registered is highlighted in the following diagram:

Note that you can configure rules so that only registered devices are allowed to make calls via the Infinity Gateway.

Configuring the registrar service

Devices can only register to Pexip Infinity if the registrar service is enabled.

To configure Pexip Infinity's registrar service, go to Services > Registrar. The options are:

Option Description
Enable registrar

Controls whether devices can register to Pexip Infinity. Devices must register with a permitted alias (configured via Users & Devices > Device aliases).

The registrar service is enabled by default.

Registration refresh (general)
Registration refresh strategy

Defines which strategy to use when calculating the expiry time of a SIP or H.323 registration:

  • Adaptive: Pexip Infinity automatically adjusts the refresh interval depending on the number of current registrations on the Conferencing Node handling the registration request, in order to spread the load of registration refreshes. As the number of devices registered to a Conferencing Node increases, the refresh interval calculated by Pexip Infinity will also typically increase, although it will always be within the bounds of the configured minimum and maximum refresh intervals.
  • Basic: Pexip Infinity simply uses the configured minimum and maximum settings, along with the requested value, to determine the refresh interval.

Default: Adaptive.

Minimum refresh interval (Adaptive strategy)

The minimum interval in seconds before a device's registration must be refreshed, when using the Adaptive strategy.

Default: 60 seconds.

Maximum refresh interval (Adaptive strategy)

The maximum interval in seconds before a device's registration must be refreshed, when using the Adaptive strategy.

Default: 3600 seconds.

Minimum refresh interval (Basic strategy)

The minimum interval in seconds before a device's registration must be refreshed, when using the Basic strategy.

Default: 60 seconds.

Maximum refresh interval (Basic strategy)

The maximum interval in seconds before a device's registration must be refreshed, when using the Basic strategy.

Default: 300 seconds.

Registration refresh intervals for SIP endpoints behind NATs
Minimum refresh interval (when behind NAT)

The minimum interval in seconds before a device's registration must be refreshed, for a SIP endpoint behind a NAT.

Default: 60 seconds.

Maximum refresh interval (when behind NAT)

The maximum interval in seconds before a device's registration must be refreshed, for a SIP endpoint behind a NAT.

The refresh interval for SIP endpoints behind a NAT typically has to be shorter than the interval for other endpoints. This is to help keep the NAT pinhole alive.

Default: 90 seconds.

Call routing for desktop clients
Route calls via registrar

When enabled, all calls from registered Connect desktop apps are routed via the Conferencing Node to which the client is registered, regardless of the domain being called. The Connect desktop app uses the previously-discovered IP address of the Conferencing Node — it does not perform a DNS SRV lookup of the Registration Host server address each time a call is placed.

When disabled, DNS is used to identify the Conferencing Node to which calls are placed from registered clients as per the process described in Connect desktop app.

Default: enabled.

Note that:

  • In all circumstances, requests for a value lower than the relevant Minimum refresh delay will result in the registration being rejected.
  • The registration refresh strategies apply only to SIP and H.323 endpoints. Connect apps have a fixed refresh interval of 120 seconds.
  • Any changes to the Route calls via registrar setting are picked up by the client each time it re-registers or refreshes its registration.

Specifying the aliases that devices are allowed to register with

Devices can only register to Pexip Infinity with a permitted alias.

You can bulk provision the device aliases from directory information contained in a Windows Active Directory LDAP server, or any other LDAP-accessible database. You can also import device aliases using a CSV file.

To manually configure the aliases that devices are allowed to register to Pexip Infinity, go to Users & Devices > Device aliases. The options are:

Option Description
Device alias The alias URI that a device/client can register to Pexip Infinity. The alias must be an exact match; regular expressions are not supported. It cannot be blank.
Creation time This read-only field shows the date and time when this record was first configured.
Service tag

This optional field lets you assign a unique identifier to this service, which you can then use to track use of the service.

Description An optional description of the device. Note that this description may be displayed to end users on registered Connect apps who are performing a directory search.
Enable SIP registration Allows this device alias to register over the SIP protocol. The registration is optionally authenticated using the specified Username and Password.
Enable H.323 registration Allows this device alias to register over the H.323 protocol. The registration is optionally authenticated using the specified Username and Password.
Enable Infinity Connect registration (non-SSO) Allows a Connect app to register using this alias (not using SSO services). The registration is optionally authenticated using the specified Username and Password.
Enable Infinity Connect registration using SSO

Allows a Connect app to register using this alias, using Single Sign-On (SSO) services such as AD FS to authenticate the registration.

For more information, see Connect app registrations.

Username and Password

These credentials apply to aliases that are enabled to register using SIP, H.323 or Connect app non-SSO registration.

They are used to authenticate the device's registration. Credentials are optional and the device is not challenged if no credentials are entered.

The username and password are case-sensitive.

Device origin The name of the LDAP sync template used to create this device alias (it is blank if the device was created by manual input or via the API). This field is read-only.
Owner's email address

The email address of the owner of the device alias. Provisioning messages for this device alias will be sent to this address.

This field is required for devices registering using Infinity Connect registration using SSO.

Directory (phone book) of devices and VMRs for registered Connect apps

Pexip Infinity provides a directory search facility to all Connect apps that are registered to a Conferencing Node.

Upon request from the Connect app (typically when the user performs a search on their contact list), Pexip Infinity will return a list of device and conference aliases that match the search string entered by the user.

Pexip Infinity checks the supplied search string to see if it is contained within the alias or alias description of any of its configured services (Virtual Meeting Rooms, Virtual Auditoriums or Virtual Receptions), or within the device aliases/descriptions that are allowed to register to Pexip Infinity (it does not matter if that device alias is currently registered or not, and no presence information is supplied).

Pexip Infinity returns up to 5 service aliases and up to 5 device aliases.

The directory service can be controlled by the Enable directory global setting (Platform > Global settings > Connectivity). It is enabled by default.

Feature extensions via the external policy API

If you make use of the external policy API, the external system can be used to:

  • determine whether a device alias is allowed to register to a Conferencing Node.
  • obtain extended directory information — this can replace or be used in addition to the list of local device and VMR aliases supplied to registered Connect apps.

See Using external and local policy to control Pexip Infinity behavior for more information.

Troubleshooting and logging

To see a list of all device aliases that are currently registered to the Pexip Infinity platform, go to Status > Registrations.

Each device alias configured in Pexip Infinity has to be enabled for the individual protocols over which that alias can be registered. If the alias is configured but the device cannot register, you should check which protocols have been enabled for registration for that alias.

Successful registration requests and expired registrations are recorded in the administrator log, for example:

Message="Registration added" Alias="bob@example.com" Protocol="SIP" Registration-id="958e52ba-4328-424b-8d77-c18a59f4c1da" Natted="False" Location="Europe"

Message="Registration deleted" Alias="55170" Protocol="H323" Registration-id="302fd156-85bd-497d-85dc-c5b29a16d612" Location="Europe" Reason="Registration expired"

Failed registration requests (due to, for example, an unknown device alias or authorization failure) and refreshed registrations are recorded in the support log only.

If a call fails to be placed to a registered device, check that an appropriate Call Routing Rule has been configured that has suitable destination alias matching strings for the registered alias (and ensure that call looping cannot occur).

Note that registrations are enabled by default when Pexip Infinity is installed. Therefore, until device aliases are configured, every registration request will be rejected.

Maintenance mode

Devices cannot register to a Conferencing Node that is in maintenance mode:

  • Requests from SIP devices and Connect apps are rejected with "503 Service Unavailable".
  • Requests from H.323 endpoints receive no response.

    • If the H.323 endpoint has previously registered and received a list of alternate gatekeepers, it should then attempt to register to one of the alternates instead.
    • If the H.323 endpoint has not previously registered (and therefore has not received a list of alternate gatekeepers) it will typically be unable to register. However, it may attempt to register to another Conferencing Node if multiple h323rs DNS SRV records have been configured and the endpoint can handle multiple records.

SIP registration behavior

The alias registered by a SIP device alias is normally a URI, for example alice@example.com, and thus the full device alias (including any domain) must match an entry in the Device aliases list.

When troubleshooting failed registrations, you need to look in the support log. Typical messages related to various successful and unsuccessful SIP registration attempts are described in the following table:

Registration scenario Behavior and example support log messages
No authentication is required and the alias exists in the list of device aliases

Register request is accepted with 200 response

Message="Summarised received SIP request" Src-address="10.44.2.77" Src-port="42576" Dst-address="10.44.155.21" Dst-port="5061" Transport="TLS" Method="REGISTER" From="sip:bob@example.com" To="sip:bob@example.com" Contacts=" <sip:bob@10.44.2.77>;+sip.instance="<urn:uuid:f0b7095d-5ee0-548a-80a8-c522aafdf94b>"" Call-ID="58078da9a56dbcee@10.44.2.77" CSeq="62195" Request-URI="sip:example.com" Received-time="2017-03-23T16:11:59,795756"

Message="Registration added" Alias="bob@example.com" Protocol="SIP" Registration-id="cacef4f2-dc7b-4cbe-9a6f-6c69aea640fb" Natted="False" Location="Europe"

Message="Summarised sending SIP response" Src-address="10.44.155.21" Src-port="5061" Dst-address="10.44.2.77" Dst-port="42576" Transport="TLS" Method="REGISTER" From="sip:bob@pexip.com" To="sip:bob@example.com" Contacts=" <sip:bob@10.44.2.77>;+sip.instance="<urn:uuid:f0b7095d-5ee0-548a-80a8-c522aafdf94b>";expires=74" Call-ID="58078da9a56dbcee@10.44.2.77" CSeq="62195" Status-code="200"

Requested alias does not exist in the list of device aliases

Register request is rejected with 403 response

Message="Summarised received SIP request" Src-address="10.44.2.77" Src-port="42576" Dst-address="10.44.155.21" Dst-port="5061" Transport="TLS" Method="REGISTER" From="sip:bob@example.com" To="sip:bob@example.com" Contacts=" <sip:bob@10.44.2.77>;+sip.instance="<urn:uuid:f0b7095d-5ee0-548a-80a8-c522aafdf94b>"" Call-ID="58078da9a56dbcee@10.44.2.77" CSeq="62191" Request-URI="sip:example.com" Received-time="2017-03-23T16:02:29,795311"

Message="Summarised sending SIP response" Src-address="10.44.155.21" Src-port="5061" Dst-address="10.44.2.77" Dst-port="42576" Transport="TLS" Method="REGISTER" From="sip:bob@example.com" To="sip:bob@example.com" Contacts="" Call-ID="58078da9a56dbcee@10.44.2.77" CSeq="62191" Status-code="403"

Authentication is required but the wrong credentials are supplied

Register request is rejected with 401 response (two requests and two 401 responses)

Message="Summarised received SIP request" Src-address="10.44.2.77" Src-port="42576" Dst-address="10.44.155.21" Dst-port="5061" Transport="TLS" Method="REGISTER" From="sip:bob@example.com" To="sip:bob@example.com" Contacts=" <sip:bob@10.44.2.77>;+sip.instance="<urn:uuid:f0b7095d-5ee0-548a-80a8-c522aafdf94b>"" Call-ID="58078da9a56dbcee@10.44.2.77" CSeq="62171" Request-URI="sip:example.com" Received-time="2017-03-23T15:44:17,530041"

Message="Summarised sending SIP response" Src-address="10.44.155.21" Src-port="5061" Dst-address="10.44.2.77" Dst-port="42576" Transport="TLS" Method="REGISTER" From="sip:bob@example.com" To="sip:bob@example.com" Contacts="" Call-ID="58078da9a56dbcee@10.44.2.77" CSeq="62171" Status-code="401"

(this pair of messages is then repeated)

Authentication is required and correct credentials are supplied

The first register request is rejected with 401 response, then the second request (when the device will supply the requested credentials) is accepted with 200

Message="Summarised received SIP request" Src-address="10.44.2.77" Src-port="42576" Dst-address="10.44.155.21" Dst-port="5061" Transport="TLS" Method="REGISTER" From="sip:bob@example.com" To="sip:bob@example.com" Contacts=" <sip:bob@10.44.2.77>;+sip.instance="<urn:uuid:f0b7095d-5ee0-548a-80a8-c522aafdf94b>"" Call-ID="58078da9a56dbcee@10.44.2.77" CSeq="62177" Request-URI="sip:example.com" Received-time="2017-03-23T15:48:39,817656"

Message="Summarised sending SIP response" Src-address="10.44.155.21" Src-port="5061" Dst-address="10.44.2.77" Dst-port="42576" Transport="TLS" Method="REGISTER" From="sip:bob@example.com" To="sip:bob@example.com" Contacts="" Call-ID="58078da9a56dbcee@10.44.2.77" CSeq="62177" Status-code="401"

Message="Summarised received SIP request" Src-address="10.44.2.77" Src-port="42576" Dst-address="10.44.155.21" Dst-port="5061" Transport="TLS" Method="REGISTER" From="sip:bob@example.com" To="sip:bob@example.com" Contacts=" <sip:bob@10.44.2.77>;+sip.instance="<urn:uuid:f0b7095d-5ee0-548a-80a8-c522aafdf94b>"" Call-ID="58078da9a56dbcee@10.44.2.77" CSeq="62178" Request-URI="sip:example.com" Received-time="2017-03-23T15:48:39,873782"

Message="Registration added" Alias="bob@example.com" Protocol="SIP" Registration-id="aecae4f2-da7b-4dbe-9a6f-6c69feb689ea" Natted="False" Location="Europe"

Message="Summarised sending SIP response" Src-address="10.44.155.21" Src-port="5061" Dst-address="10.44.2.77" Dst-port="42576" Transport="TLS" Method="REGISTER" From="sip:bob@example.com" To="sip:bob@example.com" Contacts=" <sip:bob@10.44.2.77>;+sip.instance="<urn:uuid:f0b7095d-5ee0-548a-80a8-c522aafdf94b>";expires=111" Call-ID="58078da9a56dbcee@10.44.2.77" CSeq="62178" Status-code="200"

H.323 registration behavior

An H.323 device often registers multiple aliases such as an H.323 ID, an E.164 number, and in some cases the system name. H.323 ID aliases can take the form of a full URI.

All of the device aliases presented in an H.323 registration request must be in the list of allowed device aliases. If any alias is not present, none of the aliases will be allowed to register. Additionally, if device authentication is being used, all of the device aliases in the request must be configured with the same credentials.

When an alias does not exist in the list of device aliases, a message is written to the support log in the form:

Name="support.registration" Message="H.323 device authentication failed" Reason="Alias not found" Alias="(u'Bob Jones', 'h323_ID')"

To check all the aliases that are being presented from an endpoint, you can filter the support log by "registrationRequest", and then search for one of the aliases that you know is being presented. When you have found a suitable message, the terminalAlias section lists all of the aliases that are being presented, for example:

Name="support.h323.ras" Message="Received RAS message" Src-address="10.44.2.77" Src-port="1719" Dst-address="10.44.157.21" Dst-port="1719" Detail="registrationRequest:
...
terminalAlias: [
h323_ID:
 Bob Jones,
h323_ID:
 bob@example.com
dialedDigits:
 123456
]

WebRTC (Connect desktop app) non-SSO registration behavior

When an alias does not exist in the list of device aliases, a message is written to the support log in the form:

Name="support.registration" Message="REST device authentication failed" Reason="Alias not found" Alias="alice@example.com"

If the alias exists but the wrong credentials are supplied, a message is written to the support log in the form:

Name="support.registration" Message="REST device authentication failed" Reason="Invalid credentials" Alias="alice@example.com" Expected-username="alice" Supplied-username="slice"