Passa al contenuto principale

6. Aggiunta e rimozione di SSRC

6.1. Aggiunta di flussi RTP​

Quando un endpoint aggiunge un nuovo flusso RTP (ovvero, inizia a utilizzare un nuovo SSRC):

  • DEVE inviare un pacchetto RTCP per il nuovo SSRC il prima possibile
  • Il pacchetto RTCP iniziale DOVREBBE includere un pacchetto SDES con CNAME
  • Gli altri partecipanti apprenderanno il nuovo SSRC da questi pacchetti RTCP
  • L'endpoint DEVE garantire che il nuovo SSRC sia univoco all'interno della sessione

6.2. Rimozione di flussi RTP​

Quando un endpoint smette di utilizzare un SSRC:

  • DOVREBBE inviare un pacchetto BYE per tale SSRC
  • Il pacchetto BYE consente agli altri partecipanti di rimuovere rapidamente l'SSRC dai propri database
  • Se non viene inviato un BYE, gli altri partecipanti finiranno per mandare in timeout l'SSRC
  • Dopo l'invio del BYE, l'SSRC NON DOVREBBE essere riutilizzato nella stessa sessione

7. Considerazioni RTCP per flussi con velocità disparate

Quando un endpoint invia più flussi RTP con velocità di pacchetto molto diverse, si applicano considerazioni speciali.

7.1. Timeout degli SSRC​

7.1.1. Problemi con il parametro T_rr_interval di RTP/AVPF​

La specifica RTP/AVPF originale presentava problemi con il timeout degli SSRC quando i flussi avevano velocità diverse. Il parametro T_rr_interval poteva causare il timeout prematuro dei flussi a bassa velocità.

7.1.2. Evitare il timeout prematuro​

Per evitare il timeout prematuro:

  • I ricevitori NON DEVONO mandare in timeout un SSRC basandosi esclusivamente sulla mancanza di pacchetti RTP
  • I pacchetti RTCP DEVONO essere considerati nel determinare se un SSRC è ancora attivo
  • Il periodo di timeout dovrebbe essere basato sull'intervallo di reporting RTCP, non sulla velocità dei pacchetti RTP

7.1.3. Interoperabilità tra RTP/AVP e RTP/AVPF​

Quando gli endpoint RTP/AVP e RTP/AVPF interagiscono:

  • Entrambi devono utilizzare regole di timeout compatibili
  • Dovrebbero essere applicate le regole di timeout più conservative
  • Bisogna fare attenzione a garantire che gli SSRC non vadano in timeout prematuramente

7.1.4. Regole di timeout SSRC aggiornate​

Questo documento aggiorna la RFC 4585 con le seguenti regole di timeout:

Un SSRC è considerato inattivo e PUÒ essere rimosso dal database dei partecipanti se:

  • Non sono stati ricevuti pacchetti RTP o RTCP per tale SSRC per un periodo di 5 volte l'intervallo di reporting RTCP
  • È stato ricevuto un pacchetto BYE per tale SSRC

L'intervallo di reporting RTCP utilizzato per il calcolo del timeout dovrebbe essere:

  • Per RTP/AVP: l'intervallo calcolato in base alla larghezza di banda della sessione
  • Per RTP/AVPF: il maggiore tra T_rr_interval e l'intervallo calcolato

7.2. Ottimizzazione delle trasmissioni RTCP​

7.2.1. RTP/AVP e RTP/SAVP​

Per i profili RTP/AVP e RTP/SAVP:

  • La larghezza di banda RTCP è condivisa tra tutti gli SSRC di un endpoint
  • L'endpoint dovrebbe distribuire la larghezza di banda RTCP in modo equo tra i suoi SSRC
  • I flussi a bassa velocità dovrebbero comunque inviare regolarmente pacchetti RTCP per evitare il timeout

7.2.2. RTP/AVPF e RTP/SAVPF​

Per i profili RTP/AVPF e RTP/SAVPF:

  • Il parametro T_rr_interval si applica per SSRC
  • Ogni SSRC deve inviare pacchetti RTCP regolari almeno una volta per ogni T_rr_interval
  • I messaggi di feedback possono essere inviati più frequentemente entro i vincoli del profilo

8. Considerazioni sulla Sicurezza

Si applicano le considerazioni sulla sicurezza di RTP [RFC3550] e RTP/AVPF [RFC4585]. L'uso di SSRC multipli non introduce nuove vulnerabilità di sicurezza, ma gli implementatori dovrebbero essere consapevoli di:

  • Collisione SSRC: endpoint malintenzionati potrebbero causare deliberatamente collisioni SSRC
  • Esaurimento delle risorse: un aggressore potrebbe creare molti SSRC per esaurire le risorse del ricevitore
  • Impersonificazione: senza un'autenticazione adeguata, un aggressore potrebbe impersonare degli SSRC

Le implementazioni DOVREBBERO:

  • Utilizzare SRTP [RFC3711] per proteggere i pacchetti RTP e RTCP
  • Limitare il numero di SSRC accettati da un singolo endpoint
  • Convalidare la proprietà dell'SSRC tramite il CNAME RTCP e altri meccanismi

9. Riferimenti

9.1. Riferimenti Normativi​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, Marzo 1997.
  • [RFC3550] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, Luglio 2003.
  • [RFC4585] Ott, J., et al., "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Luglio 2006.
  • [RFC3711] Baugher, M., et al., "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, Marzo 2004.

9.2. Riferimenti Informativi​

  • [RFC4588] Rey, J., et al., "RTP Retransmission Payload Format", RFC 4588, Luglio 2006.
  • [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, Dicembre 2007.
  • [CLUE-FRAME] Duckworth, M., et al., "Framework for Telepresence Multi-Streams", Lavoro in corso, 2015.
  • [SDP-BUNDLE] Holmberg, C., et al., "Negotiating Media Multiplexing Using SDP", Lavoro in corso, 2016.
  • [MULTI-RTP] Westerlund, M., et al., "Multiple RTP Sessions on a Single Lower-Layer Transport", Lavoro in corso, 2016.
Ultimo aggiornamento il