4. Panoramica del funzionamento (Overview of Operation)
4 Panoramica del funzionamento (Overview of Operation)
Questa sezione introduce le funzioni di base di SIP utilizzando un semplice esempio. Questa sezione ha carattere tutoriale e non contiene alcuna frase normativa.
Il primo esempio mostra la funzionalità di base di SIP: il rilevamento degli endpoint, la segnalazione dell'intenzione di comunicare, la negoziazione dei parametri di session per stabilire una session e lo smantellamento (teardown) della session stabilita.
La Figure 1 mostra un tipico scambio di messaggi SIP tra due utenti, Alice e Bob. (Ogni messaggio è etichettato con una lettera "F" e un numero per riferimento dal testo.) In questo esempio, Alice usa un'applicazione SIP sul suo PC (chiamata softphone) per chiamare il telefono SIP di Bob su Internet. Due server proxy SIP che agiscono per Alice e Bob sono anch'essi mostrati. Questo tipico arrangiamento è spesso chiamato "trapezio SIP (SIP trapezoid)" dalla forma geometrica tratteggiata nella Figure 1.
Alice "chiama" Bob usando la sua identità SIP, un tipo di Uniform Resource Identifier (URI) chiamato SIP URI. Un SIP URI è definito nella Sezione 19.1. Il suo formato assomiglia a un indirizzo e-mail e contiene generalmente un nome utente e un nome host. In questo caso, è sip:[email protected], dove biloxi.com è il dominio del fornitore di servizi SIP di Bob. Il SIP URI di Alice è sip:[email protected]. Alice potrebbe aver inserito l'URI di Bob o fatto clic su un collegamento ipertestuale o un elemento della rubrica. SIP fornisce anche un URI sicuro chiamato SIPS URI. Un esempio è sips:[email protected]. Una chiamata a un SIPS URI garantisce che tutti i messaggi SIP dal richiedente al dominio del chiamato siano trasportati usando un transport sicuro e cifrato (cioè TLS). Da lì, la richiesta è inviata in modo sicuro al chiamato, ma il meccanismo di sicurezza dipende dalla politica del dominio del chiamato.
SIP si basa su un modello di transazione request/response simile a HTTP. Ogni transazione consiste in una richiesta che invoca un metodo (o funzione) particolare su un server, e almeno una risposta. In questo esempio, la transazione inizia quando lo softphone di Alice invia una richiesta INVITE all'SIP URI di Bob. INVITE è un esempio di metodo SIP che specifica l'azione che il richiedente (Alice) vuole che il server (Bob) esegua. La richiesta INVITE (messaggio F1 nella Figure 1) contiene diversi header field. Gli header field forniscono attributi denominati che danno informazioni aggiuntive sul messaggio. L'INVITE contiene: un identificatore di chiamata univoco, l'indirizzo di destinazione, l'indirizzo di Alice e informazioni sul tipo di session che Alice desidera stabilire con Bob. L'INVITE (messaggio F1 nella Figure 1) appare così:
atlanta.com . . . biloxi.com
. proxy proxy .
. .
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
softphone SIP Phone
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 Trying F3 |--------------->| INVITE F4 |
|`<---------------| 100 Trying F5 |--------------->`|
| |\<-------------- | 180 Ringing F6 |
| | 180 Ringing F7 |\<---------------|
| 180 Ringing F8 |\<---------------| 200 OK F9 |
|\<---------------| 200 OK F10 |\<---------------|
| 200 OK F11 |\<---------------| |
|\<---------------| | |
| ACK F12 |
|------------------------------------------------->|
| Media Session |
|`<================================================>`|
| BYE F13 |
|\<-------------------------------------------------|
| 200 OK F14 |
|------------------------------------------------->|
| |
Figure 1: SIP session setup example with SIP trapezoid
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob `<sip:[email protected]>`
From: Alice `<sip:[email protected]>`;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: `<sip:[email protected]>`
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
La prima riga del messaggio codificato come testo contiene il nome del method (INVITE). Le righe successive sono l'elenco degli header field. Questo esempio contiene il set minimo richiesto. Gli header field sono brevemente spiegati di seguito.
Via contiene l'indirizzo (pc33.atlanta.com) dove Alice si aspetta di ricevere la risposta a questa richiesta. Contiene anche un parametro branch che identifica questa transazione.
To contiene il display name (Bob) e l'URI SIP o SIPS (sip:[email protected]) verso cui la richiesta è stata inizialmente diretta. Il display name è descritto in RFC 2822 [3].
From contiene anch'esso il display name (Alice) e l'URI SIP o SIPS (sip:[email protected]) che indica l'iniziatore della richiesta. Questo header field ha anche un parametro tag contenente una stringa casuale (1928301774) aggiunta dal softphone all'URI, usata a scopi di identificazione.
Call-ID contiene un identificatore univoco globalmente di questa chiamata, generato combinando una stringa casuale e il nome host o l'indirizzo IP del softphone. La combinazione di To tag, From tag e Call-ID definisce completamente la relazione peer-to-peer SIP tra Alice e Bob, chiamata dialog.
CSeq (Command Sequence) contiene un intero e il nome del method. Il numero CSeq è incrementato per ogni nuova richiesta in un dialog; è una sequenza classica.
Contact contiene un URI SIP o SIPS che rappresenta una rotta per raggiungere direttamente Alice, generalmente composto da un nome utente su un fully qualified domain name (FQDN). Il FQDN è raccomandato, ma molti sistemi terminali non hanno un nome di dominio registrato, quindi anche gli indirizzi IP sono ammessi. Il campo header Via indica agli altri elementi dove inviare la risposta, mentre il campo header Contact indica agli altri elementi dove inviare le richieste future.
Max-Forwards limita il numero di hop che la richiesta può attraversare prima di raggiungere la destinazione. È costituito da un intero, decrementato di uno a ogni hop.
Content-Type contiene la descrizione del corpo del messaggio (qui non mostrato).
Content-Length contiene il numero di ottetti (byte) del corpo del messaggio.
L'insieme completo degli header field SIP è definito nella Sezione 20.
I dettagli del tipo di session, codec o tasso di campionamento non sono descritti usando SIP. Invece, il corpo di un messaggio SIP contiene una descrizione di session codificata in un altro formato di protocollo. Un tale formato è il Session Description Protocol (SDP) (RFC 2327 [1]). Questo messaggio SDP (non mostrato nell'esempio) è trasportato dal messaggio SIP nello stesso modo in cui un messaggio e-mail trasporta un allegato o un messaggio HTTP trasporta una pagina web.
Poiché lo softphone non conosce né la posizione di Bob né il server SIP nel dominio biloxi.com, lo softphone invia l'INVITE al server SIP che fornisce un servizio nel dominio atlanta.com di Alice. L'indirizzo del server SIP atlanta.com potrebbe essere stato configurato sullo softphone di Alice o scoperto tramite DHCP, per esempio.
Il server SIP atlanta.com è un tipo di server SIP chiamato proxy server. Un proxy server riceve le richieste SIP e le inoltra per conto del richiedente. In questo esempio, il proxy server riceve la richiesta INVITE e restituisce una risposta 100 (Trying) allo softphone di Alice. La risposta 100 (Trying) indica che l'INVITE è stata ricevuta e il proxy la sta instradando verso la destinazione per conto di Alice. Le risposte SIP usano un codice a tre cifre seguito da una frase. Questa risposta contiene lo stesso To, From, Call-ID, CSeq e il parametro branch in Via della INVITE, così che lo softphone di Alice possa associare la risposta alla INVITE inviata. Il proxy server atlanta.com trova il proxy server biloxi.com, probabilmente eseguendo un particolare tipo di ricerca DNS (Domain Name Service) per trovare il server SIP che fornisce un servizio nel dominio biloxi.com, descritto in [4]. Ottiene l'indirizzo IP del proxy server biloxi.com e vi inoltra (o proxy) la richiesta INVITE. Prima di inoltrare la richiesta, il proxy server atlanta.com aggiunge un ulteriore valore di campo header Via contenente il proprio indirizzo (l'INVITE conteneva già l'indirizzo di Alice nel primo Via). Il proxy server biloxi.com riceve l'INVITE e restituisce una risposta 100 (Trying) al proxy server atlanta.com, indicando che ha ricevuto l'INVITE e la sta elaborando. Il proxy server consulta un database chiamato location service contenente l'indirizzo IP attuale di Bob. (La configurazione di questo database è mostrata nella sezione seguente.) Il proxy server biloxi.com aggiunge un altro valore di campo Via contenente il proprio indirizzo all'INVITE e la proxya al telefono SIP di Bob.
Il telefono SIP di Bob riceve l'INVITE, informa Bob della chiamata in arrivo da Alice e gli permette di decidere se rispondere (cioè, se il telefono di Bob suona). Il telefono SIP di Bob indica ciò con una risposta 180 (Ringing), che è instradata all'indietro attraverso i due proxy. Ogni proxy usa il campo Via per determinare dove inviare la risposta e rimuove il proprio indirizzo dall'inizio. Così, sebbene la ricerca iniziale dell'INVITE abbia richiesto ricerche DNS e nel location service, la risposta 180 (Ringing) può essere rispedita al richiedente senza ricerca e senza stato sul proxy. Questo ha anche la proprietà desiderabile che ogni proxy che vede l'INVITE veda anche tutte le risposte a tale INVITE.
Quando lo softphone di Alice riceve la risposta 180 (Ringing), informa Alice, probabilmente riproducendo un tono di ringback o mostrando un messaggio sullo schermo.
In questo esempio, Bob decide di rispondere. Quando solleva la cornetta, il suo telefono SIP invia una risposta 200 (OK) che indica che la chiamata è stata risposta. Il 200 (OK) contiene un corpo di messaggio con la descrizione media SDP del tipo di session che Bob desidera stabilire con Alice. Così, si verifica uno scambio SDP in due fasi: Alice ne invia uno a Bob, e Bob ne invia uno ad Alice. Questo scambio in due fasi fornisce una funzione di negoziazione di base basata sul semplice modello offer/answer dello scambio SDP. Se Bob non desidera rispondere o è occupato su un'altra chiamata, viene inviata una risposta di errore invece del 200 (OK), e la session media non viene stabilita. L'elenco completo dei codici di risposta SIP è nella Sezione 21. Il 200 (OK) (messaggio F9 nella Figure 1) inviato da Bob appare così:
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob `<sip:[email protected]>`;tag=a6c85cf
From: Alice `<sip:[email protected]>`;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: `<sip:[email protected]>`
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
La prima riga della risposta contiene il codice di risposta (200) e la reason phrase (OK). Le righe rimanenti contengono gli header field. I campi Via, To, From, Call-ID e CSeq sono copiati dalla richiesta INVITE. (Ci sono tre valori di campo Via - uno aggiunto dal telefono SIP di Alice, uno dal proxy atlanta.com, e uno dal proxy biloxi.com.) Il telefono SIP di Bob ha aggiunto un parametro tag al campo To. Questo tag è incorporato nel dialog da entrambe le estremità ed è incluso in tutte le richieste e risposte future di questa chiamata. Il campo Contact contiene l'URI dove il telefono SIP di Bob può essere raggiunto direttamente. Content-Type e Content-Length si riferiscono al corpo del messaggio contenente le informazioni media SDP di Bob (non mostrato).
Oltre alle ricerche DNS e location service illustrate in questo esempio, un proxy server può prendere "decisioni di routing" flessibili per determinare dove inviare una richiesta. Per esempio, se il telefono SIP di Bob restituisce una risposta 486 (Busy Here), il proxy server biloxi.com può proxare l'INVITE al server di casella vocale (voicemail) di Bob. Un proxy può anche inviare l'INVITE a più luoghi simultaneamente. Questo tipo di ricerca parallela è chiamato forking.
In questo caso, il 200 (OK) è instradato all'indietro attraverso i due proxy e ricevuto dallo softphone di Alice, che interrompe il ringback per indicare che la chiamata è stata risposta. Infine, lo softphone di Alice invia un messaggio di conferma ACK al telefono SIP di Bob per confermare la ricezione della risposta finale (200 (OK)). In questo esempio, l'ACK aggira i due proxy ed è inviato direttamente dallo softphone di Alice al telefono SIP di Bob, poiché le estremità hanno appreso i loro indirizzi reciproci tramite il campo Contact nello scambio INVITE/200 (OK), che non era noto al momento dell'invio della INVITE iniziale. Le ricerche effettuate dai due proxy non sono più necessarie, quindi i proxy escono dal flusso di chiamata. Ciò completa la stretta di mano a tre vie INVITE/200/ACK usata per stabilire una session SIP. I dettagli completi dell'instaurazione di session sono nella Sezione 13.
La session media di Alice e Bob inizia e inviano pacchetti media nel formato concordato nello scambio SDP. Generalmente, i pacchetti media end-to-end prendono un percorso diverso dai messaggi di segnalazione SIP.
Durante la session, uno di Alice o Bob può decidere di modificare le caratteristiche della session media. Ciò avviene inviando un re-INVITE contenente una nuova descrizione media. Poiché il re-INVITE fa riferimento a un dialog esistente, l'altra parte sa che si tratta di modificare una session esistente piuttosto che stabilirne una nuova. L'altra parte invia un 200 (OK) per accettare la modifica. Il richiedente risponde al 200 (OK) con un ACK. Se l'altra parte non accetta la modifica, invia una risposta di errore come 488 (Not Acceptable Here), che riceve anch'essa un ACK; ma il fallimento del re-INVITE non comporta il fallimento della chiamata esistente - la session continua con le caratteristiche precedentemente negoziate. I dettagli completi della modifica di session sono nella Sezione 14.
Alla fine della chiamata, Bob riaggancia per primo, generando un messaggio BYE. Questo BYE aggira anch'esso i proxy ed è instradato direttamente allo softphone di Alice. Alice conferma la ricezione del BYE con una risposta 200 (OK), terminando così la session e la transazione BYE. Non viene inviato alcun ACK - un ACK viene inviato solo in risposta a una risposta a una richiesta INVITE. Questa gestione speciale della INVITE è spiegata più avanti, ma è legata al meccanismo di affidabilità di SIP, al tempo che impiega un telefono per rispondere e al forking. Pertanto, l'elaborazione delle richieste SIP è spesso classificata come INVITE o non-INVITE (riferendosi a tutti i method tranne INVITE). I dettagli completi della fine di session sono nella Sezione 15.
La Sezione 24.2 descrive completamente i messaggi della Figure 1.
In alcuni casi, è utile che un proxy sul percorso di segnalazione SIP possa vedere tutti i messaggi tra le estremità durante la session. Per esempio, se il proxy server biloxi.com desidera rimanere sul percorso di segnalazione SIP dopo l'INVITE iniziale, aggiunge un campo header di routing obbligatorio chiamato Record-Route contenente un URI risolto nel suo nome host o nel suo indirizzo IP. Queste informazioni sono ricevute dal telefono SIP di Bob e (poiché il Record-Route è rispedito nel 200 (OK)) dallo softphone di Alice, e conservate per la durata del dialog. Il proxy server biloxi.com riceve quindi e proxya l'ACK, il BYE e il 200 (OK) sul BYE. Ogni proxy decide indipendentemente se ricevere i messaggi successivi, e questi passano attraverso tutti i proxy che hanno scelto di riceverli. Questa funzionalità è spesso usata per i proxy che forniscono funzioni mid-call.
La registrazione (registration) è un'altra operazione comune di SIP. La registrazione è uno dei modi in cui il server biloxi.com conosce la posizione attuale di Bob. All'inizializzazione e a intervalli regolari, il telefono SIP di Bob invia un messaggio REGISTER al registrar nel dominio biloxi.com. Il messaggio REGISTER associa l'SIP o SIPS URI di Bob (sip:[email protected]) alla macchina su cui è attualmente collegato (comunicata come URI SIP o SIPS nel campo Contact). Il registrar scrive questa associazione (anche chiamata binding) in un database chiamato location service, utilizzabile dal proxy nel dominio biloxi.com. Spesso, il server registrar di un dominio è colocalizzato con il suo proxy. È importante capire che la distinzione tra i server SIP è logica e non fisica.
Bob non è limitato a una registrazione da un singolo dispositivo. Per esempio, sia il suo telefono SIP domestico che quello da ufficio possono inviare registrazioni. Queste informazioni sono memorizzate insieme nel location service, permettendo al proxy di eseguire vari tipi di ricerca per trovare Bob. Allo stesso modo, più utenti possono essere registrati simultaneamente su un singolo dispositivo.
Il location service è un'astrazione. Esso contiene generalmente informazioni che consentono a un proxy, inserendo un URI, di ricevere un insieme di zero o più URI che indicano dove inviare la richiesta. La registrazione è un modo per creare queste informazioni, ma non l'unico. Qualsiasi funzione di mappatura può essere configurata a discrezione dell'amministratore.
Infine, è importante notare che in SIP la registrazione è usata per il routing delle richieste SIP in arrivo e non ha alcun ruolo nell'autorizzazione delle richieste in uscita. L'autorizzazione e l'autenticazione sono gestite in SIP tramite un meccanismo challenge/response per richiesta, o usando schemi di livello inferiore descritti nella Sezione 26.
I dettagli completi dei messaggi SIP per questo esempio di registrazione sono nella Sezione 24.1.
Altre operazioni SIP, come l'interrogazione delle capacità di un server o client SIP con OPTIONS, o l'annullamento di una richiesta in sospeso con CANCEL, sono presentate nelle sezioni seguenti.