idnits 2.17.1 draft-ietf-avt-ports-for-ucast-mcast-rtp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (February 26, 2010) is 5144 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 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-17) exists of draft-ietf-avt-rapid-acquisition-for-rtp-07 -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 2 errors (**), 0 flaws (~~), 2 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: August 30, 2010 February 26, 2010 7 Port Mapping Between Unicast and Multicast RTP Sessions 8 draft-ietf-avt-ports-for-ucast-mcast-rtp-00 10 Abstract 12 This document presents port mapping solutions that allow RTP 13 receivers to choose their own RTP and RTCP receive ports for the 14 unicast session(s) in RTP applications using both unicast and 15 multicast services. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 30, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 59 3. Design Guidelines . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. SDP Description . . . . . . . . . . . . . . . . . . . . . 6 62 4.2. Server-Generated Cookie Approach . . . . . . . . . . . . . 8 63 4.2.1. Steps . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.2.2. Implications of NATs . . . . . . . . . . . . . . . . . 9 65 4.2.3. Message Flows . . . . . . . . . . . . . . . . . . . . 10 66 4.3. Client-Generated Cookie Approach . . . . . . . . . . . . . 12 67 4.3.1. Steps . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.3.2. Implications of NATs . . . . . . . . . . . . . . . . . 13 69 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 8. Contributors and Acknowledgments . . . . . . . . . . . . . . . 14 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 In (any-source or source-specific) multicast RTP applications, 81 destination ports, i.e., the ports on which the multicast receivers 82 receive the RTP and RTCP packets, are defined declaratively. In 83 other words, the receivers cannot choose their receive ports and the 84 sender(s) use the pre-defined ports. 86 In unicast RTP applications, the receiving end often needs to choose 87 its receive ports for RTP and RTCP. It may convey its request to the 88 sending end through different ways, one of which is the Offer/Answer 89 Model [RFC3264] for the Session Description Protocol (SDP) [RFC4566]. 90 However, the Offer/Answer Model requires offer/answer exchange(s) 91 between the endpoints, and the resulting delay may not be acceptable 92 in delay-sensitive real-time applications. 94 RTP sessions are defined based on the destination addresses 95 [RFC3550]. While the declaration and selection of the ports are well 96 defined and work well for multicast and unicast RTP applications, 97 respectively, the usage of the ports introduces complications when a 98 receiving end mixes unicast and multicast RTP sessions within the 99 same RTP application. 101 An example scenario is where the RTP packets are distributed through 102 source-specific multicast (SSM) and a receiver sends unicast RTCP 103 feedback to a local repair server (also functioning as a feedback 104 target) [I-D.ietf-avt-rtcpssm] asking for a retransmission of the 105 packets it is missing, and the local repair server sends the 106 retransmissions over a unicast RTP session [RFC4588]. 108 Another scenario is where a receiver wants to rapidly acquire a new 109 primary multicast RTP session and receives one or more RTP 110 retransmissions over a unicast session before joining the SSM session 111 [I-D.ietf-avt-rapid-acquisition-for-rtp]. Similar scenarios exist in 112 applications where some part of the content is distributed through 113 multicast while the receivers get additional and/or auxiliary content 114 through one or more unicast connections, as sketched in Figure 1. 116 In this document, we discuss this problem and introduce alternative 117 solutions that we refer to as Port Mapping. These solutions allow 118 receivers to choose their desired RTP and RTCP receive ports for 119 every unicast session when they are running RTP applications using 120 both unicast and multicast services. 122 ----------- 123 | Unicast |................ 124 | Source |............. : 125 | (Server) | : : 126 ----------- : : 127 v v 128 ----------- ---------- ----------- 129 | Multicast |------->| Router |---------->|Client RTP | 130 | Source | | |..........>|Application| 131 ----------- ---------- ----------- 132 | : 133 | : ----------- 134 | :..............>|Client RTP | 135 +---------------->|Application| 136 ----------- 138 -------> Multicast RTP Flow 139 .......> Unicast RTP Flow 141 Figure 1: RTP applications simultaneously using both unicast and 142 multicast services 144 In the remainder of this document, we refer to the RTP endpoints that 145 serve other RTP endpoints over a unicast session as the Servers. The 146 receiving RTP endpoints are referred to as Clients. 148 2. Requirements Notation 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 3. Design Guidelines 156 We have the following design guidelines in developing a port mapping 157 solution: 159 o Design a scalable and distributable system. This drives the 160 design towards a system in which all of the actions associated 161 with a given set of flows at a given instant in time are distinct 162 from actions on other flows. This allows the system to be 163 dynamically segmented as dictated by dynamic conditions in the 164 network. 166 o Use atomic, client-driven transactions in order to limit the 167 amount of state information maintained by the server. 169 o Use idempotent transactions in order to limit the impact to the 170 overall system when messages are lost. The state of the system 171 thus only depends on the last successfully received message. 173 o Do not create dependency among messages carried in different 174 packets if possible. In other words, if an information is 175 logically coupled to other information, send all of the data in a 176 single transaction to the extent that this is practical. 178 o Do not introduce new vectors for attacks. 180 o Do not have any IPv4/IPv6 dependencies. To the extent that 181 addressing information is required to persist across transactions, 182 handle the addresses in a manner that allows the server to give 183 opaque address information (called Cookie) to the client. The 184 client then presents the opaque addressing information back to the 185 server in subsequent transactions. This allows the system to 186 maintain connectivity information without unduly burdening the 187 server(s) with state information. 189 The cookie is generated by the server (Section 4.2) or the client 190 (Section 4.3), and is only understood by the server or the client, 191 respectively. To other systems, the cookie is opaque data. Thus, 192 the endpoint generating the cookie may use any method of its 193 choice to make the cookie data opaque. 195 o Be NAT-tolerant [RFC5389] [RFC4787]. Considerations for IPv6/IPv4 196 translation are out of scope of this specification. 198 4. Port Mapping 200 We present the details of the proposed solutions in the context of an 201 example application. 203 Consider an SSM distribution network where a distribution source 204 multicasts RTP packets to a large number of clients, and one or more 205 retransmission servers function as feedback targets to collect 206 unicast RTCP feedback from these clients [I-D.ietf-avt-rtcpssm]. 207 When a client detects a missing packet in the primary multicast 208 session, it requests a retransmission from one of the retransmission 209 servers. The client may or may not be behind a NAT device. We first 210 consider the simpler scenario where there are no NAT devices between 211 the server and client. We then discuss the implications of NAT 212 devices. 214 The pertaining RTP and RTCP flows are sketched in Figure 2. 216 -------------- --- ---------- 217 | |-------------------------------| |-->|P1 | 218 | |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 | 219 | | | | | | 220 | Distribution | ---------------- | | | | 221 | Source | | | | | | | 222 | |---->|P1 | | | | | 223 | |.-.->|P2 | | | | | 224 | | | | | | | | 225 -------------- | P2|<.=.=.=.| |=.=|*c1 | 226 | P2|<~~~~~~~| |~~~|*c1 | 227 | | | N | | | 228 | Retransmission | | A | | Client | 229 | Server | | T | | | 230 | | | | | | 231 | P3|........| |..>|*c2 | 232 | P4|<.=.=.=.| |=.>|*c3 | 233 | | | | | | 234 ---------------- --- ---------- 236 -------> Multicast RTP Flow 237 .-.-.-.> Multicast RTCP Flow 238 .=.=.=.> Unicast RTCP Reports 239 ~~~~~~~> Unicast RTCP Feedback Messages 240 .......> Unicast RTP Flow 242 Figure 2: Example scenario showing an SSM distribution with support 243 for retransmissions from a local server 245 4.1. SDP Description 247 The SDP describing the scenario given in Figure 2 can be written as: 249 v=0 250 o=ali 1122334455 1122334466 IN IP4 nack.example.com 251 s=Local Retransmissions 252 t=0 0 253 a=group:FID 1 2 254 a=rtcp-unicast:rsi 255 m=video 41000 RTP/AVPF 98 256 i=Primary Multicast Stream 257 c=IN IP4 233.252.0.2/255 258 a=source-filter: incl IN IP4 233.252.0.2 198.51.100.1 259 a=rtpmap:98 MP2T/90000 260 a=rtcp:41001 IN IP4 192.0.2.1 261 a=rtcp-fb:98 nack 262 a=mid:1 263 m=video 41002 RTP/AVPF 99 264 i=Unicast Retransmission Stream 265 c=IN IP4 192.0.2.1 266 a=rtpmap:99 rtx/90000 267 a=rtcp:41003 268 a=fmtp:99 apt=98; rtx-time=5000 269 a=mid:2 271 Figure 3: SDP describing an SSM distribution with support for 272 retransmissions from a local server 274 In this SDP, the source stream is multicast from a distribution 275 source (with a source IP address of 198.51.100.1) to the multicast 276 destination address of 233.252.0.2 and port 41000. A retransmission 277 server including feedback target functionality (with an address of 278 192.0.2.1 and port of 41001) is specified with the 'rtcp' attribute. 279 The RTCP port for the unicast session (41003) is also specified with 280 the 'rtcp' attribute. 282 Based on this SDP, we define the following parameters: 284 o DS=198.51.100.1 - Address of the distribution source 286 o G=233.252.0.2 - Destination address where the primary multicast 287 stream is sent to 289 o P1=41000 - Destination RTP port where the primary multicast stream 290 is sent to 292 o P2=41001 - Destination RTCP port on the retransmission server and 293 clients for the primary multicast session 295 o S=192.0.2.1 - Address of the retransmission server 296 o P3=41002 - Source RTP port on the retransmission server for the 297 unicast session 299 o P4=41003 - RTCP port on the retransmission server for the unicast 300 session 302 We denote the client address by C. *c1 denotes the port on the client 303 used to send the unicast feedback in the primary multicast session. 304 *c2 and *c3 denote the RTP and RTCP ports on the client used in the 305 unicast session, respectively. The '*' before the port numbers means 306 that these port numbers are chosen by the client, and not assigned/ 307 imposed by another entity. Note that if the client implements RTP/ 308 RTCP port muxing [I-D.ietf-avt-rtp-and-rtcp-mux] in the unicast 309 session, c2 will equal c3. 311 During the lifetime of a unicast session, the server needs to 312 remember the public IP address and public RTP and RTCP ports of the 313 client as a part of the session state information. 315 4.2. Server-Generated Cookie Approach 317 4.2.1. Steps 319 This approach follows the steps outlined below: 321 1. The client ascertains server address and port number(s) from the 322 SDP description (S, P3 and P4). 324 2. The client determines its port numbers (*c2 and *c3). 326 3. The client sends a message to the server via a new RTCP message, 327 called PortMappingRequest. Separate messages are sourced from 328 ports c2 and c3 on the client. Note that normally the message 329 sent from port c2 should be addressed to port P3 on the server, 330 and the message sent from port c3 should be addressed to port P4 331 on the server. However, since the former RTCP message is sent to 332 an RTP port (P3), the server is required to implement RTP/RTCP 333 port muxing on this port [I-D.ietf-avt-rtp-and-rtcp-mux]. Thus, 334 the server MUST support RTP/RTCP port muxing, and both 335 PortMappingRequest messages sourced from ports c2 and c3 MUST be 336 sent to port P3 on the server. 338 4. The server derives client address (C) and its RTP and RTCP ports 339 (c2 and c3) from the received messages. 341 5. For each PortMappingRequest message, the server generates an 342 opaque encapsulation (called Cookie) that conveys client's 343 addressing information (IP address and port) using a reversible 344 transform only known to the server. 346 6. The server sends each cookie back to the client using a new RTCP 347 message, called PortMappingResponse. Assuming that the client 348 does not support port muxing, two separate PortMappingResponse 349 messages MUST be sent to port c3 on the client and the server 350 MUST indicate in each PortMappingResponse message whether it is 351 for an RTP or for an RTCP port using an appropriate field. 353 For the server to be able to send the PortMappingResponse for 354 port c2 to port c3, the client needs to include the cookie for 355 port c3 when requesting the cookie for port c2. This introduces 356 delay and dependency, which may be a drawback in certain 357 applications (See Figure 4). 359 7. If the client supports port muxing, then there is no need to 360 select a port c3 and the client needs one cookie only. 362 8. The client includes the cookie(s) when necessary in the 363 subsequent messages sent to the server. 365 9. Normal flows ensue, with the server using the addressing 366 encapsulated in the opaque cookie(s). 368 4.2.2. Implications of NATs 370 If there are no NAT devices between the server and client, the client 371 MUST acquire a cookie for each distinct 2-tuple of (S, c2) and (S, 372 c3). In other words, as long as the client uses the same local ports 373 and the same server, it can use the same cookies when communicating 374 with any feedback target running on this server. The advantage here 375 is that the client can acquire the necessary cookies at the very 376 beginning for every port pair (if it is not port-muxing) it is 377 planning to use, and thus, can avoid the delays incurred to acquire 378 the cookies later when it wants to use a new unicast service. 380 If there is a NAT device between the server and client, the client 381 may still acquire the cookies at the beginning, provided that it is 382 behind a NAT that assigns the same public IP address and port for the 383 messages sent from the same internal IP address and port even when 384 the client is talking to different destinations ("endpoint- 385 independent mapping" [RFC4787]). However, if the NAT has endpoint- 386 dependent mapping [RFC4787], the client MUST fall back to acquiring a 387 cookie for each distinct 3-tuple of (S, P3, c2) and (S, P3, c3). In 388 practice, however, it is a difficult task to determine the type of a 389 NAT device [I-D.ietf-behave-nat-behavior-discovery]. 391 When the client is behind a NAT, it needs to send periodic packets to 392 keep the NAT bindings alive [RFC4787]. If the NAT device fails for 393 some reason and then restarts, the public IP address and ports 394 assigned to a client may change. This will invalidate the previously 395 acquired cookies. Upon detecting the failure, the client must 396 acquire new cookies. 398 4.2.3. Message Flows 400 Figure 4 shows the message flows, where each message is appended with 401 the (Source Address, Source Port, Destination Address, Destination 402 Port) information. In this section, we assume that the client does 403 not mux the RTP and RTCP ports. 405 -------------- ---------------- -------- 406 | Distribution | | Retransmission | | | 407 | Source | | Server | | Client | 408 | (DS) | | (S) | | (C) | 409 -------------- ---------------- -------- 410 | | | 411 | | | 412 |- (DS, *, G, P1) ->|--------- RTP Multicast --------->| 413 |- (DS, *, G, P2) .>|.-.-.-.-. RTCP Multicast -.-.-.-.>| 414 | | | 415 | | | 416 | (C, c1, S, P2) |<.=.=. RTCP Receiver Reports =.=.=| 417 | | (for the multicast session) | 418 : : : 419 | (C, c3, S, P3) |<~~~~ PortMappingRequest(c3) ~~~~~| 420 | | | 421 | (S, P3, C, c3) |~~~~~~~ PortMappingResponse ~~~~~>| 422 | | Cookie(c3) | 423 | | | 424 | (C, c2, S, P3) |<~~~~ PortMappingRequest(c2) ~~~~~| 425 | | with Cookie(c3) | 426 | | | 427 | (S, P3, C, c3) |~~~~~~~ PortMappingResponse ~~~~~>| 428 | | Cookie(c2) | 429 | | | 430 | (C, c1, S, P2) |<~ RTCP NACK with Cookie(c2,c3) ~~| 431 | | | 432 | |**********************************| 433 | |* UNICAST SESSION ESTABLISHED *| 434 | |**********************************| 435 | | | 436 | (S, P3, C, c2) |....... RTP Retransmissions .....>| 437 | | | 438 | | | 439 | (C, c3, S, P3) |<.=.=. RTCP Receiver Reports =.=.=| 440 | | (for the unicast session) | 441 | | | 442 | (S, P3, C, c3) |.=.=.=. RTCP Sender Reports =.=.=>| 443 | | (for the unicast session) | 444 | | | 446 -------> Multicast RTP Flow 447 .-.-.-.> Multicast RTCP Flow 448 .=.=.=.> Unicast RTCP Reports 449 ~~~~~~~> Unicast RTCP Feedback Messages 450 .......> Unicast RTP Flow 451 Figure 4: Message flows for server-side cookie approach 453 In the example above, the compound RTCP packet carrying the NACK 454 message also carries the Cookie(c2) and Cookie(c3) since the server 455 must know which ports the client is expecting to receive the RTP 456 retransmission packet(s) and RTCP sender reports on. If an RTCP 457 message from the client will not trigger any transmission from the 458 server (e.g., RTCP receiver and extended reports), it does not have 459 to include any cookies. 461 4.3. Client-Generated Cookie Approach 463 4.3.1. Steps 465 This approach follows the steps outlined below: 467 1. The client ascertains server address and port number from the SDP 468 description (S and P3). 470 2. The client determines its port numbers (*c2 and *c3). 472 3. The client generates a random cookie. 474 4. The client sends separate RTCP packets from its ports c2 and c3 475 to the server port P3 to setup the NAT. Each RTCP packet 476 indicates through a bit/field whether it source port will be used 477 for RTP or RTCP traffic by the client. The client repeats this 478 step as deemed necessary to keep the NAT bindings alive 479 [RFC4787]. 481 5. The client sends unicast feedback from its port c1 to server port 482 P2 where the RTCP feedback message also carries the cookie from 483 Step 3. 485 6. The server correlates these three RTCP packets based on the 486 cookie value, and remembers the public IP address(es) and port(s) 487 of the client when sending packets back to the client. 489 If the client supports RTP/RTCP port muxing, the server needs to 490 remember only one public IP address and port. The state 491 information the server has to keep is reduced but not totally 492 eliminated. 494 If the server is about to send an RTP and/or RTCP packet to the 495 client but does not know the port mappings since it has not received 496 one or both of the RTCP packets sent in Step 4, it cannot start 497 transmission. Eventually, the client times out and resends the RTCP 498 packets carrying the cookie from its ports c2 and c3. Note that if 499 the client supports port muxing, the failure probability is 500 substantially reduced. Once the server figures out the port 501 mappings, it keeps that state information until the unicast session 502 is ended. 504 After the server has established a port mapping for the 2-tuple of 505 cookie and public IP address of the client, it discards RTCP packets 506 carrying the same cookie coming from the same public IP address but 507 from a different public port. The reason is that such packets are 508 likely to be sent by an attacker since there is no good reason for a 509 client to change its port during a short-lived session. Thus, if two 510 different clients sharing the same public IP address accidentally 511 generate the same random cookie and send it to the same port on the 512 server, only the first port mapping will be valid. If neither client 513 is port-muxing, the (total 4) RTCP packets can cross each other 514 resulting in a failure. To minimize the chances for a failure in the 515 client-generated cookie approach, the client should support port 516 muxing and the generated cookies should be truely random [RFC4086]. 518 4.3.2. Implications of NATs 520 If there are no NAT devices between the server and client, there is 521 no risk of a cookie collision. Thus, it is safe to use this 522 approach. 524 When there is a NAT device between the server and client, there is a 525 risk of a cookie collision, although it is unlikely if the random 526 cookies are generated properly [RFC4086]. 528 5. Message Formats 530 The PortMappingRequest message has the following format: 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 |V=2|P| FMT | PT | Length | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | SSRC of Packet Sender | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | SSRC of Media Source | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Figure 5: FCI field syntax for the PortMappingRequest message 544 The PortMappingResponse message has the following format: 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 |V=2|P| FMT | PT | Length | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | SSRC of Packet Sender | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | SSRC of Media Source | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 : Cookie : 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Figure 6: FCI field syntax for the PortMappingResponse message 560 Editor's note: We will finalize the message formats in a later 561 version. 563 6. Security Considerations 565 TBC. 567 7. IANA Considerations 569 TBC. 571 8. Contributors and Acknowledgments 573 TBC. 575 9. References 577 9.1. Normative References 579 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 580 Jacobson, "RTP: A Transport Protocol for Real-Time 581 Applications", STD 64, RFC 3550, July 2003. 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, March 1997. 586 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 587 Description Protocol", RFC 4566, July 2006. 589 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 591 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 592 July 2006. 594 [I-D.ietf-avt-rtcpssm] 595 Ott, J. and J. Chesterfield, "RTCP Extensions for Single- 596 Source Multicast Sessions with Unicast Feedback", 597 draft-ietf-avt-rtcpssm-19 (work in progress), 598 November 2009. 600 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 601 with Session Description Protocol (SDP)", RFC 3264, 602 June 2002. 604 [I-D.ietf-avt-rtp-and-rtcp-mux] 605 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 606 Control Packets on a Single Port", 607 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 608 August 2007. 610 9.2. Informative References 612 [I-D.ietf-avt-rapid-acquisition-for-rtp] 613 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 614 Based Rapid Acquisition of Multicast RTP Sessions", 615 draft-ietf-avt-rapid-acquisition-for-rtp-07 (work in 616 progress), February 2010. 618 [I-D.ietf-behave-nat-behavior-discovery] 619 MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 620 Using STUN", draft-ietf-behave-nat-behavior-discovery-08 621 (work in progress), September 2009. 623 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 624 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 625 RFC 4787, January 2007. 627 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 628 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 629 October 2008. 631 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 632 Requirements for Security", BCP 106, RFC 4086, June 2005. 634 Authors' Addresses 636 Ali Begen 637 Cisco 638 170 West Tasman Drive 639 San Jose, CA 95134 640 USA 642 Email: abegen@cisco.com 644 Bill VerSteeg 645 Cisco 646 5030 Sugarloaf Parkway 647 Lawrenceville, GA 30044 648 USA 650 Email: billvs@cisco.com