idnits 2.17.1 draft-ietf-mmusic-sdp-comedia-10.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.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 625. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 170 has weird spacing: '...passive act...' == Line 171 has weird spacing: '...actpass act...' == Line 172 has weird spacing: '...oldconn hold...' == Line 255 has weird spacing: '...xisting exis...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 26, 2004) is 7089 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) ** Obsolete normative reference: RFC 793 (ref. '1') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2048 (ref. '2') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '6') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '7') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '8') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC Working Group D. Yon 2 Internet-Draft Tactical Software, LLC 3 Expires: May 27, 2005 G. Camarillo 4 Ericsson 5 November 26, 2004 7 TCP-Based Media Transport in the Session Description Protocol (SDP) 8 draft-ietf-mmusic-sdp-comedia-10.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 27, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 This document describes how to express media transport over TCP using 44 the Session Description Protocol (SDP). It defines the SDP 'TCP' 45 protocol identifier, the SDP 'setup' attribute, which describes the 46 connection setup procedure, and the SDP 'connection' attribute, which 47 handles connection reestablishment. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 3 54 4. Setup Attribute . . . . . . . . . . . . . . . . . . . . . . . 4 55 4.1 The Setup Attribute in the Offer/answer Model . . . . . . 4 56 5. The Connection Attribute . . . . . . . . . . . . . . . . . . . 5 57 5.1 Offerer Behaviour . . . . . . . . . . . . . . . . . . . . 6 58 5.2 Answerer Behaviour . . . . . . . . . . . . . . . . . . . . 7 59 6. Connection Management . . . . . . . . . . . . . . . . . . . . 8 60 6.1 Connection Establishment . . . . . . . . . . . . . . . . . 8 61 6.2 Connection Reestablishment . . . . . . . . . . . . . . . . 8 62 6.3 Connection Termination . . . . . . . . . . . . . . . . . . 8 63 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7.1 Passive/Active . . . . . . . . . . . . . . . . . . . . . . 9 65 7.2 Actpass/Passive . . . . . . . . . . . . . . . . . . . . . 9 66 7.3 Existing Connection Reuse . . . . . . . . . . . . . . . . 10 67 7.4 Existing Connection Refusal . . . . . . . . . . . . . . . 10 68 8. Other Connection-Oriented Transport Protocols . . . . . . . . 11 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 71 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 74 12.2 Informative References . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 76 Intellectual Property and Copyright Statements . . . . . . . . 15 78 1. Introduction 80 The Session Description Protocol [4] provides a general-purpose 81 format for describing multimedia sessions in announcements or 82 invitations. SDP uses an entirely textual data format (the US-ASCII 83 subset of UTF-8 [11]) to maximize portability among transports. SDP 84 does not define a protocol, but only the syntax to describe a 85 multimedia session with sufficient information to participate in that 86 session. Session descriptions may be sent using arbitrary existing 87 application protocols for transport (e.g., SAP [9], SIP [10], RTSP 88 [6], email, HTTP [8], etc.). 90 SDP [4] defines two protocol identifiers: RTP/AVP and UDP, both of 91 which represent unreliable connectionless protocols. While these 92 transports are appropriate choices for multimedia streams, there are 93 applications for which TCP is more appropriate. This document 94 defines a new protocol identifier, 'TCP', to describe TCP connetions 95 in SDP. 97 TCP introduces two new factors when describing a session: how and 98 when should endpoints perform the TCP connection setup procedure. 99 This document defines two new attributes to describe TCP connection 100 setups: 'setup' and 'connection'. 102 2. Terminology 104 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 105 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 106 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 107 described in BCP 14, RFC 2119 [3] and indicate requirement levels for 108 compliant implementations. 110 3. Protocol Identifier 112 The following is the ABNF for an 'm' line, as specified by RFC 2327 113 [4]. 115 media-field = "m=" media space port ["/" integer] 116 space proto 1*(space fmt) CRLF 118 This document defines a new value for the proto field: 'TCP'. 120 The 'TCP' protocol identifier is similar to the 'UDP' protocol 121 identifier in that it only describes the transport protocol, and not 122 the upper-layer protocol. An 'm' line that specifies 'TCP' MUST 123 further qualify the application-layer protocol using an fmt 124 identifier. Media described using an 'm' line containing the 'TCP' 125 protocol identifier are carried using TCP [1]. 127 4. Setup Attribute 129 The 'setup' attribute indicates which of the end points should 130 initiate the TCP connection establishment (i.e., send the initial TCP 131 SYN). The 'setup' attribute is charset-independent and can be a 132 session-level or a media-level attribute. The following is the ABNF 133 of the 'setup' attribute: 135 setup-attr = "a=setup:" role 136 role = "active" / "passive" / "actpass" 137 / "holdconn" 139 'active': The endpoint will initiate an outgoing connection. 141 'passive': The endpoint will accept an incoming connection. 143 'actpass': The endpoint is willing to accept an incoming 144 connection or to initiate an outgoing connection. 146 'holdconn': The endpoint does not want the connection to be 147 established for the time being. 149 4.1 The Setup Attribute in the Offer/answer Model 151 The offer/answer model, defined in RFC 3264 [5], provides endpoints 152 with a means to obtain shared view of a session. Some session 153 parameters are negotiated (e.g., codecs to use), while others are 154 simply communicated from one endpoint to the other (e.g., IP 155 addresses). The value of the 'setup' attribute falls into the first 156 category. That is, both endpoints negotiate its value using the 157 offer/answer model. 159 The negotiation of the value of the 'setup' attribute takes places as 160 follows. The offerer states which role or roles it is willing to 161 perform and the answerer, taking the offerer's willingness into 162 consideration, chooses which roles both endpoints will actually 163 perform during connection establishment. The following are the 164 values that the 'setup' attribute can take in an offer/answer 165 exchange: 167 Offer Answer 168 ________________ 169 active passive / holdconn 170 passive active / holdconn 171 actpass active / passive / holdconn 172 holdconn holdconn 174 The active endpoint SHOULD initiate a connection to the port number 175 on the 'm' line of the other endpoint. The port number on its own 176 'm' line is irrelevant, and the opposite endpoint MUST NOT attempt to 177 initiate a connection to the port number specified there. 178 Nevertheless, since the 'm' line must contain a valid port number, 179 the endpoint specifying using the value active SHOULD specify a port 180 number of 9 (the discard port) on its 'm' line. The endpoint MUST 181 NOT specify a port number of zero, except to denote an 'm' line that 182 has been or is being refused. 184 The passive endpoint SHOULD be ready to accept a connection on the 185 port number specified in the 'm' line. 187 A value of 'actpass' indicates that the offerer can either initiate a 188 connection to the port number on the 'm' line in the answer or accept 189 a connection on the port number specified in the 'm' line in the 190 offer. That is, the offerer has no preference as to whether it 191 accepts or initiates the connection and, so, is letting the answerer 192 choose. 194 A value of 'holdconn' indicates that the connection should not be 195 established for the time being. 197 The default value of the setup attribute in an offer/answer exchange 198 is 'active' in the offer and 'passive' in the answer. 200 5. The Connection Attribute 202 The preceding description of the 'setup' attribute is placed in the 203 context of using SDP to initiate a session. Still, SDP may be 204 exchanged between endpoints at various stages of a session to 205 accomplish tasks such as terminating a session, redirecting media to 206 a new endpoint, or renegotiating the media parameters for a session. 207 After the initial session has been established, it may be ambiguous 208 as to whether subsequent SDP exchange represents a confirmation that 209 the endpoint is to continue using the current TCP connection 210 unchanged, or is a request to make a new TCP connection. The 211 media-level 'connection' attribute, which is charset-independent, is 212 used to disambiguate these two scenarios. The following is the ABNF 213 of the connection attribute: 215 connection-attr = "a=connection:" conn-value 216 conn-value = "new" / "existing" 218 5.1 Offerer Behaviour 220 Offerers and answerers use the 'connection' attribute to decide 221 whether a new transport connection needs to be established or, on the 222 other hand, the existing TCP connection should still be used. When 223 an offerer generates an 'm' line which uses TCP, it SHOULD provide a 224 connection attribute for the 'm' line unless the application using 225 the 'm' line has other means to deal with connection reestablishment. 227 After the initial offer/answer exchange, any of the endpoints can 228 generate a new offer to change some characteristics of the session 229 (e.g., the direction attribute). If such an offerer wants to 230 continue using the previously-established transport-layer connection 231 for the 'm' line, the offerer MUST use a connection value of 232 'existing' for the 'm' line. If, on the other hand, the offerer 233 wants to establish a new transport-layer connection for the 'm' line, 234 it MUST use a connection value of 'new'. 236 Note that, according to the rules in this section, an offer that 237 changes the transport address (IP address or port number) of an 238 'm' line will have a connection value of 'new'. The same way, the 239 'connection' attribute in an initial offer (i.e., no transport 240 connection has been established yet) takes the value of 'new'. 242 The 'connection' value resulting from an offer/answer exchange is the 243 'connection' value in the answer. If the 'connection' value in the 244 answer is 'new', the end-points SHOULD establish a new connection. 245 If the connection value in the answer is 'existing', the end-points 246 SHOULD continue using the exiting connection. 248 Taking into consideration the rules in Section 5.2, the following are 249 the values that the 'connetion' attribute can take in an offer/answer 250 exchange: 252 Offer Answer 253 ________________ 254 new new 255 existing existing / new 257 If the connection value resulting from an offer/answer exchange is 258 'existing', the end-points continue using the existing connection. 259 Consequently, the port numbers, IP addresses, and 'setup' attributes 260 negotiated in the offer/answer exchange are ignored because there is 261 no need to establish a new connection. 263 The previous rule implies that an offerer generating an offer with a 264 connection value of 'existing' and a setup value of 'passive' needs 265 to be ready (i.e., needs to allocate resources) to receive a 266 connection request from the answerer just in case the answerer 267 chooses a connection value of 'new' for the answer. However, if the 268 answerer uses a connection value of 'existing' in the answer, the 269 offerer would need to deallocate the previously allocated resources 270 which were never used because no connection request was received. 272 To avoid allocating resources unnecessary, offerers using a 273 connection value of 'existing' in their offers may choose to use a 274 setup value of 'holdconn'. Nevertheless, offerers using this 275 strategy should be aware that in the case the answerer chooses a 276 connection value of 'new', a new offer/answer exchange (typically 277 initiated by the previous offerer) with setup value different than 278 'holdconn' will be needed to establish the new connection. This may, 279 of course, cause delays in the application using the TCP connection. 281 The default value of the connection attribute in both offers and 282 answers is 'new'. 284 5.2 Answerer Behaviour 286 The connection value for an 'm' line is negotiated using the offer/ 287 answer model. The resulting connection value after an offer/answer 288 exchange is the connection value in the answer. If the connection 289 value in the offer is 'new', the answerer MUST also use a value of 290 'new' in the answer. If the connection value in the offer is 291 'existing', the answerer uses a value of 'existing' in the answer if 292 it wishes to continue using the existing connection and a value of 293 'new' if it wants a new connection to be established. 295 In some scenarios where third party call control [12] is used, an 296 endpoint may receive an initial offer with a connection value of 297 'existing'. Following the previous rules, such an answerer would 298 use a connection value of 'new' in the answer. 300 If the connection value for an 'm' line resulting from an offer/ 301 answer exchange is 'new', the endpoints SHOULD establish a new TCP 302 connection as indicated by the 'setup' attribute. If a previous TCP 303 connection is still up, the endpoints SHOULD close it as soon as the 304 offer/answer exchange is completed. It is up to the application to 305 ensure proper data synchornization between the two TCP connections. 307 If the connection value for an 'm' line resulting from an offer/ 308 answer exchange is 'existing', the endpoints SHOULD continue using 309 the existing TCP connection. 311 6. Connection Management 313 This section addresses connection establishment, connection 314 reestablishment, and connection termination. 316 6.1 Connection Establishment 318 An endpoint that according to an offer/answer exchange is supposed to 319 initiate a new TCP connection SHOULD initiate it as soon as it is 320 able to, even if the endpoint does not intend to immediately begin 321 sending media to the remote endpoint. This allows media to flow from 322 the remote endpoint if needed. 324 Note that some endpoints need to wait for some event to happen 325 before being able to establish the connection. For example, a 326 wireless terminal may need to set up a radio bearer before being 327 able to initiate a TCP connection. 329 6.2 Connection Reestablishment 331 If an endpoint determines that the TCP for an 'm' line has been 332 closed and it should be reestablished, it SHOULD perform a new offer/ 333 answer exchange using a connection value of 'new' for this 'm' line. 335 Note that the SDP direction attribute (e.g., 'a=sendonly') deals 336 with the media sent over the TCP connection, but has no impact on 337 the TCP connection itself. 339 6.3 Connection Termination 341 Typically, endpoints do not close the TCP connection until the 342 session has expired, been explicitly terminated, or a new connection 343 value has been provided for the 'm' line. Additionaly, specific 344 applications can describe further scenarios where an end-point may 345 close a given TCP connection (e.g., whenever a connection is in the 346 half-close state). As soon as an end-point notices that it needs to 347 terminate a TCP connection, it SHOULD do so. 349 In any case, individual applications may provide further 350 considerations on how to achieve a graceful connection termination. 351 For example, a file application using TCP receiving a FIN from the 352 remote endpoint may need to finish the ongoing transmission of a file 353 before sending its own FIN. 355 7. Examples 357 The following examples show the most common usage of the 'setup' 358 attribute combined with TCP-based media descriptions. For the 359 purpose of brevity, the main portion of the session description is 360 omitted in the examples, which only show 'm' lines and their 361 attributes (including 'c' lines). 363 7.1 Passive/Active 365 An offerer at 192.0.2.2 signals its availability for a T.38 fax 366 session at port 54111: 368 m=image 54111 TCP t38 369 c=IN IP4 192.0.2.2 370 a=setup:passive 371 a=connection:new 373 An answerer at 192.0.2.1 receiving this offer responds with the 374 following answer: 376 m=image 9 TCP t38 377 c=IN IP4 192.0.2.1 378 a=setup:active 379 a=connection:new 381 The endpoint at 192.0.2.1 then initiates the TCP connection to port 382 54111 at 192.0.2.2. 384 7.2 Actpass/Passive 386 In another example, an offerer at 192.0.2.2 signals its availability 387 for a T.38 fax session at TCP port 54111. Additionally, this offerer 388 is also willing to set up the media stream by initiating the TCP 389 connection: 391 m=image 54111 TCP t38 392 c=IN IP4 192.0.2.2 393 a=setup:actpass 394 a=connection:new 396 The endpoint at 192.0.2.1 responds with the following description: 398 m=image 54321 TCP t38 399 c=IN IP4 192.0.2.1 400 a=setup:passive 401 a=connection:new 403 This will cause the offerer (at 192.0.2.2) to initiate a connection 404 to port 54321 at 192.0.2.1. 406 7.3 Existing Connection Reuse 408 Subsequent to the exchange in Section 7.2, another offer/answer 409 exchange is initiated in the opposite direction. The endpoint at 410 192.0.2.1 wishes to continue using the existing connection: 412 m=image 54321 TCP t38 413 c=IN IP4 192.0.2.1 414 a=setup:passive 415 a=connection:existing 417 The endpoint at 192.0.2.2 also wishes to use the existing connection 418 and responds with the following description: 420 m=image 9 TCP t38 421 c=IN IP4 192.0.2.2 422 a=setup:active 423 a=connection:existing 425 The existing connection from 192.0.2.2 to 192.0.2.1 will be reused. 427 Note that the endpoint at 192.0.2.2 uses 'setup:active' in 428 response to the offer of 'setup:passive', and uses port 9 because 429 it is active. 431 7.4 Existing Connection Refusal 433 Subsequent to the exchange in Section 7.3, another offer/answer 434 exchange is initiated by the endpoint at 192.0.2.2, again wishing to 435 reuse the existing connection: 437 m=image 54111 TCP t38 438 c=IN IP4 192.0.2.2 439 a=setup:passive 440 a=connection:existing 442 However, this time the answerer is unaware of the old connection and 443 so wishes to establish a new one. (This could be the result of a 444 transfer via third-party call control.) It is unable to act in the 445 'passive' mode so responds as 'active': 447 m=image 9 TCP t38 448 c=IN IP4 192.0.2.3 449 a=setup:active 450 a=connection:new 452 The endpoint at 192.0.2.3 then initiates the TCP connection to port 453 54111 at 192.0.2.2, and the endpoint at 192.0.2.2 closes the old 454 connection. 456 Note that the endpoint at 192.0.2.2, while using a connection 457 value of 'existing' has used a setup value of 'passive'. Had it 458 not done this and used a setup value of 'holdconn' instead 459 (probably to avoid allocating resources as described in Section 460 5.1), a new offer/answer exchange would have been needed in order 461 to establish the new connection. 463 8. Other Connection-Oriented Transport Protocols 465 This document specifies how to describe TCP-based media streams using 466 SDP. Still, some of the attributes defined here could possibly be 467 used to describe media streams based on other connection-oriented 468 transport protocols as well. This section provides advice to authors 469 of specifications of SDP extensions which deal with 470 connetion-oriented transport protocols other than TCP. 472 It is recommended that documents defining new SDP protocol 473 identifiers that involve extra protocol layers between TCP and the 474 media itself (e.g., TLS [7] over TCP) start with the string 'TCP/' 475 (e.g., 'TCP/TLS'). 477 The 'setup' and the 'connection' attributes are specified in Section 478 4 and Section 5 respectively. While both attributes are applicable 479 to 'm' lines that use the 'TCP' protocol identifier, they are general 480 enough to be reused in 'm' lines with other connection-oriented 481 transport protocols. Therefore, it is recommended that the 'setup' 482 and 'connection' attributes are reused, as long as it is possible, 483 for new proto values associated with connection-oriented transport 484 protocols. 486 Section 6 deals with TCP connection management. It should be noted 487 that while in TCP both end-points need to close a connection, other 488 connection-oriented transport protocols may not have the concept of 489 half-close connections. In such a case, a connection would be 490 terminated as soon as one of the end-points closed it, making it 491 unnecessary for the other end-point to perform any further action to 492 terminate the connection. So, specifications dealing with such 493 transport protocols may need to specify slightly different procedures 494 regarding connection termination. 496 9. Security Considerations 498 See RFC 2327 [4] for security and other considerations specific to 499 the Session Description Protocol in general. 501 An attacker may attempt to modify the values of the connection and 502 setup attributes to have endpoints reestablish connections 503 unnecesaryly or to keep them from establishing a connection. So, it 504 is strongly RECOMMENDED that integrity protection be applied to the 505 SDP session descriptions. For session descriptions carried in SIP 506 [10], S/MIME is the natural choice to provide such end-to-end 507 integrity protection, as described in RFC 3261 [10]. Other 508 applications MAY use a different form of integrity protection. 510 10. IANA Considerations 512 This document defines two session and media level SDP attributes: 513 setup and connection. Their formats are defined in Section 4 and 514 Section 5 respectively. These two attributes should be registered by 515 the IANA under "Session Description Protocol (SDP) Parameters" under 516 "att-field (both session and media level)". 518 This document defines a proto value: TCP. Its format is defined in 519 Section 3. This proto value should be registered by the IANA under 520 "Session Description Protocol (SDP) Parameters" under "proto". 522 The SDP specification, RFC2327, states that specifications defining 523 new proto values, like the TCP proto value defined in this RFC, must 524 define the rules by which their media format (fmt) namespace is 525 managed. For the TCP protocol, new formats SHOULD have an associated 526 MIME registration. Use of an existing MIME subtype for the format is 527 encouraged. If no MIME subtype exists, it is RECOMMENDED that a 528 suitable one is registered through the IETF process [2] by production 529 of, or reference to, a standards-track RFC that defines the transport 530 protocol for the format. 532 11. Acknowledgements 534 Jonathan Rosenberg, Rohan Mahy, Anders Kristensen, Joerg Ott, Paul 535 Kyzivat, Robert Fairlie-Cuninghame, Colin Perkins, and Christer 536 Holmberg provided valuable insights and contributions. 538 12. References 540 12.1 Normative References 542 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 543 September 1981. 545 [2] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet 546 Mail Extensions (MIME) Part Four: Registration Procedures", BCP 547 13, RFC 2048, November 1996. 549 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 550 Levels", BCP 14, RFC 2119, March 1997. 552 [4] Handley, M. and V. Jacobson, "SDP: Session Description 553 Protocol", RFC 2327, April 1998. 555 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 556 Session Description Protocol (SDP)", RFC 3264, June 2002. 558 12.2 Informative References 560 [6] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 561 Protocol (RTSP)", RFC 2326, April 1998. 563 [7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 564 2246, January 1999. 566 [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 567 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 568 HTTP/1.1", RFC 2616, June 1999. 570 [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 571 Protocol", RFC 2974, October 2000. 573 [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 574 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 575 Session Initiation Protocol", RFC 3261, June 2002. 577 [11] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 578 63, RFC 3629, November 2003. 580 [12] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, 581 "Best Current Practices for Third Party Call Control (3pcc) in 582 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 583 2004. 585 Authors' Addresses 587 David Yon 588 Tactical Software, LLC 589 670 N Commercial St 590 Manchester, NH 03101 591 USA 593 EMail: yon-comedia@rfdsoftware.com 595 Gonzalo Camarillo 596 Ericsson 597 Hirsalantie 11 598 Jorvas 02420 599 Finland 601 EMail: Gonzalo.Camarillo@ericsson.com 603 Intellectual Property Statement 605 The IETF takes no position regarding the validity or scope of any 606 Intellectual Property Rights or other rights that might be claimed to 607 pertain to the implementation or use of the technology described in 608 this document or the extent to which any license under such rights 609 might or might not be available; nor does it represent that it has 610 made any independent effort to identify any such rights. Information 611 on the procedures with respect to rights in RFC documents can be 612 found in BCP 78 and BCP 79. 614 Copies of IPR disclosures made to the IETF Secretariat and any 615 assurances of licenses to be made available, or the result of an 616 attempt made to obtain a general license or permission for the use of 617 such proprietary rights by implementers or users of this 618 specification can be obtained from the IETF on-line IPR repository at 619 http://www.ietf.org/ipr. 621 The IETF invites any interested party to bring to its attention any 622 copyrights, patents or patent applications, or other proprietary 623 rights that may cover technology that may be required to implement 624 this standard. Please address the information to the IETF at 625 ietf-ipr@ietf.org. 627 Disclaimer of Validity 629 This document and the information contained herein are provided on an 630 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 631 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 632 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 633 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 634 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 635 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 637 Copyright Statement 639 Copyright (C) The Internet Society (2004). This document is subject 640 to the rights, licenses and restrictions contained in BCP 78, and 641 except as set forth therein, the authors retain all their rights. 643 Acknowledgment 645 Funding for the RFC Editor function is currently provided by the 646 Internet Society.