3. Definizioni SDP

3.1. Definizione del profilo

I profili AV definiti nelle RFC 3551 [2], RFC 4585 [3] e RFC 3711 [4] sono indicati rispettivamente come "AVP", "AVPF" e "SAVP" nel contesto, ad esempio, del Session Description Protocol (SDP) [3]. Il profilo combinato specificato in questo documento è indicato come "SAVPF".

3.2. Definizioni degli attributi

Gli attributi SDP per la negoziazione delle sessioni SAVP sono definiti nelle RFC 4567 [7] e RFC 4568 [8]. Tali attributi POSSONO essere utilizzati anche con SAVPF. Si applicano le regole definite in [7] e [8].

Gli attributi SDP per la negoziazione delle sessioni AVPF sono definiti nella RFC 4585 [3]. Tali attributi POSSONO essere utilizzati anche con SAVPF. Si applicano le regole definite in [3].

3.3. Negoziazione del profilo

Le descrizioni di sessione per le sessioni RTP possono essere trasmesse utilizzando protocolli dedicati alle comunicazioni multimediali come il modello offerta/risposta SDP (RFC 3264, [9]) utilizzato con il Session Initiation Protocol (SIP) [15], il Real Time Streaming Protocol (RTSP) [10] o il Session Announcement Protocol (SAP) [11], ma possono anche essere distribuite tramite email, NetNews, pagine web, ecc.

Il modello offerta/risposta consente di negoziare i parametri di sessione risultanti utilizzando gli attributi SDP definiti nelle RFC 4567 [7] e RFC 4568 [8]. Nella sottosezione seguente, il processo di negoziazione è descritto in termini di modello offerta/risposta.

Successivamente, vengono affrontati i casi che non utilizzano il modello offerta/risposta: il supporto alla negoziazione specifica per RTSP è fornito dalla RFC 4567 [7], come discusso nella Sezione 3.3.2, e il supporto per gli annunci SAP (senza alcuna negoziazione) è affrontato nella Sezione 3.3.3.

3.3.1. Negoziazione delle descrizioni di sessione basata sul modello offerta/risposta

Le negoziazioni (ad esempio, dei profili RTP, dei codec, degli indirizzi di trasporto, ecc.) vengono effettuate sulla base della singola sessione multimediale (ad esempio, per ogni riga m= in SDP). Se la negoziazione di una sessione multimediale fallisce, le altre POSSONO comunque avere successo.

Diversi profili RTP POSSONO essere utilizzati in diverse sessioni multimediali. Per la negoziazione di una descrizione multimediale, i quattro profili AVP, AVPF, SAVP e SAVPF si escludono a vicenda. Si noti, tuttavia, che le entità SAVP e SAVPF POSSONO essere mischiate in una singola sessione RTP (vedere la Sezione 4). Inoltre, il meccanismo di offerta/risposta PUÒ essere utilizzato per offrire alternative per la stessa sessione multimediale e consentire al rispondente di scegliere uno dei profili.

A condizione che diventi disponibile un meccanismo per offrire profili di sicurezza alternativi (come è attualmente in fase di sviluppo [14]), un offerente che è in grado di supportare più di uno di questi profili per una determinata sessione multimediale DOVREBBE sempre offrire tutte le alternative accettabili in una determinata situazione. Le alternative DOVREBBERO essere elencate in ordine di preferenza e l'offerente DOVREBBE preferire i profili sicuri rispetto a quelli non sicuri. L'offerta NON DOVREBBE includere sia un'alternativa sicura (SAVP e SAVPF) che un'alternativa non sicura (ad esempio, AVP e AVPF) nella stessa offerta in quanto ciò potrebbe consentire attacchi di bidding down (declassamento) e altri attacchi. Pertanto, se vengono offerti sia profili RTP sicuri che non sicuri (ad esempio, per SRTP best-effort [14]), la segnalazione di negoziazione DEVE essere protetta in modo appropriato per evitare tali attacchi.

Se un'offerta contiene più profili alternativi, il rispondente DOVREBBE preferire un profilo sicuro (se supportato) rispetto a quelli non sicuri. Tra i profili sicuri o non sicuri, il rispondente DOVREBBE selezionare la prima alternativa accettabile per rispettare la preferenza dell'offerente.

Se una descrizione multimediale in un'offerta utilizza SAVPF e il rispondente non supporta SAVPF, la sessione multimediale DEVE essere rifiutata.

Se una descrizione multimediale in un'offerta non utilizza SAVPF ma il rispondente desidera utilizzare SAVPF, il rispondente DEVE rifiutare la sessione multimediale. Il rispondente PUÒ fornire una contro-offerta con una descrizione multimediale che indichi SAVPF in uno scambio offerta/risposta avviato successivamente.

3.3.2. Negoziazione delle descrizioni di sessione basata su RTSP

