4. Verwendung von RTP durch Endpunkte, die mehrere Medienströme senden

Die RTP-Spezifikation [RFC3550] legt bereits fest, dass ein Endpunkt mehrere RTP-Ströme in einer einzigen RTP-Sitzung senden kann. Jeder RTP-Strom wird durch einen eindeutigen SSRC-Wert identifiziert. Die Hauptanforderung besteht darin, dass jeder SSRC innerhalb der RTP-Sitzung eindeutig sein MUSS (MUST).

Beim Senden mehrerer RTP-Ströme:

• Jeder Strom MUSS eine eindeutige SSRC-Kennung haben
• Ströme können verschiedene Medienquellen, verschiedene Kodierungen derselben Quelle oder Redundanz-/Reparaturströme darstellen
• Die RTP-Zeitstempel- und Sequenznummernbereiche sind für jeden SSRC unabhängig

5. Verwendung von RTCP durch Endpunkte, die mehrere Medienströme senden

Dieser Abschnitt klärt und aktualisiert das RTCP-Verhalten für Endpunkte, die mehrere RTP-Ströme senden.

5.1. RTCP-Berichtspflicht

Ein Endpunkt MUSS RTCP-Pakete für jeden SSRC senden, den er zum Senden von RTP-Paketen verwendet. Das bedeutet: Wenn ein Endpunkt N RTP-Ströme (mit N verschiedenen SSRCs) sendet, muss er für alle N SSRCs RTCP-Pakete senden.

Die RTCP-Pakete für verschiedene SSRCs:

• Können in separaten zusammengesetzten (compound) RTCP-Paketen gesendet werden
• Können in einem einzigen zusammengesetzten RTCP-Paket aggregiert werden (empfohlen, wenn möglich)
• MÜSSEN den in RFC 3550 spezifizierten Zeitregeln folgen

5.2. Anfangs-Berichtsintervall

Wenn ein Endpunkt mit dem Senden über einen neuen SSRC beginnt, SOLLTE (SHOULD) er so bald wie möglich ein erstes RTCP-Paket für diesen SSRC senden, gemäß den Regeln in RFC 3550, Abschnitt 6.2. Für das erste RTCP-Paket gilt:

• Die Verzögerung DARF (MAY) auf die Hälfte des normalen Mindestintervalls reduziert werden
• Bei Unicast-Sitzungen DARF die Verzögerung Null sein
• Dies ermöglicht es anderen Teilnehmern, schnell Informationen über den neuen SSRC zu erhalten

5.3. Aggregation von Berichten in zusammengesetzte RTCP-Pakete

Wenn ein Endpunkt über mehrere SSRCs verfügt, wird EMPFOHLEN (RECOMMENDED), die RTCP-Pakete für mehrere SSRCs nach Möglichkeit in einem einzigen zusammengesetzten RTCP-Paket zu aggregieren. Dies:

• Reduziert den Paket-Overhead
• Vereinfacht die RTCP-Zeitplanung
• Reduziert die Anzahl der gesendeten Pakete

5.3.1. Aufrechterhaltung von AVG_RTCP_SIZE

Bei der Aggregation von RTCP-Paketen mehrerer SSRCs muss die Berechnung von AVG_RTCP_SIZE sorgfältig berücksichtigt werden:

• Jeder SSRC sollte seine eigene Schätzung von AVG_RTCP_SIZE pflegen
• Die Schätzung sollte auf der Größe der für diesen SSRC gesendeten zusammengesetzten Pakete basieren
• Wenn Pakete aggregiert werden, wird die Schätzung jedes SSRCs basierend auf seinem Anteil am zusammengesetzten Paket aktualisiert

5.3.2. RTCP-Zeitplanung bei der Aggregation mehrerer SSRCs

Bei der Aggregation von RTCP-Paketen:

• Berechnen Sie die nächste Sendezeit für jeden SSRC unabhängig
• Senden Sie das aggregierte Paket zum frühesten geplanten Zeitpunkt
• Aktualisieren Sie die nächsten Sendezeiten aller enthaltenen SSRCs

5.4. Verwendung von RTP/AVPF- oder RTP/SAVPF-Feedback

Bei Verwendung der Profile RTP/AVPF oder RTP/SAVPF mit mehreren SSRCs gelten zusätzliche Überlegungen.

5.4.1. Wahl des SSRCs für Feedback-Pakete

Beim Senden von Feedback (wie NACK oder PLI):

• Das Feedback-Paket MUSS einen SSRC verwenden, den der Sender besitzt
• Die Wahl des zu verwendenden SSRCs ist implementierungsabhängig
• Es wird EMPFOHLEN, den SSRC des Medienstroms zu verwenden, der am engsten mit dem Feedback verknüpft ist

5.4.2. Zeitplanung eines RTCP-Feedback-Pakets

Feedback-Pakete in AVPF können außerhalb des normalen RTCP-Zeitplans gesendet werden:

• Frühes Feedback ist innerhalb der Einschränkungen des Profils zulässig
• Der Parameter T_rr_interval begrenzt, wie oft Feedback gesendet werden kann
• Feedback für verschiedene SSRCs kann bei Bedarf aggregiert werden