Course12:Advanced - Mobility

From innovaphone-wiki

Jump to: navigation, search

This book describes the building blocks for innovaphone's mobility solution.



Mobility refers to a set of features new to V9 that allow for the integration of terminals which do not register with a PBX (as VoIP-phones do), such as mobile phones for example. The idea is to integrate such terminals as if they were local PBX extensions.

The mobility function is made up of 3 independent building blocks
  • Forking. Allows to send calls to an external number instead of to a registered endpoint
  • Mobility object. A new PBX object that can act like a PBX user on behalf of an external caller
  • DTMF-Feature object. An object that provides dial-able numbers which invoke certain features when called
The fish-help.png DTMF Features object is not new to V10 but has been enhanced to provide the features required in a mobility scenario.

With mobility, there are screenshot.png 3 main calling scenarios.

Mobile Device calling

The mobile device places a call. From a user point of view, the call is to a certain user selected destination. From a technical point of view, the mobile needs to call the mobility object. The mobility object will then place the call to the final destination on behalf of the mobility enabled user object. From the PBX point of view, this looks much like a call from an endpoint registered to the mobility enabled user object to the final destination.

Mobile Device called

A call to the mobility enabled user object arrives. The call is signalled to all registered endpoints (as before). Additionally, calls are sent to all defined forking destinations for this user. From the PBX point of view, all these calls look the same, that is, it looks as if there is one call to the mobility enabled user object which is signalled to multiple registered endpoints. It does not look like calls from the mobility enabled user object to the forking destinations.

Mobile Device invoking Features

The mobile device invokes a feature (e.g. set a call forward). From a technical point of view, the mobile needs to call the mobility object. The mobility object will then forward the call to the DTMF features object which will invoke the feature on behalf of the mobility enabled user object.

Restriction on Numbers

As we can see in the overview, mobility devices need to call both the Mobility object and the DTMF object. However, most PSTN networks do not support calling numbers that contain non-digits.

Therefore, the mobility object's number and all feature codes need to be digit-only numbers, not containing # or *.

The Mobility Object

The mobility object has a number of tasks.

A closer look at the screenshot.png mobile device calling scenario may help to understand this better.

Let us assume, there is a mobile enabled user with extension 23. Her mobile device has the PSTN number 0151876. The PBX's PSTN trunk number is 0703173009. The mobility object serving the user has extension 69 and the name Mobility. The mobile device likes to place a call to extension 44. There is a trunk with trunk prefix 0.

Mobile Device Identification

When the mobile device places a call on behalf of the mobility enabled user object to the desired destination (44), technically it needs to call the mobility object (that is, 070317300969) first. It is the mobility object's task then to identify the user object the mobile is associated with. This is done by looking at the calling line id (CLI) received from the mobile device. For this to work, the mobility enabled user object needs to specify not only the forking destination (that is, the mobile devices PSTN phone number), but screenshot.png also the mobility object that will act on behalf of it. Please note that in our example, the forking destination is 00151876, not 0151876 as from the PBX's point of view, the trunk access code 0 must be prefixed.

The fish-help.png mobility object itself has no list of forking destinations in its screenshot.png configuration.

When the mobility object identifies the associated mobility enabled user object, it will connect the call and is ready to receive the final destination number (44 in our case) via DTMF. Otherwise it will simply disconnect the call.

Please note that the the mobile device must always call the mobility object first instead of the real destination number. If not, the call would not be recognized as a mobile device's call and would be treated just like any incoming call from external!

Two Stage Dialling

Once the mobile device is connected to the mobility object, the 2-stage dialling phase is started. In this phase, the mobility object will listen to incoming DTMF tones and collect digits to compose the final destination number. It will place a call on behalf of the mobility enabled user object and send all digits received into this call to dial the final destination. From a PBX point of view, this call behaves just like any call from an endpoint registered with the user. For example, the same fish-help.png filters apply.

Until v9 the Mobility object discards any extra digits in the CDPN. So if for example the object has number 69 and you call 6922, then 22 is discarded and two-stage dialling state is entered. You must dial 2 2 as DTMF digits after the secondary dial tone.

