SIP Registration

[h382]

I don't know if anyone else has seen this, but I have a 2 SIP Trunks at two different offices. Both running on 6.0.8

They just called to inform me that they were seeing a registration request come through every half second. They said I needed to change my expiry time to 2 minutes so they aren't being overloaded with registration requests.

I checked the expiry time on both SIP trunks and it was set to 60, the default. The Help file says that is 60 minutes. If I look in Monitor I see this message as I see TONS of registrations messages fly by. "SIP Line (100) parameter 7045555555 registered, expires in 0 seconds (interval 0)"

I changed the expiry to 300, and rebooted, and they said there was no longer a flood of requests, and now that message says " SIP Line (9) parameter 7045555555 registered, expires in 449 seconds (interval 898)"

Has anyone else noticed that this when leaving the default expiry to 60?

BTW, I'll probably drop it back down to 120 or something smaller when I can reboot again.

 

[TheZCom]

I have seen something very similar to this as well. A reboot would fix the problem temporarily, but then the issue would return. I am currently monitoring my in-house system to see if the problem persists on the R6 Q2 FT version. Z

 

[h382]

So even if you changed the expiry, it would end up doing the same thing eventually?

Any idea on when the next version of 6 will be out?

 

[TheZCom]

Exactly. I don't know when the Q2 version will be officially released. Z

 

[intrigrant]

release is at the end of Q2,end of june i would say

 

[h382]

@TheZCom

Do you know how long it is before it starts acting up again? I'll have to manually reboot the system before it starts getting funky again.

 

[h382]

Also...

What is the proper process of programming SIP inbound calls..

I have 5 SIP channels configured on 1 SIP trunk. I'm going to be porting over 20 DIDs within the next couple weeks to the SIP provider. Right now I only have 1 incoming call route for the BTN the SIP provider gave me, and if I create an ICR for that BTN #, it goes to wherever I point it.

Is it as simple as adding an ICR for each of the DIDs to be ported? I have the SIP trunk to use internal data, and on each user I have their 10 digit DID that they use. Right now if they call out of the SIP trunk it shows their DID, which is what I want.

I haven't done inbound SIP DIDs yet, so it's a learning experience.

 

[TheZCom]

h382--It's been a little over 24hrs now since my last reboot and the 'registration storm' has not yet appeared. I will continue to monitor...

In regards to the inbound route programming for your SIP trunks, you should be able to create an ICR for each DID as you describe. I have done this for my Broadvox SIP service and it works great. Z

 

[h382]

I had rebooted my system this past Friday, and it started the SIP Registration Storm again. I'm not sure when it started, but I had a call from Broadvox asking me to "fix" it again.

 

[TheZCom]

@h382--well, my IPO is now doing the registration retry every second now. It looks like it popped back up after about 72 hrs. Funny that we're both having this issue with Broadvox trunks (not part of the initial discussion). Z

 

[tlpeter]

Can you guys check if you have the option OOS checked.
Try to uncheck it.

Perhaps that the OOS check is the problem:

Note: Trunks that are out of service will be retried every 2 minutes.
The Out of Service check is configurable on each SIP trunk, in case the SIP trunk
does not support the OPTIONS message for example. A new check box on the SIP
line tab “Check OOS” is used to enable this feature. For a configuration that has
been upgraded to IP Office Release 6.0 from a previous release this option will be off
by default. For any new SIP lines added the default setting will be on.

Homo sapiens non urinat in ventum

honey, i fried the IP Office !!!

 

[h382]

I can try that, but even so. Broadvox would be thrilled if it was just re-trying once every two minutes. It's re-trying every half second. So instead of once every two minutes, they get 240 tries every 2 minutes.

 

[TheZCom]

tlpeter--thanks for the suggestion. I un-ticked the 'Check OOS' over the weekend. I'll let everyone know how it goes. Z

 

[TheZCom]

The issue returned after about 72 hours again. A reboot to the IPO provides a temp solution. The time period seems to be consistent for the return of the 'registration storm.' I wonder if there's something on the Broadvox side that happens every 72 hours that causes the IPO to freak out.

h382--can you confirm that the problem re-occurs after a reboot around 72 hours later? Z

 

[h382]

I last rebooted Sunday night, and when I came into the office this morning it was doing it again. So I don't think it was quite 72 hours, probably closer to 60 on my side. 2-3 days seems to be the time frame for me.