In all the examples we have seen so far, UAS has alerted the user upon reception of an INVITE. If the user accepted the invitation, the session was established. This model works just fine for sessions that can be established quickly. In an audio session, for instance, once the user accepts the call, he or she can hear the caller’s voice almost immediately. The model also works for sessions whose requirements for establishing time are not especially tough. For instance, if a user receives an invitation (INVITE) to join a gam- ing session, he or she does not expect to be able to begin playing as soon as he or she presses the accept button. The user expects (and counts on) some time to elapse between accepting and to joining the game. The application, among other tasks, will probably have to load some game scenarios into memory and synchronize positions on each player’s map of different players before the game can start.
The model is unsuitable for sessions that have tougher requirements, however. A good example is a telephone call placed over the public-switched telephone network (PSTN). When I receive a call on my PSTN phone, I expect to speak as soon as I pick up. It would be annoying and probably unacceptable if I had to wait so much as 5 seconds between answering the phone and talking.
(1) I am a new laptop in the network. I have just been connected
DHCP server
(2) Your IP address is: 131.160.1.112 Your SIP domain name is: university.com
Figure 6-9
Bob´s laptop obtains an IP address and a SIP domain name from the DHCP server.
In the Internet, establishment time increases dramatically if the session requires a certain QoS and/or a certain level of security. Establishing a secure channel between two end users and providing QoS (using RSVP for instance) takes time.
But even if an extremely fast resource reservation mechanism that could fulfill a variety of applications requirements was available, it would still be impossible to know beforehand whether the network will grant the neces- sary session QoS or not. If the session is established and the network does not grant the necessary QoS, the session fails. In an audio session, this would mean that a user answers a SIP phone that is ringing and finds no call established—a case of ghost ringing.
This problem can be resolved either by changing the user’s expectations or meeting the requirements. In the early days of cellular telephony, it was the former. Users of the fixed telephony network were accustomed to very short delays between the moment they finished dialing a telephone number and the first rings on the caller’s phone. Cellular users had to wait signifi- cantly longer for their calls to be established. However, they were willing to accept this delay in exchange for a new service feature: mobility. A typical user of SIP devices might accept longer establishment delays because he or she can trade off a little patience for a wide range of new services.
As we all know, sometimes it is necessary to simply fulfill the user’s requirements. Users who only want voice sessions are most likely to refuse to use a new technology (SIP) if it performs worse than the one they already use.
For these occasions, the SIP toolkit includes a way to meet preconditions for a session, such as security and QoS, before alerting the user. This mech- anism ensures that everything is ready for establishing the session when the user agrees to participate in it.
How It’s Done A new method called preCOnditions MET(COMET) was 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
(5) COMET (6) 200 OK (7) 180 Ringing Bob Laura (1) INVITE QoS preconditions (3) PRACK (4) 200 OK (2) 183 Session Progress Bob performs QoS reservations
Laura performs QoS reservations Figure 6-10
Bob finishes reserving QoS before Laura.
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.