tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 2543


SIP: Session Initiation Protocol

Part 2 of 6, p. 20 to 50
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 20 
2 SIP Uniform Resource Locators

   SIP URLs are used within SIP messages to indicate the originator
   (From), current destination (Request-URI) and final recipient (To) of
   a SIP request, and to specify redirection addresses (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 request-header
   fields and the SIP message-body.

        This corresponds to the use of 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 [12] and has the syntax
   shown in Fig. 3. The syntax is described using Augmented Backus-Naur
   Form (See Section C). Note that 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" [12].

Top      Up      ToC       Page 21 
  SIP-URL         = "sip:" [ userinfo "@" ] hostport
                    url-parameters [ headers ]
  userinfo        = user [ ":" password ]
  user            = *( unreserved | escaped
                  | "&" | "=" | "+" | "$" | "," )
  password        = *( unreserved | escaped
                  | "&" | "=" | "+" | "$" | "," )
  hostport        = host [ ":" port ]
  host            = hostname | IPv4address
  hostname        = *( domainlabel "." ) toplabel [ "." ]
  domainlabel     = alphanum | alphanum *( alphanum | "-" ) alphanum
  toplabel        = alpha | alpha *( alphanum | "-" ) alphanum
  IPv4address     = 1*digit "." 1*digit "." 1*digit "." 1*digit
  port            = *digit
  url-parameters  = *( ";" url-parameter )
  url-parameter   = transport-param | user-param | method-param
                  | ttl-param | maddr-param | other-param
  transport-param = "transport=" ( "udp" | "tcp" )
  ttl-param       = "ttl=" ttl
  ttl             = 1*3DIGIT       ; 0 to 255
  maddr-param     = "maddr=" host
  user-param      = "user=" ( "phone" | "ip" )
  method-param    = "method=" Method
  tag-param       = "tag=" UUID
  UUID            = 1*( hex | "-" )
  other-param     = ( token | ( token "=" ( token | quoted-string )))
  headers         = "?" header *( "&" header )
  header          = hname "=" hvalue
  hname           = 1*uric
  hvalue          = *uric
  uric            = reserved | unreserved | escaped
  reserved        = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                    "$" | ","
  digits          = 1*DIGIT

   Figure 3: SIP URL syntax

   The URI character classes referenced above are described in Appendix

   The components of the SIP URI have the following meanings.

Top      Up      ToC       Page 22 
telephone-subscriber  = global-phone-number | local-phone-number
   global-phone-number   = "+" 1*phonedigit [isdn-subaddress]
   local-phone-number    = 1*(phonedigit | dtmf-digit | 
                             pause-character) [isdn-subaddress] 
   isdn-subaddress       = ";isub=" 1*phonedigit
   post-dial             = ";postd=" 1*(phonedigit | dtmf-digit
                         |  pause-character)
   phonedigit            = DIGIT | visual-separator
   visual-separator      = "-" | "."
   pause-character       = one-second-pause | wait-for-dial-tone
   one-second-pause      = "p"
   wait-for-dial-tone    = "w"
   dtmf-digit            = "*" | "#" | "A" | "B" | "C" | "D"

   Figure 4: SIP URL syntax; telephone subscriber

   user: If the host is an Internet telephony gateway, the user field
        MAY also encode a telephone number using the notation of
        telephone-subscriber (Fig. 4). The telephone number is a special
        case of a user name and cannot be distinguished by a BNF. Thus,
        a URL parameter, user, is added to distinguish telephone numbers
        from user names. The phone identifier is to be used when
        connecting to a telephony gateway. Even without this parameter,
        recipients of SIP URLs MAY interpret the pre-@ part as a phone
        number if local restrictions on the name space for user name
        allow it.

   password: The SIP scheme MAY use the format "user:password" in the
        userinfo field. The use of passwords in the userinfo 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.

   host: The 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.

   The issue of IPv6 literal addresses in URLs is being looked at
   elsewhere in the IETF. SIP implementers are advised to keep up to
   date on that activity.

Top      Up      ToC       Page 23 
   port: The port number to send a request to. If not present, the
        procedures outlined in Section 1.4.2 are used to determine the
        port number to send a request to.

   URL parameters: SIP URLs can define specific parameters of the
        request. URL parameters are added after the host component and
        are separated by semi-colons. The transport parameter determines
        the the transport mechanism (UDP or TCP). UDP is to be assumed
        when no explicit transport parameter is included. The maddr
        parameter provides the server address to be contacted for this
        user, overriding the address supplied in the host field.  This
        address is typically a multicast address, but could also be the
        address of a backup server. 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. The user parameter was described above. For example, to
        specify to call using multicast to
        with a ttl of 15, the following URL would be used:;maddr=;ttl=15

   The transport, maddr, and ttl parameters MUST NOT be used in the From
   and To header fields and the Request-URI; they are ignored if

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

   Method: The method of the SIP request can be specified with the
        method parameter.  This parameter MUST NOT be used in the From
        and To header fields and the Request-URI; they are ignored if

   Table 2 summarizes where the components of the SIP URL can be used
   and what default values they assume if not present.

   Examples of SIP URLs are:

Top      Up      ToC       Page 24 
                     default    Req.-URI  To  From  Contact  external
      user           --         x         x   x     x        x
      password       --         x         x         x        x
      host           mandatory  x         x   x     x        x
      port           5060       x         x   x     x        x
      user-param     ip         x         x   x     x        x
      method         INVITE                         x        x
      maddr-param    --                             x        x
      ttl-param      1                              x        x
      transp.-param  --                             x        x
      headers        --                             x        x

   Table 2: Use and default values of URL components  for  SIP  headers,
   Request-URI and references;transport=tcp;user=phone

   Within a SIP message, URLs are used to indicate the source and
   intended destination of a request, redirection addresses and the
   current destination of a request. Normally all these fields will
   contain SIP URLs.

   SIP URLs are case-insensitive, so that for example the two URLs and are equivalent.  All
   URL parameters are included when comparing SIP URLs for equality.

   SIP header fields MAY contain non-SIP URLs. As an example, if a call
   from a telephone is relayed to the Internet via SIP, the SIP From
   header field might contain a phone URL.

3 SIP Message Overview

   SIP is a text-based protocol and uses the ISO 10646 character set in
   UTF-8 encoding (RFC 2279 [21]). Senders MUST terminate lines with a
   CRLF, but receivers MUST also interpret CR and LF by themselves as
   line terminators.

Top      Up      ToC       Page 25 
   Except for the above difference in character sets, much of the
   message syntax is and header fields are identical to HTTP/1.1; rather
   than repeating the syntax and semantics here we use [HX.Y] to refer
   to Section X.Y of the current HTTP/1.1 specification (RFC 2068 [11]).
   In addition, we describe SIP in both prose and an augmented Backus-
   Naur form (ABNF). See section C for an overview of ABNF.

   Note, however, that SIP is not an extension of HTTP.

   Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple SIP
   transactions can be carried in a single TCP connection or UDP
   datagram. UDP datagrams, including all headers, SHOULD NOT be larger
   than the path maximum transmission unit (MTU) if the MTU is known, or
   1500 bytes if the MTU is unknown.

        The 1500 bytes accommodates encapsulation within the
        "typical" ethernet MTU without IP fragmentation. Recent
        studies [22] indicate that an MTU of 1500 bytes is a
        reasonable assumption. The next lower common MTU values are
        1006 bytes for SLIP and 296 for low-delay PPP (RFC 1191
        [23]). Thus, another reasonable value would be a message
        size of 950 bytes, to accommodate packet headers within the
        SLIP MTU without fragmentation.

   A SIP message is either a request from a client to a server, or a
   response from a server to a client.

        SIP-message  =  Request | Response

   Both Request (section 4) and Response (section 5) messages use the
   generic-message format of RFC 822 [24] for transferring entities (the
   body of the message). Both types of messages consist of a start-line,
   one or more header fields (also known as "headers"), an empty line
   (i.e., a line with nothing preceding the carriage-return line-feed
   (CRLF)) indicating the end of the header fields, and an optional
   message-body. To avoid confusion with similar-named headers in HTTP,
   we refer to the headers describing the message body as entity
   headers. These components are described in detail in the upcoming

        generic-message  =  start-line

Top      Up      ToC       Page 26 
                            [ message-body ]

        start-line       =  Request-Line |     ;Section 4.1
                            Status-Line        ;Section 5.1

        message-header  =  ( general-header
                           | request-header
                           | response-header
                           | entity-header )

   In the interest of robustness, any leading empty line(s) MUST be
   ignored. In other words, if the Request or Response message begins
   with one or more CRLF, CR, or LFs, these characters MUST be ignored.

4 Request

   The Request message format is shown below:

        Request  =  Request-Line       ;  Section 4.1
                    *( general-header
                    | request-header
                    | entity-header )
                    [ message-body ]   ;  Section 8

4.1 Request-Line

   The Request-Line begins with a method token, followed by the
   Request-URI and the protocol version, and ending with CRLF. The
   elements are separated by SP characters.  No CR or LF are allowed
   except in the final CRLF sequence.

        Request-Line  =  Method SP Request-URI SP SIP-Version CRLF

Top      Up      ToC       Page 27 
        general-header   =  Accept               ; Section 6.7
                         |  Accept-Encoding      ; Section 6.8
                         |  Accept-Language      ; Section 6.9
                         |  Call-ID              ; Section 6.12
                         |  Contact              ; Section 6.13
                         |  CSeq                 ; Section 6.17
                         |  Date                 ; Section 6.18
                         |  Encryption           ; Section 6.19
                         |  Expires              ; Section 6.20
                         |  From                 ; Section 6.21
                         |  Record-Route         ; Section 6.29
                         |  Timestamp            ; Section 6.36
                         |  To                   ; Section 6.37
                         |  Via                  ; Section 6.40
        entity-header    =  Content-Encoding     ; Section 6.14
                         |  Content-Length       ; Section 6.15
                         |  Content-Type         ; Section 6.16
        request-header   =  Authorization        ; Section 6.11
                         |  Contact              ; Section 6.13
                         |  Hide                 ; Section 6.22
                         |  Max-Forwards         ; Section 6.23
                         |  Organization         ; Section 6.24
                         |  Priority             ; Section 6.25
                         |  Proxy-Authorization  ; Section 6.27
                         |  Proxy-Require        ; Section 6.28
                         |  Route                ; Section 6.33
                         |  Require              ; Section 6.30
                         |  Response-Key         ; Section 6.31
                         |  Subject              ; Section 6.35
                         |  User-Agent           ; Section 6.39
        response-header  =  Allow                ; Section 6.10
                         |  Proxy-Authenticate   ; Section 6.26
                         |  Retry-After          ; Section 6.32
                         |  Server               ; Section 6.34
                         |  Unsupported          ; Section 6.38
                         |  Warning              ; Section 6.41
                         |  WWW-Authenticate     ; Section 6.42

   Table 3: SIP headers

4.2 Methods

   The methods are defined below. Methods that are not supported by a
   proxy or redirect server are treated by that server as if they were
   an OPTIONS method and forwarded accordingly. Methods that are not

Top      Up      ToC       Page 28 
   supported by a user agent server or registrar cause a 501 (Not
   Implemented) response to be returned (Section 7). As in HTTP, the
   Method token is case-sensitive.

        Method  =  "INVITE" | "ACK" | "OPTIONS" | "BYE"
                   | "CANCEL" | "REGISTER"

4.2.1 INVITE

   The INVITE method indicates that the user or service is being invited
   to participate in a session. The message body contains a description
   of the session to which the callee is being invited. For two-party
   calls, the caller indicates the type of media it is able to receive
   and possibly the media it is willing to send as well as their
   parameters such as network destination. A success response MUST
   indicate in its message body which media the callee wishes to receive
   and MAY indicate the media the callee is going to send.

        Not all session description formats have the ability to
        indicate sending media.

   A server MAY automatically respond to an invitation for a conference
   the user is already participating in, identified either by the SIP
   Call-ID or a globally unique identifier within the session
   description, with a 200 (OK) response.

   If a user agent receives an INVITE request for an existing call leg
   with a higher CSeq sequence number than any previous INVITE for the
   same Call-ID, it MUST check any version identifiers in the session
   description or, if there are no version identifiers, the content of
   the session description to see if it has changed. It MUST also
   inspect any other header fields for changes. If there is a change,
   the user agent MUST update any internal state or information
   generated as a result of that header. If the session description has
   changed, the user agent server MUST adjust the session parameters
   accordingly, possibly after asking the user for confirmation.
   (Versioning of the session description can be used to accommodate the
   capabilities of new arrivals to a conference, add or delete media or
   change from a unicast to a multicast conference.)

   This method MUST be supported by SIP proxy, redirect and user agent
   servers as well as clients.

Top      Up      ToC       Page 29 
4.2.2 ACK

   The ACK request confirms that the client has received a final
   response to an INVITE request. (ACK is used only with INVITE
   requests.) 2xx responses are acknowledged by client user agents, all
   other final responses by the first proxy or client user agent to
   receive the response. The Via is always initialized to the host that
   originates the ACK request, i.e., the client user agent after a 2xx
   response or the first proxy to receive a non-2xx final response. The
   ACK request is forwarded as the corresponding INVITE request, based
   on its Request-URI. See Section 10 for details.

   The ACK request MAY contain a message body with the final session
   description to be used by the callee. If the ACK message body is
   empty, the callee uses the session description in the INVITE request.

   A proxy server receiving an ACK request after having sent a 3xx, 4xx,
   5xx, or 6xx response must make a determination about whether the ACK
   is for it, or for some user agent or proxy server further downstream.
   This determination is made by examining the tag in the To field. If
   the tag in the ACK To header field matches the tag in the To header
   field of the response, and the From, CSeq and Call-ID header fields
   in the response match those in the ACK, the ACK is meant for the
   proxy server. Otherwise, the ACK SHOULD be proxied downstream as any
   other request.

        It is possible for a user agent client or proxy server to
        receive multiple 3xx, 4xx, 5xx, and 6xx responses to a
        request along a single branch. This can happen under
        various error conditions, typically when a forking proxy
        transitions from stateful to stateless before receiving all
        responses. The various responses will all be identical,
        except for the tag in the To field, which is different for
        each one. It can therefore be used as a means to
        disambiguate them.

   This method MUST be supported by SIP proxy, redirect and user agent
   servers as well as clients.


   The server is being queried as to its capabilities. A server that
   believes it can contact the user, such as a user agent where the user
   is logged in and has been recently active, MAY respond to this
   request with a capability set. A called user agent MAY return a
   status reflecting how it would have responded to an invitation, e.g.,

Top      Up      ToC       Page 30 
   600 (Busy). Such a server SHOULD return an Allow header field
   indicating the methods that it supports. Proxy and redirect servers
   simply forward the request without indicating their capabilities.

   This method MUST be supported by SIP proxy, redirect and user agent
   servers, registrars and clients.

4.2.4 BYE

   The user agent client uses BYE to indicate to the server that it
   wishes to release the call. A BYE request is forwarded like an INVITE
   request and MAY be issued by either caller or callee. A party to a
   call SHOULD issue a BYE request before releasing a call ("hanging
   up"). A party receiving a BYE request MUST cease transmitting media
   streams specifically directed at the party issuing the BYE request.

   If the INVITE request contained a Contact header, the callee SHOULD
   send a BYE request to that address rather than the From address.

   This method MUST be supported by proxy servers and SHOULD be
   supported by redirect and user agent SIP servers.

4.2.5 CANCEL

   The CANCEL request cancels a pending request with the same Call-ID,
   To, From and CSeq (sequence number only) header field values, but
   does not affect a completed request. (A request is considered
   completed if the server has returned a final status response.)

   A user agent client or proxy client MAY issue a CANCEL request at any
   time. A proxy, in particular, MAY choose to send a CANCEL to
   destinations that have not yet returned a final response after it has
   received a 2xx or 6xx response for one or more of the parallel-search
   requests. A proxy that receives a CANCEL request forwards the request
   to all destinations with pending requests.

   The Call-ID, To, the numeric part of CSeq and From headers in the
   CANCEL request are identical to those in the original request. This
   allows a CANCEL request to be matched with the request it cancels.
   However, to allow the client to distinguish responses to the CANCEL
   from those to the original request, the CSeq Method component is set
   to CANCEL. The Via header field is initialized to the proxy issuing
   the CANCEL request. (Thus, responses to this CANCEL request only
   reach the issuing proxy.)

   Once a user agent server has received a CANCEL, it MUST NOT issue a
   2xx response for the cancelled original request.

Top      Up      ToC       Page 31 
   A redirect or user agent server receiving a CANCEL request responds
   with a status of 200 (OK) if the transaction exists and a status of
   481 (Transaction Does Not Exist) if not, but takes no further action.
   In particular, any existing call is unaffected.

        The BYE request cannot be used to cancel branches of a
        parallel search, since several branches may, through
        intermediate proxies, find the same user agent server and
        then terminate the call.  To terminate a call instead of
        just pending searches, the UAC must use BYE instead of or
        in addition to CANCEL. While CANCEL can terminate any
        pending request other than ACK or CANCEL, it is typically
        useful only for INVITE. 200 responses to INVITE and 200
        responses to CANCEL are distinguished by the method in the
        Cseq header field, so there is no ambiguity.

   This method MUST be supported by proxy servers and SHOULD be
   supported by all other SIP server types.


   A client uses the REGISTER method to register the address listed in
   the To header field with a SIP server.

   A user agent MAY register with a local server on startup by sending a
   REGISTER request to the well-known "all SIP servers" multicast
   address "" ( This request SHOULD be scoped
   to ensure it is not forwarded beyond the boundaries of the
   administrative system. This MAY be done with either TTL or
   administrative scopes [25], depending on what is implemented in the
   network. SIP user agents MAY listen to that address and use it to
   become aware of the location of other local users [20]; however, they
   do not respond to the request.  A user agent MAY also be configured
   with the address of a registrar server to which it sends a REGISTER
   request upon startup.

   Requests are processed in the order received. Clients SHOULD avoid
   sending a new registration (as opposed to a retransmission) until
   they have received the response from the server for the previous one.

        Clients may register from different locations, by necessity
        using different Call-ID values. Thus, the CSeq value cannot
        be used to enforce ordering. Since registrations are
        additive, ordering is less of a problem than if each
        REGISTER request completely replaced all earlier ones.

Top      Up      ToC       Page 32 
   The meaning of the REGISTER request-header fields is defined as
   follows. We define "address-of-record" as the SIP address that the
   registry knows the registrand, typically of the form "user@domain"
   rather than "user@host". In third-party registration, the entity
   issuing the request is different from the entity being registered.

   To: The To header field contains the address-of-record whose
        registration is to be created or updated.

   From: The From header field contains the address-of-record of the
        person responsible for the registration. For first-party
        registration, it is identical to the To header field value.

   Request-URI: The Request-URI names the destination of the
        registration request, i.e., the domain of the registrar. The
        user name MUST be empty. Generally, the domains in the Request-
        URI and the To header field have the same value; however, it is
        possible to register as a "visitor", while maintaining one's
        name. For example, a traveler (To) might
        register under the Request-URI , with the
        former as the To header field and the latter as the Request-URI.
        The REGISTER request is no longer forwarded once it has reached
        the server whose authoritative domain is the one listed in the

   Call-ID: All registrations from a client SHOULD use the same Call-ID
        header value, at least within the same reboot cycle.

   Cseq: Registrations with the same Call-ID MUST have increasing CSeq
        header values. However, the server does not reject out-of-order

   Contact: The request MAY contain a Contact header field; future non-
        REGISTER requests for the URI given in the To header field
        SHOULD be directed to the address(es) given in the Contact

   If the request does not contain a Contact header, the registration
   remains unchanged.

        This is useful to obtain the current list of registrations
        in the response.  Registrations using SIP URIs that differ
        in one or more of host, port, transport-param or maddr-
        param (see Figure 3) from an existing registration are
        added to the list of registrations. Other URI types are
        compared according to the standard URI equivalency rules
        for the URI schema. If the URIs are equivalent to that of
        an existing registration, the new registration replaces the

Top      Up      ToC       Page 33 
        old one if it has a higher q value or, for the same value
        of q, if the ttl value is higher. All current registrations
        MUST share the same action value.  Registrations that have
        a different action than current registrations for the same
        user MUST be rejected with status of 409 (Conflict).

   A proxy server ignores the q parameter when processing non-REGISTER
   requests, while a redirect server simply returns that parameter in
   its Contact response header field.

        Having the proxy server interpret the q parameter is not
        sufficient to guide proxy behavior, as it is not clear, for
        example, how long it is supposed to wait between trying

   If the registration is changed while a user agent or proxy server
   processes an invitation, the new information SHOULD be used.

        This allows a service known as "directed pick-up". In the
        telephone network, directed pickup permits a user at a
        remote station who hears his own phone ringing to pick up
        at that station, dial an access code, and be connected to
        the calling user as if he had answered his own phone.

   A server MAY choose any duration for the registration lifetime.
   Registrations not refreshed after this amount of time SHOULD be
   silently discarded. Responses to a registration SHOULD include an
   Expires header (Section 6.20) or expires Contact parameters (Section
   6.13), indicating the time at which the server will drop the
   registration. If none is present, one hour is assumed. Clients MAY
   request a registration lifetime by indicating the time in an Expires
   header in the request. A server SHOULD NOT use a higher lifetime than
   the one requested, but MAY use a lower one. A single address (if
   host-independent) MAY be registered from several different clients.

   A client cancels an existing registration by sending a REGISTER
   request with an expiration time (Expires) of zero seconds for a
   particular Contact or the wildcard Contact designated by a "*" for
   all registrations. Registrations are matched based on the user, host,
   port and maddr parameters.

   The server SHOULD return the current list of registrations in the 200
   response as Contact header fields.

   It is particularly important that REGISTER requests are authenticated
   since they allow to redirect future requests (see Section 13.2).

Top      Up      ToC       Page 34 
        Beyond its use as a simple location service, this method is
        needed if there are several SIP servers on a single host.
        In that case, only one of the servers can use the default
        port number.

   Support of this method is RECOMMENDED.

4.3 Request-URI

   The Request-URI is a SIP URL as described in Section 2 or a general
   URI. It indicates the user or service to which this request is being
   addressed. Unlike the To field, the Request-URI MAY be re-written by

   When used as a Request-URI, a SIP-URL MUST NOT contain the
   transport-param, maddr-param, ttl-param, or headers elements. A
   server that receives a SIP-URL with these elements removes them
   before further processing.

        Typically, the UAC sets the Request-URI and To to the same
        SIP URL, presumed to remain unchanged over long time
        periods. However, if the UAC has cached a more direct path
        to the callee, e.g., from the Contact header field of a
        response to a previous request, the To would still contain
        the long-term, "public" address, while the Request-URI
        would be set to the cached address.

   Proxy and redirect servers MAY use the information in the Request-URI
   and request header fields to handle the request and possibly rewrite
   the Request-URI. For example, a request addressed to the generic
   address is proxied to the particular person, e.g., , with the To field remaining as  At , Bob then designates Alice as
   the temporary substitute.

   The host part of the Request-URI typically agrees with one of the
   host names of the receiving server. If it does not, the server SHOULD
   proxy the request to the address indicated or return a 404 (Not
   Found) response if it is unwilling or unable to do so. For example,
   the Request-URI and server host name can disagree in the case of a
   firewall proxy that handles outgoing calls. This mode of operation is
   similar to that of HTTP proxies.

   If a SIP server receives a request with a URI indicating a scheme
   other than SIP which that server does not understand, the server MUST
   return a 400 (Bad Request) response. It MUST do this even if the To

Top      Up      ToC       Page 35 
   header field contains a scheme it does understand.  This is because
   proxies are responsible for processing the Request-URI; the To field
   is of end-to-end significance.

4.3.1 SIP Version

   Both request and response messages include the version of SIP in use,
   and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced
   by SIP/2.0) regarding version ordering, compliance requirements, and
   upgrading of version numbers. To be compliant with this
   specification, applications sending SIP messages MUST include a SIP-
   Version of "SIP/2.0".

4.4 Option Tags

   Option tags are unique identifiers used to designate new options in
   SIP.  These tags are used in Require (Section 6.30) and Unsupported
   (Section 6.38) fields.


        option-tag  =  token

   See Section C for a definition of token. The creator of a new SIP
   option MUST either prefix the option with their reverse domain name
   or register the new option with the Internet Assigned Numbers
   Authority (IANA). For example, "" is an apt name
   for a feature whose inventor can be reached at "".  Individual
   organizations are then responsible for ensuring that option names
   don't collide. Options registered with IANA have the prefix
   "org.iana.sip.", options described in RFCs have the prefix
   "org.ietf.rfc.N", where N is the RFC number. Option tags are case-

4.4.1 Registering New Option Tags with IANA

   When registering a new SIP option, the following information MUST be

        o  Name and description of option. The name MAY be of any
          length, but SHOULD be no more than twenty characters long. The
          name MUST consist of alphanum (See Figure 3) characters only;

Top      Up      ToC       Page 36 
        o  Indication of who has change control over the option (for
          example, IETF, ISO, ITU-T, other international standardization
          bodies, a consortium or a particular company or group of

        o  A reference to a further description, if available, for
          example (in order of preference) an RFC, a published paper, a
          patent filing, a technical report, documented source code or a
          computer manual;

        o  Contact information (postal and email address);

   Registrations should be sent to

        This procedure has been borrowed from RTSP [4] and the RTP
        AVP [26].

5 Response

   After receiving and interpreting a request message, the recipient
   responds with a SIP response message. The response message format is
   shown below:

        Response  =  Status-Line        ;  Section 5.1
                     *( general-header
                     | response-header
                     | entity-header )
                     [ message-body ]   ;  Section 8

   SIP's structure of responses is similar to [H6], but is defined
   explicitly here.

5.1 Status-Line

   The first line of a Response message is the Status-Line, consisting
   of the protocol version (Section 4.3.1) followed by a numeric
   Status-Code and its associated textual phrase, with each element
   separated by SP characters. No CR or LF is allowed except in the
   final CRLF sequence.

        Status-Line  =  SIP-version SP Status-Code SP Reason-Phrase CRLF

Top      Up      ToC       Page 37 
5.1.1 Status Codes and Reason Phrases

   The Status-Code is a 3-digit integer result code that indicates the
   outcome of the attempt to understand and satisfy the request. The
   Reason-Phrase is intended to give a short textual description of the
   Status-Code. The Status-Code is intended for use by automata, whereas
   the Reason-Phrase is intended for the human user. The client is not
   required to examine or display the Reason-Phrase.

        Status-Code     =  Informational                     ;Fig. 5
                       |   Success                           ;Fig. 5
                       |   Redirection                       ;Fig. 6
                       |   Client-Error                      ;Fig. 7
                       |   Server-Error                      ;Fig. 8
                       |   Global-Failure                    ;Fig. 9
                       |   extension-code
        extension-code  =  3DIGIT
        Reason-Phrase   =  *<TEXT-UTF8,  excluding CR, LF>

   We provide an overview of the Status-Code below, and provide full
   definitions in Section 7. The first digit of the Status-Code defines
   the class of response. The last two digits do not have any
   categorization role. SIP/2.0 allows 6 values for the first digit:

   1xx: Informational -- request received, continuing to process the

   2xx: Success -- the action was successfully received, understood, and

   3xx: Redirection -- further action needs to be taken in order to
        complete the request;

   4xx: Client Error -- the request contains bad syntax or cannot be
        fulfilled at this server;

   5xx: Server Error -- the server failed to fulfill an apparently valid

   6xx: Global Failure -- the request cannot be fulfilled at any server.

   Figures 5 through 9 present the individual values of the numeric
   response codes, and an example set of corresponding reason phrases
   for SIP/2.0. These reason phrases are only recommended; they may be
   replaced by local equivalents without affecting the protocol. Note

Top      Up      ToC       Page 38 
   that SIP adopts many HTTP/1.1 response codes. SIP/2.0 adds response
   codes in the range starting at x80 to avoid conflicts with newly
   defined HTTP response codes, and adds a new class, 6xx, of response

   SIP response codes are extensible. SIP applications are not required
   to understand the meaning of all registered response codes, though
   such understanding is obviously desirable. However, applications MUST
   understand the class of any response code, as indicated by the first
   digit, and treat any unrecognized response as being equivalent to the
   x00 response code of that class, with the exception that an
   unrecognized response MUST NOT be cached. For example, if a client
   receives an unrecognized response code of 431, it can safely assume
   that there was something wrong with its request and treat the
   response as if it had received a 400 (Bad Request) response code. In
   such cases, user agents SHOULD present to the user the message body
   returned with the response, since that message body is likely to
   include human-readable information which will explain the unusual

        Informational  =  "100"  ;  Trying
                      |   "180"  ;  Ringing
                      |   "181"  ;  Call Is Being Forwarded
                      |   "182"  ;  Queued
        Success        =  "200"  ;  OK

   Figure 5: Informational and success status codes

        Redirection  =  "300"  ;  Multiple Choices
                    |   "301"  ;  Moved Permanently
                    |   "302"  ;  Moved Temporarily
                    |   "303"  ;  See Other
                    |   "305"  ;  Use Proxy
                    |   "380"  ;  Alternative Service

   Figure 6: Redirection status codes

Top      Up      ToC       Page 39 
        Client-Error  =  "400"  ;  Bad Request
                     |   "401"  ;  Unauthorized
                     |   "402"  ;  Payment Required
                     |   "403"  ;  Forbidden
                     |   "404"  ;  Not Found
                     |   "405"  ;  Method Not Allowed
                     |   "406"  ;  Not Acceptable
                     |   "407"  ;  Proxy Authentication Required
                     |   "408"  ;  Request Timeout
                     |   "409"  ;  Conflict
                     |   "410"  ;  Gone
                     |   "411"  ;  Length Required
                     |   "413"  ;  Request Entity Too Large
                     |   "414"  ;  Request-URI Too Large
                     |   "415"  ;  Unsupported Media Type
                     |   "420"  ;  Bad Extension
                     |   "480"  ;  Temporarily not available
                     |   "481"  ;  Call Leg/Transaction Does Not Exist
                     |   "482"  ;  Loop Detected
                     |   "483"  ;  Too Many Hops
                     |   "484"  ;  Address Incomplete
                     |   "485"  ;  Ambiguous
                     |   "486"  ;  Busy Here

   Figure 7: Client error status codes

        Server-Error  =  "500"  ;  Internal Server Error
                     |   "501"  ;  Not Implemented
                     |   "502"  ;  Bad Gateway
                     |   "503"  ;  Service Unavailable
                     |   "504"  ;  Gateway Time-out
                     |   "505"  ;  SIP Version not supported

   Figure 8: Server error status codes

6 Header Field Definitions

   SIP header fields are similar to HTTP header fields in both syntax
   and semantics. In particular, SIP header fields follow the syntax for
   message-header as described in [H4.2]. The rules for extending header
   fields over multiple lines, and use of multiple message-header fields
   with the same field-name, described in [H4.2] also apply to SIP. The

Top      Up      ToC       Page 40 
        Global-Failure |  "600"  ;  Busy Everywhere
                       |  "603"  ;  Decline
                       |  "604"  ;  Does not exist anywhere
                       |  "606"  ;  Not Acceptable

   Figure 9: Global failure status codes

   rules in [H4.2] regarding ordering of header fields apply to SIP,
   with the exception of Via fields, see below, whose order matters.
   Additionally, header fields which are hop-by-hop MUST appear before
   any header fields which are end-to-end. Proxies SHOULD NOT reorder
   header fields. Proxies add Via header fields and MAY add other hop-
   by-hop header fields. They can modify certain header fields, such as
   Max-Forwards (Section 6.23) and "fix up" the Via header fields with
   "received" parameters as described in Section 6.40.1. Proxies MUST
   NOT alter any fields that are authenticated (see Section 13.2).

   The header fields required, optional and not applicable for each
   method are listed in Table 4 and Table 5. The table uses "o" to
   indicate optional, "m" mandatory and "-" for not applicable. A "*"
   indicates that the header fields are needed only if message body is
   not empty. See sections 6.15, 6.16 and 8 for details.

   The "where" column describes the request and response types with
   which the header field can be used. "R" refers to header fields that
   can be used in requests (that is, request and general header fields).
   "r" designates a response or general-header field as applicable to
   all responses, while a list of numeric values indicates the status
   codes with which the header field can be used. "g" and "e" designate
   general (Section 6.1) and entity header (Section 6.2) fields,
   respectively. If a header field is marked "c", it is copied from the
   request to the response.

   The "enc." column describes whether this message header field MAY be
   encrypted end-to-end. A "n" designates fields that MUST NOT be
   encrypted, while "c" designates fields that SHOULD be encrypted if
   encryption is used.

   The "e-e" column has a value of "e" for end-to-end and a value of "h"
   for hop-by-hop header fields.

Top      Up      ToC       Page 41 
                          where  enc.  e-e ACK BYE CAN INV OPT REG
        Accept              R           e   -   -   -   o   o   o
        Accept             415          e   -   -   -   o   o   o
        Accept-Encoding     R           e   -   -   -   o   o   o
        Accept-Encoding    415          e   -   -   -   o   o   o
        Accept-Language     R           e   -   o   o   o   o   o
        Accept-Language    415          e   -   o   o   o   o   o
        Allow              200          e   -   -   -   -   m   -
        Allow              405          e   o   o   o   o   o   o
        Authorization       R           e   o   o   o   o   o   o
        Call-ID            gc     n     e   m   m   m   m   m   m
        Contact             R           e   o   -   -   o   o   o
        Contact            1xx          e   -   -   -   o   o   -
        Contact            2xx          e   -   -   -   o   o   o
        Contact            3xx          e   -   o   -   o   o   o
        Contact            485          e   -   o   -   o   o   o
        Content-Encoding    e           e   o   -   -   o   o   o
        Content-Length      e           e   o   -   -   o   o   o
        Content-Type        e           e   *   -   -   *   *   *
        CSeq               gc     n     e   m   m   m   m   m   m
        Date                g           e   o   o   o   o   o   o
        Encryption          g     n     e   o   o   o   o   o   o
        Expires             g           e   -   -   -   o   -   o
        From               gc     n     e   m   m   m   m   m   m
        Hide                R     n     h   o   o   o   o   o   o
        Max-Forwards        R     n     e   o   o   o   o   o   o
        Organization        g     c     h   -   -   -   o   o   o

   Table 4: Summary of header fields, A--O

   Other header fields can be added as required; a server MUST ignore
   header fields not defined in this specification that it does not
   understand. A proxy MUST NOT remove or modify header fields not
   defined in this specification that it does not understand. A compact
   form of these header fields is also defined in Section 9 for use over
   UDP when the request has to fit into a single packet and size is an

   Table 6 in Appendix A lists those header fields that different client
   and server types MUST be able to parse.

6.1 General Header Fields

   General header fields apply to both request and response messages.
   The "general-header" field names can be extended reliably only in
   combination with a change in the protocol version. However, new or

Top      Up      ToC       Page 42 
                            where     enc.  e-e ACK BYE CAN INV OPT REG
    Proxy-Authenticate       407       n     h   o   o   o   o   o   o
    Proxy-Authorization       R        n     h   o   o   o   o   o   o
    Proxy-Require             R        n     h   o   o   o   o   o   o
    Priority                  R        c     e   -   -   -   o   -   -
    Require                   R              e   o   o   o   o   o   o
    Retry-After               R        c     e   -   -   -   -   -   o
    Retry-After          404,480,486   c     e   o   o   o   o   o   o
                             503       c     e   o   o   o   o   o   o
                           600,603     c     e   o   o   o   o   o   o
    Response-Key              R        c     e   -   o   o   o   o   o
    Record-Route              R              h   o   o   o   o   o   o
    Record-Route             2xx             h   o   o   o   o   o   o
    Route                     R              h   o   o   o   o   o   o
    Server                    r        c     e   o   o   o   o   o   o
    Subject                   R        c     e   -   -   -   o   -   -
    Timestamp                 g              e   o   o   o   o   o   o
    To                      gc(1)      n     e   m   m   m   m   m   m
    Unsupported              420             e   o   o   o   o   o   o
    User-Agent                g        c     e   o   o   o   o   o   o
    Via                     gc(2)      n     e   m   m   m   m   m   m
    Warning                   r              e   o   o   o   o   o   o
    WWW-Authenticate         401       c     e   o   o   o   o   o   o

   Table 5: Summary of header fields, P--Z; (1):  copied  with  possible
   addition of tag; (2): UAS removes first Via header field

   experimental header fields MAY be given the semantics of general
   header fields if all parties in the communication recognize them to
   be "general-header" fields. Unrecognized header fields are treated as
   "entity-header" fields.

6.2 Entity Header Fields

   The "entity-header" fields define meta-information about the
   message-body or, if no body is present, about the resource identified
   by the request. The term "entity header" is an HTTP 1.1 term where
   the response body can contain a transformed version of the message
   body.  The original message body is referred to as the "entity". We
   retain the same terminology for header fields but usually refer to
   the "message body" rather then the entity as the two are the same in

Top      Up      ToC       Page 43 
6.3 Request Header Fields

   The "request-header" fields allow the client to pass additional
   information about the request, and about the client itself, to the
   server. These fields act as request modifiers, with semantics
   equivalent to the parameters of a programming language method

   The "request-header" field names can be extended reliably only in
   combination with a change in the protocol version. However, new or
   experimental header fields MAY be given the semantics of "request-
   header" fields if all parties in the communication recognize them to
   be request-header fields. Unrecognized header fields are treated as
   "entity-header" fields.

6.4 Response Header Fields

   The "response-header" fields allow the server to pass additional
   information about the response which cannot be placed in the Status-
   Line. These header fields give information about the server and about
   further access to the resource identified by the Request-URI.

   Response-header field names can be extended reliably only in
   combination with a change in the protocol version. However, new or
   experimental header fields MAY be given the semantics of "response-
   header" fields if all parties in the communication recognize them to
   be "response-header" fields. Unrecognized header fields are treated
   as "entity-header" fields.

6.5 End-to-end and Hop-by-hop Headers

   End-to-end headers MUST be transmitted unmodified across all proxies,
   while hop-by-hop headers MAY be modified or added by proxies.

6.6 Header Field Format

   Header fields ("general-header", "request-header", "response-header",
   and "entity-header") follow the same generic header format as that
   given in Section 3.1 of RFC 822 [24]. Each header field consists of a
   name followed by a colon (":") and the field value. Field names are
   case-insensitive. The field value MAY be preceded by any amount of
   leading white space (LWS), though a single space (SP) is preferred.
   Header fields can be extended over multiple lines by preceding each
   extra line with at least one SP or horizontal tab (HT). Applications
   MUST follow HTTP "common form" when generating these constructs,
   since there might exist some implementations that fail to accept
   anything beyond the common forms.

Top      Up      ToC       Page 44 
        message-header  =  field-name ":" [ field-value ] CRLF
        field-name      =  token
        field-value     =  *( field-content | LWS )
        field-content   =  < the OCTETs  making up the field-value
                            and consisting of either *TEXT-UTF8
                            or combinations of token,
                            separators, and quoted-string>

   The relative order of header fields with different field names is not
   significant. Multiple header fields with the same field-name may be
   present in a message if and only if the entire field-value for that
   header field is defined as a comma-separated list (i.e., #(values)).
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma. The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.

   Field names are not case-sensitive, although their values may be.

6.7 Accept

   The Accept header follows the syntax defined in [H14.1]. The
   semantics are also identical, with the exception that if no Accept
   header is present, the server SHOULD assume a default value of

   This request-header field is used only with the INVITE, OPTIONS and
   REGISTER request methods to indicate what media types are acceptable
   in the response.


     Accept: application/sdp;level=1, application/x-private, text/html

6.8 Accept-Encoding

   The Accept-Encoding request-header field is similar to Accept, but
   restricts the content-codings [H3.4.1] that are acceptable in the
   response. See [H14.3]. The syntax of this header is defined in
   [H14.3]. The semantics in SIP are identical to those defined in

Top      Up      ToC       Page 45 
6.9 Accept-Language

   The Accept-Language header follows the syntax defined in [H14.4]. The
   rules for ordering the languages based on the q parameter apply to
   SIP as well. When used in SIP, the Accept-Language request-header
   field can be used to allow the client to indicate to the server in
   which language it would prefer to receive reason phrases, session
   descriptions or status responses carried as message bodies. A proxy
   MAY use this field to help select the destination for the call, for
   example, a human operator conversant in a language spoken by the


     Accept-Language: da, en-gb;q=0.8, en;q=0.7

6.10 Allow

   The Allow entity-header field lists the set of methods supported by
   the resource identified by the Request-URI. The purpose of this field
   is strictly to inform the recipient of valid methods associated with
   the resource. An Allow header field MUST be present in a 405 (Method
   Not Allowed) response and SHOULD be present in an OPTIONS response.

        Allow  =  "Allow" ":" 1#Method

6.11 Authorization

   A user agent that wishes to authenticate itself with a server --
   usually, but not necessarily, after receiving a 401 response -- MAY
   do so by including an Authorization request-header field with the
   request. The Authorization field value consists of credentials
   containing the authentication information of the user agent for the
   realm of the resource being requested.

   Section 13.2 overviews the use of the Authorization header, and
   section 15 describes the syntax and semantics when used with PGP
   based authentication.

Top      Up      ToC       Page 46 
6.12 Call-ID

   The Call-ID general-header field uniquely identifies a particular
   invitation or all registrations of a particular client. Note that a
   single multimedia conference can give rise to several calls with
   different Call-IDs, e.g., if a user invites a single individual
   several times to the same (long-running) conference.

   For an INVITE request, a callee user agent server SHOULD NOT alert
   the user if the user has responded previously to the Call-ID in the
   INVITE request. If the user is already a member of the conference and
   the conference parameters contained in the session description have
   not changed, a callee user agent server MAY silently accept the call,
   regardless of the Call-ID. An invitation for an existing Call-ID or
   session can change the parameters of the conference. A client
   application MAY decide to simply indicate to the user that the
   conference parameters have been changed and accept the invitation
   automatically or it MAY require user confirmation.

   A user may be invited to the same conference or call using several
   different Call-IDs. If desired, the client MAY use identifiers within
   the session description to detect this duplication. For example, SDP
   contains a session id and version number in the origin (o) field.

   The REGISTER and OPTIONS methods use the Call-ID value to
   unambiguously match requests and responses. All REGISTER requests
   issued by a single client SHOULD use the same Call-ID, at least
   within the same boot cycle.

        Since the Call-ID is generated by and for SIP, there is no
        reason to deal with the complexity of URL-encoding and
        case-ignoring string comparison.

        Call-ID   =  ( "Call-ID" | "i" ) ":" local-id "@" host
        local-id  =  1*uric

   "host" SHOULD be either a fully qualified domain name or a globally
   routable IP address. If this is the case, the "local-id" SHOULD be an
   identifier consisting of URI characters that is unique within "host".
   Use of cryptographically random identifiers [27] is RECOMMENDED.  If,
   however, host is not an FQDN or globally routable IP address (such as
   a net 10 address), the local-id MUST be globally unique, as opposed

Top      Up      ToC       Page 47 
   to unique within host. These rules guarantee overall global
   uniqueness of the Call-ID. The value for Call-ID MUST NOT be reused
   for a different call.  Call-IDs are case-sensitive.

        Using cryptographically random identifiers provides some
        protection against session hijacking. Call-ID, To and From
        are needed to identify a call leg.  The distinction between
        call and call leg matters in calls with third-party

   For systems which have tight bandwidth constraints, many of the
   mandatory SIP headers have a compact form, as discussed in Section 9.
   These are alternate names for the headers which occupy less space in
   the message. In the case of Call-ID, the compact form is i.

   For example, both of the following are valid:



6.13 Contact

   The Contact general-header field can appear in INVITE, ACK, and
   REGISTER requests, and in 1xx, 2xx, 3xx, and 485 responses. In
   general, it provides a URL where the user can be reached for further

   INVITE and ACK requests: INVITE and ACK requests MAY contain Contact
        headers indicating from which location the request is

        This allows the callee to send future requests, such as
        BYE, directly to the caller instead of through a series of
        proxies.  The Via header is not sufficient since the
        desired address may be that of a proxy.

   INVITE 2xx responses: A user agent server sending a definitive,
        positive response (2xx) MAY insert a Contact response header
        field indicating the SIP address under which it is reachable
        most directly for future SIP requests, such as ACK, within the

Top      Up      ToC       Page 48 
        same Call-ID. The Contact header field contains the address of
        the server itself or that of a proxy, e.g., if the host is
        behind a firewall. The value of this Contact header is copied
        into the Request-URI of subsequent requests for this call if the
        response did not also contain a Record-Route header. If the
        response also contains a Record-Route header field, the address
        in the Contact header field is added as the last item in the
        Route header field. See Section 6.29 for details.

        The Contact value SHOULD NOT be cached across calls, as it
        may not represent the most desirable location for a
        particular destination address.

   INVITE 1xx responses: A UAS sending a provisional response (1xx) MAY
        insert a Contact response header. It has the same semantics in a
        1xx response as a 2xx INVITE response. Note that CANCEL requests
        MUST NOT be sent to that address, but rather follow the same
        path as the original request.

   REGISTER requests: REGISTER requests MAY contain a Contact header
        field indicating at which locations the user is reachable. The
        REGISTER request defines a wildcard Contact field, "*", which
        MUST only be used with Expires: 0 to remove all registrations
        for a particular user. An optional "expires" parameter indicates
        the desired expiration time of the registration. If a Contact
        entry does not have an "expires" parameter, the Expires header
        field is used as the default value. If neither of these
        mechanisms is used, SIP URIs are assumed to expire after one
        hour. Other URI schemes have no expiration times.

   REGISTER 2xx responses: A REGISTER response MAY return all locations
        at which the user is currently reachable.  An optional "expires"
        parameter indicates the expiration time of the registration. If
        a Contact entry does not have an "expires" parameter, the value
        of the Expires header field indicates the expiration time. If
        neither mechanism is used, the expiration time specified in the
        request, explicitly or by default, is used.

   3xx and 485 responses: The Contact response-header field can be used
        with a 3xx or 485 (Ambiguous) response codes to indicate one or
        more alternate addresses to try. It can appear in responses to
        BYE, INVITE and OPTIONS methods. The Contact header field
        contains URIs giving the new locations or user names to try, or
        may simply specify additional transport parameters. A 300
        (Multiple Choices), 301 (Moved Permanently), 302 (Moved
        Temporarily) or 485 (Ambiguous) response SHOULD contain a
        Contact field containing URIs of new addresses to be tried. A

Top      Up      ToC       Page 49 
        301 or 302 response may also give the same location and username
        that was being tried but specify additional transport parameters
        such as a different server or multicast address to try or a
        change of SIP transport from UDP to TCP or vice versa. The
        client copies the "user", "password", "host", "port" and "user-
        param" elements of the Contact URI into the Request-URI of the
        redirected request and directs the request to the address
        specified by the "maddr" and "port" parameters, using the
        transport protocol given in the "transport" parameter. If
        "maddr" is a multicast address, the value of "ttl" is used as
        the time-to-live value.

   Note that the Contact header field MAY also refer to a different
   entity than the one originally called. For example, a SIP call
   connected to GSTN gateway may need to deliver a special information
   announcement such as "The number you have dialed has been changed."

   A Contact response header field can contain any suitable URI
   indicating where the called party can be reached, not limited to SIP
   URLs. For example, it could contain URL's for phones, fax, or irc (if
   they were defined) or a mailto: (RFC 2368, [28]) URL.

   The following parameters are defined. Additional parameters may be
   defined in other specifications.

   q: The "qvalue" indicates the relative preference among the locations
        given. "qvalue" values are decimal numbers from 0 to 1, with
        higher values indicating higher preference.

   action: The "action" parameter is used only when registering with the
        REGISTER request. It indicates whether the client wishes that
        the server proxy or redirect future requests intended for the
        client. If this parameter is not specified the action taken
        depends on server configuration. In its response, the registrar
        SHOULD indicate the mode used. This parameter is ignored for
        other requests.

   expires: The "expires" parameter indicates how long the URI is valid.
        The parameter is either a number indicating seconds or a quoted
        string containing a SIP-date. If this parameter is not provided,
        the value of the Expires header field determines how long the
        URI is valid. Implementations MAY treat values larger than
        2**32-1 (4294967295 seconds or 136 years) as equivalent to

   Contact = ( "Contact" | "m" ) ":" 
             ("*" | (1# (( name-addr | addr-spec )
             [ *( ";" contact-params ) ] [ comment ] )))

   name-addr      = [ display-name ] "<" addr-spec ">"
   addr-spec      = SIP-URL | URI
   display-name   = *token | quoted-string

   contact-params = "q"       "=" qvalue
                  | "action"  "=" "proxy" | "redirect"
                  | "expires" "=" delta-seconds | <"> SIP-date <">
                  | extension-attribute

   extension-attribute = extension-name [ "=" extension-value ]

Top      Up      ToC       Page 50 
        only allows one address, unquoted. Since URIs can contain
        commas and semicolons as reserved characters, they can be
        mistaken for header or parameter delimiters, respectively.
        The current syntax corresponds to that for the To and From
        header, which also allows the use of display names.


     Contact: "Mr. Watson" <>
        ;q=0.7; expires=3600,
        "Mr. Watson" <> ;q=0.1

(page 50 continued on part 3)

Next RFC Part