Solved Call forwarding to external fails - "no route exists"

[john1902]

Hi all we are using 3CX at our office, and have done so for about 12-18 months now. Recently I discovered that call forwarding to external numbers is not working, when I conducted some testing I noticed in the call log it says "no route exists" as attached. Please could you assist?

Detailed info below:

Status:

• Inbound calls work OK.
• Outbound calls work OK.
• Call forwarding to an internal number works OK.
• Call forwarding to an external number fails. It used to work OK, only recently highlighted not working by a user.

SIP trunk is set up with Colt. Host and trunk number added in 3CX, outbound rules are set up. As I said outbound calls and inbound calls both work OK, it is just the call forwarding which has mysteriously stopped working.

Testing

• Ext 859: Status set to Away and forward to mobile (use call deflection 302) - call failed (short beep, long beep)
• Ext 859: Status set to Away and forward to mobile - call failed (short beep, long beep)
• Ext 859: Status set to Available - incoming call rings OK / call connects OK
• Ext 859: Status set to Away and forward to number +447*****3020 (EE) - call failed (short beep, long beep)
• Repeated above with another Ext 577 and another mobile on Vodafone, same result
• Ext 577: Status set to Away and forward to ext 859 - incoming call rings OK / call connects OK
• Ext 859: Using 3CX iOS app I am able to place external calls OK, tested to +447*****3020 (EE). This was to test outbound call rules / routing out over Colt trunk OK.

 

[ChrisC_3CX]

It might be that your Outbound rules have extension or extension group conditions on them and therefore rejecting any calls not originating from an extension. First thing I'd recommend is, as a test, create an Outbound Rule that has no restrictions other than prefix. Set the prefix field to something like +,0-9 so it matches all digits and the plus sign and then move the Outbound Rule to the very top of the list. Make absolutely sure that the Outbound rule has nothing set under "calls from extensions" or "calls from extension groups" or any other field for that matter. Try reproducing the issue again, but do make sure that 302 deflection is not selected as this will have the SIP Provider contact the destination number directly instead of having 3CX make the Outbound call.

Let us know what happens and also let us know what version of 3CX you are running.

 

[Alphabetic]

Call in and out will be 2 on your sip trunk.

how many channels have you got?

 

[john1902]

Hi Chris thanks for your help.

I have managed to check the outbound rules as suggested. I have deleted everything under "calls from extension groups", so I presume it matches on all, rather than just those groups now.

I have left the outbound prefix as 9 for now, our default was outbound prefix 9 with strip digits set to 1.

Now when I run a test with call deflection turned off, forwarding to mobile works OK as long as the mobile number is formatted 907388******, so that the outbound rule matches and allows the call.

I am just one of a couple of IT engineers, I am a bit confused and you may be able to help me further.

Q1: I'm pretty sure earlier we used to use 302 call deflection. Could this be the root cause of our issue, if the SIP provider (Colt) has made a change to disallow this function for whatever reason?

Q2: I tried making a second outbound rule for prefix "+" and strip digits set to 0, to attempt call forwarding to a mobile number +447388****** (formatted as typed) however this did not work. How would I configure it to enable forwarding to mobiles, where all numbers in the mobile field in 3CX are set as +447388*****, without having to reformat all of the numbers to 907388******. We would like to keep the prefix 9 for users to place outside calls.

 

[john1902]

Call in and out will be 2 on your sip trunk.

how many channels have you got?

Thanks for the tip. In 3CX we are licensed for 16 calls. I believe we have 16 channels. We do not have a large number of users, so currently there are not usually more than 4 concurrent calls.

 

[ChrisC_3CX]

@john1902

Q1: I'm pretty sure earlier we used to use 302 call deflection. Could this be the root cause of our issue, if the SIP provider (Colt) has made a change to disallow this function for whatever reason?

It seems that Colt does not support it based on the information available in our 3CX Supported Providers page: https://www.3cx.com/partners/sip-trunks/france/

Q2: I tried making a second outbound rule for prefix "+" and strip digits set to 0, to attempt call forwarding to a mobile number +447388****** (formatted as typed) however this did not work. How would I configure it to enable forwarding to mobiles, where all numbers in the mobile field in 3CX are set as +447388*****, without having to reformat all of the numbers to 907388******. We would like to keep the prefix 9 for users to place outside calls.

