idnits 2.17.1 draft-ietf-avt-rtp-and-rtcp-mux-05.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 602. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3550, updated by this document, for RFC5378 checks: 1998-04-07) -- 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 (May 21, 2007) is 6178 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 2032 (ref. '3') (Obsoleted by RFC 4587) == Outdated reference: A later version (-19) exists of draft-ietf-avt-rtcpssm-13 ** Obsolete normative reference: RFC 4566 (ref. '8') (Obsoleted by RFC 8866) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-15 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Perkins 3 Internet-Draft University of Glasgow 4 Updates: 3550 (if approved) M. Westerlund 5 Intended status: Standards Track Ericsson 6 Expires: November 22, 2007 May 21, 2007 8 Multiplexing RTP Data and Control Packets on a Single Port 9 draft-ietf-avt-rtp-and-rtcp-mux-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 22, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This memo discusses issues that arise when multiplexing RTP data 43 packets and RTP control protocol (RTCP) packets on a single UDP port. 44 It updates RFC 3550 to describe when such multiplexing is, and is 45 not, appropriate, and explains how the Session Description Protocol 46 (SDP) can be used to signal multiplexed sessions. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Distinguishable RTP and RTCP Packets . . . . . . . . . . . . . 4 54 5. Multiplexing RTP and RTCP on a Single Port . . . . . . . . . . 5 55 5.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . . . 6 56 5.1.1. SDP Signalling . . . . . . . . . . . . . . . . . . . . 6 57 5.1.2. Interactions with SIP forking . . . . . . . . . . . . 7 58 5.1.3. Interactions with ICE . . . . . . . . . . . . . . . . 7 59 5.1.4. Interactions with Header Compression . . . . . . . . . 8 60 5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 8 61 5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 9 62 6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 9 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 70 Intellectual Property and Copyright Statements . . . . . . . . . . 14 72 1. Introduction 74 The Real-time Transport Protocol (RTP) [1] comprises two components: 75 a data transfer protocol, and an associated control protocol (RTCP). 76 Historically, RTP and RTCP have been run on separate UDP ports. With 77 increased use of Network Address Translation (NAT) this has become 78 problematic, since opening multiple NAT pinholes can be costly. This 79 memo discusses how the RTP and RTCP flows for a single media type can 80 be run on a single port, to ease NAT traversal, and considers when 81 such multiplexing is appropriate. The multiplexing of several types 82 of media (e.g. audio and video) onto a single port is not considered 83 here (but see Section 5.2 of [1]). 85 This memo is structured as follows: in Section 2 we discuss the 86 design choices which led to the use of separate ports, and comment on 87 the applicability of those choices to current network environments. 88 We discuss terminology in Section 3, how to distinguish multiplexed 89 packets in Section 4, and then specify when and how RTP and RTCP 90 should be multiplexed, and how to signal multiplexed sessions, in 91 Section 5. Quality of service and bandwidth issues are discussion in 92 Section 6. We conclude with security considerations in Section 7. 94 This memo updates Section 11 of [1]. 96 2. Background 98 An RTP session comprises data packets and periodic control (RTCP) 99 packets. RTCP packets are assumed to use "the same distribution 100 mechanism as the data packets" and the "underlying protocol MUST 101 provide multiplexing of the data and control packets, for example 102 using separate port numbers with UDP" [1]. Multiplexing was deferred 103 to the underlying transport protocol, rather than being provided 104 within RTP, for the following reasons: 106 1. Simplicity: an RTP implementation is simplified by moving the RTP 107 and RTCP demultiplexing to the transport layer, since it need not 108 concern itself with the separation of data and control packets. 109 This allows the implementation to be structured in a very natural 110 fashion, with a clean separation of data and control planes. 112 2. Efficiency: following the principle of integrated layer 113 processing [14] an implementation will be more efficient when 114 demultiplexing happens in a single place (e.g. according to UDP 115 port) than when split across multiple layers of the stack (e.g. 116 according to UDP port then according to packet type). 118 3. To enable third party monitors: while unicast voice-over-IP has 119 always been considered, RTP was also designed to support loosely 120 coupled multicast conferences [15] and very large-scale multicast 121 streaming media applications (such as the so-called "triple-play" 122 IPTV service). Accordingly, the design of RTP allows the RTCP 123 packets to be multicast using a separate IP multicast group and 124 UDP port to the data packets. This not only allows participants 125 in a session to get reception quality feedback, but also enables 126 deployment of third party monitors which listen to reception 127 quality without access to the data packets. This was intended to 128 provide manageability of multicast sessions, without compromising 129 privacy. 131 While these design choices are appropriate for many uses of RTP, they 132 are problematic in some cases. There are many RTP deployments which 133 don't use IP multicast, and with the increased use of Network Address 134 Translation (NAT) the simplicity of multiplexing at the transport 135 layer has become a liability, since it requires complex signalling to 136 open multiple NAT pinholes. In environments such as these, it is 137 desirable to provide an alternative to demultiplexing RTP and RTCP 138 using separate UDP ports, instead using only a single UDP port and 139 demultiplexing within the application. 141 This memo provides such an alternative by multiplexing RTP and RTCP 142 packets on a single UDP port, distinguished by the RTP payload type 143 and RTCP packet type values. This pushes some additional work onto 144 the RTP implementation, in exchange for simplified NAT traversal. 146 3. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [2]. 152 4. Distinguishable RTP and RTCP Packets 154 When RTP and RTCP packets are multiplexed onto a single port, they 155 can be distinguished provided: 1) the RTP payload type (PT) values 156 used are distinct from the RTCP packet types used; and 2) for each 157 RTP payload type, PT+128 is distinct from the RTCP packet types used. 158 The first constraint precludes a direct conflict between RTP payload 159 type and RTCP packet type, the second constraint precludes a conflict 160 between an RTP data packet with marker bit set and an RTCP packet. 161 This demultiplexing method works because the RTP payload type and 162 RTCP packet type occupy the same position within the packet. 164 The following conflicts between RTP and RTCP packet types are known: 166 o RTP payload types 64-65 conflict with the (obsolete) RTCP FIR and 167 NACK packets defined in the original RTP Payload Format for H.261 168 [3]. 170 o RTP payload types 72-76 conflict with the RTCP SR, RR, SDES, BYE 171 and APP packets defined in the RTP specification [1]. 173 o RTP payload types 77-78 conflict with the RTCP RTPFB and PSFB 174 packets defined in the RTP/AVPF profile [4]. 176 o RTP payload type 79 conflicts with RTCP Extended Report (XR) [5] 177 packets. 179 o RTP payload type 80 conflicts with Receiver Summary Information 180 (RSI) packets defined in the RTCP Extensions for Single-Source 181 Multicast Sessions with Unicast Feedback [6]. 183 New RTCP packet types may be registered in future, and will further 184 reduce the RTP payload types that are available when multiplexing RTP 185 and RTCP onto a single port. To allow this multiplexing, future RTCP 186 packet type assignments SHOULD be made after the current assignments 187 in the range 209-223, then in the range 194-199, so that only the RTP 188 payload types in the range 64-95 are blocked. 190 Given these constraints, it is RECOMMENDED to follow the guidelines 191 in the RTP/AVP profile [7] for the choice of RTP payload type values, 192 with the additional restriction that payload type values in the range 193 64-95 MUST NOT be used. Specifically, dynamic RTP payload types 194 SHOULD be chosen in the range 96-127 where possible. Values below 64 195 MAY be used if that is insufficient, in which case it is RECOMMENDED 196 that payload type numbers that are not statically assigned by [7] be 197 used first. 199 Note: since all RTCP packets MUST be sent as compound packets 200 beginning with an SR or an RR packet ([1] Section 6.1), one might 201 wonder why RTP payload types other than 72 and 73 are prohibited 202 when multiplexing RTP and RTCP. This is done to ensure robustness 203 against broken nodes which send non-compliant RTCP packets, which 204 might otherwise be confused with multiplexed RTP packets. 206 5. Multiplexing RTP and RTCP on a Single Port 208 The procedures for multiplexing RTP and RTCP on a single port depend 209 on whether the session is a unicast session or a multicast session. 210 For multicast sessions, the procedures also depend on whether Any 211 Source Multicast (ASM) or Source Specific Multicast (SSM) multicast 212 is to be used. 214 5.1. Unicast Sessions 216 It is acceptable to multiplex RTP and RTCP packets on a single UDP 217 port to ease NAT traversal for unicast sessions, provided the RTP 218 payload types used in the session are chosen according to the rules 219 in Section 4, and provided that multiplexing is signalled in advance. 220 The following sections describe how such multiplexed sessions can be 221 signalled using the Session Initiation Protocol (SIP) with the offer/ 222 answer model. 224 5.1.1. SDP Signalling 226 When the Session Description Protocol (SDP) [8] is used to negotiate 227 RTP sessions following the offer/answer model [9], the "a=rtcp-mux" 228 attribute (see Section 8) indicates the desire to multiplex RTP and 229 RTCP onto a single port. The initial SDP offer MUST include this 230 attribute to request multiplexing of RTP and RTCP on a single port. 231 For example: 233 v=0 234 o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e 235 s=- 236 c=IN IP6 2001:DB8::211:24ff:fea3:7a2e 237 t=1153134164 1153137764 238 m=audio 49170 RTP/AVP 97 239 a=rtpmap:97 iLBC/8000 240 a=rtcp-mux 242 This offer denotes a unicast voice-over-IP session using the RTP/AVP 243 profile with iLBC coding. The answerer is requested to send both RTP 244 and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e. 246 If the answerer wishes to multiplex RTP and RTCP onto a single port 247 it MUST include an "a=rtcp-mux" attribute in the answer. The RTP 248 payload types used in the answer MUST conform to the rules in 249 Section 4. 251 If the answer does not contain an "a=rtcp-mux" attribute, the offerer 252 MUST NOT multiplex RTP and RTCP packets on a single port. Instead, 253 it should send and receive RTCP on a port allocated according to the 254 usual port selection rules (either the port pair, or a signalled port 255 if the "a=rtcp:" attribute [10] is also included). This will occur 256 when talking to a peer that does not understand the "a=rtcp-mux" 257 attribute. 259 When SDP is used in a declarative manner, the presence of an "a=rtcp- 260 mux" attribute signals that the sender will multiplex RTP and RTCP on 261 the same port. The receiver MUST be prepared to receive RTCP packets 262 on the RTP port, and any resource reservation needs to be made 263 including the RTCP bandwidth. 265 5.1.2. Interactions with SIP forking 267 When using SIP with a forking proxy, it is possible that an INVITE 268 request may result in multiple 200 (OK) responses. If RTP and RTCP 269 multiplexing is offered in that INVITE, it is important to be aware 270 that some answerers may support multiplexed RTP and RTCP, some not. 271 This will require the offerer to listen for RTCP on both the RTP port 272 and the usual RTCP port, and to send RTCP on both ports, unless 273 branches of the call that support multiplexing are re-negotiated to 274 use separate RTP and RTCP ports. 276 5.1.3. Interactions with ICE 278 It is common to use the Interactive Connectivity Establishment (ICE) 279 [16] methodology to establish RTP sessions in the presence of Network 280 Address Translation (NAT) devices or other middleboxes. If RTP and 281 RTCP are sent on separate ports, the RTP media stream comprises two 282 components in ICE (one for RTP and one for RTCP), with connectivity 283 checks being performed for each component. If RTP and RTCP are to be 284 multiplexed on the same port some of these connectivity checks can be 285 avoided, reducing the overhead of ICE. 287 If it is desired to use both ICE and multiplexed RTP and RTCP, the 288 initial offer MUST contain an "a=rtcp-mux" attribute to indicate that 289 RTP and RTCP multiplexing is desired, and MUST contain "a=candidate:" 290 lines for both RTP and RTCP along with an "a=rtcp:" line indicating a 291 fallback port for RTCP in the case that the answerer does not support 292 RTP and RTCP multiplexing. This MUST be done for each media where 293 RTP and RTCP multiplexing is desired. 295 If the answerer wishes to multiplex RTP and RTCP on a single port, it 296 MUST generate an answer containing an "a=rtcp-mux" attribute, and a 297 single "a=candidate:" line corresponding to the RTP port (i.e. there 298 is no candidate for RTCP), for each media where it is desired to use 299 RTP and RTCP multiplexing. The answerer then performs connectivity 300 checks for that media as if the offer had contained only a single 301 candidate for RTP. If the answerer does not want to multiplex RTP 302 and RTCP on a single port, it MUST NOT include the "a=rtcp-mux" 303 attribute in its answer, and MUST perform connectivity checks for all 304 offered candidates in the usual manner. 306 On receipt of the answer, the offerer looks for the presence of the 307 "a=rtcp-mux" line for each media where multiplexing was offered. If 308 this is present, then connectivity checks proceed as if only a single 309 candidate (for RTP) were offered, and multiplexing is used once the 310 session is established. If the "a=rtcp-mux" line is not present, the 311 session proceeds with connectivity checks using both RTP and RTCP 312 candidates, eventually leading to a session being established with 313 RTP and RTCP on separate ports (as signalled by the "a=rtcp:" 314 attribute). 316 5.1.4. Interactions with Header Compression 318 Multiplexing RTP and RTCP packets onto a single port may negatively 319 impact header compression schemes, for example Compressed RTP (CRTP) 320 [17] and RObust Header Compression (ROHC) [18]. Header compression 321 exploits patterns of change in the RTP headers of consecutive packets 322 to send an indication that the packet changed in the expected way, 323 rather than sending the complete header each time. This can lead to 324 significant bandwidth savings if flows have uniform behaviour. 326 The presence of RTCP packets multiplexed with RTP data packets can 327 disrupt the patterns of change between headers, and has the potential 328 to significantly reduce header compression efficiency. The extent of 329 this disruption depends on the header compression algorithm used, and 330 on the way flows are classified. A well designed classifier should 331 be able to separate RTP and RTCP multiplexed on the same port into 332 different compression contexts, using the payload type field, such 333 that the effect on the compression ratio is small. A classifier that 334 assigns compression contexts based only on the IP addresses and UDP 335 ports will not perform well. It is expected that implementations of 336 header compression will need to be updated to efficiently support RTP 337 and RTCP multiplexed on the same port. 339 This effect of multiplexing RTP and RTCP on header compression may be 340 especially significant in those environments, such as some wireless 341 telephony systems, which rely on the efficiency of header compression 342 to match the media to a limited capacity channel. The implications 343 of multiplexing RTP and RTCP should be carefully considered before 344 use in such environments. 346 5.2. Any Source Multicast Sessions 348 The problem of NAT traversal is less severe for any source multicast 349 (ASM) RTP sessions than for unicast RTP sessions, and the benefit of 350 using separate ports for RTP and RTCP is greater, due to the ability 351 to support third party RTCP only monitors. Accordingly, RTP and RTCP 352 packets SHOULD NOT be multiplexed onto a single port when using ASM 353 multicast RTP sessions, and SHOULD instead use separate ports and 354 multicast groups. 356 5.3. Source Specific Multicast Sessions 358 RTP sessions running over Source Specific Multicast (SSM) send RTCP 359 packets from the source to receivers via the multicast channel, but 360 use a separate unicast feedback mechanism [6] to send RTCP from the 361 receivers back to the source, with the source either reflecting the 362 RTCP packets to the group, or sending aggregate summary reports. 364 Following the terminology of [6], we identify three RTP/RTCP flows in 365 an SSM session: 367 1. RTP and RTCP flows between media sender and distribution source. 368 In many scenarios, the media sender and distribution source are 369 co-located, so multiplexing is not a concern. If the media 370 sender and distribution source are connected by a unicast 371 connection, the rules in Section 5.1 of this memo apply to that 372 connection. If the media sender and distribution source are 373 connected by an Any Source Multicast connection, the rules in 374 Section 5.2 apply to that connection. If the media sender and 375 distribution source are connected by a Source Specific Multicast 376 connection, the RTP and RTCP packets MAY be multiplexed on a 377 single port, provided this is signalled (using "a=rtcp-mux" if 378 using SDP). 380 2. RTP and RTCP sent from the distribution source to the receivers. 381 The distribution source MAY multiplex RTP and RTCP onto a single 382 port to ease NAT traversal issues on the forward SSM path, 383 although doing so may hinder third party monitoring devices if 384 the session uses the simple feedback model. When using SDP, the 385 multiplexing SHOULD be signalled using the "a=rtcp-mux" 386 attribute. 388 3. RTCP sent from receivers to distribution source. This is an RTCP 389 only path, so multiplexing is not a concern. 391 Multiplexing RTP and RTCP packets on a single port in an SSM session 392 has the potential for interactions with header compression described 393 in Section 5.1.4. 395 6. Multiplexing, Bandwidth, and Quality of Service 397 Multiplexing RTP and RTCP has implications on the use of Quality of 398 Service (QoS) mechanism that handles flow that are determined by a 399 three or five tuple (protocol, port and address for source and/or 400 destination). In these cases the RTCP flow will be merged with the 401 RTP flow when multiplexing them together. Thus the RTCP bandwidth 402 requirement needs to be considered when doing QoS reservations for 403 the combined RTP and RTCP flow. However from an RTCP perspective it 404 is beneficial to receive the same treatment of RTCP packets as for 405 RTP as it provides more accurate statistics for the measurements 406 performed by RTCP. 408 The bandwidth required for a multiplexed stream comprises the session 409 bandwidth of the RTP stream, plus the bandwidth used by RTCP. In the 410 usual case, the RTP session bandwidth is signalled in the SDP "b=AS:" 411 (or "b=TIAS:" [11]) line, and the RTCP traffic is limited to 5% of 412 this value. Any QoS reservation SHOULD therefore be made for 105% of 413 the "b=AS:" value. If a non-standard RTCP bandwidth fraction is 414 used, signalled by the SDP "b=RR:" and/or "b=RS:" lines [12], then 415 any QoS reservation SHOULD be made for bandwidth equal to (AS + RS + 416 RR), taking the RS and RR values from the SDP answer. 418 7. Security Considerations 420 The usage of multiplexing RTP and RTCP is not believed to introduce 421 any new security considerations. Known major issues are, integrity 422 and authentication of the signalling used to setup the multiplexing, 423 the integrity, authentication and confidentiality of the actual RTP 424 and RTCP traffic. The security considerations in the RTP 425 specification [1] and any applicable RTP profile (e.g. [7]) and 426 payload format(s) apply. 428 If the Secure Real-time Transport Protocol (SRTP) [13] is to be used 429 in conjunction with multiplexed RTP and RTCP, then multiplexing MUST 430 be done below the SRTP layer. The sender generates SRTP and SRTCP 431 packets in the usual manner, based on their separate cryptographic 432 contexts, and multiplexes them onto a single port immediately before 433 transmission. At the receiver, the cryptographic context is derived 434 from the SSRC, destination network address and destination transport 435 port number in the usual manner, augmented using the RTP payload type 436 and RTCP packet type to demultiplex SRTP and SRTCP according to the 437 rules in Section 4 of this memo. After the SRTP and SRTCP packets 438 have been demultiplexed, cryptographic processing happens in the 439 usual manner. 441 8. IANA Considerations 443 Following the guidelines in [8], the IANA is requested to register 444 one new SDP attribute: 446 o Contact name/email: authors of RFC XXXX 447 o Attribute name: rtcp-mux 449 o Long-form attribute name: RTP and RTCP multiplexed on one port 451 o Type of attribute: media level 453 o Subject to charset: no 455 This attribute is used to signal that RTP and RTCP traffic should be 456 multiplexed on a single port (see Section 5 of this memo). It is a 457 property attribute, which does not take a value. 459 Note to RFC Editor: please replace "RFC XXXX" above with the RFC 460 number of this memo, and remove this note. 462 9. Acknowledgements 464 We wish to thank Steve Casner, Joerg Ott, Christer Holmberg, Gunnar 465 Hellstrom, Randell Jesup, Hadriel Kaplan, Harikishan Desineni, 466 Stephan Wenger, Jonathan Rosenberg, Roni Even, Ingemar Johansson, 467 Dave Singer, and Kevin Johns for their comments on this memo. This 468 work was supported in part by the UK Engineering and Physical 469 Sciences Research Council. 471 10. References 473 10.1. Normative References 475 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 476 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 477 RFC 3550, July 2003. 479 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 480 Levels", BCP 14, RFC 2119, March 1997. 482 [3] Turletti, T., "RTP Payload Format for H.261 Video Streams", 483 RFC 2032, October 1996. 485 [4] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 486 "Extended RTP Profile for Real-time Transport Control Protocol 487 (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. 489 [5] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol 490 Extended Reports (RTCP XR)", RFC 3611, November 2003. 492 [6] Chesterfield, J., Ott, J., and E. Schooler, "RTCP Extensions 493 for Single-Source Multicast Sessions with Unicast Feedback", 494 draft-ietf-avt-rtcpssm-13 (work in progress), March 2007. 496 [7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 497 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 499 [8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 500 Description Protocol", RFC 4566, July 2006. 502 [9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 503 Session Description Protocol (SDP)", RFC 3264, June 2002. 505 [10] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 506 Session Description Protocol (SDP)", RFC 3605, October 2003. 508 [11] Westerlund, M., "A Transport Independent Bandwidth Modifier for 509 the Session Description Protocol (SDP)", RFC 3890, 510 September 2004. 512 [12] Casner, S., "Session Description Protocol (SDP) Bandwidth 513 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 514 July 2003. 516 [13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 517 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 518 RFC 3711, March 2004. 520 10.2. Informative References 522 [14] Clark, D. and D. Tennenhouse, "Architectural Considerations for 523 a New Generation of Protocols", Proceedings of ACM 524 SIGCOMM 1990, September 1990. 526 [15] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM 527 SIGCOMM Computer Communication Review, Volume 22, Number 3, 528 July 1992. 530 [16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 531 Methodology for Network Address Translator (NAT) Traversal for 532 Offer/Answer Protocols", draft-ietf-mmusic-ice-15 (work in 533 progress), March 2007. 535 [17] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for 536 Low-Speed Serial Links", RFC 2508, February 1999. 538 [18] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 539 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., 540 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., 541 Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): 542 Framework and four profiles: RTP, UDP, ESP, and uncompressed", 543 RFC 3095, July 2001. 545 Authors' Addresses 547 Colin Perkins 548 University of Glasgow 549 Department of Computing Science 550 17 Lilybank Gardens 551 Glasgow G12 8QQ 552 UK 554 Email: csp@csperkins.org 556 Magnus Westerlund 557 Ericsson 558 Torshamgatan 23 559 Stockholm SE-164 80 560 Sweden 562 Email: magnus.westerlund@ericsson.com 564 Full Copyright Statement 566 Copyright (C) The IETF Trust (2007). 568 This document is subject to the rights, licenses and restrictions 569 contained in BCP 78, and except as set forth therein, the authors 570 retain all their rights. 572 This document and the information contained herein are provided on an 573 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 574 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 575 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 576 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 577 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 578 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 580 Intellectual Property 582 The IETF takes no position regarding the validity or scope of any 583 Intellectual Property Rights or other rights that might be claimed to 584 pertain to the implementation or use of the technology described in 585 this document or the extent to which any license under such rights 586 might or might not be available; nor does it represent that it has 587 made any independent effort to identify any such rights. Information 588 on the procedures with respect to rights in RFC documents can be 589 found in BCP 78 and BCP 79. 591 Copies of IPR disclosures made to the IETF Secretariat and any 592 assurances of licenses to be made available, or the result of an 593 attempt made to obtain a general license or permission for the use of 594 such proprietary rights by implementers or users of this 595 specification can be obtained from the IETF on-line IPR repository at 596 http://www.ietf.org/ipr. 598 The IETF invites any interested party to bring to its attention any 599 copyrights, patents or patent applications, or other proprietary 600 rights that may cover technology that may be required to implement 601 this standard. Please address the information to the IETF at 602 ietf-ipr@ietf.org. 604 Acknowledgment 606 Funding for the RFC Editor function is provided by the IETF 607 Administrative Support Activity (IASA).