Section 7 SIP Messages

SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279
   [7]).
   A SIP message is either a request from a client to a server, or a
   response from a server to a client.
   Both Request (section 7.1) and Response (section 7.2) messages use
   the basic format of RFC 2822 [3], even though the syntax differs in
   character set and syntax specifics.  (SIP allows header fields that
   would not be valid RFC 2822 header fields, for example.)  Both types
   of messages consist of a start-line, one or more header fields, an
   empty line indicating the end of the header fields, and an optional
   message-body.
         generic-message  =  start-line
                             *message-header
                             CRLF
                             [ message-body ]
         start-line       =  Request-Line / Status-Line
   The start-line, each message-header line, and the empty line MUST be
   terminated by a carriage-return line-feed sequence (CRLF).  Note that
   the empty line MUST be present even if the message-body is not.
   Except for the above difference in character sets, much of SIP's
   message and header field syntax is 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 2616 [8]).
   However, SIP is not an extension of HTTP.
7.1 Requests
   SIP requests are distinguished by having a Request-Line for a start-
   line.  A Request-Line contains a method name, a Request-URI, and the
   protocol version separated by a single space (SP) character.
   The Request-Line ends with CRLF.  No CR or LF are allowed except in
   the end-of-line CRLF sequence.  No linear whitespace (LWS) is allowed
   in any of the elements.
         Request-Line  =  Method SP Request-URI SP SIP-Version CRLF
      Method: This specification defines six methods: REGISTER for
           registering contact information, INVITE, ACK, and CANCEL for
           setting up sessions, BYE for terminating sessions, and
           OPTIONS for querying servers about their capabilities.  SIP
           extensions, documented in standards track RFCs, may define
           additional methods.
      Request-URI: The Request-URI is a SIP or SIPS URI as described in
           Section 19.1 or a general URI (RFC 2396 [5]).  It indicates
           the user or service to which this request is being addressed.
           The Request-URI MUST NOT contain unescaped spaces or control
           characters and MUST NOT be enclosed in "<>".
           SIP elements MAY support Request-URIs with schemes other than
           "sip" and "sips", for example the "tel" URI scheme of RFC
           2806 [9].  SIP elements MAY translate non-SIP URIs using any
           mechanism at their disposal, resulting in SIP URI, SIPS URI,
           or some other scheme.
      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".  The SIP-Version string is case-insensitive,
           but implementations MUST send upper-case.
           Unlike HTTP/1.1, SIP treats the version number as a literal
           string.  In practice, this should make no difference.
7.2 Responses
   SIP responses are distinguished from requests by having a Status-Line
   as their start-line.  A Status-Line consists of the protocol version
   followed by a numeric Status-Code and its associated textual phrase,
   with each element separated by a single SP character.
   No CR or LF is allowed except in the final CRLF sequence.
      Status-Line  =  SIP-Version SP Status-Code SP Reason-Phrase CRLF
   The Status-Code is a 3-digit integer result code that indicates the
   outcome of an attempt to understand and satisfy a 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.  A client
   is not required to examine or display the Reason-Phrase.
   While this specification suggests specific wording for the reason
   phrase, implementations MAY choose other text, for example, in the
   language indicated in the Accept-Language header field of the
   request.
   The first digit of the Status-Code defines the class of response.
   The last two digits do not have any categorization role.  For this
   reason, any response with a status code between 100 and 199 is
   referred to as a "1xx response", any response with a status code
   between 200 and 299 as a "2xx response", and so on.  SIP/2.0 allows
   six values for the first digit:
      1xx: Provisional -- 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.
   Section 21 defines these classes and describes the individual codes.
7.3 Header Fields
   SIP header fields are similar to HTTP header fields in both syntax
   and semantics.  In particular, SIP header fields follow the [H4.2]
   definitions of syntax for the message-header and the rules for
   extending header fields over multiple lines.  However, the latter is
   specified in HTTP with implicit whitespace and folding.  This
   specification conforms to RFC 2234 [10] and uses only explicit
   whitespace and folding as an integral part of the grammar.
   [H4.2] also specifies that multiple header fields of the same field
   name whose value is a comma-separated list can be combined into one
   header field.  That applies to SIP as well, but the specific rule is
   different because of the different grammars.  Specifically, any SIP
   header whose grammar is of the form
      header  =  "header-name" HCOLON header-value *(COMMA header-value)
   allows for combining header fields of the same name into a comma-
   separated list.  The Contact header field allows a comma-separated
   list unless the header field value is "*".
