Q on VoIPo SIP outbound vs. router

[sr98user]

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]

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.