that she can dial to join in. In this example, the session description would contain a telephone num- ber instead of IP addresses and UDP ports. When SIP delivers the session description to Laura, she reacts as she does to any kind of ping with the tool she's been given. SIP provides just enough information for the invitee to accept the invi- tation; it is an exemplary IETF specification in that it performs its task. When we need to describe a session established by SIP, we should use another protocol designed for that purpose other than SIP. The Session Initiation Protocol: SIP Intelligence in the End System: End-to-End Protocol The IETF community believes that end-to-end protocols are better for pro- viding end-to-end services and that IP is an end-to-end protocol. IP provides connectivity between end points separated by a network of intervening routers. The routers perform the well-defined task of routing datagrams as efficiently as possible. Similarly, SIP provides connectivity between users with SIP servers. SIP servers have an equally well-defined task: routing SIP requests based on the Request-URI and responses based on Via headers. SIP servers do not process session descriptions carried in SIP bodies because they don't need to in order to route SIP messages. This makes SIP an efficient protocol, along with the fact that all intelligence in a SIP net- work is located in the end systems-the UAs. SIP servers can be virtually stateless and forget everything about the transactions they're moving because the information needed to route a SIP message is contained in the message itself. Interoperability SIP is designed SO that any implementation of the core protocol can inter- operate with any other implementation and incorporates methods for nego- tiating the extensions that will be used in a session. Two highly advanced SIP UAs establishing a session are likely to use many extensions and sophisticated features. Yet if one of these advanced UAs needs to establish a session with a rudimentary UA, it always can. A