er INVITE from forking: Request-Disposition: no-fork Asynchronous Notification of Events In the examples discussed SO far, SIP signalling has been triggered by an action performed directly by a person wishing to establish, modify, or ter- minate a particular session. Bob triggers SIP signalling (an INVITE) when he picks up his SIP phone to call Laura and also when he hangs up (a BYE). However, other events besides establishing, modifying, or terminating a ses- sion can trigger SIP signalling. The SIP event notification framework enables SIP to inform users about a variety of events in which they've pre- viously indicated an interest via signalling. This event notification mecha- nism is a powerful tool for building services. Say Bob calls Laura and she is Chapter 6 busy. Even if he's in a hurry, he does not want to keep trying her number every minute to determine when she becomes available. Instead, he wants news of her availability to be delivered to him. Another example where an event notification mechanism is useful is the implementation of a presence service. A presence service usually consists of a list of your friends and colleagues and their current availability to com- municate with you. Bob can see in his buddy list whether Laura is willing to receive telephone calls at a certain moment or whether she just wants instant messages. SIP can also be used to build this presence service. Every time Laura's status changes, Bob is notified. This way Bob's buddy list will reflect changes in Laura's status. How It's Done Two new methods were defined to provide asynchronous event notification: SUBSCRIBE and NOTIFY [draft-ietf-sip-events]. SUBSCRIBE is used by a SIP entity to declare its interest in a particular event. A SIP entity subscribes to a certain event of a class of events. When the subscribed event occurs, NOTIFY requests are sent containing infor- mation about the session. Figure 6-13 shows how the automatic recall service previously described can be implemented using SUBSCRIBE and NOTIFY. Bob calls Laura