SIPPING WG                                                           
        Internet Draft                                           V. Paulsamy 
        Document: draft-victor-fullmesh-reqts-00.txt            Tamura Corp. 
        Expires: November 2003                                  May 28, 2003 
         
         
        Requirements for Full-mesh Conference Model using Baseline Session 
        Initiation Protocol 
         
         
     Status of this Memo 
         
        This document is an Internet-Draft and is in full conformance with 
        all provisions of Section 10 of RFC2026.  
         
        Internet-Drafts are working documents of the Internet Engineering 
        Task Force (IETF), its areas, and its working groups.  Note that      
        other groups may also distribute working documents as Internet-
        Drafts. 
         
        Internet-Drafts are draft documents valid for a maximum of six months 
        and may be updated, replaced, or obsoleted by other documents at any 
        time.  It is inappropriate to use Internet-Drafts as reference 
        material or to cite them other than as "work in progress." 
         
        The list of current Internet-Drafts can be accessed at 
             http://www.ietf.org/ietf/1id-abstracts.txt 
        The list of Internet-Draft Shadow Directories can be accessed at 
             http://www.ietf.org/shadow.html. 
         
         
         
     Abstract 
         
        This memo enumerates requirements to realize full-mesh multiparty 
        conferencing using baseline Session Initiation Protocol. Primary 
        requirement is to advertise conference membersÆ addresses to new 
        participants by concatenating multiple SDP session descriptions 
        together. This particular requirement can solve several well-known 
        problems, including disjoint meshes and race conditions, that are 
        lingering in full-mesh conferencing for a while now. 
         
         
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
        "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this 
        document are to be interpreted as described in RFC-2119. 
         
         
         
         
      
      
     Paulsamy               Expires - November 2003               [Page 1] 
                        Full-mesh Conference Requirements          May 2003 
      
      
     1. Introduction 
         
        Although there are several different conference models available in 
        SIP [1], full-mesh conferencing is appropriate for small and/or 
        medium size conferencing in residential, enterprise and service 
        provider environments. However, full-mesh is still missing in SIP. 
        The main reason for its non-existence is partly due to the 
        difficulties in propagating conference memberships to all 
        participants. The other known problems are disjoint meshes, race 
        conditions and authoritative view of conference membership. 
         
        In the absence of useful applications, for simplicity reasons, RFC 
        3264 [2] forbids concatenating many SDP session descriptions 
        together. However, we believe that this memo presents a strong case 
        to relax this rule and to define new semantics in its entirety for 
        carrying and processing multiple session descriptions in a SIP 
        message without affecting existing applications. 
         
        Section 2 explains, with the help of examples, how full-mesh 
        conference is setup, using the proposed requirement and how it solves 
        the well-known problems. Section 3 enumerates the requirements. 
         
     2. Examples 
         
        Every User Agent that is participating in a conference maintains in a 
        list, addresses of other participants that has established dialogs 
        with it. When a UA invites a new member into the conference or when 
        accepts a request to confer, the UA advertises existing participantsÆ 
        addresses using concatenated SDP session descriptions. When new 
        addresses are learnt, the UA consults its list to figure out the 
        addresses of the participants with which it doesnÆt have dialog. It 
        then goes about establishing the dialog. 
         
        Each session description will list exactly one participantÆs address 
        using one u= line, apart from the mandatory lines. Note that, no need 
        to carry any other lines. If there are N participants, N session 
        descriptions will be used. These descriptions and the one that lists 
        the UAÆs session characteristics are concatenated together into one 
        SDP session description. 
         
        Say, A and B are in a simple two party call. Both A and B maintain 
        addresses of remote participants in a list. Since it is a two party 
        call, AÆs list has BÆs address and BÆs list has AÆs address. At a 
        later point, A and B decide to bring in C and transition the call 
        into a conference. A takes the responsibility to add C into the 
        conference. A concatenates its session parameters and BÆs URI into a 
        single SDP and sends it to C. The answer from C consists of normal 
        SDP. By normal SDP, we mean an SDP as defined by RFC 3264. Thus, C 
        learns the presence of B and establishes a separate session with B. 
      
      
     Paulsamy               Expires - November 2003               [Page 2] 
                        Full-mesh Conference Requirements          May 2003 
      
      
        Each participant receives media from two other participants. A 
        receives media from both B and C, for instance. The media are mixed 
        prior to playback. Since A has two different sessions with B and C, 
        media is sent to B and C independently. With every member sending and 
        receiving media, a 3-party full-mesh conference is in place. Note 
        that every participant has point-to-point signaling and media 
        relationship with every other participant. 
         
        In another example, assume that the aforementioned 3-party conference 
        exists. At some point, C decides to bring in D into the conference. C 
        concatenates existing participantsÆ (A and B) addresses and its 
        session parameters together into a single SDP and offers it in an 
        INVITE. D sends C its normal SDP parameters in the answer. Almost at 
        the same time, E contacts B. B replies by sending a concatenated SDP 
        in 200 OK, that contains addresses of current members (A and C) and 
        its session parameters. 
         
        D contacts A and offers a normal SDP to setup a session. A answers 
        using concatenated SDP that consists of its session parameters and 
        the addresses of B and C. E sends a normal SDP to A. The reply from A 
        has the addresses of participants B, C and D and its session 
        parameters concatenated together into a single SDP. This sets up a 
        session between E and A. From this reply, E learns the existence of 
        D. D learnt the address of B from C, as well as from A. D establishes 
        a session with B by offering it a normal SDP. B concatenates its 
        session parameters with the addresses of A, C and E and sends it in 
        the reply. Thus, D learns the presence of E. The participant E 
        contacts C using a normal SDP. In its reply using concatenated SDP, C 
        propagates addresses of A, B and D along with the session parameters. 
        D sets up a session with E by sending it a normal SDP. The reply from 
        E contains its session parameters and the addresses of A, B and C in 
        a concatenated SDP. Thus, a 5-party conferencing is setup. 
         
        Note that, if every participant were to exchange the normal SDP 
        either while contacting a new user or while replying, in the above 
        example, both D and E wouldnÆt have learnt the presence of each 
        other. The result would be two disconnected conference meshes one 
        with A, B, C and D as participants and another with A, B, C and E as 
        participants. 
         
        If some one leaves the conference, it simply sends a BYE to rest of 
        the members. This is because, it has point-to-point signaling 
        relationship with each one of the other participants. Upon receiving 
        BYE, every UA deletes the address of the corresponding member from 
        the participantsÆ list. If some one happens to enter the conference 
        exactly at same time when a participant leaves, there is a 
        possibility that the address may not have been removed from the list 
        as yet and hence it gets advertised. However, the erstwhile member 
        may decline the request from the new member. But nevertheless, no 
      
      
     Paulsamy               Expires - November 2003               [Page 3] 
                        Full-mesh Conference Requirements          May 2003 
      
      
        race condition would prevail. The former memberÆs address gets 
        propagated if some one else were to contact the new participant. It 
        is for this reason, a UA has to maintain the addresses of only 
        participants that has established a dialog with it. 
         
        Typically, race conditions occur when a new participant joins the 
        conference at the same time when an existing participant leaves. Or 
        when two new participants enter the conference simultaneously, 
        invited by two different participants. The specific details depend on 
        how the participantsÆ addresses are advertised. However, if 
        concatenated SDP is used to advertise addresses of participants, race 
        conditions do not arise at all. 
          
     3. Requirements 
         
     3.1 Granting Conference Memberships 
                                           
        No collective opinion, from amongst current members, is needed to add 
        new members into the conference.  
         
        It MUST be possible for each member of the conference to grant 
        memberships independently.  
         
        It SHOULD be possible for a current member to invite a new entity or 
        to be contacted by the joining new entity, for the purpose of 
        conference. 
         
     3.2 Advertising ParticipantsÆ Addresses (URIs) 
         
        A mechanism needs to be defined to advertise conference participantsÆ 
        addresses, using baseline SIP messages, to a new participant when 
        invited into the conference, or when joining the conference by 
        contacting an existing member on its own and when answering a request 
        that establishes a dialog as part of the conference, after gaining 
        membership.  
         
        It MUST be possible to concatenate several SDP session descriptions 
        together into a single SDP and use it in lieu of a normal SDP in an 
        INVITE, a 200 OK and an ACK. 
         
        It MUST be possible to receive concatenated SDP session descriptions 
        in lieu of a normal SDP in an INVITE, a 200 OK and an ACK and process 
        it. 
         
        ItÆs worth it to note that using concatenated SDP in offer and answer 
        alone is advocated instead of the normal one. Which requests and 
        responses can carry it and how to process it are governed by the 
        rules defined by SIP. 
         
      
      
     Paulsamy               Expires - November 2003               [Page 4] 
                        Full-mesh Conference Requirements          May 2003 
      
      
     3.3 Disjoint Meshes 
                
        When two or more new participants get added into the conference 
        simultaneously, the new participants have to learn the addresses of 
        all the participants including that of the new ones. However, if 
        session descriptions are exchanged using the existing mechanism, the 
        new participants cannot learn the existence of each other and no 
        session could be established between them. The result is that the new 
        participants do not hear each other but all. A mechanism needs to be 
        defined to disseminate participantsÆ addresses continually. 
         
        It MUST be possible, while answering a request from a member of the 
        conference, to concatenate several SDP session descriptions together 
        into a single SDP and send it in a 200 OK or an ACK. 
         
     3.4 Leaving and Rejoining 
         
        The conference membership is highly dynamic in nature. Even if some 
        one rejoins the conference after leaving it for a brief moment, it 
        cannot assume to have an authoritative view of the conference 
        membership because of the fact that conference users come and go, at 
        will. A mechanism needs to be defined that ensures a former member 
        that rejoined the conference, to send and receive media with the 
        entire members of the conference. 
         
        Every participant, including former members, MUST learn the addresses 
        of other participants of the conference only through a current 
        member. 
         
     3.5 Terminating Conference Membership 
         
        It MUST be possible for a leaving conference member to send a BYE to 
        rest of the conference members to announce it. Every member MUST act 
        on it immediately to remove the address of the leaving member from 
        the conference participantsÆ list. This helps to avoid propagating a 
        former memberÆs address. 
         
     3.6 Glare situation 
         
        Another imminent problem arises, in the aforementioned example, if E 
        received a request from D when E already sent a request to D and 
        awaiting an answer. This situation is known as ôglare.ö If only one 
        has to answer the call, which one is it? A mechanism needs to be 
        defined to identify the participant that answers the call. Or, would 
        it be appropriate if both participants answered the call and 
        terminate one of them, perhaps after a negotiation, eventually? A 
        conclusion has to be arrived at. 
         

      
      
     Paulsamy               Expires - November 2003               [Page 5] 
                        Full-mesh Conference Requirements          May 2003 
      
      
     4. Security Considerations 
         
        Same as those defined in RFC 3264. 
         
     5. IANA Considerations 
         
        There are no IANA considerations with these requirements.  
      
     6. Acknowledgments 
         
        The author would like to thank Jonathan Rosenberg and Jonathan Lennox 
        for the very useful private discussions, suggestions and comments.  
      
     7. Normative References 
      
        [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 
        Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session 
        Initiation Protocol," RFC 3261, Internet Engineering Task Force, 
        June 2002. 
         
        [2] J. Rosenberg, H. Schulzrinne, "An Offer Answer Model with the       
        Session Description Protocol (SDP)," RFC 3264, Internet Engineering  
        Task Force, June 2002. 
        
     8. Author's Addresses 
         
        Victor Paulsamy 
        Tamura Corp 
        4677 Old Ironsides Dr., Suite #320 
        Phone: (408) 496-0324 
        Email: victor@tamura-broad.com 
          
        Intellectual Property Statement 
         
        The IETF takes no position regarding the validity or scope of     
        any intellectual property or other rights that might be claimed  
        to pertain to the implementation or use of the technology  
        described    in this document or the extent to which any license 
        under such rights might or might not be available; neither does  
        it represent that it has made any effort to identify any such  
        rights. Information on the IETF's procedures with respect to  
        rights in standards-track and standards-related documentation  
        can be found in BCP-11. Copies of claims of rights made  
        available for publication and any assurances of licenses to be  
        made available, or the result of an attempt made to obtain a  
        general license or permission for the use of such proprietary  
        rights by implementors or users of this specification can be  
        obtained from the IETF Secretariat. 
         
      
      
     Paulsamy               Expires - November 2003               [Page 6] 
                        Full-mesh Conference Requirements          May 2003 
      
      
        The IETF invites any interested party to bring to its attention  
        any copyrights, patents or patent applications, or other  
        proprietary rights which may cover technology that may be  
        required to practice this standard. Please address the  
        information to the IETF Executive Director. 
         
        Full Copyright Statement 
         
        Copyright (c) The Internet Society (2003). All Rights Reserved. 
        This document and translations of it may be copied and furnished   
        to others, and derivative works that comment on or otherwise  
        explain it or assist in its implementation may be prepared,  
        copied, published and distributed, in whole or in part, without  
        restriction of any kind, provided that the above copyright    
        notice and this paragraph are included on all such copies and  
        derivative works. However, this document itself may not be  
        modified in any way, such as by removing the copyright notice or  
        references to the Internet Society or other Internet  
        organizations, except as needed for the purpose of developing  
        Internet standards in which case the procedures for copyrights  
        defined in the Internet Standards process must be followed, or  
        as required to translate it into languages other than English. 
        The limited permissions granted above are perpetual and will not  
        be revoked by the Internet Society or its successors or assigns. 
            
        This document and the information contained herein is provided  
        on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET  
        ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR  
        IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE  
        OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY  
        IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A  
        PARTICULAR PURPOSE. 
         
















      
      
     Paulsamy               Expires - November 2003               [Page 7]