Calls intermittently going directly to voicemail

[oldcqr]

Anyone else experiencing incoming calls going directly to voicemail tonight? (4/4/2010 10PM EST)?

I'm calling my voipo line from my cell phone and about 50% of the time it rings. The other half of the time, the call goes directly to voicemail.

Naturally, I've rebooted everything a couple of times....

It's a shame.. Everything had been working for the past 2 weeks, and the service was gaining my trust.

[oldcqr]

Hmmm.....


C:\Users\Mike>tracert sip-central01.voipwelcome.com

Tracing route to sip-central01.voipwelcome.com [174.37.45.134]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms myrouter.home [192.168.1.1]
2 8 ms 6 ms 7 ms L100.TAMPFL-VFTTP-76.verizon-gni.net [96.254.233
.1]
3 9 ms 11 ms 10 ms G3-1-876.TAMPFL-LCR-08.verizon-gni.net [130.81.1
10.228]
4 10 ms 9 ms 9 ms so-6-1-0-0.TPA01-BB-RTR2.verizon-gni.net [130.81
.29.242]
5 68 ms 64 ms 64 ms ge-1-0-0-0.ATL01-BB-RTR2.verizon-gni.net [130.81
.17.48]
6 69 ms 96 ms 72 ms 0.ge-x-x-0.XT2.ATL4.ALTER.NET [152.63.80.13]
7 89 ms 86 ms 87 ms 0.ge-7-2-0.XL4.DFW7.ALTER.NET [152.63.0.54]
8 87 ms 89 ms 86 ms TenGigE0-7-4-0.GW4.DFW13.ALTER.NET [152.63.101.4
9]
9 89 ms 89 ms 89 ms internapGIGE1-gw.customer.alter.net [65.208.15.2
30]
10 87 ms 89 ms 86 ms border3.tge4-1-bbnet2.ext1.dal.pnap.net [216.52.
191.83]
11 91 ms 88 ms 86 ms te2-1.cer03.dal01.dallas-datacenter.com [216.52.
189.30]
12 * 273 ms 209 ms po3.dar01.dal01.dallas-datacenter.com [66.228.11
8.209]
13 86 ms 87 ms 89 ms po1.fcr04.dal01.dallas-datacenter.com [66.228.11
8.214]
14 88 ms 84 ms 86 ms sip-central01.voipwelcome.com [174.37.45.134]

Trace complete.

[usa2k]

The tracert seems to be a strong indicator.


C:\Users\jn\Pictures\dwn>tracert sip-central01.voipwelcome.com

Tracing route to sip-central01.voipwelcome.com [174.37.45.134]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.0.1
2 * * * Request timed out.
3 9 ms 9 ms 8 ms te-8-2-ur02.canton.mi.michigan.comcast.net [68.85.85.89]
4 9 ms 9 ms 9 ms te-9-2-ur02.vanburen.mi.michigan.comcast.net [68.87.190.118]
5 14 ms 13 ms 8 ms te-0-6-0-4-ar01.taylor.mi.michigan.comcast.net [68.87.190.41]
6 23 ms 22 ms 33 ms pos-2-8-0-0-cr01.mclean.va.ibone.comcast.net [68.86.90.105]
7 42 ms 42 ms 42 ms pos-1-10-0-0-cr01.atlanta.ga.ibone.comcast.net [68.86.86.126]
8 67 ms 63 ms 65 ms pos-1-14-0-0-cr01.dallas.tx.ibone.comcast.net [68.86.85.153]
9 62 ms 61 ms 62 ms pos-0-0-0-0-pe01.1950stemmons.tx.ibone.comcast.net [68.86.86.90]
10 64 ms 63 ms 64 ms softlayer-cr01.dallas.tx.ibone.comcast.net [75.149.228.34]
11 63 ms 75 ms 63 ms po2.dar02.dal01.dallas-datacenter.com [66.228.118.207]
12 63 ms 64 ms 61 ms po2.fcr04.dal01.dallas-datacenter.com [66.228.118.218]
13 64 ms 63 ms 64 ms sip-central01.voipwelcome.com [174.37.45.134]

Trace complete.Looking fine at the moment from my direction (Canton, MI)
I don't pass through that router.

I suggest to submit a ticket

[oldcqr]

I've done several now, and about 1/2 the time they go south. And when they do it is at hop 12.


