al responses. His SIP UA displays his new position on the screen every time a new response arrives. PRACK is an example of the SIP working group that chooses a general solution over a more efficient but less general one. This decision is in line with the IETF paradigm and the toolkit approach. The 200 OK response for the PRACK is really useless from a reliability point of view. The UAC knows that the PRACK has arrived at the UAS because the retransmissions of the provisional response stopped. So why is the 200 OK for the PRACK sent? The answer to this question is one of the key features of the Internet: end-to-end protocols perform end-to-end functions better. SIP proxies understand the basic SIP methods. We saw in Chapter 5 that a proxy receiving a method that it does not understand routes it by following the same rules as for BYE requests. The proxy basically forwards the request and if it is stateful, waits for a final answer. Support Figure 6-5 Call queue (1) INVITE implemented using (2) 182 Two In The Queue reliable provisional (3) PRACK responses. (4) 200 OK (5) 182 One In The Queue (6) PRACK (7) 200 OK (8) 180 Ringing (9) PRACK (10) 200 OK (11) 200 OK (12) ACK Extending SIP: The SIP Toolkit Making PRACK into a request-response transaction enables proxy servers that are not PRACK aware to route this new method properly. If PRACKs had no response, proxies would have to learn a new method in order to apply special routing that doesn't wait for a response. This example shows how a new service can be implemented without modifying anything in the network. Two terminals that implement the PRACK method are able to exchange reliable provisional responses over the same network of SIP servers that was implemented when PRACKs did not exist. Those SIP servers will not understand PRACK because it was developed when they were already installed in the network, but they can still route PRACKs properly. Therefore, end systems can implement new services and use them over an existing SIP network without requiring an upgrade. 