Sending Multiple RTP Streams in a Single RTP Session
updates
Extracted elements (22)
Sending multiple media types in a single RTP session increases cross-reporting between SSRCs: each SSRC reports on all others, inflating RTCP report sizes and reducing sending frequency for a given RTCP bandwidth, compared to using separate RTP sessions per media type.
The four-packet initial burst limit is chosen to match the TCP maximum initial window (RFC 3390), not the larger experimental initial windows, because an RTP endpoint will typically also start sending RTP data packets simultaneously with these initial RTCP packets.
The recommended T_rr_interval for interoperability is 4 seconds rather than the intuitive 5 seconds, because T_rr_interval suppression causes actual AVPF reporting intervals to be longer than expected, and 4 seconds produces intervals closer to what RTP/AVP endpoints expect.
The RTP/AVPF T_rr_interval suppression mechanism skews RTCP transmission intervals: the actual interval when suppression is active can reach up to 1.5*T_rr_interval + 1.5/1.21828*Td, meaning a single RTCP packet loss can time out an SSRC when T_rr_interval is non-zero.
An endpoint that incorrectly uses the full compound RTCP packet size for avg_rtcp_size will derive an RTCP reporting interval inflated by a factor proportional to the number of SSRCs aggregated, potentially causing premature timeouts. For compatibility with non-updated endpoints, aggregation SHOULD be limited to two reports per compound packet.
An SSRC cannot change media type (e.g., audio to video) or RTP timestamp clock rate. An endpoint that previously stopped sending and wants to send a new stream with a different type or rate must generate a new SSRC value.
Mixing endpoints using RTP/AVP and RTP/AVPF profiles in a single RTP session is NOT RECOMMENDED. If mixed profiles are unavoidable and endpoints are not updated per Section 7.1.4, the RTP/AVPF session SHOULD be configured with T_rr_interval = 4 seconds to avoid premature SSRC timeouts.
There is no mechanism to use different regular RTCP reporting intervals for different media types or individual RTP streams within a single RTP session; separate RTP sessions are required if per-stream RTCP intervals are needed.
After sending an aggregated compound RTCP packet, the endpoint MUST update tp, tn, and T_rr_last for each included SSRC using a calculated average effective transmission time (tt_avg) derived from each SSRC's hypothetical transmission time had it not been aggregated.
An RTP endpoint MUST NOT send more than four compound RTCP packets with zero initial delay when joining a session, regardless of how many SSRCs it has. Additional SSRCs MUST be reported later following normal RTCP timing rules.
Each endpoint MUST schedule RTCP transmission independently for each SSRC. When a timer tn expires, RTCP packets SHOULD be aggregated from additional SSRCs with future tn values into the same compound RTCP packet, selecting SSRCs in order of increasing tn until the packet is full or the MTU is reached.
For all profiles (RTP/AVP, RTP/SAVP, RTP/AVPF, RTP/SAVPF), the SSRC timeout interval SHALL be 5*Td, where Td for timeout purposes SHALL be calculated using Tmin = 5 seconds, not the reduced minimal interval. This updates RFC 4585 Section 3.5.4.
For correct operation with multiple SSRCs, implementations MUST treat each SSRC as a separate participant in the RTP session, so that an endpoint with N SSRCs counts as N participants for RTCP bandwidth and scheduling purposes.
It is RECOMMENDED that a new RTP stream reuse the endpoint's existing SSRC if the endpoint had previously been receive-only, since creating a new SSRC unnecessarily increases the participant count, leading to longer RTCP intervals.
It is RECOMMENDED that SSRCs be explicitly removed by sending an RTCP BYE packet. An endpoint that ceases transmission of all RTP streams but remains in the session MUST maintain at least one active SSRC for RTCP reporting and feedback.
RTCP feedback packets relating to a particular media type SHOULD be sent by an SSRC that receives that media type. Codec control messages and notifications regarding RTP data processed by an endpoint MUST be sent from the SSRC used for that RTP data.
To determine if a session is point-to-point or multiparty, an endpoint MUST count distinct RTCP SDES CNAME values across received RTP and RTCP packets. Endpoints MUST NOT base this determination on connection type (unicast/multicast) or number of SSRCs received.
When calculating effective transmission times for aggregated SSRCs, T_rr_interval-based suppression MUST NOT be used. Reverse reconsideration MUST be performed per Section 6.3.4 of RFC 3550 after aggregated transmission.
When checking whether a scheduled compound RTCP packet already contains feedback messages (Step 2 of RFC 4585 Section 3.5.2), that check MUST be done considering all local SSRCs, not just the sending SSRC.
When using RTP/AVPF or RTP/SAVPF with T_rr_interval non-zero and an intent to have Td smaller than T_rr_interval, Td is RECOMMENDED to be targeted at less than 1/4 of T_rr_interval to avoid very large actual reporting intervals.
When a compound RTCP packet reports on multiple SSRCs, each reporting SSRC updates avg_rtcp_size using div_packet_size = packet_size / number_of_SSRCs_reporting (via the formula avg_rtcp_size = (1/16)*div_packet_size + (15/16)*avg_rtcp_size) rather than the full compound packet size.
When using RTP/SAVP or RTP/SAVPF, the cryptographic context of a compound secure RTCP packet is determined by the SSRC of the sender of the first RTCP sub-packet. This is significant for keying mechanisms such as MIKEY (RFC 3830) that support per-SSRC keying.