Sei sulla pagina 1di 140

SIP: Session Initiation Protocol

Autore: Ing. Aldo Campi D.E.I.S. Universit di Bologna


Ringraziamento: Filippo Zangheri per le figure

Argomenti
SIP introduzione
il SIP, che cos' e cosa non architettura, terminologia

Caratteristiche del Protocollo


Tansactions, Dialog Formato dei messaggi (richieste, risposte)

Funzionalit di base
chiamate dirette ed attraverso SIP server

Funzioni di un SIP server


instradamento delle chiamate
Request-Routing, Response-Routing

costruzione dei percorsi


Record-Route, Route header

Location server Registrar server


Framework per lautenticazione

Sessione multimediale
Negoziazione (SDP)

Cenni di sicurezza

2008 Aldo Campi

Introduzione al SIP

2008 Aldo Campi

Gli albori del SIP


Sessioni di conferenza (Mbone)
Protocollo di segnalazione per negoziare, modificare e terminare una conferenza

DallHTTP e dalla negoziazione delle Sessioni per avviare e controllare conferenze multimediali su rete a pacchetto Similitudini tra SIP e HTTP
Basati su testo Proxy
2008 Aldo Campi

Instaurazione e controllo di una conferenza


Creazione: di un documento che descrive la sessione
uso di protocolli per descrivere una sessione multimediale

Annuncio: ai partecipanti della sessione


Protocolli per lannuncio di sessioni (es: SAP), Netnews, www, etc

Invito: ai partecipanti della sessione


Email, Invitation protocol, etc

Richiesta: ai partecipanti la forma di comunicazione da usare


Streaming protocol

Unione alla sessione: dei partecipanti Media streams: inizio della comunicazione
2008 Aldo Campi

Storia del conference initiation in Mbone


Session Invitation Protocol (Handley/Schooler) Locazione dei partecipanti Invito alla conferenza Capacit di negoziare durante il setup Simple Conference Invitation Protocol (Schulzrinne) Locazione dei partecipanti Invito alla conferenza Capacit di negoziare durante il setup Cambio dei parametri della conferenza Terminare/abbandonare la conferenza

1996 -> Session Initiation Protocol


2008 Aldo Campi

Session Initiation Protocol (1/1)


Breve storia
Primo draft nel Dicembre del 1996
Sforzo per unire SIP e SCIP IETF WG MMUSIC (Multiparty Multimedia Session Control)

RFC 2543 (Febbraio 1999) RFC 3261 (Giugno 2002)

RFC 3261 : an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants
2008 Aldo Campi

Session Initiation Protocol (1/2)

Protocollo di strato 7
Basato su linee di testo (UTF-8 encoding, RFC 2279) Indipendente dallo strato di trasporto TCP, UDP, TLS, etc

Protocollo di segnalazione
Creazione, modifica, conclusione della chiamata Negoziare luso dei media coinvolti del dialogo Aggiungere partecipanti ad una sessione Rinegoziazione durante la sessione di comunicazione Locazione degli utenti mobilit (identificazione univoca) Sicurezza Servizi supplementari

Trasporta protocolli applicativi


SDP, PID, XPID etc..

Non fornisce alcun servizio. Primitive che possono essere usate per la creazione di servizi.
Es: Localizza un end-point gli consegna un oggetto opaco
2008 Aldo Campi

RFC riferiti al SIP (1/4)


Base spec RFCs related to SIP (1)
RFC 3261: SIP: Session Initiation Protocol RFC 3263: Locating SIP Servers RFC 3264: An Offer/Answer Model with SDP

Extended Features RFC 2976: The SIP INFO Method RFC 3262: Reliability of Provisional Responses in SIP RFC 3265: SIP-specific Event Notification RFC 3311: SIP UPDATE Method RFC 3312, RFC 4032: Integration of Resource Management and SIP RFC 3326: Reason Header RFC 3327: Registering Non-Adjacent Contacts RFC 3428: Instant Messaging RFC 3487: Requirements for Resource Priority RFC 3515: SIP REFER Method RFC 3581: Symmetric Message Routing RFC 3680: SIP event package for registrations RFC 3725: Third-party Call Control (3PCC) RFC 3840, 3841: Callee capabilities and caller preferences RFC 3842: Message waiting indication / message summary RFC 3857, 3958: Watcher Information event package + XML format RFC 3891: Replaces: header RFC 3892: Referred-By: header RFC 3903: Event state publication (SIP PUBLISH method) RFC 3911: Join: header RFC 4028: Session timers RFC 4168: SCTP as transport protocol

2008 Aldo Campi

RFC riferiti al SIP (2/4)


Extended Features (continua)
RFC 4244: Request history RFC 4320: Addressing issues with non-INVITE transactions RFC 4321: Problems with non-INVITE transactions RFC 4412: Communications resource priority for SIP RFC 4483: Content indirection in SIP RFC 4488: Suppressing implicit subscriptions of REFER RFC 4508: Conveying feature tags with REFER RFC 4235: INVITE-initiated dialog event package RFC 4245: Requirements for SIP conferencing RFC 4353: SIP conferencing framework RFC 4376: Floor control requirements RFC 4411: SIP Reason header for preemption RFC 4453: Requirements for consent-based communications RFC 4475: SIP torture test messages RFC 4479: A data model for presence RFC 4480: RPID: rich presence RFC 4481: Extensions for timed presence RFC 4482: CPID: Contact information in presence RFC 4575: SIP conference event package RFC 4579: SIP call control: conferencing for user agents RFC 4596: Caller preferences extensions RFC 4597: Conferencing scenarios RFC 4660: Functional description of event filtering RFC 4661: XML for event filtering RFC 4662: Event notifications for resource lists

2008 Aldo Campi

RFC riferiti al SIP(3/4)


Security
RFC 3323: A Privacy Mechanism for SIP RFC 3325: Private Extension for Asserted Identity in Trusted Networks RFC 3329: Security-Mechanism Agreement for SIP RFC 3603: Proxy-to-Proxy Extensions RFC 3702: AAA requirements for SIP RFC 3853: S/MIME AES RFC 3893: Authenticated Identity Body RFC 4189: Requirements for end-to-middle security RFC 4474: Enhancements for authenticated identity management RFC 4484: Trait-based authentication requirements RFC 4538: Request authorization through dialog identification

2008 Aldo Campi

RFC riferiti al SIP (4/4)


Others
RFC 3665, 3666: SIP Call Flows RFC 3361: DHCP Option for SIP Servers RFC 3608: Service Route Discovery RFC 3398, 3578: ISUP and SIP Mapping RFC 3420: Internet Media Type message/sipfrag RFC 3427: SIP Change Process RFC 3455: Header Extensions for 3GPP RFC 3485, 3486: SIP header compression RFC 3764, 3824: Using ENUM with SIP RFC 3959: Early Session disposition type (early-session, session) RFC 3960: Early Media and Ringing Tone Generation RFC 3968, 3969: IANA SIP header field and URI registry RFC 3976: SIP IN Interworking RFC 4117: 3rd party call control invocation of transcoding services RFC 4123: SIP H.323 Interworking requirements RFC 4485: Guidelines for authors of SIP extensions RFC 4497: SIP QSIG interworking RFC 4569: IANA media feature tag registration

Pi di 100 Internet Drafts!!! Unottima guida alle specifiche RFC :


draft-ietf-sip-hitchhikers-guide-01.txt 2008 Aldo Campi

Produttivit: pagine RFC

2008 Aldo Campi

Produttivit: pagine RFC (VoIP + Audio)

2008 Aldo Campi

Il SIP non
Non pensato per il controllo della sessione
Nessun controllo di flusso Nessuna lista dei partecipanti

Modellato per la distribuzioni di dati multimediali Un generico protocollo per il trasporto! Un meccanismo RPC
SIP non ha il supporto intrinseco per la distribuzione delle informazioni di stato

Capacit per la network resource reservation (QoS) Qualcosa da mettere in ogni dispositivo!!!

proposte per un uso improprio del protocollo si vedono di frequente


2008 Aldo Campi

Architettura Architettura SIP locale


SIP Gateway SIP UA SIP Gateway SIP UA SIP Gateway SIP UA

Entit amministrativa

PSTN ISDN

Registrar

Redirect / Proxy Server

Location Server

GSM

Rete IP locale
Endpoint SIP UA Endpoint SIP UA Endpoint SIP UA

H.323

2008 Aldo Campi

Terminologia di base
Address-of-Record (AOR):
un SIP o SIPS URI che punta ad un dominio con un location service che pu mappare lURI con un altro URI dove lutente potrebbe essere disponibile.

User Agent (UA)


Client (UAC):
Endpoint, inizia una SIP transactions (requests)

Server (UAS):
Gestisce i messaggi SIP in arrivo requests/responses

Redirect server:
Recupera lindirizzo del chiamato (callee) e lo inoltra al chiamante (caller)

