18 Transport

   The transport layer is responsible for the actual transmission of
   requests and responses over network transports.  This includes
   determination of the connection to use for a request or response in
   the case of connection-oriented transports.

   The transport layer is responsible for managing persistent
   connections for transport protocols like TCP and SCTP, or TLS over
   those, including ones opened to the transport layer.  This includes
   connections opened by the client or server transports, so that
   connections are shared between client and server transport functions.
   These connections are indexed by the tuple formed from the address,
   port, and transport protocol at the far end of the connection.  When
   a connection is opened by the transport layer, this index is set to
   the destination IP, port and transport.  When the connection is
   accepted by the transport layer, this index is set to the source IP
   address, port number, and transport.  Note that, because the source
   port is often ephemeral, but it cannot be known whether it is
   ephemeral or selected through procedures in [4], connections accepted
   by the transport layer will frequently not be reused.  The result is
   that two proxies in a "peering" relationship using a connection-
   oriented transport frequently will have two connections in use, one
   for transactions initiated in each direction.

   It is RECOMMENDED that connections be kept open for some
   implementation-defined duration after the last message was sent or
   received over that connection.  This duration SHOULD at least equal
   the longest amount of time the element would need in order to bring a
   transaction from instantiation to the terminated state.  This is to
   make it likely that transactions are completed over the same
   connection on which they are initiated (for example, request,
   response, and in the case of INVITE, ACK for non-2xx responses).
   This usually means at least 64*T1 (see Section 17.1.1.1 for a
   definition of T1).  However, it could be larger in an element that
   has a TU using a large value for timer C (bullet 11 of Section 16.6),
   for example.

   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.

18.1 Clients

18.1.1 Sending Requests

   The client side of the transport layer is responsible for sending the
   request and receiving responses.  The user of the transport layer
   passes the client transport the request, an IP address, port,
   transport, and possibly TTL for multicast destinations.

   If a request is within 200 bytes of the path MTU, or if it is larger
   than 1300 bytes and the path MTU is unknown, the request MUST be sent
   using an RFC 2914 [43] congestion controlled transport protocol, such
   as TCP. If this causes a change in the transport protocol from the
   one indicated in the top Via, the value in the top Via MUST be
   changed.  This prevents fragmentation of messages over UDP and
   provides congestion control for larger messages.  However,
   implementations MUST be able to handle messages up to the maximum
   datagram packet size.  For UDP, this size is 65,535 bytes, including
   IP and UDP headers.

      The 200 byte "buffer" between the message size and the MTU
      accommodates the fact that the response in SIP can be larger than
      the request.  This happens due to the addition of Record-Route
      header field values to the responses to INVITE, for example.  With
      the extra buffer, the response can be about 170 bytes larger than
      the request, and still not be fragmented on IPv4 (about 30 bytes

      is consumed by IP/UDP, assuming no IPSec).  1300 is chosen when
      path MTU is not known, based on the assumption of a 1500 byte
      Ethernet MTU.

   If an element sends a request over TCP because of these message size
   constraints, and that request would have otherwise been sent over
   UDP, if the attempt to establish the connection generates either an
   ICMP Protocol Not Supported, or results in a TCP reset, the element
   SHOULD retry the request, using UDP.  This is only to provide
   backwards compatibility with RFC 2543 compliant implementations that
   do not support TCP.  It is anticipated that this behavior will be
   deprecated in a future revision of this specification.

   A client that sends a request to a multicast address MUST add the
   "maddr" parameter to its Via header field value containing the
   destination multicast address, and for IPv4, SHOULD add the "ttl"
   parameter with a value of 1.  Usage of IPv6 multicast is not defined
   in this specification, and will be a subject of future
   standardization when the need arises.

   These rules result in a purposeful limitation of multicast in SIP.
   Its primary function is to provide a "single-hop-discovery-like"
   service, delivering a request to a group of homogeneous servers,
   where it is only required to process the response from any one of
   them.  This functionality is most useful for registrations.  In fact,
   based on the transaction processing rules in Section 17.1.3, the
   client transaction will accept the first response, and view any
   others as retransmissions because they all contain the same Via
   branch identifier.

   Before a request is sent, the client transport MUST insert a value of
   the "sent-by" field into the Via header field.  This field contains
   an IP address or host name, and port.  The usage of an FQDN is
   RECOMMENDED.  This field is used for sending responses under certain
   conditions, described below.  If the port is absent, the default
   value depends on the transport.  It is 5060 for UDP, TCP and SCTP,
   5061 for TLS.

   For reliable transports, the response is normally sent on the
   connection on which the request was received.  Therefore, the client
   transport MUST be prepared to receive the response on the same
   connection used to send the request.  Under error conditions, the
   server may attempt to open a new connection to send the response.  To
   handle this case, the transport layer MUST also be prepared to
   receive an incoming connection on the source IP address from which
   the request was sent and port number in the "sent-by" field.  It also

   MUST be prepared to receive incoming connections on any address and
   port that would be selected by a server based on the procedures
   described in Section 5 of [4].

   For unreliable unicast transports, the client transport MUST be
   prepared to receive responses on the source IP address from which the
   request is sent (as responses are sent back to the source address)
   and the port number in the "sent-by" field.  Furthermore, as with
   reliable transports, in certain cases the response will be sent
   elsewhere.  The client MUST be prepared to receive responses on any
   address and port that would be selected by a server based on the
   procedures described in Section 5 of [4].

   For multicast, the client transport MUST be prepared to receive
   responses on the same multicast group and port to which the request
   is sent (that is, it needs to be a member of the multicast group it
   sent the request to.)

   If a request is destined to an IP address, port, and transport to
   which an existing connection is open, it is RECOMMENDED that this
   connection be used to send the request, but another connection MAY be
   opened and used.

   If a request is sent using multicast, it is sent to the group
   address, port, and TTL provided by the transport user.  If a request
   is sent using unicast unreliable transports, it is sent to the IP
   address and port provided by the transport user.

