*Hello John:* I am in complete agreement with everything you are saying (at the technical level).
However at the business level, I will be adding overnight, a residual *profit* of approximately $1,500 extra (Close to $18K extra per year) to accommodate my resellers requests to support both 3CX (SIP over TCP) and Microsoft's Communications Manager (SIP over TCP again). The decision is mostly a business reason to accommodate other technologies - where prospects are dead hard set on Windows based solutions and regardless of how much you want to educate them about the benefits of Linux & Asterisk, they just don't buy it. There are many ways to keep your system secure, and a traditional firewall is not the only, and should not be the only approach in keeping your Asterisk server safe. If you want to survive in todays economy, one needs to be technically flexible to support the technologies the customer is asking for. Every time you insist (bluntly or diplomatically) that the prospect is incorrect in their line of thinking (when they have already made their decision), you have lost the opportunity. Based on my research (and folks please give your 2 cents here) -- I am not convinced that SIP over TCP is hopelessly insecure and incompetent. It may not be as perfect as SIP over UDP - but the reality is it works. There is no doubt in my mind that the Digium folks added SIP o/TCP support, only after careful evaluation of the market and keeping in mind the technical pros & cons. The Asterisk's IAX protocol itself has limitations over SIP - and that too, IAX runs on TCP. But granted, in a perfect world - SIP over UDP should be the standard across board. * * *Kind regards,* *Reza.* On Thu, Nov 18, 2010 at 8:17 PM, John Lange <[email protected]> wrote: > Forcing SIP over TCP would make the reliability of SIP moderately > worse in normal network conditions and probably unusable in poor > network conditions. > > SIP already implements the handshaking, timeouts, retransmits etc at > the application level using settings that make sense for SIP. TCP > would just add another layer doing effectively the same thing except > using values that typically make no sense for SIP. > > About the only reason I can think of for SIP/TCP is if you had a > firewall that can't do proper UDP nat; in which case you should > replace the firewall, not the protocol. > > I have however discovered the reason why SIP over TCP is a > requirement; the Microsoft SIP implementation only runs on TCP... > > A google search reveals that one potential reason for SIP over TCP is > to handle larger messages sizes and in fact, to be compliant with the > SIP RFC 3261, both UDP & TCP must be supported. > > The message size thing seems a bit strange. It's not like you have to > squeeze everything into one small packet, but I'm not motivated enough > to read RFC to find the answer. > > -- > John Lange > www.johnlange.ca > -- Toronto based VoIP / Asterisk Trainer, I.T. Consultant and Hosted PBX Solutions Provider. +1-647-476-2067. http://www.linkedin.com/in/seminar