Proxy server:
Processa autonomamente le requests/responses e le instrada Limitate modifiche ai messaggi instradati

Registrar server :
Memorizza la locazione degli utenti registrati

Location server:
Fornisce informazioni sulla locazione degli utenti

Back-to-Back User Agent (B2BUA)


Mantiene lo stato di chiamata (call state); pu modificare pesantemente i messaggi

2008 Aldo Campi

Caratteristiche del protocollo (1/2)


Basato sul Dialogo (Dialog-based)
Composto da Transazioni (Transaction-oriented) Sequenza: richiesta risposta (RequestResponse)

Indipendente dagli strati pi bassi del protocollo di trasporto Funziona sia con protocolli di trasporto affidabili (reliable) che non affidabili (unreliable).
UDP, TCP (5060)
Secure transport: TLS su TCP (5061), IPSec

Ritrasmissione per realizzare la reliability su UDP Opzionale : IP multicast -> realizzare servizi anycast
2008 Aldo Campi

Caratteristiche del protocollo (2/2)


Indipendente dalla sessione di comunicazione da instaurare I server mantengono informazioni minime sullo stato della comunicazione
Instradamento senza mantenere lo stato (Stateless proxies)
Pi leggero e performante

Instradamento mantenendo lo stato della transazione (Transaction-stateful proxies)


Maggiore capacit finzionale (es: ritrasmissione)

Stato del dialogo (call) negli endpoints (opzionale per i proxies)


Es: forking request

2008 Aldo Campi

Funzionalit SIP
SIP supporta modi per stabilire e terminare sessioni multimediali User location: determinazione dellend system da utilizzare per la comunicazione; User availability: determinazione della disponibilit dei partecipanti a creare una sessione; User capabilities: determinazione dei media e dei parametri da usare nella sessione; Session setup: "ringing", instaurazione dei parametri di sessione tra il chiamante e il chiamato; Session management: include il trasferimento e la terminazione delle sessioni, la modifica dei parametri e linvoco di servizi.
2008 Aldo Campi

Funzionalit SIP
SIP non un sistema verticale integrato di comunicazione. Uso di altri protocolli dellIETF per un sistema completo di comunicazione:
Real-time Transport Protocol (RTP) (RFC 1889)
Trasporta dati real-time e funzioni di QoS

Real-Time streaming protocol (RTSP) (RFC 2326)


Controllare la distribuzione dei dati multimediali

Media Gateway Control Protocol (MEGACO) (RFC 3015)


Per controllare i Gateway nella Public Switched Telephone Network (PSTN)

Session Description Protocol (SDP) (RFC 2327)


Per descrivere sessioni multimediali

Le funzioni base del SIP non dipendono da nessun altro protocollo


2008 Aldo Campi

Struttura del protocollo


SIP strutturato a strati (layers)
Il comportamento descritto in termini di un gruppo di processi del tutto indipendenti con un libero accoppiamento tra di essi.

Elementi SIP
Non ogni elemento specificato contiene tutti i layer. Logici e non fisici

2008 Aldo Campi

Layers (1/3)
Primo layer di syntax e encoding:
La struttura di codificazione specificata usando una grammatica evoluta Backus-Naur Form (BNF).

Secondo transport layer:


Definisce come un client invia richieste e riceve risposte Definisce come un server riceve richieste e invia risposte. Tutti gli elementi SIP contengono un transport layer

2008 Aldo Campi

Layers (2/3)
Terzo layer transaction layer:
componente fondamentale di SIP transaction una richiesta inviata da un client transaction (usando il transport layer) ad un server transaction insieme a tutte le risposte (provvisorie o definitive) implementa la ritrasmissione a livello applicativo
implementa timeout a livello applicativo

ogni task che un user agent client (UAC) realizza utilizzando una serie di transizioni
matching delle risposte alle richieste

ogni User agents e stateful proxies contengono una transaction layer


componente client (riferito alla client transaction) e componente server (riferito alla server transaction) Macchina a stati finiti

stateless proxies NON contengono una transaction layer


2008 Aldo Campi

Layers (3/3)
Quarto transaction user (TU):
Ogni entit SIP (eccetto stateless proxy) sono una transaction user. TU invia richieste creando una istanza di client transaction con la richiesta e lindirizzo IP, porta e il trasporto. La TU che crea una client transaction pu anche cancellarla
Uso di CANCEL che avvia una transaction indipendente ma riferita alla transaction da cancellare.

2008 Aldo Campi

Elementi SIP
Elementi SIP
user agent clients e servers stateless e stateful proxies Registrars (UAS speciale)

Funzionalit del core:


Il core degli elementi (tranne stateless proxy) composto da TU. UAS e UAC dipendono dai metodi
UAS processa richieste e genera risposte UAC crea le richieste

Realizzati con stack SIP


Es: pjsip
2008 Aldo Campi

Transactions
SIP Transactions A
crea transaction state distruggi transaction state

Request Provisional Responses

B
crea transaction state distruggi transaction state

Final Response

Approccio RPC-like:
Request iniziale Attesa di Final Response

Identificativo univoco (transaction ID) (origine, destinazione, unique token, sequence number, ) Completamento indipendente della transaction

Provisional Responses:
Informazioni aggiuntive Possono essere inaffidabili

2008 Aldo Campi

Dialogs
Dialogs
Signalling vs. media session Stato distribuito tra gli endpoint
Lo stato cambia se la transazione riesce Nessun cambiamento in caso di errore

Unique dialog identifier

una transaction indica transizione di stato inizializza dialog crea dialog stabilisci dialog

A
crea dialog modifica dialog distruggi dialog create modify modify destroy

B
crea dialog modifica dialog distruggi dialog

2008 Aldo Campi

Indirizzamento SIP

2008 Aldo Campi

Uniform Resource Identifier (RFC 2396)


Definisce una sintassi generale per costruire identificatori associati in modo univoco a risorse fisiche o logiche E una estensione di Uniform Resource Locator (RFC 1738) e Uniform Resource Name (RFC 2141)
URL identifica le risorse tramite il modo di accedervi (tipicamente via rete) piuttosto che tramite suoi attributi URN identifica una risorsa logica in modo univoco indipendentemente dalla sua esistenza o accessibilit
N. Franco Callegati 30

URI (2)
Identificatore
un oggetto che viene usato come riferimento a qualcosa che ha una identit in URI una sequenza di caratteri che debbono soddisfare regole di sintassi prestabilite

Risorsa
tutto ci che ha una identit univoca
ad esempio documenti, immagini, servizi, anche un particolare insieme di altre risorse

una risorsa non necessariamente qualcosa che pu essere consultato via rete (persona, azienda ecc.)

La risorsa identifica una entit logica, per cui la risorsa pu rimanere costante anche se lentit cambia
N. Franco Callegati 31

URI (3)
Uniformit
permette di usare diversi tipi di identificatori nel medesimo contesto, anche se il modo di accedere alla risorsa non sempre il medesimo permette lintroduzione di nuovi insiemi di identificatori senza interferire con le modalit con cui vengono usati identificatori pre-esistenti permette linterpretazione uniforme del significato di convenzioni sintattiche fra insiemi diversi di identificatori permette di riutilizzare degli identificatori in diversi contesti, cos che nuove applicazioni e/o protocolli possono direttamente accedere a insiemi pre-esistenti di identificatori N.
Franco Callegati 32

URI (4)
E frutto della generalizzazione dei lavori iniziali fatti nellambito del WWW per la definizione delle URL Lobiettivo solo quello di specificare una serie di regole generali per definire ed interpretare gli identificatori Il compito di definire la sintassi specifica degli identificatori lasciata alle applicazioni specifiche

N. Franco Callegati 33

Schema dei SIP URI


Seguono lo schema base per gli URI (sintassi RFC 2396) Separazione tra il naming (permanente) e gli indirizzi (temporanei)
Supporto base per la mobilit

Due ruoli del SIP URI


Definire nominalmente un utente (Naming):
sip:user:password@host:port;uri-parameters?headers

Indirizzo per contattare un utente; tipicamente contiene il nome host o lindirizzo IP, la porta e il protocollo di trasporto, ...

URI possono portare parametri addizionali URI possono identificare servizi Uso dello schema URI sips per richiedere una comunicazione sicura
2008 Aldo Campi

Esempi di indirizzi SIP URI


Domain o indirizzo IP
sip:unibo.test sip:192.168.42.1

SIP URI da chiamare (Registro degli indirizzi)


sip:bob@unibo.test

SIP Contact Address (locazione attuale)


sip:bob@host1.unibo.test sip:bob@192.168.42.9:9950

Service identifier; semantica opaca allutente


sip:voicemail@service.com sip:conf-1234@confserv.com sip:user34@anonymizer.org

I parametri nellURI possono portare informazioni aggiuntive:


sip:bob@unibo.test;maddr=10.0.0.1 sip:+1555123456@tel-gw.unibo.test;user=phone

