\section{Common Message Components}
\label{sec:common-message}

There are certain components of SIP messages that appear in various 
places within SIP messages (and sometimes, outside of them) that
merit separate discussion.

\subsection{SIP and SIPS Uniform Resource Indicators}
\label{sec:sip-url}
\label{sec:sip-uri}

A SIP or SIPS URI identifies a communications resource.  Like all URIs, SIP and SIPS URIs
may be placed in web pages, email messages, or printed literature.  They
contain sufficient information to initiate and maintain a communication
session with the resource.

Examples of communications resources include the following:
\begin{itemize}
\item a user of an online service

\item an appearance on a multi-line phone

\item a mailbox on a messaging system
\item a PSTN number at a gateway service

\item a group (such as ``sales'' or ``helpdesk'') in an organization
\end{itemize}

\begin{changebar} 
A SIPS URI specifies that the resource be contacted securely. This
means, in particular, that TLS is to be used between the UAC and the
domain that owns the URI. From there, secure communications are used
to reach the user, where the specific security mechanism depends on
the policy of the domain. Any resource described by a SIP URI can be
``upgraded'' to a SIPS URI by just changing the scheme, if it is
desired to communicate with that resource securely.
\end{changebar}

\subsubsection{SIP and SIPS URI Components}
\label{sec:sip-url-components}
\label{sec:sip-uri-components}

The ``sip:'' and ``sips:'' schemes follow the guidelines in
RFC~2396~\citenorm{rfc2396}.  They use a form similar to the
\header{mailto} URL, allowing the specification of SIP
\header{request-header} fields and the SIP \header{message-body}.  This
makes it possible to specify the subject, media type, or urgency of
sessions initiated by using a URI on a web page or in an email message. 
The formal syntax for a SIP or SIPS URI is presented in
Section~\ref{sec:abnf}.  Its general form, in the case of a SIP URI, is
\begin{center}
\textsf{sip:user:password@host:port;uri-parameters?headers}
\end{center}

The format for a SIPS URI is the same, except that the scheme is
``sips'' instead of sip.  These tokens, and some of the tokens in their
expansions, have the following meanings:

\begin{description}

\item[\header{user}:] The identifier of a particular resource at the
host being addressed.  The term ``host'' in this context frequently
refers to a domain.  The ``userinfo'' of a URI consists of this user
field, the password field, and the~@~sign following them.  The
\header{userinfo} part of a URI is optional and {\MAY} be absent when
the destination host does not have a notion of users or when the host
itself is the resource being identified.  If the~@~sign is present in a
SIP or SIPS URI, the user field {\MUSTNOT} be empty.

If the host being addressed can process telephone numbers, for instance,
an Internet telephony gateway, a \header{telephone-subscriber} field
defined in RFC~2806~\citenorm{rfc2806} {\MAY} be used to populate the
\header{user} field.  There are special escaping rules for encoding
\header{telephone-subscriber} fields in SIP and SIPS URIs described in
Section~\ref{sec:url-escaping}.

\item[\header{password}:] A password associated with the user.
While the SIP and SIPS URI syntax allows this field to be present, its use
is {\NOTRECOMMENDED}, because the passing of authentication information
in clear text (such as URIs) has proven to be a security risk in almost
every case where it has been used. For instance, transporting a PIN 
number in this field exposes the PIN.

Note that the password field is just an extension of user portion. 
Implementations not wishing to give special significance to the password
portion of the field {\MAY} simply treat ``user:password'' as a single
string.

\item[\header{host}:] The host providing the SIP resource.  The
\header{host} part contains either a fully-qualified domain name or
numeric IPv4 or IPv6 address.  Using the fully-qualified domain name
form is {\RECOMMENDED} whenever possible.

\item[\header{port}:] The port number where the request is to be sent.

\item[URI parameters:] Parameters affecting a request constructed from 
the URI.

URI parameters are added after the \header{hostport} component and
are separated by semi-colons. 

URI parameters take the form:
\begin{center}
\begin{sf}
parameter-name "=" parameter-value
\end{sf}
\end{center}
Even though an arbitrary number of URI parameters may be included in
a URI, any given parameter-name {\MUSTNOT} appear more than once.


This extensible mechanism includes the \header{transport},
\header{maddr}, \header{ttl}, \header{user}, \header{method}
and \header{lr}
parameters.

