About aliases and access numbers

Every Virtual Meeting Room (VMR), Virtual Auditorium, Virtual Reception, scheduled conference, Media Playback Service and Test Call Service has one or more aliases associated with it.

When Pexip Infinity receives an incoming call via one of its Conferencing Nodes, it checks whether the destination alias belongs to a Virtual Meeting Room, Virtual Auditorium, Virtual Reception, scheduled conference, Media Playback Service, or Test Call Service; if so, it will direct the call to that service. If the alias does not belong to any of the above services, Pexip Infinity next checks through the Call Routing Rules used by the Infinity Gateway to see if the alias matches any rules specified there — for more information, see Service precedence.

To allow a call that is placed from outside your Pexip Infinity deployment to reach your Conferencing Nodes, the alias that has been dialed by the external participant must usually be in the form of a URI (e.g. name@domain), and you must have appropriate DNS records set up so that any such calls to your domain are routed to your Conferencing Nodes. For more information, see DNS record examples.

When Pexip Infinity receives a call to a Virtual Meeting Room (including scheduled conferences) or Virtual Auditorium alias, it creates a conference instance and routes the call to that conference. Any further calls received to any of the aliases belonging to the same Virtual Meeting Room or Virtual Auditorium are routed to the same conference instance, for the duration of that particular conference. If the service has more than one alias, participants can dial any one of the aliases and be routed to the same conference instance. For more information, see Using multiple aliases to access the same service.

When a participant dials a Virtual Reception alias, they are taken to the Virtual Reception IVR service, from which they can use a DTMF keypad to enter the number of the Virtual Meeting Room or Virtual Auditorium they wish to join. This number must correspond to a numeric-only alias of the Virtual Meeting Room or Virtual Auditorium in question. For more information, see About the Virtual Reception IVR service.

When a participant dials a Media Playback Service alias, they are taken to the playback service which, after the media playback has completed, can be configured to transfer the participant (via another, different alias) to another service such as a VMR. For more information, see Configuring a Media Playback Service.

Pexip Infinity's Test Call Service provide a test loopback service that allows users to check the quality of their video and audio, and verifies that they can connect to a Conferencing Node. See Configuring the Test Call Service for more information.

In most cases, the alias received by Pexip Infinity is the same as the alias that the conference participant dialed from their endpoint, but there are some exceptions, described in Search rules and alias transforms and ENUM.

For simplicity, the following discussion assumes that the alias dialed by the endpoint user is the same as the alias received by Pexip Infinity.

Creating, editing and viewing aliases

Each alias is associated with a single service, but a service can have more than one alias.

To view a list of all existing aliases for all services, go to Services > Aliases. From here you can:

  • Sort the list of aliases alphabetically by Alias or by Service name.
  • Search for a particular alias.
  • Add a new alias.
  • Modify an alias, including changing the service with which it is associated.

You can also add or modify aliases while creating or editing a service.

When adding or editing aliases, the options are:

Option Description
Service Select the name of the Virtual Meeting Room, Virtual Auditorium, Virtual Reception, scheduled conference, Media Playback Service, or Test Call Service to access when participants dial this alias.
Alias

The alias that, when received by Pexip Infinity, is used to route the call to this service (Virtual Meeting Room, Virtual Auditorium, Virtual Reception, scheduled conference, Media Playback Service, or Test Call Service).

The alias entered here must match the alias as it is received by Pexip Infinity. Wildcards and regular expressions are not supported.

In most cases, the alias received by Pexip Infinity is the same as the alias that the participant used to call the service, but there are some exceptions, described in About aliases and access numbers.

You may also want to define multiple aliases for the same service to ensure that it can be accessed by devices and protocols that enforce specific alias formats — for more information, see Using multiple aliases to access the same service.

Description An optional description of the alias. This is useful if you have more than one alias for a service. Note that this description may be displayed to end users on registered Connect apps who are performing a directory search.

Restrictions

An alias can include a domain or subdomain but this is optional (see Domains). Aliases can contain numbers, letters, dashes and dots. In certain circumstances an alias can also be in the form of an IP address — for more information see Dialing by IP address.

Aliases do not support wildcards or regular expressions.

Case insensitivity

The aliases that you configure on Pexip Infinity are not case-sensitive, and Pexip Infinity treats all incoming aliases as not case-sensitive. For example, this means that:

  • a user who dials meet.alice will match against a VMR with an alias of Meet.Alice
  • a user who dials Meet.Alice will match against a VMR with an alias of meet.alice

Ignoring IP addresses

Pexip Infinity ignores any IP address or IP address and port combination appended to an alias. This is because some SIP endpoints automatically add the IP address of their proxy to the URI that is dialed by the user.

For example, a VMR with a single alias of meet.alice will be matched when an endpoint dials any of:

  • meet.alice
  • meet.alice@<IPaddress>
  • meet.alice@<IPaddress>:<port>

Dialing by IP address

We do not recommend dialing by IP address. However, to support endpoints that can only dial by IP address, you can give a service an alias that is the same as the IP address of one of your Conferencing Nodes.

In this case, when a user dials the IP address from that endpoint, the call will be routed directly to the Conferencing Node with that IP address. Pexip Infinity will then perform its standard behavior and check to see if the destination alias of the call (which in this scenario will be the dialed IP address) matches any of its configured aliases; if so, the call will be routed to the service (Virtual Reception, Virtual Meeting Room etc.) that is associated with that alias.

