How do I configure the UM services for multi-site operation?

Table of contents

• Important notes
• Using multiple XCAPI controllers
  • The Challenge
  • Sending faxes
  • Voicemail / Auto Attendant / MWI
  • Voicemail-Player
  • Define controller for configuration / location groups
  • Web administration (announcements, auto attendant)
• Internal phone numbers in multi-site operations
  • Problem
  • Solution 1: Signaling in E.164 format (preferred method)
  • Solution 2: New parameter
• Location-based voicemail prefixes
  • Requirement
  • Proposed solution and realization
  • Technical background

 

Important Notes

All the parameters listed below are only implemented from V8.0.641 or 9.0.164. If necessary, you must update to one of these versions or higher.

 

The article deals with various topics in connection with UM in multi-site operation. It is not necessary to configure all three points (Use multiple XCAPI controllers / Internal numbers in multi-site operation / Site-specific voicemail prefixes).

 

Using multiple XCAPI controllers

Our XPhone Connect UM services can now specifically select a CAPI controller and are therefore much better suited for multi-site operation!

 

The Challenge

XPhone only knows one UM gateway, which is mapped by an XCAPI service. However, several locations with different dialing parameters are to be connected to this. In addition, in many cases the telephone systems of the locations are not networked.

This can be realized with an SBC between XCAPI and the PBXs. But this costs a) money and b) additional configuration work.

The approach to solving the problem “with on-board resources” is several XCAPI controllers.

For the incoming direction (i.e. incoming calls in the XPhone server: incoming faxes, auto attendant, voicemail) this is also (almost) no problem (except for a few small dialing parameter issues, which we can all get under control today): the choice of the right XCAPI controller is “hard-wired” by the external PBX system.

But in the other direction, the outgoing direction, this has not worked so far. The reason: when searching for a free channel, the UM services did not take into account which controller this channel was on.

So it could happen that an auto attendant was called on controller X, but then selected an outgoing channel on controller Y for the call transfer. This leads to problems if X = Hamburg and Y = Stuttgart.

We can now do the following:

Fax transmission: the appropriate controller is defined per location/configuration group via the fax template.
Voicemail/Auto Attendant/MWI: outgoing calls only exist here if one came in before. Now it is ensured that outgoing calls always go out on the same controller on which they came in. This is controlled via the new extended voicemail setting “UseCurrentControllerForCallTransfer = 1”.
Voicemail player: With the help of a registry entry, the VMP player can now send the appropriate XCAPI controller to the VMP service so that it is used.

Instead of more text, the illustrated details now follow.

 

Sending faxes

The XCAPI controller is selected in the fax template based on the numbering in the XCAPI configuration. For this purpose, the setting “Prefix for office for fax transmission” is reinterpreted: with three ### as prefix you determine the XCAPI controller (same counting method as in the XCAPI configuration).

Open the XPhone Connect administration interface and navigate to a location. There, go to Settings > Fax and enter ### and the controller number under Prefix for office for fax transmission.

Repeat this in the other locations, if necessary with different numbers depending on which controller is to be used.

TIP: The controller number is defined in the XCAPI, starting at 1 with the first controller created.

 

Example: Our customer has three different telephone systems and in turn three different XCAPI controllers.

Now he would like to specify in location 3 that faxes may only be sent via the 3rd controller. This would then look like this:

Voicemail / Auto Attendant / MWI

For voicemail, only the advanced setting “UseCurrentControllerForCallTransfer = 1” needs to be set.

Open the XPhone Connect administration interface and navigate to UM > Voicemail > General. Enter UseCurrentControllerForCallTransfer with the value 1 in the Advanced settings.

The following happens by setting this parameter:

The call comes in on the green path and goes out on the red path - on the same controller as on the outgoing path!

 

Voicemail-Player

To assign a controller to the voicemail player, you must create a corresponding entry in the user's registry.

Open the Windows Registry Editor and navigate to the path:

Computer\HKEY_CURRENT_USER\SOFTWARE\C4B\XPhone50\VoiceMailPlayer

Now enter a new character string:

The value for “Data” again corresponds to the number of the controller from the XCAPI.

 

 

Define controller for configuration / location groups (advanced setting "VMP CapiController")

There are two scenarios in which the controller was not specified by an incoming call:

