in Index   Prev   Next

RFC 2543

SIP: Session Initiation Protocol

Pages: 151
Obsoleted by:  32613262326332643265
Part 2 of 6 – Pages 20 to 50
First   Prev   Next

ToP   noToC   RFC2543 - Page 20   prevText

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   noToC   RFC2543 - 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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 ) CRLF [ 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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 proxies. 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   noToC   RFC2543 - 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. Syntax: 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- insensitive.

4.4.1 Registering New Option Tags with IANA

When registering a new SIP option, the following information MUST be provided: 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   noToC   RFC2543 - 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 ) CRLF [ 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   noToC   RFC2543 - 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 request; 2xx: Success -- the action was successfully received, understood, and accepted; 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 request; 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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 SIP.
ToP   noToC   RFC2543 - 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 invocation. 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   noToC   RFC2543 - 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 application/sdp. 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. Example: 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 [H14.3].
ToP   noToC   RFC2543 - 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 caller. Example: 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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 communications. INVITE and ACK requests: INVITE and ACK requests MAY contain Contact headers indicating from which location the request is originating. 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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   noToC   RFC2543 - 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 Section