Solved Problems with forwarding rules

[slapster]

• 3CX Version, 18.0 (Build 1871)
• Server OS, Debian 10
• Is the 3CX Server Hosted and where? With 3CX
• IP Phone Make/Model/Firmware NA
• Provisioning Method: Local / VPN / STUN / SBC NA
• Trunk Provider or Gateway Make/Model Telnyx
• Has the Firewall Checker passed: YES / NO
• Are custom Phone Templates being used: YES / NO

In Forwarding Rules I have been using the mobile forwarding field to forward to a non-mobile external number, which has given me a certain flexibility in routing behaviour. This works fine most of the time, but it was reported to us that it did not work for calls from Ireland. I have been able to reproduce this by getting someone in Ireland to call in:

Irish caller calls our main line menu successfully on +4420MAINMENU
Selects menu option 1 for reception, with "if phone is unregistered, forward calls to mobile": (number is not mobile, but another VOIP line with another provider +4420VIRTUA RECEP)
Line goes dead. This would normally divert fine to that number.
Also, Irish caller dials +4420RECEPTION which has Inbound DID rule forwarding to +4420VIRTUALRECEP and line goes dead. This would normally divert fine to that number.
This issue occurs whether mobile number is formed as +4420VIRTUALRECEP or 020VIRTUALRECEP.
Irish caller then dials +4420VIRTUALRECEP directly, and is connected.

Log says:
03/08/2021 18:35:31 - L:35.3[Extn:151] got Terminated Recv 486/INVITE from 127.0.0.1:5483 tid=f6822cXXXXXXX4 Call-ID=5QlVhrR_bHngXXXXXX..:
SIP/2.0 486 Busy Here
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-XXXXXX-1---f6822c7XXXXXX;rport=5060
To: <sip:[email protected]>;tag=11c46076
From: "020 MAIN MENU Main:353IRISHCALLER"<sip:[email protected]:5060;nf=e>;tag=10fxdc0d
Call-ID: 5QlVhrR_bHngsecwrEpcQ..
CSeq: 1 INVITE
User-Agent: 3CX Dialer for Ext.151
Content-Length: 0

I then tried to play around with forwarding rules in the 3CX Dash, but found when trying to change from "Forward to Mobile" to "Forward to Number", any new settings did not save, which appears to be a separate problem.

Any help with this issue would be greatly appreciated as our friendly customers in Ireland are having their patience tested. I do not know if this is also happening from other countries, as I have only tested Ireland.

 

[ChrisC_3CX]

I then tried to play around with forwarding rules in the 3CX Dash, but found when trying to change from "Forward to Mobile" to "Forward to Number", any new settings did not save, which appears to be a separate problem.

This might happen if the number you are specifying for the "forward to Number" forwarding rule is actually set as that extension's mobile number in the "General" tab. If this is the case, then this behavior is expected.

Regarding the issue, since this is happening only for a specific caller, it leads me to believe that it may have to do with what your Provider allows you to show outward as your Caller ID.

In Dashboard got to "Activity Log >> Settings " and enable verbose mode and apply. Reproduce the issue again and check the Activity Log one more time to hopefully determine if the SIP Provider is responding with a message that may shed some light on the matter.

 

[slapster]

since this is happening only for a specific caller, it leads me to believe that it may have to do with what your Provider allows you to show outward as your Caller ID.

In Dashboard got to "Activity Log >> Settings " and enable verbose mode and apply. Reproduce the issue again and check the Activity Log one more time to hopefully determine if the SIP Provider is responding with a message that may shed some light on the matter.

Hi there,

This is actually happening for the original customer multiple times, but she did not assist in troubleshooting. Also I have had multiple other unspecific reports from other customers in other countries. This time, I got a colleague who was in Ireland to try it several different ways, and this is the result of that testing. So it is at least two numbers, from at least Ireland. My guess is that this would be the same for other countries.

