Core SIP ensures that the initiator of a session is informed when the remote party agrees to join the session. Short of actual acceptance,
though, reports on the progress of session establishment are not considered valuable.
However, some applications need this type of information. For example, suppose the support department of a company implements a queue for incoming calls. When all of the clerks are busy, calls from customers are placed in the call queue. As the next clerk becomes available, he or she answers the first call in the queue.
Customers calling this service will insist on being informed about their progress in the queue. They can be informed either by displaying a message on the screen of the caller’s SIP phone (such as “You are now the second in the queue”) or by playing a voice message for the caller. The relevant exten-sion for providing this service is the reliable delivery of proviexten-sional responses.
How It’s Done Information about how session establishment is gressing is carried in provisional responses for an INVITE request. The pro-visional response 180 Ringing from the callee to the caller indicates that the callee is being alerted. The provisional response 182 Queued indicates that the call has been placed in a queue.
SIP does not transmit provisional responses reliably. When a User Agent Server (UAS) returns a provisional response to the User Agent Client (UAC), it traverses the same proxies as the INVITE did but in the opposite direction. Even if proxies in the path forward this provisional response to the UAC, because UASs do not retransmit provisional responses, any router in the network may discard the IP datagram containing the SIP response.
So, it might come about that the UAC never receives the provisional response (Figure 6-3).
[Draft-ietf-sip-100rel] is the SIP extension defined to provide the reliable transfer of provisional responses. UASs transmitting reliable provisional responses retransmit until a message from the UAC is received acknowl-edging reception. This mechanism is similar to the one used by core SIP for 200 OK responses, which are retransmitted by the UAS until the ACK is received.
A new method was defined to acknowledge the reception of provisional responses. This new method is called Provisional Response ACK(PRACK).
A UAS stops retransmitting a provisional response upon reception of a PRACK from the UAC.
The PRACK request belongs to a different transaction than the INVITE request. Thus, the UAS also must send a response to the PRACK. In Figure 6-4, the UAS sends a 200 OK response to the PRACK, indicating that the PRACK request succeeded.
Bob Laura
(1) INVITE
(3) 200 OK
(2) 180 Ringing
(4) ACK
Conversation Figure 6-3
Provisional responses might get lost.
Bob Laura
(1) INVITE
(3) 180 Ringing (5) 200 OK (4) PRACK
(6) 200 OK (7) ACK
Conversation
(2) 180 Ringing Figure 6-4
The PRACK ensures that the provisional response is transmitted reliably.
Figure 6-5 contains the example that was previously described. A cus-tomer is informed about his position in the call queue through reliable pro-visional 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.
Bob Support
(1) INVITE (3) PRACK
(5) 182 One In The Queue (2) 182 Two In The Queue
(4) 200 OK
(7) 200 OK (6) PRACK
(11) 200 OK (12) ACK (8) 180 Ringing
(10) 200 OK (9) PRACK Figure 6-5
Call queue implemented using reliable provisional responses.
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. This is one of the reasons why the pace at which services are cre-ated for SIP is much faster than for networks other than the Internet.