3.1. Scelta dello schema di multiplexing

Session-multiplexing e SSRC-multiplexing hanno pro e contro diversi:

Il session-multiplexing si basa sull'invio del flusso di ritrasmissione in una sessione RTP diversa (come definito in RTP [3]) da quella del flusso originale; cioè, i flussi originali e di ritrasmissione sono inviati a indirizzi di rete e/o numeri di porta diversi. Avere una sessione separata consente maggiore flessibilità. In multicast, l'uso di due sessioni separate per i flussi originale e di ritrasmissione consente a un ricevente di scegliere se iscriversi o meno alla sessione RTP che trasporta il flusso di ritrasmissione. La sessione originale può anche essere multicast a sorgente singola mentre sessioni unicast separate sono usate per convogliare le ritrasmissioni a ciascun ricevente, che di conseguenza riceverà solo i pacchetti di ritrasmissione che richiede.

L'uso di sessioni separate facilita anche un trattamento differenziato da parte della rete e può semplificare l'elaborazione in mixer, translator e cache di pacchetti.

Con SSRC-multiplexing, per i flussi originali e di ritrasmissione basta una sola sessione. Ciò consente a server di streaming e middleware coinvolti in un elevato numero di sessioni concorrenti di minimizzare l'uso delle porte.

Questo formato di payload per la ritrasmissione consente sia session-multiplexing sia SSRC-multiplexing per sessioni unicast. Dal punto di vista dell'implementazione, c'è poca differenza tra i due approcci. Pertanto, per massimizzare l'interoperabilità, entrambi gli approcci di multiplexing SHOULD essere supportati da mittenti e riceventi. Per sessioni multicast, MUST essere usato il session-multiplexing perché l'associazione tra flusso originale e flusso di ritrasmissione è problematica se si usa SSRC-multiplexing con sessioni multicast (si veda la sezione 5.3 per la motivazione).