 the session. User agents must tear down the call after the expiration of the timer. The caller can send re-INVITES to refresh the timer, enabling a "keep alive" mechanism for SIP. This solves the problem of how long to store state information in cases where a BYE request is lost or misdirected, or in other security cases described in later sections. The details of this implementation are described in Section 6.2.29. 3.5.2 Redirect Servers A redirect server was introduced in Figure 2.6 as a type of SIP server that responds to, but does not forward requests. Like a proxy sever, a redirect server 1. TCP usually provides end-to-end reliability for applications. In SIP, however, TCP only pro- vides single-hop reliability. End-to-end reliability is only achieved by a chain of TCP hops or TCP hops interleaved with UDP hops and stateful proxies. SIP Clients and Servers uses a database or location service to look up a user. The location information, however, is sent back to the caller in a redirection class response (3xx), which, after the ACK, concludes the transaction. Figure 3.5 shows a call flow that is very similar to the example of Figure 2.2, except the server uses redirection instead of proxying to assist Schroedinger locate Heisenberg. The INVITE from Figure 3.5 contains: INVITE sip : werner.heisenberg@munich.de SIP/2.0 Via: SIP/2.0/UDP 100.101.102.103:5060 ; branch=z9hG4bK54532 Max-Forwards: 70 To: Heisenberg <sip:werner.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=4313413 Call-ID: 9@100.101.102.103 CSeq: 1 INVITE Subject: Where are you exactly? Contact: <sip:schroed5244@pc33.aol.com> Content-Type: application/sdp Content-Length: 159 o=schroed5244 2890844526 2890844526 IN IP4 100.101.102.103 s=Phone Call C=IN IP4 100.101.102.103 m=audio 49172 RTP/AVP 0 a=rtpmap 0 PCMU/8000 The redirection response to the INVITE is sent by the redirect server: Redirect server Schroedinger Heisenberg INVITE 302 Moved temporarily INVITE 200 OK Media session 200 OK Figure 3.5 Example with redirect serve