\begin{changebar}
The \header{transport} parameter determines the transport mechanism to
be used for sending SIP messages, as specified 
in~\citenorm{draft-ietf-sip-srv}.  SIP can use any network transport
protocol.  Parameter names are defined for UDP
(RFC~768~\citenorm{rfc768}), TCP (RFC~761~\citenorm{rfc761}), and SCTP
(RFC~2960~\citenorm{rfc2960}).  For a SIPS URI, the \header{transport}
parameter {\MUST} indicate a reliable transport.
\end{changebar}

The \header{maddr} parameter indicates the server address to be
contacted for this user, overriding any address derived from the
\header{host} field.  When an \header{maddr} parameter is present, the
\header{port} and \header{transport} components of the URI apply to the
address indicated in the \header{maddr} parameter value. 
\citenorm{draft-ietf-sip-srv}~describes the proper interpretation of the
\header{transport}, \header{maddr}, and \header{hostport} in order to
obtain the destination address, port, and transport for sending a
request. 

\motivation{The \header{maddr} field has been used as a simple form of
loose source routing.  It allows a URI to specify a proxy that
must be traversed en-route to the destination. Continuing to use
the \header{maddr} parameter this way is strongly discouraged (the
mechanisms that enable it are deprecated).  Implementations should 
instead use the \header{Route} mechanism described in this document,
establishing a pre-existing route set if necessary (see
Section~\ref{sec:general:uac:header:ruri}).
This provides a full URI to describe the node to be traversed.}


The \header{ttl} parameter determines the time-to-live value of the UDP
multicast packet and {\MUST} only be used if \header{maddr} is a
multicast address and the transport protocol is UDP.  For example, to
specify to call {\tt alice@atlanta.com} using multicast to
{239.255.255.1} with a ttl of 15, the following URI would be used:

\begin{verbatim}
  sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15
\end{verbatim}


The set of valid \header{telephone-subscriber} strings is a subset of
valid \header{user} strings.  The \header{user} URI parameter
exists to distinguish telephone numbers from user names that happen
to look like telephone numbers.
If the user string contains a telephone number formatted as a 
\header{telephone-subscriber}, the
\header{user} parameter value ``\header{phone}''
{\SHOULD} be present. Even without this parameter,
recipients of SIP and SIPS URIs {\MAY} interpret the pre-@ part as a telephone
number if local restrictions on the name space for user name allow it. 

The method of the SIP request constructed from the URI can be specified 
with the \header{method} parameter. 


The \header{lr} parameter, when present, indicates that the element
responsible for this resource implements the routing mechanisms
specified in this document. This parameter will be used in the URIs
proxies place into \header{Record-Route} header field values, and
may appear in the URIs in a pre-existing route set. 
\motivation{This parameter is used to achieve backwards compatibility
with systems implementing the strict-routing mechanisms of RFC~2543 and the
rfc2543bis drafts up to bis-05. An element preparing to send a request
based on a URI not containing this parameter can assume the receiving
element implements strict-routing and reformat the message to preserve
the information in the \header{Request-URI}.}


Since the uri-parameter mechanism is extensible, SIP elements {\MUST}
silently ignore any uri-parameters that they do not understand.

\item[Headers:] Header fields to be included in a request constructed from the
URI.  

Headers fields in the SIP request can be specified with the ``?''
mechanism within a URI.  The header names and values are encoded in
ampersand separated \header{hname} = \header{hvalue} pairs.  The special
\header{hname} ``\header{body}'' indicates that the associated
\header{hvalue} is the \header{message-body} of the SIP request. 

\end{description}

Table~\ref{tab:url} summarizes the use of SIP and SIPS URI components based on
the context in which the URI appears.  The external column describes
URIs appearing anywhere outside of a SIP message, for instance on a web
page or business card.  Entries marked ``m'' are mandatory, those marked
``o'' are optional, and those marked ``-'' are not allowed.  Elements
processing URIs {\SHOULD} ignore any disallowed components if they are
present.  The second column indicates the default value of an optional
element if it is not present.  ``--'' indicates that the element is
either not optional, or has no default value.

URIs in \header{Contact} header fields have different restrictions
depending on the context in which the header field appears.  One set
applies to messages that establish and maintain dialogs ({\INVITE} and
its 200 (OK) response).  The other applies to registration and
redirection messages ({\REGISTER}, its 200 (OK) response, and 3xx class
responses to any method).

