[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
MMUSIC Working Group                                             E. Kim
Internet Engineering Task Force                                 J. Park
Category: Standard Tracks                                       S. Kang
October 2004                                                       ETRI
Expires April 2005


                      Tight membership support in SDP
                 <draft-ekim-mmusic-sdp-membership-01.txt>



Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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.

   This Internet-Draft will expire on April 17, 2005.


Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


Abstract

   This document defines a set of Session Description Protocol
   (SDP)attributes that allow SDP to provides tightly controlled
   membership information. Some multimedia conferencing applications may
   require strict membership control policies. A group session creator
   describes basic membership information in SDP, and it can be
   negotiated by the Offer / Answer model.


E.Kim                    Expires - April 2005                 [Page 1]


                   Tight Membership Support in SDP       October 2004



Table of Contents

   1. Introduction...................................................3
   2. Conventions used in this document..............................3
   3. Terminology....................................................3
   4. New attributes for membership description in SDP...............5
      4.1 Attributes for group policy................................5
      4.2 Attributes for Membership Information......................5
   5. Example of membership negotiation..............................6
   6. Security Considerations........................................7
   7. References.....................................................7
   Acknowledgments...................................................8
   Author's Addresses................................................8
   Intellectual Property Statement and Copyright Statement...........9




































E.Kim                    Expires - April 2005                 [Page 2]


                   Tight Membership Support in SDP       October 2004

1. Introduction

   Session Description Protocol (SDP) [1] is designed to convey
   multimedia conference relevant information to recipients. It provides
   general description for all multimedia sessions.

   However, it still does not provide specific membership information
   which is necessary for some multicast sessions. Many scenarios can be
   examples requiring membership information. In a conference, group
   organizer may want to designate who should be mandatory participants
   and how many number of participants are able to be handled when it
   create a session. In a closed group where only specific member are
   invited, a prospective group participant may want to know specific
   group information as well as general information before session
   joining, and may want to block a specific member. The initial
   information described by group organizer can be negotiated with the
   group joiners by Offer/Answer model [2].

   This draft is based upon a set of requirements to deliver tight
   controlled membership information. It defines a set of new SDP
   attributes that satisfy the requirements of tight membership control.



2. Conventions used in this document

   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 [3] and
   indicate requirement levels for compliant implementations.



3. Terminology

   closed model

      only pre-determined, pre-announced, or end systems determined
      during runtime can join a session.


   static model

      the group of participants does not change during runtime of the
      session.


   dynamic model




E.Kim                    Expires - April 2005                 [Page 3]


                   Tight Membership Support in SDP       October 2004

      the group of participants might change during runtime of the
      session.

   loose model

      a loose group is one for which it is not possible to determine
      the group membership


   tight model

      a tight group can provide individual information of member, which
      can be fully controlled. There may be two sub-categories by
      participants' knowledge of the membership information:
      completely-tight or partially tight model.


   completely-tight model

      every member may have knowledge of the individual name or email
      address, or et al.


   partially-tight model

      a subset of members may have knowledge of the individual name or
      address of every member (e.g. in a conference, a chairman and one
      or more speakers can acquire the individual details).
























E.Kim                    Expires - April 2005                 [Page 4]


                   Tight Membership Support in SDP       October 2004

4. New attributes for membership description in SDP

   For tight controlled membership, SDP MUST have the optional
   attributes to specify additional features:

      - Group Characteristics: If the group is created as a static,
         closed model or not.

      - Membership Information: If there are mandatory members who
         should be participated, group organizer may describe the list
         of members.



4.1 Attributes for group policy


   * a=agipolicy:<policy>
     a=agipolicy:<policy>/<condition>

   A session owner can define this attribute when it creates a session.
   Active Group Integrity(AGI) means a set of conditions concerning an
   active group. <policy> filed holds "hard" or "soft". In "hard" policy,
   the transport connection MUST be terminated when the AGI is violated.
   In "soft" policy, it MUST be suspended when the AGI is violated and
   it will be restored if the AGI is recovered.

   <condition> defines "unity" or "quorum". "unity" specifies that all
   of enrolled group members are required to be present in the active
   group. "quorum" implies that the majority of group members are
   required to be present.



4.2 Attributes for Membership Information


   * a=max:<maximum number>

   This attributes specifies maximum number of participants that can be
   allowed in an active group. The value of <maximum number> is
   represented as a numeric number like "a=max:100".


   * a=min:<minimum number>

   This attributes specifies minimum number of participants that can be
   allowed in an active group. The value of <minimum number> is
   represented as a numeric number like "a=min:3".



E.Kim                    Expires - April 2005                 [Page 5]


                   Tight Membership Support in SDP       October 2004


   * a=token:<token number>

   This attribute specifies maximum number of participants that can be
   allowed to concurrently transmit data. The value of <token number> is
   represented as a numeric number like "a=token number:3".


   * a=mandatory:permission <user id>/<URIs>/<others>

   This attribute specifies the selected group members required to be
   present or blocked in an active group. The value of permission is
   "in" or "out", which represents the user is a mandatory participant
   or a blocked participant. A series of "a=mandatory" can be specified
   as following examples:

   a=mandatory:in eunah/<sip:eunah@etri.re.kr>/ /
   a=mandatory:out bob/<sip:bob@example.com>/ /


   <user id> is the same with <username> in origin field of RFC2327.
   <URIs> address the users contact information. <others> can be used to
   specify additional information.

   In order to identify mandatory users, a key should be exchanged, but
   the detail methods of the key exchanges are of out the scope of this
   document.


5. Example of membership negotiation

   Assume that the caller, Alice, has included the following description
   in her offer. The offered SDP is:


   v=0
   o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
   s=Example of SDP extension for group information
   c=IN IP4 host.anywhere.com
   t=0 0
   a=agipolicy:hard/quorum
   a=min:3
   a=token:2
   a=mandatory:in bob/<sip:bob@example.com>/ /
   a=mandatory:in eunah/Eunsook Kim <sip:eunah@etri.re.kr>/ /
   m=audio 49170 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 51372 RTP/AVP 31
   a=rtpmap:31 H261/90000



E.Kim                    Expires - April 2005                 [Page 6]


                   Tight Membership Support in SDP       October 2004


   The callee, Bob, want to create the group with "unity" condition, so
   he returns the SDP below as the answer:


   v=0
   o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
   s=Example of SDP extension for group information
   c=IN IP4 host.anywhere.com
   t=0 0
   a=agipolicy:hard/unity
   a=min:3
   a=token:2
   a=mandatory:in bob/<sip:bob@example.com>/ /
   a=mandatory:in eunah/Eunsook Kim <sip:eunah@etri.re.kr>/ /
   m=audio 49170 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 51372 RTP/AVP 31
   a=rtpmap:31 H261/90000



6. Security Considerations

   Group membership policy and information is very sensitive information,
   so that it MUST use appropriate authentication to ensure the data
   originated from trusted parties. Other SDP considerations apply. The
   further concerned security issues will be identified as the further
   works go on.



7. References

   [1] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC
      2327, April 1998

   [2] J. Rosenberg, H. Schulzrinne, " An Offer/Answer Model with the
      Session Description Protocol (SDP)," RFC 3264, June 2002.

   [3] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
            Levels", BCP 14, RFC 2119, March 1997.










E.Kim                    Expires - April 2005                 [Page 7]


                   Tight Membership Support in SDP       October 2004


Acknowledgments

   Authors are thanks for J. Ott and C. Perkins for their comments.



Author's Addresses


      Eunsook Kim
      161 Gajeong-Dong Yuseong-Gu
      Deajon 305-350
      Korea

      E-mail: eunah@etri.re.kr


      Juyoung Park
      361 Gajeong-Dong Yuseong-Gu
      Deajon 305-350
      Korea

      E-mail: jypark@etri.re.kr


      Shin-Gak Kang
      361 Gajeong-Dong Yuseong-Gu
      Deajon 305-350
      Korea

      E-mail: sgkang@etri.re.kr



















E.Kim                    Expires - April 2005                 [Page 8]


                   Tight Membership Support in SDP       October 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



E.Kim                    Expires - April 2005                 [Page 9]


                   Tight Membership Support in SDP       October 2004



















































E.Kim                    Expires - April 2005                [Page 10]