Skip to main content

4. Use of RTP by Endpoints That Send Multiple Media Streams

The RTP specification [RFC3550] is already clear that an endpoint can send multiple RTP streams in a single RTP session. Each RTP stream is identified by a unique SSRC value. The main requirement is that each SSRC MUST be unique within the RTP session.

When sending multiple RTP streams:

  • Each stream MUST have a unique SSRC identifier
  • Streams can represent different media sources, different encodings of the same source, or redundancy/repair streams
  • The RTP timestamp and sequence number spaces are independent for each SSRC

5. Use of RTCP by Endpoints That Send Multiple Media Streams

This section clarifies and updates the RTCP behavior for endpoints sending multiple RTP streams.

5.1. RTCP Reporting Requirement​

An endpoint MUST send RTCP packets for each SSRC it uses to send RTP packets. This means that if an endpoint sends N RTP streams (with N different SSRCs), it needs to send RTCP packets for all N SSRCs.

The RTCP packets for different SSRCs:

  • Can be sent in separate compound RTCP packets
  • Can be aggregated into a single compound RTCP packet (recommended when possible)
  • MUST follow the timing rules specified in RFC 3550

5.2. Initial Reporting Interval​

When an endpoint starts sending on a new SSRC, it SHOULD send an initial RTCP packet for that SSRC as soon as possible, following the rules in RFC 3550 Section 6.2. For the first RTCP packet:

  • The delay MAY be reduced to half the normal minimum interval
  • For unicast sessions, the delay MAY be zero
  • This allows other participants to quickly learn about the new SSRC

5.3. Aggregation of Reports into Compound RTCP Packets​

When an endpoint has multiple SSRCs, it is RECOMMENDED to aggregate the RTCP packets for multiple SSRCs into a single compound RTCP packet when possible. This:

  • Reduces packet overhead
  • Simplifies RTCP scheduling
  • Reduces the number of packets sent

5.3.1. Maintaining AVG_RTCP_SIZE​

When aggregating RTCP packets from multiple SSRCs, the AVG_RTCP_SIZE calculation needs careful consideration:

  • Each SSRC should maintain its own estimate of AVG_RTCP_SIZE
  • The estimate should be based on the size of compound packets sent for that SSRC
  • When packets are aggregated, each SSRC's estimate is updated based on its portion of the compound packet

5.3.2. Scheduling RTCP when Aggregating Multiple SSRCs​

When aggregating RTCP packets:

  • Calculate the next transmission time for each SSRC independently
  • Send the aggregated packet at the earliest scheduled time
  • Update all included SSRCs' next transmission times

5.4. Use of RTP/AVPF or RTP/SAVPF Feedback​

When using the RTP/AVPF or RTP/SAVPF profiles with multiple SSRCs, additional considerations apply.

5.4.1. Choice of SSRC for Feedback Packets​

When sending feedback (such as NACK or PLI):

  • The feedback packet MUST use an SSRC that the sender owns
  • The choice of which SSRC to use is implementation-dependent
  • It is RECOMMENDED to use the SSRC of the media stream most closely related to the feedback

5.4.2. Scheduling an RTCP Feedback Packet​

Feedback packets in AVPF can be sent outside the normal RTCP schedule:

  • Early feedback is allowed within the constraints of the profile
  • The T_rr_interval parameter limits how often feedback can be sent
  • Feedback for different SSRCs can be aggregated when appropriate
Last updated on