www.Tutorialsforu.info

20.5 Allow

   The Allow header field lists the set of methods supported by the UA
   generating the message.

   All methods, including ACK and CANCEL, understood by the UA MUST be
   included in the list of methods in the Allow header field, when
   present.  The absence of an Allow header field MUST NOT be
   interpreted to mean that the UA sending the message supports no
   methods.   Rather, it implies that the UA is not providing any
   information on what methods it supports.

   Supplying an Allow header field in responses to methods other than
   OPTIONS reduces the number of messages needed.

   Example:

      Allow: INVITE, ACK, OPTIONS, CANCEL, BYE

20.6 Authentication-Info

   The Authentication-Info header field provides for mutual
   authentication with HTTP Digest.  A UAS MAY include this header field
   in a 2xx response to a request that was successfully authenticated
   using digest based on the Authorization header field.

   Syntax and semantics follow those specified in RFC 2617 [17].

   Example:

      Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"

20.7 Authorization

   The Authorization header field contains authentication credentials of
   a UA.  Section 22.2 overviews the use of the Authorization header
   field, and Section 22.4 describes the syntax and semantics when used
   with HTTP authentication.

   This header field, along with Proxy-Authorization, breaks the general
   rules about multiple header field values.  Although not a comma-
   separated list, this header field name may be present multiple times,
   and MUST NOT be combined into a single header line using the usual
   rules described in Section 7.3.


   In the example below, there are no quotes around the Digest
   parameter:

      Authorization: Digest username="Alice", realm="atlanta.com",
       nonce="84a4cc6f3082121f32b42a2187831a9e",
       response="7587245234b3434cc3412213e5f113a5432"

20.8 Call-ID

   The Call-ID header field uniquely identifies a particular invitation
   or all registrations of a particular client.  A single multimedia
   conference can give rise to several calls with different Call-IDs,
   for example, if a user invites a single individual several times to
   the same (long-running) conference.  Call-IDs are case-sensitive and
   are simply compared byte-by-byte.

   The compact form of the Call-ID header field is i.

   Examples:

      Call-ID: 
 This e-mail address is being protected from spambots. You need JavaScript enabled to view it
 
      i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4

20.9 Call-Info

   The Call-Info header field provides additional information about the
   caller or callee, depending on whether it is found in a request or
   response.  The purpose of the URI is described by the "purpose"
   parameter.  The "icon" parameter designates an image suitable as an
   iconic representation of the caller or callee.  The "info" parameter
   describes the caller or callee in general, for example, through a web
   page.  The "card" parameter provides a business card, for example, in
   vCard [36] or LDIF [37] formats.  Additional tokens can be registered
   using IANA and the procedures in Section 27.

   Use of the Call-Info header field can pose a security risk.  If a
   callee fetches the URIs provided by a malicious caller, the callee
   may be at risk for displaying inappropriate or offensive content,
   dangerous or illegal content, and so on.  Therefore, it is
   RECOMMENDED that a UA only render the information in the Call-Info
   header field if it can verify the authenticity of the element that
   originated the header field and trusts that element.  This need not
   be the peer UA; a proxy can insert this header field into requests.

   Example:

   Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
     <http://www.example.com/alice/> ;purpose=info

<< Prev - Next >>