I did have verbose logging on anyway to try to fix this, and I have now found a bit more of it which may help:

03/08/2021 18:35:31 - L:35.3[Extn:151]: destroying InvADS.ADS(37615)

03/08/2021 18:35:31 - L:35.1[Line:10001<<353IRISHCALLER] forwards call from Extn:151 to Out#:>>Rule{Main}>>020VIRTUALRECEP based on rule Fwd[Available/Busy]

03/08/2021 18:35:31 - L:35.1[Line:10001<<353IRISHCALLER] failed to reach Extn:151, reason Busy

03/08/2021 18:35:31 - Stop call record for leg L:35.3[Extn:151]

03/08/2021 18:35:31 - Removing leg L:35.3[Extn:151]

03/08/2021 18:35:31 - Leg L:35.3[Extn:151] is terminated: Cause: 486 Busy Here/INVITE from 127.0.0.1:5483

03/08/2021 18:35:31 - Call(C:35), Extn:151 on entry: DlgInfo(35-1239/Terminated / R)

03/08/2021 18:35:31 - Notify dialog-info: Extn:151: sip:[email protected]:5483;rinstance=021dbbafbc5b3773, Call(C:35)

03/08/2021 18:35:31 - L:35.3[Extn:151] got Terminated Recv 486/INVITE from 127.0.0.1:5483 tid=f6822c706bb2c724 Call-ID=5QlVhrR_bHngm8Ful4EpcQ..:

SIP/2.0 486 Busy Here

Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-524287-1---f6822c706bb2c724;rport=5060

To: <sip:[email protected]>;tag=11c46076

From: "020 MAINMENU Main:353IRISHCALLER <sip:[email protected]:5060;nf=e>;tag=10fab70d

Call-ID: 5QlVhrR_bHngm8Ful4EpcQ..

CSeq: 1 INVITE

User-Agent: 3CX Dialer for Ext.151

Content-Length: 0



03/08/2021 18:35:31 - Call(C:35), Extn:151 on exit: DlgInfo(35-1239/Terminated / R)

03/08/2021 18:35:31 - Call(C:35), Extn:151 on entry: DlgInfo(35-1239/Early / R)

03/08/2021 18:35:31 - Notify dialog-info: Extn:151: sip:[email protected]:5483;rinstance=021dbbafbc5b3773, Call(C:35)

03/08/2021 18:35:31 - L:35.3[Extn:151]: Terminating route Dev:sip:[email protected]:5483;rinstance=021dbbafbc5b3773

03/08/2021 18:35:31 - Call to T:Extn:151@[Dev:sip:[email protected]:5483;rinstance=021dbbafbc5b3773] from L:35.1[Line:10001<<353IRISHCALLER] failed, cause: Cause: 486 Busy Here/INVITE from 127.0.0.1:5483

03/08/2021 18:35:31 - L:35.3[Extn:151] got Failure: Failure Recv 486/INVITE from 127.0.0.1:5483 tid=f6822c706bb2c724 Call-ID=5QlVhrR_bHngm8Ful4EpcQ..:

SIP/2.0 486 Busy Here

Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-524287-1---f6822c706bb2c724;rport=5060

To: <sip:[email protected]>;tag=11c46076

From: "020 MAINMENU Main:353IRISHCALLER"<sip:[email protected]:5060;nf=e>;tag=10fab70d

Call-ID: 5QlVhrR_bHngm8Ful4EpcQ..

CSeq: 1 INVITE

User-Agent: 3CX Dialer for Ext.151

Content-Length: 0



03/08/2021 18:35:31 - Session 37617 has failed in leg L:35.3[Extn:151] ; Cause: 486 Busy Here/INVITE from 127.0.0.1:5483

03/08/2021 18:35:31 - L:36.1[Extn:151]: destroying InvADS.ADS(37618)

03/08/2021 18:35:31 - Stop call record for leg L:36.1[Extn:151]

