3.1. Wahl des Multiplexing-Schemas

Session-Multiplexing und SSRC-Multiplexing haben unterschiedliche Vor- und Nachteile:

Session-Multiplexing basiert darauf, den Retransmission-Strom in einer anderen RTP-Session (gemäß RTP [3]) als dem Originalstrom zu senden; d. h. Original- und Retransmission-Ströme gehen an unterschiedliche Netzadressen und/oder Portnummern. Eine separate Session ermöglicht mehr Flexibilität. Bei Multicast erlauben zwei getrennte Sessions für Original- und Retransmission-Ströme dem Empfänger zu wählen, ob er der RTP-Session mit dem Retransmission-Strom beitritt oder nicht. Die Original-Session kann Single-Source-Multicast sein, während für Retransmissionen zu jedem Empfänger separate Unicast-Sessions genutzt werden, sodass jeder Empfänger nur die von ihm angeforderten Retransmission-Pakete erhält.

Getrennte Sessions erleichtern auch eine differenzierte Behandlung im Netz und können die Verarbeitung in Mixern, Translators und Paket-Caches vereinfachen.

Bei SSRC-Multiplexing genügt eine einzige Session für Original- und Retransmission-Ströme. Das ermöglicht Streaming-Servern und Middleware mit vielen gleichzeitigen Sessions, den Portverbrauch zu minimieren.

Dieses Retransmission-Nutzlastformat erlaubt sowohl Session- als auch SSRC-Multiplexing für Unicast-Sessions. Aus Implementierungssicht unterscheiden sich die beiden Ansätze kaum. Daher SHOULD Sender und Empfänger beide Multiplexing-Ansätze unterstützen, um die Interoperabilität zu maximieren. Für Multicast-Sessions MUST Session-Multiplexing verwendet werden, weil die Zuordnung von Originalstrom und Retransmission-Strom bei SSRC-Multiplexing mit Multicast-Sessions problematisch ist (Motivation siehe Abschnitt 5.3).