www.Tutorialsforu.info

20.10 Contact

   A Contact header field value provides a URI whose meaning depends on
   the type of request or response it is in.

   A Contact header field value can contain a display name, a URI with
   URI parameters, and header parameters.

   This document defines the Contact parameters "q" and "expires".
   These parameters are only used when the Contact is present in a
   REGISTER request or response, or in a 3xx response.  Additional
   parameters may be defined in other specifications.

   When the header field value contains a display name, the URI
   including all URI parameters is enclosed in "<" and ">".  If no "<"
   and ">" are present, all parameters after the URI are header
   parameters, not URI parameters.  The display name can be tokens, or a
   quoted string, if a larger character set is desired.

   Even if the "display-name" is empty, the "name-addr" form MUST be
   used if the "addr-spec" contains a comma, semicolon, or question
   mark.  There may or may not be LWS between the display-name and the
   "<".

   These rules for parsing a display name, URI and URI parameters, and
   header parameters also apply for the header fields To and From.

      The Contact header field has a role similar to the Location header
      field in HTTP.  However, the HTTP header field 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 compact form of the Contact header field is m (for "moved").

   Examples:

      Contact: "Mr. Watson" <sip:
 This e-mail address is being protected from spambots. You need JavaScript enabled to view it
 >
         ;q=0.7; expires=3600,
         "Mr. Watson" <mailto:
 This e-mail address is being protected from spambots. You need JavaScript enabled to view it
 > ;q=0.1
      m: <sips:bob@192.0.2.4>;expires=60

20.11 Content-Disposition

   The Content-Disposition header field describes how the message body
   or, for multipart messages, a message body part is to be interpreted
   by the UAC or UAS.  This SIP header field extends the MIME Content-
   Type (RFC 2183 [18]).

   Several new "disposition-types" of the Content-Disposition header are
   defined by SIP.  The value "session" indicates that the body part
   describes a session, for either calls or early (pre-call) media.  The
   value "render" indicates that the body part should be displayed or
   otherwise rendered to the user.  Note that the value "render" is used
   rather than "inline" to avoid the connotation that the MIME body is
   displayed as a part of the rendering of the entire message (since the
   MIME bodies of SIP messages oftentimes are not displayed to users).
   For backward-compatibility, if the Content-Disposition header field
   is missing, the server SHOULD assume bodies of Content-Type
   application/sdp are the disposition "session", while other content
   types are "render".

   The disposition type "icon" indicates that the body part contains an
   image suitable as an iconic representation of the caller or callee
   that could be rendered informationally by a user agent when a message
   has been received, or persistently while a dialog takes place.  The
   value "alert" indicates that the body part contains information, such
   as an audio clip, that should be rendered by the user agent in an
   attempt to alert the user to the receipt of a request, generally a
   request that initiates a dialog; this alerting body could for example
   be rendered as a ring tone for a phone call after a 180 Ringing
   provisional response has been sent.

   Any MIME body with a "disposition-type" that renders content to the
   user should only be processed when a message has been properly
   authenticated.

   The handling parameter, handling-param, describes how the UAS should
   react if it receives a message body whose content type or disposition
   type it does not understand.  The parameter has defined values of
   "optional" and "required".  If the handling parameter is missing, the
   value "required" SHOULD be assumed.  The handling parameter is
   described in RFC 3204 [19].

   If this header field is missing, the MIME type determines the default
   content disposition.  If there is none, "render" is assumed.

   Example:

      Content-Disposition: session

<< Prev - Next >>