\section{SIP Uniform Resource Locators}
\label{sec:sip-url}

SIP URLs are used within SIP messages to indicate the originator
(\header{From}), current destination (\header{Request-URI}) and final
recipient (\header{To}) of a SIP request, and to specify redirection
addresses (\header{Contact}).  A SIP URL can also be embedded in web
pages or other hyperlinks to indicate that a particular user or service
can be called via SIP.  When used as a hyperlink, the SIP URL indicates
the use of the {\INVITE} method.

The SIP URL scheme is defined to allow setting SIP
\header{request-header} fields and the SIP \header{message-body}.

\motivation{This corresponds to the use of \header{mailto:} URLs.  It
makes it possible, for example, to specify the subject, urgency or media
types of calls initiated through a web page or as part of an email
message.}

A SIP URL follows the guidelines of RFC 2396 \cite{rfc2396} and has
the syntax shown in Fig.~\ref{fig:url_syntax}.  The syntax is
described using Augmented Backus-Naur Form (see Section
\ref{sec:abnf}).  Although the ABNF described in Section
\ref{sec:abnf} uses implicit whitespace, unescaped whitespace {\MUSTNOT} be
present within a SIP URL. Any \header{reserved} characters
have to be escaped and that the ``set of characters 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''
\cite{rfc2396}.  Excluded US-ASCII characters
\cite[Sec.~2.4.3]{rfc2396}, such as space and control characters and
characters used as URL delimiters, also {\MUST} be escaped. 
URLs {\MUSTNOT} contain unescaped space and control characters.

\begin{figure}[htpb]
\inputtxt{url_syntax}
\caption{SIP URL syntax}
\label{fig:url_syntax}
\end{figure}

The URI character classes referenced above are described in
Appendix~\ref{sec:abnf}.

The components of the SIP URI have the following meanings.

\begin{description}

\item[\header{user}:] The name of the user addressed. Note that this
field {\MAY} be empty where the destination host does not have a notion
of users, e.g., for embedded devices.

\item[\header{telephone-subscriber}:] If the \header{host} is an
Internet telephony gateway, a \header{telephone-subscriber} field {\MAY}
be used instead of a \header{user} field.  The
\header{telephone-subscriber} field uses the notation of RFC 2806
\cite{rfc2806}.  Any characters of the un-escaped
``\header{telephone-subscriber}'' that are not either in the set
``\header{unreserved}'' or ``\header{user-unreserved}'' {\MUST} be
escaped.  The set of characters not reserved in the RFC 2806 description
of \header{telephone-subscriber} contains a number of characters in
various syntax elements that need to be escaped when used in SIP URLs,
for example quotation marks (\%22), hash (\%23), colon (\%3a), at-sign
(\%40) and the ``unwise'' characters, i.e., punctuation of \%5b and
above. 

The telephone number is a special case of a user name
and cannot be distinguished by a BNF.  Thus, a URL parameter,
\header{user}, is added to distinguish telephone numbers from user
names.

The \header{user} parameter value ``\header{phone}'' indicates that the
user part contains a telephone number.  Even without this parameter,
recipients of SIP URLs {\MAY} interpret the pre-@ part as a telephone
number if local restrictions on the name space for user name allow it. 

\item[\header{password}:] The SIP scheme {\MAY} use the format
``\header{user:password}'' in the \header{userinfo} field.  The use of
passwords in the \header{userinfo} 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.

\item[\header{host}:]
The \header{host} part {\SHOULD} be a fully-qualified domain name or
numeric IP address.

The \header{mailto:} URL and RFC 822 email addresses require that
numeric host addresses (``host numbers'') are enclosed in square
brackets (presumably, since host names might be numeric), while host
numbers without brackets are used for all other URLs.  The SIP URL
requires the latter form, without brackets.

\item[\header{port}:] The port number to send a request to. If not
present, the procedures outlined in Section \ref{sec:server} are used
to determine the port number to send a request to.

\item[URL parameters:] SIP URLs can define specific parameters of the
request.  URL parameters are added after the \header{host} component and
are separated by semi-colons.  The \header{transport} parameter
determines the the transport mechanism to be used for sending SIP
requests and responses.  SIP can use any network transport protocol;
parameter names are defined for UDP \cite{rfc768}, TCP \cite{rfc761},
TLS \cite{rfc2246}, and SCTP.  UDP is to be assumed when no explicit
transport parameter is included.  The \header{maddr} parameter indicates
the server address to be contacted for this user, overriding the address
supplied in the \header{host} field.  This address is typically, but not
necessarily, a multicast address.  

\motivation{The \header{maddr} field can be used to force requests from
traveling users to visit a home proxy even if an outbound proxy is
used.}

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.  The \header{user}
parameter was described above.  For example, to specify to call {\tt
j.doe@big.com} using multicast to {239.255.255.1} with a ttl of 15, the
following URL would be used:

\begin{verbatim}
  sip:j.doe@big.com;maddr=239.255.255.1;ttl=15
\end{verbatim}

The \header{transport}, \header{maddr}, and \header{ttl} parameters
{\MUSTNOT} be used in the \header{From} and \header{To} header fields;
they are ignored if present. 

\motivation{For \header{Request-URI}s, these parameters are useful
primarily for outbound proxies.}

Receivers {\MUST} silently ignore any URI parameters that they do not
understand.

