Q on VoIPo SIP outbound vs. router

**voipinit** · 03-14-2011 01:52 PM

Originally Posted by stevech

... 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** · 03-14-2011 04:05 PM

Originally Posted by voipinit

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** · 03-15-2011 05:06 AM

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?

**sr98user** · 03-15-2011 03:41 PM

NAT Keep alive packets probably don't have any SIP header.. That maybe the reason it is rejecting the packets.

Since you are working fine with the packets being rejected, I assume you don't need any keep alive packets. You could probably ask VOIPo to turn off Keep Alive packets. Since your router is SIP aware, it is getting the registration interval from the SIP packets and keeping the NAT entry alive for the duration.

I am not sure if STUN setting is turned on for your ATA. If not, your router's SIP ALG is working fine. If the SIP ALG is turned off in your router, you will need NAT Traversal and STUN server on your ATA.

On my ATA, NAT Traversal, STUN and Keep alive packets are turned off.

**voipinit** · 03-15-2011 05:21 PM

Originally Posted by sr98user

NAT Keep alive packets probably don't have any SIP header.. That maybe the reason it is rejecting the packets.

Sounds correct, if keep alive packets had a valid SIP header, it would be passed just like registration requests are.

Originally Posted by sr98user

On my ATA, NAT Traversal, STUN and Keep alive packets are turned off.

On my ATA, NAT traversal (STUN) and keep alive are on (keep alive sent every 20 seconds but really is just bouncing back and forth between the router and ATA).

**stevech** · 03-15-2011 05:54 PM

Do I have this correct:
The Grandstream ATA is sending "keep alive" packets to the SIP server, on the SIP port, but these are not SIP-formatted (standards-compliant). Therefore, the ALG in my router rejects them. So they should not be sent on the SIP port. Yes?

VoIPo told me they moved my ATA to non-standard SIP ports to better hide from bad guys trying to steal service. Not sure this is relevant.

The keep-alive packets, if this is what they are, seemingly should be sent via some port number that is not reserved by agreement for a given service like SIP.
Yes?

It would be noise on the LAN but my router's log fills quickly with these junk messages, and those of rejected incoming messages from VoIPo's SIP servers doing some sort of NAT trigger keep-alive. I'd really like my router's log to be useful for what it is intended for: logging anomalies.

**sr98user** · 03-15-2011 07:35 PM

Originally Posted by stevech

Do I have this correct:
The Grandstream ATA is sending "keep alive" packets to the SIP server, on the SIP port, but these are not SIP-formatted (standards-compliant). Therefore, the ALG in my router rejects them. So they should not be sent on the SIP port. Yes?

Your router log says that SIP ALG functionality rejected it. But I am not sure if the packet is still sent out without being rewritten by SIP ALG. Cradlepoint can confirm that for you.

VoIPo told me they moved my ATA to non-standard SIP ports to better hide from bad guys trying to steal service. Not sure this is relevant.

The keep-alive packets, if this is what they are, seemingly should be sent via some port number that is not reserved by agreement for a given service like SIP. Yes?

VOIPo could have just changed the port on your side to avoid the "bad guys stealing service" problem. I am not sure if they changed both the local port and the destination port. Given that SIP ALG is kicking in on your router, I would guess that VOIPo changed only the local port.

I know that you can access VOIPo service at ports other than 5060. Like 5061, 5062, 5078 etc..

It would be noise on the LAN but my router's log fills quickly with these junk messages, and those of rejected incoming messages from VoIPo's SIP servers doing some sort of NAT trigger keep-alive. I'd really like my router's log to be useful for what it is intended for: logging anomalies.

Is your router rejecting incoming packets from multiple SIP servers or just one? I know your service works fine, but rejecting incoming packets from SIP servers it not the ideal setup.

**stevech** · 03-15-2011 07:52 PM

The log entries are an about equal mix of outgoing packets from the grandstream that are blocked as apparently invalid SIP packets, by the ALG in the router. Others here said it's probably keep-alive packets sent on the SIP port but without a SIP header; and incoming packets from VoIPo's SIP servers, apparently in an attempt to cope with some consumer routers that won't work correctly for NAT without this barrage of ping-like packets.