defined [draft-ietf-sip-manyfolks-resource]. COMETs are sent to indicate that all preconditions are met and session establishment can proceed. (See Figure 6-10 for an example of how to use this method.) Bob wants to establish a session with Laura that requires QoS. The INVITE he sends her will contain QoS preconditions. Bob specifies that he does not want Laura to be alerted until the network has granted a certain QoS. If this QoS can't be provided, Bob would rather let the session lapse. So Laura's UA receives the INVITE and sends back a "183 Session Chapter 6 Laura Figure 6-10 Bob finishes (1) INVITE QoS preconditions reserving QoS before Laura. (2) 183 Session Progress (3) PRACK (4) 200 OK (5) COMET (6) 200 OK (7) 180 Ringing Progress" response with Laura's QoS preconditions for the session (this response is transmitted reliably using the techniques described previously in this chapter). Then Bob and Laura perform resource reservation (using RSVP for instance). Bob waits until he finishes reserving resources to send a COMET to Laura. When Laura's UA has also completed resource reser- vation, it resumes the session establishment process by alerting Laura. Figure 6-11 illustrates what happens if Laura's UA finishes resource reservation ahead of Bob's. Laura's UA waits until a COMET arrives from Bob. Once the COMET is received, it alerts Laura. Caller Preferences We have seen SIP servers handle requests in many different ways. A SIP server, for instance, can choose between performing parallel or sequential searches, and between forking or trying a single location. The core SIP spec- ification leaves these decisions up to the administrator who configures the server. Extending SIP: The SIP Toolkit Laura Figure 6-11 Laura finishes (1) INVITE reserving QoS QoS preconditions before Bob. (2) 183 Session Progress (3) PRACK (4) 200 OK (5) COMET (6) 200 OK (7) 180 Ringing The caller, however, might have different preferences. I might want all my requests to be forked in parallel rather than sequentially to save time, wher