18.1.2 Receiving Responses

   When a response is received, the client transport examines the top
   Via header field value.  If the value of the "sent-by" parameter in
   that header field value does not correspond to a value that the
   client transport is configured to insert into requests, the response
   MUST be silently discarded.

   If there are any client transactions in existence, the client
   transport uses the matching procedures of Section 17.1.3 to attempt
   to match the response to an existing transaction.  If there is a
   match, the response MUST be passed to that transaction.  Otherwise,
   the response MUST be passed to the core (whether it be stateless
   proxy, stateful proxy, or UA) for further processing.  Handling of
   these "stray" responses is dependent on the core (a proxy will
   forward them, while a UA will discard, for example).

18.2 Servers

18.2.1 Receiving Requests

   A server SHOULD be prepared to receive requests on any IP address,
   port and transport combination that can be the result of a DNS lookup
   on a SIP or SIPS URI [4] that is handed out for the purposes of
   communicating with that server.  In this context, "handing out"
   includes placing a URI in a Contact header field in a REGISTER
   request or a redirect response, or in a Record-Route header field in
   a request or response.  A URI can also be "handed out" by placing it
   on a web page or business card.  It is also RECOMMENDED that a server
   listen for requests on the default SIP ports (5060 for TCP and UDP,
   5061 for TLS over TCP) on all public interfaces.  The typical
   exception would be private networks, or when multiple server
   instances are running on the same host.  For any port and interface
   that a server listens on for UDP, it MUST listen on that same port
   and interface for TCP.  This is because a message may need to be sent
   using TCP, rather than UDP, if it is too large.  As a result, the
   converse is not true.  A server need not listen for UDP on a
   particular address and port just because it is listening on that same
   address and port for TCP.  There may, of course, be other reasons why
   a server needs to listen for UDP on a particular address and port.

   When the server transport receives a request over any transport, it
   MUST examine the value of the "sent-by" parameter in the top Via
   header field value.  If the host portion of the "sent-by" parameter
   contains a domain name, or if it contains an IP address that differs
   from the packet source address, the server MUST add a "received"
   parameter to that Via header field value.  This parameter MUST
   contain the source address from which the packet was received.  This
   is to assist the server transport layer in sending the response,
   since it must be sent to the source IP address from which the request
   came.

   Consider a request received by the server transport which looks like,
   in part:

      INVITE sip:bob@Biloxi.com SIP/2.0
      Via: SIP/2.0/UDP bobspc.biloxi.com:5060

   The request is received with a source IP address of 192.0.2.4.
   Before passing the request up, the transport adds a "received"
   parameter, so that the request would look like, in part:

      INVITE sip:bob@Biloxi.com SIP/2.0
      Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4

   Next, the server transport attempts to match the request to a server
   transaction.  It does so using the matching rules described in
   Section 17.2.3.  If a matching server transaction is found, the
   request is passed to that transaction for processing.  If no match is
   found, the request is passed to the core, which may decide to
   construct a new server transaction for that request.  Note that when
   a UAS core sends a 2xx response to INVITE, the server transaction is
   destroyed.  This means that when the ACK arrives, there will be no
   matching server transaction, and based on this rule, the ACK is
   passed to the UAS core, where it is processed.

