idnits 2.17.1 draft-ott-mmusic-sdp-t120-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 309. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 124: '... MUST be followed....' RFC 2119 keyword, line 126: '...t on the m= line MUST indicate "data",...' RFC 2119 keyword, line 128: '... connections, again following the rules of [3]), the proto part MUST...' RFC 2119 keyword, line 129: '..." and the format MUST indicate "t120"....' RFC 2119 keyword, line 137: '... the confname attribute MUST be copied...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (12 July 2004) is 7226 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-18 == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-comedia-07 -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Ott 2 Expires: January 2005 TZI 3 12 July 2004 5 SDP Attributes for T.120 Data Conferencing 6 draft-ott-mmusic-sdp-t120-00.txt 8 Status of this memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668 (BCP 79). 15 By submitting this Internet-Draft, I accept the provisions of Section 16 3 of RFC 3667 (BCP 78). 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 To view the list Internet-Draft Shadow Directories, see 32 http://www.ietf.org/shadow.html. 34 Distribution of this document is unlimited. 36 This document is a contribution to the Multiparty Multimedia Session 37 Control (MMUSIC) working group of the Internet Engineering Task 38 Force. Comments are solicited and should be addressed to the working 39 group's mailing list at mmusic@ietf.org and/or the authors. 41 Abstract 43 This memo specifies the use of the Session Description Protocol in 44 combination with the SDP Offer/Answer exchange to setup and teardown 45 data conferecing sessions based upon the ITU-T T.120 Series of 46 Recommendations, thereby particularly enabling application sharing as 47 defined in ITU-T T.128. 49 1. Introduction 51 SDP [1] is widely used in the Internet today to describe multimedia 52 sessions between two or more endpoints. The offer/answer exchange 53 [2] allows two endpoints to negotiate the media streams to be 54 established, e.g. in the context of a SIP dialog [4]. While fax and 55 text conversation have been defined for use with SIP, the primary 56 media types in use today are still audio and video. What is 57 currently lacking is the support for application-sharing, shared 58 editing, whiteboard and similar teleconferencing tools. 60 This memo defines a minimal set of SDP attributes to enable 61 standardized setup of T.120 data conferencing sessions -- and 62 particularly application sharing as defined in T.128 and implemented 63 e.g. in NetMeeting. 65 While SDP is defined for use with many signaling protocols, the use 66 of T.120 is probably only meaningful for SIP calls and conferences 67 and hence this memo focuses on its use with SIP. 69 2. Overview of T.120 71 T.120 defines multipoint conferencing protocols and services for data 72 applications including whiteboard (T.126), file transfer (T.127), 73 application sharing (T.128), and text conversation (T.134, T.140), 74 among others [5]. 76 In T.120, communication takes place in a hierarchical structure of 77 T.120 entities interconnected by T.120 connections. In the simplest 78 case, this may be just two entities interconnected via a T.120 79 connection, in a slightly more sophisticated one a single conference 80 bridge (MCU) may be used to interconnect more than two entities. 81 Each point-to-point T.120 connection uses TCP as underlying transport 82 and TPKT (RFC1006) framing on top [6]. Up to four TCP connections 83 may be between any two T.120 entities to provide independent flow 84 control for different transmission priorities. 86 The lowest layer above the point-to-point transport is the Multipoint 87 Communication Service (MCS) [7][8]. The MCS defines a connection 88 setup procedure that allows to associate different transport 89 connections with the same MCS Domaina and to organize the MCS 90 "providers" in a tree structure during connection setup. In the 91 resulting tree, the MCS provides a multiplex for application data 92 (using up to 64K channels) and simple means for synchronizations 93 (tokens). 95 On top of MCS, the Generic Conference Control (GCC) [9] is 96 responsible for controlling the connection setup and their 97 association with a conference. Furthermore, GCC manages conference 98 resources, provides capability exchange, allows for floor control, 99 and provides some kind of a conference-wide registry. In GCC, 100 conferences are identified by means of an octet string that is mapped 101 to the MCS Domain identifier. GCC allows to create and destroy 102 conferences as well as to inquire for, join, and leave existing ones. 104 T.120 data applications make use of the MCS communication platform to 105 exchange information and of the GCC services to learn about each 106 others existence and to find each other. In particular, GCC's 107 capability exchange mechanism is used to discover commonly available 108 applications and their respective features (with many tiny details 109 being negotiable). 111 The purpose of this memo is to define a minimal meaningful set of SDP 112 attributes that allows two nodes to learn about their respective 113 T.120 capabilities and enable them to set up a single T.120 114 connection. Whether a single or more TCP connections are used and 115 how those are associated if entirely left up to the respective T.120 116 entities, as is most of the T.120-specific capability exchange. 118 3. T.120 Setup Procedure 120 3.1. Use of the m= line 122 A T.120 session is based upon TCP as underlying transport. 123 Therefore, the rules for connection-oriented media as defined in [3] 124 MUST be followed. 126 The media part on the m= line MUST indicate "data", the port number 127 indicate the port number to connect to (for one to four transport 128 connections, again following the rules of [3]), the proto part MUST 129 indicate "TCP" and the format MUST indicate "t120". The 130 registered port number for T.120 is 1503. 132 3.2. T.120-specific Attributes 134 T.120 connections established within the context of an SDP 135 offer/answer exchange may need to be associated with a SIP dialog or 136 a SIP conference. Therefore, the media-level "confname" attribute 137 is introduced. The content of the confname attribute MUST be copied 138 to the ConferenceName field used by the GCC entity. For a simple SIP 139 dialog, the confname attribute SHOULD contain the SIP From tag, To 140 tag, and Call-ID, concatenated with the comma (",") as a separator. 141 For a SIP dialog in a conference, the confname attribute SHOULD 142 contain the focus URI. 144 T.120 defines a number of applications. To determine from the 145 offer/answer exchange whether or not at least the target 146 application(s) are available at a peer, the optional "t120apps" 147 attribute is introduced. If present, this attribute SHOULD contain a 148 list of T.120 application protocols supported by the respective peer. 149 The following application protocols are defined: "t126", "t127", 150 "t128", "t134", "t136", and "t137". The fine-grained 151 negotiation of capabilities within these application protocols is 152 left up to the GCC operation after setup of a T.120 connection. 154 3.3. Offer/Answer Operation 156 The offerer wishing to set up a T.120 session MUST include an m= line 157 according to section 3.1 and include an appropriate c= line. The 158 offerer MUST choose a new "connid" and MAY choose to specify a 159 "setup" attribute of "active", "passive", or "actpass". The 160 offerer MUST provide the "confname" attribute as specified in 161 section 3.2 and SHOULD include the list of supported T.120 162 application protocols. 164 The answerer MUST examine that it supports T.120 protocol. If it 165 does not support T.120 or does not wish to use T.120 in the present 166 communication relationship, it MUST refure the media section by 167 setting the port number to "0" in the answer. If the answerer 168 supports T.120, it MUST validate the "confname" attribute. If no 169 matching SIP dialog or focus URI can be found, the media section 170 SHOULD be refused by setting the port number to "0" in the answer. 171 If a matching conference is found and the "t120apps" attribute is 172 not present, the answerer MAY decide whether to accept the session 173 and proceed with the transport connection setup as per [3] or whether 174 to refuse the media section. If the "t120apps" attribute is 175 present, the answerer MUST examine its contents and match the 176 applications listed by the offerer against its own capabilities. If 177 the intersection of capabilities is empty, the answerer SHOULD refuse 178 the media section. If the intersection is not empty, the answerer 179 SHOULD return the intersecting capabilities (in the order provided by 180 the offerer) and then proceed with the transport connection setup as 181 per [3]. 183 After successful establishment of a TCP connection as per [3], the 184 respective entities MUST proceed with the T.120 connection setup as 185 defined in [6], [8], and [9]. 187 4. Formal SDP Attribute Specification 189 This section provides the formal SDP attribute specification: 191 confname = "a=confname:" token 193 t120apps = "a=t120apps:" t120appid *("," t120appid) 194 t120appid = "t126" / "t127" / "t128" / "t134" / 195 "t136" / "t137" 197 5. Example 199 In the following example, an node A wants to set up a telephone call 200 to a node B and use supportive data applications (whiteboard, file 201 transfer, and application sharing). Node A expects to initiate 202 connection setup to node B and therefore uses port number 9 [3] and 203 sets the setup attribute to "active". 205 c=IN IP4 10.20.30.40 206 m=audio 52000 UDP/AVP 96 97 207 a=rtpmap:96 PCMU/8000 208 a=rtpmap:97 L16/16000 209 m=data 9 TCP t120 210 a=setup:active 211 a=connid:1 212 a=confname:623847692,789234789,78687afded278bd@example.com 213 a=t120apps:t126,t127,t128 215 Node B accepts the T.120 media session in its answer. However, as 216 node B does not support whiteboard and file transfer, it only 217 confirms application sharing (T.128) in its answer. Node B offers 218 the registered T.120 port number to connect to. 220 c=IN IP4 10.20.30.40 221 m=audio 52000 UDP/AVP 96 222 a=rtpmap:96 PCMU/8000 223 m=data 1503 TCP t120 224 a=setup:passive 225 a=connid:1 226 a=confname:623847692,789234789,78687afded278bd@example.com 227 a=t120apps:t128 229 6. IANA Considerations 231 This document defines two media level SDP attributes: "confname" 232 and "t120apps". Their format is defined in Section 4. These two 233 attributes should be registered by the IANA on 235 http://www.iana.org/assignments/sdp-parameters 237 under "att-field (at the media level only)". 239 7. Security Considerations 241 TBD. 243 8. Author's Addresses 245 Joerg Ott 246 Universitaet Bremen 247 MZH 5180 248 Bibliothekstr. 1 249 D-28359 Bremen 250 Germany 251 tel:+49-421-201-7028 252 sip:jo@tzi.org 254 9. Normative References 256 [1] Mark Handley, Van Jacobson, Colin Perkins, "SDP: Session 257 Description Protocol," Internet Draft draft-ietf-mmusic-sdp- 258 new-18.txt, Work in Progress, June 2004. 260 [2] Jonathan Rosenberg and Henning Schulzrinne, "An Offer/Answer 261 Model with SDP," RFC 3264, June 2002. 263 [3] David Yon and Gonzalo Camarillo, "Connection-Oriented Media 264 Transport in SDP," Internet Draft draft-ietf-mmusic-sdp- 265 comedia-07.txt, Work in Progress, June 2004. 267 [4] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 268 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session 269 Initiation Protocol," RFC 3261, June 2002. 271 [5] ITU-T Recommendation T.120, "Data Protocols for Multimedia 272 Conferencing", 1996. 274 [6] ITU-T Recommendation T.123, "Network Specific Data Protocol 275 Stacks for Multimedia Conferencing", 1996. 277 [7] ITU-T Recommendation T.122, "Multipoint Communication Service 278 for Audiographics and Audiovisual Conferencing Service 279 Definition," 1993. 281 [8] ITU-T Recommendation T.125,."Multipoint Communication Service 282 Protocol Specification," 1994. 284 [9] ITU-T Recommendation T.124, "Generic Conference Control,", 285 1995. 287 Intellectual Property Notice 289 The IETF takes no position regarding the validity or scope of any 290 Intellectual Property Rights or other rights that might be claimed to 291 pertain to the implementation or use of the technology described in 292 this document or the extent to which any license under such rights 293 might or might not be available; nor does it represent that it has 294 made any independent effort to identify any such rights. Information 295 on the procedures with respect to rights in RFC documents can be 296 found in BCP 78 and BCP 79. 298 Copies of IPR disclosures made to the IETF Secretariat and any 299 assurances of licenses to be made available, or the result of an 300 attempt made to obtain a general license or permission for the use of 301 such proprietary rights by implementers or users of this 302 specification can be obtained from the IETF on-line IPR repository at 303 http://www.ietf.org/ipr. 305 The IETF invites any interested party to bring to its attention any 306 copyrights, patents or patent applications, or other proprietary 307 rights that may cover technology that may be required to implement 308 this standard. Please address the information to the IETF at ietf- 309 ipr@ietf.org. 311 Disclaimer of Validity 313 This document and the information contained herein are provided on an 314 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 315 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 316 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 317 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 318 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 319 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 321 Full Copyright Statement 323 Copyright (C) The Internet Society (2004). This document is subject 324 to the rights, licenses and restrictions contained in BCP 78, and 325 except as set forth therein, the authors retain all their rights. 327 Acknowledgment 329 Funding for the RFC Editor function is currently provided by the 330 Internet Society.