Linked by David Adams on Mon 21st Mar 2011 20:14 UTC, submitted by Anonymous
Permalink for comment 467176
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
Linked by Thom Holwerda on 04/16/13 9:29 UTC
Linked by Thom Holwerda on 04/15/13 22:44 UTC
More Features »
Sponsored Links



Member since:
2011-01-28
I am a strong supporter of open standards and interoperability, and when it comes to internet telephony, that points to SIP/RTP.
However it is one of the worst thought out protocols I've ever had to deal with on account of assuming that both ends can open up arbitrary public facing ports. This is terribly difficult to accomplish behind NAT routers - particularly those which I don't own/control.
To anyone who's having trouble with SIP port forwarding on netgear routers:
Many home netgear routers have a SIP ALG bug which causes corruption and breaks SIP calls even when the port forwarding is correct. (It took me hours to discover this by looking at wireshark traces).
Once I realized what was happening it was easy to recognize, the router was corrupting all values which appeared to match an internal/external IP address and mangled the values. The problem is that the 4 byte substitution was applied on raw packets without regard to the SIP fields - whoever programmed this was an idiot.
Anyways, many sip clients use "USERNAME@EXTERNALIP" to identify themselves. When the packets are acked, netgear routers substitute USERNAME@INTERNALIP, which is wrong so the client drops the ACKs.
Since I was debugging the source code (initially thinking it was a client issue), I modified the client to ignore the mangled IPs, which "solved" the problem. However, this can be fixed by using domain names instead of IP addresses.
I reported this bug to netgear, and they eventually were able to confirm the bug. They initially denied the home routers had any SIP ALG - their business products do, however it turns out the home routers have the SIG ALG enabled in an invalid state and the engineers merely disabled the user interface to control it.
That was two years ago and it hasn't been fixed. Anyone working with SIP should keep this in mind.