If other endpoints, such as Connect apps, dial the IP address alias, they will also be connected to the appropriate service (although the Conferencing Node they connect to is determined via other means).

In most cases you would use this feature to assign a Conferencing Node IP address as an alias for a Virtual Reception, so that users could then select which Virtual Meeting Room or Virtual Auditorium they wish to join. For more information, see About the Virtual Reception IVR service.

Ignoring protocol prefixes

Pexip Infinity ignores relevant URI schemes included in an alias, as in the case where a SIP endpoint automatically prefixes the URI dialed by the user with "sip:". The ignored prefixes are "sip:", "sips:" and "h323:". This is because the protocol used for the call does not matter to Pexip Infinity.

For example, a VMR with a single alias of meet.alice will be matched when an endpoint dials any of:

  • sip:meet.alice@IPaddress
  • sips:meet.alice@IPaddress
  • h323:meet.alice

Search rules and alias transforms

Some call control systems (for example the Cisco VCS) support the use of search rules and alias transforms. In these cases, the alias that was dialed by the endpoint user and received by the call control system may be changed by the call control system in some way before it is passed on to Pexip Infinity. Often this is done in larger deployments to support complex dial plans.

For example, the call control system might have a rule that replaces the domain example.com with example.net. This means that when a user dials meet.alice@example.com, the call is routed to meet.alice@example.net. Therefore it is this latter alias that must be configured on Pexip Infinity in order to match it with a VMR.

ENUM

The ENUM system allows users to dial an E.164 number (for example a telephone number) which is then mapped using DNS to a SIP URI. For more information, see RFC 3761.

For example, your dial plan could be set up so that when a user dials 555 0123, the call is routed via ENUM to meet.alice.

If your dial plan uses ENUM, the resulting SIP URIs must be included as aliases on Pexip Infinity in order to match them with a VMR.

Domains

Domains are optional in aliases. However, when a call is received to an alias in the form of a URI that includes a domain, the domain is not ignored.

For example, if a VMR is configured with an alias of meet.alice, users can dial meet.alice or meet.alice@<IPaddress> to access the meeting room. However, if they dial meet.alice@example.com they will not be able to access the VMR because the VMR alias does not include the domain.

When a SIP endpoint user dials an alias that does not include a domain (for example meet.alice), the SIP endpoint will automatically add its own domain to the alias (making it for example meet.alice@example.com). So even if the VMR is configured with an alias of meet.alice and this alias is dialed by a participant from a SIP endpoint, the participant will not be able to join the conference. (H.323 endpoints do not add domains.)

In the absence of a call control system to strip the domain part of the alias, you could instead add to the VMR a second alias of meet.alice@example.com so that participants can dial meet.alice from either a SIP or H.323 endpoint and access the same conference.

Using multiple aliases to access the same service

You may want conference participants to be able to dial different numbers to access the same Virtual Reception, or to allow different conference participants to dial different aliases but still end up in the same VMR.

Thus, depending on your deployment environment and the types of devices and protocols used to dial into your services, you may want to configure a variety of alias formats to allow access to those services, including:

  • name@domain (for full URI dialing such as from SIP clients)
  • name (for systems that strip off or do not require a domain)
  • numeric/E.164 (for endpoints that do not support URI dialing, or can only dial via IP address, or for audio-only callers via PSTN/ISDN gateways that need to be routed via a Virtual Reception).

It is often good practice to create a URI and a numeric alias as a minimum. If numeric/E.164 formatted aliases are used as your primary dial plan, you could also reuse the same number in a number@domain URI-style alias. Some example alias dial plans are given below.

You can add any number of aliases to a single service (Virtual Meeting Room, Virtual Reception etc). Note that the order in which aliases appear in the list of aliases is relevant when Automatically dialing out to a participant from a conference.

Adding additional aliases

To add an additional alias to a service while you are creating it, select Add another Alias.

To add another alias to an existing service:

  1. Go to Services > Virtual Meeting Rooms, Services > Virtual Auditoriums, Services > Virtual Receptions, Services > Scheduled Conferences or Services > Test Call Service as appropriate.
  2. Select the name of the service you wish to add the alias to.
  3. In the Aliases section at the bottom of the page, enter the new alias in the empty Alias field.
  4. Select Save.

If you have provisioned your VMRs from Active Directory via LDAP and you want to manually change or add aliases to those VMRs, you may want to ensure that Allow aliases to be overridden is enabled on the LDAP sync templates used to generate those VMRs, otherwise any changes you make will be overridden the next time that template is synchronized.

Examples

  • If some of your endpoints do not support URI dialing, you could set up a VMR for Alice with one alias of meet.alice.jones and another alias of 555 25423. This would give conference participants two different methods of accessing the same conference.
  • If your deployment includes a Virtual Reception, every Virtual Meeting Room and Virtual Auditorium that you want to be accessible from the Virtual Reception needs to have a numeric-only alias (so that participants can enter the number using DTMF), in addition to any aliases in the form of a URI. So to continue with our example, you could add a third alias to Alice's VMR of 25423, which is the number that participants would enter from the Virtual Reception. For more information, see About the Virtual Reception IVR service.
  • If you use an ISDN gateway to support telephone participants, you could set up Alice's VMR with aliases of meet.alice.jones and an appropriate E.164 number.
  • If you do not have or do not wish to use a call control system to transform aliases, you could set up Alice's VMR with aliases of meet.alice.jones and meet.alice.jones@example.com to support internal and external dialing, and dialing from both SIP and H.323 endpoints.