The Internet most prominently offers IP layer multicast for this purpose, which has been designed about 20 years ago following the model of any source multicast © 2009 by Taylor & Francis Group, LLC Group Conference Management with SIP (ASM). The advantages of multicast over unicast-based multi-party commu- nication must be seen in its scalability and lightweight interface at the client side. Deployment of IP multicast has been hesitant over the past decade, although it has emerged in recent times with the remarkable spread of IPTV offers. In the meanwhile, the infrastructure-friendly source specific multicast (SSM) model has been developed, as well as infrastructure-agnostic multi- cast on the application layer with promising performance potentials. Keeping deployment complexity in mind, it is desirable for any multicast conferencing solution to restrict group communication for signaling and media data to only one of the multicast models. Due to its bandwidth requirements, transmission of media data takes the largest advantage of multicast. RTP streams transparently conform to group communication. While SDP session descriptions convey sufficient information for a user agent client to join a multicast group by providing multicast desti- nation addresses within connection type fields on a per session and per media basis [4], SDP offer/answer negotiations [7] only partially fulfill multicast requirements. Supporting only a uniform view of the multicast session among all participants, RFC 3264 requires an SDP answer to match a multicast offer in address, port, and directionality. Thus, the roles of multicast sender and receiver remain in disguise and neither multicast send/receive capabilities nor SSM specifics may be arranged. Current work in the IETF sipping working group addresses this issue. Multicast communication may be desired for SIP signaling whenever a pre- viously configured group of receivers is to be contacted or in distributed sce- narios with severe scalability constraints. The basic interaction with 