03/08/2021 18:35:31 - Removing leg L:36.1[Extn:151]

03/08/2021 18:35:31 - Leg L:36.1[Extn:151] is terminated: Cause: BYE from PBX

03/08/2021 18:35:31 - Call(C:36), Extn:151 on exit: DlgInfo(36-1403/Terminated / I)

03/08/2021 18:35:31 - Call(C:36), Extn:151 on entry: DlgInfo(36-1403/Terminated / I)

03/08/2021 18:35:31 - Notify dialog-info: Extn:151: sip:[email protected]:5483;rinstance=021dbbafbc5b3773, Call(C:36)

03/08/2021 18:35:31 - L:36.1[Extn:151] Sending: OnSendResp Send 480/INVITE from 0.0.0.0:0 tid=65bdb119910df54b Call-ID=Z9qjG34zIlRjmAFoujwkmw..:

SIP/2.0 480 Temporarily Unavailable

Via: SIP/2.0/UDP 127.0.0.1:5483;branch=z9hG4bK-524287-1---65bdb119910df54b;rport=5483

To: <sip:[email protected]:5060;nofwd=1>;tag=9cd0db09

From: "020 MAINMENU Main:353IRISHCALLER"<sip:[email protected]:5060;dialer=1>;tag=7f0f7c26

Call-ID: Z9qjG34zIlRjmAFoujwkmw..

CSeq: 2 INVITE

Warning: 499 XXXX-RNJOI-SH8YT-FKHQY-TDZAU "Not available"

Content-Length: 0



03/08/2021 18:35:31 - Call(C:36), Extn:151 on exit: DlgInfo(36-1403/Terminated / I)

03/08/2021 18:35:31 - Call(C:36), Extn:151 on entry: DlgInfo(36-1403/Initial / I)

03/08/2021 18:35:31 - Notify dialog-info: Extn:151: sip:[email protected]:5483;rinstance=021dbbafbc5b3773, Call(C:36)

03/08/2021 18:35:31 - [CM503020]: Call(C:36): Normal call termination. Call originator: Extn:151. Reason: Not available

03/08/2021 18:35:31 - [CM503016]: Call(C:36): Attempt to reach <sip:[email protected]:5060> from Extn:151 has failed. Reason: Forbidden

03/08/2021 18:35:31 - Call to T:Line:10001>>020VIRTUALRECEP@[Dev:sip:[email protected];transport=TLS] from L:36.1[Extn:151] failed, cause: Cause: 403 Caller Origination Number is Invalid D35/INVITE from TELNYXIP:5061

 

[ChrisC_3CX]

03/08/2021 18:35:31 - Call to T:Line:10001>>020VIRTUALRECEP@[Dev:sip:[email protected];transport=TLS] from L:36.1[Extn:151] failed, cause: Cause: 403 Caller Origination Number is Invalid D35/INVITE from TELNYXIP:5061

From this here it seems that it is indeed the Caller ID number that is causing the issue. If I'm not mistaken, Telnyx requires that E.164 formatting is used.

Try the following configuration on the Telnyx SIP Trunk that is used for the Outbound call:

1. Go to SIP Trunks.
2. Edit the Telnyx SIP Trunk.
3. Click on Caller ID.
4. Add the following two Outbound rules in the exact order shown:

The first Rule simply checks for Caller ID numbers starting with a + sign and leaves them as is, and the second one checks for Caller ID numbers starting with 353 and adds a + sign to them.

Let me know if you can reproduce the same issue after implementing the above.

 

[slapster]

I'm very happy to say that this has worked! Thank you so much.

Does this need to be done manually for all country codes? Or is there a happy universal solution?

It seems funny that Telnyx won't accept the Caller ID formatting that comes from a call that it routed in to start with. Or could it be the receiving SIP provider on 020VIRTUALRECEP that is fussy?

 

[NickD_3CX]

Hi @slapster ,

I think we might be missing something here. Your call flow is:

