Internet DRAFT - draft-ekim-mmusic-sdp-membership
draft-ekim-mmusic-sdp-membership
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]