\begin{table}[htbp]
\begin{center}
\begin{tabular}{llcccccc}
  &  &  &  &  &    & dialog  &       \\
  &  &  &  &  & \header{reg./redir.}& \header{Contact}/  &   \\
  & default & \header{Req.-URI} & \header{To} & \header{From} & \header{Contact} & \header{R-R/Route} & external\\
\header{user}            &    --       & o & o & o & o & o & o\\
\header{password}        &    --       & o & o & o & o & o & o\\
\header{host}            &    --       & m & m & m & m & m & m\\
\header{port}            &   (1)       & o & - & - & o & o & o\\ 
\header{user-param}      & \header{ip} & o & o & o & o & o & o\\
\header{method}          & {\INVITE}   & - & - & - & - & - & o\\ 
\header{maddr-param}     &    --       & o & - & - & o & o & o\\ 
\header{ttl-param}       &     1       & o & - & - & o & - & o\\ 
\header{transp.-param}   &   (2)       & o & - & - & o & o & o\\ 
\header{lr-param}        &    --       & o & - & - & - & o & o\\
\header{other-param}     &    --       & o & o & o & o & o & o\\
\header{headers}         &    --       & - & - & - & o & - & o\\
\end{tabular}
\end{center}

(1): The default port value is transport and scheme dependent.
The default is 5060 for sip: using UDP, TCP, or SCTP.
The default is 5061 for sip: using TLS over TCP and sips: over TCP.

(2): The default transport is scheme dependent. For sip:, it is
UDP. For sips:, it is TCP.

\caption{Use and default values of URI components for SIP header field values,
\header{Request-URI} and references}

\label{tab:url}
\end{table}

\subsubsection{Character Escaping Requirements}
\label{sec:url-escaping}

SIP follows the requirements and guidelines of 
RFC~2396~\citenorm{rfc2396} when defining the set of characters that must be
escaped in a SIP URI, and uses its ``"\%" HEX HEX'' mechanism for
escaping.  From RFC~2396~\cite{rfc2396}:

\begin{quote}
The set of characters actually reserved within any given URI component
is defined by that component.  In general, a character is reserved if
the semantics of the URI changes if the character is replaced with its
escaped US-ASCII encoding.~\citenorm{rfc2396}. 
\end{quote}
Excluded US-ASCII characters (RFC~2396~\citenorm{rfc2396}), such as
space and control characters and characters used as URI delimiters, also
{\MUST} be escaped.  URIs {\MUSTNOT} contain unescaped space and control
characters.

For each component, the set of valid BNF expansions defines exactly
which characters may appear unescaped.  All other characters {\MUST} be
escaped. 

For example, ``@'' is not in the set of characters in the user
component, so the user ``j@s0n'' must have at least the @~sign encoded,
as in ``j\%40s0n''.

Expanding the \header{hname} and \header{hvalue} tokens in
Section~\ref{sec:abnf} show that all URI reserved characters in header
field names and values {\MUST} be escaped. 

The \header{telephone-subscriber} subset of the \header{user} component
has special escaping considerations.  The set of characters not reserved
in the RFC~2806~\citenorm{rfc2806} description of
\header{telephone-subscriber} contains a number of characters in various
syntax elements that need to be escaped when used in SIP URIs.  Any
characters occurring in a \header{telephone-subscriber} that do not
appear in an expansion of the BNF for the \header{user} rule {\MUST} be
escaped.

Note that character escaping is not allowed in the host component of a
SIP or SIPS URI (the \% character is not valid in its expansion).  This is
likely to change in the future as requirements for Internationalized
Domain Names are finalized.  Current implementations {\MUSTNOT} attempt
to improve robustness by treating received escaped characters in the
host component as literally equivalent to their unescaped counterpart. 
The behavior required to meet the requirements of IDN may be
significantly different.

\subsubsection{Example SIP and SIPS URIs}
\label{sec:url-examples}

\begin{verbatim}
  sip:alice@atlanta.com
  sip:alice:secretword@atlanta.com;transport=tcp
  sips:alice@atlanta.com?subject=project%20x&priority=urgent
  sip:+1-212-555-1212:1234@gateway.com;user=phone
  sips:1212@gateway.com
  sip:alice@192.0.2.4
  sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
  sip:alice;day=tuesday@atlanta.com
\end{verbatim}

The last sample URI above has a \header{user} field value of
``alice;day=tuesday''.  The escaping rules defined above allow a
semicolon to appear unescaped in this field.  For the purposes of this
protocol, the field is opaque.  The structure of that value is only
useful to the SIP element responsible for the resource. 