If the provider accepts a number format that includes a plus sign (e.g +44123456789) then what you did should've been enough. You could perhaps just test if such calls are accepted by manually dialing +44123456789 from an extension directly. If this format is not accepted and the call fails you could have your Outbound Rule match the + sign by having it in the prefix, then strip 3 so that +44 gets removed and then prepend 0 if required by the provider. With this configuration a number such as +44123456789 would be sent to the provider as 0123456789.

Hope this helps.

 

[john1902]

Hi Chris, thanks for your help. Yes I have checked with the provider, it seems as though 302 deflection was not officially supported.

All clear now.

One last thing.... I promise. When I make an outbound call, the outbound phone number is presented correctly, it uses our main trunk number, populated in the Caller ID field under the SIP trunk.

However when someone calls one of our DDI's and it forwards to an external number, e.g. forward to mobile, the phone number isn't presented as our main trunk number. It is presented as another landline number, unrelated to the original caller or the DDI that was dialled.

Attached are the outbound and inbound parameters. As mentioned, outbound ID works OK except when call forwarding.

 

[john1902]

I will clarify about the above that when a call is forwarded by 3CX I would like the call to be presented as either the original caller's number (preferred, but may not be allowed?) or our main trunk number, which is usually what is presented for outbound calls.

3CX is correctly presenting our number as the main trunk number when making outbound calls, but this is not the case when 3CX is forwarding an incoming call to an external destination.

 

[ChrisC_3CX]

When OriginatorCallerID is selected in the outbound parameters, and an external call reaches the 3CX PBX and is routed outward again, it should carry the original Caller ID of the initial caller. Specifically, it will populate the parameter with whatever the original SIP Invite had in it's From: User Part field as defined by your Inbound Parameters.

Is there any chance you are routing the call out through another SIP Trunk for those cases? A way to check if 3CX is sending the correct Caller ID would be to enable Verbose Logging under "Dashboard >> Activity Log >> Settings", reproduce the issue and then check the Activity Log in order to determine exactly what the 3CX PBX is sending.


Regarding if it's allowed or not, do note that according to the info for this provider, it should allow it since the "CLIP no screening functionality" is supported, but you could switch from using the OriginatorCallerID in your Outbound Rules to using the OutboundCallerID taken from the extension settings. This way the Caller ID sent out will be the one of your 3CX PBX.

 

[john1902]

When OriginatorCallerID is selected in the outbound parameters, and an external call reaches the 3CX PBX and is routed outward again, it should carry the original Caller ID of the initial caller. Specifically, it will populate the parameter with whatever the original SIP Invite had in it's From: User Part field as defined by your Inbound Parameters.

Is there any chance you are routing the call out through another SIP Trunk for those cases? A way to check if 3CX is sending the correct Caller ID would be to enable Verbose Logging under "Dashboard >> Activity Log >> Settings", reproduce the issue and then check the Activity Log in order to determine exactly what the 3CX PBX is sending.


Regarding if it's allowed or not, do note that according to the info for this provider, it should allow it since the "CLIP no screening functionality" is supported, but you could switch from using the OriginatorCallerID in your Outbound Rules to using the OutboundCallerID taken from the extension settings. This way the Caller ID sent out will be the one of your 3CX PBX.

Hi Chris, we just have the one SIP trunk, so the call is definitely going via the same SIP trunk.

I turned on the debug logging as suggested, and it appears to be using a blank outbound caller ID, when a call is forwarded.

Note when I receive an inbound call with call forwarding disabled, the phone number for the inbound call is displayed OK in 3CX.

Which SIP field is supposed to be used when a call is forwarded?

My observations are as follows:

• Under our individual user extensions, the Outbound Caller ID field is blank. When we make an outbound. call it uses the main trunk number.
• If I change the Outbound Caller ID field under an extension, then it will use that Outbound Caller ID when placing an outbound call.
• When a call is forwarded, it does not use the Outbound Caller ID field at all from the user ext settings, as no matter if I leave it blank or populate the field, the outbound ID used is a different number which is not our main trunk or DDI.

 

[john1902]

Hi Chris, actually I think I have spotted the issue now. When I looked under outbound rules, then our default / primary outbound rule, the outbound caller ID was blank.

Now I've populated the outbound caller ID with a number, this is the number which is displayed when 3CX forwards a call to external, which is what I was aiming for!

It took a bit longer than expected for me to figure out, since outbound calls were showing the outbound caller ID OK.

 

[ChrisC_3CX]

I'm glad to hear you managed to resolve the issue! Please feel free to start a new thread should your require additional information or assistance!