1. Introduzione
All'epoca in cui il Real-Time Transport Protocol (RTP) [RFC3550] fu originariamente progettato, e per diverso tempo a seguire, gli endpoint nelle sessioni RTP trasmettevano tipicamente una singola sorgente multimediale e, pertanto, utilizzavano un singolo flusso RTP e una singola sorgente di sincronizzazione (SSRC) per sessione RTP, dove sessioni RTP separate venivano tipicamente utilizzate per ogni distinto tipo di media. Recentemente, tuttavia, sono emersi diversi scenari in cui gli endpoint desiderano inviare più flussi RTP, distinti da diversi identificatori di sorgente di sincronizzazione (SSRC), in una singola sessione RTP. Sebbene il progetto iniziale di RTP avesse considerato tali scenari, la specifica non è stata scritta in modo coerente tenendo a mente tali casi d'uso; pertanto, la specifica risulta alquanto confusa in alcuni punti.
Questo promemoria aggiorna la [RFC3550] per chiarire il comportamento nei casi d'uso in cui gli endpoint utilizzano SSRC multipli. Aggiorna inoltre la [RFC4585] per risolvere i problemi relativi al timeout degli SSRC inattivi e per chiarire il comportamento relativo all'inclusione dei messaggi di feedback.
2. Terminologia
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", e "OPTIONAL" in questo documento devono essere interpretate come descritto nella RFC 2119 [RFC2119] e indicano i livelli di requisito per le implementazioni conformi.
3. Casi d'Uso per Endpoint Multi-Flusso
Questa sezione discute diversi casi d'uso che hanno motivato lo sviluppo di endpoint che inviano dati RTP utilizzando SSRC multipli in una singola sessione RTP.
3.1. Endpoint con Dispositivi di Cattura Multipli
La motivazione più diretta per cui un endpoint invia più flussi RTP simultanei in una singola sessione RTP è quando un endpoint ha più dispositivi di cattura e, quindi, può generare più sorgenti multimediali, dello stesso tipo e 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 ogni tipo all'interno di una singola sessione RTP.
3.2. Tipi di Media Multipli in una Singola Sessione RTP
L'attività recente ha aggiornato RTP [MULTI-RTP] e il Session Description Protocol (SDP) [SDP-BUNDLE] per rimuovere l'assunto storico in RTP secondo cui le sorgenti multimediali di diversi tipi di media verrebbero sempre inviate su sessioni RTP diverse. In questo lavoro, i flussi RTP audio e video di un singolo endpoint (ad esempio) vengono invece inviati in una singola sessione RTP per ridurre il numero di flussi a livello di trasporto utilizzati.
3.3. Mixer di 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 la composizione centralizzata per uno scenario di cattura multipla come quello descritto nella Sezione 3.1. In questo caso, il nodo centralizzato si comporta in modo molto simile a un endpoint multi-cattura, generando diverse sorgenti simili e correlate.
3.4. SSRC Multipli per una Singola Sorgente Multimediale
Esistono diversi casi in cui vengono utilizzati SSRC multipli per inviare dati da una singola sorgente multimediale all'interno di una sessione. Questi includono:
- Codec stratificati o a descrizione multipla: Dove diversi strati o descrizioni vengono inviati con SSRC diversi
- Meccanismi di robustezza del trasporto: Come la ritrasmissione RTP [RFC4588] o la correzione degli errori in avanti (FEC) [RFC5109]
- Simulcast: Invio di più codifiche della stessa sorgente a diverse qualità o risoluzioni