he session, he finds it useful to see who is calling. SIP can deliver, at session initiation, the caller's photo along with the session description, which will be displayed on Bob's laptop. Bob now has the option of accepting or refusing the call based on the identity of the caller. How It's Done In order to be able to display the photo of the caller, Bob's UA needs to receive a file with the photo (such as Laura.jpg) or a URL where Bob's UA can retrieve the photo (such as http://www.university.com/ ~laura/photos/laura.jpg). If a URL is received, Bob's UA uses his Web browser to display the photo. In order to receive this information, whether it turns out to be a file or a URL, Bob's UA needs to receive an INVITE car- rying a message body with two parts: an SDP session description and a photo (Figure 6-7). Extending SIP: The SIP Toolkit Laura Figure 6-7 Bob receives Laura's (1) INVITE photo in her INVITE. Laura's photo (2) 200 OK (3) ACK Core SIP accepts multipart message bodies in Multipurpose Internet Mail Extensions (MIME) [RFC 2045] format. SIP does not need to be extended in order to support them. Again, SIP uses the same format to send multipart bodies that e-mail systems use to send attachments. This shows the toolkit approach at work SO that new services can be built on existing mechanisms. Instant Messages To establish a session, SIP delivers a session description to the caller. If instead of a session description, SIP is used to deliver a human-readable message, an instant-messaging system can be trivially implemented with SIP. The main difference between instant messages and e-mail is that instant messages are short and are delivered immediately to the user. E- mails are usually longer and they are stored in the user's inbox until he or she accesses it to read them. It is also common to maintain interactive text conversations using instant messages, but much less SO with e-mail where responses aren't always sent within a short period of time. Many applications use instant messages. For example, several