\subsubsection{URI Comparison}
\label{sec:uri_comparison}

\begin{changebar}
Some operations in this specification require determining whether two
SIP or SIPS URIs are equivalent.  In this specification, registrars need to
compare bindings in \header{Contact} URIs in {\REGISTER} requests (see
Section~\ref{sec:reg:processing}.)
SIP and SIPS URIs are compared for equality according to the following rules:
\end{changebar}
\begin{itemize}

\begin{changebar}
\item A SIP and SIPS URI are never equivalent.
\end{changebar}

\item Comparison of the \header{userinfo} of SIP and SIPS URIs is case-sensitive. 
This includes \header{userinfo} containing passwords or formatted as
\header{telephone-subscribers}.  Comparison of all other components of
the URI is case-insensitive unless explicitly defined otherwise.

\item The ordering of parameters and header fields is not significant in
comparing SIP and SIPS URIs.  

\item Characters other than those in the ``reserved'' and ``unsafe''
sets (see RFC~2396~\citenorm{rfc2396}) are equivalent to their ``"\%" HEX
HEX'' encoding.

\item An IP address that is the result of a DNS lookup of a host name
does \textbf{not} match that host name.

\item For two URIs to be equal, the \header{user}, \header{password},
\header{host}, and \header{port} components must match. 

A URI omitting the user component will \emph{not} match a
URI that includes one. A URI omitting the password component will 
\textbf{not} match a URI that includes one. 

\begin{changebar} 
A URI omitting any component with a default value will \emph{not}
match a URI explicitly containing that component with its default value.
For instance, 
a URI omitting the optional port component will \emph{not} match a URI
explicitly declaring port 5060. The same is true for
the \header{transport-parameter}, \header{ttl-parameter}, 
\header{user-parameter}, and \header{method} components.

\motivation{Defining sip:user@host to \emph{not} be equivalent to
sip:user@host:5060 is a change from RFC~2543. When deriving addresses
from URIs, equivalent addresses are expected from equivalent URIs.
The URI sip:user@host:5060 will always resolve to port 5060.
The URI sip:user@host may resolve to other ports through the
DNS SRV mechanisms detailed in~\citenorm{draft-ietf-sip-srv}.}
\end{changebar}

\item URI \header{uri-parameter} components are compared as follows 

\begin{itemize}
\item Any \header{uri-parameter} appearing in both URIs must match.

\begin{changebar}
\item A \header{user}, \header{ttl}, or \header{method}
\header{uri-parameter} appearing in only one URI never
matches, even if it contains the default value.
\end{changebar}

\item A URI that includes an \header{maddr} parameter will \emph{not} match a
URI that contains no \header{maddr} parameter.

\item All other \header{uri-parameter}s appearing in only one URI
are ignored when comparing the URIs.
\end{itemize}

\item URI \header{header} components are never ignored. Any present
\header{header} component {\MUST} be present in both URIs and match
for the URIs to match. The matching rules are defined for each
header field in Section~\ref{sec:header-fields}.

\end{itemize}

The URIs within each of the following sets are equivalent: 

\begin{changebar}
\begin{verbatim}
sip:%61lice@atlanta.com;transport=TCP
sip:alice@AtLanTa.CoM;Transport=tcp
\end{verbatim}
\end{changebar}

\begin{verbatim}
sip:carol@chicago.com
sip:carol@chicago.com;newparam=5
sip:carol@chicago.com;security=on
\end{verbatim}

\begin{verbatim}
sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com
sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com
\end{verbatim}

\begin{verbatim}
sip:alice@atlanta.com?subject=project%20x&priority=urgent
sip:alice@atlanta.com?priority=urgent&subject=project%20x
\end{verbatim}

The URIs within each of the following sets are \textbf{not} equivalent:

\begin{verbatim}
SIP:ALICE@AtLanTa.CoM;Transport=udp               (different usernames)
sip:alice@AtLanTa.CoM;Transport=UDP
\end{verbatim}

\begin{changebar}
\begin{verbatim}
sip:bob@biloxi.com                     (can resolve to different ports)
sip:bob@biloxi.com:5060
\end{verbatim}

\begin{verbatim}
sip:bob@biloxi.com                (can resolve to different transports)
sip:bob@biloxi.com;transport=udp
\end{verbatim}

\begin{verbatim}
sip:bob@biloxi.com       (can resolve to different port and transports)
sip:bob@biloxi.com:6000;transport=tcp
\end{verbatim}
\end{changebar}

