3. Casi d'uso per endpoint multi-stream
Questa sezione discute diversi casi d'uso che hanno motivato lo sviluppo di endpoint che inviano dati RTP usando SSRC multipli in una singola sessione RTP.
3.1. Endpoint con più dispositivi di acquisizione
La motivazione più diretta per un endpoint a inviare più flussi RTP simultanei in una singola sessione RTP è quando un endpoint dispone di più dispositivi di acquisizione e, quindi, può generare più sorgenti di media, dello stesso tipo di media e con le stesse caratteristiche. Ad esempio, i sistemi di telepresenza del tipo descritto dal CLUE Telepresence Framework [CLUE-FRAME] hanno spesso più telecamere o microfoni che coprono varie aree di una stanza e, quindi, inviano diversi flussi RTP di ciascun tipo all'interno di una singola sessione RTP.
3.2. Tipi di media multipli in una singola sessione RTP
Lavori recenti hanno aggiornato RTP [MULTI-RTP] e il Session Description Protocol (SDP) [SDP-BUNDLE] per rimuovere l'assunzione storica di RTP secondo cui sorgenti di media di tipi di media diversi sarebbero sempre state inviate su sessioni RTP diverse. In questo lavoro, i flussi RTP audio e video di un singolo endpoint (per esempio) sono invece inviati in una singola sessione RTP per ridurre il numero di flussi a livello di trasporto utilizzati.
3.3. Mixer con flussi multipli
Esistono diverse topologie RTP che possono coinvolgere un dispositivo centrale che genera esso stesso più flussi RTP in una sessione. Un esempio è un mixer che fornisce compositing centralizzato per uno scenario multi-acquisizione come quello descritto nella Sezione 3.1. In questo caso, il nodo centralizzato si comporta in modo molto simile a un endpoint multi-acquisitore, generando diverse sorgenti simili e correlate.
Un esempio più complesso è il middlebox di inoltro selettivo, descritto nella Sezione 3.7 di [RFC7667]. Si tratta di un middlebox che riceve flussi RTP da diversi endpoint e poi inoltra selettivamente versioni modificate di alcuni flussi RTP verso gli altri endpoint a cui è connesso. Per ciascun endpoint connesso, una sorgente di media separata appare nella sessione per ogni altra sorgente connessa al middlebox, "proiettata" dai flussi originali, ma in un dato momento molte di esse possono apparire inattive (e quindi sono ricevitori, non mittenti, in RTP). Questo tipo di dispositivo è più vicino a essere un mixer RTP che un traduttore RTP: termina la reportistica RTCP sui flussi mixati; può riscrivere SSRC, timestamp e numeri di sequenza, nonché il contenuto dei payload RTP; e può attivare e disattivare le sorgenti a piacimento senza apparire come generatore di perdita di pacchetti. Ogni flusso proiettato tipicamente preserva le sue informazioni originali di descrizione della sorgente RTCP (SDES).
3.4. SSRC multipli per una singola sorgente di media
Esistono anche diversi casi in cui SSRC multipli possono essere usati per inviare dati da una singola sorgente di media all'interno di una singola sessione RTP. Questi includono, ma non sono limitati a, strumenti di robustezza del trasporto, come il formato di payload di ritrasmissione RTP [RFC4588], che richiede che un SSRC sia usato per i dati di media e un altro SSRC per i dati di riparazione. Allo stesso modo, alcuni schemi di codifica di media a livelli, per esempio H.264 Scalable Video Coding (SVC) [RFC6190], possono essere usati in una configurazione in cui ciascun livello è inviato usando un SSRC diverso all'interno di una singola sessione RTP.