An example SIP digest authentication exchange is shown in Figure 6.13. The
initial INVITEmessage has no authorization credentials and has received a
407 Proxy Authorization Requiredresponse from the proxy, which con-
tains a Proxy-Authorizationheader describing the nature of the chal-
lenge. After sending an ACKto the proxy, the user agent then resends the
INVITEwith an Authorizationheader containing the encrypted username
and password of the user. The proxy then accepts the credentials, sends a 100
Tryingresponse, and forwards the request to the destination user agent.
The user agent then launches its own authentication challenge with a 401
Unauthorizedresponse. This response is proxied back to the calling user
agent. The SIP user agent then finally does the right thing and resends the
INVITErequest containing both the Proxy-Authorizationwith the cre-
dentials for the proxy and Authenticationheader with the credentials for
the other user agent.
Following are the details of Message 11, which contains both sets of
credentials:INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 4.3.2.1
To: User B <sip:[email protected]>
From: User A <sip:[email protected]>
Call-ID: [email protected]
CSeq: 3 INVITE
Proxy-Authorization: Digest username=”usera”,
realm=”SIP Telephone Company”, nonce=”814f12cec4341a34e6e5a35549”
opaque=””, uri=”sip:proxy.sip.com”, response=”6131d1854834593984587ecc”
Authorization: Digest username=”A”, realm=”userb”,
nonce=”e288df84f1cec4341ade6e5a359”, opaque=””,
uri=”sip:[email protected]”, response=”1d19580cd833064324a787ecc”
Contact: sip:[email protected]
Content-Length: ...In this way, SIP supports both network (server) and user (user agent)
authentication within a call.Extensibility
The SIP protocol was designed to be extensible. As a consequence, the protocol
was designed so that user agents could implement new extensions using new
headers and message bodies without requiring intermediate servers such as
proxies to also support the extensions. By default, a proxy forwards unchanged
unknown request types and headers. The use of the Supportedheader allows
a requestor to inform the network and the other user agent of which extensions
and features it supports, allowing them the option of activating the feature. If it
is required that the feature be understood or activated, there is a Require
header [30], which is included in a request. A user agent receiving such a
request must return an error if it does not understand or support the feature.130 Chapter 6