• Listening to voicemail via the voicemail player on the client / Outlook
• Switching off the MWI lamp

To ensure that the “correct” controller is used for these scenarios, it must be defined accordingly in advance. This can be done with the following parameter:

Name: VMP.CapiController

Value: Corresponds to the number of the controller

To be set under: User administration > Location > Settings > Connect Client > Advanced settings

TIP: The controller number is defined in the XCAPI, starting at 1 with the first controller created.

Example: Our customer has three different telephone systems and in turn three different XCAPI controllers

Web administration (announcements, auto attendant)

Web administration also uses the voicemail service, e.g. to simulate auto attendants or to check announcements. Similar to the voicemail player, there is no incoming call that determines the XCAPI controller.

For this scenario, you can now decide which controller is to be used when entering the call number via which the announcement is to be played.

(1) Select playback of an announcement or simulation in the Auto Attandent

(2) Enter the destination number and specify the XCAPI controller separated by three plus signs (+++) (highlighted in yellow in the example).

(3) Play with the play button.

 

Internal phone numbers in multi-site operations

Problem

There are two locations with different dialing parameters. One of them is entered in the UM Gateway, the other has been added in the “NumberSeachFormats”.

Now an XPhone user from the 2nd location wants to check his voicemail. He calls the central VM number.

However, only his extension number is signaled for the caller number. The caller number is now automatically supplemented to E.164 using the UM dialing parameters → of course the wrong number comes out!

As a result, the call is canceled.

 

Solution 1: Signaling in E.164 format (preferred method)

The problem stems from the fact that the caller number is signaled as an extension. It must be converted to E.164 for further internal processing.

The simplest solution (from XPhone's point of view) would be for the system to signal E.164 here. Then there would be no doubt about the caller number and the caller would be identified.

If this is not possible for whatever reason, read solution 2.

 

Solution 2: New parameter

Basically, the XPhone server already has all the information it needs to correctly identify the caller number. Namely in - in the “NumberSearchFormats”, in which all phone numbers of the secondary locations are already entered

In order for the voicemail service to use the signaled, short phone number to populate the search formats (i.e. the “i” after the number), this new advanced setting must be set:

Navigieren Sie in der Administrationsoberfläche zu UM > Voicemail > Allgemein und fügen Sie einen neuen Parameter bei den erweiterten Einstellungen hinzu.

Name: UseUnresolvedCallerNumberForDatabaseSearch

Value: 1

This replaces the “i” in the NumberSearchFormats with the signaled (short) extension number. The correct user is now also found.

 

Location-based voicemail prefixes

Requirement

For example, a customer has connected 4 OpenScape4000 nodes to an XPhone server (CTI and XCC each have their own SIP trunks).

UM/XCAPI runs exclusively via the main system. Voicemail code is 899 in all nodes and the code is also correctly routed to the appropriate node and the calls can be assigned to the mailboxes.

The customer would now also like to use the voicemail prefix to be able to divert calls to any voicemail boxes.

 

Proposed solution and realization

New parameter “SubstituteVoicemailPrefixes”. This parameter can be used to assign the phone numbers to the prefixes.

This must be set in the administration interface under UM > Voicemail > General > Advanced settings

Create a new parameter with the name SubstituteVoicemailPrefixes.

The value is a Key=Value Collection, separated by a semicolon:

SubstituteVoicemailPrefixes = “p1=s1;p2=s2;...”

px = Voicemail prefix
sx = root number that is to be substituted

Example:

SubstituteVoicemailPrefixes = “11=+49123456789;22=+49987654321”

 

Technical background

The extension number is signaled with a unique prefix as the caller number. Example: Prefix=99, extension=1234, signaled number 991234.

The exchange number of the associated location is +4989890798. The number you are looking for would therefore be +4989890798-1234.

If you replace the 99 in 991234 with +4981416677, you would end up with exactly this number: +49814166771234.

For the conversion you need a lookup prefix → exchange number.

 

How does it work?

The voicemail prefixes from this collection are evaluated during number recognition in addition to the voicemail prefix configured in the admin interface of the voicemail service. The dialling parameters of the UM gateway apply to this one prefix as normal, so no special lookup is required.

If one of the prefixes from the collection is recognized, the substitution takes place before the user search is started in the XPhone server.