L'RTSP [10] non supporta il modello offerta/risposta. Tuttavia, l'RTSP supporta lo scambio dei parametri della sessione multimediale (inclusi il profilo e le informazioni sull'indirizzo) per mezzo dell'intestazione Transport. La gestione delle chiavi basata su SDP, come definita nella RFC 4567 [7], aggiunge un'intestazione RTSP (KeyMgmt) per supportare la trasmissione di un protocollo di gestione delle chiavi (incluso il materiale delle chiavi).

L'intestazione RTSP Transport PUÒ essere utilizzata per determinare il profilo per la sessione multimediale. Concettualmente, le regole definite nella Sezione 3.3.1 si applicano di conseguenza. Il funzionamento dettagliato è il seguente: una descrizione SDP (ad esempio, recuperata dal server RTSP per mezzo di DESCRIBE) contiene la descrizione dei flussi multimediali della particolare risorsa RTSP.

Il client RTSP DEVE selezionare esattamente uno dei profili per flusso multimediale che desidera ricevere. DEVE farlo nella richiesta SETUP. Il client RTSP DEVE indicare il profilo RTP scelto indicando il profilo e l'indirizzo di trasporto completo del server (indirizzo IP e numero di porta) nell'intestazione Transport inclusa nella richiesta SETUP. La risposta del server RTSP al messaggio SETUP del client DEVE confermare questa selezione del profilo o rifiutare la richiesta SETUP (cosa che non dovrebbe fare dopo aver offerto i profili in primo luogo).

Nota: Per cambiare uno qualsiasi dei profili in uso, il client deve chiudere questo flusso multimediale (e possibilmente l'intera sessione RTSP) utilizzando il metodo TEARDOWN e ristabilirlo utilizzando SETUP. Questo potrebbe cambiare non appena verrà specificato l'aggiornamento dei media (simile a un SIP UPDATE o re-INVITE).

Quando si utilizza la gestione delle chiavi SDP [7], l'intestazione KeyMgmt DEVE essere inclusa nei messaggi RTSP appropriati se viene scelto un profilo sicuro. Se nella descrizione SDP vengono offerti diversi profili sicuri (ad esempio, SAVP e SAVPF) e per questi viene fornito materiale di chiavi diverso, dopo aver scelto un profilo nel messaggio SETUP, DEVE essere fornita solo l'intestazione KeyMgmt per quello scelto. Si applicano le regole per la corrispondenza delle intestazioni KeyMgmt ai flussi multimediali secondo la RFC 4567 [7].

3.3.3. Annuncio delle descrizioni di sessione

I protocolli che non consentono di negoziare le descrizioni di sessione in modo interattivo (ad esempio, SAP [11], descrizioni pubblicate su una pagina web o inviate per posta) pongono la responsabilità di un accesso adeguato alle sessioni multimediali sull'iniziatore di una sessione.

L'iniziatore DOVREBBE fornire descrizioni di sessione alternative per più profili RTP per quanto accettabile per l'applicazione e lo scopo della sessione. Se si desidera la sicurezza, il SAVP può essere offerto come alternativa al SAVPF — ma le sessioni AVP o AVPF NON DOVREBBERO essere annunciate a meno che non vengano impiegati altri mezzi di sicurezza che non facciano affidamento sull'SRTP.

Gli attributi SDP definiti nelle RFC 4567 [7] e RFC 4568 [8] possono anche essere utilizzati per la distribuzione dei parametri di sicurezza delle descrizioni di sessione annunciate.

La descrizione dello schema di sicurezza definita nella RFC 4568 [8] richiede un canale di comunicazione sicuro per impedire a terzi di intercettare i parametri di chiavi e di manipolarli. Pertanto, la sicurezza SAP (come definita nella RFC 2974 [11]), S/MIME [12], HTTPS [13] o altri meccanismi idonei DOVREBBERO essere utilizzati per distribuire o accedere a queste descrizioni di sessione.

3.3.4. Descrizione dei profili di sessione alternativi

Le entità SAVP e SAVPF POSSONO essere mischiate nella stessa sessione RTP (vedere anche la Sezione 4) e così pure le entità AVP e AVPF. Altre combinazioni — cioè tra profili sicuri e non sicuri — nella stessa sessione RTP sono incompatibili e NON DEVONO essere utilizzate insieme.

Se la negoziazione tra i peer coinvolti è possibile (come con il modello offerta/risposta per la Sezione 3.3.1 o l'RTSP per la Sezione 3.3.2), i profili alternativi (sicuri e non sicuri) POSSONO essere specificati da un'entità (ad esempio, l'offerente) e una scelta di un profilo DEVE essere fatta dall'altra. Se non è possibile alcuna negoziazione di questo tipo (ad esempio, con il SAP come per la Sezione 3.3.3), i profili incompatibili NON DEVONO essere specificati come alternative.

La negoziazione di profili alternativi è oggetto di ulteriore studio.

I profili RTP POSSONO essere mischiati arbitrariamente tra diverse sessioni RTP.

3.4. Esempi

Questa sezione include esempi per l'uso dell'SDP per negoziare l'uso di profili sicuri e non sicuri. A seconda di quale meccanismo di chiavi viene utilizzato e di come viene parametrizzato, i messaggi SDP in genere richiedono la protezione dell'integrità e, per alcuni meccanismi, avranno anche bisogno della protezione della riservatezza. Ad esempio, si potrebbe dire che la protezione dell'integrità è richiesta per l'a=fingerprint del Datagram Transport Layer Security - Secure Real-time Transport Protocol (DTLS-SRTP) [16], e la riservatezza è richiesta per la RFC 4568 [8] (Security Descriptions) a=crypto.

Esempio 1: La seguente descrizione di sessione indica una sessione sicura composta da audio e multifrequenza a doppio tono (DTMF) per la comunicazione punto a punto in cui il flusso DTMF utilizza NACK generici. Il protocollo di gestione delle chiavi indicato è MIKEY. Questa descrizione di sessione (l'offerta) potrebbe essere contenuta in un messaggio SIP INVITE o 200 OK per indicare che il suo mittente è in grado e disposto a ricevere feedback per il flusso DTMF che trasmette. La risposta corrispondente può essere portata in un 200 OK o in un ACK. I parametri per il protocollo di sicurezza sono negoziati come descritto dalle estensioni SDP definite nella RFC 4567 [7].

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...

Esempio 2: Questo esempio mostra gli stessi parametri di feedback dell'esempio 1 ma utilizza la sintassi delle descrizioni sicure [8]. Si noti che la parte chiave dell'attributo a=crypto non è protetta contro l'intercettazione e quindi la descrizione della sessione deve essere scambiata su un canale di comunicazione sicuro.

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=crypto:AES_CM_128_HMAC_SHA1_32
  inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1
  :32

Esempio 3: Questo esempio è replicato dall'esempio 1 sopra, ma mostra l'interazione tra l'offerente e il rispondente in uno scambio offerta/risposta, utilizzando nuovamente MIKEY per negoziare il materiale delle chiavi:

Offerta:

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack

Risposta:

v=0
o=alice 3203093521 3203093521 IN IP4 host.another.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.another.example.com
a=key-mgmt:mikey ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD...
m=audio 53012 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack

Esempio 4: Questo esempio mostra lo scambio per lo streaming video controllato tramite RTSP. Un client acquisisce una descrizione multimediale da un server utilizzando DESCRIBE e ottiene una descrizione SDP statica senza alcun parametro di chiavi, ma la descrizione multimediale mostra che sono disponibili sessioni multimediali sia sicure che non sicure utilizzando (S)AVPF. Un meccanismo che consente l'identificazione esplicita di queste alternative (ovvero, sessioni sicure e non sicure) nella descrizione della sessione è attualmente in fase di definizione [14]. Il client invia quindi una richiesta SETUP e indica la sua scelta includendo il rispettivo profilo nel parametro Transport. Inoltre, il client include un'intestazione KeyMgmt per trasmettere i suoi parametri di sicurezza, che è abbinata a una corrispondente intestazione KeyMgmt dal server nella risposta. Viene scelta una singola sessione multimediale in modo che l'URI RTSP aggregato sia sufficiente per l'identificazione.

Coppia richiesta-risposta RTSP DESCRIBE (opzionale):

DESCRIBE rtsp://movies.example.org/example RTSP/2.0
CSeq: 314
Accept: application/sdp

200 OK
CSeq: 314
Date: 25 Nov 2005 22:09:35 GMT
Content-Type: application/sdp
Content-Length: 316

v=0
o=alice 3203093520 3203093520 IN IP4 movies.example.com
s=Media with feedback
t=0 0
c=IN IP4 0.0.0.0
m=video 49170 RTP/SAVPF 96
a=rtpmap:96 H263-2000/90000
a=rtcp-fb:96 nack
m=video 49172 RTP/AVPF 96
a=rtpmap:96 H263-2000/90000
a=rtcp-fb:96 nack

Coppia richiesta-risposta RTSP SETUP

SETUP rtsp://movies.example.org/example RTSP/2.0
CSeq: 315
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
         data="uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnD..."

200 OK
CSeq: 315
Date: 25 Nov 2005 22:09:36 GMT
Session: 4711
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013";
           src_addr="192.0.2.15:60000"/"192.0.2.15:60001"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
         data="ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD..."
Accept-Ranges: NPT, SMPTE

Esempio 5: La seguente descrizione di sessione indica una sessione audio/video multicast (utilizzando PCMU per l'audio e H.261 o H.263+) con la sorgente video che accetta NACK generici per entrambi i codec e Reference Picture Selection per H.263. I parametri per il protocollo di sicurezza sono negoziati come descritto dalle estensioni SDP definite nella RFC 4567 [7], utilizzate a livello di sessione. Tale descrizione potrebbe essere stata trasmessa utilizzando il Session Announcement Protocol (SAP).

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
a=key-mgmt:mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/SAVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi