Calls intermittently going directly to voicemail

[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/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.

[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.