Extremely High Registration Frequency

[blueface]

Hi,

I work for a VoIP Provider and we have started to get a few customers connecting to our service with the 3CX PBX. The majority work fine but there are a small number that end up sending us a very high volume of REGISTER requests, at one stage one user was sending over 30 a second.

We have installed the 3CX software and are trying to replicate the problem in order to advise users but even when setting the registration interval to 0 our 3CX install does not generate that volume of requests.

Any idea whether this issue has cropped up before and/or whether there are any settings we can request our users to change to throttle back teh volume of requests?

Regards,

Aaron

 

[stevef]

Aaron,

I was that user... I have been trying to figure out the cause. One suggestion from the support guys at 3CX is a NAT problem ias the multiple registration request kept switching ports.

We appeared to have the problem start again yesterday evening and it coincided with our Broadband becoming maxed out. We only have DSL 6MB/512K and yesterday eveing a large mailshot was being sent out that essentially killed our upstream bandwidth. At the same time 3CX started to have registration issues. Not sure if this is what caused the issue in the first place but i'll keep monitoring.

PS
We are the Irish 3CX partner and I'd be interested to get an idea how many Irish users you have using 3CX.

Cheers
Steve

 

[blueface]

Hi Steve,

I was that user...

Yes you were . However you are not the only one we have had it with so i thought I'd check with the source.

I have been trying to figure out the cause. One suggestion from the support guys at 3CX is a NAT problem ias the multiple registration request kept switching ports.

That could be very likely. I have seen similar behaviour with other devices. The NAPT router in front of them loses the mapping and the REGISTER responses never make it back through to them causing them to continually attempt to register. That sort of behaviour is expected and in fact desired however it's the frequency that is the problem. An attempt to re-register every 10s would be ideal, every 1s is high but acceptable but if it's 30 times a second that's a lot of SIP traffic to process... My humble suggestion to the 3CX developers would be to hard code a minimum limit on the time between REGISTER requests that is at least over one second.

PS
We are the Irish 3CX partner and I'd be interested to get an idea how many Irish users you have using 3CX.

A quick check of our database shows approximately 20 users have registered with a 3CX system with about a dozen currently active.

Regards,

Aaron

 

[archie]

We apologize for inconvenience, we had inappropriate approach to registering in version 3. In version 4 we had fixed this issue and it should not spam registrations anymore. Although, I think it is useful to check it once more in different stressful situations. Again, we can not guarantee that somebody will not create 30 lines of the same account, which also may produce 30 registrations at a time.

 

[blueface]

Hi archie,

Thanks for the update it's good news and if the problem re-occurs with our users we'll ask them to upgrade their 3cx software.

I agree the same type of problem could re-occur if 30 lines are set up with the same credentials however that would be easier to fix as the user would make the link between 30 lines and a high volume of registrations. In the past the problem was that when we notified the user they were generally unable to identify anything on the 3cx system that could help, such as increasing the register expiration.

Regards,

Aaron

 

[archie]

General approach to fix it on version 3 is to set registration time much less than STUN resolution re-check time. This flood can be caused if resolved iport mapping has changed. And, if it happens more often than registration refresh - it may accumulate a lot of active registrations.

 

[NMN]

I had a very similar problem a few weeks back. Enabling QoS (Quality of Service) with high priority on the 3CX port/IP and ultimatively throttling the bandwidth to 'surfing' computers to around 75% of line speed fixed the problem for me.

HTH

NMN