Q on VoIPo SIP outbound vs. router

[sr98user]

If you are getting 3 per minute, its probably the keep alive packets from the ATA to the SIP server to keep the UDP NAT entries alive. I am not sure why your router is blocking that traffic. Does it give any reason at all? What router do you have?

Depending on the NAT entry timeout for the UDP packets, you could increase the keep alive interval. To do that, you would need to the timeout or should be able to configure it.

[stevech]

If you are getting 3 per minute, its probably the keep alive packets from the ATA to the SIP server to keep the UDP NAT entries alive. I am not sure why your router is blocking that traffic. Does it give any reason at all? What router do you have?

Depending on the NAT entry timeout for the UDP packets, you could increase the keep alive interval. To do that, you would need to the timeout or should be able to configure it.

I am seeing my router's log (Cradlepoint MBR900) filled with rejected incoming packets from VoIPo's SIP servers. Also, my ATA's ALG function is trying to send SIP packets out but the router log says it did not forward, apparently because the Grandstream's SIP packet is not formatted properly according to the Cradlepoint.

[voipinit]

... Also, my ATA's ALG function is trying to send SIP packets out but the router log says it did not forward, apparently because the Grandstream's SIP packet is not formatted properly according to the Cradlepoint.

Keep alive packets from your ATA are sent to keep your router ports open, not VOIPo's. The ATA is sending a local request to your router, a local request (local IP, private IP, any IP starting with 192.16 cannot be forwarded, if local IP's forwarded to the internet you would be colliding with millions of routers worldwide. Your registration requests are getting forwarded because the ATA sends it thru your WAN IP address. As long as your ATA is keeping your routers ports open (or your router has built in VOIP logic), you are right, VOIPo's attempt to keep yours alive is unnecessary. But, they have more than just you to think about, thousands of VOIPo customers are benefiting from keep alive requests sent by VOIPo and it is not detrimental to routers that don't need the reminder. Albeit maybe a little unnerving seeing your logs fill up.

[stevech]

Keep alive packets from your ATA are sent to keep your router ports open, not VOIPo's. The ATA is sending a local request to your router, a local request (local IP, private IP, any IP starting with 192.16 cannot be forwarded, if local IP's forwarded to the internet you would be colliding with millions of routers worldwide. Your registration requests are getting forwarded because the ATA sends it thru your WAN IP address. As long as your ATA is keeping your routers ports open (or your router has built in VOIP logic), you are right, VOIPo's attempt to keep yours alive is unnecessary. But, they have more than just you to think about, thousands of VOIPo customers are benefiting from keep alive requests sent by VOIPo and it is not detrimental to routers that don't need the reminder. Albeit maybe a little unnerving seeing your logs fill up.

Geeze, I know the difference between a non-routable/private IP and a public IP address. The problem is why does my router's ALG reject the SIP packets form the Grandstream. If not rejected, they get NATed to my public address and on to VoIPo's designated SIP server. I will try to get from Cradlepoint what criteria they use to reject a SIP packet in their ALG.

[voipinit]

I wonder if SIP ALG is re-writing the packet to use your public IP as opposed to using NAT and discarding the original. Does your traffic decrease with SIP ALG disabled?

[stevech]

I wonder if SIP ALG is re-writing the packet to use your public IP as opposed to using NAT and discarding the original. Does your traffic decrease with SIP ALG disabled?

While I await a response from Cradlepoint tech support, all I can say is what the log says

"SIP ALG rejected packet from 192.168.1.51:5079 to 72.51.46.124:5060"

where the source is the VoIP device and the destination is the SIP server I am assigned. One must assume that the packet would get NATed to my public IP address had ALG not rejected it as formatted by the Grandstream.

EDIT: I did find this statement from a lay-person:
"As most modern sip clients are NAT aware, there really isn't a need for the sip alg."
But I wonder if this applies to the NAT traversal techniques in the Grandstream client?


To be clear: The VoIPo service works OK, this is an admin issue.