\begin{verbatim}
sip:carol@chicago.com                      (different header component)
sip:carol@chicago.com?Subject=next%20meeting
\end{verbatim}

\begin{verbatim}
sip:bob@phone21.boxesbybob.com      (even though that's what 
sip:bob@192.0.2.4                    phone21.boxesbybob.com resolves to)
\end{verbatim}

Note that equality is not transitive:

\begin{itemize}
\item[] sip:carol@chicago.com and sip:carol@chicago.com;security=on are 
equivalent
\item[and] sip:carol@chicago.com and sip:carol@chicago.com;security=off 
are equivalent
\item[But] sip:carol@chicago.com;security=on and 
sip:carol@chicago.com;security=off are \textbf{not} equivalent
\end{itemize}

\subsubsection{Forming Requests from a URI}
\label{sec:url-forming-requests}
\label{sec:uri-forming-requests}

An implementation needs to take care when forming requests directly from a
URI.  URIs from business cards, web pages, and even from sources inside
the protocol such as registered contacts may contain inappropriate
header fields or body parts.

An implementation {\MUST} include any provided \header{transport},
\header{maddr}, \header{ttl}, or \header{user} parameter in the
\header{Request-URI} of the formed request.  If the URI contains a
\header{method} parameter, its value {\MUST} be used as the method of
the request.  The \header{method} parameter {\MUSTNOT} be placed in the
\header{Request-URI}.  Unknown URI parameters {\MUST} be placed in the message's
\header{Request-URI}.

An implementation {\SHOULD} treat the presence of any headers or body
parts in the URI as a desire to include them in the message, and choose
to honor the request on a per-component basis.

An implementation {\SHOULDNOT} honor these obviously dangerous header
fields:  \header{From}, \header{Call-ID}, \header{CSeq}, \header{Via},
and \header{Record-Route}.

An implementation {\SHOULDNOT} honor any requested \header{Route} header
field values in order to not be used as an unwitting agent in malicious
attacks.

An implementation {\SHOULDNOT} honor requests to include header fields that
may cause it to falsely advertise its location or capabilities.  These
include:  \header{Accept}, \header{Accept-Encoding},
\header{Accept-Language}, \header{Allow}, \header{Contact} (in its
dialog usage), \header{Organization}, \header{Supported}, and
\header{User-Agent}.

An implementation {\SHOULD} verify the accuracy of any requested
descriptive header fields, including:  \header{Content-Disposition},
\header{Content-Encoding}, \header{Content-Language},
\header{Content-Length}, \header{Content-Type}, \header{Date},
\header{Mime-Version}, and \header{Timestamp}.

If the request formed from constructing a message from a given URI is
not a valid SIP request, the URI is invalid.  An implementation
{\MUSTNOT} proceed with transmitting the request.  It should instead
pursue the course of action due an invalid URI in the context it occurs.

\motivation{The constructed request can be invalid in many ways.  These
include, but are not limited to, syntax error in header fields, invalid
combinations of URI parameters, or an incorrect description of the
message body.}

Sending a request formed from a given URI may require capabilities
unavailable to the implementation.  The URI might indicate use of an
unimplemented transport or extension, for example.  An implementation
{\SHOULD} refuse to send these requests rather than modifying them to
match their capabilities.  An implementation {\MUSTNOT} send a request
requiring an extension that it does not support.

\motivation{For example, such a request can be formed through the
presence of a \header{Require} header parameter or a method URI parameter
with an unknown or explicitly unsupported value.}




\subsubsection{Relating SIP URIs and tel URLs}
\label{sec:uri-telephone-subscriber}

When a tel URL (RFC~2806~\citenorm{rfc2806}) is converted to a SIP or
SIPS URI, the entire telephone-subscriber portion of the tel URL,
including any parameters, is placed into the \header{userinfo} part of
the SIP or SIPS URI.

Thus, tel:+358-555-1234567;postd=pp22 becomes
\begin{verbatim}
  sip:+358-555-1234567;postd=pp22@foo.com;user=phone
or
  sips:+358-555-1234567;postd=pp22@foo.com;user=phone
\end{verbatim}
not
\begin{verbatim}
  sip:+358-555-1234567@foo.com;postd=pp22;user=phone
or
  sips:+358-555-1234567@foo.com;postd=pp22;user=phone
\end{verbatim}

