re message retransmissions. See Table 4 in RFC 3261 [1] for a sum- mary of SIP timers. Note that gaps in CSeq number do not always indicate a lost message. In the authentication examples in the next section, not every request (and hence CSeq) generated by the UAC will reach the UAS if authentication challenges occur by proxies in the path. 3.8 Authentication Authentication in SIP takes two general forms. One is the authentication of a user agent by a proxy, redirect, or registration server. The other is the Stateful proxy OPTIONS OPTIONS 100 Trying Packet Loss! OPTIONS 200 OK 200 OK OPTIONS 200 OK Figure 3.6 SIP reliability example. SIP: Understanding the Session Initiation Protocol authentication of a user agent by another user agent. Mutual authentication between proxies or a proxy and a user agent is also possible using certificates. A proxy or redirect server might require authentication to allow a user agent to access a service or feature. For example, a proxy server may require authentication before forwarding an INVITE to a gateway or invoking a serv- ice. A registration server may require authentication to prevent incoming call hijacking as described previously. User agents can authenticate each other to verify who they are communicating with, since From header fields are easily forged. SIP supports both a simple lightweight authentication scheme and a very robust scheme. The simple scheme is based on HTTP Digest [9] and uses a simple challenge/response mechanism and a shared secret between the two serv- ers. The other schemes involve cryptographic means to exchange and verify certificates. Using HTTP Digest authentication, a proxy requiring authentication replies to an unauthenticated INVITE with a 407 Proxy Authoriza- tion Required response containing a Proxy-Authenticate header field with the form of the challenge. After sending an ACK for the 407, the user agent can then resend the INVITE with a Proxy- Authorization header field containing the credentials. This request is usually sent using the same C