Voip.ms losing registration several times a day.

[Jim Canfield]

I recently setup a SipXcom system (16.08) with voip.ms trunks.  SipXbridge is losing registration several times a day. The registration is down for about 10 minutes and comes back.  Restarting sipXbridge will bring it back right away.   After some searching it looks like it could be a couple things.  

HA ITSP - https://groups.google.com/forum/#!topic/sipxcom-users/F4JLSXx6taY

or

Registration timers

I'll attempt to pull logs tomorrow and open a ticket with voip.ms, but I'm curious if anyone else is struggling with this?

Thanks,

--Jim

[pmkr...@gmail.com]

Hi Jim - we had a customer on 14.04 with registered SIP trunk from voip.ms that experienced this issue every 2-3 days, where there would be a ten minute stoppage of sipxbridge processing, even when the registration interval was reduced from 600 seconds to 120 seconds. The workaround was to re-define the SIP trunk as a static trunk (you need to create a subaccount within voip.ms to do this) and add a firewall rule to accept all traffic from the voip.ms node that your DIDs are anchored on.

Voip.ms nodes do not do high availability 'today' - all traffic comes from one voip.ms node. The cable network that this customer was on was experiencing intermittent packet losses at the time, and wondered whether the issue was related to the UDP keepalive packets that Sipxbridge sends every 20 seconds, whether some of them aren't getting through to voip.ms, or the responses aren't coming back. Given this is happening several times per day, I'd do a packet capture from Sipx or the firewall and try correlate the 20 second UDP packets to the issue. I'd also look at the firewall states when the issue occurs and see whether the inbound state from voip.ms to sipx has aged out.

Peter

[Jim Canfield]

On Wednesday, August 17, 2016 at 9:48:08 AM UTC-5, pmkr...@gmail.com wrote:

Hi Jim - we had a customer on 14.04 with registered SIP trunk from voip.ms that experienced this issue every 2-3 days, where there would be a ten minute stoppage of sipxbridge processing, even when the registration interval was reduced from 600 seconds to 120 seconds. The workaround was to re-define the SIP trunk as a static trunk (you need to create a subaccount within voip.ms to do this) and add a firewall rule to accept all traffic from the voip.ms node that your DIDs are anchored on.

Voip.ms nodes do not do high availability 'today' - all traffic comes from one voip.ms node. The cable network that this customer was on was experiencing intermittent packet losses at the time, and wondered whether the issue was related to the UDP keepalive packets that Sipxbridge sends every 20 seconds, whether some of them aren't getting through to voip.ms, or the responses aren't coming back. Given this is happening several times per day, I'd do a packet capture from Sipx or the firewall and try correlate the 20 second UDP packets to the issue. I'd also look at the firewall states when the issue occurs and see whether the inbound state from voip.ms to sipx has aged out.

Hi Peter,

Thanks for the input.  I've changed the registration timer to 60 from from 600 per Tony's suggestion.  You bring up a good point with UDP states and firewall.  I noticed my firewall state timers included a udp-idle-timer that times out after 60 seconds so I may be dealing with a firewall state issue as well.  I'm going to play with these timers as see if I can find a good combination. 

[Gerald Drouillard]

IMO, It is better to do static IP authentication with voip.ms and setup a sip URI on voip.ms for inbound calls.

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-users+unsubscribe@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/07af7d5f-014e-48b1-bc4b-fd40728d4ba2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Regards
--------------------------------------
Gerald Drouillard
Cell: 734.502.4356

[Jim Canfield]

*FOLLOW UP*

Hi folks, just want to follow up on this issue now that I have everything sorted out.  Turns out this issue had "everything" to do with session timers.  Here's what I did and why...

Tony's suggestion to change registration timer to 60 seconds was the fix, but after some playing around I was able to understand the issue a little better.  I realized there were other timers in the works here, more specifically, firewall session timers.  Since these are UDP sessions, finding and setting them can be challenging, especially at the firewall level. 

  For PFsense - The only way to change UDP session timers is to put the firewall in "conservative" mode.  This will, by nature, extend the UDP session timers.  Keep in mind, longer session timers mean more system resources. 

  For Fortigate - set udp-session-timer (default is 180 seconds) 

I was trying to avoid IP auth for philosophical reasons (i.e Multi-WAN) so I'm glad this is all worked out now.  We have been running solid for a week and averaging over 300 calls a day.  

Hope this helps someone else.

--Jim