1 1 ms 2 ms 1 ms myrouter.home [192.168.1.1]
2 7 ms 7 ms 9 ms L100.TAMPFL-VFTTP-76.verizon-gni.net [96.254.233
.1]
3 10 ms 11 ms 11 ms G3-1-876.TAMPFL-LCR-08.verizon-gni.net [130.81.1
10.228]
4 12 ms 12 ms 9 ms so-6-1-0-0.TPA01-BB-RTR2.verizon-gni.net [130.81
.29.242]
5 66 ms 64 ms 64 ms ge-1-0-0-0.ATL01-BB-RTR2.verizon-gni.net [130.81
.17.48]
6 66 ms 66 ms 67 ms 0.ge-x-x-0.XT2.ATL4.ALTER.NET [152.63.80.13]
7 83 ms 86 ms 83 ms 0.ge-7-2-0.XL4.DFW7.ALTER.NET [152.63.0.54]
8 92 ms 84 ms 89 ms TenGigE0-7-1-0.GW4.DFW13.ALTER.NET [152.63.101.2
5]
9 83 ms 84 ms 87 ms internapGIGE1-gw.customer.alter.net [65.208.15.2
30]
10 88 ms 89 ms 91 ms border3.tge4-1-bbnet2.ext1.dal.pnap.net [216.52.
191.83]
11 82 ms 81 ms 82 ms te2-1.cer03.dal01.dallas-datacenter.com [216.52.
189.30]
12 87 ms 86 ms * po3.dar01.dal01.dallas-datacenter.com [66.228.11
8.209]
13 86 ms 85 ms 88 ms po1.fcr04.dal01.dallas-datacenter.com [66.228.11
8.214]
14 87 ms 87 ms 87 ms sip-central01.voipwelcome.com [174.37.45.134]

[scott2020]

I've done several now, and about 1/2 the time they go south. And when they do it is at hop 12.


1 1 ms 2 ms 1 ms myrouter.home [192.168.1.1]
2 7 ms 7 ms 9 ms L100.TAMPFL-VFTTP-76.verizon-gni.net [96.254.233
.1]
3 10 ms 11 ms 11 ms G3-1-876.TAMPFL-LCR-08.verizon-gni.net [130.81.1
10.228]
4 12 ms 12 ms 9 ms so-6-1-0-0.TPA01-BB-RTR2.verizon-gni.net [130.81
.29.242]
5 66 ms 64 ms 64 ms ge-1-0-0-0.ATL01-BB-RTR2.verizon-gni.net [130.81
.17.48]
6 66 ms 66 ms 67 ms 0.ge-x-x-0.XT2.ATL4.ALTER.NET [152.63.80.13]
7 83 ms 86 ms 83 ms 0.ge-7-2-0.XL4.DFW7.ALTER.NET [152.63.0.54]
8 92 ms 84 ms 89 ms TenGigE0-7-1-0.GW4.DFW13.ALTER.NET [152.63.101.2
5]
9 83 ms 84 ms 87 ms internapGIGE1-gw.customer.alter.net [65.208.15.2
30]
10 88 ms 89 ms 91 ms border3.tge4-1-bbnet2.ext1.dal.pnap.net [216.52.
191.83]
11 82 ms 81 ms 82 ms te2-1.cer03.dal01.dallas-datacenter.com [216.52.
189.30]
12 87 ms 86 ms * po3.dar01.dal01.dallas-datacenter.com [66.228.11
8.209]
13 86 ms 85 ms 88 ms po1.fcr04.dal01.dallas-datacenter.com [66.228.11
8.214]
14 87 ms 87 ms 87 ms sip-central01.voipwelcome.com [174.37.45.134]



I see the same latency from Missouri on that same router hop. I can't get my trace to paste in for some reason!

It isn't every time, about half I suppose.

[oldcqr]

The tracert and ping are looking much better, but I'm still going to voicemail 1/2 the time.

Ugh. Ticket time.


Edit: Nope, I take that back. The latency looks better, but sure enough hop 12 is still dropping packets.

[Russell]

The tracert and ping are looking much better, but I'm still going to voicemail 1/2 the time.

Ugh. Ticket time.


Edit: Nope, I take that back. The latency looks better, but sure enough hop 12 is still dropping packets.

I too have had flaky service the past several days. Example: I got a call two minutes ago and only line 1 rang. Could well be related to what I describe in http://forums.voipo.com/showthread.php?t=2323.

[gigaman]

I'm seeing the same issue....both yesterday and today....some calls going directly to vmail.

[oldcqr]

Support swapped me to a different server and then once again had me forward every UDP port from 5004 to 65535. I did so, but by that time things were working fine on their own.

The next day everything was still working, so I removed the port forwarding as a test. As of right now everything is working well. It's definately something outside of my network/configuration/etc.

[scott2020]

VOIPo had some connectivity issues yesterday in the afternoon I believe. It wasn't posted here (since forums were down), only on Twitter I believe. I don't do Twitter but someone told me about it. It seems Dallas gets hit a lot with latency from wherever in the world, and VOIPo has a lot of "stuff" in Dallas. I seem to remember Tim mentioning enhancements coming soon, which will be nice considering Dallas seems to get hammered a lot.

[holmes4]

According to the Twitter feed, the connectivity issue affected only the web site and control panel, not the service itself.

[VOIPoTim]

According to the Twitter feed, the connectivity issue affected only the web site and control panel, not the service itself.

That's correct. Service failed over within minutes, but the web server for the site and vPanel had issues being brought back online.

[lost_]

Callers were getting fast busy on incoming calls to my add-on line today from around noon for a few hours. Outgoing calls were ok, and rebooting the ATA didn't solve it, though the vpanel showed the device registered to East. My primary line worked fine during that time.