1. Caller (+353) calls your Telnyx DID (+4420MAINMENU)
2. Caller is connected and presses '1' on IVR
3. Call is forward out through your Telnyx Provider to number (+4420VIRTUA RECEP)

Is this correct? Or maybe do you have 2 providers, Telnyx and some other one? If you have a second one, which one is it?

 

[slapster]

We actually have 2 call flows. One is as you describe. The other starts with +4420RECEPTION and bypasses the IVR with an inbound rule that forwards it to +4420VIRTUALRECEP. This is because "reception" only relates to part of the business and the main menu IVR allows access to the other side of the business.

But these 2 call flows have exactly the same problem.

We only use Telnyx. But +4420VIRTUALRECEP is managed by our outsourced virtual reception service, and they have told me it is through Voiceflex. I have no idea if that has any relevance. But calling it should just work like any publicly accessible 020 number.

 

[slapster]

I have discussed this issue with Telnyx. They said:

I can confirm the reason for these call failures is due to the missing '+' in the calls being sent. Unfortunately the only way to ensure we're sending the + is through the Caller ID Override function in your SIP connection settings but this won't be helpful to you as the number is being forwarded. This will need to be done directly through your 3cx device.

Especially since my number format for inbound calls at Telnyx is set to +E.164 this seems to suggest something is wrong within 3CX. I think most people would agree that putting in a reformatting rule into 3CX for every single country that could be calling us is very time consuming, prone to error and a bad workaround.

Is it feasible to prefix every number not starting with a 0 with a +? Or can this be logged as an incompatibility with Telnyx that needs dev work?

 

[ChrisC_3CX]

Especially since my number format for inbound calls at Telnyx is set to +E.164 this seems to suggest something is wrong within 3CX

I'm not entirely sure I agree, all the information you have provided until now shows that the Caller ID sent to 3CX is missing the + sign. If the Caller ID was already in the correct format required by Telnyx then it should've just worked without re-formatting being necessary, so, the question is, why is the Caller ID number not in E164 formatting when it reaches 3CX in the first place.

 

[slapster]

Thank you for that. I have a lot of sympathy as tracking down these issues does not seem to be fun or easy. And I feel somewhat redundant in the middle here because my knowledge is orders of magnitude below either you or this Telnyx guy. What I do know is that this is causing many calls to fail and that there is an incompatibility between Telnyx and 3CX.

I am adding reformatting rules in 3CX as countries arise, but this is the worst kind of workaround because it is clunky to implement and helps no one else. Whether the ultimate solution lies with Telnyx, 3CX or both, I am sure it would be quicker for everyone concerned if we could get you guys talking. Is that feasible?

 

[ChrisC_3CX]

I completely understand that this may seem difficult to grasp at times and it does indeed require some knowledge but that is why we are here to help as much as we can! That said, if you do need to go more in depth on this and require more specialized help I do recommend considering contacting on of our 3CX Partners who have the necessary experience and know-how.

Regarding the matter at hand, you might actually be able to use a more generalized rule to reformat the Caller ID and avoid having to identify why calls are being received in this format altogether. The ones I provided earlier would handle numbers already containing the + sign and Irish numbers. Provided that all numbers you receive already contain the country code and are only missing the + sign, what you could do is just use the following instead:




The first rule will match any numbers already containing the + sign and keep the number as is. The second rule will match the rest of the numbers and just add a + sign to them.

Note: You can scrap the previous line used specifically for Irish numbers.

Could you give it a go and let me know if this works for you?

 

[slapster]

Unfortunately this blocked outgoing domestic calls
I tried putting a rule in between the two: Source: 0(.*) Replace: +44(.*)
That allowed outgoing domestic but blocked domestic forwarding. I don't understand why.

 

[ChrisC_3CX]

I'll PM you for more information regarding this.

 

[ChrisC_3CX]

This issue has been resolved after changes affecting the formatting of the ANI were made in Telnyx's portal.