2008 Aldo Campi

Messaggi SIP

2008 Aldo Campi

Messaggi
Protocollo basato su linee di testo (UTF-8, RFC 2279) Messaggi:
Request: richieste da UA client a UA server
In Dialog, out of Dialog

Response: risposte da server a client Formato descritto da RFC 2822 anche se la sintassi differisce nel set di caratteri e nei dettagli
Es: SIP permette luso di campi header

Formato di un generico messaggio (riuso della sintassi HTTP/1.1):


start-line (CRLF) : Request-Line / Status-Line Headers (CRLF) CRLF [ message-body ]

CR e LF sono permessi solo a fine linea, non permesso l utilizzo di linear whitespace (LWS) CRLF: carriage-return line-feed

2008 Aldo Campi

Sintassi del messaggio: Richiesta


Start line
INVITE sip:user@domani.com SIP/2.0 To: Bob <sip:bob@domain.com> From: Alice<sip:alice@domain.com>; tag=4711 Max-Forwards: 70 Content-Length: 117 Content-Type: application/sdp Call-ID: 2342344233@134.102.218.1 Cseq: 49581 INVITE Contact: sip:alice@137.204.107.60:5083; transport=udp Via: SIP/2.0/UDP 134.102.218.1; branch=z9hG4bK776asdhds
v=0 o=jo 75638353 98543585 IN IP4 134.102.218.1 s=SIP call t=0 0 c=IN IP 134.102.224.152 m=audio 47654 RTP/AVP 0 1 4

Intestazione messaggio (header)

Message body (contenuto SDP)

2008 Aldo Campi

Sintassi del messaggio: Richiesta


Start line -> Request-Line
Method (SP) Request-URI (SP) Versione del protocollo SIP (CRLF)

Header
Specifica le intestazioni del messaggio: transaction, dialog etc..

Body
Contenuto del messaggio SIP (es: email, HTTP)

Method : tipo di messaggio che si intende inviare (RFC3261)


INVITE Avvia una chiamata (crea un Dialogo)
RE-INVITE, solo per Dialoghi confermati La transaction ID pu essere diversa, i parametri del dialogo sono quelli dellINVITE Solo per Dialoghi confermati Solo per dialoghi non confermati

ACK Conferma di un messaggio ricevuto (non nella transaction) BYE Termina o trasferisce la chiamata (Distrugge il Dialogo) CANCEL Cancella ricerche o lo stato di ringing OPTIONS Caratteristiche supportate dall'inviante REGISTER Registra presso un server UPDATE aggiorna un dialogo non stabilito (simile ad INVITE)
Solo per dialoghi non confermati

SP: spazio singolo


2008 Aldo Campi

Sintassi del messaggio: Richiesta


Request-URI:
un SIP o SIPS URI Uniform Resource Indicators o un generico URI (Uniform Resource Identifiers RFC 2396). Indica lutente o il servizio al quale la richiesta inviata Non pu contenere unescaped spaces o caratteri di controllo e non deve essere racchiuso da "<> Gli elementi SIP possono supportare schemi diversi da sip:
Schema tel:" URI (RFC 2806)

SIP o SIPS URI Uniform Resource Indicators


Identifica una risorsa di comunicazione
Come tutte la URI posso essere messe in web pages, email, etc..

Contengono informazioni sufficienti per iniziare e mantenere una sessione di comunicazione con una risorsa Esempi:
mailbox in un servizio di messaggistica, numero PSTN in un gataway, un gruppo di una organizzazione (helpdesk), etc
2008 Aldo Campi

Sintassi del messaggio: Richiesta


Versione del protocollo SIP:
Sia per le richieste che per le risposte
HTTP -> SIP HTTP/1.1 -> SIP/2.0

Stringa case-insensitive, ma bisogna inviare il formato in upper-case

2008 Aldo Campi

Sintassi del messaggio : Risposta


Start line
SIP/2.0 200 OK To: Bob <sip:bob@domain.com>;tag=428 From: Alice <sip:alice@domain.com>; tag=4711 Subject: Congratulations! Content-Length: 121 Content-Type: application/sdp Call-ID: 2342344233@134.102.218.1 Cseq: 49581 INVITE Contact: sip:bob@myhost.com Via: SIP/2.0/UDP 134.102.218.1; branch=z9hG4bK776asdhds
v=0 o=jdoe 28342 98543601 IN IP4 134.102.20.22 s=SIP call t=0 0 c=IN IP 134.102.20.38 m=audio 61002 RTP/AVP 0 4

Intestazione messaggio (header)

Message body (contenuto SDP)

2008 Aldo Campi

Sintassi del messaggio: Risposta


Start line -> Status-Line
Versione SIP (SP) Status-Code (SP) Indicazione ragione (CRLF)

Header
Specifica le intestazioni del messaggio: transaction, dialog etc..

Body
Contenuto del messaggio SIP (generalmente omesso)

Codice di stato: il risultato del tentativo di interpretare e soddisfare la richiesta, composto da 3 cifre decimali. Processamento in automatico

2008 Aldo Campi

Sintassi del messaggio: Risposta


La prima cifra definisce la classe di risposta, XX sono cifre numeriche proprie di una determinata azione.
1xx Provisional: in ricerca, squillo, accodato (100 Trying, 180 Ringing) 2xx Success: (200 OK) 3xx Redirection: forwarding (302 Moved temporarily) 4xx Client Error: errori lato client (404 User not Found) 5xx Server Error: errori lato server (500 Internal Server Error) 6xx Global Failure:occupato, rifiutato, non disponibile (603 Decline)

Tipi di risposte
Provvisorie: non terminano una transaction (1xx) Definitive: terminano una transaction (2xx, 3xx,4xx,5xx, 6xx)
3xx,4xx,5xx: indicano informazioni provvisorie per il dialogo 2xx, 6xx: avviano o chiudono definitivamente il dialogo

Indicazione ragione: una descrizione testuale del codice di stato, per linterazione con lutente
Il client non obbligato ne a mostrare ne a processare la ReasonPhrase (es: linguaggi differenti)
2008 Aldo Campi

Headers
Formato dei campi header:
field-name: field-value *(;parameter-name=parameter-value) Possono essere estesi su pi linee Lordine dei campi non rilevante
I campi processati dai proxy dovrebbero essere primi Via, Route, Record-Route, Proxy-Require, Max-Forwards, and Proxy-Authorization, etc

Lordine dei campi con lo stesso nome rilevante


Via, Route, etc

Per ogni field-value si possono specificare pi parametri, ma non con lo stesso nome field names sono sempre case- insensitive Si dividono in campi request header e response header

2008 Aldo Campi

Body del messaggio


In Richieste e in risposte (opzionale)
Linterpretazione del body dipende dal tipo di messaggio.

Body Type
Definiti dagli headers Tipo "multipart" MIME (RFC 2046) Tipo di default "text

Headers
Content-Type: definisce il tipo di body Content-Length: contiene un ottetto (byte) che indica la lunghezza del body Content- Encoding: header: definisce il tipo di decodifica come per esempio la compressione (altrimenti omesso)
2008 Aldo Campi

Esempio di Dialogo
A
prepara media session Early dialog stabilisci media session, dialog sessione multimediale attiva termina media session; distruggi dialog

B
INVITE Ringing OK ACK Media Streams BYE OK
Early dialog crea media session, dialog

sessione multimediale attiva termina media session distruggi dialog Caso particolare: le transaction INVITE richiedono un threeway handshake. 2008 Aldo Campi

UAC: generazione di una richiesta


Differenze tra richieste:
Dentro un dialogo Fuori dal dialogo

Start line: Request-URI Set minimo di Header richiesti: To, From, CSeq, Call-ID, Max-Forwards e Via
Indirizzi dei messaggi Instradamento delle risposte Limite della propagazione del messaggio Identificazione della transaction
2008 Aldo Campi

Request-URI
La Request-URI iniziale dovrebbe essere uguale al campo To:
Metodo REGISTER uneccezione Pu essere cambiata durante il percorso del messaggio

La presenza di una pre-existing route ha effetto sulla Request-URI


Configurato dal service provider nello UA o con altri meccanismi non-SIP. Es: outbound proxy la Request-URI diventa la remote target URI
2008 Aldo Campi

Header Via:
Via: contiene lindirizzo (es:myaddress.com) dal quale lend-point (Alice) si aspetta di ricevere la risposta alla richiesta
Indica il trasporto utilizzato, dove inviare le risposte

Deve contenere un branch parameter che identifica la transaction


Usato da client e server Unico per tutte le richieste

Eccezioni per risposte non-2xx


CANCEL: ha il branch della transaction da cancellare ACK: ha il branch della transaction di INVITE

branch parameter (RFC3261)


Deve iniziare con "z9hG4bK I parametri: maddr, ttl, e sent-by possono essere aggiunti dal transport layer
2008 Aldo Campi

