e header field is used to force routing through a proxy for all subsequent requests in a session between two user agents. Normally, the pres- ence of a Contact header field allows user agents to send messages directly bypassing the proxy chain used in the initial request (which probably involved database lookups to locate the called party). A proxy inserting its address into a Record-Route header field overrides this and forces future requests to include a Route header field containing the address of the proxy that forces this proxy to be included. A proxy, such as a firewall control proxy, wishing to implement this inserts the header field containing its own URI, or adds its URI to an already present Record-Route header field. The URI is constructed SO that the URI resolves SIP Header Fields back to the proxy server. The UAS copies the Record-Route header field into the 200 OK response to the request. The header field is forwarded unchanged by proxies back to the UAC. The UAC then stores the Record- Route proxy list plus a Contact header field if present in the 200 OK for use in a Route header field in all subsequent requests. Because Record- Route is bidirectional, messages in the reverse direction will also traverse the same set of proxies. Chapter 10 contains an example of the use of the Record-Route and Route header fields. The lr parameter is new to RFC 3261 and indicates that the proxy server supports "loose routing." Older RFC 2543 compliant proxy servers create Record-Route URIs that instead of the lr parameter often contain the maddr parameter with an address or host that resolves to that proxy server. Examples are: Record-Route: <sip:proxy1.carrier.com lr>, <sip:firewal133.corporation.com lr> Record-Route: <sip:139.23.1.44;lr> 6.1.11 Retry-After The Retry-After header field is used to indicate when a resource or service may be available again. In 503 Service Unavailable responses, it indi- cates when the server will be available. In 404 Not Found, 600 Busy Everywhere, and 603 Decline responses, it indi