1. Introduzione

Il protocollo di trasporto in tempo reale, il relativo protocollo di controllo RTP (RTP/RTCP, RFC 3550) [1] e il profilo per le comunicazioni audiovisive con controllo minimo (RFC 3551) [2] definiscono meccanismi per la trasmissione di media basati sul tempo attraverso una rete IP. L'RTP fornisce mezzi per preservare il timing e rilevare le perdite di pacchetti, tra le altre cose, e i formati di payload RTP consentono una corretta strutturazione dei media (continui) in un ambiente basato sui pacchetti. L'RTCP consente ai ricevitori di fornire feedback sulla qualità della ricezione e permette a tutti i membri di una sessione RTP di conoscersi reciprocamente.

La specifica RTP fornisce solo un supporto rudimentale per la crittografia dei pacchetti RTP e RTCP. Il Secure RTP (RFC 3711) [4] definisce un profilo RTP ("SAVP") per sessioni multimediali RTP sicure, definendo metodi per la corretta crittografia dei pacchetti RTP e RTCP, l'integrità e la protezione dal replay. La negoziazione iniziale dell'SRTP e dei suoi parametri di sicurezza deve essere effettuata fuori banda, ad esempio utilizzando il Session Description Protocol (SDP, RFC 4566) [6] insieme alle estensioni per il trasporto del materiale di chiavi (RFC 4567 [7], RFC 4568 [8]).

La specifica RTP fornisce inoltre un supporto limitato per un feedback tempestivo dai ricevitori ai mittenti, tipicamente per mezzo di rapporti sulle statistiche di ricezione a intervalli alquanto regolari a seconda della dimensione del gruppo, della dimensione media del pacchetto RTCP e della larghezza di banda RTCP disponibile. Il profilo RTP esteso per il feedback basato su RTCP ("AVPF") (RFC 4585, [3]) consente ai partecipanti alla sessione di fornire statisticamente un feedback immediato mantenendo la velocità di dati RTCP media per tutti i mittenti. Come per il SAVP, l'uso dell'AVPF e dei suoi parametri deve essere negoziato fuori banda per mezzo dell'SDP (RFC 4566, [6]) e delle estensioni definite nella RFC 4585 [3].

Sia l'SRTP che l'AVPF sono profili RTP e devono essere negoziati. Ciò implica che può essere utilizzato l'uno o l'altro, ma entrambi i profili non possono essere negoziati per la stessa sessione RTP (utilizzando una singola descrizione a livello di sessione SDP). Tuttavia, è auspicabile l'uso combinato di comunicazioni sicure e feedback tempestivo. Pertanto, questo documento specifica un nuovo profilo RTP ("SAVPF") che combina le caratteristiche di SAVP e AVPF.

Poiché SAVP e AVPF sono ampiamente ortogonali, la combinazione di entrambi è per lo più semplice. In questo documento non è necessario specificare algoritmi sofisticati. Al contrario, viene fatto riferimento ad entrambi i profili esistenti e vengono descritte solo le implicazioni della loro combinazione e le possibili deviazioni dalle regole dei profili esistenti, così come il processo di negoziazione.

1.1. Definizioni

Si applicano le definizioni delle RFC 3550 [1], RFC 3551 [2], RFC 4585 [3] e RFC 3711 [4].

Le seguenti definizioni sono specificamente utilizzate in questo documento:

Sessione RTP: Un'associazione tra un insieme di partecipanti che comunicano con RTP come definito nella RFC 3550 [1].
Descrizione multimediale (SDP): Questo termine si riferisce alla specifica fornita in una singola riga m= in un messaggio SDP. Una descrizione multimediale SDP può definire solo una sessione RTP.
Sessione multimediale: Una sessione multimediale si riferisce a una raccolta di descrizioni multimediali SDP che sono raggruppate semanticamente per rappresentare alternative dello stesso mezzo di comunicazione. Da tale gruppo, una sarà negoziata o scelta per una relazione di comunicazione e la corrispondente sessione RTP sarà istanziata. Se non è possibile trovare parametri di sessione comuni adatti agli endpoint coinvolti, la sessione multimediale verrà rifiutata. Nel caso più semplice, una sessione multimediale è equivalente a una descrizione multimediale SDP ed equivalente a una sessione RTP.

1.2. Terminologia

Le parole chiave "MUST" (deve), "MUST NOT" (non deve), "REQUIRED" (richiesto), "SHALL" (dovrà), "SHALL NOT" (non dovrà), "SHOULD" (dovrebbe), "SHOULD NOT" (non dovrebbe), "RECOMMENDED" (raccomandato), "MAY" (può) e "OPTIONAL" (opzionale) in questo documento devono essere interpretate come descritto nella RFC 2119 [5].