e way a lap- top uses DHCP to retrieve its IP address from a DHCP server, a SIP UA can also retrieve the domain name of a SIP server using DHCP [draft-ietf-sip- dhcp]. Figure 6-9 shows how Bob retrieves both his IP address and his SIP domain name from a DHCP server. A more advanced UA can use the Service Location Protocol (SLP) [RFC 2608] to find a SIP server with certain characteristics. SLP provides server location that matches up server capabilities with user needs [draft-kempf- sip-findsrv]. Chapter 6 DHCP server Figure 6-9 Bob's laptop obtains an IP address and a SIP domain name (1) I am a new laptop in the network. from the DHCP I have just been connected server. (2) Your IP address is: 131.160.1.112 Your SIP domain name is: university.com Preconditions to Be Fulfilled Before Alerting 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