Audiocodes + Lync 2013 + provider that does not support History-info
While working on the Lync 2013 implementation project, I ran into a problem related to Call Forwarding and Simultaneous Ring. The test group complained that call forwarding did not work.
Troubleshooting revealed that this problem exists in certain scenarios. The problem is that the provider does not route outgoing calls where the calling number is not included in the pool of numbers provided to the client.
A detailed description and solution to the problem is under the cut.
Scheme of docking Lync infrastructure with telephony:
The diagram shows :
The following diagram shows the possible call forwarding scenarios.
Legend :
In scenario # 3, the provider “cuts” the outgoing call from the organization, since the calling number “E1” is not registered with the organization. If it’s good, the provider should work out the call on the appropriate route and make an entry in the billing system according to the History-info field. But in our case, the provider does not accept the HISTORY-INFO field, the work of the provider's billing system is built only on the FROM, TO attributes.
The following SIP Invite request comes from Lync Mediation to Audiocodes:
Solution Options :
The first option was not even tried.
The second and third options give more minuses than pluses. Script # 3 is fixed, but useful functionality is lost in scripts # 1, 2, 4 - all forwarded calls come from the number where call forwarding is activated.
It was decided to use the third option, finalizing it.
It is necessary, using the Message Manipulations Rule, to replace the value of the FROM field with sip: “E1” with sip “L1” for messages where “E1” and “E2” are external numbers.
For other scenarios, this rule should not be applied, as this will lead to loss of functionality. The subscriber receiving the redirected call will not see the actual caller-id of the caller.
Activation table of the substitution rule calling number :
Explanation of the table :
Configuration :
Rules table :
Rule number 1 checks if there is a HISTORY-INFO header, forms a group that matches the extension number template, writes this group to var.call.src.0. This variable will be used in the 3rd rule to replace the calling number in the header header.from.url.user.
Rule # 2 checks the TO header for an external number. The regex function “Negative lookahead” is used, which excludes local numbers by the prefix 717212. In case of a positive result, the variable var.global.0 is written. This variable has no role whatsoever.
Rule 3 checks the FROM header for an external number. The regex “Negative lookahead” function is used, which excludes local numbers by the prefix 717212. In case of a positive result, the variable var.call.src.0, recorded in step 1, is used to replace the called number in the header header.from.url.user.
In scenario # 3, the calling number is changed to the number of the initiator of the forwarding.
In other scenarios, the calling number does not change.
Troubleshooting revealed that this problem exists in certain scenarios. The problem is that the provider does not route outgoing calls where the calling number is not included in the pool of numbers provided to the client.
A detailed description and solution to the problem is under the cut.
Description of the problem
Scheme of docking Lync infrastructure with telephony:
The diagram shows :
- PBX Nortel CS1000;
- Audiocodes Mediation 1000, v 6.60;
- Lync 2013 with the combined roles of Front End, Mediation.
The following diagram shows the possible call forwarding scenarios.
Legend :
- N - PBX Nortel;
- A - Audiocodes;
- N1, N2 - Nortel PBX subscribers;
- L1 - Lync subscriber (Lync server is intentionally not shown to simplify the scheme);
- P - Telephony Provider;
- E1, E2 - External subscribers;
- The red frame is the subscriber to whom calls from the Lync subscriber are forwarded.
In scenario # 3, the provider “cuts” the outgoing call from the organization, since the calling number “E1” is not registered with the organization. If it’s good, the provider should work out the call on the appropriate route and make an entry in the billing system according to the History-info field. But in our case, the provider does not accept the HISTORY-INFO field, the work of the provider's billing system is built only on the FROM, TO attributes.
The following SIP Invite request comes from Lync Mediation to Audiocodes:
FROM: ;epid=7B11BD1265;tag=8c9e1f2146
TO: CSEQ: 329 INVITE
HISTORY-INFO: ;index=1;ms-retarget-reason=forwarding,;index=1.1
Formulation of the problem
Solution Options :
- Recycle provider billing system;
- Create a route with a special prefix, activate the “Hide caller ID” parameter on it and set the “Alternate caller ID”. Encourage users to enter a forwarding number with a prefix assigned:
- Use the SIP Message Manipulation Rule function as described here. (A similar solution was proposed by vendor support).
The first option was not even tried.
The second and third options give more minuses than pluses. Script # 3 is fixed, but useful functionality is lost in scripts # 1, 2, 4 - all forwarded calls come from the number where call forwarding is activated.
It was decided to use the third option, finalizing it.
It is necessary, using the Message Manipulations Rule, to replace the value of the FROM field with sip: “E1” with sip “L1” for messages where “E1” and “E2” are external numbers.
For other scenarios, this rule should not be applied, as this will lead to loss of functionality. The subscriber receiving the redirected call will not see the actual caller-id of the caller.
Activation table of the substitution rule calling number :
| # | FROM | Forward TO (History-info) | IsRuleNeedToBeApplied |
|---|---|---|---|
| 1 | internal | interna | False |
| 2 | external | internal | False |
| 3 | external | external | TRUE |
| 4 | internal | external | False |
Explanation of the table :
- A replacement rule should only be activated if the calling number and the forwarding number are external.
- Internal eq + 7717212XXXX, numbers registered with the organization.
- External not eq + 7717212XXXX, names not registered with the organization.
- #1. The rule does not need to be applied, since routing is carried out internally. The provider filter is not enabled.
- # 2 The rule does not need to be applied, since CallingNumber (FROM) is registered with the organization. The provider filter is enabled but does not block the call.
- # 3 The rule does not need to be applied, since routing is carried out internally. The provider filter is not enabled.
- #4. The rule must be applied. The provider filter is enabled, the call will be blocked if you do not substitute CallingNumber (FROM).
Decision
Configuration :
- Open the INI parameters page at xxxx / AdminPage . SetID SetID, for this in the Parameter Name field, enter GWINBOUNDMANIPULATIONSET, in the Enter Value field the corresponding SetID number.
- Create the rules described in the following table at VOIP> SIP Defenitions> Message Manipulations.
Rules table :
| Indx | ID | Msgtype | Condition | Actubj | ActType | Actvalue | Rowole |
|---|---|---|---|---|---|---|---|
| 1 | 1 | invite | header.history-info regex (sip: \ + 7 (717212 ....) @) | var.call.src.0 | modify | $ 2 | 0 |
| 2 | 1 | invite | header.to regex (sip :( ?! 717212) (. *) @) | var.global.0 | modify | '1' | 0 |
| 3 | 1 | invite | header.from regex (sip :( ?! 717212) (. *) @) | header.from.url.user | modify | var.call.src.0 | 0 |
Rule number 1 checks if there is a HISTORY-INFO header, forms a group that matches the extension number template, writes this group to var.call.src.0. This variable will be used in the 3rd rule to replace the calling number in the header header.from.url.user.
Rule # 2 checks the TO header for an external number. The regex function “Negative lookahead” is used, which excludes local numbers by the prefix 717212. In case of a positive result, the variable var.global.0 is written. This variable has no role whatsoever.
Rule 3 checks the FROM header for an external number. The regex “Negative lookahead” function is used, which excludes local numbers by the prefix 717212. In case of a positive result, the variable var.call.src.0, recorded in step 1, is used to replace the called number in the header header.from.url.user.
Result
In scenario # 3, the calling number is changed to the number of the initiator of the forwarding.
In other scenarios, the calling number does not change.
Appendix 1. Configuration Listing
GWINBOUNDMANIPULATIONSET = 1
[ MessageManipulations ]
FORMAT MessageManipulations_Index = MessageManipulations_ManSetID, MessageManipulations_MessageType, MessageManipulations_Condition, MessageManipulations_ActionSubject, MessageManipulations_ActionType, MessageManipulations_ActionValue, MessageManipulations_RowRole;
MessageManipulations 1 = 1, "invite", "header.history-info regex (sip:\+7(717212....)@)", "var.call.src.0", 2, "$2", 0;
MessageManipulations 2 = 1, "invite", "header.to regex (sip:(?!717212)(.*)@)", "var.global.0", 2, "'1'", 0;
MessageManipulations 3 = 1, "invite", "header.from regex (sip:(?!717212)(.*)@)", "header.from.url.user", 2, "var.call.src.0", 0;
[ \MessageManipulations ]