idnits 2.17.1 draft-begen-avt-ports-for-ucast-mcast-rtp-02.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 4, 2010) is 5188 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-05 -- 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 8, 2010 February 4, 2010 7 Port Mapping Between Unicast and Multicast RTP Sessions 8 draft-begen-avt-ports-for-ucast-mcast-rtp-02 10 Abstract 12 This document presents the details of two port mapping solutions that 13 allow RTP receivers to choose their own RTP and RTCP receive ports 14 for the 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 8, 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. Receiver-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 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 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 try to correlate information from messages that do not 174 fate-share. In other words, if an information is logically 175 coupled to other information, send all of the data in a single 176 transaction to the extent that this is practical. 178 o Do not introduce new vectors for attacks. 180 o Do not carry transport addresses explicitly at the application 181 layer, which is a layer violation. 183 o Do not have any IPv4/IPv6 dependencies. To the extent that 184 addressing information is required to persist across transactions, 185 handle the addresses in a manner that allows the server to give 186 opaque address information (called Cookie) to the client. The 187 client then presents the opaque addressing information back to the 188 server in subsequent transactions. This allows the system to 189 maintain connectivity information without unduly burdening the 190 server(s) with state information. 192 Note that the cookies are not meant to be understood by the 193 clients or other application-layer gateway devices. Thus, a 194 server may use any method of its choice to make the cookie data 195 opaque. 197 o Be NAT-tolerant [RFC5389] [RFC4787]. 199 4. Port Mapping 201 We present the details of the proposed solutions in the context of an 202 example application. 204 Consider an SSM distribution network where a distribution source 205 multicasts RTP packets to a large number of clients, and one or more 206 retransmission servers function as feedback targets to collect 207 unicast RTCP feedback from these clients [I-D.ietf-avt-rtcpssm]. 208 When a client detects a missing packet in the primary multicast 209 session, it requests a retransmission from one of the retransmission 210 servers. The client may or may not be behind a NAT device. We first 211 consider the simpler scenario where there are no NAT devices between 212 the server and client. We then discuss the implications of NAT 213 devices. 215 The pertaining RTP and RTCP flows are sketched in Figure 2. 217 -------------- --- ---------- 218 | |-------------------------------| |-->|P1 | 219 | |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 | 220 | | | | | | 221 | Distribution | ---------------- | | | | 222 | Source | | | | | | | 223 | |---->|P1 | | | | | 224 | |.-.->|P2 | | | | | 225 | | | | | | | | 226 -------------- | P2|<.=.=.=.| |=.=|*c1 | 227 | P2|<~~~~~~~| |~~~|*c1 | 228 | | | N | | | 229 | Retransmission | | A | | Client | 230 | Server | | T | | | 231 | | | | | | 232 | P3|........| |..>|*c2 | 233 | P4|<.=.=.=.| |=.>|*c3 | 234 | | | | | | 235 ---------------- --- ---------- 237 -------> Multicast RTP Flow 238 .-.-.-.> Multicast RTCP Flow 239 .=.=.=.> Unicast RTCP Reports 240 ~~~~~~~> Unicast RTCP Feedback Messages 241 .......> Unicast RTP Flow 243 Figure 2: Example scenario showing an SSM distribution with support 244 for retransmissions from a local server 246 4.1. SDP Description 248 The SDP describing the scenario given in Figure 2 can be written as: 250 v=0 251 o=ali 1122334455 1122334466 IN IP4 nack.example.com 252 s=Local Retransmissions 253 t=0 0 254 a=group:FID 1 2 255 a=rtcp-unicast:rsi 256 m=video 41000 RTP/AVPF 98 257 i=Primary Multicast Stream 258 c=IN IP4 233.252.0.2/255 259 a=source-filter: incl IN IP4 233.252.0.2 198.51.100.1 260 a=rtpmap:98 MP2T/90000 261 a=rtcp:41001 IN IP4 192.0.2.1 262 a=rtcp-fb:98 nack 263 a=mid:1 264 m=video 41002 RTP/AVPF 99 265 i=Unicast Retransmission Stream 266 c=IN IP4 192.0.2.1 267 a=rtpmap:99 rtx/90000 268 a=rtcp:41003 269 a=fmtp:99 apt=98; rtx-time=5000 270 a=mid:2 272 Figure 3: SDP describing an SSM distribution with support for 273 retransmissions from a local server 275 In this SDP, the source stream is multicast from a distribution 276 source (with a source IP address of 198.51.100.1) to the multicast 277 destination address of 233.252.0.2 and port 41000. A retransmission 278 server including feedback target functionality (with an address of 279 192.0.2.1 and port of 41001) is specified with the 'rtcp' attribute. 280 The RTCP port for the unicast session (41003) is also specified with 281 the 'rtcp' attribute. 283 Based on this SDP, we define the following parameters: 285 o DS=198.51.100.1 - Address of the distribution source 287 o G=233.252.0.2 - Destination address where the primary multicast 288 stream is sent to 290 o P1=41000 - Destination RTP port where the primary multicast stream 291 is sent to 293 o P2=41001 - Destination RTCP port on the retransmission server and 294 clients for the primary multicast session 296 o S=192.0.2.1 - Address of the retransmission server 297 o P3=41002 - Source RTP port on the retransmission server for the 298 unicast session 300 o P4=41003 - RTCP port on the retransmission server for the unicast 301 session 303 We denote the client address by C. *c1 denotes the port on the client 304 used to send the unicast feedback in the primary multicast session. 305 *c2 and *c3 denote the RTP and RTCP ports on the client used in the 306 unicast session, respectively. The '*' before the port numbers means 307 that these port numbers are chosen by the client, and not assigned/ 308 imposed by another entity. Note that if the client implements RTP/ 309 RTCP port muxing [I-D.ietf-avt-rtp-and-rtcp-mux] in the unicast 310 session, c2 will equal c3. 312 During the lifetime of a unicast session, the server needs to 313 remember the IP address and ports c2 and c3 of the client. 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 the addressing 343 information using a reversible transform only known to the 344 server. 346 6. The server sends each cookie back to the client using a new RTCP 347 message, called PortMappingResponse. 349 Editor's note: Normally, each PortMappingResponse message needs 350 to be sent back to the port where the request came from. 351 However, this requires the client to implement RTP/RTCP port 352 muxing on port c2. If the client supports port muxing, then 353 there is no need to select a port c3 and the client needs one 354 cookie. However, if the client does not support port muxing, 355 both PortMappingResponse messages MUST be sent to port c3 on the 356 client. In that case, each PortMappingResponse message MUST 357 indicate whether the cookie is for the RTP or RTCP port on the 358 client side. 360 Editor's note: What type of a flag/field should we add to the 361 PortMappingRequest and PortMappingResponse messages? 363 For the server to be able to send the PortMappingResponse for 364 port c2 to port c3, we need to include the cookie for port c3 365 when requesting the cookie for port c2. This introduces delay 366 and dependency, which may be a drawback in certain applications 367 (See Figure 4). 369 7. The client includes the cookie(s) when necessary in the 370 subsequent messages sent to the server. 372 8. Normal flows ensue, with the server using the addressing 373 encapsulated in the opaque cookie(s). 375 4.2.2. Implications of NATs 377 If there are no NAT devices between the server and client, the client 378 MUST acquire a cookie for each distinct 2-tuple of (S, c2) and (S, 379 c3). In other words, as long as the client uses the same local ports 380 and the same server, it can use the same cookies when communicating 381 with any feedback target running on this server. The advantage here 382 is that the client can acquire the necessary cookies at the very 383 beginning for every port pair (if it is not port-muxing) it is 384 planning to use, and thus, can avoid the delays incurred to acquire 385 the cookies later when it wants to use a new unicast service. 387 If there is a NAT device between the server and client, the client 388 may still acquire the cookies at the beginning, provided that it is 389 behind a NAT that assigns the same public IP address and port for the 390 messages sent from the same internal IP address and port even when 391 ithe client is talking to different destinations. However, if this 392 is not true, i.e., the public address(es) and/or port(s) of the 393 client changes when the client communicates with a different feedback 394 target on the same server, the client MUST fall back to acquiring a 395 cookie for each distinct 3-tuple of (S, P3, c2) and (S, P3, c3). 397 4.2.3. Message Flows 399 Figure 4 shows the message flows, where each message is appended with 400 the (Source Address, Source Port, Destination Address, Destination 401 Port) information. In this section, we assume that the client does 402 not mux the RTP and RTCP ports. 404 -------------- ---------------- -------- 405 | Distribution | | Retransmission | | | 406 | Source | | Server | | Client | 407 | (DS) | | (S) | | (C) | 408 -------------- ---------------- -------- 409 | | | 410 | | | 411 |- (DS, *, G, P1) ->|--------- RTP Multicast --------->| 412 |- (DS, *, G, P2) .>|.-.-.-.-. RTCP Multicast -.-.-.-.>| 413 | | | 414 | | | 415 | (C, c1, S, P2) |<.=.=. RTCP Receiver Reports =.=.=| 416 | | (for the multicast session) | 417 : : : 418 | (C, c3, S, P3) |<~~~~ PortMappingRequest(c3) ~~~~~| 419 | | | 420 | (S, P3, C, c3) |~~~~~~~ PortMappingResponse ~~~~~>| 421 | | Cookie(c3) | 422 | | | 423 | (C, c2, S, P3) |<~~~~ PortMappingRequest(c2) ~~~~~| 424 | | with Cookie(c3) | 425 | | | 426 | (S, P3, C, c3) |~~~~~~~ PortMappingResponse ~~~~~>| 427 | | Cookie(c2) | 428 | | | 429 | (C, c1, S, P2) |<~~~ RTCP NACK with Cookie(c2) ~~~| 430 | | | 431 | |**********************************| 432 | |* UNICAST SESSION ESTABLISHED *| 433 | |**********************************| 434 | | | 435 | (S, P3, C, c2) |....... RTP Retransmissions .....>| 436 | | | 437 | | | 438 | (C, c3, S, P3) |<.=.=. RTCP Receiver Reports =.=.=| 439 | | (for the unicast session) | 440 | | | 441 | (S, P3, C, c3) |.=.=.=. RTCP Sender Reports =.=.=>| 442 | | (for the unicast session) | 443 | | | 445 -------> Multicast RTP Flow 446 .-.-.-.> Multicast RTCP Flow 447 .=.=.=.> Unicast RTCP Reports 448 ~~~~~~~> Unicast RTCP Feedback Messages 449 .......> Unicast RTP Flow 450 Figure 4: Message flows for server-side cookie approach 452 Editor's note: When sending the sender reports in the unicast 453 session, how does the server know which port the client is expecting 454 to receive them on? Does this imply that the server needs to 455 remember the specific RTCP port for each client? Update: Yes, this 456 is part of the session state information. 458 In the example above, the compound RTCP packet carrying the NACK 459 message also carries the Cookie(c2) since the server must know which 460 port the client is expecting to receive the RTP retransmission 461 packet(s) on. Some other feedback messages such as the RAMS-R 462 message defined in [I-D.ietf-avt-rapid-acquisition-for-rtp] will 463 result in both RTP and RTCP packets to be sent by the server to the 464 client. The compound RTCP packet carrying such a feedback message 465 MUST carry both Cookie(c2) and Cookie(c3). If an RTCP message from 466 the client will not trigger any transmission from the server (e.g., 467 RTCP receiver and extended reports), it does not have to include any 468 cookies. 470 4.3. Receiver-Generated Cookie Approach 472 4.3.1. Steps 474 This approach follows the steps outlined below: 476 1. The client ascertains server address and port number from the SDP 477 description (S and P3). 479 2. The client determines its port numbers (*c2 and *c3). 481 3. The client generates a random cookie. 483 4. The client sends separate RTCP packets from its ports c2 and c3 484 to the server port P3 to setup the NAT. Each RTCP packet 485 indicates through a bit/field whether it source port will be used 486 for RTP or RTCP traffic by the client. The client repeats this 487 step as deemed necessary to keep the NAT bindings alive. 489 5. The client sends unicast feedback from its port c1 to server port 490 P2 where the RTCP feedback message also carries the cookie from 491 Step 3. 493 6. The server correlates these three RTCP packets based on the 494 cookie value, and remembers the public IP address(es) and port(s) 495 of the client when sending packets back to the client. 497 If the client supports RTP/RTCP port muxing, the server needs to 498 remember only one public IP address and port. The state 499 information the server has to keep is reduced but not totally 500 eliminated. 502 If the server is about to send an RTP and/or RTCP packet to the 503 client but does not know the port mappings since it has not 504 received one or both of the RTCP packets sent in Step 4, it 505 cannot start transmission. Eventually, the client times out and 506 resends the RTCP packets carrying the cookie from its ports c2 507 and c3. Note that if the client supports port muxing, the 508 failure probability is substantially reduced. Once the server 509 figures out the port mappings, it keeps that state information 510 until the unicast session is ended. 512 After the server has established a port mapping for the 2-tuple 513 of cookie and public IP address of the client, it discards RTCP 514 packets carrying the same cookie coming from the same public IP 515 address but from a different public port. The reason is that 516 such packets are likely to be sent by an attacker since there is 517 no good reason for a client to change its port during a short- 518 lived session. Thus, if two different clients sharing the same 519 public IP address accidentally generate the same random cookie 520 and send it to the same port on the server, only the first port 521 mapping will be valid. If neither client is not port-muxing, the 522 (total 4) RTCP packets can cross each other resulting in a 523 failure. 525 To minimize the chances for a failure in the receiver-generated 526 cookie approach, the client should support port muxing and the 527 generated cookies should be truely random. 529 4.3.2. Implications of NATs 531 If there are no NAT devices between the server and client, there is 532 no risk of a cookie collision. Thus, it is safe to use this 533 approach. 535 When there is a NAT device between the server and client, there is a 536 risk of a cookie collision, although it is unlikely if the random 537 cookies are generated properly. 539 5. Message Formats 541 The PortMappingRequest message has the following format: 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 |V=2|P| FMT | PT | Length | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | SSRC of Packet Sender | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | SSRC of Media Source | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Figure 5: FCI field syntax for the PortMappingRequest message 555 The PortMappingResponse message has the following format: 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 |V=2|P| FMT | PT | Length | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | SSRC of Packet Sender | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | SSRC of Media Source | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 : Cookie : 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 6: FCI field syntax for the PortMappingResponse message 571 Editor's note: We will finalize the message formats in a later 572 version. 574 6. Security Considerations 576 TBC. 578 7. IANA Considerations 580 TBC. 582 8. Contributors and Acknowledgments 584 TBC. 586 9. References 588 9.1. Normative References 590 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 591 Jacobson, "RTP: A Transport Protocol for Real-Time 592 Applications", STD 64, RFC 3550, July 2003. 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, March 1997. 597 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 598 Description Protocol", RFC 4566, July 2006. 600 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 601 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 602 July 2006. 604 [I-D.ietf-avt-rtcpssm] 605 Ott, J. and J. Chesterfield, "RTCP Extensions for Single- 606 Source Multicast Sessions with Unicast Feedback", 607 draft-ietf-avt-rtcpssm-19 (work in progress), 608 November 2009. 610 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 611 with Session Description Protocol (SDP)", RFC 3264, 612 June 2002. 614 [I-D.ietf-avt-rtp-and-rtcp-mux] 615 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 616 Control Packets on a Single Port", 617 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 618 August 2007. 620 9.2. Informative References 622 [I-D.ietf-avt-rapid-acquisition-for-rtp] 623 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 624 Based Rapid Acquisition of Multicast RTP Sessions", 625 draft-ietf-avt-rapid-acquisition-for-rtp-05 (work in 626 progress), November 2009. 628 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 629 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 630 RFC 4787, January 2007. 632 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 633 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 634 October 2008. 636 Authors' Addresses 638 Ali Begen 639 Cisco 640 170 West Tasman Drive 641 San Jose, CA 95134 642 USA 644 Email: abegen@cisco.com 646 Bill VerSteeg 647 Cisco 648 5030 Sugarloaf Parkway 649 Lawrenceville, GA 30044 650 USA 652 Email: billvs@cisco.com