d dial-out call control for user agents. This simultaneously holds for ad-hoc and sched- uled conferences. However, the main design guidelines of SIP extensions keep changes to a minimum and should guarantee seamless backward compatibility with conference-unaware user agents [21]. The subsequently outlined exten- sions reflect these principles. 6.2.2.1 Join Header The join header [22] expresses the request of the caller to participate in an existing dialog. It is solely used in invitations and designed as the generic operation for a third party to initiate a conference. The user agent receiving a join normally needs to create a new conference URI, which is then handed to the joining party via a re-INVITE. Conference creation is needless if the dialog to be joined is already part of a conference. The existing dialog: From: Charlie Sips:charlie@brown.com>;tag=7654321 To: Lucy <sips:lucy@psychic.org>;tag=1234567 Call-ID: 333333@alpha.brown.com is identified in the join header by its call-ID, the to-tag and the from-tag: INVITE sips: charlie@brown.com SIP/2.0 From: Snoopy <sips:snoopy@dog.net>;tag=95148 To: Charlie sips:charlie@brown.com> Call-ID: 2772@beta.dog.net Join: 333333@alpha.brown.com to-tag=1234567; from-tag=7654321 © 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security Note that even though the joining party need not know about an ongoing con- ference nor a conference URI, it must acquire call information of the existing remote session. These IDs may be learned from non-SIP means or via a SIP event package [23]. 6.2.2.2 Re-INVITE The SIP re-INVITE operation [1] is not an independent method, but an iter- ated INVITE within an ongoing session, i.e., with unaltered call-ID. It allows for a change of SIP session characteristics and always triggers SDP media negotiations anew. Thus, in conferencing situations it can be used to adapt control- and media-session parameters at the same time. Commonly, confer- ence URIs and focus points or multicast groups used for signaling are dis