e unaware user agents. In detail, protocol operations of SIP initiated SSM proceed as follows: caller, wishing to participate in a previously established unicast dialog, will initiate a regular INVITE request to some selected member. Eventually, after the call setup has completed, either party will decide to transfer the estab- lished session to group communication. Heading for SSM, it will create a conference URI with a locator consisting of an SSM group address G, e.g., sip: dog-matter@232.116.16. Like in unicast conferences, the initiator will submit a re-INVITE announcing its conference URI, i.e., the desired multicast address, in the CONTACT field of the SIP header: INVITE sip: lucy@psychic.org SIP/2.0 CSeq: 1024 INVITE Contact: <sip: :dog-matter@232.116.16.6> isfocus Content-Type: application/sãp In parallel, the SIP protocol stack will submit a multicast source-specific JOIN to its underlying IGMP/MLD stack, thereby subscribing to the group and the source address of the corresponding peer, both learned from the previous SIP message exchange. Any peer will identify the multicast address in the contact field, and proceed along the protocol semantic for SSM SIP. This two-step procedure purposefully decouples application layer session establishment and underlying multicast routing operations. Temporal progress in IP layer multicast routing and SIP transactional timers thereby remain independent for the sake of robustly layered protocol operations. Appropriate media session descriptions for source-specific multicast distribution of media streams may or may not be submitted along the re-INVITE request. In multiparty environments, the straightforward generalization for switch- ing a previously established unicast conference into SSM group communica- tion is shown in Figure 6.9. If the callee decides to accept the call from Snew, it will forward the INVITE to its partner, thereby initiating unicast sessions among the three. Thereafter, the callee will turn the conference signaling to multicast by submitting the co