RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback

Abstract

This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism.

Unicast-Based Rapid Acquisition of Multicast RTP Sessions

“…While this problem equally applies to both any-source multicast (ASM) and source-specific multicast (SSM) applications, in this specification we address it for the SSM-based applications by describing a method that uses the fundamental tools offered by the existing RTP and RTCP protocols [RFC3550]. In this method, either the multicast source (or the distribution source in an SSM session) retains the Reference Information for a period after its transmission, or an intermediary network element (that we refer to as Retransmission Server) joins the multicast session and continuously caches the Reference Information as it is sent in the session and acts as a feedback target (see [RFC5760]) for the session. When an RTP receiver wishes to join the same multicast session, instead of simply issuing a Source Filtering Group Management Protocol (SFGMP) Join message, it sends a request to the feedback target for the session and asks for the Reference Information.…”

“…Feedback Target (FT): Unicast RTCP feedback target as defined in [RFC5760]. FT_Ap denotes a specific feedback target running on a particular address and port.…”

“…As shown in Figure 2, the main entities involved in rapid acquisition and the message flows are: As defined in [RFC5760], the feedback target (FT) is the entity to which the RTP_Rx sends its RTCP feedback messages indicating packet loss by means of an RTCP NACK message or indicating RTP_Rx's desire to rapidly acquire the primary multicast RTP session by means of an RTCP feedback message defined in this document. While the Burst/ Retransmission Source (BRS) is responsible for responding to these messages and for further RTCP interaction with the RTP_Rx in the case of a rapid acquisition process, it is assumed in the remainder of this document that these two logical entities (FT and BRS) are combined in a single physical entity and they share state.…”

“…The FT is involved in the primary multicast RTP session and receives unicast feedback for that session as in [RFC5760]. The BRS is involved in the unicast burst (or retransmission) RTP session and transmits the unicast burst and retransmission packets formatted as RTP retransmission packets [RFC4588] in a single separate unicast RTP session to each RTP_Rx.…”

“…o The SDP grouping framework and flow identification (FID) semantics [RFC5888] o The RTP/AVPF profile [RFC4585] o The RTP retransmission payload format [RFC4588] o The RTCP extensions for SSM sessions with unicast feedback [RFC5760] o The 'multicast-rtcp' attribute [RFC6128] o Multiplexing RTP and RTCP on a single port on both endpoints in the unicast session [RFC5761] o The 'portmapping-req' attribute [RFC6284] Support for the source-specific media attributes [RFC5576] can also be needed when the 'ssrc' attribute is to be used for the media descriptions.…”