Header To:
To: contiene il nome da mostrare (display name, Bob) e il SIP o il SIPS URI (sip:bob@unibo.test) verso il quale la richiesta era originariamente diretta (logical recipient) oppure lAoR
Display names sono decritti in RFC 2822 Tag: parameter contiene una stringa random che aggiunta allURI dallo UA. utilizzata per lidentificazione.
presente solo a dialogo stabilito

Pu avere una dicitura semplificata


Es: bob. Processato dallHome doman per lo "speed dial

Se non si vuole specificare il dominio si pu utilizzare il tel URL.


Tel:113, processato dalloutbound proxy
2008 Aldo Campi

Header From:
From: contiene il nome da mostrare (display name, Alice) e il SIP o il SIPS URI (sip:alice@unibo.test) che indica chi ha dato origine alla richiesta oppure lAoR
Tag: parameter contiene una stringa random che aggiunta allURI dallo UA. utilizzata per lidentificazione. Non pu contenere IP address o FQDN poich non sono nomi logici

Usato dagli elementi SIP per determinare quale regole applicare automaticamente alla richiesta (es: automatic call rejection) Usato per Display names:
Per lo stato Anonymous :
Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

Usato per lautenticazione


2008 Aldo Campi

Header Call-ID:
Call-ID: contiene un identificativo unico e globale per la chiamata (unique identifier),
Generato da una combinazione di una stringa random con il nome dellhost o dallindirizzo IP del softphone. Il Dialogo completamente definito ed identificato dalla combinazione di:
To tag, From tag e Call-ID

lo stesso per tutti i messaggi in un Dialogo Case-sensitive comparato byte-by-byte

Dovrebbe essere lo stesso per ogni REGISTER message. Uso di cryptographically random identifiers (RFC 1750) raccomandato
Protezione contro il session hijacking e riduce la probabilit di collisioni con altri Call-ID
2008 Aldo Campi

Header CSeq
CSeq: o Command Sequence contiene un valore intero (32-bit unsigned) e un nome di un metodo.
Il metodo lo stesso del messaggio

Il numero nel CSeq: incrementato per ogni nuova richiesta allinterno di un dialogo ed il sequence number

2008 Aldo Campi