In general, equivalent ``tel'' URLs converted to SIP or SIPS URIs in this
fashion may not produce equivalent SIP or SIPS URIs.  The \header{userinfo} of
SIP and SIPS URIs are compared as a case-sensitive string.  Variance in
case-insensitive portions of tel URLs and reordering of tel URL
parameters does not affect tel URL equivalence, but does affect the
equivalence of SIP URIs formed from them.

For example, 
\begin{verbatim}
  tel:+358-555-1234567;postd=pp22 
  tel:+358-555-1234567;POSTD=PP22 
\end{verbatim}
are equivalent, while
\begin{verbatim}
  sip:+358-555-1234567;postd=pp22@foo.com;user=phone
  sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone
\end{verbatim}
are not.

Likewise,
\begin{verbatim}
  tel:+358-555-1234567;postd=pp22;isub=1411
  tel:+358-555-1234567;isub=1411;postd=pp22
\end{verbatim}
are equivalent, while
\begin{verbatim}
  sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone
  sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone
\end{verbatim}
are not.

To mitigate this problem, elements constructing telephone-subscriber
fields to place in the userinfo part of a SIP or SIPS URI {\SHOULD} fold any
case-insensitive portion of telephone-subscriber to lower case, and
order the telephone-subscriber parameters lexically by parameter name. 
(All components of a tel URL except for future-extension parameters are
defined to be compared case-insensitive.)

Following this suggestion, both
\begin{verbatim}
  tel:+358-555-1234567;postd=pp22 
  tel:+358-555-1234567;POSTD=PP22 
\end{verbatim}
become
\begin{verbatim}
  sip:+358-555-1234567;postd=pp22@foo.com;user=phone
\end{verbatim}
and both
\begin{verbatim}
  tel:+358-555-1234567;postd=pp22;isub=1411
  tel:+358-555-1234567;isub=1411;postd=pp22
\end{verbatim}
become
\begin{verbatim}
  sip:+358-555-1234567;isub=1411;postd=pp22;user=phone
\end{verbatim}


\subsection{Option Tags}
\label{sec:option_tags}

Option tags are unique identifiers used to designate new options
(extensions) in SIP.  These tags are used in \header{Require}
(Section~\ref{sec:Require}), \header{Proxy-Require}
(Section~\ref{sec:Proxy-Require}), \header{Supported}
(Section~\ref{sec:Supported}) and \header{Unsupported}
(Section~\ref{sec:Unsupported}) header fields.  Note that these options
appear as parameters in those header fields in an \begin{sf} option-tag =
token \end{sf} form (see Section~\ref{sec:abnf} for the definition of
\header{token}).

Option tags are defined in standards track RFCs. This is a change
from past practice, and is instituted to ensure continuing 
multi-vendor interoperability (see discussion in Section~\ref{sec:Require}
and Section~\ref{sec:Supported}). An IANA registry of option tags is
used to ensure easy reference.

\subsection{Tags}
\label{sec:common-message:tags}

\begin{changebar}
The ``\header{tag}'' parameter is used in the \header{To} and
\header{From} header fields of SIP messages.  It serves as a general mechanism
to identify a dialog, which is the combination of the \header{Call-ID}
along with two tags, one from each participant in the dialog. When a
UA sends a request outside of a dialog, it contains a \header{From}
tag only, providing ``half'' of the dialog ID. The dialog is completed
from the response(s), each of which contributes the second half in the
\header{To} header field. The forking of SIP requests means that multiple
dialogs can be established from a single request. This also explains
the need for the two-sided dialog identifier; without a contribution
from the recipients, the originator could not disambiguate the
multiple dialogs established from a single request.
\end{changebar}

When a tag is generated by a UA for insertion into a request or
response, it {\MUST} be globally unique and cryptographically random
with at least 32 bits of randomness.  A property of this selection
requirement is that a UA will place a different tag into the
\header{From} header of an {\INVITE} as it would place into the
\header{To} header of the response to the same {\INVITE}.  This is
needed in order for a UA to invite itself to a session, a common case
for ``hairpinning'' of calls in PSTN gateways.  Similarly, two
{\INVITE}s for different calls will have different \header{From} tags. 

Besides the requirement for global uniqueness, the algorithm for
generating a tag is implementation-specific.  Tags are helpful in fault
tolerant systems, where a dialog is to be recovered on an alternate
server after a failure.  A UAS can select the tag in such a way that a
backup can recognize a request as part of a dialog on the failed server,
and therefore determine that it should attempt to recover the dialog and
any other state associated with it.

