Audiocodes + Lync 2013 + provider that does not support History-info
During the work on the Lync 2013 implementation project, I encountered a problem with call forwarding (simultaneous call) and simultaneous ringing. The test team complained that forwarding was not working.
Troubleshuting revealed that this problem exists in certain scenarios. The problem is due to the fact that the provider does not route outgoing calls, where the caller's number (calling number) is not included in the pool of numbers provided to the client.
Detailed description and solution of the problem - under the cut.
Lync docking 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 for the organization. For good, the provider must complete 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 based only on the FROM, TO attributes.
From Lync Mediation to Audiocodes comes the following SIP Invite request:
Solution options :
The first option did not even try.
The second and third options give more minuses than pluses. Scenario # 3 is fixed, but the useful functionality in scenarios # 1, 2, 4 is lost - all redirected calls come from the number on which redirection 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 from 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 forwarded call will not see the caller-id of the caller.
Activation table of the substitution rule calling number :
Explanation of the table :
Configuration :
Table of rules :
Rule # 1 checks if the HISTORY-INFO header is present, forms a group that matches the extension number, writes this group to the variable var.call.src.0. This variable will be used in the 3rd rule for substitution of the calling number in header header.from.url.user.
Rule 2 checks the TO header for the presence of 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 does not have any role.
Rule number 3 checks the FROM header for the presence of 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.call.src.0, recorded in step 1, is used to substitute the called number in header header from.url.user.
In scenario # 3, the calling number is replaced with the number of the initiator of the call forwarding.
In other scenarios, the calling number is not changed.
Troubleshuting revealed that this problem exists in certain scenarios. The problem is due to the fact that the provider does not route outgoing calls, where the caller's number (calling number) is not included in the pool of numbers provided to the client.
Detailed description and solution of the problem - under the cut.
Description of the problem
Lync docking infrastructure with telephony:
')
The diagram shows :
- PBX Nortel CS1000;
- Audiocodes Mediation 1000, v 6.60;
- Lync 2013 with combined roles Front End, Mediation.
The following diagram shows the possible call forwarding scenarios.
Legend :
- N - Nortel PBX;
- A - Audiocodes;
- N1, N2 - subscribers of Nortel PBX;
- L1 - Lync subscriber (Lync server does not intend to depict it to simplify the scheme);
- P - Telephony provider;
- E1, E2 - External subscribers;
- The red frame is the subscriber to which calls from the Lync subscriber are diverted.
In scenario # 3, the provider “cuts” the outgoing call from the organization, since the calling number "E1" is not registered for the organization. For good, the provider must complete 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 based only on the FROM, TO attributes.
From Lync Mediation to Audiocodes comes the following SIP Invite request:
FROM: <sip:"E1";phone-context=enterprise@domain.net;user=phone>;epid=7B11BD1265;tag=8c9e1f2146 TO: <sip"E2"@voice_gw.domain.net;user=phone>CSEQ: 329 INVITE HISTORY-INFO: <sip:"L1"@lyncmediation1.domain.net;user=phone>;index=1;ms-retarget-reason=forwarding,<sip:"E2"@lyncmediation1.domain.net;user=phone>;index=1.1 Formulation of the problem
Solution options :
- Recycle provider billing system;
- Create a route with a special prefix, activate the “Suppress caller ID” parameter on it and set the “Alternate caller ID”. Recommend users to enter the redirect number with the assigned prefix:
- Use the “SIP Message Manipulation Rule” feature, as described here. (a similar solution was proposed by the support of the vendor).
The first option did not even try.
The second and third options give more minuses than pluses. Scenario # 3 is fixed, but the useful functionality in scenarios # 1, 2, 4 is lost - all redirected calls come from the number on which redirection 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 from 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 forwarded call will not see the caller-id of the caller.
Activation table of the substitution rule calling number :
| # | FROM | Forward TO (History-info) | IsRuleNeedToBeApplied |
|---|---|---|---|
| one | internal | interna | FALSE |
| 2 | external | internal | FALSE |
| 3 | external | external | TRUE |
| four | internal | external | FALSE |
Explanation of the table :
- The replacement rule should be activated only in the case when the calling number and the forwarding number are external.
- Internal eq + 7717212XXXX, numbers registered for the organization.
- External not eq + 7717212XXXX, nomen not registered by organization.
- #one. The rule is not necessary to apply, since the routing is carried out within the organization. Provider filter is not involved.
- # 2. You do not need to apply the rule, since CallingNumber (FROM) is registered for the organization. The provider filter is enabled, but does not block the call.
- # 3. The rule is not necessary to apply, since the routing is carried out within the organization. Provider filter is not involved.
- #four. The rule is necessary to apply. The provider filter is enabled, the call will be blocked if you do not substitute CallingNumber (FROM).
Decision
Configuration :
- Open the INI Settings page at xxxx / AdminPage . Set 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.
Table of rules :
| Indx | ID | MsgType | Condition | ActSubj | ActType | Actvalue | RowRole |
|---|---|---|---|---|---|---|---|
| one | one | invite | header.history-info regex (sip: \ + 7 (717212 ....) @) | var.call.src.0 | modify | $ 2 | 0 |
| 2 | one | invite | header.to regex (sip :(? 717212) (. *) @) | var.global.0 | modify | 'one' | 0 |
| 3 | one | invite | header.from regex (sip :(? 717212) (. *) @) | header.from.url.user | modify | var.call.src.0 | 0 |
Rule # 1 checks if the HISTORY-INFO header is present, forms a group that matches the extension number, writes this group to the variable var.call.src.0. This variable will be used in the 3rd rule for substitution of the calling number in header header.from.url.user.
Rule 2 checks the TO header for the presence of 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 does not have any role.
Rule number 3 checks the FROM header for the presence of 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.call.src.0, recorded in step 1, is used to substitute the called number in header header from.url.user.
Result
In scenario # 3, the calling number is replaced with the number of the initiator of the call forwarding.
In other scenarios, the calling number is not changed.
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 ] Appendix 2. Useful Resources
Source: https://habr.com/ru/post/249711/
All Articles