idnits 2.17.1 draft-peterson-rosenberg-avt-rtp-ssrc-demux-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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 583. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 599), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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. ** 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: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 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 (July 12, 2004) is 7227 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: '3' is defined on line 503, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 535, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-01 ** Obsolete normative reference: RFC 3489 (ref. '5') (Obsoleted by RFC 5389) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-18 == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-06 == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-04 -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '11') (Obsoleted by RFC 4566) Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AVT WG J. Peterson 2 Internet-Draft NeuStar 3 Expires: January 10, 2005 J. Rosenberg 4 dynamicsoft 5 July 12, 2004 7 A Multiplexing Mechanism for the Real-Time Protocol (RTP) 8 draft-peterson-rosenberg-avt-rtp-ssrc-demux-00 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 10, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document defines a mechanism for the Real-Time Protocol (RTP) 42 that allows multiple RTP sessions to be demultiplexed at a single 43 port. Accordingly, it also requests that the IANA allocate assigned 44 ports for the use of RTP with three applications: voice, video and 45 text. A similar mechanism is proposed for the Real-Time Control 46 Protocol (RTCP). The use of this mechanism is confined to a strict 47 domain of applicability. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Multiple Ports vs. Single Port Multiplexing . . . . . . . . . 4 53 3. Applicability of this Mechanism . . . . . . . . . . . . . . . 5 54 4. RTP and SSRC Multiplexing . . . . . . . . . . . . . . . . . . 7 55 5. Negotiating Usage in SDP . . . . . . . . . . . . . . . . . . . 8 56 5.1 Specifying a Port in SDP . . . . . . . . . . . . . . . . . 9 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 59 7.1 Registration for SDP Attributes . . . . . . . . . . . . . 11 60 7.2 Registration for SIP option-tag . . . . . . . . . . . . . 11 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 63 8.2 Informative References . . . . . . . . . . . . . . . . . . . 12 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 65 Intellectual Property and Copyright Statements . . . . . . . . 14 67 1. Introduction 69 The Real-Time Protocol (RTP) specification (RFC 3550) [1]) Section 3 70 notes that "RTP depends upon the lower-layer protocol to provide some 71 mechanism such as ports to multiplex the RTP and RTCP packets of a 72 session." As such, there is no standard port over which RTP traffic 73 flows; ephemeral ports are generally selected for RTP connections. 74 While this simplifies the implementation of RTP as a protocol, it 75 also gives rise to problems for applications that use RTP. Notably, 76 it interferes with the operation of Network Address Translators 77 (NATs, [8]). It also makes it hard for firewall administrators to 78 implement layer-4 policies for RTP, since the ports over which RTP 79 travels cannot be anticipated. 81 As such, this document proposes a mechanism for RTP that would allow 82 multiple RTP sessions to be multiplexed at a single transport-layer 83 port. A given host might instruct several peers, for example, to all 84 send media (using this extension) to the same transport address on 85 that host. This mechanism leverages the synchronization source 86 (SSRC) parameter of the RTP header to multiplex and demultiplex 87 discrete RTP sessions that are sent to the same IP address and port. 89 Multiplexing RTP for this purpose would yield little benefit if the 90 Real-Time Control Protocol (RTCP) did not admit of a similar 91 multiplexing scheme. Today, an RTCP session is paired with an RTP 92 session (typically, though not always, RTCP runs on a port one port 93 higher than RTP). This proposal continues to manage RTP and RTCP on 94 separate ports, but only one port will be required for RTCP. 96 RTP today is used to carry data associated with a number of common 97 media types. These include real-time voice, video and text traffic. 98 Since it desirable for firewall administrators to be able to 99 implement policies that allow or disallow particular media types, 100 this document requests that the IANA allocate separate standard RTP 101 ports for each of the three common media types. The 'rtp-voice' port 102 would also serve as a default port for all other media types, though 103 if in the future other media types for RTP become popular, they might 104 also warrant new media types. 106 The motivations for the existing RTP lower-layer multiplexing 107 decision are analyzed in Section 2, and current RTP operation is 108 compared with the use of the proposed extension. The use of the SSRC 109 to multiplex traffic is described in Section 4, and the problems with 110 sending multiple RTP sessions to the same transport address described 111 in Section 5.2 of RFC3550 are also examined. The use of this 112 mechanism is confined to the domain of applicability described in 113 Section 3, which provides a high-layer scheme for negotiating support 114 of this mechanism and reverting back to standard RTP if it is 115 unsupported. 117 2. Multiple Ports vs. Single Port Multiplexing 119 RTP runs over an existing transport protocol, such as UDP or DCCP 120 [7]. All transport protocols by definition carry a port number - 121 port numbers differentiate services or applications that are using a 122 single Internet address on a device. Therefore, during the design of 123 RTP, a decision was made that providing an indicator for handling 124 multiplexing within RTP would be undesirable because the transport 125 protocol under RTP already necessarily supports multiplexing through 126 multiple ports - adding capability for multiplexing within RTP would 127 be redundant. 129 Accordingly, selection of a port for RTP is deferred to the 130 application layer. Applications typically bind to a random available 131 port to listen for RTP, and then inform their peers (through an 132 out-of-band protocol like the Session Description Protocol (SDP [6]) 133 the port to which media should be sent. However, carriage of RTP 134 over multiple ports has created a number of obstacles to the 135 widespread deployment of RTP. The most infamous of these is the 136 interaction with firewalls and Network Address Translators (NATs). 138 Typically, firewall administrators are reluctant to allow traffic on 139 arbitrary ports to enter (and in some cases exit) their network. 140 However, in order to allow the random ports selected by RTP, firewall 141 administrators have little recourse. If RTP (and RTCP) ran over 142 well-known assigned ports, firewall administrators could make a 143 trivial decision to allow traffic over such ports into their network. 145 NAT traversal presents an even more troublesome obstacle, since its 146 impacts on RTP traffic are not necessarily side-effects of policy 147 enforcement, but are innate in the deployment of many enterprises and 148 residential networks. Since NATs are fielded in order to conserve 149 IPv4 address resources by allowing multiple hosts to share a single 150 IP address, many users that would like to connect an IP telephone to 151 their existing residential network discover only inadvertently that 152 their NAT blocks RTP traffic. 154 In the absence of a single RTP port, a whole cottage industry of 155 standard and proprietary protocols and devices have emerged that 156 facilitate RTP's traversal through firewalls and NATs. The MIDCOM 157 and NSIS protocols, ICE [4] and its components (STUN [5] and TURN 158 [9]) are IETF standards that have been developed for this purpose. 159 Specifying a standard-port variant of RTP will not obviate the need 160 for mechanisms like ICE, but it does significantly simplify 161 authorized firewall traversal (essentially eliminating the need for 162 special-purpose ALGs or firewall controllers designed to permit VoIP 163 while maintaining network security), and it helps with some limited 164 NAT cases. 166 Given this problem space, there seems to be ample motivation for a 167 way of consolidating all RTP traffic for a single IP address down to 168 a single port that can easily be managed by middlebox administrators. 170 Section 5.2 of RFC3550 anticipates that applications designers might 171 want to multiplex several RTP streams over the same port, and 172 normatively recommends against this practice. Five major points are 173 raised against multiplexing in that section. The first three of 174 these points, as RFC3550 notes, do not effect mechanisms that use the 175 synchronization source (SSRC) for multiplexing. Of the remaining 176 two, point 4 notes that an RTP mixer would not be able to combine 177 streams of incompatible media into a single stream; however, since 178 the mechanism presented in this document still uses different ports 179 for different media types, this is not immediately applicable here. 180 Similarly, point 5 establishes more problems with sending different 181 varieties of media over the same port, and also notes that 182 establishing different network paths or resource allocations for 183 different sessions is rendered impossible. This last point is valid 184 in networks where certain quality of service (QoS) mechanisms are 185 used. In order for these mechanisms to work with a standard-port 186 variant of RTP, resource allocation for RTP would need to evolve into 187 a form similar to that used for TCP, where a 5-tuple is used to 188 identify network resources rather than just the pairs of network 189 addresses and ports. While this presents hurdles for the deployment 190 of such QoS mechanisms with standard-port RTP, they are not 191 insurmountable hurdles. On balance, the trade-off seems to favor the 192 specification of standard-port RTP. 194 3. Applicability of this Mechanism 196 If the mechanism proposed in this document is employed, but 197 understood by only one of the parties in an RTP session, the 198 consequences for the protocol could be very negative (i.e. in all 199 likelihood, RTP would not function properly). In order to prevent 200 this eventuality, implementations MUST NOT use this mechanism without 201 a higher-layer negotiation mechanism that allows implementations to 202 back off to traditional (unmodified) RTP. 204 Specifically, implementations of this session MUST negotiate the use 205 of the extension via SDP. Furthermore, implementations that use the 206 Session Initiation Protocol (SIP [2]) to carry such SDP MUST supply a 207 Require header field value with the 'sp-rtp' option-tag defined in 208 Section 5. 210 This mechanism is of primary value for traversing firewalls, in 211 keeping with the policies of firewall administrators, in the absence 212 of Network Address Translators. When NATs are used, the 213 applicability of this mechanism is more limited. The following 214 scenarios are appropriate for use with standard-port RTP: 215 If a single RTP implementation is behind a NAT, then the 216 administrator of the NAT can use a simple packet-forwarding rule 217 to forward all packets directed to standard RTP ports to the IP 218 address of the RTP implementation. This could be useful in some 219 residential deployments, for example. 220 If multiple RTP implementations are behind a NAT, then there must 221 be a single host which acts as a media relay for that network, 222 effectively demultiplexing and reflecting traffic to the RTP 223 implementations as appropriate. TURN servers could readily be 224 adapted to this purpose, and furthermore, many enterprises 225 effectively have such relays already, in the form of IP PBXs and 226 various sorts of devices that manage call centers. 228 However, even in these instances, this mechanism does not interact 229 well with the usage of STUN as a means for obtaining an IP address 230 and port to signal as the media destination. The problem is that the 231 NAT will modify the source port of the outbound STUN request, and the 232 source port it selected depends on the algorithms it implements, 233 along with the state of the NAT itself. As a result, a client is 234 likely to get back an IP address and a random port. This random port 235 will not match any of the default ports for RTP traffic. This will 236 make it impossible for the client to receive RTP traffic on the 237 default ports. 239 This problem is mitigated somewhat by NATs that provide a port 240 preservation property. Port preservation is defined as a property 241 whereby a NAT tries to preserve the source port in the outgoing 242 packet. However, even in NATs that provide port preservation, there 243 is a possibility that the port is already in use for another binding. 244 In such a case, the NAT is forced to allocate a different port to the 245 client. Thus, if a client sends its STUN messages from the default 246 RTP port, port preservation makes it possible that the STUN results 247 will indicate the same port, but there is no guarantee. 249 Eventually, as NAT's become less transparent and more controllable, 250 using techniques like MIDCOM and NSIS, a client could explicitly ask 251 for a binding to the necessary RTP port. 253 Fortunately, the mechanism described here is very compatible with 254 ICE. ICE is based on the idea that a client might be able to receive 255 RTP traffic at a multiplicity of IP addresses and ports. The default 256 RTP port just becomes one other possibility, and ICE's peer-to-peer 257 connectivity checks would be used to verify that RTP traffic could 258 flow to the default RTP port. 260 Indeed, ICE provides a good transition mechanism to aid in the 261 gradual adoption of the approach described here. ICE can be 262 configured to prefer RTP traffic that connects to the default port, 263 but would allow it to work to other ports when the default doesn't 264 work (as in the STUN case above). As the STUN cases reduce in 265 frequency (with the advent of more controllable devices and/or the 266 usage of TURN servers when multiple clients behind a NAT require RTP 267 services), ICE will discover, more and more frequently, that the 268 default RTP port works. 270 As this work progresses, it is expected that further work will be 271 done on the interaction between standard-port RTP, STUN, TURN and 272 ICE. 274 An additional limitation of this mechanism is that the usage of RTP 275 by multiple applications on a single host can be problematic, given 276 common RTP implementations today. Any application that binds to an 277 assigned port for RTP becomes the only application that can receive 278 such RTP packets on a host. However, the authors believe that there 279 are enough devices (like Internet telephones) that would only host a 280 single RTP application that this extension would still have 281 significant applicability without changes to existing RTP 282 implementations. In environments where multiple applications would 283 like to use RTP on a single host, RTP implementations would need to 284 provide system-wide services. 286 The applicability of this mechanism to multicast scenarios is a 287 subject for further study. The intended use of this mechanism is in 288 unicast scenarios, most likely those RTP sessions associated with the 289 Session Initiation Protocol (SIP). 291 4. RTP and SSRC Multiplexing 293 SSRC multiplexing does not require any extension to RTP. It reuses 294 the 32-bit synchronization source (SSRC) header, which already exists 295 in RFC3550, to differentiate discrete streams originating from a 296 single source. 298 The most obvious change to RTP behavior prescribed by this draft is 299 that RTP server applications would no longer bind to ephemeral ports, 300 but rather to one or more standard ports for various media types, 301 depending on the capabilities and needs of the application. RTP 302 implementations would also be required the multiplex and demultiplex 303 traffic according to the SSRC, and render the results appropriately 304 to higher level applications. This requires changes to existing RTP 305 APIs. 307 RFC3550 states that the SSRC is created randomly and unilaterally, 308 and that it must be globally unique within a particular RTP session 309 (which is especially meaningful in ad-hoc conferences, or when 310 multiple source devices are used to provide media for a single 311 participant). In order to use the mechanism described in this 312 document, the SSRC is negotiated collaboratively with other 313 participants in a session using a higher-layer protocol like the 314 Session Description Protocol (SDP). More information about 315 negotiating the SSRC in SDP and SIP is given in Section 5. Without 316 this higher-layer negotiation, this mechanism MUST NOT be used. 317 Additionally, the SSRC negotiated by an RTP application MUST be 318 unique across all RTP sessions on the host (or more specifically, 319 associated with the same network address), rather than merely unique 320 across participants in a particular RTP session. 322 RTCP also uses the SSRC parameter. Like RTP, RTCP server 323 applications would bind to standard ports rather than ephemeral 324 ports, and similar multiplexing/demultiplexing operations are 325 required to associate RTCP traffic with the proper multiplexed 326 session. 328 5. Negotiating Usage in SDP 330 The use of this mechanism with the Session Description Protocol (SDP) 331 requires the addition of new attributes to SDP that communicate the 332 values of the SSRC when using the offer/answer model (described in 333 RFC3263). It also eliminates the need for RTP port selection in SDP. 335 Thus, this mechanism defines two new attributes (a= lines) that can 336 appear in SDP: 'ssrc-upper' and 'ssrc-lower'. Each of these 337 attributes offers 16 bits of the SSRC that will be received by each 338 participant in a RTP session. When an SDP offer is made, the offerer 339 specifies the upper 16 bits of the SSRC in RTP that they will receive 340 in the 'ssrc-upper' parameter, and specifies the lower 16 bits of the 341 SSRC that the answerer will receive in the 'ssrc-lower' parameter. 342 When the SDP answer is formulated, the answerer again specifies the 343 upper 16 bits of the SSRC that they will receive in the 'ssrc-upper' 344 parameter, and specifies the lower bits of the SSRC that the offerer 345 will receive in the 'ssrc-lower' parameter. In both cases the 346 generation of these bits MUST be random (following the guidance given 347 in RFC3550 Appendix A) and MUST be unique across all RTP sessions 348 supported by the host. 350 So, for example, in an offer: 352 a:ssrc-upper=0x6f12 353 a:ssrc-lower=0xaa9f 354 and in the answer: 356 a:ssrc-upper=0x8b3b 357 a:ssrc-lower=0x110c 359 In this example, the RTP from the offerer to the answerer would have 360 SSRC 0x8b3baa9f, and the SSRC from the answerer to offerer would be 361 0x6f12110c. 363 The primary motivation for this collaborative agreement on SSRCs is 364 to allow this mechanism to work with cases where SIP forking has 365 occurred. Without this collaboration on SSRC, it would be difficult 366 to distinguish media coming from different SIP user agents that were 367 reached by an offer. 369 Note that this mechanism does not eliminate the potential for 370 collisions in SSRC selection described in RFC3550 Section 8.1. In 371 fact, since each party to an offer/answer in a SIP forking case 372 specifies only 16 bits of their SSRC, the potential for collisions 373 may be higher. However, given a reasonable amount of randomness, the 374 odds of a collision remain very low, and SDP could conceivably be 375 used to renegotiate the SSRC in case of a collision. 377 5.1 Specifying a Port in SDP 379 The presence of the 'ssrc-upper' and 'ssrc-lower' attributes in an 380 SDP offer signals that this use of this mechanism is desired. SDP 381 answerers MUST NOT supply 'ssrc-upper' and 'ssrc-lower' attributes in 382 an SDP answer if they were not present in the offer; if the answerer 383 requires the use of this extension, they SHOULD refuse the initial 384 offer and formulate an appropriate counteroffer. 386 SDP attributes that are not understood are ignored. Consequently, if 387 an SDP offer containing 'ssrc-upper' and 'ssrc-lower' is answered 388 with an SDP that does not contain these attributes, the offerer can 389 determine that this extension is unsupported. However, this would 390 not prevent the answerer from sending RTP media based on its 391 understanding of the offer, which could have undesirable 392 consequences, especially in SIP cases where the SDP offer is forked 393 to multiple endpoints. 395 When SIP INVITEs are used to carry SDP that contains the 'ssrc-upper' 396 and 'ssrc-lower' attributes, those messages MUST have a SIP Require 397 header field value containing the option-tag 'sp-rtp'. If this 398 option is unsupported by recipients of such SIP request, a suitable 399 SIP error code will be sent in the backwards direction, and the 400 parties may subsequently attempt to renegotiate a session without 401 supporting this mechanism. 403 SDP offers and answers use a field of the m= line to specify the port 404 to which media should be sent. In the context of this mechanism, 405 since standard port numbers are used, there is no need to signal a 406 media port in the m= line. Moreover, it is undesirable, when this 407 extension is used, to allow a port number to be specified (since this 408 would allow applications potentially to use the voice port for video 409 media, and the like). Therefore, the 'port' value of the m= line of 410 SDP using this mechanism MUST be set to 99999. This is an invalid 411 UDP port, and thus implementations which do not support this 412 mechanism will be unable to send or receive media at this port. 413 Implementations that support this mechanism MUST ignore the value 414 99999 in the port field of the m= line, and instead use the media 415 value of the m= line to determine the port to which they will send 416 media. 418 In particular, if the media value of the m= line is 'audio', the port 419 to which media will be sent MUST be the standard 'rtp-audio' port; 420 similarly, 'video' MUST use the 'rtp-video' port, and 'text' MUST use 421 the 'rtp-text' port. All other media values default to the 422 'rtp-audio' port, unless otherwise specified in a standards-track RFC 423 that extends this specification. The IANA will assign port numbers 424 for these ports as per the instructions in Section 7. 426 6. Security Considerations 428 If the mechanism described in this document is used by RTP 429 applications, firewall administrators will gain the ability to create 430 firewall policies to control admission of RTP to their networks with 431 a simple transport-layer filter. Like any other port-based policy, 432 however, it is not a perfect instrument of security. Mischievous 433 users have been known to send traffic over well-known ports (such as 434 port 80) that is not appropriate for the IANA-registered application 435 of that port. So while this document specifies, for example, 436 separate RTP ports for voice and video, there is nothing that 437 prevents a misbehaving application from accidentally or intentionally 438 sending RTP video over the RTP voice port, and so on. For more 439 information on the limitations of port-based security policies, see 440 [10]. 442 That much said, this approach does increase the firewall-friendliness 443 of RTP significantly. In order to support an RTP implementation 444 based entirely on ephemeral ports, firewall administrator today would 445 have to open vast ranges of ephemeral ports to any applicable UDP 446 traffic. If the mechanism described in this draft were widely 447 deployed, firewall administrators would need to open only a handful 448 of ports in order to allow RTP traffic. Since in many environments, 449 network administrators might have to remove firewalls in order to 450 allow VoIP services on ephemeral ports, this mechanism improves the 451 security of deployments. 453 The best known practice for securing RTP is sRTP. Implementers 454 should strongly consider the use of sRTP to authenticate the source 455 of a media stream. The behavior suggested in this draft for 456 constructing SSRCs is not a substitute for cryptographic 457 authentication of a media source. The effects of this mechanism on 458 sRTP are a subject for further study. 460 7. IANA Considerations 462 This document requests that the IANA allocate three standard ports 463 associated with RTP media types: one port for 'rtp-audio', one or 464 'rtp-video', and one for 'rtp-text.' This document also requests that 465 the IANA allocate three standard ports for RTCP, one associated with 466 each of the RTP ports described above: 'rtcp-audio, 'rtcp-video' and 467 'rtcp-text'. Further, this document requests that the assignment 468 ports be ascending, and in the following order: rtp-audio, 469 rtcp-audio, rtp-video, rtcp-video, rtp-text, rtcp-text. The first 470 assigned port number must be an even number. 472 Future standards-track specifications may request the assignment of 473 additional ports that will be used by this mechanism. Such 474 specifications MUST identify ports corresponding to the top-level 475 media values that appear in the m= line of SDP. 477 7.1 Registration for SDP Attributes 479 This document requests that the IANA allocate two new media-level 480 attributes for SDP: 'ssrc-upper' and 'ssrc-lower'. 482 [Ed Note: The formal registrations TBD] 484 7.2 Registration for SIP option-tag 486 This document requests that the IANA allocate a new option-tag for 487 SIP: 'sp-rtp'. 489 [Ed Note: The formal registrations TBD] 491 8. References 493 8.1 Normative References 495 [1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 496 "RTP: A Transport Protocol for Real-Time Applications", RFC 497 3261, May 2002. 499 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 500 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 501 Session Initiation Protocol", RFC 3550, July 2003. 503 [3] Bradner, S., "Key words for use in RFCs to indicate requirement 504 levels", RFC 2119, March 1997. 506 [4] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 507 Methodology for Network Address Translator (NAT) Traversal for 508 Multimedia Session Establishment Protocols", 509 draft-ietf-mmusic-ice-01 (work in progress), February 2004. 511 [5] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 512 Simple Traversal of User Datagram Protocol (UDP) Through Network 513 Address Translators (NATs)", RFC 3489, March 2003. 515 [6] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session 516 Description Protocol", draft-ietf-mmusic-sdp-new-18 (work in 517 progress), June 2004. 519 [7] Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion 520 Control Protocol (DCCP)", draft-ietf-dccp-spec-06 (work in 521 progress), February 2004. 523 8.2 Informative References 525 [8] Senie, D., "Network Address Translator (NAT)-Friendly 526 Application Design Guidelines", RFC 3235, January 2002. 528 [9] Rosenberg, J., Huitema, C. and R. Mahy, "Traversal Using Relay 529 NAT (TURN)", draft-rosenberg-midcom-turn-04 (work in progress), 530 February 2004. 532 [10] St. Johns, M. and G. Huston, "Considerations on the use of a 533 Service Identifier in Packet Headers", RFC 3639, October 2003. 535 [11] Handley, M. and V. Jacobson, "SDP: Session Description 536 Protocol", RFC 2327, April 1998. 538 Authors' Addresses 540 Jon Peterson 541 NeuStar, Inc. 542 1800 Sutter St 543 Suite 570 544 Concord, CA 94520 545 US 547 Phone: +1 925/363-8720 548 EMail: jon.peterson@neustar.biz 549 URI: http://www.neustar.biz/ 551 Jonathan Rosenberg 552 dynamicsoft 553 600 Lanidex Plaza 554 Parsippany, NJ 07054-2711 555 US 557 Phone: +1 973/952-5050 558 EMail: jdrosen@dynamicsoft.com 559 URI: http://www.dynamicsoft.com/ 561 Intellectual Property Statement 563 The IETF takes no position regarding the validity or scope of any 564 Intellectual Property Rights or other rights that might be claimed to 565 pertain to the implementation or use of the technology described in 566 this document or the extent to which any license under such rights 567 might or might not be available; nor does it represent that it has 568 made any independent effort to identify any such rights. Information 569 on the procedures with respect to rights in RFC documents can be 570 found in BCP 78 and BCP 79. 572 Copies of IPR disclosures made to the IETF Secretariat and any 573 assurances of licenses to be made available, or the result of an 574 attempt made to obtain a general license or permission for the use of 575 such proprietary rights by implementers or users of this 576 specification can be obtained from the IETF on-line IPR repository at 577 http://www.ietf.org/ipr. 579 The IETF invites any interested party to bring to its attention any 580 copyrights, patents or patent applications, or other proprietary 581 rights that may cover technology that may be required to implement 582 this standard. Please address the information to the IETF at 583 ietf-ipr@ietf.org. 585 Disclaimer of Validity 587 This document and the information contained herein are provided on an 588 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 589 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 590 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 591 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 592 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 593 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 595 Copyright Statement 597 Copyright (C) The Internet Society (2004). This document is subject 598 to the rights, licenses and restrictions contained in BCP 78, and 599 except as set forth therein, the authors retain all their rights. 601 Acknowledgment 603 Funding for the RFC Editor function is currently provided by the 604 Internet Society.