[asterisk-users] Microsoft Office Communications Server

[Raj Jain]

I'd concur that allowing SIP to be transported over UDP was one of the
biggest mistakes made in the initial protocol design. In addition to
the issues stated below (such as IP fragmentation and how that impacts
NAT traversal), there are other unsolvable problems w/ SIP/UDP such as
when a request is smaller than path MTU and is therefore sent over UDP
but the response exceeds the MTU size - how do you deliver the
response then?.

If there is ever a SIP 3.0, I believe there is enough consensus that
it'll not support UDP transport.

--
Raj


On Mon, Mar 10, 2008 at 9:29 PM, Philipp von Klitzing
<klitzing at pool.informatik.rwth-aachen.de> wrote:
> Hi!
>
>
>  > What is the logic of them using SIP over TCP? Is this a broad industry
>  > trend? Or just the latest attempt to get around SIP/NAT issues?
>
>  I remember a quote of Henning Schulzrinne where he states that having
>  designed SIP with UDP in mind was the biggest mistake he (and Mark
>  Handle?) were to be found guilty of. I am not sure if this is what's
>  driving Microsoft's decisions, my guess is that this is/was mostly driven
>  by security reasons (and the new focus of Microsoft on security aspects).
>
>  Cheers, Philipp
>
>
>  * Taken from http://www.faqs.org/rfcs/rfc4168.html:
>
>  3.1.  Advantages over UDP
>
>    All the advantages that SCTP has over UDP regarding SIP transport are
>    also shared by TCP.  Below, there is a list of the general advantages
>    that a connection-oriented transport protocol such as TCP or SCTP has
>    over a connection-less transport protocol such as UDP.
>
>    Fast Retransmit: SCTP can quickly determine the loss of a packet,
>       because of its usage of SACK and a mechanism that sends SACK
>       messages faster than normal when losses are detected.  The result
>       is that losses of SIP messages can be detected much faster than
>       when SIP is run over UDP (detection will take at least 500 ms, if
>       not more).  Note that TCP SACK exists as well, and TCP also has a
>       fast retransmit option.  Over an existing connection, this results
>       in faster call setup times under conditions of packet loss, which
>       is very desirable.  This is probably the most significant
>       advantage of SCTP for SIP transport.
>
>    Congestion Control: SCTP maintains congestion control over the entire
>       association.  For SIP, this means that the aggregate rate of
>       messages between two entities can be controlled.  When SIP is run
>       over TCP, the same advantages are afforded.  However, when run
>       over UDP, SIP provides less effective congestion control.  This is
>       because congestion state (measured in terms of the UDP retransmit
>       interval) is computed on a transaction-by-transaction basis,
>       rather than across all transactions.  Thus, congestion control
>       performance is similar to opening N parallel TCP connections, as
>       opposed to sending N messages over one TCP connection.
>
>    Transport-Layer Fragmentation: SCTP and TCP provide transport-layer
>       fragmentation.  If a SIP message is larger than the MTU size, it
>       is fragmented at the transport layer.  When UDP is used,
>       fragmentation occurs at the IP layer.  IP fragmentation increases
>       the likelihood of having packet losses and makes NAT and firewall
>       traversal difficult, if not impossible.  This feature will become
>       important if the size of SIP messages grows dramatically.
>
>
>  * Quote from http://tools.ietf.org/html/draft-jennings-sip-dtls-01:
>
>    There has been considerable discussion of why SIP needs DTLS when we
>    have TLS.  This is the wrong question.  The right question is why SIP
>    has UDP and TCP (not to mention SCTP).  There are two reasons for
>    believing that UDP is likely to be an important protocol in SIP for
>    the foreseeable future.
>
>    o  In theory, there is no problem building systems that terminate a
>       million TCP connections on a single host.  In practice, the common
>       operating systems used for building SIP aggregation devices make
>       this impossible.  To date, no one has demonstrated terminating
>       over 100k SIP TCP connections to a single host.  Doing that many
>       connections with UDP has not been difficult.
>
>    o  If we want to talk about "running code" for SIP, it's UDP.  Unless
>       UDP is deprecated for SIP, it is important to provide a reasonable
>       level of security for it.
>
>
>
>
>  _______________________________________________
>  -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
>  asterisk-users mailing list
>  To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>