\item[Headers:] Headers of the SIP request can be defined with the ``?''
mechanism within a SIP URL.  The special \header{hname}
``\header{body}'' indicates that the associated \header{hvalue} is the
\header{message-body} of the SIP \header{INVITE} request.  Headers
{\MUSTNOT} be used in the \header{From} and \header{To} header fields
and the \header{Request-URI}; they are ignored if present. 
\header{hname} and \header{hvalue} are encodings of a SIP header name
and value, respectively.  All URL reserved characters in the header
names and values {\MUST} be escaped.

\item[Method:] The method of the SIP request can be specified with the
\header{method} parameter.  This parameter {\MUSTNOT} be used in the
\header{From} and \header{To} header fields and the
\header{Request-URI}; they are ignored if present. 

\end{description}

Table~\ref{tab:url} summarizes where the components of the SIP URL can
be used.  Entries marked ``m'' are mandatory, those marked ``o''
are optional, and those marked ``-'' are not allowed. For optional
elements, the second column indicates the default value if the element
is not present.

\begin{table}[htbp]
\begin{center}
\begin{tabular}{llcccccc}
& default & \header{Req.-URI} & \header{To} & \header{From} & \header{Contact} & \header{Rec.-Route} & external\\
\header{user}            &    --       & o & o & o & o & o & o\\
\header{password}        &    --       & o & o & - & o & o & o\\
\header{host}            & mandatory   & m & m & m & m & m & m\\
\header{port}            &   5060      & o & o & o & o & o & o\\ 
\header{user-param}      & \header{ip} & o & o & o & o & o & o\\
\header{method}          & {\INVITE}   & - & - & - & o & - & o\\ 
\header{maddr-param}     &    --       & o & - & - & o & m & o\\ 
\header{ttl-param}       &     1       & o & - & - & o & - & o\\ 
\header{transp.-param}   & \header{udp}& o & - & - & o & - & o\\ 
\header{other-param}     &    --       & o & o & o & o & o & o\\
\header{headers}         &    --       & - & - & - & o & - & o\\
\end{tabular}
\end{center}
\caption{Use and default values of URL components for SIP headers,
\header{Request-URI} and references}

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

Examples of SIP URLs are:
\begin{verbatim}
  sip:j.doe@big.com
  sip:j.doe:secret@big.com;transport=tcp
  sip:j.doe@big.com?subject=project%20x&priority=urgent
  sip:+1-212-555-1212:1234@gateway.com;user=phone
  sip:1212@gateway.com
  sip:alice@10.1.2.3
  sip:alice@example.com
  sip:alice%40example.com@gateway.com
  sip:alice@registrar.com;method=REGISTER
\end{verbatim}

\subsection{SIP URL Comparison}
\label{sec:uri_comparison}

SIP URLs are compared for equality according to the following rules:
\begin{itemize}
\item Comparisons of scheme name (``sip''), domain names, parameter
names and header names are case-insensitive, all other comparisons are
case-sensitive.

\item The ordering of parameters and headers is not significant in
comparing SIP URLs.  

\item \header{user} or \header{telephone-subscriber}, \header{password},
\header{host}, \header{port} and any \header{url-parameter} parameters
of the URI must match.  If one of the components in the previous
sentence is omitted, it matches based on its default value.  (For
example, otherwise equivalent URLs without a port specification and
with port 5060 match.) URL parameters (which excludes
\header{telephone-subscriber}, \header{password}, and \header{port})
not found in both URLs being compared, for which there is no default
value, are ignored, and therefore not included in the comparison
operation. Other URL components not found in both URLs being compared,
for which there is no default value, are included in the comparison
operation, and the result will be that the URLs do not match.


\item Characters other than those in the ``reserved'' and ``unsafe''
sets (see RFC 2396 \cite{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 URL parameters that have no default value are compared only if
they are present in both URLs.
\end{itemize}

Thus, the following URLs are equivalent:
\begin{verbatim}
sip:juser@%65xample.com:5060
sip:juser@ExAmPlE.CoM;Transport=udp
\end{verbatim}
while
\begin{verbatim}
SIP:JUSER@ExAmPlE.CoM;Transport=udp
sip:juser@ExAmPlE.CoM;Transport=UDP
\end{verbatim}
are not.

The following URLs are also equivalent:
\begin{verbatim}
sip:user@domain.com;foo=baz
sip:user@domain.com
\end{verbatim}
while
\begin{verbatim}
sip:user@domain.com
sip:domain.com
\end{verbatim}
are not.

Header fields such as \header{Contact}, \header{From} and \header{To}
are equal if and only if their URIs match under the rules above and if
their header parameters (such as \header{contact-param},
\header{from-param} and \header{to-param}) match in name and parameter
value, where parameter names and token parameter values are compared
ignoring case and quoted-string parameter values are case-sensitive.

\subsection{Non-SIP URLs}
\label{sec:nonsipuri_comparison}

SIP header fields and the \header{Request-URI} {\MAY} contain non-SIP
URLs, with the exceptions noted below.  As an example, if a call from a
telephone is relayed to the Internet via SIP, the SIP \header{From}
header field might contain a \header{tel:} URL \cite{rfc2806}. 

In the following locations, only SIP URLs are allowed:
\begin{itemize}
\item \header{Request-URI} in a {\REGISTER} request;
\item \header{Contact} header field in {\INVITE} and
and 2xx responses to {\INVITE}.
\end{itemize}

Implementations {\MAY} compare non-SIP URLs by treating them as generic
URIs \cite{rfc2396} or, alternatively, compare them byte-by-byte.
