Call Fowarding / Multiple SIP Trunks

[stevendq]

Hi,

I have a problem on my 3CX phone system that may be configuration related but I can't find the issue.

I have 3 SIP Trunks, 2 of which forward to ring groups, and 1 to an extension. A similar config exists for outbound calls.

3x Outbound rules, 2 for calls originating from groups, and 1 for calls originating from a single extension.

When the user of the single extension forwards their phone to their cell, directly from the handset, then the outbound call goes via the wrong SIP trunk. It doesn't consistently use the trunk they are assigned for their extension.

Any ideas?

Steven

 

[lneblett]

Would like to clairfy what you mean when you indicate "forwards their phone to their cell, directly from the handset". I take this to mean that rather than using 3CX itself via the MyPhone app, or status change via dial codes to handle the forwarding tasks, that the extension user has a hard phone that allows for the external cell number to be programmed and then a key that the user can toggle to indicate call forward on or off. You don't mention the make and model of hard phone which might be helpful for others who have same to mimic the scenario. The only suggestion at the moment is to look at the log files and see how 3CX interprets the hard phone handling the call and compare to how the rules are set.

If you mean that the user is changing their status via the handset and 3CX is then handling the forwarding tasks, then that is different, but still the logs should give a clue.

Is it possible that the outbound rules may have alternate routings established such that the other providers could come into play (say for instance, if the primary provider is not registered or returns an error of some type)?

 

[stevendq]

Thats correct, they have a Cisco SPA504G that they are using the menu function on to diver their calls to a cell phone, rather than using the "myphone" feature.

I've carried out some more testing, and looked at the logs. I can't work out what outbound rule 3CX is evaluating to make the call. It looks like it's just picking the top one in the list. All three outbound rules are set to calls starting with "9" and then use the extension group to define a different provider for the route.

Here is the log file from the error. You can see the inbound call comes in on the trunk Ln.1006, but then when it forwards it sends it out on Ln1003. This is the first rule on the outbound rules list, but is set for an extension group that does NOT include the 1010 extension.

13:59:51.823 [CM503025]: Call(783): Calling VoIPline:07xxxxxxxxx@(Ln.10003@VU - Hamble)@[Dev:sip:[email protected]:5060]
13:59:51.817 [CM503004]: Call(783): Route VoIPline:07xxxxxxxxx@(Ln.10003@VU - Hamble)@[Dev:sip:[email protected]:5060]:
13:59:51.816 [CM503006]: Call(783): Diverted to: <sip:[email protected]:5060>
13:59:51.721 [CM503025]: Call(783): Calling Ext:Ext.1010@[Dev:sip:[email protected]:5060]
13:59:51.679 [CM503004]: Call(783): Route 1: Ext:Ext.1010@[Dev:sip:[email protected]:5060]
13:59:51.678 [CM503010]: Making route(s) to <sip:[email protected]:5060>
13:59:51.677 [CM505003]: Provider:[VU - Aztec] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CXPhoneSystem 10.0.23053.0] PBX contact: [sip:[email protected]:5060]
13:59:51.675 [CM503001]: Call(783): Incoming call from 01794xxxx@(Ln.10006@VU - Aztec) to <sip:[email protected]:5060>

 

[lneblett]

On the surface, it looks like a call came in and was routed to extension 1010. 1010 "diverted" the call which is then going out route 1003.

My guess is that the "diverted to" message lacks any info within the messaging that identifies the extension. As a test, I would disable the forwarding aspect within the phone and set-up the equivalent within the 3CX forwarding rules and run the same test again and compare what the logs show. if the logs are not set to verbose mode, then I would do so to ensure that as many details as possible are captured.

I am under the assumption that virtually all outbound rules are expected to have a "9" and be associated to an extension which then selects the route and that not meeting both conditions should result in a failed call. Do you concur with this?

What is the rule that is associated to 1003@VU-Hamble, particularly the extension range?

 

[stevendq]