Note: Starting with v10 a feature was implemented regarding the 2 Stage Dialling. It now supports dial through, so when calling the Mobility object from the mobile phone, additional dialled digits are used to call the destination. This is an alternative to using DTMF tones for dialling the final destination number. How many digits may be dialled depends on what the network of the mobile phone supports.

R-Key features

When the call finally is established, the mobility object will provide common fish-help.png R-key functions such as hold and retrieve.

These functions are implemented in the PBX, not in the mobile device. In fact, if the mobile device implements similar functions (as e.g. cellular phones do), they should not be used at all. For example, when the mobile device creates a consultation call, there is in fact still only a single call in the mobile. The second consultation call is created in the mobility object and all logical calls are multiplexed on the one physical call to the mobile device.

The DTMF-Features Object

The fish-help.png DTMF Features object has been enhanced to support additional features such as fish-help.png enable/disable mobility. However, these features are disabled by default. You need to enable them in the screenshot.png DTMF object configuration and define proper feature codes.

The screenshot.png mobile device invoking feature scenario is not really different from the mobile device calling scenario. The final call destination in this scenario is the DTMF features object which then executes the desired feature (Please note that the extension 68 is merely an example as the DTMF features object actually has one number per feature, not one for all features).

However, for convenience, the DTMF feature object allows to be screenshot.png called directly by the mobile. The DTMF feature object will do the identification of the calling number as a mobile device (that is, searching a forking destination with mobility enabled) like the Mobility object itself would do. This way, it makes sure that the feature (e.g. setting a CFU) is invoked on the correct user object.

Some of the DTMF features are related to a current call (e.g. fish-help.png Call Park). For these features, the call invoking the feature must be a consultation call (that is, it must be created in parallel to the affected call).

Invoking features is done by a call to the DTMF feature object. This normally would be charged by your mobile operator. However, the DTMF feature object will not connect an incoming call when all required information (that is, the complete feature code) is already present in the call setup. This means that the DTMF object will see the call, invoke the feature and then cancel the call. This in turn implies that you will not be charged for the call. However, when calling it looks as if the call failed, which it actually did not!

