, but she is busy. Bob sends a SUBSCRIBE to Laura's SIP UA indicating his interest in Laura's status. Laura's SIP UA answers with a 200 OK to the SUBSCRIBE and sends a NOTIFY to Bob with Laura's current status: busy. After a while, Laura hangs up and her UA detects a change in her sta- tus and sends a NOTIFY to Bob with her new status: available. Bob will then send an INVITE to Laura to talk to her. This time his call will be suc- cessful. Figure 6-14 shows another example of a service implemented using SUBSCRIBE and NOTIFY. Bob is participating in a SIP conference call that uses a centralized conference unit. All of the participants send an INVITE to the conference unit to establish a session with it. The conference unit then combines all incoming audio streams and delivers them to the participants. Bob wants to know how many people are attending the conference at any moment. He sends a SUBSCRIBE to the conference unit. The conference unit keeps Bob updated about changes in the number of participants by sending a NOTIFY every time a participant joins or leaves the conference. Extending SIP: The SIP Toolkit Laura Figure 6-13 Bob is notified when (1) INVITE Laura hangs up. (2) 484 Busy here (3) ACK (4) SUBSCRIBE Laura's status (5) 200 OK (6) NOTIFY Laura is busy (7) 200 OK (8) NOTIFY Laura is available (9) 200 OK (10) INVITE When Laura joins the conference, Bob receives a NOTIFY with the new number of participants. Third-party Call Control We know a SIP UA can establish a session with other UAs. However, a user sometimes wants to establish a session between other UAs without taking part on it. This situation is quite common when one of the UAs rep- resents a machine instead of a human. If a conference call is scheduled using a conference unit like the one described in the previous section, invi- tees can opt out without losing out. Bob is interested in what is said dur- ing the conference call, but he is busy at that particular time and can't attend. Bob thinks that recording the conference would be a good idea. C