<?xml version="1.0" encoding="utf-8"?>
<html>

Basic Operation

This service is also called Follow-me Routing. When users receive internal or external calls, the default user line rings first and if not answered the call is transfered to the user?s voicemail box, provided that the user has voicemail permission enabled (refer to user and group permissions).

The Call Forwarding feature allows users to influence the call sequence. One can insert any number of intermediary destinations for a call, internal or external, based on the user's needs. If the call is not picked up anywhere, the call is redirected to voicemail at the end of the sequence.

Parallel or serial forking can be used at any stage of the forwarding sequence. I.e. call destinations can start ringing at the same time or first after the previous call attempt expires. However, the call can only be picked up on the device that answers first. Parallel ringing of devices (ringing multiple devices at the same time) should be limited to 10 to 12 devices.

Configuring Call Sequences

A call forwarding sequence for a particular user can either be configured by the user or the administrator. This is consistent though as changes made by the administrator are visible to the user and vice-versa, and both the administrator and the user have permission to make changes at any time.

User Defined Call Sequences

The user can login to the Configuration Server user portal using either the User ID or an Alias and the assigned PIN. There is a new Call Forwarding screen in the user portal accessible by following the link on the left side once loged in. Navigate your browser to:

http://sipx.domain.com

Select Configuration and login to ConfigServer. Then select Call Forwarding.
<center>

</center>

The following options are available:

<center>

</center>

Administrator Defined Call Sequences

The administrator can access user call forwarding from the User Management screen by clicking on the link Call Forwarding. Both the administrator and the user will see the same information so that there is consistency between the two ways of accessing and changing call forwarding destinations and behavior.

Forwarding Calls to External (PSTN) Numbers

In order to be authorized to forward calls to external PSTN numbers, the individual user or the group to which the user belongs to has to have the permission "Forward Calls External" enabled. This option is Disabled by default. Refer to how to configure users and groups. Having this permission allows the user to enter an exception to normal authorization rules so that the external call forwarding will work correctly even for callers that would not otherwise be allowed to make an external call (such as a call that it coming in from the outside).

Formatting Forwarded Numbers

The sipXpbx dial plans can be set up to create many convenient ways of making the same call. For example, in North America it is common to configure a 7 digit dial plan that implicitly adds the 3 digit local area code before passing the call to a PSTN gateway (which usually needs the full 10 digit number to pass to the phone company). This kind of dial plan causes some confusion for the current call forwarding functionality.

In versions earlier than 3.10, the number that is entered in the forwarded number box must be in the final format to be passed to the gateway. So in the example above, the forwarded number should be the full 10 digit number rather than just the 7 digit local number, even though that would work if you dialed it directly.

In 3.10 and later, this rather difficult constraint is removed (if dialing the number works, then forwarding or transferring to it should work too).

See XPB-939 http__--track.sipfoundry.org-browse-XPB-939

Do Not Use Phone-based Forwarding To External Numbers

Some SIP phones can do forwarding on busy or no-answer to a number you program into the phone. If you do this, and the number you forward to requires some permission (as is the case with the default permissions in sipXpbx), then the call may fail. If you use the User Call Forwarding in the server to do the same forwarding operation, it will work.

The reason is that when a permission is required, it is the permission of the caller that is validated. So if an external caller calls your phone, and the phone redirects the call to an external number, the authorization check is made to see if the caller has permission to make external calls. Since the caller is not local, they cannot even authenticate, and have no permission to do anything, so the call fails.

Forwarding to an external number using the server works because the server configures a special exception for the normal permission checks that applies to the number you forwarded to.

Adjusting call timeouts to prevent voicemail pickups

As with any alias based forwarding it is possible that forwarded calls will get captured by voicemail of the extension to which it is forwarded. You can adjust the call expiration time so that before the call is picked up by the voicemail system assigned to that extension it is forwarded to the next extension in the forwarding sequence.

However if the extension called is busy or disconnected (i.e. a wireless phone) the call typically will automatically get forwarded to the voicemail system assigned to that extension. Because of that it is best not to use extensions that have voice mail capabilities as intermediary destinations for forwarded calls.

Note: Calls to internal extensions that are part of a forwarding calling sequence are not transferred to voicemail except if this is the last call in the sequence.

Implementation

Every entry in the list of calls corresponds to an entry in the alias databases. The q value is automatically generated to allow for parallel (in case of "at the same time" entry) or serial (in case of "if no response" entry) forking. All generated q values are from the range (1,0.8) and the step is calculated based on the number of entries in the list.

The delay (expiration) is implemented by adding the "expires" parameter to contact's sip URL:

<234234@sipfoundry.com?expires=40>;q=0.9

In versions earlier than 3.10, authorization exceptions are generated for external calls (strictly speaking since there is not a bullet proof way of determining which calls are external, authorization exceptions are generated for all entries on the list). The exceptions are generated only for users that have

ForwardCallExternal

permission enabled. Users that do not have this permission enabled can still configure forwarding to external number. However for those users a call forwarded to external number will be denied by the authorization proxy.

</html>