18.2.2 Sending Responses

   The server transport uses the value of the top Via header field in
   order to determine where to send a response.  It MUST follow the
   following process:

      o  If the "sent-protocol" is a reliable transport protocol such as
         TCP or SCTP, or TLS over those, the response MUST be sent using
         the existing connection to the source of the original request
         that created the transaction, if that connection is still open.
         This requires the server transport to maintain an association
         between server transactions and transport connections.  If that
         connection is no longer open, the server SHOULD open a
         connection to the IP address in the "received" parameter, if
         present, using the port in the "sent-by" value, or the default
         port for that transport, if no port is specified.  If that
         connection attempt fails, the server SHOULD use the procedures
         in [4] for servers in order to determine the IP address and
         port to open the connection and send the response to.

      o  Otherwise, if the Via header field value contains a "maddr"
         parameter, the response MUST be forwarded to the address listed
         there, using the port indicated in "sent-by", or port 5060 if
         none is present.  If the address is a multicast address, the
         response SHOULD be sent using the TTL indicated in the "ttl"
         parameter, or with a TTL of 1 if that parameter is not present.

      o  Otherwise (for unreliable unicast transports), if the top Via
         has a "received" parameter, the response MUST be sent to the
         address in the "received" parameter, using the port indicated
         in the "sent-by" value, or using port 5060 if none is specified
         explicitly.  If this fails, for example, elicits an ICMP "port
         unreachable" response, the procedures of Section 5 of [4]
         SHOULD be used to determine where to send the response.

      o  Otherwise, if it is not receiver-tagged, the response MUST be
         sent to the address indicated by the "sent-by" value, using the
         procedures in Section 5 of [4].

18.3 Framing

   In the case of message-oriented transports (such as UDP), if the
   message has a Content-Length header field, the message body is
   assumed to contain that many bytes.  If there are additional bytes in
   the transport packet beyond the end of the body, they MUST be
   discarded.  If the transport packet ends before the end of the
   message body, this is considered an error.  If the message is a
   response, it MUST be discarded.  If the message is a request, the
   element SHOULD generate a 400 (Bad Request) response.  If the message
   has no Content-Length header field, the message body is assumed to
   end at the end of the transport packet.

   In the case of stream-oriented transports such as TCP, the Content-
   Length header field indicates the size of the body.  The Content-
   Length header field MUST be used with stream oriented transports.

18.4 Error Handling

   Error handling is independent of whether the message was a request or
   response.

   If the transport user asks for a message to be sent over an
   unreliable transport, and the result is an ICMP error, the behavior
   depends on the type of ICMP error.  Host, network, port or protocol
   unreachable errors, or parameter problem errors SHOULD cause the
   transport layer to inform the transport user of a failure in sending.
   Source quench and TTL exceeded ICMP errors SHOULD be ignored.

   If the transport user asks for a request to be sent over a reliable
   transport, and the result is a connection failure, the transport
   layer SHOULD inform the transport user of a failure in sending.

19 Common Message Components

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

19.1 SIP and SIPS Uniform Resource Indicators

   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:

      o  a user of an online service

      o  an appearance on a multi-line phone

      o  a mailbox on a messaging system

      o  a PSTN number at a gateway service

      o  a group (such as "sales" or "helpdesk") in an organization

   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.

19.1.1 SIP and SIPS URI Components

   The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 [5].
   They use a form similar to the mailto URL, allowing the specification
   of SIP request-header fields and the SIP 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 25.  Its
   general form, in the case of a SIP URI, is:

      sip:user:password@host:port;uri-parameters?headers

   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:

      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
         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 MUST NOT be empty.

         If the host being addressed can process telephone numbers, for
         instance, an Internet telephony gateway, a telephone-
         subscriber field defined in RFC 2806 [9] MAY be used to
         populate the user field.  There are special escaping rules for
         encoding telephone-subscriber fields in SIP and SIPS URIs
         described in Section 19.1.2.

      password: A password associated with the user.  While the SIP and
         SIPS URI syntax allows this field to be present, its use is NOT
         RECOMMENDED, 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 the 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.

      host: The host providing the SIP resource.  The 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.

      port: The port number where the request is to be sent.

      URI parameters: Parameters affecting a request constructed from
         the URI.

         URI parameters are added after the hostport component and are
         separated by semi-colons.

         URI parameters take the form:

            parameter-name "=" parameter-value

         Even though an arbitrary number of URI parameters may be
         included in a URI, any given parameter-name MUST NOT appear
         more than once.

         This extensible mechanism includes the transport, maddr, ttl,
         user, method and lr parameters.

         The transport parameter determines the transport mechanism to
         be used for sending SIP messages, as specified in [4].  SIP can
         use any network transport protocol.  Parameter names are
         defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP
         (RFC 2960 [16]).  For a SIPS URI, the transport parameter MUST
         indicate a reliable transport.

         The maddr parameter indicates the server address to be
         contacted for this user, overriding any address derived from
         the host field.  When an maddr parameter is present, the port
         and transport components of the URI apply to the address
         indicated in the maddr parameter value.  [4] describes the
         proper interpretation of the transport, maddr, and hostport in
         order to obtain the destination address, port, and transport
         for sending a request.

         The 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
         maddr parameter this way is strongly discouraged (the
         mechanisms that enable it are deprecated).  Implementations
         should instead use the Route mechanism described in this
         document, establishing a pre-existing route set if necessary
         (see Section 8.1.1.1).  This provides a full URI to describe
         the node to be traversed.

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

            sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15

         The set of valid telephone-subscriber strings is a subset of
         valid user strings.  The 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 telephone-subscriber, the user
         parameter value "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 method parameter.

         The 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 Record-Route header field values, and
         may appear in the URIs in a pre-existing route set.

         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
         Request-URI.

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

      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 hname = hvalue pairs.  The
         special hname "body" indicates that the associated hvalue is
         the message-body of the SIP request.

   Table 1 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 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).

