Skip to main content

6. Adding and Removing SSRCs

6.1. Adding RTP Streams​

When an endpoint adds a new RTP stream (i.e., starts using a new SSRC):

  • It MUST send an RTCP packet for the new SSRC as soon as possible
  • The initial RTCP packet SHOULD include an SDES packet with CNAME
  • Other participants will learn about the new SSRC from these RTCP packets
  • The endpoint MUST ensure the new SSRC is unique within the session

6.2. Removing RTP Streams​

When an endpoint stops using an SSRC:

  • It SHOULD send a BYE packet for that SSRC
  • The BYE packet allows other participants to quickly remove the SSRC from their databases
  • If a BYE is not sent, other participants will eventually time out the SSRC
  • After sending BYE, the SSRC SHOULD NOT be reused in the same session

7. RTCP Considerations for Streams with Disparate Rates

When an endpoint sends multiple RTP streams with very different packet rates, special considerations apply.

7.1. Timing Out SSRCs​

7.1.1. Problems with the RTP/AVPF T_rr_interval Parameter​

The original RTP/AVPF specification had issues with SSRC timeout when streams have different rates. The T_rr_interval parameter could cause premature timeout of low-rate streams.

7.1.2. Avoiding Premature Timeout​

To avoid premature timeout:

  • Receivers MUST NOT time out an SSRC based solely on lack of RTP packets
  • RTCP packets MUST be considered when determining if an SSRC is still active
  • The timeout period should be based on the RTCP reporting interval, not the RTP packet rate

7.1.3. Interoperability between RTP/AVP and RTP/AVPF​

When RTP/AVP and RTP/AVPF endpoints interact:

  • Both must use compatible timeout rules
  • The more conservative timeout rules should be applied
  • Care must be taken to ensure SSRCs are not prematurely timed out

7.1.4. Updated SSRC Timeout Rules​

This document updates RFC 4585 with the following timeout rules:

An SSRC is considered inactive and MAY be removed from the participant database if:

  • No RTP or RTCP packets have been received for that SSRC for a period of 5 times the RTCP reporting interval
  • A BYE packet has been received for that SSRC

The RTCP reporting interval used for timeout calculation should be:

  • For RTP/AVP: The calculated interval based on session bandwidth
  • For RTP/AVPF: The larger of T_rr_interval and the calculated interval

7.2. Tuning RTCP Transmissions​

7.2.1. RTP/AVP and RTP/SAVP​

For RTP/AVP and RTP/SAVP profiles:

  • RTCP bandwidth is shared among all SSRCs from an endpoint
  • The endpoint should distribute RTCP bandwidth fairly among its SSRCs
  • Low-rate streams should still send RTCP regularly to avoid timeout

7.2.2. RTP/AVPF and RTP/SAVPF​

For RTP/AVPF and RTP/SAVPF profiles:

  • The T_rr_interval parameter applies per SSRC
  • Each SSRC must send regular RTCP packets at least once per T_rr_interval
  • Feedback messages can be sent more frequently within the constraints of the profile

8. Security Considerations

The security considerations of RTP [RFC3550] and RTP/AVPF [RFC4585] apply. Using multiple SSRCs does not introduce new security vulnerabilities, but implementers should be aware of:

  • SSRC Collision: Malicious endpoints could deliberately cause SSRC collisions
  • Resource Exhaustion: An attacker could create many SSRCs to exhaust receiver resources
  • Impersonation: Without proper authentication, an attacker could impersonate SSRCs

Implementations SHOULD:

  • Use SRTP [RFC3711] to protect RTP and RTCP packets
  • Limit the number of SSRCs accepted from a single endpoint
  • Validate SSRC ownership through RTCP CNAME and other mechanisms

9. References

9.1. Normative References​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

  • [RFC3550] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

  • [RFC4585] Ott, J., et al., "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.

  • [RFC3711] Baugher, M., et al., "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

9.2. Informative References​

  • [RFC4588] Rey, J., et al., "RTP Retransmission Payload Format", RFC 4588, July 2006.

  • [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.

  • [CLUE-FRAME] Duckworth, M., et al., "Framework for Telepresence Multi-Streams", Work in Progress, 2015.

  • [SDP-BUNDLE] Holmberg, C., et al., "Negotiating Media Multiplexing Using SDP", Work in Progress, 2016.

  • [MULTI-RTP] Westerlund, M., et al., "Multiple RTP Sessions on a Single Lower-Layer Transport", Work in Progress, 2016.

Last updated on