SIP registrations/calls failing all of a sudden

[JohnM]

Hi,

I'm having some bizarre issues today where progressively all SIP registrations, and inbound trunk calls are failing.

It started with one phone, but then slowly as the day progressed more and more phones dropped offline and were unable to register.

I have had a look at tcpdump on the server, and packets are definitely reaching the server;

16:00:47.832065 IP x.x.x.x.5065 > x.x.x.x.5060: SIP: SUBSCRIBE sip:[email protected]:5060 SIP/2.0
16:00:47.989591 IP x.x.x.x.5065 > x.x.xx.5060: SIP: SIP/2.0 200 Ok

However then the extension does not appear as registered in 3cx. In cxSystemService.log I can see the following;

2018/06/27 15:56:52.432|4639|0017|Verb|Enqueue Updated.REGISTRATION.45
2018/06/27 15:56:52.433|4639|0008|Verb|Dequeue Updated.REGISTRATION.45
2018/06/27 15:56:58.731|4639|0017|Verb|Enqueue Updated.REGISTRATION.26
2018/06/27 15:56:58.732|4639|0008|Verb|Dequeue Updated.REGISTRATION.26
2018/06/27 15:57:02.533|4639|0017|Verb|Enqueue Updated.REGISTRATION.53
2018/06/27 15:57:02.533|4639|0008|Verb|Dequeue Updated.REGISTRATION.53
2018/06/27 15:57:37.978|4639|0003|Verb|WaitingEvent for updates:60000

With the occasional;

2018/06/27 15:57:02.534|4639|0033|Info|HD: registration sip:[email protected]:5065;line=abcdefgh is valid

(This extension is the only one which continues to successfully register, out of around 20 extensions at different sites).

I'm at a complete loss as to why this has suddenly started happening, and exactly where the problem lies. Any help much appreciated!

 

[eddv123]

Please explain your topology in more detail. Is this a hosted system or on premise with remote connections ? If you have phones connected remotely to the 3CX system how are they connected and what are brand, model and firmware running on them ?

Who is the SIP trunking provider ? I would imagine they are registration based (judging on your description) and are they supported: https://www.3cx.com/partners/sip-trunks/

Please run a PCAP trace from the PBX for the SIP trunk and the IP handsets for the handsets - what responses are you getting back to the registration request ?

 

[JohnM]

Hi,

This is self hosted at a remote datacentre.

Phones are connected via Direct SIP. At a variety of different locations, in different countries, using different ISPs for connectivity.

All Snoms - a variety of 710, 720 and MeetingPoint - running the 3cx approved firmware for each model.

SIP trunking is Gradwell - not registration based. Calls come in as a SIP Invite. They are supported.

This config has worked perfectly for more than a year, and we only started experiencing these issues today.

Bizarrely, in the intervening period since I first posted - everything has gone back to normal and started working again, apparently without intervention! It sounded very much like a hosting provider (at the 3cx server end) connectivity issue, but I'm fairly sure that was eliminated.

If it reoccurs I will grab a PCAP, and follow up here.

Thanks!

 

[eddv123]

No problem, I am not preferable of using direct STUN (unless for single remote extensions per site).

This should not be a provider issue in that case, and if they are not a registration based provider they should be seen as green (registered) at all times anyway. I would look at the hosting provider also.

 

[YiannisH_3CX]

Hello @JohnM

Glad to see that things went back to normal. Please keep an eye on the issue and report back if you experience similar behaviour again.

 

[JohnM]

It seems this is happening again, although only with inbound calls from the trunk provider (Gradwell, UK).

In a PCAP I can see invites coming from Gradwell, but no response from 3cx.

Bizarrely, after a while (10 seconds or so), the relevant extension in 3cx *sometimes* starts ringing, however there is no audio at the callers end (ring tone or otherwise), and if the extension is answered, there is silence. Also, if the call is terminated at the callers end, the 3cx extension continues to ring and eventually goes to voicemail.

In the call logs, I can see the "From" for these failed test calls is shown as (@(Ln.10000@Gradwell Communications)).

Very bizarre. I'm starting to think there has been some underlying change somewhere which is causing this..

 

[JohnM]

Looking through a PCAP in more detail - I am seeing that the INVITE packets are fragmented. I am guessing this has a lot to do with it..