19.1.2 Character Escaping Requirements

                                                       dialog
                                          reg./redir. Contact/
              default  Req.-URI  To  From  Contact   R-R/Route  external
user          --          o      o    o       o          o         o
password      --          o      o    o       o          o         o
host          --          m      m    m       m          m         m
port          (1)         o      -    -       o          o         o
user-param    ip          o      o    o       o          o         o
method        INVITE      -      -    -       -          -         o
maddr-param   --          o      -    -       o          o         o
ttl-param     1           o      -    -       o          -         o
transp.-param (2)         o      -    -       o          o         o
lr-param      --          o      -    -       -          o         o
other-param   --          o      o    o       o          o         o
headers       --          -      -    -       o          -         o

   (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.

   Table 1: Use and default values of URI components for SIP header
   field values, Request-URI and references

   SIP follows the requirements and guidelines of RFC 2396 [5] 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 [5]:

      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 [5].  Excluded US-
      ASCII characters (RFC 2396 [5]), such as space and control
      characters and characters used as URI delimiters, also MUST be
      escaped.  URIs MUST NOT 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 hname and hvalue tokens in Section 25 show that all URI
   reserved characters in header field names and values MUST be escaped.

   The telephone-subscriber subset of the user component has special
   escaping considerations.  The set of characters not reserved in the
   RFC 2806 [9] description of 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 telephone-subscriber
   that do not appear in an expansion of the BNF for the 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 MUST NOT 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.

19.1.3 Example SIP and SIPS URIs

   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

   The last sample URI above has a 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.

19.1.4 URI Comparison

   Some operations in this specification require determining whether two
   SIP or SIPS URIs are equivalent.  In this specification, registrars
   need to compare bindings in Contact URIs in REGISTER requests (see
   Section 10.3.).  SIP and SIPS URIs are compared for equality
   according to the following rules:

      o  A SIP and SIPS URI are never equivalent.

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

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

      o  Characters other than those in the "reserved" set (see RFC 2396
         [5]) are equivalent to their ""%" HEX HEX" encoding.

      o  An IP address that is the result of a DNS lookup of a host name
         does not match that host name.

      o  For two URIs to be equal, the user, password, host, and port
         components must match.

         A URI omitting the user component will not match a URI that
         includes one.  A URI omitting the password component will not
         match a URI that includes one.

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

            Defining sip:user@host to 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 [4].

      o  URI uri-parameter components are compared as follows:

         -  Any uri-parameter appearing in both URIs must match.

         -  A user, ttl, or method uri-parameter appearing in only one
            URI never matches, even if it contains the default value.

         -  A URI that includes an maddr parameter will not match a URI
            that contains no maddr parameter.

         -  All other uri-parameters appearing in only one URI are
            ignored when comparing the URIs.

      o  URI header components are never ignored.  Any present 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 20.

   The URIs within each of the following sets are equivalent:

   sip:%61lice@atlanta.com;transport=TCP
   sip:alice@AtLanTa.CoM;Transport=tcp

   sip:carol@chicago.com
   sip:carol@chicago.com;newparam=5
   sip:carol@chicago.com;security=on

   sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com
   sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com

   sip:alice@atlanta.com?subject=project%20x&priority=urgent
   sip:alice@atlanta.com?priority=urgent&subject=project%20x

   The URIs within each of the following sets are not equivalent:

   SIP:ALICE@AtLanTa.CoM;Transport=udp             (different usernames)
   sip:alice@AtLanTa.CoM;Transport=UDP

   sip:bob@biloxi.com                   (can resolve to different ports)
   sip:bob@biloxi.com:5060

   sip:bob@biloxi.com              (can resolve to different transports)
   sip:bob@biloxi.com;transport=udp

   sip:bob@biloxi.com     (can resolve to different port and transports)
   sip:bob@biloxi.com:6000;transport=tcp

   sip:carol@chicago.com                    (different header component)
   sip:carol@chicago.com?Subject=next%20meeting

   sip:bob@phone21.boxesbybob.com   (even though that's what
   sip:bob@192.0.2.4                 phone21.boxesbybob.com resolves to)

   Note that equality is not transitive:

      o  sip:carol@chicago.com and sip:carol@chicago.com;security=on are
         equivalent

      o  sip:carol@chicago.com and sip:carol@chicago.com;security=off
         are equivalent

      o  sip:carol@chicago.com;security=on and
         sip:carol@chicago.com;security=off are not equivalent

19.1.5 Forming Requests from a URI

   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 transport, maddr, ttl, or
   user parameter in the Request-URI of the formed request.  If the URI
   contains a method parameter, its value MUST be used as the method of
   the request.  The method parameter MUST NOT be placed in the
   Request-URI.  Unknown URI parameters MUST be placed in the message's
   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 SHOULD NOT honor these obviously dangerous header
   fields: From, Call-ID, CSeq, Via, and Record-Route.

   An implementation SHOULD NOT honor any requested Route header field
   values in order to not be used as an unwitting agent in malicious
   attacks.

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

   An implementation SHOULD verify the accuracy of any requested
   descriptive header fields, including: Content-Disposition, Content-
   Encoding, Content-Language, Content-Length, Content-Type, Date,
   Mime-Version, and 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 MUST
   NOT proceed with transmitting the request.  It should instead pursue
   the course of action due an invalid URI in the context it occurs.

      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 MUST NOT send a request
   requiring an extension that it does not support.

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

19.1.6 Relating SIP URIs and tel URLs

   When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the
   entire telephone-subscriber portion of the tel URL, including any
   parameters, is placed into the userinfo part of the SIP or SIPS URI.

   Thus, tel:+358-555-1234567;postd=pp22 becomes

      sip:+358-555-1234567;postd=pp22@foo.com;user=phone

   or
      sips:+358-555-1234567;postd=pp22@foo.com;user=phone

   not
      sip:+358-555-1234567@foo.com;postd=pp22;user=phone

   or

      sips:+358-555-1234567@foo.com;postd=pp22;user=phone

   In general, equivalent "tel" URLs converted to SIP or SIPS URIs in
   this fashion may not produce equivalent SIP or SIPS URIs.  The
   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,

      tel:+358-555-1234567;postd=pp22
      tel:+358-555-1234567;POSTD=PP22

   are equivalent, while

      sip:+358-555-1234567;postd=pp22@foo.com;user=phone
      sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone

   are not.

   Likewise,

      tel:+358-555-1234567;postd=pp22;isub=1411
      tel:+358-555-1234567;isub=1411;postd=pp22

   are equivalent, while

      sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone
      sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone

   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, excepting isdn-subaddress and post-dial, which occur first and
   in that order.  (All components of a tel URL except for future-
   extension parameters are defined to be compared case-insensitive.)

   Following this suggestion, both

      tel:+358-555-1234567;postd=pp22
      tel:+358-555-1234567;POSTD=PP22

      become

        sip:+358-555-1234567;postd=pp22@foo.com;user=phone

   and both

        tel:+358-555-1234567;tsp=a.b;phone-context=5
        tel:+358-555-1234567;phone-context=5;tsp=a.b

      become

        sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone

19.2 Option Tags

   Option tags are unique identifiers used to designate new options
   (extensions) in SIP.  These tags are used in Require (Section 20.32),
   Proxy-Require (Section 20.29), Supported (Section 20.37) and
   Unsupported (Section 20.40) header fields.  Note that these options
   appear as parameters in those header fields in an option-tag = token
   form (see Section 25 for the definition of 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 20.32 and Section
   20.37).  An IANA registry of option tags is used to ensure easy
   reference.

19.3 Tags

   The "tag" parameter is used in the To and From header fields of SIP
   messages.  It serves as a general mechanism to identify a dialog,
   which is the combination of the 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 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 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.

   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 From
   header of an INVITE than it would place into the 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 INVITEs for different calls will
   have different From tags, and two responses for different calls will
   have different To 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.