This of course is subject to the number of digits the mobile and ISDN carrier allows to send in a call setup message. Because of that, DTMF features codes used for mobility should be as short as possible (and must not contain * or #). In most cases, you will for that reason want to create a DTMF object especially for mobility and change the default feature code settings.

The DTMF features object does not support two-stage dialling. When a feature code is called, then the feature code sequence may be variable in length as it may include parameters (e.g. the forward destination when setting a call forward). As the maximum length of a called number in a real network is limited, the complete feature code may be too long. For codes like this, you have to call through the Mobility object. This allows you to connect and then provide the remainder of the feature code per DTMF. If for example the trunk has number 0703173009, the mobility object the number 69, the Set CFU feature code the number 6822$# and the CFU shall be set to 1234, then you need to call 070317300969, from the mobile, wait for the two-stage dial tone, then dial 68221234# per DTMF.

Please note that the maximum reliable number of digits in a phone number for international calls is only 12 digits (this limit has been recommended thus by the ITU). For example
is OK, but
004970317300969 is not! If your mobile devices need to use mobility function through international calls, you must make sure that your mobility object is reachable within 12 digits. Please note that this limitation does not apply to external callers who call mobility enabled extensions.

For national calls, the maximum differs country by country. In Germany for example, up to 20 digits are fine, so there is plenty of room for feature codes.

The Forking Mechanism

The screenshot.png mobile device called scenario is substantially different from the other two.

As you can see, the mobility object is not called at all. When the call is received at the mobility enabled user object, it is sent to all registered endpoints as usual and in addition it is sent to the defined screenshot.png forking destination (after a possible delay, if configured). To provide all R-Key features to the called mobile device, the call is routed through the mobility object.

Please note that for this to work, no registered endpoint is required.
Starting with v10, forking destinations can be made dependant on dynamic conditions (e.g. the time of day). This is done by selecting a condition object (a.k.a. as fish-help.png boolean object) for the Bool property of the forking destination.

The forking destination is called only if the condition described in the boolean object is met (or is not met, if the Not check mark is ticked too).

Problems with forking destinations which erroneously take calls

When a call is sent to local registrations and forking destinations defined for the mobility enabled user and one of the called parties answers the call, all other calls are closed down obviously.

This creates problems with forking destinations which take calls although the recipient does not pick up the calls. This is often the case for mobile phones where incoming calls are routed to the users mailbox if the mobile is turned off or the user is busy. Mobile voice boxes should be disabled thus when the mobile is used for mobility (the PBX voice mail should be used instead).

However, even turning off the voice mail does not really help. Many mobile operators then take the call and play an announcement asking if the recipient shall be informed about the call (usually via short messaging system SMS). It is important thus to disable the mobility function using the fish-help.png enable/disable mobility feature code or the Disable property in fish-help.png PBX/Objects/Edit Forks when the mobile is not reachable.

Forking without Mobility

When a forking destination is configured at a user object but no mobility object is specified, a call to the user object will still be sent to the configured forking destination. As a result, forking does work without any existing mobility object and thus does not require a mobility license either.

However, in this case no mobility features are available to the called party. Also, from a PBX point of view, the call looks subtly different: it looks as if the caller would call the forking destination directly, much like it would look if a fish-help.png Number Map object would be called (except that with a number map object you cannot call multiple targets like you can do with multiple forking destinations).

Mobility in a distributed PBX

As the fish-help.png mobility object acts on behalf of the served user (that is, the user which has this object defined as his mobility object), it should be clear that the mobility object serving a user must reside on the same PBX where the served user is registered with. If not, call instances for the served user would be created on the wrong PBX.

As a result, there must be a mobility object on each PBX where a mobility enabled user is registered (that is, has the PBX set as PBX property in its fish-help.png configuration).

The same is true for the DTMF feature object used by a mobility endpoint, which also needs to be in the same PBX where the user belonging to the endpoint is registered with.

There are a few different ways to achieve this.

Distinct Objects per PBX

The most straight forward way is to create separate Mobility and DTMF objects per PBX. This has the advantage that you have full control over where such an object is available and which configuration properties are used for each. Then again, there are some drawbacks. When maintaining the PBX, you need to make sure you always follow up with creating appropriate objects for new PBXs. Also, when changing object properties, you must make sure all your changes are done on all the objects consistently. Also, with a flat numbering plan, all objects need to have different numbers.

Identical Copy on each PBX

This method takes advantage of the PBX's ability to fish-help.png replicate identical objects between PBXs.

There are again several fish-help.png ways to do this. However, we recommend to create the object and set both PBX and Node empty. This will replicate the object to all PBXs (as the PBX is empty) and will create an object that is in the PBX node on each PBX (as the Node is empty).

Each object can then be called uniformly from any node using the PBXs prefix followed by the objects Number.

There is one thing to take care of though: the PBX prefix needs to be a digit-only number, not a number containing # or *. This is because the mobility object needs to be called from the mobile device and most devices and PSTN networks do not support calling numbers that contain non-digits!

Also, you could be tempted to set the Local flag on the mobility and/or DTMF object. However, this creates problems currently when combined with empty PBX/Node properties.

Mobility Features

During a call from or to the mobile device, virtually all PBX features can be used by the mobile device. However, all features must be invoked using DTMF sequences. As such, user experience is much like the user experience when an analogue phone is used a as a PBX extensions.

The R-Key however is simulated by a DTMF sequence too, as configured in fish-help.png PBX/Objects/Mobility, ** by default.

The features available is a combination of the fish-help.png R-Key features and the fish-help.png features provided by the DTMF feature object.

Even the fish-help.png Directory Search object can be used by the mobile phone. However, as the mobile connection does not support search feedback on the display, this object is of limited use.

The Mobility Client

Using mobility features from a standard mobile phone is possible but rather disgusting. This is because
  • all features, including the R-key, are invoked through DTMF sequences. These tend to be difficult to use and hard to remember (although you can simplify the feature codes by fish-help.png configuring the DTMF feature object used for mobility)
  • Any outgoing call must be initiated using two-stage-dialling. While the user could configure a speed dial on the mobile phone to call the mobility object, the real destination number then must be dialled manually by the user. This also implies that the standard mobile phone-book cannot be used

This is why users usually ask for a mobile client that simplifies access of the mobility functions. This request can be solved using a 3rd Party Product, the fish-help.png Opticaller Client.

Since v9 it is possible to perform a fish-help.png CallBack or fish-help.png Callthrough using fish-help.png HTTP requests . The mobile phone would use his data connection to send a HTTP request to the PBX. This additional features can be used easily from the aforementioned Opticaller Client reducing the call establishing time compared to the two-stage-dialling DTMF Method.

Mobility and the Trunk Line

The whole idea with mobility is that any external PSTN number used as an extension is hidden from external callers. That is, these numbers are transparent and thus not known to external (or even internal) callers.

The way this is achieved is that any call goes to the internal extension that is assigned to the mobility enabled user. The PBX then will create one or more calls to the registered endpoints and/or the forking destinations. These calls will be sent with the original callers CGPN so that it is seen on the receiving phone.

However, many trunk lines (both SIP and ISDN) do not allow calls originating from the trunk line to carry a CGPN which does not belong to this line. In this case, they remove the CGPN and replace it with the lowest subscriber number assigned to the trunk (usually the trunks subscriber number plus 0). To the external mobility device such calls will look like they were originated from the companies switchboard (-0).

This problem is quite similar to the scenario where an extension has a permanent call forward (CFU) to an external PSTN number (e.g. the users mobile phone). However, in that case, enabling fish-help.png partial rerouting helps. With mobility, fish-help.png Clip no Screening needs to be enabled. Clip no Screening usually is a service offered by your ISDN carrier and is probably charged for.

screenshot.png Clip no Screening call flow

For CLNS to work, some special configuration is required in the routing part of your ISDN gateway. This is because when the call from the PSTN phone comes in to the PBX, a 0 is prefixed to the CGPN (to be more precise, the Number of the Trunk object is prefixed). However, when it is sent out to the trunk (because it is forwarded to the mobile phone), this extra 0 will not be removed (as CGPNs are never modified by the Trunk object for outgoing calls). So this extra 0 must be removed by special logic configured in fish-help.png Gateway/Routes.

This can be added to your configuration as described in the fish-help.png CLNS wiki article. However, if you use the wizard to do the initial device configuration, then the required logic will be inserted automatically.

The The PSTN Simulation can be configured to support CLNS.

Mobility and GSM Gateways

A frequent misconception is that mobile integration through mobility requires a GSM gateway. The GSM gateway would be integrated then as an screenshot.png alternate trunk line for mobile phones.

As could be seen in the scenario discussed so far, no GSM gateway is required at all. Even worse, mobile device integration is impossible or limited if a GSM gateway is used. This is due to the fact that GSM cannot support meaningful CLI for calls to the mobile, let alone CLIP no screening. Not only external calling numbers are not presented to the called mobile. Even straight calls from internal extension do not carry a meaningful CLI. Some GSM gateway vendors try to cope with these problems. However, solutions are only partial.

If the goal is to save on mobile call costs, GSM gateways may be a good solution. If mobile integration is required, they probably are not.

Mobility and Waiting Queue Operators

Starting with V10, calls from a waiting queue to an operator are forked. Queue operators thus can take waiting queue calls with their mobile devices.


A user object requires a Port license if there is at least one registration on it. A user using a mobility object (that is, a forking destination and a mobility object is defined) requires a Mobility license per destination. A forking destination with no mobility object defined requires no Mobility license.

So if you create a user object with a VoIP terminal registration and a forking destination with mobility, then you will need 1 Port license and 1 Mobility license. If on the user object there are no registrations but a forking destination with mobility enabled, then it will need 1 Mobility license but no Port license. If there are no registrations and a forking destination without mobility, then no license is required.
Personal tools