5. Struttura del protocollo (Structure of the Protocol)
5 Struttura del protocollo (Structure of the Protocol)
SIP è strutturato come un protocollo a strati (layered protocol). Ciò significa che il suo funzionamento è descritto come un insieme di trattamenti piuttosto indipendenti, con accoppiamenti laschi tra le fasi. La descrizione del protocollo a strati è una comodità di presentazione, per consentire di descrivere le funzionalità comuni in un'unica sezione tra gli elementi. Ciò non prescrive in alcun modo l'implementazione. Il fatto che un elemento "contenga" uno strato significa che è conforme all'insieme di regole definito in quello strato.
Non tutti gli elementi specificati dal protocollo contengono tutte le strati. Inoltre, gli elementi specificati da SIP sono elementi logici, non fisici. Una realizzazione fisica può scegliere di combinare diversi elementi logici, forse persino scelti per transazione.
Lo strato più basso di SIP è la sua sintassi e codifica. La sua codifica è specificata utilizzando una grammatica estesa Backus-Naur Form (BNF). Il BNF completo è specificato nella Sezione 25. Una panoramica della struttura dei messaggi SIP è nella Sezione 7.
La seconda strato è la livello transport (transport layer). Essa definisce come un client invia una richiesta e riceve una risposta, e come un server riceve una richiesta e invia una risposta sulla rete. Tutti gli elementi SIP contengono la livello transport. La livello transport è descritta nella Sezione 18.
La terza strato è la livello transazione (transaction layer). Una transazione è il blocco costruttivo fondamentale di SIP. Una transazione consiste in una richiesta inviata dal client transaction (usando la livello transport) al server transaction, e in tutte le risposte a quella richiesta inviate dal server al client. La livello transazione gestisce le ritrasmissioni a livello di applicazione, la corrispondenza delle risposte alle richieste e le scadenze a livello di applicazione. Qualsiasi attività compiuta da un user agent client (UAC) è effettuata utilizzando una serie di transazioni. La discussione sulle transazioni si trova nella Sezione 17. Un user agent contiene la livello transazione, così come un proxy stateful. Un stateless proxy non contiene la livello transazione. La livello transazione ha un componente client (chiamato client transaction) e un componente server (chiamato server transaction), ciascuno espresso come una macchina a stati finiti (finite state machine) costruita per gestire una particolare richiesta.
Lo strato sopra la livello transazione è chiamato transaction user (TU). Ogni entità SIP, ad eccezione dello stateless proxy, è un transaction user. Quando un TU desidera inviare una richiesta, crea un'istanza di client transaction e le passa la richiesta, nonché l'indirizzo IP, la porta e il transport di destinazione a cui inviarla. Il TU che ha creato la client transaction può anche annullarla. Quando un client annulla una transazione, richiede al server di cessare qualsiasi ulteriore elaborazione e di tornare allo stato precedente l'avvio della transazione, generando una risposta di errore particolare per quella transazione. Ciò avviene tramite una richiesta CANCEL, che costituisce essa stessa una transazione, ma fa riferimento alla transazione annullata (Sezione 9).
Gli elementi SIP, vale a dire user agent client e server, proxy stateless e stateful, e registrar, contengono un core che li distingue. Ad eccezione dello stateless proxy, il core è un transaction user. Le regole del core per UAC e UAS dipendono dal method, ma ci sono alcune regole comuni a tutti i method (Sezione 8). Per il UAC, queste regole governano la costruzione delle richieste. Per il UAS, esse governano l'elaborazione delle richieste e la generazione delle risposte. Poiché la registrazione svolge un ruolo importante in SIP, il UAS che elabora REGISTER riceve un nome speciale, registrar. La Sezione 10 descrive il comportamento del core UAC e UAS del method REGISTER. La Sezione 11 descrive il comportamento del core UAC e UAS del method OPTIONS, usato per determinare le capacità di un UA.
Alcune altre richieste sono inviate in un dialog. Un dialog è una relazione SIP peer-to-peer tra due user agent che persiste per un certo tempo. Un dialog facilita l'ordinamento dei messaggi e il routing appropriato delle richieste tra user agent. Il method INVITE è l'unico definito in questa specifica per stabilire un dialog. Quando un UAC invia una richiesta nel contesto di un dialog, segue le regole comuni UAC discusse nella Sezione 8, nonché le regole per le richieste in un dialog. La Sezione 12 discute i dialog, presentando le loro procedure di costruzione e manutenzione, nonché la costruzione di richieste in un dialog.
Il method SIP più importante è INVITE, usato per stabilire una session tra i partecipanti. Una session è un insieme di partecipanti e flussi multimediali tra loro, allo scopo di comunicare. La Sezione 13 discute come una session inizia e diventa uno o più dialog SIP. La Sezione 14 discute come le caratteristiche di questa session sono modificate tramite l'uso di richieste INVITE in un dialog. Infine, la Sezione 15 discute come una session termina.
Le procedure delle Sezioni 8, 10, 11, 12, 13, 14 e 15 trattano solo il core UA (la Sezione 9 descrive l'annullamento, applicabile al core UA e proxy). La Sezione 16 discute l'elemento proxy, che facilita il routing dei messaggi tra user agent.