|
1) Introduzione
Ci sono molte applicazioni in internet che richiedono l'instaurazione di una sessione e la sua gestione. Una sessione è considerata uno scambio di dati tra più partecipanti. Le implementazioni di queste applicazioni sono complicate dalle abitudini che hanno i partecipanti: gli user possono spostarsi tra più end point, possono essere contattati attraverso più nomi, e possono comunicate attraverso differenti media, qualche volta simultaneamente. Numerosi protocolli sono stati creati per trasportare le varie forme di trasmissioni multimediali real-time come video, voce, o messaggi di testo. Il Session Initiation Protocol (SIP) lavora con questi protocolli per permettere agli endpoints(called user agent) di trovarsi l'uno con l'altro e accordarsi sul tipo di sessione che vogliono instaurare. Per localizzare i potenziali partecipanti alle sessioni, e per altre funzioni, il SIP permette la creazione di un infrastruttura di server (chiamata proxy servers) a cui l'utente può inviare richieste di registrazione, instaurazione di sessione ed altro. Il SIP è un potente mezzo per creare, modificare e terminare sessioni indipendentemente dal trasport protocol e senza dipendere dal tipo di sessione che sarà stabilita.
2)Anteprima delle
funzionalità del SIP
Il SIP è un'application layer protocol che stabilisce,
modifica e termina sessioni multimediali come una chiamata telefonica. Il SIP
può anche invitare partecipanti a una sessione già esistente, come in una
conferenza. I media possono essere aggiunti e rimossi da una sessione
esistente. Il SIP supporta trasparentemente la mappatura per nomi e il servizio
di redirect, che permettono la personal mobility.
Il Sip supporta cinque caratteristiche di creazione e
terminata delle chiamate:
User location: determina se l'end
user è disponibile per la comunicazione;
User availability: determina la disponibilità del called party a instaurare la
comunicazione;
User capabilities: determina i media parameters da usare;
Session setup: "ringing", stabilisce i parametri della sessione che devono
usare entrambi i chiamanti;
Session management: include il trasferimento e il termine della sessione,
modifica dei parametri di sessione, e invocazione dei servizi.
Il SIP non è un sistema di comunicazione verticale,
piuttosto il SIP è un componente che può essere utilizzato con altri protocolli
per costruire un'architettura multimediale completa. Tipicamente,
quest'architettura include protocolli come il Real-time Trasport Protoco (RTP)
per trasportare i dati in tempo reale e fornire Quality of Service, il
Real-time streaming protocol(RTSP) per controllare la consegna dello streaming,
il Media Gateway Control Protocol (MEGACO) per controllare i gateways alla rete
telefonica pubblica (PSNT), e il Session Description Protocol (SDP) per
descrivere le sessioni multimediali. Per cui, il SIP se è usato con altri
protocolli è in grado di fornire un servizio completo agli utenti. Comunque, le
funzionalità base e operative del SIP non dipendono da nessuno di questi
protocolli.
Il SIP non fornisce servizi. Piuttosto, il SIP fornisce le
basi che possono essere usate per implementare differenti servizi. Per esempio,
il SIP può localizzare un utente e consegnare ad esso un qualunque oggetto
nella sua posizione attuale. Se queste basi sono usate per trasmettere la
descrizione di una session scritta con l'SDP, per instaurarla, l'end point può
accordarsi sull'impostazione dei parametri della sessione. Se le stesse basi
sono utilizzate per consegnare una foto del chiamante, per descrivere meglio la
sessione, un "caller ID" service può essere facilmente implementato. Questo
esempio mostra, una singola base tipicamente usata per fornire diversi servizi.
Il SIP non fornisce un servizio di controllo delle
conferenze, ma può essere usato per inizializzare una sessione che usa altri
conference control protocol.
La natura del servizio fornito dà alla sicurezza particolare
importanza. Il SIP fornisce una suite di servizi relativi alla sicurezza, che
includono il denial-of-service prevention, autenticazione (da utente a utente e
da proxy a utente), protezione dell'integrità, encryption e servizi per la
privacy.
Il SIP lavora sia con Ipv4 che Ipv6
3) Panoramica
dell'operatività
Questa sezione introduce le operazioni base del SIP
utilizzando dei semplici esempi.
Il primo esempio mostra le funzioni base del SIP: localizzazione di un end
point, segnalazione di una richiesta di comunicazione, negoziazione dei
parametri di sessione per stabilire la sessione, e la distruzione della
sessione una volta stabilita.
La figura 1 mostra un tipico esempio di un messaggio SIP scambiato tra due
user, Alice e Bob. (Ciascun messaggio è etichettato con la lettera "F" e un
numero per il riferimento del testo.) In questo esempio Alice usa
un'applicazione SIP sul suo PC (un softphone) per chiamare Bob sul suo SIP
phone, attraverso internet. Mostra anche due SIP proxy server che facilitano
l'instaurazione della sessione tra Alice e Bob.
Alice chiama Bob usando la sua SIP identity, un tipo di Uniform Resouce
Identifier (URI) chiamata SIP URI. Questa ha una forma simile all'indirizzo
email, tipicamente contiene un username e un hostname. In questo caso è
sip:bob@biloxi.com, dove biloxi.com è il dominio del ISP di Bob. Alice ha come
SIP URI sip:alice@atlanta.com. Alice ha digitato l'URI di Bob o ha cliccato su
un hyperlink nella sua rubrica. Il SIP fornisce anche un secure URI chiamato
SIPS URI. Un esempio può essere sips:bob@biloxi.com Una chiamata fatta a un
SIPS URI garantisce la sua sicurezza, è usato un trasporto criptato( chiamato
TLS) per trasportare tutti i messaggi SIP da chiamante al chiamato. Perciò la
richiesta è mandata in modo sicuro al chiamato, ma con meccanismi di sicurezza
che dipendono dalle policy implementate sul dominio del chiamato.
Il SIP è basato su un modello di transazione
richiesta/risposta HTTP-like. Ciascuna transazione consiste in una richiesta
che invoca un metodo particolare, o funzione, su un server e riceve almeno una
risposta. In questo esempio, la transazione comincia con il softphone di Alice
che invia una richiesta INVITE al SIP URI di Bob. INVITE è un esempio di un
metodo SIP che specifica l'azione che il richiedente (Alice) vuole che il
server (Bob) compia. La richiesta INVITE contiene un numero di campi header. I
campi Header sono chiamati attributi e forniscono informazioni addizionali
riguardo il messaggio. In questo esempio l'INVITE contiene un identificativo
univoco per la chiamata, l'indirizzo di destinazione, l'indirizzo di Alice, e
le informazioni riguardanti il tipo di sessione che Alice vuole stabilire con
Bob. L'INVITE message è questo (il messaggio F1 della Figura 1):
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
La prima riga del messaggio contiene il metodo chiamato
INVITE. Le righe che lo seguono sono una lista dei campi dell'header. Questo
esempio ne contiene il minimo indispensabile. I campi dell'header sono
brevemente spiegati qui sotto:
Via: contiene
l'indirizzo (pc33.atlanta.com) dove Alice si aspetta di ricevere il messaggio
di risposta. Contiene anche il parametro branch
che identifica la transazione
To contiene un nome (Bob) e
l'indirizzo SIP o SIPS (sip:bob@boòpxo.com) verso cui la richiesta originale
era diretta.
From: anche qui è contenuto un nome
(Alice) e un indirizzo SIP o SIPS.(sip:alice@atlanta.com) che indica
l'originario della richiesta. Questo campo dell'header ha un parametro tag che
contiene una stringa randomica (192831774) che viene aggiunta all'indirizzo dal
softphone. E' utilizzata per funzioni di identificazione
Call-ID: contiene l'identificativo
globale di questa chiamata, generato dalla combinazione di una stringa casuale
e dal softphone hostname o dall'indirizzo IP. La combinazione del To tag, From
tag e Call-ID definiscono completamente la relazione SIP punto-punto tra Alice
e Bob.
Cseq: o Command Sequence contiene un
intero e il nome di un metodo. Il numero CSeq è incrementale per ogni nuova
richiesta di dialogo.
Contact: contiene un indirizzo SIP o
SIPS che rappresentano un percorso diretto per contattare Alice, di solito è
composto da un username e un fully qualified domain name(FQDN). Benché gli FQDM sono preferibili, molti sistemi non
hanno registrato nessun domain name, così sono permessi anche gli indirizzi IP.
Mentre il campo Via dice dove mandare la risposta, il campo Contact informa su
dove mandare le richieste future.
Max-Forwards serve a limitare il
numero di hops che una richiesta può attraversare per giungere a destinazione.
Questo consiste in un numero intero che viene decrementato di uno da ciascun
hop.
Content-Type contiene una descrizione
del corpo del messaggio(non mostrato)
Contect-Lenght: informa della
lunghezza del messaggio, il campo è di 1 byte
I dettagli della sessione, così come il tipo di media, il
codec, o il sampling rate, non sono forniti usando il SIP. Il campo body del
messaggio SIP contiene una descrizione della sessione, codificata in altri
protocolli. Uno di questi protocolli è il Session Descritpion Protocol (SDP).
Questo messaggio SDP (non mostrato nell'esempio) è trasportato dal messaggio
SIP in un modo molto simile a come viaggiano i documenti allegati nelle mail, o
come le pagine web sono trasportate in un messaggio in http.
Dal softphone non conosciamo la posizione di Bob o il SIP server nel dominio
biloxi.com, il softphone invia l'INVITE al SIP server che serve il dominio di
Alice, atlanta.com. L'indirizzo del SIP server di atlanta.com deve essere
configurato nel softphone di Alice, o deve essere passato tramite DHCP.
Il SIP server di atlanta.com è un tipo di server conosciuto
come proxy server. Un proxy server riceve le richieste SIP e le gira al
destinatario. In questo esempio, il proxy server riceve una richiesta INVITE e
invia in risposta un 100 (Trying) al softphone di Alice. La risposta
100(Trying) indica che l'INVITE è stato ricevuto e che il proxy sta girando
l'INVITE a destinazione. La risposta nel SIP è un codice di 3 cifre seguito da
una frase descrittiva. Questa risposta contiene gli stessi parametri To, From,
Call-ID, Cseq e branch e il VIA del messaggio INVITE , questo per far
relazionare al softphone questa risposta con l'INVITE mandato. Il proxy server
di atlanta.com localizza il proxy server del dominio biloxi.com, effettuando
una particolare tipo di DNS Lookup per trovare il SIP server che fornisce
servizi nel dominio biloxi.com. Come risultato, questo ottiene l'indirizzo IP
del proxy server di biloxi.com e gira(forward), o proxies, a lui la richiesta
INVITE. Prima di girare la richiesta, il proxy server di atlanta.com aggiunge
un campo Via nell'header che contiene il suo indirizzo (l'INVITE già contiene
un l'indirizzo di Alice nell'header). Il server proxy di biloxi.com riceve
l'invito e risponde con un 100(Trying) al proxy di atlanta.com che indica che
sta processando la richiesta. Il proxy server consulta il database,
generalmente ha un servizio di localizzazione, che contiene l'indirizzo IP di
Bob. Il server di biloxi.com aggiunge un altro campo Via all'header con il
proprio indirizzo all'INVITE e lo gira(proxies) al telefono SIP di Bob.
Il telefono SIP di Bob riceve l'invito e avverte Bob di una
chiamata in entrata da parte di Alice così Bob può decidere se rispondere,
questo significa che il telefono squilla. Il telefono SIP di Bob per indicarlo
risponde con il messaggio 180(Ringing), che è inviato all'indietro attraverso i
2 proxy. Ciascun Proxy usa il campo Via dell'header per determinare dove
mandare la risposta e rimuove il suo indirizzo Ip da essa. In questo modo il
messaggio 180(Ringing) torna al chiamante.
Quando il Softphone di Alice riceve il messaggio di risposta
180(Ringing), questo passa questa informazione ad Alice, facendo il suono di
libero o mostrando un messaggio sul display.
In questo esempio, Bob deicide di rispondere alla chiamata.
Quando alza la cornetta, il suo SIP phone manda un messaggio di risposta con
200 (OK) che indica che la chiamata ha ricevuto risposta. Il 200 (OK) contiene
nel body del messaggio l'SDP media descripton del tipo di sessione che Bob è
disposto stabilire con Alice. Come risultato, c'è uno scambio di messaggi SDP
di due fasi: Alice ne invia uno a Bob e questo ne invia uno ad Alice. Questo
scambio a due fasi fornisce una capacità base di negoziazione ed è basato su
una semplice modello di scambio SDP Offerta/Risposta. Se Bob non vuole
rispondere alla chiamata o, è occupato con un'altra chiamata, un messaggio di
errore è inviato al posto del 200(OK), che ha come risultato l'impossibilità di
stabilire la sessione. Il messaggio 200 (OK) può essere visto qui sotto:
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:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
La prima linea di questo messaggio di risposta contiene il
response code (200) e la frase descrittiva(OK). Le rimanenti righe sono i campi
dell'header che sono copiato dalla richiesta INVITE. (Ci sono 3 campi Via
nell'header - uno aggiunto dal telefono SIP di alice, uno aggiunto dal server
proxy di atlanta.com, e l'ultimo aggiunto dal server proxy di biloxi.com.) Il
telefono SIP di Bob ha aggiunto un parametro Tag al campo To dell'header.
Questo tag viene messo da tutti e due gli endpoint della conversazione e verrà
incluso in tutte le future richieste e messaggi di risposta di questa chiamata.
Il campo Contact dell'header contiene una URI con la quale Bob può essere
contattato direttamente sul suo SIP phone. Il Content-Type e il Content-Lenght
si riferiscono al corpo del messaggio(nell'esempio non viene mostrato) che
contiene l'SDP media information di Bob.
Oltre al DNS e al localizzazione attraverso il servizio
lookups mostrato in questo esempio, il server proxy può prendere delle
decisioni dinamiche riguardo al routing della richiesta. Per esempio, se il
telefono di Bob risponde un 486 (Busy here), il server proxy di biloxi.com può
girare l'INVITE al server voicemail di Bob. Un server proxy può anche mandare
un INVITO a più location nello stesso momento. Questo tipo di ricerca parallela
è chiamato forking
In questo caso, il 200 (OK) è routing indietro attraverso
due proxy e viene ricevuto dal softphone di Alice, che smette di suonare e
indica che la chiamata ha ricevuto una risposta. Alla fine, il softphone di
Alice invia un messaggio di aknowledgement, ACK, al telefono di Bob, bypassando
i due proxy. Questo accade perché i ciascun endpoints ha imparato l'indirizzo
dell'altro attraverso il campo Contact dell'header. Il lookups fatto dai due
proxies non è più necessario, così i due proxy escono dal processo della
chiamata. Questo scambio di dati per l'instaurazione della sessione SIP è
chiamato three-way handshake (INVITE/200/ACK).
La media session di Alice e Bob è stata istaurata, e ora
loro si scambiano media packets usando il formato su cui si sono accordati
attraverso lo scambio SDP.
Durante la sessione, uno tra Alice e Bob può decidere di
cambiare le caratteristiche della media session. Questo è possibile grazie al
invio di un re-INVITE contenente una nuova media description. Questo re-INVITO
fa riferimento al esistente dialogo così che le altre parti riconoscono che è
una modifica di una sessione esistente invece di stabilire una nuova sessione.
Gli altri partecipanti inviano il 200 (OK) con un ACK. Se le altre parti non
accettano il cambio, esse mandano un messaggio di errore con un 488(Not
Acceptable Here), che è seguito da un ACK. Comunque il fallimento del re-INVITE
non causa una caduta della chiamata esistente - la sessione continua a
utilizzare il media precedentemente negoziato.
Alla fine della chiamata, Bob attacca (Hangs up) per primo e
genera un messaggio BYE. Questo BYE è routing direttamente al softphone di
Alice, anche questa volta bypassando i proxies. Alice conferma il ricevimento
del BYE con un messaggio 200 (OK), che termina la sessione e lo scambio del
BYE. Non è inviato nessun ACK - l'ACK è mandato soltanto per rispondere alla
risposta della richiesta di INVITE.
In alcuni casi, potrebbe essere utile per i proxies vedere i
segnali SIP per tutta la durata della sessione. Per esempio, se il server proxy
biloxi.com vuole rimanere nel percorso delle segnalazioni dei messaggi SIP
oltre l'iniziale INVITE, può aggiungere all'header dell'INVITE un campo
chiamato Record-Route che contiene un URI all'hostname o all'IP del Proxy.
Questa informazione sarà ricevuta dal telefono SIP di Bob e dal softphone di
Alice e mantenute per tutta la durata della sessione. Il server proxy
biloxi.com riceverà e girerà i messaggi ACK, BYE e 200(OK) fino al BYE. Ciascun proxies può
indipendentemente decidere se ricevere i messaggi SIP, e i messaggi passeranno
attraverso tutti i proxies che lo richiedono. Questa capacità è spesso usata dai
proxies che forniscono servizi durante le chiamate.
La registrazione è un altra delle operazioni comuni nel SIP.
La registrazione è una delle strade attraverso la quale il biloxi.com server
può imparare la location di Bob. All'avvio e a intervalli regolari, il telefono
SIP di Bob manda un messaggio REGISTER al server del dominio biloxi.com. Il
messaggio REGISTER associa il SIP o SIPS URI di Bob(sip:bob@biloxi.com)
all'apparecchio in cui è attualmente loggato. Il server scrive questa
associazione, anche chiamata Binding, in un database, chiamato location
service, che può essere usato dal proxies nel biloxi.com domain.
Bob non è costretto a registrarsi in un solo device, Per
esempio, entrambi i suoi telefoni SIP, quello di casa e quello dell'ufficio
possono mandare la registrazione. Queste informazioni sono registrate nel
location service e lasciano la possibilità al proxy di effettuare vari tipi di
ricerca per localizzare Bob. Allo stesso modo, più utenti si possono registrare
allo stesso tempo su un unico device. Il location service è solo un concetto
astratto. Questo di solito contiene informazioni che permettono a un proxy di
inserire una URI e ricevere una o più URIs che indicano al server dove mandare
la richiesta. La registrazione è una strada per avere queste informazioni, ma
non l'unica. Una mappatura arbitraria può essere configurata a discrezione
dell'amministratore.
Infine, è importante notare che nel SIP, la registrazione è
usata per routing le richieste SIP entranti e non ha rilevanza
nell'autorizzazione delle richieste in uscita. Sia l'autorizzazione e
l'autenticazione sono effettuate da SIP attraverso uno scambio di richieste con
un meccanismo di challenge/response.
Ultimo aggiornamento: 01-11-2007 15:18
|
