Thanks Tim.
Printable View
Thanks Tim.
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.Quote:
Originally Posted by Brian
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.Quote:
Originally Posted by caseydoug
Any news on this, Tim?Quote:
Originally Posted by VOIPoTim
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).Quote:
Originally Posted by VOIPoTim
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.
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.
What ISP and router? What DOCSIS level?Quote:
Originally Posted by Brian
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.Quote:
Originally Posted by usa2k
DOCSIS, not sure, but it's not v3 yet. On a 16/2 link, and that's one of the faster tiers available.
Have you tried running PingPlotter 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.
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'.
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.
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.comQuote:
Originally Posted by holmes4
Another Sunday and the problems are back. This time I have the port fowarding in effect, so it's not my side.
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.Quote:
Originally Posted by sr98user
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).
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.Quote:
Originally Posted by sr98user
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.
Wouldn't setting up the ATA's to use STUN alleviate this need to forward 10's of thousands of ports?
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.
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.
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?Quote:
Originally Posted by sr98user
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:
Quote:
Originally Posted by VOIPoJustin
Quote:
Originally Posted by sr98user
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.
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.
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.Quote:
Originally Posted by sr98user
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/r221...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.
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.
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.
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!)
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)?Quote:
Originally Posted by sr98user
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).
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.
Unfortunately, they can only tell if the SIP port is forwarded. There is no way for us to know if you forwarded all.Quote:
Originally Posted by oldcqr
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.
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