Zum Hauptinhalt springen

6. Hinzufügen und Entfernen von SSRCs

6.1. Hinzufügen von RTP-Strömen​

Wenn ein Endpunkt einen neuen RTP-Strom hinzufügt (d. h. beginnt, einen neuen SSRC zu verwenden):

  • MUSS er so bald wie möglich ein RTCP-Paket für den neuen SSRC senden
  • Das erste RTCP-Paket SOLLTE ein SDES-Paket mit CNAME enthalten
  • Andere Teilnehmer erfahren durch diese RTCP-Pakete vom neuen SSRC
  • Der Endpunkt MUSS sicherstellen, dass der neue SSRC innerhalb der Sitzung eindeutig ist

6.2. Entfernen von RTP-Strömen​

Wenn ein Endpunkt die Verwendung eines SSRCs einstellt:

  • SOLLTE er ein BYE-Paket für diesen SSRC senden
  • Das BYE-Paket ermöglicht es anderen Teilnehmern, den SSRC schnell aus ihren Datenbanken zu entfernen
  • Wenn kein BYE gesendet wird, lassen andere Teilnehmer den SSRC schließlich per Timeout ablaufen
  • Nach dem Senden von BYE SOLLTE der SSRC in derselben Sitzung NICHT wiederverwendet werden

7. RTCP-Überlegungen für Ströme mit unterschiedlichen Raten

Wenn ein Endpunkt mehrere RTP-Ströme mit sehr unterschiedlichen Paketraten sendet, gelten besondere Überlegungen.

7.1. Timeout von SSRCs​

7.1.1. Probleme mit dem RTP/AVPF-Parameter T_rr_interval​

Die ursprüngliche RTP/AVPF-Spezifikation hatte Probleme mit dem SSRC-Timeout, wenn Ströme unterschiedliche Raten hatten. Der Parameter T_rr_interval konnte zu einem vorzeitigen Timeout von Strömen mit niedriger Rate führen.

7.1.2. Vermeidung von vorzeitigem Timeout​

Um einen vorzeitigen Timeout zu vermeiden:

  • Empfänger DÜRFEN einen SSRC NICHT allein aufgrund des Fehlens von RTP-Paketen per Timeout ablaufen lassen
  • RTCP-Pakete MÜSSEN bei der Bestimmung, ob ein SSRC noch aktiv ist, berücksichtigt werden
  • Die Timeout-Periode sollte auf dem RTCP-Berichtsintervall basieren, nicht auf der RTP-Paketrate

7.1.3. Interoperabilität zwischen RTP/AVP und RTP/AVPF​

Wenn RTP/AVP- und RTP/AVPF-Endpunkte interagieren:

  • Beide müssen kompatible Timeout-Regeln verwenden
  • Es sollten die konservativeren Timeout-Regeln angewendet werden
  • Es muss darauf geachtet werden, dass SSRCs nicht vorzeitig per Timeout ablaufen

7.1.4. Aktualisierte SSRC-Timeout-Regeln​

Dieses Dokument aktualisiert RFC 4585 mit den folgenden Timeout-Regeln:

Ein SSRC gilt als inaktiv und DARF (MAY) aus der Teilnehmerdatenbank entfernt werden, wenn:

  • Für eine Dauer vom 5-fachen des RTCP-Berichtsintervalls keine RTP- oder RTCP-Pakete für diesen SSRC empfangen wurden
  • Ein BYE-Paket für diesen SSRC empfangen wurde

Das für die Timeout-Berechnung verwendete RTCP-Berichtsintervall sollte sein:

  • Bei RTP/AVP: Das berechnete Intervall basierend auf der Sitzungsbandbreite
  • Bei RTP/AVPF: Der größere Wert von T_rr_interval und dem berechneten Intervall

7.2. Abstimmung von RTCP-Übertragungen​

7.2.1. RTP/AVP und RTP/SAVP​

Für RTP/AVP- und RTP/SAVP-Profile:

  • Die RTCP-Bandbreite wird von allen SSRCs eines Endpunkts geteilt
  • Der Endpunkt sollte die RTCP-Bandbreite fair auf seine SSRCs verteilen
  • Ströme mit niedriger Rate sollten dennoch regelmäßig RTCP senden, um einen Timeout zu vermeiden

7.2.2. RTP/AVPF und RTP/SAVPF​

Für RTP/AVPF- und RTP/SAVPF-Profile:

  • Der Parameter T_rr_interval gilt pro SSRC
  • Jeder SSRC muss mindestens einmal pro T_rr_interval regelmäßige RTCP-Pakete senden
  • Feedback-Nachrichten können innerhalb der Einschränkungen des Profils häufiger gesendet werden

8. Sicherheitsüberlegungen

Es gelten die Sicherheitsüberlegungen von RTP [RFC3550] und RTP/AVPF [RFC4585]. Die Verwendung mehrerer SSRCs führt keine neuen Sicherheitsanfälligkeiten ein, aber Implementierer sollten sich folgender Punkte bewusst sein:

  • SSRC-Kollision: Böswillige Endpunkte könnten absichtlich SSRC-Kollisionen verursachen
  • Ressourcenerschöpfung: Ein Angreifer könnte viele SSRCs erstellen, um die Ressourcen des Empfängers zu erschöpfen
  • Identitätsvortäuschung (Impersonation): Ohne ordnungsgemäße Authentifizierung könnte ein Angreifer SSRCs vortäuschen

Implementierungen SOLLTEN (SHOULD):

  • SRTP [RFC3711] verwenden, um RTP- und RTCP-Pakete zu schützen
  • Die Anzahl der von einem einzelnen Endpunkt akzeptierten SSRCs begrenzen
  • Die SSRC-Inhaberschaft durch RTCP CNAME und andere Mechanismen validieren

9. Referenzen

9.1. Normative Referenzen​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, März 1997.
  • [RFC3550] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, Juli 2003.
  • [RFC4585] Ott, J., et al., "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Juli 2006.
  • [RFC3711] Baugher, M., et al., "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, März 2004.

9.2. Informative Referenzen​

  • [RFC4588] Rey, J., et al., "RTP Retransmission Payload Format", RFC 4588, Juli 2006.
  • [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, Dezember 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.
Letztes Update am