er, nothing ensures that a provisional response from the callee's UA will reach the caller's UA. Proxies in the path will usually forward the response to the previous hop once, but will not retransmit if it fails to arrive (Figure 5-24). In contrast, SIP guarantees that final responses arrive at their intended destination. Successful responses (200 to 299) are delivered reliably to the originating UA. Non-successful final responses (300 to 699) use the same hop-by-hop mechanism as INVITE. Non-successful Final Responses The idea behind transmitting non-successful final responses is the same as that behind transmitting INVITEs. Every server ensures that the previous hop receives the response and then the previous hop assumes responsibility for handling the response. A UA using an unreliable transport protocol is going to retransmit the non-successful final response until an ACK arrives (Figure 5-25). In theory, a UA using a reliable transport protocol would not have to make use of the ACK. However, in order to make the protocol look homoge- neous across reliable and unreliable transports, ACKs are used in both. SIP: Protocol Operation Laura Proxy Proxy Proxy Figure 5-24 Provisional responses (1) INVITE are not transmitted reliably end to end. (2)100 Trying (3) INVITE (4)100 Trying (5) INVITE (6) )100 Trying (7) INVITE (8)100 Trying (9)180 Ringing (10)180 (11)180 Ringing Ringing Proxy Figure 5-25 The 404 Not Found response is (1) 404 Not Found retransmitted until the ACK arrives. (2) ACK (3) 404 Not Found (4) 404 Not Found (5) ACK I've mentioned some situations in which non-successful final responses are not transmitted to the originating UA. Figure 5-26 shows how the fork- ing proxy at company.com receives 404 Not Found responses that it does not forward to Laura's UA, thanks to the hop-by-hop transport mechanism used for this kind of response. Chapter 5 Forking Figure 5-26 workstation1 1234 Laura The forking proxy Proxy university.com 131.160.1.112 does not forward (1) INVITE 404 Not Found (2) INVITE responses to 