In selected environments it can happen that a redirection stored in the presence is no longer removed when switching back from this presence. Why this happens and how to fix it is described here.
The problem:
An XPhone user has stored a forwarding to the phone number 1234 in a presence, e.g. in 'Briefly absent'.
If the user switches to 'Briefly absent', the call forwarding is inserted. If he switches back to 'Present', however, the forwarding remains in place and is not automatically removed again.
The mechanism:
In order to understand the cause later, the mechanism for removing call forwarding must first be briefly explained.
In order for the call forwarding to be removed again automatically, the active call forwarding must correspond to the phone number configured in the call forwarding presence when the call forwarding presence is 'removed' (the phone number format does not matter as long as the phone numbers themselves are identical).
This means that if a forwarding is set to 1234 in the presence, it must still be active when the presence is switched back. If another call forwarding is detected, the mechanism for removing the call forwarding is no longer effective. This prevents manually set call forwarding to other numbers from being deleted when the presence is changed.
Cause:
If the user changes to this presence, the 1234 is "passed to telephony". There, this phone number is sent through the user's dialing parameter and the result is transmitted to the telephone system, e.g. via CSTA. The PBX confirms the redirection and sends back the active redirection number. So, if either the "sent" call forwarding or the "received" call forwarding confirmation are processed by dialing parameter special configuration, the mechanism will be defeated.
Scenario 1:
If DisplayToDialable rules are configured in this dialing parameter to match and process this 1234, a call forwarding to a number other than 1234 is effectively inserted. The mechanism recognizes that the phone numbers are no longer identical and leaves the redirection in place.
Solution:
The solution here is to configure a PhoneToDisplay rule that corresponds to the DisplayToDialable rule and converts the result of the DisplayToDialable rule back to the original redirection number.
Example:
Call number stored in the presence: 1234
Special configuration configured in the dialing parameter:
DisplayToDialable
Value 1: ^1234$
Value 2: 99$0
This rule must be supplemented:
PhoneToDisplay
Value 1: ^99(1234)$
Value 2: $1
Scenario 2:
If PhoneToDisplay rules are configured in this dialing parameter that match 1234 and handle this phone number, nothing is changed yet when the call forwarding is inserted, but the PBX confirmation event now passes through this PhoneToDisplay rule and thus the XPhone Server is notified of a different phone number as the active forwarding. As soon as the presence is changed, the phone numbers no longer match and the presence remains.
Solution:
As a solution, the PhoneToDisplay rule must be adjusted so that the redirection phone number is no longer matched and thus is not processed further.
Example:
Phone number stored in presence: 1234
Special configuration configured in the dialing parameter:
PhoneToDisplay
Value 1: ^[0-9]{4}$
Value 2: 99$0
This rule must be changed so that the 1234 no longer matches:
PhoneToDisplay
value 1: ^[2-9][0-9]{3}$
Value 2: 99$0
Comments
0 comments
Article is closed for comments.