Thank you for your comments! While this is off-topic for FreeSWITCH I'm not sure where else this conversation could take place. Apologies in advance to the list admins - if you want me to take it elsewhere just say so :). You could probably tell I wasn't exactly sure how to address SIP/UDP and fragmentation issues. More than anything it came out of the various efforts deployed by some implementations to reduce SIP packet size (omitting rtpmap lines, specifically). I wanted to explain why some implementations (FreeSWITCH being one) make attempts to minimize SIP packet size, even at the expense of overall interoperability (depending on how you want to look at it). One could certainly argue that the UDP -> TCP transition specified in RFC 3261 would lead to more interop problems than "missing" rtpmap lines. To answer the question I don't see a lot of UDP fragmentation issues but then again the majority of my production UDP SIP traffic has pretty small packet sizes. Your comment on actively blocking undesired ICE candidate paths with a firewall is well taken. I'll add it to the doc! Re-INVITEs. Yep. Remember one of the first rules of the document - someone, somewhere has broken just about anything and everything. On Mon, Jun 18, 2012 at 4:32 PM, Michael Giagnocavo <mgg@giagnocavo.net> wrote:
Excellent work. It's great to see a practical guide to the complicated (and sometimes downright moronic) mess that encumbers VoIP.
Some notes:
- From viewing a medium sized production network, I see about 1% of the SIP packets received and processed are fragmented (MTU of 576 bytes somewhere along the way). Are you seeing implementations actually failing due to IP fragmentation of UDP packets? I tested sending 2KB length UDP messages to my proxies over the Internet, and it seems to work. Certainly sending frag'd SIP messages is more likely to work than the crazy idea of protocol transition, right? Who's really experiencing MTU issues?
- Watch out with ICE and VPNs. While communicating to a server on a public IP that's also available internally via VPN, an aggressive anti-NAT solution like ICE might determine there's a "direct" path via the private VPN IPs. If the VPN is not a good path (say, its implemented over SSL), connectivity will happen over that path, and audio quality suffers. Microsoft Lync does this (Google lots of complaints related to using Lync with a VPN), and the only workaround is to configure firewalls to block such traffic. - Subnote: I wonder how well things would work if SIP clients implemented UPnP, which is supported by tons of home routers?
- Re-INVITE messages *should* be distinguished by a to tag. But, there are many networks out there using software written by folks that didn't bother to read the SIP spec, and they will happily ignore an existing to tag and treat it like a new request. This has implications for the standard OpenSIPS config, for instance, which allows relaying of INVITEs if there's a to-tag.
-Michael
-- Kristian Kielhofner