You are here: Administration > Infinity services > About aliases

About aliases

Every Virtual Meeting Room (VMR), Virtual Auditorium, Virtual Reception 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 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 will then check through the Call Routing Rules used by the Pexip Distributed Gateway 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.

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 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 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 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 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 Infinity Connect clients, dial the IP address alias, they will also be connected to the appropriate service (although the Conferencing Node they connect to will be 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:
  • 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 and Lync / Skype for Business 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 Virtual Meeting Room, Virtual Auditorium, Virtual Reception or Test Call Service. (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:
    • Service configuration > Virtual Meeting Rooms,
    • Service configuration > Virtual Auditoriums,
    • Service configuration > Virtual Receptions, or
    • Service configuration > Test Call Service.
  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.

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 will need 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.