7.3.1 Header Field Format
   Header fields follow the same generic header format as that given in
   Section 2.2 of RFC 2822 [3].  Each header field consists of a field
   name followed by a colon (":") and the field value.
      field-name: field-value
   The formal grammar for a message-header specified in Section 25
   allows for an arbitrary amount of whitespace on either side of the
   colon; however, implementations should avoid spaces between the field
   name and the colon and use a single space (SP) between the colon and
   the field-value.
      Subject:            lunch
      Subject      :      lunch
      Subject            :lunch
      Subject: lunch
   Thus, the above are all valid and equivalent, but the last is the
   preferred form.
   Header fields can be extended over multiple lines by preceding each
   extra line with at least one SP or horizontal tab (HT).  The line
   break and the whitespace at the beginning of the next line are
   treated as a single SP character.  Thus, the following are
   equivalent:
      Subject: I know you're there, pick up the phone and talk to me!
      Subject: I know you're there,
               pick up the phone
               and talk to me!
   The relative order of header fields with different field names is not
   significant.  However, it is RECOMMENDED that header fields which are
   needed for proxy processing (Via, Route, Record-Route, Proxy-Require,
   Max-Forwards, and Proxy-Authorization, for example) appear towards
   the top of the message to facilitate rapid parsing.  The relative
   order of header field rows with the same field name is important.
   Multiple header field rows 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 (that is, if follows the grammar
   defined in Section 7.3).  It MUST be possible to combine the multiple
   header field rows 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 exceptions
   to this rule are the WWW-Authenticate, Authorization, Proxy-
   Authenticate, and Proxy-Authorization header fields.  Multiple header
   field rows with these names MAY be present in a message, but since
   their grammar does not follow the general form listed in Section 7.3,
   they MUST NOT be combined into a single header field row.
   Implementations MUST be able to process multiple header field rows
   with the same name in any combination of the single-value-per-line or
   comma-separated value forms.
   The following groups of header field rows are valid and equivalent:
      Route: <sip:alice@atlanta.com>
      Subject: Lunch
      Route: <sip:bob@biloxi.com>
      Route: <sip:carol@chicago.com>
      Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
      Route: <sip:carol@chicago.com>
      Subject: Lunch
      Subject: Lunch
      Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>,
             <sip:carol@chicago.com>
   Each of the following blocks is valid but not equivalent to the
   others:
      Route: <sip:alice@atlanta.com>
      Route: <sip:bob@biloxi.com>
      Route: <sip:carol@chicago.com>
      Route: <sip:bob@biloxi.com>
      Route: <sip:alice@atlanta.com>
      Route: <sip:carol@chicago.com>
      Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,
             <sip:bob@biloxi.com>
   The format of a header field-value is defined per header-name.  It
   will always be either an opaque sequence of TEXT-UTF8 octets, or a
   combination of whitespace, tokens, separators, and quoted strings.
   Many existing header fields will adhere to the general form of a
   value followed by a semi-colon separated sequence of parameter-name,
   parameter-value pairs:
         field-name: field-value *(;parameter-name=parameter-value)
   Even though an arbitrary number of parameter pairs may be attached to
   a header field value, any given parameter-name MUST NOT appear more
   than once.
   When comparing header fields, field names are always case-
   insensitive.  Unless otherwise stated in the definition of a
   particular header field, field values, parameter names, and parameter
   values are case-insensitive.  Tokens are always case-insensitive.
   Unless specified otherwise, values expressed as quoted strings are
   case-sensitive.  For example,
      Contact: <sip:alice@atlanta.com>;expires=3600
   is equivalent to
      CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
   and
      Content-Disposition: session;handling=optional
   is equivalent to
      content-disposition: Session;HANDLING=OPTIONAL
   The following two header fields are not equivalent:
      Warning: 370 devnull "Choose a bigger pipe"
      Warning: 370 devnull "CHOOSE A BIGGER PIPE"
7.3.2 Header Field Classification
   Some header fields only make sense in requests or responses.  These
   are called request header fields and response header fields,
   respectively.  If a header field appears in a message not matching
   its category (such as a request header field in a response), it MUST
   be ignored.  Section 20 defines the classification of each header
   field.
7.3.3 Compact Form
   SIP provides a mechanism to represent common header field names in an
   abbreviated form.  This may be useful when messages would otherwise
   become too large to be carried on the transport available to it
   (exceeding the maximum transmission unit (MTU) when using UDP, for
   example).  These compact forms are defined in Section 20.  A compact
   form MAY be substituted for the longer form of a header field name at
   any time without changing the semantics of the message.  A header
   field name MAY appear in both long and short forms within the same
   message.  Implementations MUST accept both the long and short forms
   of each header name.
7.4 Bodies
   Requests, including new requests defined in extensions to this
   specification, MAY contain message bodies unless otherwise noted.
   The interpretation of the body depends on the request method.
   For response messages, the request method and the response status
   code determine the type and interpretation of any message body.  All
   responses MAY include a body.
7.4.1 Message Body Type
   The Internet media type of the message body MUST be given by the
   Content-Type header field.  If the body has undergone any encoding
   such as compression, then this MUST be indicated by the Content-
   Encoding header field; otherwise, Content-Encoding MUST be omitted.
   If applicable, the character set of the message body is indicated as
   part of the Content-Type header-field value.
   The "multipart" MIME type defined in RFC 2046 [11] MAY be used within
   the body of the message.  Implementations that send requests
   containing multipart message bodies MUST send a session description
   as a non-multipart message body if the remote implementation requests
   this through an Accept header field that does not contain multipart.
   SIP messages MAY contain binary bodies or body parts. When no
   explicit charset parameter is provided by the sender, media subtypes
   of the "text" type are defined to have a default charset value of
   "UTF-8".
7.4.2 Message Body Length
   The body length in bytes is provided by the Content-Length header
   field.  Section 20.14 describes the necessary contents of this header
   field in detail.
   The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP.
   (Note: The chunked encoding modifies the body of a message in order
   to transfer it as a series of chunks, each with its own size
   indicator.)
7.5 Framing SIP Messages
   Unlike HTTP, SIP implementations can use UDP or other unreliable
   datagram protocols.  Each such datagram carries one request or
   response.  See Section 18 on constraints on usage of unreliable
   transports.
   Implementations processing SIP messages over stream-oriented
   transports MUST ignore any CRLF appearing before the start-line
   [H4.1].
      The Content-Length header field value is used to locate the end of
      each SIP message in a stream.  It will always be present when SIP
      messages are sent over stream-oriented transports.