Incoming calls go to failover number

It was mentioned in passing in a long thread on BYOD SIP server connectivity, but Brandon said that it is a different topic, so I'll start on new thread.

I have two Voipo BYOD accounts that are running BYOD adapters. One has no problems, and another was not receiving incoming calls for several days. Fortunately, the working account is my in-laws'; otherwise I'd probably be dead by now :eek:

On the non-working account I have old SPA-2002. I couldn't find whether Voipo requires Auth ID (usually inbound providers do); but it didn't seem to make a difference. Device status page shows registered; Voipo web page shows registered - however the phone doesn't ring and incoming calls go to failover number (or to voicemail, if failover is disabled).

Obviously, both accounts connect to the same server (sip.voipwelcome.com); so it's strange that they behave so differently. The adapter on the working account is new Obi100 - but I don't see how the adapter would make the difference.

Any suggestions?

Standard troubleshooting tip is to set a static ip on your byod device. Then make sure you have forwarded ports 5005 to 65000, or set your byod devices ip as DMZ in your router.

If that solves it, then you know it's a firewall issue and can go from there.

If your SPA-2002 and/or your router it sits behind has UPnP try enabling it.

Thanks for the troubleshooting advice... It is *not* a firewall issue :) It has static IP, @voipinit - you probably mean try disabling it :cool: - it is disabled... The main point is that calls come on ATA's other port without any problems; and if I put "official" Voipo adapter - the calls come fine as well.

I also noticed that my in-laws' calls (in-Voipo network) also always come through; however, non-Voipo calls go to failover number 9 times of 10. So, back to my original question - anybody using BYOD SPA or PAP2-NA to share the experience?

The fact that the Voipo-to-Voipo calls come through and the others don't sounds like a port blocking issue. What happens if you temporairly put the ATA in front of router? Does the issue go away?

tritch,

Thank you for your response. You didn't explain why it sounds to you as port blocking issue - and I can't think of any reason (given other data points that I listed: calls to the other SPA phone port go fine, and calls to Voipo-provided adapter go fine as well).

Regardless, for last two days the incoming calls come fine; so it sounds to me that Voipo fixed something on their BYOD server. If the problem starts again, I'll continue the troubleshooting.

Thanks again for trying to help.

Disregard second half of my last post. The calls started to fall over again. The good part I think I figured the root cause; the bad part - I don't know how to fix it (or even if I can fix it or it is something that only Voipo can fix).

So here it is. On the "good" device I see the following in the "Device" sub tab:

Username: [phone number]
Received: sip:[ip address]:5060
Contact: sip:[phone number]@[ip address]:5060
Connected to: [blank]

However, in the "bad" device I see something different:
Username: [phone number]
Received: sip:[ip address]:5060
Contact: sip:[phone number]@192.168.1.200:5060
Connected to: [blank]

192.168.1.200 is the address of the device on internal LAN.

Interesting that Voipo locked Grandstream gives the following:
Username: [phone number]
Received: sip:[ip address]:5074
Contact: sip:[phone number]@192.168.1.200:5074;user=phone
Connected to: Voipo Central

In other words, Voipo adapter also shows internal LAN IP in Contact field, but it is "connected to" something else.

I don't know what Received and Contact are and what's the difference between the two. Other Voip providers typically show single "registered from" value. So, the question is - is there something that I can set up on the adapter, or is it something that Voipo needs to set up on their end?

I realize that Voipo officially doesn't support BYOD devices; however, SPA/PAP2 are such popular devices and I believe I did my share of troubleshooting - that some semi-official advice might be in order!

Thank you...

More analysis...

When the adapter registers, the incoming calls go to failover number. Once the outgoing call is made, it apparently triggers some kind of registration on voipo server, and after that incoming calls ring the adapter. Registration is valid for 3600 seconds (1 hour); so once adapter re-registers, the server loses track of it - and subsequent calls go to failover number again!

(Since we probably made a lot of outgoing calls, I thought that the problem was fixed).

Any idea what could be causing it on SPA adapter? Again, I don't have this problem on Obi adapter...

Check to see if you have keep alive enabled.

Quote:

---

Originally Posted by burris

Check to see if you have keep alive enabled.

---

YES!!! That was it. Thank you very much... And the most embarrassing part is that I was tinkering with NAT settings, but for whatever stupid reason ended up with keep alive disabled :mad:

FWIW, the screenshot shows both NAT Mapping and NAT keep-alive disabled.
Changing those to Yes (enabled) was what fixed my problem...

So it turned out to be a firewall (port blocking) issue after all........your router's firewall was closing up the UDP ports after a period of inactivity. By enabling the NAT Keep Alive, the ATA keeps the UDP ports open in your router's firewall by periodically sending data packets to the SIP server.

tritch,

I am sure you understand the difference between firewall and NAT functionality (I saw your posts, and I am saying this without any sarcasm). Obviously, there is a firewall on the router, and obviously it blocks all unsolicited incoming traffic. That functionality is expected and doesn't make it a firewall (port blocking) issue.

If I needed to open any ports instead or in addition to make NAT changes in ATA - then it would be a firewall issue. Heck, if I had to make any changes on the router...

But if it makes you feel better - yes, it turned out to be a firewall (port blocking) issue after all and I was an a$$ to not listen to your advice from the very beginning. Should have started tinkering with the router last week - I'd be in much better position now!