Check out the most comprehensive, actively managed Lync blog roll in the known universe, your one-stop source for links to over 100 of the very best Lync blogs. Here you will also find weekly blog highlights and a feed for a dozen of the top blogs.
Lync Server Support Home
Top Lync Solutions RSS Feed
Microsoft Senior Support engineers walk you through real-life support cases, giving you an insider’s view into the systematic approach they use to troubleshoot Lync Server issues.
These short videos focus on specific tasks and show you how to accomplish them for Microsoft Lync Server 2010.
Author: Russell Bennett
Publication date: May 2008
Product version: Office Communications Server 2007 R2
Generically, SIP can use (at least) 3 types of transport. Office Communications Server supports TCP and TLS, with the latter being the default (actually, TLS runs on TCP).
Various interactions with some partners and customers of late of have posed the question: "Why doesn’t OCS support SIP over UDP?" Their belief is that UDP is the ‘lowest common denominator’ SIP transport that is supported by "everyone" and that, by not supporting it, OCS is out of step with the mainstream of SIP implementation and interoperability.
Let’s evaluate that proposition on its merits.
There are three issues with UDP:
A commercially deployable enterprise communications solution must, at the very least, be secure, reliable and scalable. UDP presents challenges in all of these areas and the SIP RFCs (see below) allow us to choose from alternative SIP transports. Within the OCS network we use TLS, and at the edge of the network we can interoperate over TCP.
Why do people object to TCP or TLS as a SIP transport?The fundamental objection to SIP over TCP or TLS is that it they are computationally expensive relative to UDP. There are several parameters at the transport, session and application layers that affect transaction performance:
An IBM Research article "Evaluating SIP Proxy Server Performance" examined, among other things, the impact of the choice of SIP transport protocol on SIP transaction throughput. The authors found clear evidence that stateless UDP with no authentication (and therefore no encryption) has, by far, the highest throughput. However, this modality is completely incompatible with a reliable and secure commercial communications service. Stateful transaction processing with authentication yielded a 43% transaction degradation when using TCP compared with UDP. However, the authors were using an open source proxy server and brought to light various performance issues that were implementation specific.
An IEEE Article "SIP Security Issues: The SIP Authentication Procedure and its Processing Load" further examines the security and authentication overhead issue and found only a 5.5% overhead to TCP vs. UDP. Their summary includes the comment:
Another interesting finding is that the TCP processing introduces a small increase [in processing overhead] with respect to UDP and that the additional increase due to TLS is almost negligible.Therefore, if you compare UDP to TCP and TLS in a commercially deployable solution, it is hard to defend the argument that the overhead of TCP and TLS outweigh the reliability and security advantages that they provide.
The debate regarding whether or not TCP is inefficient/expensive has been going on for many years. An IEEE Landmark Article "An Analysis of TCP Processing Overhead" published in June 1989 disproves the notion that TCP (by then a 15 year old protocol) is an inefficient protocol. The fact that it is still in use nearly 20 years later suggests that the authors were correct and that current anti-TCP sentiment is based upon "techno-urban legend", rather than scientific analysis.
There is a belief among certain constituencies that UDP is "more standard" than TCP or TLS.
From a historical perspective, the original SIP spec, RFC 2543 (published in March 1999), states:
User agents SHOULD implement both UDP and TCP transport. Proxy, registrar, and redirect servers MUST implement both UDP and TCP transport.
Note that equal priority was given to TCP and UDP. If you take a look at the current SIP spec, RFC 3261 (published in June 2002), you will see in section 18 the following statements related to SIP transport:
All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols.
Making TCP mandatory for the UA is a substantial change from RFC 2543. It has arisen out of the need to handle larger messages, which MUST use TCP, as discussed below. Thus, even if an element never sends large messages, it may receive one and needs to be able to handle them.
While it is true that OCS does not comply with RFC 3261 by not offering or accepting UDP, the assumption that all SIP messages will exceed the UDP datagram size limit provides an implied waiver on this requirement. Furthermore, TCP is the base transport for TLS, which we strongly recommend for security reasons; note that TLS does not run on UDP. Therefore, the conjunction of the security, fragmentation and reliability/scalability issues has lead us to the conclusion that UDP is not a useful transport for the transmission of SIP messages.
In order to verify the notion that SIP over UDP is supported by everyone, and yet TCP/TLS is supported by no-one, let’s examine the SIP offerings of the (overwhelming) majority market share vendors:
Based on this small, but statistically significant sample – there is a strong argument that TCP is actually the lowest common denominator SIP transport. Certainly, the notion that vendors do not support, and customers can not deploy, SIP over TCP is thoroughly debunked.
We have examined the myth that UDP is the best choice SIP transport:
As Adam and Jamie say on the Discovery Channel’s ‘Mythbusters’: I think we are ready to make a call on this myth….and it is definitely ‘busted’.