1. Introduction (Introduzione)
1. Introduction (Introduzione)
Il Session Description Protocol (protocollo di descrizione di sessione, SDP) [1] fu concepito in origine come modo per descrivere sessioni multicast trasportate sul Mbone. Il Session Announcement Protocol (protocollo di annuncio di sessione, SAP) [6] fu ideato come meccanismo multicast per trasportare messaggi SDP. Sebbene la specifica SDP consenta il funzionamento in unicast, non è completa a tale riguardo. A differenza del multicast, in cui esiste una visione globale della sessione usata da tutti i partecipanti, le sessioni unicast coinvolgono due partecipanti, e una visione completa della sessione richiede informazioni da entrambi e un accordo sui parametri tra loro.
Ad esempio, una sessione multicast richiede di trasmettere un singolo indirizzo multicast per un determinato flusso multimediale. Per una sessione unicast, invece, servono due indirizzi, uno per ciascun partecipante. Come altro esempio, una sessione multicast richiede un'indicazione di quali codec saranno usati nella sessione. Per l'unicast, invece, l'insieme dei codec va determinato trovando l'intersezione tra gli insiemi supportati da ciascun partecipante.
Di conseguenza, pur avendo il SDP l'espressività per descrivere sessioni unicast, mancano la semantica e i dettagli operativi su come ciò si faccia in pratica. In questo documento rimediamo definendo un semplice modello offer/answer (offerta/risposta) basato su SDP. In questo modello, un partecipante alla sessione genera un messaggio SDP che costituisce l'offer: l'insieme di flussi multimediali e codec che l'offerer (offerente) desidera usare, insieme agli indirizzi IP e alle porte con cui l'offerer vorrebbe ricevere il media. L'offer viene comunicato all'altro partecipante, detto answerer (rispondente). L'answerer genera una answer (risposta), ossia un messaggio SDP che risponde all'offer fornito dall'offerer. La answer ha un flusso multimediale corrispondente per ogni flusso nell'offer, indicando se il flusso è accettato o meno, insieme ai codec che saranno usati e agli indirizzi IP e alle porte con cui l'answerer vuole ricevere il media.
È inoltre possibile che una sessione multicast funzioni in modo simile a una unicast: i suoi parametri sono negoziati tra una coppia di utenti come nel caso unicast, ma entrambe le parti inviano pacchetti allo stesso indirizzo multicast anziché a indirizzi unicast. Questo documento tratta anche dell'applicazione del modello offer/answer ai flussi multicast.
Definiamo inoltre linee guida su come il modello offer/answer sia usato per aggiornare una sessione dopo uno scambio iniziale offer/answer.
La modalità con cui vengono trasportate offer e answer è fuori dall'ambito di questo documento. Il modello offer/answer qui definito è il meccanismo di base obbligatorio usato dal Session Initiation Protocol (protocollo di iniziazione di sessione, SIP) [7].