Scaling issues may arise from media mixing, which requires transcoding in the absence of a common coding scheme. Without explicit group management, no opportunity is given to negotiate on common codecs, nor are means provided to distribute mix- ing tasks or redirect media streams in many-party scenarios. Finally, privacy concerns are raised by a solution that allows for an undisclosed third party joining in a conversation-an explicit IETF policy holds off Internet Protocols from "wiretapping" [3]. SIP resolves these issues by explicitly defining a conference focus, which is identified by a Uniform Resource Identifier (URI). This URI represents the conference, and while it is uniquely created, additional Session Description Protocol (SDP) [4] media negotiations are foreseen [5]. The focus forms the central point of control only for the SIP conference management, which is free to define media distribution or mixing otherwise. The focus may be altered within an ongoing multi-party conversation, but this will lead to the creation of a new conference instance, distinguished by a newly defined conference URI. In detail, SIP operations for our example will proceed as follows (see [6]). After Charlie decided to invite Snoopy into the conversation with Lucy, he generates a conference URI and issues a SIP INVITE to Snoopy using this URI in his contact field as follows: INVITE sips:snoopy@dog.net SIP/2.0 Via: SIP/2.0/TLS alpha.brown.com: 5061;branch=z9hG4bcHlkapff Max-Forwards: 70 From: Charlie <sips:charlie@brown.com>;tag=4576932 To: Snoopy <sips:snoopy@dog.net> Call-ID: 777777@alpha.brown.com CSeq: 1024 INVITE Contact: <sips:dog-matter@alpha.brown.com>;isfocus Content-Type: application/sdp Even though the contact URI addresses Charlie directly, it is not inherently bound to a conference situation. Charlie needs to add an "isfocus" feature tag to make the multi-party situation transparent and to mark himself as the focus point. After the session has been successfully established, with SDP offer/answe negotiations aware of 