SIP Trunk Re-Registration

[Bastian Lüth]

Hi everyone,

quick question because I encountered this issue twice this week.

We have a SIP Trunk Pure (Deutsche Telekom) connected to our 3CX (Re-Register Timeout 240 - default value, i guess?).

On Monday, around 3 pm our users reported OUTGOING calls as "Forbidden By Administrator". At this time, the last registration should (according to the display in the SIP trunks menu) only be a few minutes ago.

However, the issue persisted until I selected the trunk and hit "Refresh Registration".

Now - today - around 1 pm - same issue, same solution. Anyone got an idea, why? Is the Re-Registration not working properly?


Thanks!
Bastian

 

[YiannisH_3CX]

Hi @Bastian Lüth

The message you are getting does not line up with the trunk registration not happening correctly. You will usually receive this message if outbound calls are forbidden on the trunk or on your extension.
If the issue is resolved with a trunk re-registration however then you need to see what is happening at the point this happens.
Do inbound calls work? If so then the trunk is still registered on the providers side as the call is coming in.
Are other people on call at that point? Perhaps the limit on the trunk is reached?
The activity log of the PBX should provide more info on why this happens. You may need to increase the logging level to verbose for the duration of the testing to have maximum details logged.

 

[eddv123]

I have experienced a similar random issue on a site before but it was due to the overally secure firewall doing something very odd with the provider IP address that 3CX was sending (and yes SIP ALG was not present on the firewall).

The error itself I would agree is more an internal 3CX error (happens regularly when outbound rules are not in place to support your call).

If I were in your place I would run a PCAP from the 3CX system and see if you just get the outbound leg from the phone to PBX, or whether the leg from PBX to provider is present.

VERBOSE logging would also be useful as well if the issue is internal to 3CX.

https://www.3cx.com/docs/capture-network-traffic/
https://www.3cx.com/docs/collecting-logs-for-3cx-support/

 

[Tomas Raska]

Hi, we now have the same problem with Deutsche Telekom. First I enabled verbose logging.

After the problem occurred, I found in the verbose logl "Forbidden" for some outgoing calls. The problem was gone when we clicked “Refresh Registration”. This action (refresh registration) is documented in a detailed log, but I do not see any action to "re-register timeout" in this log. Is this action too documented in verbose log or only in SIP Trace? Or this action occurrs only when we dont have any calls 120 seconds (re-register timeout)?

And the problem occurred after we updated to v16 last week.

 

[eddv123]

Next time it occurs Wireshark/PCAP the call (as above and lets see whats being sent to the provider).

 

[YiannisH_3CX]

Hi, we now have the same problem with Deutsche Telekom. First I enabled verbose logging.

After the problem occurred, I found in the verbose logl "Forbidden" for some outgoing calls. The problem was gone when we clicked “Refresh Registration”. This action (refresh registration) is documented in a detailed log, but I do not see any action to "re-register timeout" in this log. Is this action too documented in verbose log or only in SIP Trace? Or this action occurrs only when we dont have any calls 120 seconds (re-register timeout)?

And the problem occurred after we updated to v16 last week.

Your issue looks different from the one the OP has. I believe your is related to an issue we found in V16 SP3 so i would recommend upgrading to V16 SP4 which is currently in Beta where the issue is fixed.
https://www.3cx.com/blog/releases/chrome-call-extension-beta/

 

[Bastian Lüth]

Hi everyone,

just a quick headsup regarding this issue. I've found a similar post related to this
https://www.3cx.de/forum/threads/telekom-ngn-r403_request_not_allowed.94528/

and the quick-fix resolution to this seems to work for now.

Refreshing the DNS cache every X (5) minutes via
systemd-resolve --flush-caches

We'll monitor this - and upgrade to SP4 as soon as it's marked as stable.


Cheers!
Bastian