|
Page 4 of 16
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 spam bots, you need JavaScript enabled to view it
i:
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
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
|
