request will obtain several responses from different servers. Sending an ACK to every destination that has responded is essential to ensuring SIP operation over unreliable protocols such as UDP. Laura Figure 5-2 Three-way (1) INVITE handshake: INVITE-200 OK-ACK. (2) 180 Ringing (3) 200 OK (4) ACK Conversation Chapter 5 Besides the speedy session setup and forking, INVITE's three-way hand- shake also enables us to send an INVITE without a session description, which will be sent later in the ACK. This feature is useful, for example, when SIP interworks with other signalling protocols that use different mes- sage sequencing. However, the historical motivation for having a three-way handshake can be found in the old SIPv1 draft, in the section about how to provide reli- able delivery of session invitation. The draft introduced the ACK method in order to avoid unsynchronized parties on session establishment, which might occur when a two-way handshake is used over an unreliable trans- port protocol such as UDP. Consider the following case where a two-way handshake is implemented. Bob would send an INVITE to Laura and retransmit it until it received a final response from Laura. Until this final response is received, Bob can- not know whether Laura received the INVITE or it got lost in the network. Bob waits for a while and because he gets no answer, he gives up and stops retransmitting the INVITE. Bob believes that no session has been established. At roughly the same time, Laura accepts Bob's call and sends back a "200 OK" response. If this response gets lost, Bob will never receive it, so, Bob still believes that no session has been established. Because Laura observes that Bob has stopped retransmitting the INVITE, she assumes that Bob has received her 200 OK. Therefore, Laura thinks that the session has been successfully established (Figure 5-3). Laura Figure 5-3 This situation is (1) INVITE avoided by having a (2) INVITE three-way handshake (3) INVITE (INVITE-200 OK-ACK). (4) INVITE Hello hello Anybody there? gives u