\section{Changes From RFC~2543}

This RFC revises RFC~2543. It is mostly backwards compatible with 
RFC~2543. The changes described here fix many errors discovered in 
RFC~2543 and provide information on scenarios not detailed in 
RFC~2543. The protocol has been presented in a more cleanly layered model
here. 

We break the differences into functional behavior that is a
substantial change from RFC~2543, which has impact on
interoperability or correct operation in some cases, and functional
behavior that is different from RFC~2543 but not a potential source of
interoperability problems. There have been countless clarifications as
well, which are not documented here.

\subsection{Major Functional Changes}
\begin{itemize}

\item When a UAC wishes to terminate a call before it has been
answered, it sends {\CANCEL}. If the original {\INVITE} still returns
a 2xx, the UAC then sends {\BYE}. {\BYE} can only be sent on an
existing call leg (now called a dialog in this RFC), whereas it could
be sent at any time in RFC~2543.

\item The SIP BNF was converted to be RFC~2234 compliant.

\item SIP URL BNF was made more general, allowing a greater set of
characters in the user part. Furthermore, comparison rules were
simplified to be primarily case-insensitive, and detailed handling of
comparison in the presence of parameters was described. The most substantial
change is that a URI with a parameter with the default value does not
match a URI without that parameter. 

\item Removed \header{Via} hiding. It had serious trust issues, since
it relied on the next hop to perform the obfuscation process. Instead,
\header{Via} hiding can be done as a local implementation choice in
stateful proxies, and thus is no longer documented.

\item In RFC~2543, {\CANCEL} and {\INVITE} transactions were
intermingled. They are separated now. When a user sends an {\INVITE}
and then a {\CANCEL}, the {\INVITE} transaction still terminates
normally. A UAS needs to respond to the original {\INVITE} request
with a 487 response.

\item Similarly, {\CANCEL} and {\BYE} transactions were intermingled;
RFC~2543 allowed the UAS not to send a response to {\INVITE} when a
{\BYE} was received. That is disallowed here. The original {\INVITE}
needs a response.

\item In RFC~2543, UAs needed to support only UDP. In this RFC, UAs
need to support both UDP and TCP.

\item In RFC~2543, a forking proxy only passed up one challenge from
downstream elements in the event of multiple challenges. In this RFC,
proxies are supposed to collect all challenges and place them into the
forwarded response.

\item In Digest credentials, the URI needs to be quoted; this is
unclear from RFC~2617 and RFC~2069 which are both inconsistent on it.

\item SDP processing has been split off into a separate 
specification~\citenorm{draft-ietf-mmusic-sdp-offer-answer},
and more fully specified as a
formal offer/answer exchange process that is effectively tunneled
through SIP.  SDP is allowed in {\INVITE}/200 or 200/{\ACK} for baseline
SIP implementations; RFC~2543 alluded to the ability to use it in
{\INVITE}, 200, and {\ACK} in a single transaction, but this was not
well specified.  More complex SDP usages are allowed in extensions.

\begin{changebar}
\item Added full support for IPv6 in URIs and in the \header{Via}
header field. Support for IPv6 in \header{Via} has required that 
its header field parameters allow the square bracket and colon characters. 
These characters were previously not permitted. In theory, this could
cause interop problems with older implementations. However, we have
observed that most implementations accept any non-control ASCII character
in these parameters.
\end{changebar}

\item DNS SRV procedure is now documented in a separate 
specification~\citenorm{draft-ietf-sip-srv}. 
This procedure uses both SRV and NAPTR
resource records and no longer combines data from across SRV records
as described in RFC~2543.

\item Loop detection has been made optional, supplanted by a mandatory
usage of \header{Max-Forwards}. The loop detection procedure in 
RFC~2543 had a serious bug which would report ``spirals'' as an error
condition when it was not. The optional loop detection procedure is
more fully and correctly specified here.

\item Usage of tags is now mandatory (they were optional in RFC~2543),
as they are now the fundamental building blocks of dialog
identification.

\item Added the \header{Supported} header field, allowing for clients to
indicate what extensions are supported to a server, which can apply
those extensions to the response, and indicate their usage with a
\header{Require} in the response. 

\item Extension parameters were missing from the BNF for several
header fields, and they have been added. 

\item Handling of \header{Route} and \header{Record-Route}
construction was very underspecified in RFC~2543, and also not the
right approach. It has been substantially reworked in this
specification (and made vastly simpler), and this is arguably the largest
change. Backwards compatibility is still provided for deployments that
do not use ``pre-loaded routes'', where the initial request has a set
of \header{Route} header field values obtained in some way outside of
\header{Record-Route}. In those situations, the new mechanism is not
interoperable. 

\item In RFC~2543, lines in a message could be terminated with CR, LF,
or CRLF. This specification only allows CRLF. 

\item Comments (expressed with rounded brackets) have been removed
from the grammar of SIP.

\item Usage of \header{Route} in {\CANCEL} and {\ACK} was not 
well defined in RFC~2543. It is now well specified; if a request had a
\header{Route} header field, its {\CANCEL} or {\ACK} for a non-2xx response
to the request need to carry the same \header{Route} header field values. {\ACK}s
for 2xx responses use the \header{Route} values learned from the
\header{Record-Route} of the 2xx responses. 

