About aliases
Every Virtual Meeting Room (VMR), Virtual Auditorium and Virtual Reception 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, or Virtual Receptions; if so, it will direct the call to that service. If the alias does not belong to any of the above services, Pexip Infinity will then check through the Pexip Distributed Gateway's Gateway Routing Rules to see if the alias matches any rules specified there - for more information, see Service precedence.
When Pexip Infinity receives a call to a Virtual Meeting Room 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.
Virtual Receptions also have one or more aliases associated with them. In these cases, when the participant dials a Virtual Reception alias they will be 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.
In most cases, the alias received by Pexip Infinity will be 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 the sake of clarity, the following discussion assumes that the alias dialed by the endpoint user is the same as the alias received by Pexip Infinity.
Restrictions
An alias can include a domain but this is optional (see Domains). Aliases can be made up of:
- numbers
- letters
- dashes
- dots
- a combination of the above.
In certain circumstances an alias can also be in the form of an IP address - for more information see Using IP addresses as aliases.
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 Virtual Meeting Room with an alias ofMeet.Alice
- a user who dials
Meet.Alice
will match against a Virtual Meeting Room with an alias ofmeet.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 will automatically add the IP address of their proxy to the URI that is dialed by the user.
For example, a Virtual Meeting Room 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>
Using IP addresses as aliases
To support users who can only dial by IP address, you can give a Virtual Reception, Virtual Meeting Room or Virtual Auditorium 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, they will be routed directly to the Conferencing Node in question. Pexip Infinity will then check to see if the IP address matches any of the aliases configured on it; if so, the call will be routed to the associated Virtual Reception, Virtual Meeting Room or Virtual Auditorium.
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:
h323:
This is because the protocol used for the call does not matter to Pexip Infinity.
For example, a Virtual Meeting Room 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 Virtual Meeting Room.
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 Virtual Meeting Room.
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 Virtual Meeting Room 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 Virtual Meeting Room because the Virtual Meeting Room 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 Virtual Meeting Room 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 Virtual Meeting Room 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.