All of the outbound rule groups do have a "9" defined as the outbound rule, but then specify an extension group rather than explicit extensions. I've tried setting the extension range as well but it made no difference.

1003@VU-Hamble rule is "9" and calls from an extension group that contains 1001-1008 extensions.

It does look like the Cisco Phone when it returns the call doesn't do so with any particular from extension field. This is confusing though as then surely none of the outbound rules would match so the forward would fail?

I tested specifying the forward on 3CX and it goes out of the correct outbound trunk as per the outbound rules. If there is no appropriate outbound rule for that extension then the call fails with "no route to number" error.

I tried verbose mode, but I didn't get any further output. Do i need to restart services for that to take effect?

 

[craigreilly]

Verbose mode does require a restart. I think it even tells you that when you select and apply.

I just tried this on my Yealinks.
If I forward using 3cx - it uses the VOIP Trunk my department uses.
If I forward using the Yealink phone - it uses the TelCo trunk.

Ahhah! Eureka!

The diversion uses the rule for the original extension.
I learned this by forwarding my phone using the handset.
Called from an internal extension. It used the Trunk instead of VOIP.
I added the other internal extension to the VOIP List of outbound rules and called my extension again. This time is used the VOIP Line.

So - since inbound calls do not have an outbound route - this is likely what is occuring.

By the way - why are you using "Dial 9" anyhow? It just adds to the confusion of programming.

 

[stevendq]

Thanks for trying to replicate / resolve the issue.

I'm not sure I understand what you are saying. I have an outbound rule defined for the extension with the divert (set on the Cisco Handset) and normal calls via this extension work and use the correct voip provider. Calls forwarded from the handset use a different voip provider (for an unknown reason).

I've set verbose on, but it doesn't show how it's decided on which trunk to use for the outbound call.

If I remove the extension from any outbound group then the call forward fails with "no defined route".

When you say you added the "other internal" extension to the outbound group - do you mean the calling extension. So the calling extension is forwarded to the external number using their outbound rule? Ahh - yes that makes sense.

What about when the call is from an external number though.

P.S - We use 9 in the UK generally for an "outside" line, so historically its what our users are used too, thats all.

 

[craigreilly]

I am guessing the external calls use the outbound rules.
So - it found a route for a 10 digit number, not from any particular extension - and used that rule.
Then when I added that extension, it found a different rule to use.

So - I am not sure that helps you fix the issue at all - but it certainly explains what is going on.

We previously used 8 or 9 - but got rid of it. And nobody asked any questions when we changed over to 3cx.

 

[stevendq]

I've just tried some more testing. It looks like 3CX is evaluating the outbound rule base and just picking the first one, on the basis that the outgoing call starts "9" and ignoring the extension group setting.

I put the outbound route I want the call to use at the top of the priority list and now the call is going out via the correct trunk.

This sounds like a bug to me? If when the phone forwards the call it doesnt pass any "from" extension details then I would expect the forward to fail because there is no valid route? Instead it's assessing the rules and picking the first one that only part meets the validation criteria. Odd...

 

[lneblett]

Sorry for the late reply.

You may be correct. A few questions -

1. Is it safe to say that with the 3 outbound rules you mentioned in the orginal post, that there are no others and that all three are similar in their format, the difference being that the rules have different extension ranges?

2. By you putting the one rule that is currently in question at the top, does this then not assume that similar forwarding desires for extensions not in the 1000-1008 (and other) group(s) do not, nor will, exist?

3. What happens if you simply eliminate the rule starting with "9" from all routes, but still leave the strip 1 digit rule in (to remove it being that it is a legacy and likely hard to break old habits) along with the extensions rules and then relcoate the rule in question back into the same order where it was? The "9" does not seem to have a useful purpose relative to making any decisions about how to route being that all routes have it.

I think this may confirm your suspiciions, but at the same time accomplish what you wish along with providing some ability to modify the other extension rules if the need arises. It may also provide some insight as to how the Divert scenario is handled. I do not have a Cisco Phone to test with and as a result am uncertain that using a different phone might not lead to different results.