he midst of the session, one of them wishes to modify the session, they just have to issue a new INVITE. This type of INVITE, called a re-INVITE, carries an updated session description. It might consist of new parameters such as port numbers for the existing media, or it might add new media streams. For instance, Bob and Laura can add a video stream to their voice conversation via a re-INVITE. Significantly, SIP only handles the invitation to the user and the user's acceptance of the invitation. All of the session particulars are handled by the session description protocol used (SDP in this case). Thus, with a dif- ferent session description, SIP can invite users to any type of session. Figure 5-1 Laura issues a final I will call Laura to see response (200 OK) how she is doing. for the INVITE she received. Laura (1) INVITE (2) 180 Ringing (3) 200 OK SIP: Protocol Operation ACK ACK requests are used to acknowledge the reception of a final response to an INVITE. Thus, a client originating an INVITE request issues an ACK request when it receives a final response for the INVITE, providing a three-way handshake: INVITE-final response-ACK (Figure 5-2). Why Does SIP Use a Three-Way Handshake? INVITE is the only method that uses a three-way handshake as opposed to a two-way hand- shake (METHOD-final response). Certain characteristics set the INVITE method apart from other methods. When a client issues a request other than INVITE, it expects a fast response from the server. However, the response from an INVITE request might take a long time. When Bob calls Laura, she may have to fish her SIP phone out of her coat pocket and press buttons, SO the "200 OK" response that will come will be more or less delayed. Sending an ACK from the client to the server when the response is received lets the server know that the client is still there and that the session has been successfully established. The three-way handshake also enables the implementation of forking proxies. When one of these forks a request, the client who issued the 