Header Contact:
Contact: contiene il SIP o il SIPS URI che rappresenta un percorso diretto (direct route) per contattare lend-point
Generalmente composta da username e un fully qualified domain name (FQDN) Anche se FQDN preferibile, molti end systems non hanno un nome di dominio registrato (domain names), quindi luso di indirizzi IP permesso Pu anche contenere informazioni sulla priorit del contatto (parametro q:[0;1]

Presente nei messaggi per stabilire un dialogo (INVITE) Il comapo Via header indica dove inviare le risposte, il campo Contact header indica dove inviare le richieste future.
2008 Aldo Campi

Header Max-Forwards
Max-Forwards: serve per limitare il numero di hops che una richiesta pu fare fino alla destinazione.
Valore intero che decrementato di 1 ad ogni hop. Quando arriva a zero; 483(Too Many Hops) Valore consigliato: 70

2008 Aldo Campi

Option tag: header Supported e Require


Supported header: lo UAS supporta estensioni che devono essere applicate dal server alle risposte
option tag si possono riferire solo a quelli standard (RFC pubblicati)
Prevenzione per soluzioni mono-vendor

Require header: lo UAC vuole che uno che lo UAS processi una estensione di una richiesta Proxy-Require: stessa cosa per i proxy
2008 Aldo Campi

Header Allow
Allow: lista dei metodi supportati dallo UA
Inclusi ACK e CANCEL Se non compare non significa che lo UA non supporta metodi (non obbligatorio) Al posto di OPTIONS

2008 Aldo Campi

UAS: generazione di una risposta


Processamento della richiesta, method-specific
REGISTER, INVITE,OPTION, BYE etc

Headers
From, To, Call-ID, CSeq sono uguali alla richiesta Via: sono gli stessi e nello stesso ordine To tag viene aggiunto se non presente
Eccezione: 100 Try

2008 Aldo Campi

Scenari applicativi

2008 Aldo Campi

Scenario applicativo 1: Chiamata diretta UAUA

Alice

Internet

Bob

Call signaling Stream multimediali

2008 Aldo Campi

Chiamata diretta
N.B.: Il three-way handshake usato solo per richieste di tipo INVITE.
bob@deis.test

unibo.test
INVITE sip:bob@deis.test 100 Tying
alice@unibo.test

deis.test

180 Ringing 200 OK ACK

Media Streams
BYE 200 OK

Il chiamante (caller) conosce il nome host o lindirizzo IP del chiamato (callee) LUA destinatario riporta i cambiamenti di stato Quando Bob accetta la chiamata viene inviato lOK LUA chiamante conferma, la chiamata stabilita Segue lo scambio di informazioni multimediali (es. RTP) La chiamata terminata da uno dei due partecipanti

2008 Aldo Campi

Chiamato rifiuta la comunicazione


unibo.test
INVITE sip:bob@deis.test 180 Ringing 603 Decline ACK

deis.test

alice@unibo.test

bob@deis.test

Lutente locale contattato dal SIP UA chiamato.

LUA chiamante termina la transaction.

Lutente clicca rifiuta. LUA risponde di conseguenza.

2008 Aldo Campi

Chiamante abbandona la chiamata


unibo.test
INVITE sip:bob@deis.test alice@unibo.test

deis.test
bob@deis.test

Lutente locale riaggancia.

100 Try 180 Ringing CANCEL

Lutente locale contattato dallUA chiamato. LUA chiamato termina di squillare, non viene creato nessun stato di chiamata.

Riuscito. Distruggi l early dialog.

200 OK 487 Request Terminated ACK

Distruggi lo stato della transaction e termina lINVITE.

Chiusura della transaction INVITE.

2008 Aldo Campi

Chiamante abbandona a chiamata stabilita


unibo.test
INVITE sip:bob@deis.test alice@unibo.test

deis.test
bob@deis.test

Lutente chiamante riaggancia. Stabilisci il dialog.

180 Ringing CANCEL 200 OK

487 Transaction does not exist

Lutente risponde. Il transaction state per INVITE viene distrutto. Crea il dialog, stabilisci la sessione multimediale.

Termina lINVITE

ACK BYE

Nessuna transaction da annullare!

e trasmetti BYE! Distruggi il dialog.

200 OK

Session teardown. Distruggi il dialog.


2008 Aldo Campi

Processamento atomico delle Transaction


Transaction:
Creata con la richiesta iniziale Termina con una risposta definitiva alla richiesta iniziale Identificata da :
Method, Request-URI, To:, From:, Call-ID:, CSeq: e topmost Via:

Le transaction si processano sempre indipendentemente luna dallaltra!


INVITE 100 Trying (INVITE) CANCEL 200 OK (CANCEL) 487 Terminated (INVITE) ACK INVITE transaction Cancel transaction INVITE transaction

2008 Aldo Campi

Come trovare il chiamato


Chiamate dirette richiedono la conoscenza dellindirizzo del chiamato SIP fornisce uno schema dei nomi astratto:
sip:user@domain

Definire una relazione tra SIP URI e la locazione corrente:


Registrazione esplicita:
UA registra il suo nome con la sua locazione

Location service:
Fornisce lindirizzo dellutente

Il chiamante invia un INVITE al SIP server che conosce la locazione dellutente chiamato Il server pu ridirigere la chiamata, rifiutarla o trasferirla
2008 Aldo Campi

Come trovare il next hop SIP


Se la URI contiene lindirizzo IP e la porta, il messaggio pu essere inviato direttamente, altrimenti Lo UA necessita di un SIP server per la segnalazione allesterno UAC pu usare un proxy (outbound) configurato manualmente
Outbound proxy possono essere indicati in fase di registrazione

Altrimenti si determina il next hop SIP server attraverso luso del DNS
Query per SRV RR: _sip._udp, _sip._tcp, _sips._tcp per tutti i protocolli di trasporto supportati
Es : _sip._udp SRV 0 5060 unibo.test

Sconsigliato: sip.unibo.test

2008 Aldo Campi

Scenario applicativo 2: Redirected Call


Chiamalo allindirizzo Chiamata per Bob CPL: < Sono Bob, ridirigi le chiamate al mio attuale indirizzo >

2 3 4

Alice

Internet

Bob

Call signaling Stream multimediali

2008 Aldo Campi

Redirected Call
unibo.test
INVITE sip:bob@deis.test
alice@unibo.test

deis.test

100 Trying
302 Moved Temporarily Contact: sip:bob@1.2.3.4;q=1

bob@deis.test
Lookup utente
IP: 1.2.3.4

ACK

INVITE sip:bob@1.2.3.4 200 OK ACK

2008 Aldo Campi

Scenario applicativo 3: Proxied Call


CPL: < Sono Bob, ridirigi le chiamate al mio attuale indirizzo >

Chiamata per Bob

2 4 Alice 3

Internet

Bob
Chiamata da parte di Alice

Call signaling Stream multimediali

2008 Aldo Campi

Proxied Call (stateless, stateful)


Lookup server

deis.test
Lookup utente

unibo.test
INVITE sip:bob@deis.test 100 Trying
alice@ unibo.test

deis.test

INVITE sip:bob@deis.test 100 Trying


bob@deis.test

200 OK ACK Media Streams

200 OK

2008 Aldo Campi

Scenario applicativo 4: Proxied Call (caso reale)


Le Request tipicamente Seguono percorsi diversi Si biforcano Formano spirali

Alice

Bob
Le Response Seguono sempre il percorso inverso a quello della Request originaria 2008 Aldo Campi

Call signaling Stream multimediali

SIP Network: Connettivit IP e Segnalazione SIP

2008 Aldo Campi

Architettura SIP Globale


SIP backbone
SIP Server SIP Server SIP Server SIP Server

Dominio SIP locale

Dominio SIP Provider X

SIP Server

Segnalazione SIP per linstradamento iniziale e la negoziazione della chiamata

SIP Server

Dominio SIP Provider Y

SIP Server

Segnalazione SIP durante la chiamata

SIP Server

SIP Endpoint

SIP Endpoint Stream multimediale (es. RTP)

SIP Endpoint

SIP Endpoint

2008 Aldo Campi

Funzioni SIP (Proxy) Server


Stateless vs. stateful
Stateless: efficiente e scalabile (backbone) Stateful: fornisce servizi, controllo del firewall, ...

Ruoli dei proxy


Outbound proxy
Provvede a risolvere gli indirizzi e instrada le chiamate per gli endpoint Preconfigurato per gli endpoint (manualmente, DHCP, ...)

Backbone proxy
Funzioni di instradamento delle chiamate

Access proxy (inbound)


Autenticazione, autorizzazione e accounting Nasconde la rete interna (topologia, dispositivi, utenti, ecc.)

Centralino locale telefonico IP (IP PBX) Creazione di servizi

Funzioni pi elaborate sono fornite dai Back-to-Back User Agents (B2BUAs)


2008 Aldo Campi

Proxy vs. B2BUA


Dialog X Proxy
(stateful o stateless)

UA 1

Dialog X

UA 2

UA 1

Dialog X

U A 1

B2BUA
(stateful)

U A 2

Dialog Y

UA 2

Proxy instrada e reindirizza le richieste B2BUA termina il dialogo: crea lillusione di un dialogo end-to-end accoppiando due differenti dialoghi ed instradando i messaggi tra gli UA; il dialogo end-to-end fa parte di entrambi i dialoghi.

2008 Aldo Campi

Scenario applicativo 4: Proxied Call (caso reale)


Le Request tipicamente Seguono percorsi diversi Si biforcano Formano spirali

Alice

Bob
Le Response Seguono sempre il percorso inverso a quello della Request originaria 2008 Aldo Campi

Call signaling Stream multimediali

Request-Routing
u3@B

P2 UA A
u1@P1

UA B

P1 P3
u4@C

UA C

Ogni server determina il suo next hop


Location e/o DNS based o preimpostato (Least Cost Routing)

Diverse destinazioni possono essere provate in parallelo


Marca i messaggi uscenti con il branch tag Uso di un unico id per identificare un unico branch tag

Richieste multiple possono arrivare ad un singolo UAS


tag To: nellheader identifica la presenza dellutente
Originale, peocessato delloutboud proxy o servizio speed-dial

RFC3261: tag From: obbligatorio per lidentificazione della richiesta da parte di un UAS
2008 Aldo Campi

Response Path: creazione del Via-path


Via: P1 Via: A Via: P2 Via: P1 Via: A Via: P3 Via: P1 Via: A Via: P1 Via: A

P2

UA B

UA A

Via: A

P1 P3

Via: P3 Via: P1 Via: A

UA C

Inserire Via: header quando la richiesta instradata


Aggiunge il branch tag per distinguere i differenti path

Le risposte si inviano al primo Via-entry Le risposte seguono lo stesso path della richiesta originale Successive richieste possono avere percorsi differenti!
Non se specificato record-route

UAS elimina le risposta con il topmost Via differente da se stesso


2008 Aldo Campi

Risposte multiple (Merging)


200 OK Via: P1, A 200 OK Via: P2, P1, A

P2

UA B

UA A

200 OK Via: A

P1
408 Timeout Via: P1, A

P3

408 Timeout Via: P3, P1, A

UA C

Proxy attendono le risposte finch


Nessuna richiesta in sospeso, oppure Time-out delle richieste, oppure Un utente invia una risposta finale (6xx or 2xx)

La migliore risposta inviata al chiamante, le altre sono eliminate o aggregate Risposte OK sono inoltrate sempre
INVITE pu generare multiple risposte 200 OK
2008 Aldo Campi

Record-Route
I Proxy possono avere necessit di vedere tutte le richieste in un dialogo
Aggiornare le informazioni di stato: accounting, call distribution, Firewall e NAT

Record-Route e Route headers per richiedere gli instradamenti


Si aggiungono gli indirizzi dei proxy alla Record-Route
lo UAS che riceve la richiesta copia i RR nella risposta

Route header pu essere inizializzato con un gruppo di route predefinito

Le successive richieste conterranno i percorsi (source route) creati nella prima richiesta attraverso il Record-Route header
La Route creata durante la costruzione del dialogo (es: INVITE) Immutata per tutta la durata del dialogo (solo la destination URI pu cambiare)

2008 Aldo Campi

Costruzione della Route


Richiesta
UA A invia una richiesta per UA B a P1 P1 e P2 aggiungono se stessi nel Record-Route header UA B memorizza la RecordRoute per scopi futuri
RR: r1 RR: r2, r1

UA A

P1

P2

UA B

Risposta
UA B copia Record-Route della richiesta dentro la risposta
UA A
RR: r2, r1

P1

RR: r2, r1

P2

RR: r2, r1

UA B

2008 Aldo Campi

Uso di una Route predefinita


Richiesta
UA A crea una nuova richiesta per B ed inserisce nella Route-header il contenuto rovesciato della Record-Route della risposta UA A aggiunge lindirizzo di B trovato dal campo contact della prima risposta Tutti i proxy instradano la richiesta seguendo la Route

UA A

R: r1, r2,rB

P1

R: r2,rB

P2

R: rB

UA B

Risposta
UA B usa la stessa route della risposta UA B aggiunge lindirizzo di A nella risposta
UA A
R: rA

P1

R: r1, rA

P2

R: r2, r1, rA

UA B

2008 Aldo Campi

Pre-loaded Routes
La richiesta pu contenere un set di pre-loaded route
Default outbound proxy, CSCFs in 3GPP
Configurato automaticamente o manualmente

Loose source routing:


Forwarding proxy possono ignorare il topmost Route entry

Route entry rewriting:


In una risposta il Proxy pu riscrivere la sua Route URI

P2 UA A
R:r1,r2,rB

UA B

P1 P2 UA B

2008 Aldo Campi

Cancellare le richieste
200 OK

P2 UA A
200 OK

UA B

P1 P3
CANCEL

UA C

Non ha effetto sulle transactions completate


UAS invia 487 Transaction does not exist Altrimenti, non ha nessun impatto sullo stato dello UAS

Usato dai forking proxy per limitare lalbero di ricerca quando arriva una risposta positiva (vedi P1)

2008 Aldo Campi

Problemi delle risposte (Forking proxy) 1

UA B UA A
INVITE 180

P1 UA C

P1 invia una INVITE a pi destinazioni


UA B invia 401 Unauthorized UA C inizia a squillare (180)

La risposta provvisoria 180 inviata allo UA A


UA A vede lo squillo

Nessun trattamento della risposta 401 per il momento

2008 Aldo Campi

Problemi delle risposte (Forking proxy) 2

UA B UA A
CANCEL
401

P1 UA C

Nessuna risposta da C, A decide di annullare la transaction


CANCEL Request

2008 Aldo Campi

Problemi delle risposte (Forking proxy) 3

UA B UA A
401
401

P1
487

UA C

P1 inoltra la migliore risposta (401) ad A


Rinvio della INVITE con le credenziali per B

Problemi:
C squiller ancora Aumento del ritardo della chiamata

Errori eterogenei causano problemi!!!


2008 Aldo Campi

SIP Registration e Location

2008 Aldo Campi

Ricapitolando
Lookup server

deis.test
Lookup utente

unibo.test
INVITE sip:bob@deis.test 100 Trying
alice@ unibo.test

deis.test

INVITE sip:bob@deis.test 100 Trying


bob@deis.test

200 OK ACK Media Streams

200 OK

2008 Aldo Campi

User Location
Segnalazione SIP Protocollo arbitrario (fuori dagli scopi del SIP)

Location server INVITE SIP server (proxy o redirect)


Registrazioni esplicite Entry utmp Awareness protocols Finger, rwho LDAP, X.500,

DB

SIP server chiede al Location server dove trovare il chiamato Location server ritorna una lista di indirizzi (contact address) SIP proxy o redirect processa la richiesta in accordo con la lista di indirizzi (q= value) trovata
2008 Aldo Campi

User Location
sip:unibo.test INVITE sip:bob@unibo.test SIP/2.0 To: sip:bob@unibo.test From: sip:alice@unibo.test;tag=4711 Contact: sip:alice@137.204.103.48 ...

Entit amministrativa (SIP server)


Redirect / Proxy Server Location Server Registrar

1 2 3
134.102.218.57 SIP/2.0 302 Moved Temporarily Contact: sip:bob@137.204.92.23 ... Recupera le informazioni di registrazione dal DB

DB

sip:bob@unibo.test

sip:bob@137.204.92.23 sip:bobby@137.204.92.25

2008 Aldo Campi

User Registration
sip:unibo.test

Entit amministrativa (SIP server)


Redirect / Proxy Server Location Server Registrar

REGISTER sip:unibo.test SIP/2.0 To: sip:bob@unibo.test From: sip:bob@deisnet.test Contact: sip:bob@137.204.92.23 sip:bobby@137.204.92.25 ...

1 2 3
SIP/2.0 200 OK Expires: 3600 ... 137.204.92.23

Salva le informazioni di registrazione nel DB

DB
137.204.92.25 sip:bob@unibo.test sip:bob@137.204.92.23 sip:bobby@137.204.92.25

2008 Aldo Campi

User Registration
UA invia REGISTER al Registrar server
Non inizia un dialogo Record-Route header viene ignorato
Uso di proxy nel path fino al Registrar con Record-Route

Route header e pre-existing route sono permesse

Header obbligatori Request URI: nome di dominio o del Location servive, es:sip:domain
Nome utente e la @ NON sono permessi Il Registrar server pu rifiutare la registrazione per altri domini

To: Contiene lAoR per lutente da registrare, cancellare, modificare


tipicamente sip:user@domain

From: Contiene lAoR dellutente responsabile per la registrazione


pu variare dal To: per registrazioni fatte da altri utenti (third party registration)

Call-ID: ogni registrazione verso lo stesso dominio dovrebbe avere lo stesso valore
Mantiene la sequenza delle registrazioni

CSeq: mantiene la sequenza delle registrazioni


Incrementato di 1 per ogni registrazione con lo stesso Call-ID

2008 Aldo Campi

User Registration
Header opzionali Contact: informazioni per contattare lutente registrato
Indirizzo, parametri di trasporto, metodi ecc. Pu specificare pi indirizzi
Pu anche contenere informazioni sulla priorit del contatto (parametro q: [0;1])

Non si pu inviare un REGISTRAR con un contact differente se non finita la transaction precedente Pu contenere ogni URI valido: SIP o SIPS URI, tel URL, mailto URL, etc

Expires: indica la durata relativa (secondi) della registrazione (2^32-1 = 136 anni)
RFC 2543: permessa anche una data assoluta (RFC 1123, solo formato GMT) Default (omissione o valori mal formattati): 3600s

Gli indirizzi specificati sono aggiunti alle registrazioni esistenti

2008 Aldo Campi

Scadenza della registrazione


UA rinnova la registrazione prima della scadenza con un nuovo messaggio REGISTER Registrar pu indicare valori minori nellheader Expires, indicati in 200 OK
Registrar non pu aumentare la durata della registrazione Pu rifiutare la registrazione 423 Registration Too Brief
Includendo la durata minima di registrazione, Min-Expiry:

Cancellazione
Richiesta dal client: Expires: 0
Per cancellare una specifica URI usa il campo Contact: Cancellare tutte le registrazioni: Contact: *

Dopo la scadenza della registrazione il Registrar cancella le informazioni per contattare lutente
2008 Aldo Campi

Uso dei Contact: Parallel vs. Sequential Forking


jo jo jo q=0.8 sip:bob@pda-bob q=0.8 tel:+39-123-4567890 sip:bob20921@voicemail q=0.1

DB
pda-bob

Lookup bob

INVITE sip:bob@unibo.test Proxy

out Time 408


INV IT sip: E bob 209

ISDN

SIP-ISDN Gateway
21@

4567890

Chiamante

voic

ema

il

Contact-Parameter q per il peso del contatto Forking proxy posso essere raggruppati secondo il q-value
esempio: chiama il server voicemail solo in assenza di risposta da tutti gli UA

Nessun successo
Si procede con il pi basso q-value

Problema: aumento del tempo per stabilire una chiamata


2008 Aldo Campi

Trovare un Registrar Server locale


Ci sono diversi modi per trovare un Registrar
Richiesta REGISTER in multicast Inviare una richiesta a "sip.mcast.net" (224.0.1.75)
Si usa lindirizzo del primo server che risponde con un OK Se ci sono altre risposte OK si utilizzano in caso di fallimento Redirect ad un indirizzo unicast

Configurare manualmente Usare il DNS lookup sul nome di dominio

Atri meccanismi
DHCP
DNS SRV lookup fatto sul dominio ottenuto via DHCP Se nessun server stato trovato, query A or AAAA record

Service Location Protocol (SLP) In generale con un servizio di localizzazione


2008 Aldo Campi

Multicast Registration
Registrar Server: memorizza i dati di registrazione e risponde con OK

137.204.92.101

200 OK

137.204.92.45
User Agent: ignora la REGISTER Request

2
DB

REGISTER

1
137.204.92.1 137.204.92.61

DB

User Agent: memorizza lindirizzo di Contact in silenzio lindirizzo del Registrar 137.204.92.101

2008 Aldo Campi

Framework per lautenticazione SIP


SIP ha un meccanismo challenge-based basato sullautenticazione in HTTP (RFC 2617)
auth-scheme, auth-param, challenge, realm, realm-value, e le credenziali sono identici Per iniziare lautenticazione uso di: 401 (Unauthorized) o 407 (Proxy Authentication Required) Proxy-Authenticate, Proxy-Authorization, WWW-Authenticate e Authorization sono identici

HTTP digest authentication


basic authentication non usata (RFC 2543 era permessa) Autenticazione senza integrit del messaggio o confidenzialit "anonymous", senza password Unico Username/password per un gruppo di utenti (es: Gataway PSTN)

Massaggi speciali
ACK: non dotato di risposta, duplica tutti gli Authorization e Proxy-Authorization header cha sono nellINVITE CANCEL: non pu essere inviata di nuovo, il server la accetta se arriva dallo stesso Hop (transport o network layer security)

2008 Aldo Campi

Framework per lautenticazione SIP


Inizio della challenge (401 o 407)
Creazione della Realm strings da parte del server
Unica con hostname o domain name Forma human-readable Es: Authorization: Digest realm=unibo.test", <...>

nonce: stringa per la Digest (rfc2617)

Due tipi di contrattazione:


End-to-end
WWW-Authenticate: header per la contrattazione Authorization: header per lutenticazione

Proxy-to-User
Proxy- Authenticate: header per la contrattazione Proxy-Authorization: header per lutenticazione
2008 Aldo Campi

User-to-User Authentication
UAC: request -> UAS: 401 (Unauthorized) Risposta 401 (Unauthorized)
WWW-Authenticate: indica lo schema per lautenticazione e i parametri applicabili al realm

UAC inserice le credenziali nel nuovo messaggio, Authorization:


Memorizza le credenziali in relazione al: To header e "realm Se non ha credenziali pu provare con "anonymous" e senza password CSeq: va incementato
2008 Aldo Campi

Autenticazione: esempio di call flow


INVITE sip:bob@unibo.test 401 Unauthorized ACK INVITE sip:bob@unibo.test Authorization: Digest username=bob, realm=UNIBO, nonce=qf84..., response=50c6a6071bc8...

WWW-Authenticate: Digest realm=UNIBO, domain=sip:unibo.test, nonce=qf84..., stale=FALSE, algorithm=MD5

200 OK ACK

Il security domain individuato da realm e


URI della richiesta originale Il chiamante deve creare una nuova richiesta incrementando il valore di CSeq Attenzione: i parametri sono separati da virgole header-split non ammesso!
2008 Aldo Campi

Proxy-to-User Authentication
UAC: request -> UAS: 407 (Proxy Authentication Required)
Pi proxies durante il percorso possono richiedere lautenticazione

Risposta 407 (Proxy Authentication Required)


Proxy- Authenticate; si seguono le normali procedure delle risposte per lautenticazione

UAC inserice le credenziali nel nuovo messaggio, ProxyAuthorization:


Pi headers con le credenziali potrebbero essere necessari Proxy-Authorization con le crednziali per il realm Se non ha credenziali pu provare con "anonymous" e senza password CSeq: va incementato
2008 Aldo Campi

Autenticazioni multiple
UAC INVITE 407 Proxy Auth Req. ACK INVITE INVITE 401 Unauthorized 401 Unauthorized ACK INVITE ACK INVITE 180 Ringing 180 Ringing 200 OK ACK ACK 200 OK Proxy-Authorization: ... Authorization: ... WWW-Authenticate: ... Proxy-Authorization: ... Proxy-Authenticate: ... Proxy UAS

2008 Aldo Campi

Metodi di autenticazione in SIP


Validazione della identit del peer ovvero ne assicura lidentit
Il Registrar server non pu generare una risposta 6xx Di frequente uso di multicast e 302 (Moved Temporarily)

Hop-by-Hop
Uso di TLS + certificati, quando disponibili (generalmente servers)

UA-to-middle (infrastruttura)
Si autentica uno UA invece di un SIP server Richiede un sistema centralizzato Richiede un sistema di contrattazione

UA-to-UA
Uso di S/MIME e dei certificati X.509 (generalmente senza una CA condivisa) Alternativa: certificati self-signed (non in uso)
Permette di stabilire se si gi contattato un peer Stessa efficacia dell SSH; facile implementazione
2008 Aldo Campi

Asserted Identity e Transitive Trust Relationships


UAC stabilisce la connessione TLS
Proxy fornisce il certificato UAC verifica il certificato Autenticazione password-based per il chiamante P1 aggiunge P-Asserted-Identity:, firma il messaggio e lo instrada verso P2 ITSP B si fida dellAI firmato P4 e UAS si sono autenticati UAS si fida dellAI

Aggiunge P-AI

Certification Authority

ITSP A
P1 Verifica certificato UAC

P2

P3

ITSP B
P4

Accordi di Peering fra ITSP estesi a rapporti di fiducia per VoIP

UAS

2008 Aldo Campi

Privacy
Option-tag privacy per richiedere al proxy un trattamento dei dati Extension header Privacy:
Chi inizia la comunicazione pu specificare un livello di privacy richiesto Tipicamente gli hop devono rimuovere certi header
B2BUA

Differenti tipi di informazioni per la privacy (header, session, user)

Uso del meccanismo di asserted identity se richiesta una autenticazione


Necessita di relazioni di trust tra gli ITSP
2008 Aldo Campi

Session Description Protocol

2008 Aldo Campi

Descrizione di una conferenza


Informazioni necessarie per creare una sessione di conferenza
Chi? Convocare la sessione + indirizzo dei partecipanti Cosa? Nome e informazioni sullargomento Quando? Data e ora, periodica Dove? Indirizzi (multicast), numero di porta Quali media? Caratteristiche richieste Quanto? Banda richiesta etc

2008 Aldo Campi

Sessione di Conferenza
Session Description Protocol (SDP, RFC 2327)
Descrive una sessione di conferenza Procedura per negoziare una conferenza Indipendente da SIP: Session Announcement Protocol (SAP), e-mail (SMTP), web servers (HTTP), Netnews (NNTP) Definizione del tipo MIME per SDP: application/sdp

Distribuzione del contenuto della conferenza: Conference Configuration


Applicazione
Tipi di media, parametri dei media

Parametri di trasporto
Indirizzi IP, protocollo di trasporto, parametri del protocollo

Negoziazione dei parametri!


Sistemi eterogenei Hardware e software differenti Preferenze degli utenti

2008 Aldo Campi

Modello concettuale per la creazione di una sessione multimediale

A
Seleziona una o pi configurazioni ; determina i parametri di trasporto di A INVITO: Lista di applicazioni e configurazioni supportate RISPOSTA: Lista di applicazioni e conf. supportate da entrambi Configurazioni selezionate e parametri di trasporto di A

B
Trova corrispondenza fra le configurazioni di A e B

Determina i parametri di trasporto di B

Parametri di trasporto di B

2008 Aldo Campi

Negoziazione
Segnalazione: SIP
Capacit di negoziare con il modello Offerta/Risposta (RFC 3264)

Descrizione della sessione: SDP (RFC 2327)


Modello Offerta/Risposta Descrizione del contenuto

2008 Aldo Campi

SDP sintassi
Descrizione della sessione
v= (versione del protocollo) o= (origine della chiamata e identificazione) s= (nome della sessione) i=* (informazioni sulla sessione) u=* (URI per la descrizione) e=* (indirizzo di emai) p=* (numero di telefono) c=* (informazioni di connessione non richiesto se incluso nei media) b=* (informazioni sulla banda) descrittori del tempo ("t=" e "r= vedi sotto) z=* (aggiustamento della time zone) k=* (chiave di criptazione) a=* (attributi della sessione) descrittori dei media

Descrizione della tempistica


t= (tempo in cui la sessione attiva) r=* (intervallo di ripetizione)

Descrittori dei media, se presenti


m= (tipo dei media e indirizzo di trasporto) i=* (titolo dei media) c=* (informazioni di connessione opzionali se incluse nella descrizione di sessione) b=* (informazioni sulla banda) k=* (chiave di criptazione) a=* (attributi della sessione)

2008 Aldo Campi

SDP esempio
v=0 o=- 285442017 285442017 IN IP4 10.0.21.1 s= Lezione SIP i= Trasmissione della lezione sul protocollo SIP u= http://deisnet.deis.unibo.it/slides/SIP e= aldo.campi@unibo.it t=0 0 Porta a=type:test c=IN IP4 10.0.21.1 m=audio 16480 RTP/AVP 18 0 2 4 8 96 97 98 100 101 a=rtpmap:18 G729a/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 Codec a=rtpmap:96 G726-40/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:100 NSE/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv

Media stream

2008 Aldo Campi

Capacit di negoziazione SIP


SDP: Session Description Protocol, RFC 2327
Modello Offerta/Risposta

Il chiamante include lSDP nel body del messaggio INVITE (Offerta) Il chiamato risponde (es: 200 OK) con le sue caratteristiche per ogni media stream (m-part di SDP),
Indirizzo di destinazione: campo c= Porta e parametri dei media selezionati: campo m= Attributi: campo a=

Per eliminare uno stream si setta la sua porta nel campo m a zero
2008 Aldo Campi

Negoziazione dei Media durante linstaurazione di una chiamata


Caso normale Delayed description

INVITE Caps(A) 200 OK Caps(A) Caps(B)

INVITE 200 OK Caps(B)

ACK

ACK Caps(A) Caps(B)

2008 Aldo Campi

Modifica dei parametri della sessione


Tramite linvio di un re-INVITE che contiene un nuovo SDP
Nuovo indirizzo e porta Aggiungere/Rimuovere codec Aggiungere nuovi stream alla fine del messaggio

Il destinatario riassegna alla sessione i parametri correnti


Cambia i parametri degli stream Cancella gli stream (porta con valore zero) Aggiunge nuovi stream
2008 Aldo Campi

SDP in SIP

alice@192.168.1.1

bob@192.168.1.2 Alternative

INVITE sip:bob@192.168.1.2

v=0 o=alice 7595 1 IN IP4 192.168.1.1 s=Ciao di nuovo e=alice@unibo.test t=0 0 c=IN IP4 192.168.1.1 m=audio 46000 RTP/AVP 96 97 98 a=rtpmap:96 G129/8000 a=rtpmap:97 GSM-EFR/8000 a=rtpmap:98 PCMA/8000 m=audio 46002 RTP/AVP 99 a=rtpmap:99 telephone-events

Sessione multimediale aggiuntiva

2008 Aldo Campi

SDP in SIP

alice@192.168.1.1

bob@192.168.1.2

INVITE sip:bob@192.168.1.2
v=0 o=bob 5160 1 IN IP4 192.168.1.2 s=Ciao di nuovo e=bob@unibo.test t=0 0 c=IN IP4 192.168.1.2 m=audio 34000 RTP/AVP 98 a=rtpmap:98 PCMA/8000 m=audio 0 RTP/AVP 99 a=rtpmap:99 telephone-events

200 OK

La seconda sessione multimediale non supportata!

2008 Aldo Campi

SDP in SIP

alice@192.168.1.1

bob@192.168.1.2

INVITE sip:bob@192.168.1.2

200 OK

ACK

2008 Aldo Campi

Selezione dei Media e dei Codec in SDP


Pu contenere pi media stream (m=)
Il chiamato seleziona quelli appropriati per se stesso Indica i media non supportati imponendo port=0 I media si identificano e si accoppiano secondo lordine nellSDP

Si possono definire pi codec per un singolo media stream


Ordinati secondo le preferenze La risposta dovrebbe generare una lista di codec supportati per ogni stream
Possono essere aggiunti ulteriori codec

Selezione di un codec
Il chiamante propone alcuni codec, non pu cambiarli dinamicamente Il chiamato invia una lista di codec Il chiamante ne sceglie uno per la sessione
2008 Aldo Campi

Esempio di allineamento SDP


v=0 o=alice 7595 1 IN IP4 192.168.1.1 s=Chiamata SIP e=alice@unibo.test t=0 0 c=IN IP4 192.168.1.1 m=audio 52392 RTP/AVP 98 99 a=rtpmap:98 L8/8000 a=rtpmap:99 L16/8000 m=video 59485 RTP/AVP 31 a=rtpmap:31 H261/90000 v=0 o=bob 82347 1 IN IP4 192.168.1.2 s=Chiamata SIP e=bob@unibo.test t=0 0 c=IN IP4 192.168.1.2 m=audio 49823 RTP/AVP 98 a=rtpmap:98 L8/8000 m=video 0 RTP/AVP 31 a=rtpmap:31 H261/90000

Configurazione risultante:
:52392 alice@unibo.test 192.168.1.1 Streaming audio (L8/8000) (senza video) :49823 bob@unibo.test 192.168.1.2

2008 Aldo Campi

Sicurezza

2008 Aldo Campi

Requisiti di una rete VoIP


Servizi di base
Gestione di una o pi linee telefoniche e interni (telefoni) Gestione di servizi pi o meno evoluti (risponditore di cortesia, Call Center, caselle vocali, etc.)

Qualit, Stabilit, Affidabilit


Paragonabili alle linee telefoniche tradizionali

Sicurezza
Confidenzialit: il contenuto della comunicazione deve essere accessibile solo agli interessati. Disponibilit: il servizio deve essere sempre accessibile e disponibile agli utenti autenticati. Autenticazione: autenticazione per terminali, server e messaggi. Integrit: le comunicazioni devono essere autenticate e verificabili e non devono essere corrotte o modificate. Non ripudio: dellorigine e della destinazione, per chiamate voce e messaggi. Qualit del servizio QoS: garantire il rispetto del livello del servizio. SPAM telefonico

Il telefono un servizio primario

2008 Aldo Campi

Sicurezza
Il VoIP una tecnologia relativamente giovane e complessa che, almeno fino a poco tempo fa, veniva sviluppata senza prestare troppa attenzione alla sicurezza.
SIP is not an easy protocol to secure RFC 3261.

La telefonia su IP intrinsecamente meno sicura della telefonia tradizionale


Collegamento alla rete dati (bug, virus,worm, trojan, ecc.) Riduzione della sicurezza degli apparati di rete (NAT,Firewall) un guasto o un attacco riuscito alla rete dati pu bloccare anche il servizio voce e viceversa Attacchi interni: monitoring e intrusioni nelle chiamate

Servizi telefonici essenziali, "a meno che non siano pianificati, installati e mantenuti con molta cura, saranno pi a rischio di intrusioni se basati su VoIP" [NIST - National Institute of Standards and Technology].
2008 Aldo Campi

Perch?
Protezione della privacy
Criptazione dei media, chiamate anonime, servizi personalizzati, ...

Billing e accounting
Servizi a pagamento, uso della banda, etc

Regolamentazione
Blocco delle chiamate (Call id blocking) Perseguire gli abusi (call tracing) Chiamate di emergenza (Emergency call) Etc
2008 Aldo Campi

Aspetti di sicurezza
Apparati SIP sono esposti a numerosi attacchi che producono disservizi e frode
Man-in-the-middle (MITM)
SIP: Impersonare un Proxy Server, Risposte 302 e 305, Impersonare un Registrar Server RTP: modifica indirizzo IP

Denial of service (DoS)


Chiudere, modificare e cancellare una sessione, attacchi DoS SIP Identity spoofing (furto di identit)

Intercettazione e dirottamento delle chiamate (Hijacking)


Media Segnalazione

Analisi del traffico Uso del servizio non autorizzato Disturbo della connessione

2008 Aldo Campi

Hijacking
Vittima A Proxy SIP Attaccante Vittima B

INVITE: vittima B 100 Try INVITE: vittima B 301 Moved Permanently INVITE: vittima B 100 Try INVITE: vittima B 180 Ringing 180 Ringing

2008 Aldo Campi

DoS
Vittima A Proxy SIP Attaccante Vittima B

Sessione RTP

BYE: da vittima B 200 OK 200 OK

BYE: da vittima A

200 OK 200 OK

2008 Aldo Campi

Man in the Middle RTP


Vittima A Proxy SIP Attaccante Vittima B

Sessione RTP RE-INVITE: da vittima B 200 OK 200 OK 200 OK ACK: da vittima B ACK: da vittima A RE-INVITE: da vittima A

Sessione RTP

Sessione RTP

2008 Aldo Campi

Sicurezza in VoIP
Utilizzare le medesime tecniche e tecnologie impiegate per proteggere una struttura basata su IP:
Apparati di rete, es: Firewall Tecniche crittografiche Uso dei sistemi di sicurezza esistenti

Sicurezza di una infrastruttura SIP:


Applicativo
Implementazione, telefoni SIP -> PC

Trasporto
SIP in formato testo ed in chiaro

2008 Aldo Campi

Possibili soluzioni
Qualche contromisura attraverso luso di sistemi di sicurezza esistenti
Client e server authentication Autorizzazione delle richieste (Request authorization) Crittazione dei dati (segnalazione, media)
Controllo dellintegrit dei messaggi

Problemi:
ritardi nella trasmissione voce impossibilit di raggiungere o garantire i servizi pi banali

Common practices:
Separare il traffico voce su IP dal traffico dati laddove possibile Fare uso di switch in luogo di hub per usufruire di funzionalit pi elevate nonch di caratteristiche di sicurezza intrinseche. Accertarsi che tutti gli apparecchi telefonici siano dotati di password di accesso e che le password non siano quelle fornite dalla fabbrica (o di default). Fare uso di Firewall progettati per il traffico VOIP, i filtri stateful possono tracciare lo stato delle connessioni respingendo i pacchetti che non fanno parte della chiamata originaria Utilizzare tecniche di cifratura della comunicazione sia allesterno della rete aziendale che allinterno
Utilizzare tecniche di cifratura IPSEC o Secure Shell per tutta la gestione remota

2008 Aldo Campi

Sicurezza in SIP
SIP ha come meccanismi per aumentare il livello di sicurezza
Meccanismi di autenticazione del client verso il server; Riservatezza e integrit dei messaggi
TLS (Transaction Layer Security) RFC 2246 Derivato da SSL 3.0, un protocollo di livello 5 (Session Layer) in grado di garantire: Confidenzialit dei messaggi (cifratura simmetrica con chiave segreta DES, 3DES e scambio del segreto con Diffie-Helman o RSA); Autenticazione (opzionale con utilizzo di Certificati); Integrit (con funzioni di hash MD5 e SHA-1) Richiede un trasporto TCP IPSEC (IP Security) Framework in grado di gestire tecniche e protocolli in grado di garantire alti livelli di sicurezza su reti IP; Offre anche meccanismo di gestione delle chiavi (Internet Key Exhange); Implementazione a maggior impatto in rete;

2008 Aldo Campi

SIP Security: Segnalazione Hop-by-Hop, End-toEnd

UA

UA

Media Agent

Stream Multimediale: End-to-end

Media Agent

Dominio Azienda A

Dominio Service Provider

Dominio Azienda B

2008 Aldo Campi

Criptazione dei messaggi Hop-by-hop


Meccanismi di basso livello
Lapplicabilit dipende dalla tecnologia presente tra i due link

VPN-like tunnel usando IPSec


Adatto per mettere in comunicazione pi siti di una stessa entit amministrativa Comunque richiesto lIPv6 (NAT)

SIP su TLS (Transport Layer Security)


Accesso attraverso un outbound proxy Call routing verso ITSP Call routing tra ITSPs (necessita di accordi!) Nella maggior parte dei casi solo i server hanno i certificati

Chain of trust: opportuno per lautenticazione


Es: in trusted networks
2008 Aldo Campi

Hop-by-hop encryption con IPSec


SIP proxy server con supporto IPSec Terminale SIP con supporto IPSec Terminale SIP con supporto IPSec

SIP/UDP/IPSec

Possibile scenario

Non si usa IPSec nelle trusted networks, eventualmente altri meccanismi di sicurezza

IPSec tra host dentro lo stesso dominio amministrativo Relazione di fiducia prestabilita, chiavi condivise (pre-shared keys)

Sicurezza non dipendente da SIP


2008 Aldo Campi

SIP e TLS
Rapporti di fiducia intermedi

SIP/TLS/TCP

Lo UA stabilisce una trust association con il suo outbound proxy (TLS)


Solo TCP, il proxy deve supportare la segnalazione Utile se non presente una relazione di trust

Il proxy stabilisce le trust associations con gli altri Proxy o UA


Pu richiedere lo scambio di certificati

Il SIP informato del layer TLS


Es: Via headers

Problemi
Ritardi nella Call setup Risorse necessarie per le connessioni TLS 2008 Aldo Campi

Thanks
Aldo Campi aldo.campi (at) ieee.org