idnits 2.17.1 draft-ietf-mmusic-sdp-comedia-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 10 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([SDP], [UTF-8]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 35 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** 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 187: '...a) Each endpoint MUST accept data from...' RFC 2119 keyword, line 190: '... connections, it MUST use that connect...' RFC 2119 keyword, line 194: '...etermined to be idle, the endpoint MAY...' RFC 2119 keyword, line 380: '...n-setup" attribute field, which MAY be...' 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 (February 2001) is 8468 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) == Unused Reference: 'T38' is defined on line 402, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2960 (ref. 'SCTP') (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 2327 (ref. 'SDP') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. 'T38' ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2044 (ref. 'UTF-8') (Obsoleted by RFC 2279) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D. Yon 3 Document: draft-ietf-mmusic-sdp-comedia-00.txt Dialout.Net 4 Expires August 2001 February 2001 6 Connection-Oriented Media Transport in SDP 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at: 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at: 28 http://www.ietf.org/shadow.html. 30 Copyright (C) The Internet Society (2001). All Rights Reserved. 32 Abstract 34 This document describes how to express media transport over 35 connection-oriented protocols using the Session Description Protocol 36 (SDP). It defines three new protocol identifiers: TCP, TLS and 37 SCTP. It also defines the syntax and semantics for an SDP 38 "direction" attribute that describes the connection setup procedure. 40 Yon 1 41 Introduction 43 The Session Description Protocol [SDP] provides a general-purpose 44 format for describing multimedia sessions in announcements or 45 invitations. SDP uses an entirely textual data format (the US-ASCII 46 subset of [UTF-8]) to maximize portability among transports. SDP 47 does not define a protocol, but only the syntax to describe a 48 multimedia session with sufficient information to discover and 49 participate in that session. Session descriptions may be sent using 50 any number of existing application protocols for transport (e.g., 51 SAP, SIP, RTSP, email, HTTP, etc.). 53 Motivation 55 [SDP] describes two protocol identifiers: RTP/AVP and UDP, both of 56 which are unreliable, connectionless protocols, an appropriate 57 choice for multimedia streams. There are, however, applications for 58 which the connection-oriented transports such as TCP or SCTP is more 59 appropriate, but [SDP] provides no way to describe a session that 60 uses protocols other than RTP or UDP. 62 Connection-oriented protocols introduce a new factor when describing 63 a session: not only must it be possible to express that a protocol 64 will be based on this protocol, but it must also describe the 65 connection setup procedure. 67 1 Protocol Identifiers 69 1.1 TCP 71 The TCP protocol identifier is similar to the UDP protocol 72 identifier in that it only describes the transport protocol without 73 any connotation as to the upper-layer protocol. An m= line that 74 specifies TCP must further qualify the protocol using a fmt 75 identifier (see [SDP] Appendix B). 77 1.2 SCTP 79 The SCTP protocol identifier, like TCP above, only describes the 80 transport protocol without any connotation as to the upper-layer 81 protocol. An m= line that specifies SCTP indicates that media will 82 be transports using the SCTP protocol [SCTP], with an upper-layer 83 protocol specified by the fmt identifier. 85 1.3 TLS 87 The TLS protocol identifier specifies that the session will use the 88 Transport Layer Security protocol [TLS] with an implied transport 89 protocol of TCP. To describe a media session that uses TLS over 90 TCP, the protocol identifier TLS must be specified in the m= line. 91 An m= line that specifies TLS must further qualify the protocol 92 using a fmt identifier. 94 Yon INTERNET-DRAFT � Expires August 2001 2 95 2 Direction Attribute 97 An important attribute of connection-oriented protocols is the setup 98 procedure. One endpoint needs to initiate the connection and the 99 other endpoint needs to accept the connection. The direction 100 attribute is used to describe these roles, and the syntax is as 101 follows: 103 a=direction: 105 The is one of the following: 107 passive: The endpoint will accept an incoming connection. 109 active: The endpoint will initiate an outgoing connection. 111 both: The endpoint will both accept an incoming connection 112 and will initiate an outgoing connection. 114 The is an optional value that may only be specified in 115 the context of direction:active or direction:both. 117 2.1 Semantics of direction:passive 119 By specifying direction:passive, the endpoint indicates that the 120 port number specified in the m= line is available to accept a 121 connection from the other endpoint. 123 2.2 Semantics of direction:active 125 By specifying direction:active, the endpoint indicates that it will 126 initiate a connection to the port number on the m= line of the other 127 endpoint. The port number on its own m= line is irrelevant and is 128 to be ignored by the other endpoint. Nevertheless, since the m= 129 line must contain a valid port number, the endpoint specifying 130 direction:active should specify a port number of 9 (the discard 131 port) on its m= line. The endpoint must not specify a port number 132 of zero, as that carries other semantics in [SDP]. 134 The endpoint may optionally specify the port number from which it 135 will initiate the connection in the position on the a= 136 line. 138 2.3 Semantics of direction:both 140 By specifying direction:both, the endpoint indicates that it will 141 both accept a TCP connection on the port number of its own m= line, 142 and that it will also initiate a connection to the port number on 143 the m= line of the other endpoint. As with direction:active, the 144 endpoint may optionally specify the port number from which it will 145 initiate the connection in the position on the a= 146 line. 148 Yon INTERNET-DRAFT � Expires August 2001 3 149 Since this attribute describes behavior that is similar to 150 connectionless media descriptions in [SDP], it is the default value 151 for the direction attribute and is therefore optional. 153 Endpoints may choose to specify direction:both for one or more of 154 the following reasons: 156 1) The endpoint has no preference as to whether it accepts or 157 initiates the connection, and therefore is offering the remote 158 endpoint a choice of connection setup procedures. 160 2) The endpoints intend to use a single connection to transport 161 the media, but it is not known whether firewall issues will 162 prevent either endpoint from initiating or accepting the 163 connection. Therefore both endpoints will attempt to initiate 164 a connection in hopes that at least one will succeed. 166 3) The endpoints intend to use two connections to transport the 167 media, and one must be initiated by the remote endpoint and 168 the other must be initiated by the local endpoint. 170 If one endpoint specifies either direction:active or 171 direction:passive and the other specifies direction:both, both 172 endpoints must behave as if the latter had specified the inverse 173 direction of the former. For example, specifying direction:both 174 when the other endpoint specifies direction:active should cause both 175 endpoints to behave as if the former had specified 176 direction:passive. Conversely, specifying direction:both when the 177 other endpoint specifies direction:passive should cause both 178 endpoints to behave as if the former had specified direction:active. 180 If both endpoints specify direction:both then each endpoint must 181 initiate a connection to the port number specified on the m= line of 182 the opposite endpoint. If only one connection succeeds, then that 183 connection will be used to carry the media. If both connections 184 succeed but only one was needed (case #2 above), the following rules 185 shall apply: 187 a) Each endpoint MUST accept data from either connection. 189 b) Once an endpoint has transmitted data to one of the 190 connections, it MUST use that connection exclusively for 191 transmission. 193 c) Once an endpoint has transmitted AND received data, if one of 194 the connections is determined to be idle, the endpoint MAY 195 close the idle connection. 197 3 Source-Port Considerations 199 In the cases where the endpoint is initiating the connection, a 200 source port number may optionally be specified on the a= line by 201 that endpoint. In most environments, the source port number can be 203 Yon INTERNET-DRAFT � Expires August 2001 4 204 determined by binding the socket before initiating the connect, as 205 shown in the sample C code below: 207 { 208 SOCKET s_id 209 SOCKADDR_IN cli_sin; 210 int namelen; 212 // Create the socket 213 s_id = socket(AF_INET,SOCK_STREAM,IPPROTO_TCP); 215 // Bind the socket to any IP address and port 216 bzero((char *)&cli_sin,sizeof(cli_sin)); 217 cli_sin.sin_family = AF_INET; 218 cli_sin.sin_addr.s_addr = htonl(INADDR_ANY); 219 cli_sin.sin_port = 0; 220 bind(s_id,(SOCKADDR *)&cli_sin,sizeof(cli_sin)); 222 // Find the port number that was bound 223 namelen = sizeof(cli_sin); 224 getsockname(s_id,(SOCKADDR *)&cli_sin,&namelen); 226 // Print the port number 227 printf("Source Port = %d\n",ntohs(cli_sin.sin_port)); 228 } 230 The motivation for specifying the source port is to allow topologies 231 where one or more endpoints use a single, fixed TCP port for 232 incoming connections. Non-RTP protocols transported over TCP 233 commonly use this technique. By specifying the source port, an 234 endpoint avoids a potential ambiguity when more than one session is 235 set up between two endpoints. 237 For example, consider two endpoints with IP addresses of 10.1.1.1 238 and 10.1.1.2. The endpoint at 10.1.1.1 signals the availability of 239 a session on TCP port 2393 (passive). Before the endpoint at 240 10.1.1.2 has a chance to initiate the connection, events transpire 241 that cause the endpoint at 10.1.1.1 to signal the availability of a 242 separate session that is also found at TCP port 2393 (passive). 243 Shortly thereafter, both entities at 10.1.1.2 initiate connections 244 to 10.1.1.1 on port 2393. 246 The problem is this: how does the endpoint at 10.1.1.1 differentiate 247 the two connections? To which entity at 10.1.1.2 does each 248 connection correspond? By specifying the source port prior to 249 connecting, the entities at 10.1.1.2 can avoid this ambiguity, 250 because now the endpoint at 10.1.1.1 can simply inspect the port 251 number from which the connection originated to determine which 252 entity has initiated the connection. 254 Caution must be exercised when designing systems that rely on this 255 feature, as not all environments are able to determine the source 256 port prior to initiating the connection. 258 Yon INTERNET-DRAFT � Expires August 2001 5 259 4 Examples 261 What follows are a number of examples that show the most common 262 usage of the direction attribute combined with TCP-based media 263 descriptions. For the purpose of brevity, the main portion of the 264 session description is omitted in the examples and is assumed to be 265 the following: 267 v=0 268 o=Me 269 s=Call me using TCP 270 t=0 0 272 4.1 Example: simple passive/active 274 An endpoint at 10.1.1.2 signals the availability of a T.38 fax 275 session at port 54111: 277 c=IN IP4 10.1.1.2/127 278 m=image 54111 TCP t38 279 a=direction:passive 281 An endpoint at 10.1.1.1 receiving this description responds with the 282 following: 284 c=IN IP4 10.1.1.1/127 285 m=image 9 TCP t38 286 a=direction:active 288 The endpoint at 10.1.1.1 then initiates the TCP connection to port 289 54111 at 10.1.1.2. Note that the TCP connection may originate from 290 any port. The endpoint at 10.1.1.1 could have optionally committed 291 to a source port with a simple modification: 293 c=IN IP4 10.1.1.1/127 294 m=image 9 TCP t38 295 a=direction:active 1892 297 By adding the "1892" to the a= line, the endpoint at 10.1.1.1 must 298 now use a source port of 1892 when initiating the TCP connection to 299 port 54111 at 10.1.1.2. 301 4.2 Example: agnostic both 303 An endpoint at 10.1.1.2 signals the availability of a T.38 fax 304 session at TCP port 54111, but is also willing to set up the media 305 stream by initiating the TCP connection: 307 c=IN IP4 10.1.1.2/127 308 m=image 54111 TCP t38 309 a=direction:both 311 The endpoint at 10.1.1.1 has three choices: 313 Yon INTERNET-DRAFT � Expires August 2001 6 314 1) It can respond with either of the two direction:active 315 descriptions listed in the previous example. In this case the 316 endpoint at 10.1.1.1 must initiate a connection to port 54111 317 at 10.1.1.2. 319 2) It can respond with a description similar to the following: 321 c=IN IP4 10.1.1.1/127 322 m=image 54321 TCP t38 323 a=direction:passive 325 In this case the endpoint at 10.1.1.2 must initiate a 326 connection to port 54321 at 10.1.1.1. 328 3) It can respond with a description that specifies 329 direction:both, which is covered in the next example. 331 4.3 Example: redundant both 333 An endpoint at 10.1.1.2 uses the same description as the previous 334 example: 336 c=IN IP4 10.1.1.2/127 337 m=image 54111 TCP t38 338 a=direction:both 340 Unlike the previous example, the endpoint at 10.1.1.1 responds with 341 the following description: 343 c=IN IP4 10.1.1.1/127 344 m=image 54321 TCP t38 345 a=direction:both 347 This will cause the endpoint at 10.1.1.2 to initiate a connection to 348 port 54321 at 10.1.1.1, and the endpoint at 10.1.1.1 to initiate a 349 connection to port 54111 at 10.1.1.2. Whichever TCP connection 350 succeeds will be used. If both succeed, one of the connections may 351 be closed as an optimization, using the rules in section 2.3. 353 5 Security Considerations 355 See [SDP] for security and other considerations specific to the 356 Session Description Protocol in general. There are no new security 357 considerations introduced by these protocol identifiers and 358 attributes. 360 6 IANA Considerations 362 As recommended by [SDP] Appendix B, the direction attribute 363 described in this document should be registered with IANA, as should 364 the TCP, TLS, and SCTP protocol identifiers. 366 Acknowledgements 368 Yon INTERNET-DRAFT � Expires August 2001 7 369 The author would like to thank Jonathan Rosenberg, Anders 370 Kristensen, and Robert Fairlie-Cuninghame for their valuable 371 insights. 373 Yon INTERNET-DRAFT � Expires August 2001 8 374 Appendix A: Direction Attribute Syntax 376 This appendix provides an Augmented BNF [ABNF] grammar for 377 expressing the direction attribute for connection setup. It is 378 intended as an extension to the grammar for the Session Description 379 Protocol, as defined in [SDP]. Specifically, it describes the 380 syntax for the new "connection-setup" attribute field, which MAY be 381 either a session-level or media-level attribute. 383 connection-setup = "direction" ":" direction-spec 385 direction-spec = "passive" | qualified-direction 387 qualified-direction = direction-ident | direction-ident port 389 direction-ident = "both" | "active" 391 References 393 [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax 394 Specifications: ABNF," RFC 2234, November 1997 396 [SCTP] Stewart et al, "Stream Control Transmission Protocol," 397 RFC 2960, October 2000 399 [SDP] M. Handley, V. Jacobson, "SDP: Session Description 400 Protocol," RFC 2327, April 1998 402 [T38] International Telecommunication Union, "Procedures for 403 Real-Time Group 3 Facsimile Communications over IP 404 Networks," Recommendation T.38, June 1998 406 [TLS] T. Dierks, C. Allen, "The TLS Protocol," RFC 2246, 407 January 1999 409 [UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode 410 and ISO 10646," RFC 2044, October 1996 412 Author�s Address 414 David Yon 415 Dialout.Net, Inc. 416 402 Amherst St 417 Nashua, NH 03063 419 Phone: (603) 577-8708 420 EMail: yon@dialout.net 422 Full Copyright Statement 424 Copyright (C) The Internet Society (2001). All Rights Reserved. 426 Yon INTERNET-DRAFT � Expires August 2001 9 427 This document and translations of it may be copied and furnished to 428 others, and derivative works that comment on or otherwise explain it 429 or assist in its implementation may be prepared, copied, published 430 and distributed, in whole or in part, without restriction of any 431 kind, provided that the above copyright notice and this paragraph 432 are included on all such copies and derivative works. However, this 433 document itself may not be modified in any way, such as by removing 434 the copyright notice or references to the Internet Society or other 435 Internet organizations, except as needed for the purpose of 436 developing Internet standards in which case the procedures for 437 copyrights defined in the Internet Standards process must be 438 followed, or as required to translate it into languages other than 439 English. 441 The limited permissions granted above are perpetual and will not be 442 revoked by the Internet Society or its successors or assigns. 444 This document and the information contained herein is provided on an 445 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 446 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 447 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 448 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 449 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 451 Yon INTERNET-DRAFT � Expires August 2001 10