Unicast-Based Rapid Acquisition of Multicast RTP Sessions
Extracted elements (31)
RAMS deliberately reuses existing RTP/RTCP machinery (RFC 4588 retransmission format, RFC 4585 feedback framework, RFC 5760 unicast feedback for SSM) rather than defining a new protocol. This was chosen to improve versatility of existing implementations, promote faster deployment, and achieve better interoperability.
RAMS is designed for engineered networks (e.g., managed IPTV/DSL/DOCSIS) where the bottleneck bandwidth between retransmission server and receiver is known. The protocol explicitly states it SHOULD NOT be used across best-effort Internet paths and requires that unicast burst traffic be a known constant upper-bound multiplier (e*B) on the nominal multicast load.
TCP-style slow-start was explicitly rejected for the unicast burst because it would add many RTTs of delay before reaching full throughput, defeating the purpose of rapid acquisition. Similarly, RSVP-style per-flow admission control has too much latency and overhead for the short-duration, high-bitrate burst flows that RAMS generates.
The RFC 4585 Tmin=1.0s rule is overridden to Tmin=0 for initial RAMS-R because the rule exists to prevent flash crowds in multiparty sessions, but rapid acquisition requests are independent events whose timing does not compound. Delaying the request by any fixed or random amount defeats the purpose of fast acquisition without providing meaningful congestion benefit.
Burst stream synchronization with primary multicast streams is achieved via RTP header extensions carrying NTP-based timing information per RFC 6051, piggybacked on retransmission packets per RFC 4588's requirement to propagate original header extensions. RECOMMENDED that multicast sources emit synchronization header extensions frequently.
Multiple parallel instances of RAMS MAY be run simultaneously to rapidly acquire multiple RTP sessions. Each instance creates its own unicast RTP session, so n simultaneous session acquisitions produce n unicast burst sessions. Within a single instance, all streams of one session share one unicast session.
After joining the multicast session, the RTP_Rx MUST send a RAMS-T message in the unicast burst RTP session with the sequence number of the first RTP packet received in the primary multicast stream. The BRS MUST then terminate the respective burst after transmitting the unicast burst packet whose OSN equals that sequence number minus one.
Each FT_Ap (feedback target at a specific address and port) MUST be associated with only a single RTP session to avoid ambiguity when an RTP_Rx sends a RAMS-R without specifying individual media sender SSRCs.
For transient reject responses (insufficient resources), the RTP_Rx MUST follow RFC 4585 timer rules before retrying. For non-transient reject responses (e.g., response codes 504, 505, 506), the RTP_Rx MUST NOT attempt a retry.
If RFC 5506 reduced-size RTCP has not been signaled, compound RTCP packets MUST be used per RFC 3550. When no data has been received, an empty receiver report MUST still be included in the RTCP BYE compound packet.
In engineered environments where the burst path bandwidth is known, the BRS MUST transmit burst packets at an initial bitrate higher than the nominal multicast bitrate but within the engineered or reserved bandwidth limit. The BRS MUST continuously monitor for congestion-caused packet loss during the burst.
Join time information (when RTP_Rx should send the SFGMP Join) MUST be conveyed in at least one RAMS-I message if the request is accepted. If the BRS cannot include it in the initial RAMS-I, it MUST send a subsequent RAMS-I message with this information.
The BRS MUST NOT send preamble information in a particular format unless the RTP_Rx has explicitly signaled support for that format via a public or private extension in the RAMS-R message. Absent the Preamble-only Allowed TLV (Type=5), the BRS MUST NOT respond to a RAMS-R with preamble-only content.
The RTP_Rx MUST first set up port mappings between the unicast burst RTP session and the primary multicast RTP session and include this mapping in the RAMS-R message before the BRS can respond. This is a prerequisite step before any RAMS signaling can proceed.
The RTP_Rx MUST use a unique CNAME identifier per RFC 6222, since the BRS uses the CNAME to identify requesting receivers and bind RAMS-T messages to ongoing bursts.
Tmin is initialized to zero for the initial RAMS-R message, overriding the RFC 4585 rule that mandates Tmin=1.0 second in multiparty sessions. For subsequent RAMS messages (e.g., updated requests), the normal RFC 4585 timing rules still apply.
When accepting a RAMS request, the BRS MUST send at least one RAMS-I message with response code 200 (or zero for private) per accepted primary multicast stream, and MUST always populate the first RTP sequence number of the burst in each accepted RAMS-I message. Multiple RAMS-I messages for a single RAMS-R MUST be combined in one compound RTCP packet if they fit.
When the RTP_Rx is no longer interested in any primary multicast streams, it SHALL issue RTCP BYE messages in both the unicast burst RTP session and the primary multicast RTP session. Upon receiving RTCP BYE, the BRS MUST terminate the rapid acquisition operation and cease all burst and retransmission packet transmission.
RAMS defines optional TLV fields in the RAMS-R message for burst control: Min RAMS Buffer Fill Requirement (Type=2, 32-bit, milliseconds), Max RAMS Buffer Fill Requirement (Type=3, 32-bit, milliseconds), Max Receive Bitrate (Type=4, 64-bit, bits per second), Preamble-only Allowed (Type=5, zero-length), and Supported Enterprise Number(s). These let the receiver constrain burst behavior.
RAMS (Rapid Acquisition of Multicast RTP Sessions) uses a unicast RTP burst session carrying Reference Information, formatted as RTP retransmission packets per RFC 4588, to precede or accompany a primary multicast RTP session. The burst may be transmitted at faster than natural bitrate, allowing the receiver to acquire Reference Information quickly before or during multicast join.
The RAMS signaling uses three RTCP transport-layer feedback messages: RAMS Request (RAMS-R, SFMT=1), RAMS Information (RAMS-I, SFMT=2), and RAMS Termination (RAMS-T, SFMT=3). All are sent with PT=RTPFB (205) and FMT=RAMS (6), and are payload-independent.
IANA RAMS Response Code Space Registry: governs numeric response codes in RAMS-I messages. Initial codes include 200 (success), 510 (collective reject—cannot serve any stream), 511 (preamble-only response), and 5xx codes for per-stream reject reasons (504, 505, 506 for non-transient failures). Codes are categorized by scope (collective vs. per-stream) and transience.
IANA RAMS TLV Space Registry: governs Type values for TLV elements in RAMS messages. Types 0–127 require IETF Review for vendor-neutral extensions; Types 128–254 are reserved for private/vendor extensions managed by individual vendors using IANA enterprise numbers; Type 255 is reserved.
IANA SFMT Values for RAMS Messages Registry: defines sub-feedback message types within the RAMS FMT (6) space. Initial assignments are RAMS-R (SFMT=1), RAMS-I (SFMT=2), and RAMS-T (SFMT=3). Values 4–254 require IETF Review; value 0 and 255 are reserved.
Because RAMS unicast bursts carry the same Reference Information (including potential encryption keys) as the multicast stream, the unicast session requires at least equivalent security protection as the multicast session. Implementations should ensure SRTP or equivalent confidentiality and integrity protections are applied to both the unicast burst RTP session and RTCP signaling messages.
The RAMS method is susceptible to denial-of-service attacks: a malicious receiver could flood the retransmission server with RAMS-R requests, exhausting its resources. The BRS SHOULD implement a policing mechanism against receivers that do not follow retry rules after non-transient reject responses, and MUST be provisioned to terminate bursts that can no longer proceed faster than the multicast stream.
RAMS acquisition state flow: (1) Port Mapping Setup → (2) RTP_Rx sends RAMS-R → (3) BRS sends RAMS-I (accept/reject) → (4) BRS transmits unicast burst → (5) Optional updated RAMS-R/RAMS-I exchanges → (6) SFGMP Join issued by RTP_Rx → (7) Multicast reception begins → (8) RTP_Rx sends RAMS-T (or RTCP BYE) → (9) BRS terminates burst. Updated requests may loop back to step 5.
Private TLV extension structure prepends a 32-bit Enterprise Number field (from IANA enterprise numbers registry) after the Type/Reserved/Length header and before the Value field, ensuring uniqueness without IANA management. Type values 128–254 are reserved for private extensions.
RAMS Request (RAMS-R) FCI structure: SFMT=1 (8 bits), Reserved (24 bits), followed by a mandatory TLV element listing Requested Media Sender SSRC(s) (Type=1; Length=0 means acquire entire session, otherwise Length=4*n for n SSRCs), plus optional TLV fields.
RTCP feedback common packet format for RAMS messages: V(2 bits)=2, P(1 bit), FMT(5 bits)=6, PT(8 bits)=205 (RTPFB), Length(16 bits), SSRC of packet sender (32 bits), SSRC of media source (32 bits), followed by variable-length FCI. Individual RAMS messages are distinguished by a sub-feedback message type (SFMT) field within the FCI.
TLV extension element structure: Type (1 octet), Reserved (1 octet, set to zero), Length (2 octets, excluding Type, Reserved, and Length fields), Value (variable). Elements must be padded to 32-bit boundary with zero bits if not already aligned.