Laura. (3) 404 Not found (4) ACK (5) INVITE (6) 404 Not found (7) ACK (8) INVITE (9) 200 OK (10) 200 OK (11) ACK Conversation Successful Final Responses Successful final responses are transmitted reli- ably end to end between UAs and do not need the hop-by-hop mechanism used by other final responses (Figure 5-27). Only the UA that originated an INVITE can send an ACK for a final successful response. Therefore, regard- less of the transport protocol used (reliable or unreliable), a UA retransmits successful final responses until it receives an ACK from the originating UA. Proxies in the path simply forward successful final responses and their ACKs. They are not implicated in reliability. Figure 5-28 shows the whole session establishment process from the INVITE until the actual conversation takes place. CANCEL Transactions As hop-by-hop transactions, CANCEL transactions are handled in a special way. When a UA sends a CANCEL to a proxy, the proxy responds with a final response. At that point, the CANCEL transaction is finished for the UA. Next, the proxy will send another CANCEL to the next hop, and it will also receive a final response. You can see that reliability for CANCEL requests is easy to accomplish by retransmission (Figure 5-29). SIP: Protocol Operation Laura Proxy Proxy Proxy Figure 5-27 Successful final (1) 200 OK responses are (2) 200 OK (3) 200 OK transmitted reliably (4) 200 OK end to end. (5) ACK (6) 200 OK (7) 200 OK (8) 200 OK (9) 200 OK (10) 200 OK (11) ACK Laura Proxy Proxy Proxy Figure 5-28 The whole session (1) INVITE establishment (2) 100 Trying process. (3) INVITE (4) 100 Trying (5) INVITE (6) 100 Trying (7) INVITE (8) 100 Trying (9) 180 (10) 180 Ringing (11) 180 Ringing Ringing (12) 200 OK (13) 200 OK (14) 200 OK (15) 200 OK (16) ACK Conversation Chapter 5 Proxy Figure 5-29 The CANCEL request is retransmitted until (1) CANCEL the final response arrives. (2) 200 OK (3) CANCEL- (4) CANCEL (5) 200 OK Other Transactions In the case of INVITE, ACK, and CANCEL requests, SIP provides reliabil- ity 