V20 SIP trunk quarentine

[Gioal]

Hello!

In V20 after a "404 timeout" received from unsupported provider SIP trunk, 3CX put SIP trunk in quarentine for a X seconds refusing incomming and outgonind calls.

Tested same scenario (same provider) in V18 and the problem doesn't appear.

3CX support refuse to verify the system because is "unsupported provider" even knowing that the question is the 3CX behaviour and not the SIP provider. We want know if is a normal behaviour or some flag/parameter tha can be set on system.


Thanks!

 

[Gioal]

1 - User make a call, the outside number doesn't exists
2 - 3CX send to provider, provider respond with Request Timeout
3 - User make another call and 3CX now doesn't send to provider
On activity logs 3CX show "being terminated (NoRouteExists)".
During X seconds all incoming and outgoing calls from or to this provider are refused by 3CX.
After X seconds they work again. It's a kind of quarentine.

 

[Ubiratan Martins]

Hi @Gioal
How many seconds are X in your case?
I had the same problem here but the outbound calls no longer work.

 

[Gioal]

About 120s.

 

[Guillaume Bourgeois]

So 192.168.1.120 is your PBX and 10.101.255.1 is .. provider SBC ? Or FXO ?

 

[Gioal]

So 192.168.1.120 is your PBX and 10.101.255.1 is .. provider SBC ? Or FXO ?

Yes, my 3CX and provider SBC

 

[Guillaume Bourgeois]

The way you're being authenticated seems to be IP-based.
Could you check with your SBC provider if it's possible for you to register?
That alone would bring you closer to compliance!

 

[Gioal]

Do you mean that for 3CX a registered sip trunk will be treated differently?

 

[Guillaume Bourgeois]

It’s not just 3CX; when using IP-Based mode, during INVITEs, there is no authentication validation. As a result, calls are sent by 3CX without receiving confirmation that your server is authorized to make these calls.

With the SBC in REGISTER (proxy) mode If your provider properly configures your SBC in proxy mode, your 3CX will authenticate directly to the upstream server through the SBC, which acts as a proxy. If it is properly registered (UP), it means it is authorized.

In IP-Based mode, the SBC does not validate, it only forwards your call to the upstream server. The issue you are encountering might be that the upstream server behind the SBC does not authorize the call because the CallerID is in an incorrect format, is not authorized, etc., and the SBC is not correctly relaying the message back to you, instead sending a request timeout rather than the real error SIP code.

 

[Gioal]

It’s not just 3CX; when using IP-Based mode, during INVITEs, there is no authentication validation. As a result, calls are sent by 3CX without receiving confirmation that your server is authorized to make these calls.

With the SBC in REGISTER (proxy) mode If your provider properly configures your SBC in proxy mode, your 3CX will authenticate directly to the upstream server through the SBC, which acts as a proxy. If it is properly registered (UP), it means it is authorized.

In IP-Based mode, the SBC does not validate, it only forwards your call to the upstream server. The issue you are encountering might be that the upstream server behind the SBC does not authorize the call because the CallerID is in an incorrect format, is not authorized, etc., and the SBC is not correctly relaying the message back to you, instead sending a request timeout rather than the real error SIP code.

Let me explain, the number used in the test doesn't exist, we made this way to force provider to give us this message.

Again, the case here is not the relationship between 3CX and provider but the way 3CX acts after that call result. Even sip trunk was in register mode, the result would be the same because the number is proposital wrong.

My question is why 3CX puts sip trunk in quarantine after this call result. I only want to know if it is a normal behavior of V20 or there is something that can be done by configuration. Or it could be a bug of the new version since doesn't happen in the old one.

 

[Guillaume Bourgeois]

Check if your "408 Request Timeout" includes a "Retry-After" parameter.
This could explain why 3CX isn't retrying, per your service provider's request

 

[Guillaume Bourgeois]

Please share your complete pcap file with me privately so I can analyze it in more detail; it's challenging to assist with limited information. I've tested on my end and did not replicate the issue—when I receive a 408 Request Timeout, and retry immediately, 3CX sends the invite.

 

[Gioal]

Good news!

3CX contacted me, there is a bug in V20 that blocks incoming calls when the provider IP is greylisted, but the behavior for outgoing calls is correct. So they will fix the issue for incoming calls.

For outgoing calls, the way is to avoid the provider IP from being greylisted. To avoid this, the provider can either not respond 408 or 503 (which is incorrect for failed calls due to wrong number) or use FQDN instead of IP in sip trunk. I will try by FQDN and give feedback here.

 

[Gioal]

Correcting, even using a FQDN the provider will be graylisted and will be out for 120s.

I had a misunderstanding, my fault.

 

[Milton Taylor]

After we updated to v20, it started to present a problem of not finding the route for some outgoing connections.
There is prints attached.
However there is a note release from 3cx where where it is described that grey list timer for truncs is fixed (print attached)