INTERNET-DRAFT J. Ott
Expires: January 2005 TZI
12 July 2004
SDP Attributes for T.120 Data Conferencing
draft-ott-mmusic-sdp-t120-00.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,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, I accept the provisions of Section
3 of RFC 3667 (BCP 78).
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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Distribution of this document is unlimited.
This document is a contribution to the Multiparty Multimedia Session
Control (MMUSIC) working group of the Internet Engineering Task
Force. Comments are solicited and should be addressed to the working
group's mailing list at mmusic@ietf.org and/or the authors.
Abstract
This memo specifies the use of the Session Description Protocol in
combination with the SDP Offer/Answer exchange to setup and teardown
data conferecing sessions based upon the ITU-T T.120 Series of
Recommendations, thereby particularly enabling application sharing as
defined in ITU-T T.128.
Ott [Page 1]
INTERNET-DRAFT SDP Attributes for T.120 Data Conferencing 12 July 2004
1. Introduction
SDP [1] is widely used in the Internet today to describe multimedia
sessions between two or more endpoints. The offer/answer exchange
[2] allows two endpoints to negotiate the media streams to be
established, e.g. in the context of a SIP dialog [4]. While fax and
text conversation have been defined for use with SIP, the primary
media types in use today are still audio and video. What is
currently lacking is the support for application-sharing, shared
editing, whiteboard and similar teleconferencing tools.
This memo defines a minimal set of SDP attributes to enable
standardized setup of T.120 data conferencing sessions -- and
particularly application sharing as defined in T.128 and implemented
e.g. in NetMeeting.
While SDP is defined for use with many signaling protocols, the use
of T.120 is probably only meaningful for SIP calls and conferences
and hence this memo focuses on its use with SIP.
2. Overview of T.120
T.120 defines multipoint conferencing protocols and services for data
applications including whiteboard (T.126), file transfer (T.127),
application sharing (T.128), and text conversation (T.134, T.140),
among others [5].
In T.120, communication takes place in a hierarchical structure of
T.120 entities interconnected by T.120 connections. In the simplest
case, this may be just two entities interconnected via a T.120
connection, in a slightly more sophisticated one a single conference
bridge (MCU) may be used to interconnect more than two entities.
Each point-to-point T.120 connection uses TCP as underlying transport
and TPKT (RFC1006) framing on top [6]. Up to four TCP connections
may be between any two T.120 entities to provide independent flow
control for different transmission priorities.
The lowest layer above the point-to-point transport is the Multipoint
Communication Service (MCS) [7][8]. The MCS defines a connection
setup procedure that allows to associate different transport
connections with the same MCS Domaina and to organize the MCS
"providers" in a tree structure during connection setup. In the
resulting tree, the MCS provides a multiplex for application data
(using up to 64K channels) and simple means for synchronizations
(tokens).
On top of MCS, the Generic Conference Control (GCC) [9] is
responsible for controlling the connection setup and their
association with a conference. Furthermore, GCC manages conference
resources, provides capability exchange, allows for floor control,
and provides some kind of a conference-wide registry. In GCC,
conferences are identified by means of an octet string that is mapped
to the MCS Domain identifier. GCC allows to create and destroy
Ott [Page 2]
INTERNET-DRAFT SDP Attributes for T.120 Data Conferencing 12 July 2004
conferences as well as to inquire for, join, and leave existing ones.
T.120 data applications make use of the MCS communication platform to
exchange information and of the GCC services to learn about each
others existence and to find each other. In particular, GCC's
capability exchange mechanism is used to discover commonly available
applications and their respective features (with many tiny details
being negotiable).
The purpose of this memo is to define a minimal meaningful set of SDP
attributes that allows two nodes to learn about their respective
T.120 capabilities and enable them to set up a single T.120
connection. Whether a single or more TCP connections are used and
how those are associated if entirely left up to the respective T.120
entities, as is most of the T.120-specific capability exchange.
3. T.120 Setup Procedure
3.1. Use of the m= line
A T.120 session is based upon TCP as underlying transport.
Therefore, the rules for connection-oriented media as defined in [3]
MUST be followed.
The media part on the m= line MUST indicate "data", the port number
indicate the port number to connect to (for one to four transport
connections, again following the rules of [3]), the proto part MUST
indicate "TCP" and the format MUST indicate "t120". The
registered port number for T.120 is 1503.
3.2. T.120-specific Attributes
T.120 connections established within the context of an SDP
offer/answer exchange may need to be associated with a SIP dialog or
a SIP conference. Therefore, the media-level "confname" attribute
is introduced. The content of the confname attribute MUST be copied
to the ConferenceName field used by the GCC entity. For a simple SIP
dialog, the confname attribute SHOULD contain the SIP From tag, To
tag, and Call-ID, concatenated with the comma (",") as a separator.
For a SIP dialog in a conference, the confname attribute SHOULD
contain the focus URI.
T.120 defines a number of applications. To determine from the
offer/answer exchange whether or not at least the target
application(s) are available at a peer, the optional "t120apps"
attribute is introduced. If present, this attribute SHOULD contain a
list of T.120 application protocols supported by the respective peer.
The following application protocols are defined: "t126", "t127",
"t128", "t134", "t136", and "t137". The fine-grained
Ott [Page 3]
INTERNET-DRAFT SDP Attributes for T.120 Data Conferencing 12 July 2004
negotiation of capabilities within these application protocols is
left up to the GCC operation after setup of a T.120 connection.
3.3. Offer/Answer Operation
The offerer wishing to set up a T.120 session MUST include an m= line
according to section 3.1 and include an appropriate c= line. The
offerer MUST choose a new "connid" and MAY choose to specify a
"setup" attribute of "active", "passive", or "actpass". The
offerer MUST provide the "confname" attribute as specified in
section 3.2 and SHOULD include the list of supported T.120
application protocols.
The answerer MUST examine that it supports T.120 protocol. If it
does not support T.120 or does not wish to use T.120 in the present
communication relationship, it MUST refure the media section by
setting the port number to "0" in the answer. If the answerer
supports T.120, it MUST validate the "confname" attribute. If no
matching SIP dialog or focus URI can be found, the media section
SHOULD be refused by setting the port number to "0" in the answer.
If a matching conference is found and the "t120apps" attribute is
not present, the answerer MAY decide whether to accept the session
and proceed with the transport connection setup as per [3] or whether
to refuse the media section. If the "t120apps" attribute is
present, the answerer MUST examine its contents and match the
applications listed by the offerer against its own capabilities. If
the intersection of capabilities is empty, the answerer SHOULD refuse
the media section. If the intersection is not empty, the answerer
SHOULD return the intersecting capabilities (in the order provided by
the offerer) and then proceed with the transport connection setup as
per [3].
After successful establishment of a TCP connection as per [3], the
respective entities MUST proceed with the T.120 connection setup as
defined in [6], [8], and [9].
4. Formal SDP Attribute Specification
This section provides the formal SDP attribute specification:
confname = "a=confname:" token
t120apps = "a=t120apps:" t120appid *("," t120appid)
t120appid = "t126" / "t127" / "t128" / "t134" /
"t136" / "t137"
5. Example
In the following example, an node A wants to set up a telephone call
to a node B and use supportive data applications (whiteboard, file
transfer, and application sharing). Node A expects to initiate
connection setup to node B and therefore uses port number 9 [3] and
Ott [Page 4]
INTERNET-DRAFT SDP Attributes for T.120 Data Conferencing 12 July 2004
sets the setup attribute to "active".
c=IN IP4 10.20.30.40
m=audio 52000 UDP/AVP 96 97
a=rtpmap:96 PCMU/8000
a=rtpmap:97 L16/16000
m=data 9 TCP t120
a=setup:active
a=connid:1
a=confname:623847692,789234789,78687afded278bd@example.com
a=t120apps:t126,t127,t128
Node B accepts the T.120 media session in its answer. However, as
node B does not support whiteboard and file transfer, it only
confirms application sharing (T.128) in its answer. Node B offers
the registered T.120 port number to connect to.
c=IN IP4 10.20.30.40
m=audio 52000 UDP/AVP 96
a=rtpmap:96 PCMU/8000
m=data 1503 TCP t120
a=setup:passive
a=connid:1
a=confname:623847692,789234789,78687afded278bd@example.com
a=t120apps:t128
6. IANA Considerations
This document defines two media level SDP attributes: "confname"
and "t120apps". Their format is defined in Section 4. These two
attributes should be registered by the IANA on
http://www.iana.org/assignments/sdp-parameters
under "att-field (at the media level only)".
7. Security Considerations
TBD.
8. Author's Addresses
Joerg Ott <jo@tzi.org>
Universitaet Bremen
MZH 5180
Bibliothekstr. 1
D-28359 Bremen
Germany
tel:+49-421-201-7028
sip:jo@tzi.org
Ott [Page 5]
INTERNET-DRAFT SDP Attributes for T.120 Data Conferencing 12 July 2004
9. Normative References
[1] Mark Handley, Van Jacobson, Colin Perkins, "SDP: Session
Description Protocol," Internet Draft draft-ietf-mmusic-sdp-
new-18.txt, Work in Progress, June 2004.
[2] Jonathan Rosenberg and Henning Schulzrinne, "An Offer/Answer
Model with SDP," RFC 3264, June 2002.
[3] David Yon and Gonzalo Camarillo, "Connection-Oriented Media
Transport in SDP," Internet Draft draft-ietf-mmusic-sdp-
comedia-07.txt, Work in Progress, June 2004.
[4] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session
Initiation Protocol," RFC 3261, June 2002.
[5] ITU-T Recommendation T.120, "Data Protocols for Multimedia
Conferencing", 1996.
[6] ITU-T Recommendation T.123, "Network Specific Data Protocol
Stacks for Multimedia Conferencing", 1996.
[7] ITU-T Recommendation T.122, "Multipoint Communication Service
for Audiographics and Audiovisual Conferencing Service
Definition," 1993.
[8] ITU-T Recommendation T.125,."Multipoint Communication Service
Protocol Specification," 1994.
[9] ITU-T Recommendation T.124, "Generic Conference Control,",
1995.
Intellectual Property Notice
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
Ott [Page 6]
INTERNET-DRAFT SDP Attributes for T.120 Data Conferencing 12 July 2004
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.
Full 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ott [Page 7]