VOIP Tech Chat → [Voip.ms] Having a really frustrating couple of days with our voip service

We've had a couple of SPA-112's at our office giving us 4 lines for just over a year now. Seems that once every month or two they act up and it takes some combination of power-down, hard reset or config re-load to get them up and stable again. Our service is with voip.ms, and I use them for home voip (also with an spa-112) and there's no problem with that at the moment. Problem at the office was noticed last night around 6 - 7 pm. Pick a line, no dialtone. A few minutes later, pick a line, get dialtone, so I dial, get dead air. Check the voip.ms portal, it says we're registered. Check a few minutes later, no registration (and no dialtone). We have one ATA set for Toronto7 (and port 5060) the other for Toronto8 (and some weird port like 12 or 14k). Home is using Toronto5. We putz around, it's getting late, we'll hit it again in the morning.

We have a syslog running and try to always have it running (on a windows box, not a lot of good syslog options on windows) but it's really time-consuming to check those (huge) logs for the stuff you're looking for. The few times we looked, we were only seeing a few registration failures over a 3 or 4 week period.

Today, everything is working - but we rarely make calls and only 2 calls come in. Then again this evening the same problem. Voip.ms is not indicating any problem with servers on the website. We power cycle our router (UBNT ER3), a couple of switches, the ATA's, but still have the problem. I manage to make 1 call over the course of an hour, but otherwise it's like I described above. Start putzing with increasing UDP/TCP timeout settings on the router, but again it's getting late so we'll hit it again in the morning. From home I can see the ATA's are not registering (or if they are, they're only doing it for maybe a minute or two and then go down for like 10 minutes). The voip.ms call logs indicate that when the ata's are showing as registered and we have a dialtone and we dial-out (and get nothing) the call logs are not picking up those outbound call attempts.

Why does this happen? Nothing is changing on our end as far as I know to cause these bouts of instability/non-functionality.

Next time you have a problem, change your ATA's SIP Port to a random number between 20000 and 65535, for example, 30896. If that gets you back online, your router's UDP timeouts are incompatible with your ATAs' keep alive and registration intervals.

If that doesn't change the symptoms, check your dialog debug to see if it gives you any clues. You need only check the most recent messages for that specific ATA.

I suggest you try tcp for signalling and don't use any inbound nat/firewall rules.
I can explain in detail if you required.

As I expected, our ATA's were behaving themselves during the day today, at least every time I picked a line and made a test call. But again late in the day (after 5:30 pm) they went wonky again. So we putzed around and I think I made a change that seemed to work (and stay working). Our two SPA-112's were set to use SIP ports 5060 (line 1) and 5062 (line 2) where ATA-1 was using the toronto-7 server and ATA-2 was using the toronto-8 server. I changed the ports to 15060/15062 (ata1) and 15064/15066 (ata2) and each time when I applied the change the ATA came up and registered immediately - and the lines worked (inbound and outbound). So I'll monitor this for long-term stability.

Regarding SIP using TCP vs UDP, I don't see a setting in the SPA-112 to change that. Only the SIP port number. We have no router firewall or nat rules pertaining to the ATA's or voip ports.

Just as a friendly clarification, that is not a good way to test registration, since registration IS NOT required for outgoing calls. A better way would be to place calls to the device´s DID number.

You also dont mention if you opened a ticket with Voip.ms? Changing the ports should be one of the first things that should have been suggested

Good luck!

I second the recommendation that INBOUND calls to those ATA are the best test. And make sure you are using GOOD DNS servers. Put those ATAs on Google DNS and see if they are more stable. They are likely doing DNS lookups every re-register. Good DNS does not always include the ISPs DNS servers. Google or OpenDNS or maybe Cloudflare. If DNS doesn't fix it, go after UDP timers in your firewall (some default to 30 seconds globally which isn't friendly enough to VoIP, create a rule to select your VoIP traffic and adjust the timer for just that traffic). Also do you know that your Internet is actually reliable? Web surfing doesn't really test ISP quality enough for VoIP.

I don't know what you guys are talking about. I don't get a dial-tone unless these ATA's are registered. Read what I said in the first post. I pick a line, get dialtone, try to call, get dead air. Check the voip.ms portal - the ATA's are showing as registered during all this, but voip.ms isin't seeing the out-bound call attempts in the call logs.

Changing the sip ports (moving them from 506x to 1506x) and giving each line it's own port seemed to help immediately when the problem was happening. I had said that the ATA's were using different sip servers (toronto7 and 8).

After making the port changes we tested the hunt-group/roll-over and found it wasn't working (ie - dial our did when line-1 is busy is supposed to forward to line-2 but it wasn't). Turns out that all lines in a hunt group need to be on the same sip server. So we put them all on toronto7 and it's working again (it may not have been working like we thought it should be for some time but we just didn't notice). But I think that changing the ports was the real fix in this situation - not putzing with dns setting.

I don't know if there's a lot of hacking attempts being done on 506x ports or what (it wouldn't surprise me) and it's somehow interfering / messing up the ata's.

We did increase UDP timeout in the router (that was before the port-change) but I don't think it did anything. And no-one has answered the question - do the SPA's use UDP or TCP for sip? There's no setting in them for that as far as I can see.

>>> And no-one has answered the question - do the SPA's use UDP or TCP for sip?
>>> There's no setting in them for that as far as I can see.

The Spa112 does both. According to this
»basichelp.sipgate.co.uk/ ··· Adaptors
there is a SIP Transport box to chose...

ah, ok, I see it. I can choose udp, tcp, and tls. My home ATA is set to udp. Is that the default for these (or most) ata's? Is TCP preferred?

The default is UDP.
And voip.ms worked for me with half a dozen different ATAs just fine (I use Chicago2 servers).
Never used SPA...

I don't think UDP/TCP is the root of your problem.
Something nefarious happening on a particular port is more likely...
Or finicky internet access...

Alternate theory: by changing your port numbers outside 506x, you've bypassed your router's malfunctioning SIP ALG. In any case, I'm glad things are working.