idnits 2.17.1 draft-ietf-avt-ports-for-ucast-mcast-rtp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- 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 IETF Trust and authors Copyright Line does not match the current year -- The document date (April 12, 2010) is 5100 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) == Missing Reference: 'RFCXXXX' is mentioned on line 553, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-10) exists of draft-ietf-avt-app-rtp-keepalive-07 == Outdated reference: A later version (-17) exists of draft-ietf-avt-rapid-acquisition-for-rtp-08 -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT A. Begen 3 Internet-Draft B. VerSteeg 4 Intended status: Standards Track Cisco 5 Expires: October 14, 2010 April 12, 2010 7 Port Mapping Between Unicast and Multicast RTP Sessions 8 draft-ietf-avt-ports-for-ucast-mcast-rtp-01 10 Abstract 12 This document presents a port mapping solution that allows RTP 13 receivers to choose their own receive ports for an auxiliary unicast 14 session in RTP applications using both unicast and multicast 15 services. The solution requires multiplexing RTP and RTCP on a 16 single port on both endpoints in the unicast session. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 14, 2010. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 54 3. Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1. Steps for Establishing a Unicast Session . . . . . . . . . 8 56 3.2. Implications of NATs . . . . . . . . . . . . . . . . . . . 9 57 3.3. Message Flows . . . . . . . . . . . . . . . . . . . . . . 9 58 3.4. Keeping the NAT Binding(s) Alive . . . . . . . . . . . . . 11 59 3.5. SDP Description . . . . . . . . . . . . . . . . . . . . . 11 60 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 61 4.1. PortMappingRequest (PMReq) . . . . . . . . . . . . . . . . 13 62 4.2. PortMappingResponse (PMRes) . . . . . . . . . . . . . . . 14 63 5. Procedures for Cookie Construction . . . . . . . . . . . . . . 15 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 66 7.1. Registration of FMT Values . . . . . . . . . . . . . . . . 17 67 8. Contributors and Acknowledgments . . . . . . . . . . . . . . . 18 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 73 1. Introduction 75 In (any-source or source-specific) multicast RTP applications, 76 destination ports, i.e., the ports on which the multicast receivers 77 receive the RTP and RTCP packets, are defined declaratively. In 78 other words, the receivers cannot choose their receive ports and the 79 sender(s) use the pre-defined ports. 81 In unicast RTP applications, the receiving end needs to choose its 82 receive ports for RTP and RTCP since these ports are local resources 83 and only the receiving end can determine which ports are available to 84 use. The receiving may convey its request to the sending end through 85 different ways, one of which is the Offer/Answer Model [RFC3264] for 86 the Session Description Protocol (SDP) [RFC4566]. However, the 87 Offer/Answer Model requires offer/answer exchange(s) between the 88 endpoints, and the resulting delay may not be desirable in delay- 89 sensitive real-time applications. Furthermore, the Offer/Answer 90 Model may be burdensome for the endpoints that are concurrently 91 running a large number of unicast sessions with other endpoints. 93 In this specification, we consider an RTP application that uses one 94 or more unicast and multicast RTP sessions together. While the 95 declaration and selection of the ports are well defined and work well 96 for multicast and unicast RTP applications, respectively, the usage 97 of the ports introduces complications when a receiving end mixes 98 unicast and multicast RTP sessions within the same RTP application. 100 An example scenario is where the RTP packets are distributed through 101 source-specific multicast (SSM) and a receiver sends unicast RTCP 102 feedback to a local repair server (also functioning as a feedback 103 target) [RFC5760] asking for a retransmission of the packets it is 104 missing, and the local repair server sends the retransmission packets 105 over a unicast RTP session [RFC4588]. 107 Another scenario is where a receiver wants to rapidly acquire a new 108 primary multicast RTP session and receives one or more RTP burst 109 packets over a unicast session before joining the SSM session 110 [I-D.ietf-avt-rapid-acquisition-for-rtp]. Similar scenarios exist in 111 applications where some part of the content is distributed through 112 multicast while the receivers get additional and/or auxiliary content 113 through one or more unicast connections, as sketched in Figure 1. 115 In this document, we discuss this problem and introduce a solution 116 that we refer to as Port Mapping. This solution allows receivers to 117 choose their desired RTP and RTCP receive ports for every unicast 118 session when they are running RTP applications using both unicast and 119 multicast services. 121 ----------- 122 | Unicast |................ 123 | Source |............. : 124 | (Server) | : : 125 ----------- : : 126 v v 127 ----------- ---------- ----------- 128 | Multicast |------->| Router |---------->|Client RTP | 129 | Source | | |..........>|Application| 130 ----------- ---------- ----------- 131 | : 132 | : ----------- 133 | :..............>|Client RTP | 134 +---------------->|Application| 135 ----------- 137 -------> Multicast RTP Flow 138 .......> Unicast RTP Flow 140 Figure 1: RTP applications simultaneously using both unicast and 141 multicast services 143 In the remainder of this document, we refer to the RTP endpoints that 144 serve other RTP endpoints over a unicast session as the Servers. The 145 receiving RTP endpoints are referred to as Clients. 147 2. Requirements Notation 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 3. Port Mapping 155 We present the details of the port mapping solution in the context of 156 an illustrative example. 158 Consider an SSM distribution network where a distribution source 159 multicasts RTP packets to a large number of clients, and one or more 160 retransmission servers function as feedback targets to collect 161 unicast RTCP feedback from these clients [RFC5760]. The 162 retransmission servers also join the primary multicast session to 163 receive the multicast packets and cache them for a certain time 164 period. When a client detects missing packets in the primary 165 multicast session, it requests a retransmission from one of the 166 retransmission servers by using an RTCP NACK message [RFC4585]. The 167 retransmission server pulls the requested packet(s) out of the cache 168 and retransmits them to the requesting client. 170 The pertaining RTP and RTCP flows are sketched in Figure 2. Between 171 the client and server, there may be one or more NAT devices 172 [RFC4787]. 174 -------------- --- ---------- 175 | |-------------------------------| |-->|P1 | 176 | |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 | 177 | | | | | | 178 | Distribution | ---------------- | | | | 179 | Source | | | | | | | 180 | |---->|P1 | | | | | 181 | |.-.->|P2 | | | | | 182 | | | | | | | | 183 -------------- | P3|<.=.=.=.| |=.=|*c1 | 184 | P3|<~~~~~~~| |~~~|*c1 | 185 | | | N | | | 186 | Retransmission | | A | | Client | 187 | Server | | T | | | 188 | | | | | | 189 | P4|........| |..>|*c2 | 190 | P4|<.=.=.=.| |=.>|*c2 | 191 | | | | | | 192 ---------------- --- ---------- 194 -------> Multicast RTP Flow 195 .-.-.-.> Multicast RTCP Flow 196 .=.=.=.> Unicast RTCP Reports 197 ~~~~~~~> Unicast RTCP Feedback Messages 198 .......> Unicast RTP Flow 200 Figure 2: Example scenario showing an SSM distribution with support 201 for retransmissions from a server 203 In this figure, we have the following multicast and unicast ports: 205 o Ports P1 and P2 denote the destination RTP and RTCP ports in the 206 primary multicast session, respectively. The clients listen to 207 these ports to receive the multicast RTP and RTCP packets. Ports 208 P1 and P2 are defined declaratively. 210 o Port P3 denotes the RTCP port on the feedback target running on 211 the retransmission server to collect the RTCP feedback messages, 212 and RTP receiver and extended reports from the clients in the 213 primary multicast session. Port P3 is defined declaratively. 215 o Port P4 denotes the port on the retransmission server used for the 216 unicast session. The server multiplexes RTP and RTCP traffic on 217 this single port [I-D.ietf-avt-rtp-and-rtcp-mux] in the unicast 218 session. Port P4 is defined declaratively. 220 o Ports *c1 and *c2 are chosen by the client. *c1 denotes the port 221 on the client used to send the unicast RTCP feedback in the 222 primary multicast session. *c2 denotes the port on the client used 223 in the unicast session. The client muxes RTP and RTCP traffic on 224 this single port [I-D.ietf-avt-rtp-and-rtcp-mux] in the unicast 225 session. Ports c1 and c2 do not have to be different ports. 227 Once the unicast session is established, the server needs to remember 228 the public IP address and public port of the client as part of the 229 session state information. The public ports of the client are 230 denoted by c1' and c2'. 232 In addition to the ports, we use the following notation: 234 o DS: IP address of the distribution source 236 o G: Destination multicast address 238 o S: IP address of the retransmission server 240 o C: IP address of the client 242 o C': Public IP address of the client (as seen by the server) 244 We assume that the information declaratively defined is available as 245 part of the session description information and is provided to the 246 clients. The Session Description Protocol (SDP) [RFC4566] and other 247 session description methods can be used for this purpose. 249 3.1. Steps for Establishing a Unicast Session 251 The steps to establish a unicast session are provided below: 253 1. The client ascertains server address (S) and port numbers (P3 and 254 P4) from the session description. 256 2. The client determines its receive port numbers (*c1 and *c2). 258 3. The client sends a message to the server via a new RTCP message, 259 called PortMappingRequest. This message MUST be sent from port 260 c2 to port P4. The server learns client's public IP address (C') 261 and its public RTP/RTCP port (c2') from the received message. 263 4. The server generates an opaque encapsulation (called Cookie) that 264 conveys client's addressing information using a reversible 265 transform only known to the server. 267 5. The server sends the Cookie back to the client using a new RTCP 268 message, called PortMappingResponse. This message MUST be sent 269 from port P4 to port c2'. 271 6. The client includes the Cookie when necessary in the subsequent 272 messages sent to the server. 274 7. Normal flows ensue, with the server using the addressing 275 encapsulated in the opaque Cookie. The client is responsible for 276 keeping the NAT binding alive for the duration of the unicast 277 session. 279 3.2. Implications of NATs 281 There may be one or more NAT devices between the client and server. 282 Without an external mechanism such as STUN [RFC5389], the client 283 cannot determine whether there are any NATs between itself and the 284 server. Such NAT devices would block all incoming traffic unless the 285 client sent traffic of the same transport protocol to the server 286 first. Thus, the client has always to assume that there is at least 287 one NAT device and send periodic packets to keep the NAT binding 288 alive [I-D.ietf-avt-app-rtp-keepalive]. Since the client multiplexes 289 RTP and RTCP on a single port, it has to keep a single NAT binding 290 alive for each unicast session. See Section 3.4 for further details. 292 If the NAT device fails for some reason and then restarts, the public 293 IP address and/or port assigned to a particular client may change. 294 This will invalidate the previously acquired cookies and may result 295 in a failure in the unicast session. Upon detecting the failure, the 296 client must acquire new cookies. Applications using this method must 297 be aware of the potential temporary interruptions. 299 The NAT device may have endpoint-independent mappings [RFC4787], 300 meaning that it assigns the same public IP address and port for the 301 packets sent from the same internal IP address and port, even when 302 the client is talking to different destinations. Oppositely, the NAT 303 device may have endpoint-dependent mappings in which case the public 304 IP address and port of the outgoing packets may differ when they are 305 sent to different destinations. In practice, however, it is a 306 difficult task to determine the type of a NAT device 307 [I-D.ietf-behave-nat-behavior-discovery]. 309 3.3. Message Flows 311 Figure 3 shows the message flows, where each message is appended with 312 the (Source Address, Source Port, Destination Address, Destination 313 Port) information. 315 ------------ ---------------- ------ 316 |Distribution| | Retransmission | | | 317 | Source | | Server | |Client| 318 | (DS) | | (S) | | (C) | 319 ------------ ---------------- ------ 320 | | - | 321 | | | | | 322 (DS,*,G,P1)|--->|-------- RTP Multicast --------->| |-->| 323 (DS,*,G,P2)|.-.>|.-.-.-.- RTCP Multicast .-.-.-.->| |-->| 324 | | | | 325 | | | | 326 |<=.=. RTCP Receiver Reports =.=.=| |<..|(C,c1,S,P3) 327 | (for the multicast session) | | | 328 : | | : 329 : | | : 330 : | | : 331 : | | : 332 |<~~~~~ PortMappingRequest ~~~~~~~| |<~~|(C,c2,S,P4) 333 | |N| | 334 (S,P4,C',c2')|~~~~~~ PortMappingResponse ~~~~~>|A|~~>| 335 | (Cookie) |T| | 336 | | | | 337 |<~~~~ RTCP NACK with Cookie ~~~~~| |<~~|(C,c1,S,P3) 338 | | | | 339 |*********************************|*|***| 340 |* UNICAST SESSION ESTABLISHED | | *| 341 |*********************************|*|***| 342 | | | | 343 (S,P4,C',c2')|...... RTP Retransmissions .....>| |..>| 344 | | | | 345 | | | | 346 |<=.=. RTCP Receiver Reports =.=.=| |<..|(C,c2,S,P4) 347 | (for the unicast session) | | | 348 | | | | 349 (S,P4,C',c2')|=.=.=. RTCP Sender Reports =.=.=>| |..>| 350 | (for the unicast session) | | | 351 | | | | 352 - 354 -------> Multicast RTP Flow 355 .-.-.-.> Multicast RTCP Flow 356 .=.=.=.> Unicast RTCP Reports 357 ~~~~~~~> Unicast RTCP Feedback Messages 358 .......> Unicast RTP Flow 360 Figure 3: Message flows for establishing a unicast session 362 In the example above, the compound RTCP packet carrying the NACK 363 message also carries the Cookie since the server must know which port 364 the client is expecting to receive the RTP retransmission packet(s) 365 and RTCP sender reports on. If an RTCP message from the client will 366 not trigger any transmission from the server (e.g., RTCP receiver and 367 extended reports), it does not have to include the Cookie. 369 3.4. Keeping the NAT Binding(s) Alive 371 Editor's note: We need to determine the best option to keep the NAT 372 bindings alive [I-D.ietf-avt-app-rtp-keepalive]. 374 Editor's note: Are RTCP receiver/extended reports enough to keep the 375 binding alive? 377 TBD. 379 3.5. SDP Description 381 The SDP describing the scenario given in Figure 2 can be written as: 383 v=0 384 o=ali 1122334455 1122334466 IN IP4 nack.example.com 385 s=Local Retransmissions 386 t=0 0 387 a=group:FID 1 2 388 a=rtcp-unicast:rsi 389 m=video 41000 RTP/AVPF 98 390 i=Primary Multicast Stream 391 c=IN IP4 233.252.0.2/255 392 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 393 a=rtpmap:98 MP2T/90000 394 a=multicast-rtcp:42000 395 a=rtcp:43000 IN IP4 192.0.2.1 396 a=rtcp-fb:98 nack 397 a=mid:1 398 m=video 51000 RTP/AVPF 99 399 i=Unicast Retransmission Stream 400 c=IN IP4 192.0.2.1 401 a=sendonly 402 a=rtpmap:99 rtx/90000 403 a=rtcp-mux 404 a=fmtp:99 apt=98; rtx-time=5000 405 a=mid:2 407 Figure 4: SDP describing an SSM distribution with support for 408 retransmissions from a local server 410 In this SDP, the source stream is multicast from a distribution 411 source (with a source IP address of 198.51.100.1) to the multicast 412 destination address of 233.252.0.2 (G) and port 41000 (P1). The 413 associated RTCP packets are multicast in the same group to port 42000 414 (P2). A retransmission server including feedback target 415 functionality with an IP address of 192.0.2.1 (S) and port of 43000 416 (P3) is specified with the 'rtcp' attribute. The server uses port 417 51000 (P4) for the unicast sessions. 419 4. Message Formats 421 The common packet format for the RTCP feedback messages is defined in 422 Section 6.1 of [RFC4585]. A feedback message has a fixed-length 423 field for version, padding, feedback message type (FMT), payload type 424 (PT), length, SSRC of packet sender, SSRC of media sender as well as 425 a variable-length field for feedback control information (FCI). 427 In the PortMappingRequest and PortMappingResponse messages, the PT 428 field is set to RTPFB (205), and the respective FMT fields are set to 429 PMReq (7) and PMRes (8). Depending on the specific scenario, it may 430 be desirable to send these messages in a reduced-size RTCP packet 431 [RFC5506]. However, unless support for [RFC5506] has been signaled, 432 compound RTCP packets MUST be used by following [RFC3550] rules. 434 Editor's note: Should the server always respond to the PMReq message 435 as soon as possible? 437 Following the rules specified in [RFC3550], all integer fields in the 438 messages defined below are carried in network-byte order, that is, 439 most significant byte (octet) first, also known as big-endian. 440 Unless otherwise noted, numeric constants are in decimal (base 10). 441 Any Reserved field SHALL be set to zero and ignored. 443 4.1. PortMappingRequest (PMReq) 445 Editor's note: How do we set the media source SSRC field in the 446 following message? Is it application specific (e.g., 447 retransmissions, RAMS, etc.)? 449 0 1 2 3 450 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 |V=2|P| FMT=7 | PT=205 | Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | SSRC of Packet Sender | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | SSRC of Media Source | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Figure 5: Syntax for the PortMappingRequest (PMReq) message 461 Editor's note: What else do we need to transmit in the PMReq 462 message? 464 4.2. PortMappingResponse (PMRes) 466 Editor's note: How do we set the packet sender SSRC and media source 467 SSRC fields in the following message? Are they application specific 468 (e.g., retransmissions, RAMS, etc.)? 470 0 1 2 3 471 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 |V=2|P| FMT=8 | PT=205 | Length | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | SSRC of Packet Sender | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | SSRC of Media Source | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 : Cookie : 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 Figure 6: Syntax for the PortMappingResponse (PMRes) message 484 Editor's note: What else do we need to transmit in the PMRes 485 message? 487 5. Procedures for Cookie Construction 489 Editor's notes: 491 The Cookie may contain 493 o A 32-bit value randomly generated by the client [RFC4086] 495 o Client's IP address and port (Note that the PMReq and NACK 496 messages are sent from different client ports (and maybe from 497 different public IP addresses as well), thus the server cannot use 498 this information to check whether a cookie is used by the true 499 owner of that cookie) 501 o Client's CNAME 503 o A timestamp to protect against replay attacks (Should the server 504 tell the client about the expiration date so that the client may 505 request a new cookie before the current one expires?) 507 o HMAC [RFC2104] of the above information (where only the server 508 knows the HMAC secret) 510 Details are TBC. 512 6. Security Considerations 514 Editor's notes: 516 o Cookie expiration via timestamping. This could be important for 517 clients behind the same NAT (The clients may still generate the 518 same random number) 520 o Stealing cookies. Can CNAME be used to avoid this for the clients 521 behind the same NAT? 523 o Modifying cookies. Can somebody manipulate the cookies to 524 redirect the traffic? 526 7. IANA Considerations 528 The following contact information shall be used for all registrations 529 in this document: 531 Ali Begen 532 abegen@cisco.com 534 170 West Tasman Drive 535 San Jose, CA 95134 USA 537 Note to the RFC Editor: In the following, please replace "XXXX" with 538 the number of this document prior to publication as an RFC. 540 7.1. Registration of FMT Values 542 Within the RTPFB range, the following format (FMT) values are 543 registered: 545 Name: PMReq 546 Long name: Port Mapping Request 547 Value: 7 548 Reference: [RFCXXXX] 550 Name: PMRes 551 Long name: Port Mapping Response 552 Value: 8 553 Reference: [RFCXXXX] 555 8. Contributors and Acknowledgments 557 Many individuals in the AVT and MMUSIC WGs have contributed to this 558 work, reviewed earlier versions of this specification and provided 559 feedback. The authors thank each of them. 561 9. References 563 9.1. Normative References 565 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 566 Jacobson, "RTP: A Transport Protocol for Real-Time 567 Applications", STD 64, RFC 3550, July 2003. 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, March 1997. 572 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 573 Description Protocol", RFC 4566, July 2006. 575 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 576 "Extended RTP Profile for Real-time Transport Control 577 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 578 July 2006. 580 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 581 Protocol (RTCP) Extensions for Single-Source Multicast 582 Sessions with Unicast Feedback", RFC 5760, February 2010. 584 [I-D.ietf-avt-rtp-and-rtcp-mux] 585 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 586 Control Packets on a Single Port", 587 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 588 August 2007. 590 [I-D.ietf-avt-app-rtp-keepalive] 591 Marjou, X. and A. Sollaud, "Application Mechanism for 592 maintaining alive the Network Address Translator (NAT) 593 mappings associated to RTP flows.", 594 draft-ietf-avt-app-rtp-keepalive-07 (work in progress), 595 December 2009. 597 9.2. Informative References 599 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 600 with Session Description Protocol (SDP)", RFC 3264, 601 June 2002. 603 [I-D.ietf-avt-rapid-acquisition-for-rtp] 604 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 605 Based Rapid Acquisition of Multicast RTP Sessions", 606 draft-ietf-avt-rapid-acquisition-for-rtp-08 (work in 607 progress), March 2010. 609 [I-D.ietf-behave-nat-behavior-discovery] 610 MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 611 Using STUN", draft-ietf-behave-nat-behavior-discovery-08 612 (work in progress), September 2009. 614 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 615 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 616 RFC 4787, January 2007. 618 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 619 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 620 July 2006. 622 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 623 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 624 October 2008. 626 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 627 Real-Time Transport Control Protocol (RTCP): Opportunities 628 and Consequences", RFC 5506, April 2009. 630 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 631 Requirements for Security", BCP 106, RFC 4086, June 2005. 633 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 634 Hashing for Message Authentication", RFC 2104, 635 February 1997. 637 Authors' Addresses 639 Ali Begen 640 Cisco 641 170 West Tasman Drive 642 San Jose, CA 95134 643 USA 645 Email: abegen@cisco.com 647 Bill VerSteeg 648 Cisco 649 5030 Sugarloaf Parkway 650 Lawrenceville, GA 30044 651 USA 653 Email: billvs@cisco.com