Gli indirizzi SIP, detti anche SIP URL (Uniform Resource Locator) o URI (Uni-form Resource Identifier), si presentano nella (Uni-forma sip: user@host, dove user pu`o essere un nome utente o un numero telefonico e host rappresenta un dominio, a cui si dovr`a associare (es. tramite un proxy o un redirect server) un indiriz-zo IP che individui l’attuale posizione dell’utente sulla rete. L’indirizindiriz-zo SIP di Bob potrebbe essere ad esempio sip: bob@domain.com. Ma bob@domain.com potrebbe essere anche il suo indirizzo e-mail. Risulta allora evidente come un utente possa utilizzare per un’applicazione SIP (es. VoIP) lo stesso indirizzo us-ato per la posta elettronica. Inoltre, come gi`a avviene per l’e-mail, anche per VoIP (o per altre applicazioni SIP) si pu`o pensare di inserire un collegamento ipertestuale in una pagina web in modo da poter essere facilmente contattati da chi lo desideri.
Richieste
Ecco come si presenta un tipico messaggio di richiesta SIP: INVITE sip:bob@domain.com SIP/2.0
Via: SIP/2.0/UDP 167.180.112.24:5060 From: sip:alice@wonderland.com To: sip:bob@domain.com Call-ID: a2e3a@wonderland.com CSeq: 34 INVITE Content-Type: application/sdp Content-Length: 885 c=IN IP4 167.180.112.24 m=audio 38060 RTP/AVP 0
La start line indica che il messaggio `e un invite, usato per avviare una sessione di comunicazione. Le altre informazioni in essa contenute riguardano il Request-URI, cio`e l’indirizzo SIP dell’utente da contattare (bob@domain.com) e la ver-sione del protocollo usata dal terminale che ha generato il messaggio (SIP/2.0). Il campo Via, che in questo caso `e relativo al terminale chiamante, pu`o essere pi`u di uno e serve a tenere traccia del percorso compiuto dalla richiesta. From e To identificano il chiamante e il chiamato. Call-ID `e, come sar`a pi`u chiaro in seguito, un identificativo di dialog: permette di individuare i messaggi appartenenti alla stessa chiamata. Content-Type definisce il contenuto del messaggio SIP (codi-ficato tipicamente in SDP) e Content-Length definisce la dimensione in byte di tale carico utile. Cseq, definendo un ordine tra i messaggi, favorisce la gestione delle ritrasmissioni. Un altro campo, assente nell’esempio ma spesso usato, `e Contact, con cui il chiamante indica al chiamato indirizzo IP e numero di porto su cui desidera essere contattato in futuro. Dopo la linea bianca di separazione troviamo il message-body codificato in SDP, con il quale, in questo caso, Alice d`a indicazioni riguardo al suo indirizzo IP e al formato audio preferito in ricezione. Altri parametri analoghi, relativi in particolare ai flussi multimediali scambiati e al protocollo di trasporto usato, possono essere negoziati nel corpo del messag-gio dai partecipanti alla sessione, tramite il protocollo SDP. Come visto, ci`o che caratterizza una richiesta `e la riga iniziale dell’intestazione, nota anche, in questo caso, come request line, che identifica un metodo di richiesta.
I metodi di richiesta fondamentali, definiti nella RFC 3261, sono: • INVITE • ACK • BYE • CANCEL • REGISTER • OPTIONS
Esaminiamone ora la semantica.
INVITE
Consente di invitare un utente a partecipare ad una sessione di comunicazione. Il chiamante pu`o specificare nel corpo del messaggio, codificato in SDP, il tipo di dati che `e in grado di ricevere (e.g. audio o video), le proprie preferenze riguardo al formato dei dati stessi, l’indirizzo IP su cui desidera riceverli e altri parametri della sessione.
ACK
Il chiamante invia un ACK per confermare al chiamato la ricezione di una risposta definitiva ad un precedente INVITE. Se tale risposta era positiva, si instaura cos`ı una sessione di comunicazione, grazie ad una procedura di handshake a tre vie. Il corpo dell’ACK pu`o contenere una descrizione della sessione nella usuale codifica SDP. In caso contrario, il chiamato deve considerare ancora validi i parametri di sessione presenti nell’INVITE ricevuto precedentemente.
BYE
Questo messaggio pu`o essere inviato indifferentemente dal chiamante o dal chiam-ato per terminare una sessione di comunicazione.
CANCEL
Con questo metodo un client pu`o annullare una precedente richiesta per la quale non ha ancora ricevuto una risposta definitiva. Ci`o avviene tipicamente in seguito all’invio di un INVITE che non riceve risposta per un certo tempo. Un proxy deve inoltrare una richiesta di CANCEL a tutte le destinazioni con richieste pendenti, mentre un redirect server si limita a rispondere con un codice di stato: 200 (OK) se l’operazione `e ancora in corso, 481 (Transaction Does Not Exist) altrimenti.
REGISTER
Un client pu`o ricorrere a questo metodo per registrare presso un registrar server l’utente specificato tramite l’indirizzo SIP presente nel campo To dell’intestazione. Tale utente pu`o essere lo stesso che ha chiesto la registrazione o un altro: in quest’ultimo caso si parla di third-party registration. Il registrar server estrae dal messaggio le informazioni (indirizzo IP e numero di porto) che definiscono la posizione attuale dell’utente nella rete e le memorizza in un location database, a cui accedono proxy e redirect server per localizzare gli utenti. Ogni registrazione ha una scadenza, che viene definita dal server nel campo Expires della risposta o richiesta dal client nello stesso campo della REGISTER, e pu`o essere aggiornata dall’utente che l’ha effettuata. Un UAC pu`o anche annullare esplicitamente una registrazione prima della scadenza stabilita, semplicemente inviando una REGIS-TER con uno 0 nel campo Expires; per deallocare contemporaneamente tutti gli indirizzi SIP associati all’utente, basta inserire un asterisco nel campo Contact del messaggio.
OPTIONS
Un client si pu`o servire di questo metodo per ottenere informazioni relative allo stato di un utente e alle funzionalit`a (e.g. metodi) da esso supportate. In par-ticolare, un chiamante pu`o verificare in questo modo la disponibilit`a dell’utente che ha intenzione di contattare ad accettare un INVITE.
Le primitive di richiesta fondamentali del protocollo SIP, chesono state qui breve-mente presentate, sono state estese con nuovi metodi da RFC successive alla 2543 (prima definizione del protocollo), o alla 3261 (definizione aggiornata che ha sostituito la precedente).
Risposte
Ogni richiesta SIP deve ricevere una risposta, fatta eccezione per le richieste di tipo ACK, che rappresentano le conferme nell’handshake a tre vie. Ecco un tipico esempio di risposta SIP:
SIP/2.0 200 OK Via: SIP/2.0/UDP 167.180.112.24:5060 From: sip:alice@wonderland.com To: sip:bob@domain.com Call-ID: a2e3a@wonderland.com CSeq: 34 INVITE Content-Type: application/sdp Content-Length: 0
Come si vede, il messaggio `e molto simile ad una richiesta se non per la start line, che presenta, oltre alla versione del protocollo, un codice di stato e una sua descrizione testuale. Si noti come i campi Via, From, To, Call-ID e CSeq abbiano lo stesso contenuto che avevano nella richiesta (riportata precedentemente): From e To non sono invertiti, come si potrebbe essere indotti a pensare. Ci`o consente ai server SIP di mettere la risposta in relazione con la richiesta, mentre la funzione di distinguere i due messaggi `e affidata alla prima riga dell’intestazione. I codici di stato, mutuati dall’HTTP, sono degli interi compresi tra 100 e 699 e identificano le risposte inviate da un server a un client. Essi si dividono in sei categorie, a seconda del contenuto informativo:
• INFORMATIONAL (1XX) • SUCCESSFUL (2XX) • REDIRECTION (3XX) • REQUEST FAILURE (4XX) • SERVER FAILURE (5XX) • GLOBAL FAILURE (6XX)
Vediamo ora la semantica delle diverse classi di risposte SIP.
INFORMATIONAL (1XX)
Si tratta di risposte provvisorie inviate ad un client per informarlo che una richi-esta `e stata ricevuta ma la relativa elaborazione non `e ancora terminata e quindi non `e disponibile al momento una risposta definitiva. In seguito alla ricezione di una riposta provvisoria, che viene generata oltre un tempo di attesa di 200 ms, il client `e tenuto ad astenersi da ritrasmissioni della richiesta e ad attendere ulteriori informazioni sull’esito dell’elaborazione.
SUCCESSFUL (2XX)
La richiesta `e stata accolta con successo. La risposta definitiva inviata dal server `
e 200 OK.
REDIRECTION (3XX)
Questa classe di risposte fornisce informazioni riguardanti la nuova posizione dell’utente o i servizi alternativi che potrebbero portare a buon fine la chiamata.
REQUEST FAILURE (4XX)
Si tratta di precise risposte di fallimento fornite da un determinato server. Il client non dovrebbe riformulare la richiesta senza modifiche (e.g. aggiungendo le autorizzazioni del caso). Tuttavia la stessa richiesta potrebbe avere successo se inviata ad un server diverso.
SERVER FAILURE (5XX)
Il fallimento della richiesta `e dovuto ad un errore del server.
GLOBAL FAILURE (6XX)
Il server ha informazioni definitive riguardo all’utente desiderato ma non quelle relative alla particolare richiesta effettuata.