SIP backup routing problem

[AlexanderReichert]

So either I don't understand how the SIP backup routing works or there is a problem
I have a outbound rule with two routes
first Flowroute then Amazon chime

someone makes a call that hits that rule
and I see this in the log in 3CX
01/27/2021 10:56:40 AM - Leg L:1101.1[Extn:1007] is terminated: Cause: BYE from PBX
01/27/2021 10:53:49 AM - [CM503025]: Call(C:1101): Calling T:Line:10000>>XXXXXXX*1906XXXXXXX@[Dev:sip:[email protected]] for L:1101.1[Extn:1007]
01/27/2021 10:53:49 AM - [CM503027]: Call(C:1101): From: Extn:1007 ("xxxxxx, Madeleine" <sip:[email protected]:0>) to T:Line:10002>>+1906XXXXXXXX@[Dev:sip:[email protected]]
01/27/2021 10:53:49 AM - [CM503004]: Call(C:1101): Route 2: from L:1101.1[Extn:1007] to T:Line:10002>>+1906XXXXXXXXX@[Dev:sip:[email protected]]
01/27/2021 10:53:49 AM - [CM503027]: Call(C:1101): From: Extn:1007 ("xxxxx, Madeleine" <sip:[email protected]:0>) to T:Line:10000>>XXXXXXXXX*190XXXXXXX@[Dev:sip:[email protected]]
01/27/2021 10:53:49 AM - [CM503004]: Call(C:1101): Route 1: from L:1101.1[Extn:1007] to T:Line:10000>>XXXXXXXX*1906XXXXXXX@[Dev:sip:[email protected]]
01/27/2021 10:53:49 AM - Call(C:1101): Call from Extn:1007 to 906XXXXXXXX matches outbound rule 'Domestic Number'

the problems that the call never connects. if I take the backup route out of the outbound rule the call connects fine.

 

[AlexanderReichert]

In addition the caller sees actually that 3CX tries to make two calls at the same time.

 

[AlexanderReichert]

@cobaltit I apologize to just randomly tag you on this. But maybe you have any idea what might go in here?

 

[cobaltit]

No problem. I guess the first thing is some more back story. Did it ever work/behave differently? Passes firewall check? I assume the adding of Chime was recent. Was this because of previous issues with Flowroute? Does this happen with all numbers? With all extensions?

 

[AlexanderReichert]

routing through Amazon Chime and routing through Flowroute alone works.
Well some exchanges have problems routing through flowroute hence we, as you guessed, changed those exchanges to route through Amazon Chime until Flowroute can figure out what is going on.
So just alone it works (only route 1 is filled all other routes are blocked in the outbound rule)
The problem starts when I add a Route 2 in the outbound rule (as a backup)
and then the behavior is consistently wrong with every number that hits that outbound rule with a route 1 and route 2 filled.
it doesn't matter if amazon is in route 1 or Flowroute is in route 1

My expectation of such an outbound rule is:
try route 1 first , if that fails, try route 2

That is not what 3CX apparently does. according to the logs above it tries both routes at the same time. resulting in the webclient with two calls to the some number being tried. none of them connects.

As I said - either I don't understand this feature in the outbound rule correctly or there is a problem.

 

[DFP]

I have this setup to with different provider and four of them.

3cx calls the first and if we get 486 or 503 message back it goes on to the next provider the user only see one call.

What software version are you running ? Maybe a bug?

 

[AlexanderReichert]

@DFP your system behavior is what I would have expected.
As you see in the log that is not the case for us.
software version: 16.0.7.1078

 

[YiannisH_3CX]

Hi @AlexanderReichert

A few questions: Does the firewall checker pass? How many lines do you have on your trunks? Also I see you are using the Browser extension for making calls. Does the same thing happen when using an IP phone or mobile client? Also use you using Debian or Windows?

I would recommend switching the logging level to verbose and then replicating the issue again. Check the activity log then as it should provide more details as to what is going on. Share the logs if you need any assistance.

Backup routes should work one at a time. If the first fails move to the next one and so on.

 

[AlexanderReichert]

so seems for now the problem was in fact the firewall. there was a problem with the port 5060 not totally open (it was restricted to FlowRoutes IPs, but Amazon Chime was missing.
I don't totally understand why that would cause this issues because this is an outbound call and the initiator is 3CX and not Flowroute or Amazon. But after i opened the port totally (which I don't particular like) it seems to work now.

I will have to watch that for today and will report if it is really solved with this.

 

[leejor]

If you have some time to play with Wireshark (after changing your firewall back to what it was originally), it would be interesting to see what SIP messages (or lack thereof), would cause 3CX to establish a second call, without dropping the first. To me, that sounds like a situation, that could be prevented, with a software tweak.

If 3CX saw fit to use the second route, then it should drop the first call, no matter what.

 

[DFP]

I believe amazon chime is a static route so any reply would be blocked by default.