SIP - Il modello di offerta / risposta
L'uso di SDP con SIP è indicato nella risposta all'offerta SDP RFC 3264. Il tipo di corpo del messaggio predefinito in SIP è application/sdp.
La parte chiamante elenca le funzionalità multimediali che desidera ricevere in SDP, di solito in un INVITO o in un ACK.
La parte chiamata elenca le proprie capacità multimediali nella risposta 200 OK a INVITE.
Un tipico utilizzo SIP di SDP include i seguenti campi: versione, origine, oggetto, ora, connessione e uno o più supporti e attributi.
I campi oggetto e ora non vengono utilizzati da SIP ma sono inclusi per compatibilità.
Nello standard SDP, il campo oggetto è un campo obbligatorio e deve contenere almeno un carattere, suggerito come s = - se non c'è soggetto.
Il campo ora è generalmente impostato su t = 00. SIP utilizza i campi connessione, media e attributi per impostare le sessioni tra gli UA.
Il campo origine ha un uso limitato con SIP.
L'id di sessione viene solitamente mantenuto costante durante una sessione SIP.
La versione viene incrementata ogni volta che si modifica l'SDP. Se l'SDP inviato è invariato rispetto a quello inviato in precedenza, la versione rimane la stessa.
Poiché il tipo di sessione multimediale e il codec da utilizzare fanno parte della negoziazione della connessione, SIP può utilizzare SDP per specificare più tipi di media alternativi e per accettare o rifiutare selettivamente tali tipi di media.
La specifica offerta / risposta, RFC 3264, consiglia di utilizzare un attributo contenente a = rtpmap: per ogni campo media. Un flusso multimediale viene rifiutato impostando il numero di porta su zero per il campo multimediale corrispondente nella risposta SDP.
Esempio
Nell'esempio seguente, il chiamante Tesla vuole impostare una chiamata audio e video con due possibili codec audio e un codec video nell'SDP trasportato nell'INVITO iniziale -
v = 0
o = John 0844526 2890844526 IN IP4 172.22.1.102
s = -
c = IN IP4 172.22.1.102
t = 0 0
m = audio 6000 RTP/AVP 97 98
a = rtpmap:97 AMR/16000/1
a = rtpmap:98 AMR-WB/8000/1
m = video 49172 RTP/AVP 32
a = rtpmap:32 MPV/90000I codec sono referenziati dai numeri di profilo RTP / AVP 97, 98.
La parte chiamata Marry risponde alla chiamata, sceglie il secondo codec per il primo campo multimediale e rifiuta il secondo campo multimediale, desiderando solo la sessione AMR.
v = 0
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110
s = -
c = IN IP4 200.201.202.203
t = 0 0
m = audio 60000 RTP/AVP 8
a = rtpmap:97 AMR/16000
m = video 0 RTP/AVP 32Se questa chiamata solo audio non è accettabile, Tom invierà un ACK e poi un BYE per annullare la chiamata. Altrimenti, la sessione audio verrebbe stabilita e i pacchetti RTP scambiati.
Come illustra questo esempio, a meno che il numero e l'ordine dei campi multimediali non vengano mantenuti, la parte chiamante non saprebbe con certezza quali sessioni multimediali sono state accettate e rifiutate dalla parte chiamata.
Le regole di offerta / risposta sono riassunte nelle sezioni seguenti.
Regole per la generazione di un'offerta
Un'offerta SDP deve includere tutti i campi SDP obbligatori (questo include v =, o =, s =, c = e t =). Questi sono campi obbligatori in SDP.
Di solito include un campo media ( m = ) ma non è necessario. Le righe multimediali contengono tutti i codec elencati in ordine di preferenza. L'unica eccezione è che se l'endpoint supporta un numero enorme di codec, dovrebbe essere elencato il più probabile o il più preferito. Diversi tipi di media includono audio, video, testo, MSRP, BFCP e così via.
Regole per la generazione di una risposta
Una risposta SDP a un'offerta deve essere costruita secondo le seguenti regole:
La risposta deve avere lo stesso numero di m = righe nello stesso ordine della risposta.
I singoli flussi multimediali possono essere rifiutati impostando il numero di porta su 0.
Gli stream vengono accettati inviando un numero di porta diverso da zero.
I payload elencati per ogni tipo di supporto devono essere un sottoinsieme dei payload elencati nell'offerta.
Per i payload dinamici, non è necessario utilizzare lo stesso numero di payload dinamico in ciascuna direzione. Di solito, viene selezionato un solo payload.
Regole per la modifica di una sessione
Entrambe le parti possono avviare un altro scambio di offerte / risposte per modificare una sessione. Quando una sessione viene modificata, è necessario seguire le seguenti regole:
Il numero di versione della riga di origine ( o = ) deve essere lo stesso dell'ultimo inviato, il che indica che questo SDP è identico allo scambio precedente, oppure può essere incrementato di uno, che indica il nuovo SDP che deve essere analizzato.
L'offerta deve includere tutte le linee multimediali esistenti e devono essere inviate nello stesso ordine.
È possibile aggiungere ulteriori flussi multimediali alla fine dell'elenco di m = line.
Un flusso multimediale esistente può essere eliminato impostando il numero di porta su 0. Questa linea multimediale deve rimanere nell'SDP e in tutti i futuri scambi di offerte / risposte per questa sessione.
Chiamata in attesa
Un partecipante in una chiamata può mettere temporaneamente in attesa l'altro. Questo viene fatto inviando un INVITE con un SDP identico a quello dell'INVITO originale ma cona = sendonly attributo presente.
La chiamata viene resa nuovamente attiva inviando un altro INVITO con il a = sendrecvattributo presente. La figura seguente mostra il flusso di una chiamata in attesa.
