Passa al contenuto principale

4. Uso di RTP da parte di Endpoint che inviano flussi multimediali multipli

La specifica RTP [RFC3550] è già chiara sul fatto che un endpoint può inviare più flussi RTP in una singola sessione RTP. Ogni flusso RTP è identificato da un valore SSRC univoco. Il requisito principale è che ogni SSRC DEVE essere univoco all'interno della sessione RTP.

Quando si inviano più flussi RTP:

  • Ogni flusso DEVE avere un identificatore SSRC univoco
  • I flussi possono rappresentare diverse sorgenti multimediali, diverse codifiche della stessa sorgente o flussi di ridondanza/riparazione
  • Gli spazi dei timestamp RTP e dei numeri di sequenza sono indipendenti per ogni SSRC

5. Uso di RTCP da parte di Endpoint che inviano flussi multimediali multipli

Questa sezione chiarisce e aggiorna il comportamento RTCP per gli endpoint che inviano flussi RTP multipli.

5.1. Requisito di reporting RTCP​

Un endpoint DEVE inviare pacchetti RTCP per ogni SSRC utilizzato per inviare pacchetti RTP. Ciò significa che se un endpoint invia N flussi RTP (con N diversi SSRC), deve inviare pacchetti RTCP per tutti gli N SSRC.

I pacchetti RTCP per diversi SSRC:

  • Possono essere inviati in pacchetti RTCP composti separati
  • Possono essere aggregati in un singolo pacchetto RTCP composto (raccomandato quando possibile)
  • DEVONO seguire le regole di temporizzazione specificate nella RFC 3550

5.2. Intervallo di reporting iniziale​

Quando un endpoint inizia a trasmettere su un nuovo SSRC, DOVREBBE inviare un pacchetto RTCP iniziale per tale SSRC il prima possibile, seguendo le regole della Sezione 6.2 della RFC 3550. Per il primo pacchetto RTCP:

  • Il ritardo PUÒ essere ridotto alla metà del normale intervallo minimo
  • Per le sessioni unicast, il ritardo PUÒ essere zero
  • Ciò consente agli altri partecipanti di conoscere rapidamente il nuovo SSRC

5.3. Aggregazione dei report in pacchetti RTCP composti​

Quando un endpoint ha più SSRC, è RACCOMANDATO aggregare i pacchetti RTCP per più SSRC in un singolo pacchetto RTCP composto, quando possibile. Questo:

  • Riduce l'overhead dei pacchetti
  • Semplifica la pianificazione RTCP
  • Riduce il numero di pacchetti inviati

5.3.1. Mantenimento di AVG_RTCP_SIZE​

Quando si aggregano pacchetti RTCP da più SSRC, il calcolo di AVG_RTCP_SIZE richiede un'attenta considerazione:

  • Ogni SSRC dovrebbe mantenere la propria stima di AVG_RTCP_SIZE
  • La stima dovrebbe essere basata sulla dimensione dei pacchetti composti inviati per tale SSRC
  • Quando i pacchetti sono aggregati, la stima di ogni SSRC viene aggiornata in base alla sua parte del pacchetto composto

5.3.2. Pianificazione di RTCP durante l'aggregazione di SSRC multipli​

Quando si aggregano pacchetti RTCP:

  • Calcolare l'orario di trasmissione successivo per ogni SSRC in modo indipendente
  • Inviare il pacchetto aggregato all'orario programmato più prossimo
  • Aggiornare gli orari di trasmissione successivi di tutti gli SSRC inclusi

5.4. Uso del feedback RTP/AVPF o RTP/SAVPF​

Quando si utilizzano i profili RTP/AVPF o RTP/SAVPF con SSRC multipli, si applicano ulteriori considerazioni.

5.4.1. Scelta dell'SSRC per i pacchetti di feedback​

Quando si invia un feedback (come NACK o PLI):

  • Il pacchetto di feedback DEVE utilizzare un SSRC di proprietà del mittente
  • La scelta di quale SSRC utilizzare dipende dall'implementazione
  • Si RACCOMANDA di utilizzare l'SSRC del flusso multimediale più strettamente correlato al feedback

5.4.2. Pianificazione di un pacchetto di feedback RTCP​

I pacchetti di feedback in AVPF possono essere inviati al di fuori della normale pianificazione RTCP:

  • Il feedback anticipato è consentito entro i vincoli del profilo
  • Il parametro T_rr_interval limita la frequenza con cui è possibile inviare il feedback
  • I feedback per diversi SSRC possono essere aggregati quando appropriato
Ultimo aggiornamento il