Why doesn't Follow-Me work? – C4B Support

This article describes possible causes why the Follow-Me function might not work when using AnyDevice and how to fix them.

1) The call is not routed from the PBX to the XPhone Server.

This is quite easy to reproduce. Start Wireshark on the XPhone Connect Server and cut the network traffic of the Ethernet interface (not loopback adapters). In the display filter, filter on "sip".

You should be able to see the following after about a minute (provided there is no other SIP communication on the system):

Now recreate the error case. If you cannot find any further packets in Wireshark (look for "Request: INVITE" packets), the call has not yet reached the XPhone server from the PBX. In this case, please check the routing in the PBX.

2) XPhone Connect Server does not find the AnyDevice user

The most common cause of Follow-Me problems is that the PBX signals a phone number in the "Diversion" or "History" field that the XPhone Server does not know. XPhone Server looks at the "Diversion" or "History" field of the PBX's SIP Invite to find out the user for whom the call was originally intended.

If XPhone Server does not find the user based on the "Diversion" header, you will see the error 503 Service Unavailable in the Wireshark trace.

Officially, the XPhone Server can only recognize phone numbers in this field if they are delivered in one of these formats:

E.164 (+49...)
Internal (123)

If the phone number is signaled in a different format, XPhone Server may not be able to assign the phone number to an XPhone user and reject the call -> the call is aborted.

The preferred solution is now to configure the PBX to send the phone number in the "Diversion" or "History" field in one of these formats. If this is not possible, e.g. because the telephone system is not "flexible enough" in this respect, there is still the possibility of adapting the XccDiversionPattern.

The XccDiversionPattern is the "magnifying glass" that is placed over the "Diversion" or "History" field and recognizes the phone numbers from the field. This phone number detection can be extended by editing the value in the SIP Gateway's Advanced Settings.

In the following, two fictitious but realistic scenarios have been devised:

Scenario 1: The phone number is signaled in the wrong format

follow_me_invite_blurred_corrected_diversion0089

In this case, the call number is not signaled in Diversion in either E.164 or internal format. The result: The XPhone Server cannot assign the call number to a user and the call is aborted.

The solution now is to tell our magnifier to recognize the phone number in E.164 format. For this we edit the value XccDiversionPattern, which can be found in the "Advanced Settings" of the SIP gateway, as follows:

Default:

^[^<]*<(?:tel|sip):([+]?\d+)\D+.*$

Solution:

^[^<]*<(?:tel|sip):([+]?\d+)\D+.*$]||[^00([1-9][0-9]{3,})$||+49$1

The ]||[ is our separator here. The bracket [ must not be closed again!

The well-known AdaptCSTAAddress syntax is used.

In the solution we have now set the magnifier so that a 00 is recognized like a +49.

Normally the PBX does not change the way it signals the phone number in "Diversion" or "History", so other phone number formats normally do not need to be considered.

Scenario 2: The phone number is signaled with prefix/node number

follow_me_invite_blurred_corrected_diversion99

The phone number is now in the correct format, but there is a prefix in front of the phone number, which gives us the same problem of not being able to find the user. Again, we need to adjust our XccDiversionPattern, which can be found in the "Advanced Settings" of the SIP Gateway.

In this scenario, the fictitious customer has an internal number length of 3.

Default:

^[^<]*<(?:tel|sip):([+]?\d+)\D+.*$

Solution:

^[^<]*<(?:tel|sip):([+]?\d+)\D+.*$]||[^99([1-9][0-9]{2})$||$1

It can also happen that instead of a prefix a superfluous character is sent (e.g. +123). In this case, the same procedure as with the 99 can be used, only the 99 is replaced by a \+ in the solution.

Scenario 3: The call is routed to the wrong SIP trunk

Furthermore, it is possible that the XPhone Server is connected to the PBX via multiple SIP trunks. If the call is sent from the PBX to the incorrect SIP trunk, XPhone Server does not find the user on this trunk and rejects the call.

3) The PBX cannot handle the call from the XPhone Server to the AnyDevice device.

It may happen that the XPhone Server processes the incoming call correctly, but still no connection is established. In this case, the PBX usually rejects the call to the AnyDevice initiated by the XCC. Possible reasons are:

Format of the call numbers in the Invite to the AnyDevice
Codecs offered in the Invite to the AnyDevice
Missing configuration in the PBX to accept the call (e.g. routing).
The provider rejects the call because of the FROM header.

Solution to 1)

For a Follow-Me call, the XCC accepts the call from the PBX, and then calls the Follow-Me device. On the call to the Follow-Me device, the XCC takes the From and CLIP information from the incoming call, and sends it back to the PBX in the same way. Only the To information is changed (now the phone number of the AnyDevice device is displayed). The format of this To header can be edited via the value "Flags" in the dialing parameter of the SIP gateway.

If the other fields (From, CLIP) are in the wrong format, then they must be sent initially in the correct format from the PBX to the XPhone server.

Solution to 2)

For a Follow-Me call, the PBX not only signals the phone number information in the SIP-Invite, but also offers the codecs it supposedly understands. The XPhone server then selects the best codec from these and offers this codec itself in order to reach the AnyDevice. It may happen that the PBX then still cannot cope with the codec and rejects the call. The codecs used by the XCC can be set in the SIP gateway. Here, the codec that the PBX does not understand must be removed.

Solution to 3)

If the behavior could not be solved by 1) or 2), there is no further analysis/help available from XPhone Support. Now the PBX technician has to check at the PBX why the call is not answered.

Solution to 4)

With IP providers, it can happen that the provider rejects the call to the AnyDevice based on the From information in the SIP Invite because the phone number does not "belong" to the customer. As a solution, these two parameters can be set in the Advanced Settings of the SIP gateway:

XccLineNumberAsClipFirstLeg = True

XccLineNumberAsClipSecondLeg = True

4) Further notes

The central AnyDevice call forwarding number must not exceed the internal number length of the SIP gateway dialing parameter, or the internal number length must be adjusted to the AnyDevice call forwarding number length.
If the user was previously configured as an AnyDevice Only user, it must be ensured that no call forwarding is active in the AnyDevice Only "state". This redirection is no longer visible in the AnyDevice Twinning configuration.