IETF RFC 6284 PDF

Introduction

In (any-source or source-specific) multicast RTP applications, destination ports (i.e., the ports on which the multicast receivers receive the RTP and RTP Control Protocol (RTCP) packets) are defined declaratively. In other words, the receivers cannot choose their receive ports, and the sender(s) use the predefined ports.

In unicast RTP applications, the receiving end needs to choose its ports for RTP and RTCP since these ports are local resources and only the receiving end can determine which ports are available to use. In addition, Network Address Port Translation (NAPT, hereafter simply called NAT) devices are commonly deployed in networks; thus, static port assignments cannot be used. The receiving end may convey its request to the sending end through different ways, one of which is the Offer/Answer Model [RFC3264] for the Session Description Protocol (SDP) [RFC4566]. However, the Offer/Answer Model requires offer/ answer exchange(s) between the endpoints, and the resulting delay may not be desirable in delay-sensitive real-time applications. Furthermore, the Offer/Answer Model may be burdensome for the endpoints that are concurrently running a large number of unicast sessions with other endpoints.

In this specification, we consider an RTP application that uses one or more unicast and multicast RTP sessions together. While the declaration and selection of the ports are well defined and work well for multicast and unicast RTP applications, respectively, the usage of the ports introduces complications when a receiving end mixes unicast and multicast RTP sessions within the same RTP application.

An example scenario is where the RTP packets are distributed through source-specific multicast (SSM) [RFC4607] and a receiver sends unicast RTCP NACK feedback [RFC4585] to a local repair server (also functioning as a unicast RTCP feedback target) [RFC5760] asking for a retransmission of the packets it is missing, and the local repair server sends the retransmission packets over a unicast RTP session [RETRANSMISSION-FOR-SSM].

Another scenario is where a receiver wants to rapidly acquire a new primary multicast RTP session and receives one or more RTP burst packets over a unicast session before joining the SSM session; see [RFC6285] regarding Rapid Acquisition of Multicast RTP Sessions (RAMS). Similar scenarios exist in applications where some part of the content is distributed through multicast while the receivers get additional and/or auxiliary content through one or more unicast connections, as illustrated in Figure 1.

In this document, we discuss this problem and introduce a solution that we refer to as port mapping. This solution allows receivers to choose their desired UDP ports for RTP and RTCP in every unicast session when they are running RTP applications using both unicast and multicast services and offer/answer exchange is not available. The solution includes a Token-based protection mechanism against denial-of-service (DoS) or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. This solution is not applicable in cases where TCP is used as the transport protocol in the unicast sessions. For such scenarios, refer to [RFC4145].

In the remainder of this document, we refer to the RTP endpoints that serve other RTP endpoints over a unicast session as the Servers. The receiving RTP endpoints are referred to as Clients. This terminology also reflects the fact that when port mapping is used, the RTP packets can only flow in one direction (from the server to the client) in the unicast sessions.