Printable View
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.
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.
The tracert seems to be a strong indicator.
Looking fine at the moment from my direction (Canton, MI)Code: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.
I don't pass through that router.
I suggest to submit a ticket
I've done several now, and about 1/2 the time they go south. And when they do it is at hop 12.
Code: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]
Quote:
Originally Posted by oldcqr
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.
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.Quote:
Originally Posted by oldcqr
I'm seeing the same issue....both yesterday and today....some calls going directly to vmail.
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.
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.
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.Quote:
Originally Posted by holmes4
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.Quote:
Originally Posted by lost_
Do you have all the port forwarding setup? Ports 5004-65000 UDP need to be forwarded to the adapter.
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)
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.p...7980#post17980.
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).
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).Quote:
Originally Posted by VOIPoTim
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.Quote:
Originally Posted by Russell
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.
Tim, is 5004-65000 the new, recommended UDP port forwarding range? Previously, the common recommendation for UDP port forwarding was 35000-65000, and 5060-5080 TCP/UDP.Quote:
Originally Posted by VOIPoTim
Yes, this is the new range we are recommending. It's the range our CLEC partners use for media now.Quote:
Originally Posted by lost_
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.Quote:
Originally Posted by zcnkac
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?Quote:
Originally Posted by VOIPoTim
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.
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.Quote:
Originally Posted by Brian
In particular, that port range overlaps ranges used by other services.
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.Quote:
Originally Posted by Brian
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.
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.
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.Quote:
Originally Posted by MisterEd
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 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
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.Quote:
Originally Posted by VOIPoTim
That should be fine to forward ports you use.Quote:
Originally Posted by caseydoug
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.
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.......
BTW, the ports in question - are they UDP only?
Yeah, we are UDP only.Quote:
Originally Posted by Brian
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?Quote:
Originally Posted by VOIPoTim
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.Quote:
Originally Posted by Brian
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.