\item RFC~2543 allowed multiple requests in a single UDP packet. This
usage has been removed.

\item Usage of absolute time in the \header{Expires} header field and
parameter has been removed. It caused interoperability problems in
elements that were not time synchronized, a common occurrence. Relative
times are used instead. 

\item The branch parameter of the \header{Via} 
header field value
is now mandatory
for all elements to use. It now plays the role of a unique transaction
identifier. This avoids the complex and bug-laden transaction
identification rules from RFC~2543. A magic cookie is used in the
parameter value to determine if the previous hop has made the
parameter globally unique, and comparison falls back to the old rules
when it is not present. Thus, interoperability is assured.

\item In RFC~2543, closure of a TCP connection was made equivalent to
a {\CANCEL}. This was nearly impossible to implement (and wrong) for
TCP connections between proxies. This has been eliminated, so that
there is no coupling between TCP connection state and SIP processing. 

\item RFC~2543 was silent on whether a UA could initiate a new
transaction to a peer while another was in progress. That is now
specified here. It is allowed for non-{\INVITE} requests, disallowed
for {\INVITE}.

\item PGP was removed. It was not sufficiently specified, and not
compatible with the more complete PGP MIME. It was replaced with
S/MIME.

\begin{changebar}
\item Added the ``sips'' URI scheme for end-to-end TLS. This scheme is
not backwards compatible with RFC~2543. Existing elements that receive
a request with a SIPS URI scheme in the \header{Request-URI} will likely
reject the request. This is actually a feature; it ensures that a call
to a SIPS URI is only delivered if all path hops can be secured. 
\end{changebar}

\item Additional security features were added with TLS, and these are
described in a much larger and complete security considerations section.

\item In RFC~2543, a proxy was not required to forward provisional
responses from 101 to 199 upstream. This was changed to {\MUST}. This
is important, since many subsequent features depend on delivery of all
provisional responses from 101 to 199.

\item Little was said about the 503 response code in RFC~2543. It has
since found substantial use in indicating failure or overload
conditions in proxies. This requires somewhat special
treatment. Specifically, receipt of a 503 should trigger an attempt to
contact the next element in the result of a DNS SRV lookup. Also, 503
response is only forwarded upstream by a proxy under certain
conditions.

\item RFC~2543 defined, but did no sufficiently specify, a mechanism
for UA authentication of a server. That has been removed. Instead, the
mutual authentication procedures of RFC~2617 are allowed. 

\item A UA cannot send a {\BYE} for a call until it has received an {\ACK}
for the initial {\INVITE}. This was allowed in RFC~2543 but leads to
a potential race condition.

\item A UA or proxy cannot send {\CANCEL} for a transaction until it
gets a provisional response for the request. This was allowed in
RFC~2543 but leads to potential race conditions.

\item The action parameter in registrations has been deprecated. It
was insufficient for any useful services, and caused conflicts when
application processing was applied in proxies.

\item RFC~2543 had a number of special cases for multicast. For
example, certain responses were suppressed, timers were adjusted, and
so on. Multicast now plays a more limited role, and the protocol
operation is unaffected by usage of multicast as opposed to
unicast. The limitations as a result of that are documented.

\item Basic authentication has been removed entirely and its usage
forbidden. 

\item Proxies no longer forward a 6xx immediately on receiving
it. Instead, they CANCEL pending branches immediately. This avoids a
potential race condition that would result in a UAC getting a 6xx
followed by a 2xx. In all cases except this race condition, the result
will be the same - the 6xx is forwarded upstream.

\item RFC~2543 did not address the problem of request merging. This
occurs when a request forks at a proxy and later rejoins at an
element. Handling of merging is done only at a UA, and procedures are
defined for rejecting all but the first request.
\end{itemize}

\subsection{Minor Functional Changes}

\begin{itemize}

\item Added the \header{Alert-Info}, \header{Error-Info}, and
\header{Call-Info} header fields for optional content presentation to
users.

\item Added the \header{Content-Language}, \header{Content-Disposition}
and \header{MIME-Version} header fields.

\item Added a ``glare handling'' mechanism to deal with the case where
both parties send each other a re-{\INVITE} simultaneously.  It uses the
new 491 (Request Pending) error code.

\item Added the \header{In-Reply-To} and \header{Reply-To} header fields for
supporting the return of missed calls or messages at a later time.

\item Added TLS and SCTP as valid SIP transports.

\item There were a variety of mechanisms described for handling failures
at any time during a call; those are now generally unified.  {\BYE} is
sent to terminate.

\item RFC~2543 mandated retransmission of {\INVITE} responses over TCP,
but noted it was really only needed for 2xx.  That was an artifact of
insufficient protocol layering.  With a more coherent transaction layer
defined here, that is no longer needed.  Only 2xx responses to
{\INVITE}s are retransmitted over TCP.

\item Client and server transaction machines are now driven based on
timeouts rather than retransmit counts.  This allows the state machines
to be properly specified for TCP and UDP.

\item The \header{Date} header field is used in {\REGISTER} responses to
provide a simple means for auto-configuration of dates in user agents.

\item Allowed a registrar to reject registrations with expirations that
are too short in duration.  Defined the 423 response code and the
\header{Min-Expires} for this purpose.

\end{itemize}
