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 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: a=agipolicy:/ 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. 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. 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: This attributes specifies maximum number of participants that can be allowed in an active group. The value of is represented as a numeric number like "a=max:100". * a=min: This attributes specifies minimum number of participants that can be allowed in an active group. The value of 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: This attribute specifies maximum number of participants that can be allowed to concurrently transmit data. The value of is represented as a numeric number like "a=token number:3". * a=mandatory:permission // 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// / a=mandatory:out bob// / is the same with in origin field of RFC2327. address the users contact information. 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// / a=mandatory:in eunah/Eunsook Kim / / 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// / a=mandatory:in eunah/Eunsook Kim / / 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]