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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