EDIT: VM is disabled on my add-on line. I wonder if it would've gone to it instead of fast busy.

[VOIPoTim]

Callers were getting fast busy on incoming calls to my add-on line today from around noon for a few hours. Outgoing calls were ok, and rebooting the ATA didn't solve it, though the vpanel showed the device registered to East. My primary line worked fine during that time.

EDIT: VM is disabled on my add-on line. I wonder if it would've gone to it instead of fast busy.

No issues today at all and tickets were very light.

Do you have all the port forwarding setup? Ports 5004-65000 UDP need to be forwarded to the adapter.

[lost_]

By the time I posted above, the problem already disappeared without any changes on my end -- not even any router or ATA restart. Weird.

(I didn't want to open a ticket during the problem period because outgoing still worked and I needed to make outgoing calls from that line)

[Russell]

I've had another call go to voicemail this morning. And, a call a minute later come through fine. It may be related to http://forums.voipo.com/showthread.php?p=17980#post17980.

[bill875]

I've been intermittently having calls go directly to my failover number which is my cell phone. This seems to mostly be calls coming from the 608 area code (Central Wisconsin).

[VOIPoTim]

If you have the VOIPo device connected to a router or a modem with a built in router, it's very important to have ports 5004-65000 forwarded on your router when using VOIPo service in order to be sure to receive all calls. For those of you having issues, please be sure to have those forwarded. Support can help you if you don't know how to setup the forwarding.

If you still have issues AFTER forwarding, contact support for further assistance for further troubleshooting. There are other things we can do such as increasing your "re-registration" interval which is making your device connect to us more often.

[Russell]

If you have the VOIPo device connected to a router or a modem with a built in router, it's very important to have ports 5004-65000 forwarded on your router when using VOIPo service in order to be sure to receive all calls. For those of you having issues, please be sure to have those forwarded. Support can help you if you don't know how to setup the forwarding.

If you still have issues AFTER forwarding, contact support for further assistance for further troubleshooting. There are other things we can do such as increasing your "re-registration" interval which is making your device connect to us more often.

Tim, I've been having a variety of issues recently. Calls going to voicemail; if I'm on the phone then the second line does not ring (if I'm not, both lines ring), etc. If a call goes to voicemail, calling again will let the call come through fine. Nothing has changed on my side except I've noticed that my UVerse router has upgraded it's firmware. In the "old" router it was clear how to disable SIP ALG. In the "new" router it's not clear - I just don't see a checkbox (the screens are completely different). I believe Brandon has UVerse and I was hoping he had the new firmware and could shed some light on this setting (see http://forums.voipo.com/showthread.php?t=2333).

Btw, can you post a cheat sheet on how to forward the ports on UVerse's RG? I guess I can put the adapter in the DMZ and it'll get everything, but if you can post the instructions support uses to help folks with UVerse do the forwarding, I'll be happy to do it myself rather than DMZ it. Of course if I have a SIP ALG issue, will forwarding solve the problem?

Btw, why do you use such a wide range of ports on the customer side. If I remember how this works there's a port on the your side and a port on the customer side and packets get exchanged between them - while I can understand your servers using a wide range of ports (on the server side) to service multiple customers at the same time can't the servers talk to a narrower range on the customer side?

[VOIPoTim]

Tim, I've been having a variety of issues recently. Calls going to voicemail; if I'm on the phone then the second line does not ring (if I'm not, both lines ring), etc. If a call goes to voicemail, calling again will let the call come through fine. Nothing has changed on my side except I've noticed that my UVerse router has upgraded it's firmware. In the "old" router it was clear how to disable SIP ALG. In the "new" router it's not clear - I just don't see a checkbox (the screens are completely different). I believe Brandon has UVerse and I was hoping he had the new firmware and could shed some light on this setting (see http://forums.voipo.com/showthread.php?t=2333).

Btw, can you post a cheat sheet on how to forward the ports on UVerse's RG? I guess I can put the adapter in the DMZ and it'll get everything, but if you can post the instructions support uses to help folks with UVerse do the forwarding, I'll be happy to do it myself rather than DMZ it. Of course if I have a SIP ALG issue, will forwarding solve the problem?

Btw, why do you use such a wide range of ports on the customer side. If I remember how this works there's a port on the your side and a port on the customer side and packets get exchanged between them - while I can understand your servers using a wide range of ports (on the server side) to service multiple customers at the same time can't the servers talk to a narrower range on the customer side?

I'll see what I can find on U-Verse. I don't know it off the top of my head, but will ask some of our guys Monday.

The port range is not really our range. Audio does not go through VOIPo at all except in very special cases. The audio connects directly from our CLEC partners that completely the call to the ATA and that is the range they all use. We use 5060-5080 for communication between our servers, but if the audio stream can't start from the CLEC gateways on one of the other ports, the call will still fail.

[lost_]

If you have the VOIPo device connected to a router or a modem with a built in router, it's very important to have ports 5004-65000 forwarded on your router when using VOIPo service in order to be sure to receive all calls.

Tim, is 5004-65000 the new, recommended UDP port forwarding range? Previously, the common recommendation for UDP port forwarding was 35000-65000 (http://forums.voipo.com/showpost.php?p=15002&postcount=4), and 5060-5080 TCP/UDP.

[VOIPoTim]

Tim, is 5004-65000 the new, recommended UDP port forwarding range? Previously, the common recommendation for UDP port forwarding was 35000-65000 (http://forums.voipo.com/showpost.php?p=15002&postcount=4), and 5060-5080 TCP/UDP.

Yes, this is the new range we are recommending. It's the range our CLEC partners use for media now.

[zcnkac]

Aren't these ports what the CPE (linksys/grandstream) selects for the local media stream, rather than what the CLEC media server use ? Linksys by default uses - 16384-16482. Usually only these ports need to be forwarded. In another thread someone mentioned that the router might map the ports to something else externally and therefore a lot more ports need to be forwarded.

I have Asterisk and limit it to ports 14020-14030. I have a Linksys WRT running Tomato and forward only these ports.

[VOIPoTim]

Aren't these ports what the CPE (linksys/grandstream) selects for the local media stream, rather than what the CLEC media server use ? Linksys by default uses - 16384-16482. Usually only these ports need to be forwarded. In another thread someone mentioned that the router might map the ports to something else externally and therefore a lot more ports need to be forwarded.

I have Asterisk and limit it to ports 14020-14030. I have a Linksys WRT running Tomato and forward only these ports.

I guess it depends on router, but am not 100% sure of the technical reasoning. What I do know is that most of the time when people report issues and we check logs, we see the traffic coming in from the remote media gateway on a port within to 5004-65000 range and the router blocking it or misrouting it. Some routers let it through, but the ones that analyze it sometimes see the connection as "unknown" since it's from a different IP on a port not already being used, etc.

[Brian]

I guess it depends on router, but am not 100% sure of the technical reasoning. What I do know is that most of the time when people report issues and we check logs, we see the traffic coming in from the remote media gateway on a port within to 5004-65000 range and the router blocking it or misrouting it. Some routers let it through, but the ones that analyze it sometimes see the connection as "unknown" since it's from a different IP on a port not already being used, etc.

I guess, since it's not within VOIPo's network, it isn't possible to narrow this range down, or specific ports? What do those of us with multiple VOIP providers/lines do?

[stevech]

For my ATA connected on the LAN side of the router, why do I not need to do port forwarding for VoIP? I do have a couple of servers: HTTP and IP cameras with single ports forwarded.

[Russell]

I guess, since it's not within VOIPo's network, it isn't possible to narrow this range down, or specific ports? What do those of us with multiple VOIP providers/lines do?
I would agree with Brian. That's a huge range to open. It really does not matter what port the CLEC uses - it's what port the CLEC is trying to access on the ATA on our (customer) side and only those ports need to be forwarded. For one provider to hog a range that wide is (in my opinion) unreasonable. Surely you can work with your partners that they use a certain range for VOIPo customers? As I previously mentioned: my basic understanding is that there is a port/ports on the CLEC side and a port/ports on the customer side that talk to each other and while the CLEC gateway could be talking to many many customers and so will need a wide range of ports in operation on the CLEC side, they can still target a narrow range on the customer side.

[holmes4]

In particular, that port range overlaps ranges used by other services.

[caseydoug]

I guess, since it's not within VOIPo's network, it isn't possible to narrow this range down, or specific ports? What do those of us with multiple VOIP providers/lines do?

I would carve out the assignments for other devices, and give the rest over to VOIPo. For example, I have several other adapters, for both voice and security, which I assign ports 5060, 5061, 5063, 5065, etc. VOIPo's two lines get 5079 and 5080. Ports in the 5060-5080 range must be assigned to the appropriate VoIP adapter for signaling. But I can still assign 35000-65000 to VOIPo for RTP (audio), and it does not seem to interfere with the other devices. I suppose I could also extend that to 5081-65000 if I were having problems with my VOIPo line.

I also have other devices, such as a Slingbox and a digital audio server (or I occasionally run servers such as HTTP or Remote Desktop), which require that I forward other ports. These are generally TCP ports, however, so they don't interfere.

The point is that if you need to forward other ports for other purposes, do it, but give VOIPo as many of the UDP ports between 5004 and 65000 as you can. The chances are pretty slim that the ports you have forwarded to other adapters will ever be needed by VOIPo.

[voipinit]

That does seem like a huge range to open unnecessarily. My ATA is behind my router and I don't forward any ports, also have my router SPI firewall enabled and rely on a STUN server to open the appropriate ports.

[MisterEd]

In my case changing the ports to what Tim suggested resolved ALL the "no audio" problems I had been having for months <knock wood>. Haven't had a single occurrence since I changed them. <knock more wood, plastic and galvanized steel>

I'm on Fios with a Buffalo router running DD-WRT.

[VOIPoTim]

In my case changing the ports to what Tim suggested resolved ALL the "no audio" problems I had been having for months <knock wood>. Haven't had a single occurrence since I changed them. <knock more wood, plastic and galvanized steel>

I'm on Fios with a Buffalo router running DD-WRT.

Yeah we are hearing this a lot not. One thing about your situation too is that you had A LOT of VOIPo problems with multiple routers to the point that you were ready to cancel even though you had the smaller range 5060-5080 and 35000-65000 forwarded, but the full range resolved them all.

We've had quite a few cases of this were that range solved everything and it's the range our CLEC partners recommend, so we're just going with what works so people can get the quickest resolution possible.

[tritch]

I agree. I haven't had any issues since forwarding these ports over a year ago. Initially, my router (Linksys WRT350N) was blocking ports and causing all sorts of strange audio problems (dead air, etc.). The SPI firewall on some routers can be problematic. I've since purchased another router, but have forwarded these ports as well just to avoid any potiential issues. Other than a few glitches with my ISP and minor Voipo datacenter issues, the service has been working great since Feb 09.

DSL modem bridged
Buffalo WZR-HP-G300N (stock firmware)
static IP assigned to ATA
UDP ports 5000-65000 forwarded to ATA's static IP

[caseydoug]

Yeah we are hearing this a lot not. One thing about your situation too is that you had A LOT of VOIPo problems with multiple routers to the point that you were ready to cancel even though you had the smaller range 5060-5080 and 35000-65000 forwarded, but the full range resolved them all.

We've had quite a few cases of this were that range solved everything and it's the range our CLEC partners recommend, so we're just going with what works so people can get the quickest resolution possible.

Tim, what about Brian's question regarding other devices that need specific ports forwarded? Do you agree that it's OK to give those devices the ports they need, but then to forward to VOIPo as many other ports in that range as possible? The way I figure it, it's a question of probabilities. There is only a small chance that any particular port in that range will be needed by VOIPo (except, of course, the local port used for SIP signaling), so the more ports you can forward, the lower the probability that the audio will be blocked or get lost.

[VOIPoTim]

Tim, what about Brian's question regarding other devices that need specific ports forwarded? Do you agree that it's OK to give those devices the ports they need, but then to forward to VOIPo as many other ports in that range as possible? The way I figure it, it's a question of probabilities. There is only a small chance that any particular port in that range will be needed by VOIPo (except, of course, the local port used for SIP signaling), so the more ports you can forward, the lower the probability that the audio will be blocked or get lost.

That should be fine to forward ports you use.

I guess the best way to explain it is that while it's true the ATA and router can be setup to communicate on certain ports, if an audio stream comes into your IP on one of the ports we use and the router doesn't know what it is or where it goes, it wouldn't know to get it to the ATA in the first place so the ports the ATA use are not really even in the picture. With the forwarding it just directs all the traffic in those port ranges to the ATA regardless.

This setup is a little different since we don't handle audio. Some providers proxy 100% of the audio through their systems so it comes from the same IPs the router already knows are communicating with the ATA.

[tritch]

Caseydoug, your previous post on page 3 seems appropriate.

Carve out as much of a port range for Voipo's ATA that you can and hopefully this will not interfere with any other devices that maybe in this port range. I'd estimate the majority of people out there (95% or more) do not have other devices that conflict with UDP 5000-65000. They'll just have to experiment and see what works.......

[Brian]

BTW, the ports in question - are they UDP only?

[VOIPoTim]

BTW, the ports in question - are they UDP only?

Yeah, we are UDP only.

There's no need to forward TCP and most other things you guys might use on those ports are likely TCP.

[Brian]

Yeah, we are UDP only.

There's no need to forward TCP and most other things you guys might use on those ports are likely TCP.

Cool. How about people w/multiple VOIPo adapters?

Also, would it be simpler just to put the device in the router's DMZ?:)

[VOIPoTim]

Cool. How about people w/multiple VOIPo adapters?

Also, would it be simpler just to put the device in the router's DMZ?:)

When multiple adapters are involved, a router that properly handles things is really recommended.

We don't recommend DMZ because newer routers don't have a true DMZ mode and still filter the traffic. They make them so complicated these days.

[Brian]

Thanks Tim.

[caseydoug]

Cool. How about people w/multiple VOIPo adapters?

Also, would it be simpler just to put the device in the router's DMZ?:)
Putting the device in the router's DMZ will prevent the router from blocking the ports. The biggest problem, however, is not that the router is blocking the ports, but that the router doesn't know what port to send the packet to, so the packet gets lost, not blocked.

I am not an expert on SIP protocol, but I thought it was part of the SIP call setup for the adapter and the server to determine what RTP port would be used, at least initially. Why doesn't this apply even when VOIPo does not proxy its own audio?

[VOIPoTim]

Putting the device in the router's DMZ will prevent the router from blocking the ports. The biggest problem, however, is not that the router is blocking the ports, but that the router doesn't know what port to send the packet to, so the packet gets lost, not blocked.

I am not an expert on SIP protocol, but I thought it was part of the SIP call setup for the adapter and the server to determine what RTP port would be used, at least initially. Why doesn't this apply even when VOIPo does not proxy its own audio?

I'm not sure of the specifics, but all I know is that most newer routers handle the traffic incorrectly and in our logs we see it blocked at the router when people report those issues. Old routers handle it perfectly fine. New ones try to do all this crazy stuff and analyze/rewrite/direct every single packet and do it incorrectly most of the time.

[Russell]

I'll see what I can find on U-Verse. I don't know it off the top of my head, but will ask some of our guys Monday.

Any news on this, Tim?

[MisterEd]

Yeah we are hearing this a lot not. One thing about your situation too is that you had A LOT of VOIPo problems with multiple routers to the point that you were ready to cancel even though you had the smaller range 5060-5080 and 35000-65000 forwarded, but the full range resolved them all.

We've had quite a few cases of this were that range solved everything and it's the range our CLEC partners recommend, so we're just going with what works so people can get the quickest resolution possible.

I may try going back to my "official" Fios Actiontec router with the proper ports opened and see if the problem recurrs again. Never tried it that way. As much as I like the Buffalo/DD-WRT better I'd have to use the Actiontec if I eventually want to switch to Fios TV (currently I use DirecTV).

[Brian]

I finally broke down and put the forwarding in place. I'm not convinced this will fix the specific issue I'm having (a specific number gets VM more than not when calling me - calls don't go to failover, but straight to VM), but it's worth a try. I'm running DD-WRT, which I didn't think was impacted as much as some other routers by this bug. The strange thing is this has only started happening in the last 2 weeks or so. I put a ticket in to see i there's anything odd with the last call where this happened, so we'll see, I guess.

[lost_]

True, I have those ports forwarded, but still get fast busy intermittently. My VOIPo VM is turned off, because GV forwards to my VOIPo number. During the past week, I'd get GV SMS/email VM notification while my VOIPo phone never rang. I would immediately check by calling my VOIPo number from my cell and get the fast busy.

It's hard to file a ticket on this, because no call log shows up, and the problem is intermittent.

[usa2k]

I finally broke down and put the [port] forwarding ... I'm running DD-WRT ...What ISP and router? What DOCSIS level?

[Brian]

What ISP and router? What DOCSIS level?

Comcast, Buffalo WHR-G125, I believe (not at home to check), DD-WRT, not sure the version off the top of my head but one of the more recent releases.

DOCSIS, not sure, but it's not v3 yet. On a 16/2 link, and that's one of the faster tiers available.

[ctaranto]

Have you tried running PingPlotter (http://www.pingplotter.com) on the voipwelcome server that you're configured to use? Getting a history the connectivity between you, the ISP, and VOIPo may point to something.

If you're interested, set the check interval to 2.5 seconds and let it run for a few days.

[oldcqr]

I'm glad this isn't just me, and that I'm not the only one who things forwarding 60K+ ports is 'over the top'.

[sr98user]

If you know exactly how your router translates your internal ports on the WAN side, then you can narrow down the port forwarding range. But in most routers, you don't have access to the Network Address Translation (NAT) table to see what the port numbers are on the WAN side. Hence the big range.

[holmes4]

How do you figure out the name of the VOIPo server you're using? I can see that I am on "Central" but that doesn't translate to a hostname.

[burris]

How do you figure out the name of the VOIPo server you're using? I can see that I am on "Central" but that doesn't translate to a hostname.

sip-central01.voipwelcome.com

[oldcqr]

Another Sunday and the problems are back. This time I have the port fowarding in effect, so it's not my side.

[Russell]

If you know exactly how your router translates your internal ports on the WAN side, then you can narrow down the port forwarding range. But in most routers, you don't have access to the Network Address Translation (NAT) table to see what the port numbers are on the WAN side. Hence the big range.

I don't quite get your explanation. Essentially, the "media gateway" is choosing a port in the 60+K range and sending UDP packets to your public IP address at that port. You don't have control over which port the "media gateway" chooses. You have no option but to forward all the ports in that range. It really doesn't matter what internal mapping of ports your NAT router does to avoid conflict - it's still getting packets at that external UDP port.

I do agree with others (and I've said the same) that the wide port range is "unreasonable". I'd urge Tim, as VOIPo grows and he gives more business to the "media gateways", to exert leverage over them and get them to use a narrower range for VOIPo customers. After all the "media gateways" just needs a single port on our public IP (based on a post of Justin from some time back).

[sr98user]

Russell,

I am not an expert in SIP but I am quite familiar with my router. Atleast for me, the port is selected by my ATA to be in the 16384-16482 range for RTP and 5061-5062 for SIP. My router maps these to the same port numbers on the public side unless that port is being used by someone else. From what I see, the port is not selected by the media gateway.

The destination port of media gateway could be anything. But we are forwarding incoming data to the ATA. So, port number on the media gateway side does not affect port forwarding.

[Russell]

Russell,

I am not an expert in SIP but I am quite familiar with my router. Atleast for me, the port is selected by my ATA to be in the 16384-16482 range for RTP and 5061-5062 for SIP. My router maps these to the same port numbers on the public side unless that port is being used by someone else. From what I see, the port is not selected by the media gateway.

The destination port of media gateway could be anything. But we are forwarding incoming data to the ATA. So, port number on the media gateway side does not affect port forwarding.

sr98, I too am not a SIP expert. I'm just looking at the facts: VOIPo wants us to open up 60+K ports on our firewalls and send traffic on those ports to the ATA. In other words, the media gateway can target one of those 60K ports on your public IP. And, if your ATA was (hypothetically) directly connected to your (hypothetical) non-router broadband modem the media gateway would be directly addressing one port in that 60K port range on your ATA. Correct? Perhaps someone from VOIPo can explain the 16384-16482 range for RTP seen on the ATA with this 60K range requirement.

[VOIPoBrandon]

the 16384-16482 port range is source ports when placing an outbound call.

The 5004-65000 port range is source ports when receiving an incoming call.

[voipinit]

Wouldn't setting up the ATA's to use STUN alleviate this need to forward 10's of thousands of ports?

[sr98user]

I just made an incoming call. Here is my NAT entry..

udp <public_ip>:16422 <internal_ip>:16422 209.244.31.1:61094 209.244.31.1:61094

Then I placed a outgoing call. Here is the NAT entry for that.

udp <public_ip>:16426 <internal_ip>:16426 64.35.56.74:14014 64.35.56.74:14014

The format is as follows..
Protocol Inside_global Inside_local Outside_local Outside_global

My earlier point was.. It depends on the router on how port is translated. Even in my case, if the 16422 was used by another IP in my LAN then the public port will be different. With my router if that happens, then the public port will be starting from around 1000.

Since VOIPo customers will have various routers and different routers will do the mapping differently, Voipo has to cover the entire range. Even if I did port forwarding, Voipo range will fail in my case if there is a port conflict with another IP in my node. Since my router will use unused port numbers starting from 1000 and this is not in the in the 5004-65000 range.

voipinit,

STUN is useful only when you need NAT mapping. The issue here is when the router rejects packets from the media gateway (different from your SIP server), various issues crop up.

[Russell]

What really puzzles me about this whole port-forwarding thing is ... does this mean that one cannot have two VOIPo adapters (say for two distinct phone numbers, each having two lines) reliably function in the same household? With the way most consumer routers are set up one will not be able to forward those 60K ports to both routers.

[sr98user]

I think you are right. If you have to do port forwarding and forward the entire range, I assume you can't have two adapters behind your router. Also, there could be other applications that are using UDP ports in that range. PAP2 provides the fields for RTP port range. You could set the port range different for different adapters. Even with that port forwarding depends on the way your router translates the port numbers.

[Russell]

I think you are right. If you have to do port forwarding and forward the entire range, I assume you can't have two adapters behind your router. Also, there could be other applications that are using UDP ports in that range. PAP2 provides the fields for RTP port range. You could set the port range different for different adapters. Even with that port forwarding depends on the way your router translates the port numbers.
As Brandon mentioned the PAP2 RTP port range is used for outgoing calls only. So, I'm not sure if setting different ranges will affect incoming - incoming is up to the "media gateway" to pick a port from the 60K range. We don't know as to exact mechanics of how setup works - not sure how the incoming port is picked. Does each gateway pick a destination port using some internal algorithm (with no negotiation with your router) and start sending UDP packets to your public IP at that port?

[tritch]

For those who are reluctant to open this port range or have other devices that may conflict, the solution may be to have Voipo directly handle your audio instead of the media gateways. It's possible they may use a specific port or smaller port range for RTP traffic. A quick question to support should answer this. The only drawback is that it may increase your latency as quoted by one of Voipo's staffers below:


Another thing to keep in mind -- while having VOIPo handle your audio directly does ensure the quality of data; it can sometimes come at the expense of increased latency with the RTP transmission (in situations where a terminating media gateway is significantly closer from a geographical perspective).

[voipinit]

voipinit,

STUN is useful only when you need NAT mapping. The issue here is when the router rejects packets from the media gateway (different from your SIP server), various issues crop up.


I currently am using symmetric NAT (STUN) and don't forward any ports and don't have issues. I will have to have to try port forwarding again without STUN, just for kicks. In the past when I tried I reliably got one-way audio (100% of the time), but didn't open up the 60K+ ports, but this is prior to the 60K + port forwarding requirement. We shall see.

[sr98user]

Russell,

Maybe I was not clear when I listed my NAT entries. My ATA uses 16384-16482 for both incoming and outgoing calls. It just increases by 4 after each call to get the next port number and cycles through the range again. I think this port number is communicated through the SIP packets. The adapter probably finds out the translated port number using STUN server if its used. I don't know a lot about how its communicated to the media gateway. The translated port number on the public side could be different depending on the router.

[VOIPoTim]

The translated port number on the public side could be different depending on the router.

The problem is that the majority of new routers don't handle the negotiation correctly and the ports are mixed up. So if the router is not expecting a connection on a given port, it will reject the incoming connection. Some routers do this properly, but it's rare to see it.

In theory users should not need ports forwarded, but again 99% of the time when we see the issues like this in logs, the logs for the user show that the packets were rejected by the router which in turn sent an error code back and it was passed upstream generating a drop to fast busy, disconnected, etc.

So you're correct that in theory, the routers should be able to negotiate. Most new ones rewrite all packets though and don't do it correctly so the ports aren't correct. Since this changes even with router firmwares (and we've learned most new routes auto update themselves), we can't really track which routers handle it properly and which don't (especially since we'd have to track every single firmware version too).

We don't provide networking support and recommend using connect our devices directly to their modems and bypass their consumer router and use the router built into the adapters. When they have issues that are 100% caused by a consumer router, we have to take the most direct approach to resolve the issues for our service. In this situation, it's to forward the entire range since that is effective 100% of the time.

Should users need to do it? No. As long as router manufacturers continue on the path they are on with adding all this unnecessary stuff (like SIP ALG, filtering every single packet and rewriting incorrect, etc), forwarding will eventually be needed by everyone or someone is going to have to invent workarounds.

Here is a perfect example where the stock Linksys router firmware for a brand new router completely breaks VoIP service and the user experienced all the standard router issues commonly caused by a consumer router (things like dropped calls, no audio, disconnected messages, missed calls, etc). Swapping to a firmware that handled it correctly and 100% of the issues were gone.

http://www.dslreports.com/forum/r22179978-VoIPo-If-you-have-a-Linksys-router

Router manufacturers are making things more and more difficult every day. Today I actually tell our team that the #1 thing that can make or break a user's VoIP experience is their router. It's no longer the internet connection because nearly all of those are fine for VoIP, but the majority of new routers require tweaking.

[voipinit]

Just discovered my routers UPnP feature when enabled opens the necessary ports. So for my router, as long as UPnP is enabled, I don't need to forward any ports.

[holmes4]

I'd love to put my RTP312 outside my router - unfortunately, it just doesn't work when I do that, and support told me to put it behind the router.

[usa2k]

Granted this is related to OLD threads
http://www.dslreports.com/forum/remark,13561259
There have been modems that were the route cause of VoIP issues too.
(No pun intended!)

[Russell]

Russell,

Maybe I was not clear when I listed my NAT entries. My ATA uses 16384-16482 for both incoming and outgoing calls. It just increases by 4 after each call to get the next port number and cycles through the range again. I think this port number is communicated through the SIP packets. The adapter probably finds out the translated port number using STUN server if its used. I don't know a lot about how its communicated to the media gateway. The translated port number on the public side could be different depending on the router.

Yes, there are a lot of missing pieces of the puzzle which folks like me don't understand - e.g. what kind of negotiation of port number takes place. And, now that Tim has mentioned that "old" routers (which don't do any of the new fangled stuff work fine), how exactly do those routers know to let audio traffic from the media gateway in (e.g. is the ip address of the media gateway - different from the SIP server - part of the information that is exchanged in the negotiation)?

I have a really old router which worked fine with many VOIP companies and also with VOIPo until a couple of weeks ago. At that time I port forwarded. I'm tempted to undo port forwarding and restart all pieces after reading Tim's comment that old routers should work fine. Unfortunately, the wife volunteers three evenings this week and the phone needs to be "perfect" for any incoming calls - so it'll be next weekend before any such experiment.

My router does not appear to let me specify what type of traffic to forward - so presumably it's forwarding both TCP and UDP (and not just UDP).

[oldcqr]

I am getting very frustrated.

I find myself now needing to 'test' my service every few hours to ensure that it is working. Many times it is not. Today I find I am once again going directly to voicemail. Fri/Sat I was having problems with outgoing calls.

Most frustrating of all is that it appears that no one is even researching my problems. The ticket over the weekend was replied to with the 'forward all the ports' reply. I've had the port forwarding in place for several weeks now.

I know the Voipo staff can tell if the ports are forwarded or not, since they caught that I had not forwarded them on a previous ticket (I had the entry but forgot to enable it). That tells me the rep didn't even bother to check anything.

[VOIPoTim]

I know the Voipo staff can tell if the ports are forwarded or not, since they caught that I had not forwarded them on a previous ticket (I had the entry but forgot to enable it). That tells me the rep didn't even bother to check anything.

Unfortunately, they can only tell if the SIP port is forwarded. There is no way for us to know if you forwarded all.

If it has ALG or a SPI firewall, these will also likely need to be disabled.

I know it's frustrating, but unless the router allows the traffic through fully, there's not much we can do on our end. We can't really force your router let traffic through from our end. We're happy to help you review the router configuration to see what can be adjusted to open it up.

If you have a ticket number, I'm happy have a Tier II rep contact you to review your router settings.

[oldcqr]

I just opened up remote administration to my router, and placed the information into the ticket I have open for your support to access it.

PPV-307843