Great doc! Some short notes: *This is broken. Cisco is the most well known vendor to make this mistake.

These implementations should be fixed to use G729 as the codec name with payload type 18.*

Linksys / Sipura SPAs do this, too, I'm pretty sure even before they were bough by cisco. *Typically this NAT functionality is referred to as a SIP NAT helper, or

SIP ALG. Of course there are other names.*

Many routers let you turn off NAT ALG, if you can find it in the menu. *Latching has several issues:... scalability* At what point does this seriously become an issue? 100 concurrent calls? 1000? If you're proxying media anyway the IP rewriting sounds pretty minimal. More info about NAT, one way media, and how sipsorcery is a SIP proxy that doesn't ever proxy media but can still set up calls with 2 way media would be much appreciated. One other things I'm interested in is the ability to not handle media, for latency & performance reasons: What are the pitfalls with FreeSWITCH specifically that makes it not happy with not handling media? and.. if I still need FS to handle DTMF what are my options? Do many/most carriers (on origination) support SIP INFO or something like that? (I run a calling card with an option to hang up the call) Thanks for the helpful info! -Avi On Fri, Jun 15, 2012 at 8:24 PM, dingdong <freeswitch@zoho.com> wrote:

** very nice and helpful,and yes,it would really be more useful if somehow related to how does FS do SIP.

Thanks

---- On Thu, 14 Jun 2012 13:06:52 -0700 *Kristian Kielhofner < kris@kriskinc.com>* wrote ----

FreeSWITCHers,

As some of you may have noticed I frequently comment on SIP-related FreeSWITCH posts. Long story short I decided to finally put some of these thoughts and experiences down in writing. What I ended up with is a 21 page (and counting) document describing various SIP header fields, SDP information, RTP issues, DTMF issues, NAT traversal technologies, interop headaches, etc.

I wrote a little intro and linked to the document if any of you would like to check it out (link at the end of post):

http://blog.krisk.org/2012/06/everything-you-wish-you-didnt-need-to.html

Of course I'd appreciate any feedback you may have. What do you disagree with? Find a typo? Have burning SIP/RTP/SDP/T.38/codec questions you'd like to see me address? Should I get into more implementation (FreeSWITCH) specific issues? Let me know.

Thanks!

-- Kristian Kielhofner

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

Join Us At ClueCon - Aug 7-9, 2012

FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

Join Us At ClueCon - Aug 7-9, 2012

FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

On Sun, Jun 17, 2012 at 6:44 AM, Steve Underwood <steveu@coppice.org> wrote:

I thought the only Cisco products which did this were the ones which started as Linksys/Sipura products. The usual G.729 problem with real Cisco products is G.729 with the bits packed in the opposite order to the RFC. This isn't an error. Cisco implemented G.729 in RTP before there was a standard, and the packing order they chose just happened to be the opposite of the standard. Of course, modern Cisco kit implements the standard order, but they can still do the opposite order for backwards compatibility with their own kit. Sometimes you still meet systems configured to use that, and G.729 calls produce a horrible noise.

You are generally correct, however, some of the rtmpap G729a craziness seems to have moved to "Cisco proper". I've seen IOS-powered media gateways and CallManager express systems put G729a in the rtpmap. With how much that hardware interacts with the current line of rebadged Sipura/Linksys phones I can't say I'm completely surprised. -- Kristian Kielhofner

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