6. Hinzufügen und Entfernen von SSRCs
Die Menge der in einer einzigen RTP-Sitzung vorhandenen SSRCs kann sich im Laufe der Zeit ändern, sei es aufgrund von Änderungen der Anzahl der Endpunkte in der Sitzung oder aufgrund von Änderungen der Anzahl oder Art der gesendeten RTP-Ströme.
Jeder Endpunkt in einer RTP-Sitzung verfügt über mindestens eine SSRC, die er für die RTCP-Berichterstattung und, falls gewünscht, zum Senden von Medien verwendet. Er kann auch über zusätzliche SSRCs verfügen, um zusätzliche Medienquellen zu senden oder um zusätzliche RTCP-Berichte zu erstellen. Wenn sich die Menge der gesendeten Medienquellen ändert, ändert sich auch die Menge der gesendeten SSRCs. Änderungen des Medienformats oder der Taktrate können ebenfalls Änderungen der Menge der verwendeten SSRCs erfordern. Ein Endpunkt kann außerdem mehr SSRCs haben, als er aktive RTP-Ströme hat, und RTCP in Bezug auf SSRCs senden, die derzeit keine RTP-Datenpakete senden, damit seine Peers über die SSRCs informiert sind und der zugehörige Kontext (z. B. Taktsynchronisation und ein SDES-CNAME) vorhanden ist, um Medien abspielen zu können, sobald sie aktiv werden.
Im Folgenden beschreiben wir einige Überlegungen zum Hinzufügen und Entfernen von RTP-Strömen und den zugehörigen SSRCs.
6.1. Hinzufügen von RTP-Strömen
Wenn ein Endpunkt einer RTP-Sitzung beitritt, kann er null, einen oder mehrere RTP-Ströme haben, die er senden wird oder zu senden bereit ist. Wenn er keinen RTP-Strom zu senden beabsichtigt, benötigt er dennoch eine SSRC, die zum Senden von RTCP-Feedback verwendet wird. Wenn er einen oder mehrere RTP-Ströme senden wird, benötigt er die entsprechende Anzahl von SSRC-Werten. Die von einem Endpunkt verwendeten SSRCs werden den anderen Endpunkten in der RTP-Sitzung durch Senden von RTP- und RTCP-Paketen bekannt gegeben. SSRCs können auch mit Nicht-RTP-Mitteln signalisiert werden (z. B. [RFC5576]). Sofern nicht durch Signalisierung eingeschränkt, kann ein Endpunkt jederzeit einen zusätzlichen RTP-Strom senden, der durch eine neue SSRC gekennzeichnet ist (dies kann mit einem Signalisierungsereignis verbunden sein, was jedoch außerhalb des Anwendungsbereichs dieses Memorandums liegt). Dadurch wird die neue SSRC für die anderen Endpunkte in der Sitzung sichtbar, da sie sich den einzigen SSRC-Raum teilen, der der Definition einer RTP-Sitzung inhärent ist.
Ein Endpunkt, der noch nie einen RTP-Strom gesendet hat, verfügt über eine SSRC, die er für die RTCP-Berichterstattung verwendet. Wenn dieser Endpunkt mit dem Senden eines RTP-Stroms beginnen möchte, ist es RECOMMENDED, dass er seine vorhandene SSRC für diesen Strom verwendet, da andernfalls die Teilnehmerzahl in der RTP-Sitzung unnötig erhöht wird, was zu einem längeren RTCP-Berichtsintervall und größeren RTCP-Berichten aufgrund von Querberichterstattung (Cross Reporting) führt. Wenn der Endpunkt mit dem Senden von mehr als einem RTP-Strom beginnen möchte, muss er für den zweiten und jeden weiteren RTP-Strom eine neue SSRC erzeugen.
Ein Endpunkt, der zuvor das Senden eines RTP-Stroms eingestellt hat und mit dem Senden eines neuen RTP-Stroms beginnen möchte, kann im Allgemeinen nicht die vorhandene SSRC wiederverwenden und muss oft eine neue SSRC erzeugen, weil eine SSRC weder den Medientyp (z. B. Audio zu Video) noch die RTP-Zeitstempel-Taktrate [RFC7160] ändern kann und weil die SSRC von der Anwendung mit einer bestimmten Semantik verknüpft sein kann (Hinweis: Ein RTP-Strom kann pausieren und mit derselben SSRC neu starten, sofern während der Pause RTCP für diese SSRC gesendet wird; diese Regeln gelten nur für neue RTP-Ströme, die eine vorhandene SSRC wiederverwenden).
6.2. Entfernen von RTP-Strömen
Eine SSRC wird auf eine von zwei Arten aus einer RTP-Sitzung entfernt. Wenn ein Endpunkt aufhört, RTP- und RTCP-Pakete unter Verwendung einer SSRC zu senden, läuft für diese SSRC schließlich ein Timeout ab, wie in Abschnitt 6.3.5 von [RFC3550] beschrieben. Alternativ kann eine SSRC durch Senden eines RTCP-BYE-Pakets, wie in Abschnitt 6.3.7 von [RFC3550] beschrieben, explizit außer Betrieb genommen werden. Es wird RECOMMENDED, SSRCs durch Senden eines RTCP-BYE-Pakets außer Betrieb zu nehmen. Beachten Sie, dass [RFC3550] verlangt, dass das RTCP BYE das letzte in der RTP-Sitzung für eine SSRC gesendete RTP/RTCP-Paket sein SHOULD. Wenn ein Endpunkt einen RTP-Strom neu starten muss, nachdem er ein RTCP BYE für seine SSRC gesendet hat, muss er für diesen Strom einen neuen SSRC-Wert erzeugen.
Die Endgültigkeit des Sendens von RTCP BYE bedeutet, dass Endpunkte abwägen müssen, ob die Einstellung der Übertragung eines RTP-Stroms vorübergehend oder dauerhaft ist. Eine vorübergehende Aussetzung der Medienübertragung unter Verwendung eines bestimmten RTP-Stroms (SSRC) erfordert, dass diese SSRC als aktiver Teilnehmer erhalten bleibt, indem die RTCP-Übertragung für sie fortgesetzt wird. Auf diese Weise kann die Medienübertragung sofort wieder aufgenommen werden, da bekannt ist, dass der Kontext vorhanden ist. Beim dauerhaften Einstellen der Übertragung muss ein Teilnehmer ein RTCP BYE senden, damit die anderen Teilnehmer die RTCP-Bandbreitenressourcen nutzen und ihre Zustandsdatenbanken bereinigen können.
Ein Endpunkt, der die Übertragung aller seiner RTP-Ströme einstellt, aber in der RTP-Sitzung verbleibt, MUST mindestens eine SSRC beibehalten, die für die RTCP-Berichterstattung und das Feedback verwendet wird (d. h., er kann nicht für alle SSRCs ein BYE senden, sondern muss mindestens eine aktive SSRC behalten). Da einige Feedback-Pakete an den Medientyp gebunden sein können, kann es erforderlich sein, innerhalb einer RTP-Sitzung eine SSRC pro Medientyp beizubehalten. Eine Alternative kann darin bestehen, eine neue SSRC zu erstellen, die für die RTCP-Berichterstattung und das Feedback verwendet wird. Um jedoch den Eindruck zu vermeiden, dass ein Endpunkt vollständig aus einer RTP-Sitzung ausscheidet, sollte eine solche neue SSRC zuerst eingerichtet werden -- bevor alle vorhandenen SSRCs beendet werden.