 had failed, Bob's secretary would have been able to retrieve her session with Laura to continue speaking with her. After the BYE, Bob and Laura are in a closed two-party session with both signalling and media traffic exchanged directly between them. Sending Commands Because SIP doesn't function as a master/slave protocol, it's not suitable for controlling tightly coupled devices. In such scenarios, the master sends com- mands to the slave who responds with the current status of the command. The master controls how the slave is proceeding with each command at every moment. Protocols such as H.248 or MGCP [RFC 2705] are appropri- ate to resolve these problems because they were designed with tightly cou- pled devices in mind. However, sometimes it is necessary to send a command to a device out- side a master/slave architecture. When both the entity issuing the com- mand and the entity receiving it are loosely coupled, SIP becomes an interesting alternative to master/slave protocols. In such an environment, when one entity sends a command to another entity, the latter does what it is requested to do and then reports the status of the command. Note that the entity issuing the command does not behave as a master because it can- not control the process from moment to moment and has to await the final result of the command. How It's Done A new SIP method called DO [draft-moyer-sip-appli- ances-framework] was defined to carry commands. An entity issues a DO method carrying a command in the message body. The entity receiving the DO performs the action the message has specified. Besides the DO method, a format to describe commands, the Device Messaging Protocol (DMP), was defined. DMP describes commands the same way as SDP describes ses- sions. With these two extensions, it is possible to control SIP-enabled entities, and Bob can control his SIP-enabled radio from his laptop. Figure 6-18 shows how Bob's SIP UA adjusts the volume using DO. In this way, the UA can automatically mute the radio every time Bob receives a call a