SIP: SessionInitiation Protocol - · 2 2008 Aldo Campi Introduzione al SIP 2008 Aldo Campi Gli...
68
1 SIP: Session Initiation Protocol Autore: Ing. Aldo Campi D.E.I.S. Università di Bologna Ringraziamento: Filippo Zangheri per le figure 2008 Aldo Campi 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 l’autenticazione • Sessione multimediale – Negoziazione (SDP) • Cenni di sicurezza
Transcript of SIP: SessionInitiation Protocol - · 2 2008 Aldo Campi Introduzione al SIP 2008 Aldo Campi Gli...
1
SIP: Session Initiation
Protocol
Autore: Ing. Aldo Campi
D.E.I.S. Università di BolognaRingraziamento: Filippo Zangheri per le figure
2008 Aldo Campi
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 l’autenticazione
• Sessione multimediale– Negoziazione (SDP)
• Cenni di sicurezza
2
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
• Dall’HTTP e dalla negoziazione delle Sessioni per avviare e controllare conferenze multimediali su rete a pacchetto
• Similitudini tra SIP e HTTP– Basati su testo
– Proxy
3
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 l’annuncio 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 parteciapanti
• 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
4
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 l’uso 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“
5
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
6
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!!!• Un’ottima guida alle specifiche RFC è:
– draft-ietf-sip-hitchhikers-guide-01.txt
7
2008 Aldo Campi
“Produttività”: pagine RFC
2008 Aldo Campi
“Produttività”: pagine RFC (VoIP + Audio)
8
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
PSTN
ISDN
PSTN
ISDNSIP
Gateway
SIP UA
SIP
Gateway
SIP UA
SIP
Gateway
SIP UA
Endpoint
SIP UA
Endpoint
SIP UA
Endpoint
SIP UA
Entità amministrativa
Location
Server
Redirect /
Proxy
ServerRegistrar
GSM
H.323Rete IP locale
Architettura SIP locale
9
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 l’URI con un altro URI dove l’utente 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 l’indirizzo 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 (Request–Response)
• 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
10
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 dell’end 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 l’invoco di servizi.
11
2008 Aldo Campi
Funzionalità SIP
• SIP non è un sistema verticale integrato di comunicazione. Uso di altri protocolli dell’IETF 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
12
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 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 da 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 transactionlayer
• comonente client (riferito alla client transaction) e comonente server (riferito alla server transaction)
• Macchina a stati finiti
– stateless proxies NON contengono una transaction layer
13
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 l’indirizzo 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
14
2008 Aldo Campi
Transactions
SIP TransactionsA B
Request
Provisional Responses
Final Response
crea
transaction
state
crea
transaction
state
distruggi
transaction
state
distruggi
transaction
state
• Approccio RPC-like:– Request iniziale
– Attesa di Final Response
• Provisional Responses:– Informazioni aggiuntive
– Possono essere inaffidabili
• Identificativo univoco (transactionID) (origine, destinazione, uniquetoken, sequence number, …)
• Completamento indipendente della transaction
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
A B
crea dialog
modifica
dialog
distruggi
dialog
inizializza
dialog
stabilisci
dialog
crea dialog
una transaction indica
transizione di stato
create
modify
modify
destroy
crea dialog
modifica
dialog
distruggi
dialog
15
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 l’uso 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 linearwhitespace (LWS)
• CRLF: carriage-return line-feed
16
2008 Aldo Campi
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
Sintassi del messaggio: Richiesta
INVITE sip:[email protected] SIP/2.0
To: Bob <sip:[email protected]>
From: Alice<sip:[email protected]>;
tag=4711
Max-Forwards: 70
Content-Length: 117
Content-Type: application/sdp
Call-ID: [email protected]
Cseq: 49581 INVITE
Contact: sip:[email protected]:5083;
transport=udp
Via: SIP/2.0/UDP 134.102.218.1;
branch=z9hG4bK776asdhds
Start line
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– ACK Conferma di un messaggio ricevuto (non nella transaction)
• La transaction ID può essere diversa, i parametri del dialogo sono quelli dell’INVITE– BYE Termina o trasferisce la chiamata (Distrugge il Dialogo)
• Solo per Dialoghi confermati– CANCEL Cancella ricerche o lo stato di ringing
• Solo per dialoghi non confermati– 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
17
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 l’utente 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
18
2008 Aldo Campi
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 l’indirizzo 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:[email protected]
• SIP Contact Address (locazione attuale)– sip:[email protected]– sip:[email protected]:9950
• Service identifier; semantica opaca all’utente– sip:[email protected]– sip:[email protected]– sip:[email protected]
• I parametri nell’URI possono portare informazioni aggiuntive:– sip:[email protected];maddr=10.0.0.1– sip:[email protected];user=phone
19
2008 Aldo Campi
Sintassi del messaggio : Risposta
SIP/2.0 200 OK
To: Bob <sip:[email protected]>;tag=428
From: Alice <sip:[email protected]>;
tag=4711
Subject: Congratulations!
Content-Length: 121
Content-Type: application/sdp
Call-ID: [email protected]
Cseq: 49581 INVITE
Contact: sip:[email protected]
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
Start line
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
20
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 l’interazione con l’utente– Il client non è obbligato ne a mostrare ne a processare la Reason-
Phrase (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
– L’ordine dei campi non è rilevante• I campi processati dai proxy dovrebbero essere primi
– Via, Route, Record-Route, Proxy-Require, Max-Forwards, and Proxy-Authorization, etc…
– L’ordine 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
21
2008 Aldo Campi
Body del messaggio
• In Richieste e in risposte (opzionale)– L’interpretazione 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 BINVITE
Ringing
OK
prepara media
session
Early dialog
stabilisci media
session, dialog
termina media
session;
distruggi dialog
crea media
session, dialog
termina media
session
distruggi
dialog
ACK
Media Streams
BYE
OK
sessione
multimediale
attiva
sessione
multimediale
attiva
Caso particolare: le
transaction INVITE
richiedono un three-
way handshake.
Early dialog
22
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 è un’eccezione
– 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
23
2008 Aldo Campi
Header Via:
• Via: contiene l’indirizzo (es:myaddress.com) dal quale l’end-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:[email protected]) verso il quale la richiesta era originariamente diretta (logical recipient) oppure l’AoR– Display names sono decritti in RFC 2822– Tag: parameter contiene una stringa random che è aggiunta
all’URI dallo UA. È utilizzata per l’identificazione.• presente solo a dialogo stabilito
• Può avere una dicitura “semplificata”– Es: “bob”. Processato dall’Home doman per lo "speed dial“
• Se non si vuole specificare il dominio si può utilizzare il tel URL.– Tel:113, processato dall’outbound proxy
24
2008 Aldo Campi
Header From:
• From: contiene il nome da mostrare (display name, Alice) e il SIP o il SIPS URI (sip:[email protected]) che indica chi ha dato origine alla richiesta oppure l’AoR– Tag: parameter contiene una stringa random che è aggiunta
all’URI dallo UA. È utilizzata per l’identificazione.– 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: automaticcall rejection)
• Usato per Display names:– Per lo stato “Anonymous” :
• Anonymous <sip:[email protected]>;tag=hyh8
• Usato per l’autenticazione
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 dell’host o dall’indirizzo 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
25
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 all’interno 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 l’end-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 l’uso 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.
26
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
27
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
28
2008 Aldo Campi
Scenari applicativi
2008 Aldo Campi
Scenario applicativo 1: Chiamata diretta UA–UA
Call signaling
Stream multimediali
InternetAlice Bob
29
2008 Aldo Campi
Chiamata diretta
unibo.testINVITE
100 Tying
180 Ringing
200 OK
ACK
Media Streams
BYE
200 OK
deis.test
[email protected] [email protected]
• Il chiamante (caller) conosce il nome host o l’indirizzo IP del chiamato (callee)
• L’UA destinatario riporta i cambiamenti di stato
• Quando Bob accetta la chiamata viene inviato l’OK
• L’UA chiamante conferma, la chiamata è stabilita
• Segue lo scambio di informazioni multimediali (es. RTP)
• La chiamata è terminata da uno dei due partecipanti
N.B.:
Il three-way handshake è
usato solo per richieste
di tipo INVITE.
2008 Aldo Campi
Chiamato rifiuta la comunicazione
unibo.test
INVITE
180 Ringing
603 Decline
ACK
deis.test
[email protected] [email protected]
L’utente locale
è contattato dal
SIP UA
chiamato.
L’utente clicca
“rifiuta”. L’UA
risponde di
conseguenza.
L’UA
chiamante
termina la
transaction.
30
2008 Aldo Campi
Chiamante abbandona la chiamata
unibo.test
INVITE
180 Ringing
ACK
deis.test
[email protected] [email protected] Try
CANCEL
200 OK
487 Request Terminated
L’utente locale è
contattato dall’UA
chiamato.
L’UA chiamato termina di
“squillare”, non viene
creato nessun stato di
chiamata.
Chiusura della
transaction INVITE.
L’utente locale
“riaggancia”.
Riuscito. Distruggi l’
“early dialog”.
Distruggi lo stato
della transaction e
termina l’INVITE.
2008 Aldo Campi
Chiamante abbandona a chiamata stabilita
unibo.test
INVITE
200 OK
ACK
deis.test
[email protected] [email protected] Ringing
CANCEL
200 OK
L’utente risponde. Il
transaction state per
INVITE viene distrutto.
Crea il dialog, stabilisci la
sessione multimediale.
Session teardown.
Distruggi il dialog.
L’utente chiamante
“riaggancia”.
Stabilisci il dialog.
…e trasmetti BYE!
Distruggi il dialog.
Termina l’INVITE…
BYE
487 Transaction does not
exist
Nessuna transaction
da annullare!
31
2008 Aldo Campi
Processamento atomico delle Transaction
INVITE
100 Trying (INVITE)
CANCEL
487 Terminated (INVITE)
ACK
• 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 l’una dall’altra!
200 OK (CANCEL)
INVITE transaction
INVITE transaction
Cancel transaction
2008 Aldo Campi
Come trovare il chiamato
• Chiamate dirette richiedono la conoscenza dell’indirizzo 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 l’indirizzo dell’utente
• Il chiamante invia un INVITE al SIP server che conosce la locazione dell’utente chiamato
• Il server può ridirigere la chiamata, rifiutarla o trasferirla
32
2008 Aldo Campi
Come trovare il next hop SIP
• Se la URI contiene l’indirizzo IP e la porta, il messaggio può essere inviato direttamente, altrimenti…
• Lo UA necessita di un SIP server per la segnalazione all’esterno
• 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 l’uso 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
12
34
Call signaling
Stream multimediali
InternetAlice Bob
Chiamalo
all’indirizzo … CPL: < Sono Bob,
ridirigi le chiamate
al mio attuale
indirizzo … >Chiamata per Bob
33
2008 Aldo Campi
Redirected Call
INVITE sip:[email protected]
302 Moved Temporarily
Contact: sip:[email protected];q=1
100 Trying
ACK
INVITE sip:[email protected]
200 OK
ACK
deis.testunibo.test
IP: 1.2.3.4
Lookup
utente
2008 Aldo Campi
Scenario applicativo 3: Proxied Call
12
34
Call signaling
Stream multimediali
InternetAlice Bob
CPL: < Sono Bob,
ridirigi le chiamate
al mio attuale
indirizzo … >Chiamata per Bob
Chiamata da
parte di Alice
34
2008 Aldo Campi
Proxied Call (stateless, stateful)
INVITE sip:[email protected]
100 Trying
ACK
deis.test
unibo.test
alice@
unibo.test [email protected]
deis.test
100 Trying
INVITE sip:[email protected]
200 OK200 OK
Media Streams
Lookup
server
Lookup
utente
2008 Aldo Campi
Scenario applicativo 4: Proxied Call (caso reale)
Call signaling
Stream multimediali
Alice Bob
Le Request tipicamente
•Seguono percorsi diversi
•Si biforcano
•Formano spirali
Le Response
Seguono sempre il percorso
inverso a quello della Request
originaria
35
2008 Aldo Campi
SIP Network: Connettività IP e Segnalazione SIP
2008 Aldo Campi
Architettura SIP Globale
SIP
Server
SIP
Server
SIP
Server
SIP
Server
SIP
Server
SIP
Server
SIP
Endpoint
SIP
Endpoint
SIP
Server
SIP
Server
SIP
Endpoint
SIP
Endpoint
Dominio SIP
Provider X
Dominio SIP
Provider Y
Dominio
SIP locale
SIP
backbone
Segnalazione SIP
per l’instradamento
iniziale e la negoziazione
della chiamata
Segnalazione SIP
durante la chiamata
Stream multimediale
(es. RTP)
36
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 UserAgents (B2BUAs)
2008 Aldo Campi
Proxy vs. B2BUA
• Proxy instrada e reindirizza le richieste
• B2BUA termina il dialogo: crea l’illusione 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.
UA 1Proxy
(stateful o
stateless)
UA 2Dialog X Dialog X
UA 1B2BUA(stateful)
UA 2Dialog X Dialog YU
A
1
U
A
2
37
2008 Aldo Campi
Scenario applicativo 4: Proxied Call (caso reale)
Call signaling
Stream multimediali
Alice Bob
Le Request tipicamente
•Seguono percorsi diversi
•Si biforcano
•Formano spirali
Le Response
Seguono sempre il percorso
inverso a quello della Request
originaria
2008 Aldo Campi
Request-Routing
• 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: nell’header identifica la presenza dell’utente
• Originale, peocessato dell’outboud proxy o servizio speed-dial– RFC3261: tag From: obbligatorio per l’identificazione della richiesta da parte di un
UAS
UA A P1
P2
P3
UA B
UA C
u1@P1u2@P2
u1@P3
u3@B
u3@B
u4@C
38
2008 Aldo Campi
Response Path: creazione del Via-path
• 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
UA A P1
P2
P3
UA B
UA C
Via: A
Via: P1
Via: A
Via: P1
Via: A
Via: P2
Via: P1
Via: A
Via: P3
Via: P1
Via: A Via: P3
Via: P1
Via: A
2008 Aldo Campi
Risposte multiple (Merging)
UA A P1
P2
P3
UA B
UA C
200 OK
Via: A
200 OK
Via: P1, A
408 Timeout
Via: P1, A
200 OK
Via: P2, P1, A
486 Busy
Via: P3, P1, A
• 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
408 Timeout
Via: P3, P1, A
39
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-Routeheader
– UA B memorizza la Record-Route per scopi futuri
• Risposta– UA B copia Record-Route
della richiesta dentro la risposta
UA A P1RR: r1
UA BP2RR: r2, r1
UA A P1 UA BP2RR: r2, r1RR: r2, r1RR: r2, r1
40
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 l’indirizzo di B trovato dal campo contactdella prima risposta
– Tutti i proxy instradano la richiesta seguendo la Route
• Risposta– UA B usa la stessa route
della risposta– UA B aggiunge l’indirizzo di
A nella risposta
UA A P1R: r2,rB
UA BP2R: rBR: r1, r2,rB
UA A P1 UA BP2R: r2’, r1’, rAR: r1’, rAR: rA
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
UA A P1
P2
P2’
UA B
UA B’
R:r1,r2,rB
41
2008 Aldo Campi
Cancellare le richieste
• 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 l’albero di ricerca quando arriva una risposta positiva (vedi P1)
UA A P1
P2
P3
UA B
UA C
200 OK
200 O
K
CANCEL
200 OK
CANC
EL
CANCEL
2008 Aldo Campi
Problemi delle risposte (Forking proxy) 1
• 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
UA A P1
UA B
UA C
INVITE
INVITE
INVITE180
401
180
42
2008 Aldo Campi
Problemi delle risposte (Forking proxy) 2
UA A P1
UA B
UA C
CANCELCANCEL
CANCEL200
• Nessuna risposta da C, A decide di annullare la transaction– CANCEL Request
401
2008 Aldo Campi
Problemi delle risposte (Forking proxy) 3
• 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!!!
UA A P1
UA B
UA C
401
487
ACK
401
487
43
2008 Aldo Campi
SIP Registration e Location
2008 Aldo Campi
Ricapitolando
INVITE sip:[email protected]
100 Trying
ACK
deis.test
unibo.test
alice@
unibo.test [email protected]
deis.test
100 Trying
INVITE sip:[email protected]
200 OK200 OK
Media Streams
Lookup
server
Lookup
utente
44
2008 Aldo Campi
User Location
• SIP server chiede al Location server dove trovare il chiamato
• Location server ritorna una lista di indirizzi (contactaddress)
• SIP proxy o redirect processa la richiesta in accordo con la lista di indirizzi (q= value) trovata
INVITE
SIP server
(proxy o redirect)
Location
server
DB
Trova
il chia
mato
Segnalazione SIP
Protocollo arbitrario
(fuori dagli scopi del SIP)
•Registrazioni esplicite
•Entry utmp
•Awareness protocols
•Finger, rwho
•LDAP, X.500, …
2008 Aldo Campi
User Location
DB134.102.218.57
Redirect /
Proxy
Server
Location
ServerRegistrar
Entità amministrativa
(SIP server)
sip:unibo.test
1
2
3
Recupera le informazioni
di registrazione dal DB
INVITE sip:[email protected] SIP/2.0
To: sip:[email protected]
From: sip:[email protected];tag=4711
Contact: sip:[email protected]
...
SIP/2.0 302 Moved Temporarily
Contact: sip:[email protected]
...
sip:[email protected] sip:[email protected]
45
2008 Aldo Campi
User Registration
DB
Redirect /
Proxy
Server
Location
ServerRegistrar
Entità amministrativa
(SIP server)
2
Salva le informazioni
di registrazione nel DB
137.204.92.23
137.204.92.25
1
3
REGISTER sip:unibo.test SIP/2.0
To: sip:[email protected]
From: sip:[email protected]
Contact: sip:[email protected]
...
SIP/2.0 200 OK
Expires: 3600
...
sip:unibo.test
sip:[email protected] sip:[email protected]
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 l’AoR per l’utente da registrare, cancellare, modificare– tipicamente sip:user@domain
• From: Contiene l’AoR dell’utente 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
46
2008 Aldo Campi
User Registration
• Header opzionali• Contact: informazioni per contattare l’utente 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 nell’header 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 l’utente
47
2008 Aldo Campi
Uso dei Contact: Parallel vs. Sequential Forking
• 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
DB
ChiamanteProxy
INVITE
Lookup “bob”408 T
imeout
408 Timeout
SIP-ISDN
GatewayINVITEsip:bob20921@voicemail
ISDN
4567890
pda-bob
jo
jo
jo
sip:bob@pda-bob
tel:+39-123-4567890
sip:bob20921@voicemail
q=0.8
q=0.8
q=0.1
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 l’indirizzo 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…
48
2008 Aldo Campi
Multicast Registration
DB
DB1
REGISTER
2
200 OK
User Agent:
ignora la REGISTER
Request
User Agent:
memorizza l’indirizzo di
Contact in silenzio
137.204.92.61
137.204.92.45
137.204.92.1
137.204.92.101Registrar Server:
memorizza i dati di
registrazione e risponde
con OK
l’indirizzo del Registrar
è 137.204.92.101
2008 Aldo Campi
Framework per l’autenticazione SIP
• SIP ha un meccanismo challenge-based basato sull’autenticazione in HTTP (RFC 2617)– auth-scheme, auth-param, challenge, realm, realm-value, e le credenziali sono
identici– Per iniziare l’autenticazione 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 nell’INVITE– CANCEL: non può essere inviata di nuovo, il server la accetta se arriva dallo
stesso Hop (transport o network layer security)
49
2008 Aldo Campi
Framework per l’autenticazione 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 l’utenticazione
– Proxy-to-User• Proxy- Authenticate: header per la contrattazione
• Proxy-Authorization: header per l’utenticazione
2008 Aldo Campi
User-to-User Authentication
• UAC: request -> UAS: 401 (Unauthorized)
• Risposta 401 (Unauthorized)– WWW-Authenticate: indica lo schema per
l’autenticazione 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
50
2008 Aldo Campi
Autenticazione: esempio di call flow
INVITE
401 Unauthorized
ACK
INVITE
200 OK
ACK
WWW-Authenticate: Digest realm=“UNIBO”,
domain=“sip:unibo.test”, nonce=“qf84...”,
stale=FALSE, algorithm=MD5
Authorization: Digest username=“bob”,
realm=“UNIBO”, nonce=“qf84...”,
response=“50c6a6071bc8...”
• 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 AuthenticationRequired)– Più proxies durante il percorso possono richiedere
l’autenticazione
• Risposta 407 (Proxy Authentication Required)– Proxy- Authenticate; si seguono le normali procedure delle
risposte per l’autenticazione
• UAC inserice le credenziali nel nuovo messaggio, Proxy-Authorization:– 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
51
2008 Aldo Campi
Autenticazioni multiple
INVITE
407 Proxy Auth Req.
INVITE
UAC
ACK
401 Unauthorized
INVITE
401 Unauthorized
ACKINVITE
INVITE
180 Ringing
180 Ringing200 OK
200 OK
ACKACK
Proxy UAS
Proxy-Authenticate: ...
Proxy-Authorization: ...
WWW-Authenticate: ...
Proxy-Authorization: ...
Authorization: ...
ACK
2008 Aldo Campi
Metodi di autenticazione in SIP
• Validazione della identità del peer ovvero ne assicura l’identità– 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
52
2008 Aldo Campi
Asserted Identity e Transitive Trust Relationships
ITSP A ITSP BP2
P1
UAC
P3
P4
Certification
AuthorityAggiunge
P-AI
• 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 dell’AI firmato
• P4 e UAS si sono autenticati
���� UAS si fida dell’AI
Verifica
certificato
UASAccordi di Peering fra
ITSP estesi a rapporti
di fiducia per VoIP
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
53
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 sull’argomento
– Quando? Data e ora, periodica
– Dove? Indirizzi (multicast), numero di porta
– Quali media? Caratteristiche richieste
– Quanto? — Banda richiesta
– etc…
54
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: ConferenceConfiguration– 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 B
INVITO:
Lista di applicazioni e
configurazioni supportate
RISPOSTA:
Lista di applicazioni e conf.
supportate da entrambi
Configurazioni selezionate e
parametri di trasporto di A
Parametri di trasporto di B
Trova
corrispondenza
fra le
configurazioni
di A e B
Seleziona una
o più
configurazioni;
determina i
parametri di
trasporto di A
Determina i
parametri di
trasporto di B
55
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)
56
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
t=0 0
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
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
Codec
Porta
2008 Aldo Campi
Capacità di negoziazione SIP
• SDP: Session Description Protocol, RFC 2327– Modello Offerta/Risposta
• Il chiamante include l’SDP 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
57
2008 Aldo Campi
Negoziazione dei Media durante l’instaurazione di una chiamata
INVITE
Caps(A)
200 OK
Caps(A) ∩∩∩∩ Caps(B)
BA
ACK
INVITE
200 OK
Caps(B)
BA
ACK
Caps(A) ∩∩∩∩ Caps(B)
“Delayed description”Caso normale
2008 Aldo Campi
Modifica dei parametri della sessione
• Tramite l’invio 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
58
2008 Aldo Campi
v=0
o=alice 7595 1 IN IP4 192.168.1.1
s=Ciao di nuovo
t=0 0
c=IN IP4 192.168.1.1
SDP in SIP
[email protected] [email protected]
INVITE sip:[email protected]
m=audio 46002 RTP/AVP 99
a=rtpmap:99 telephone-events
m=audio 46000 RTP/AVP 96 97 98
a=rtpmap:96 G129/8000
a=rtpmap:97 GSM-EFR/8000
a=rtpmap:98 PCMA/8000
Alternative
Sessione
multimediale
aggiuntiva
2008 Aldo Campi
SDP in SIP
v=0
o=bob 5160 1 IN IP4 192.168.1.2
s=Ciao di nuovo
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
[email protected] [email protected]
INVITE sip:[email protected]
La seconda sessione
multimediale non è
supportata!
200 OK
59
2008 Aldo Campi
SDP in SIP
[email protected] [email protected]
INVITE sip:[email protected]
200 OK
ACK
Nessun contenuto SDP
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 l’ordine nell’SDP
• 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
60
2008 Aldo Campi
Esempio di allineamento SDP
v=0
o=alice 7595 1 IN IP4 192.168.1.1
s=Chiamata SIP
t=0 0
c=IN IP4 192.168.1.1
a=rtpmap:98 L8/8000
a=rtpmap:99 L16/8000
a=rtpmap:31 H261/90000
v=0
o=bob 82347 1 IN IP4 192.168.1.2
s=Chiamata SIP
t=0 0
c=IN IP4 192.168.1.2
a=rtpmap:98 L8/8000
a=rtpmap:31 H261/90000
m=audio 49823 RTP/AVP 98
m=video 0 RTP/AVP 31
m=audio 52392 RTP/AVP 98 99
m=video 59485 RTP/AVP 31
Configurazione risultante:
192.168.1.1
:52392
192.168.1.2
:49823Streaming audio (L8/8000)
(senza video)
2008 Aldo Campi
Sicurezza
61
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: dell’origine 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].
62
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
63
2008 Aldo Campi
Hijacking
INVITE: vittima B
100 Try
301 Moved Permanently
Vittima A Proxy SIP Vittima BAttaccante
INVITE: vittima B
INVITE: vittima B
100 TryINVITE: vittima B
180 Ringing
180 Ringing
2008 Aldo Campi
DoS
Vittima A Proxy SIP Vittima BAttaccante
Sessione RTP
BYE: da vittima B BYE: da vittima A
200 OK
200 OK
200 OK
200 OK
64
2008 Aldo Campi
Man in the Middle RTP
RE-INVITE: da vittima B
Vittima A Proxy SIP Vittima BAttaccante
200 OK
Sessione RTP
RE-INVITE: da vittima A
200 OK
200 OK
ACK: da vittima B
ACK: 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
65
2008 Aldo Campi
Possibili soluzioni
• Qualche contromisura attraverso l’uso di sistemi di sicurezza esistenti– Client e server authentication– Autorizzazione delle richieste (Request authorization)– Crittazione dei dati (segnalazione, media)
• Controllo dell’integrità 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 all’esterno della rete aziendale che all’interno
• 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;
66
2008 Aldo Campi
SIP Security: Segnalazione Hop-by-Hop, End-to-End
UAP
Media
Agent
UA
Media
Agent
P P P P
Stream Multimediale: End-to-end
Dominio
Azienda A
Dominio
Azienda B
Dominio Service Provider
2008 Aldo Campi
Criptazione dei messaggi Hop-by-hop
• Meccanismi di basso livello– L’applicabilità 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 l’IPv6 (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 l’autenticazione– Es: in trusted networks
67
2008 Aldo Campi
Hop-by-hop encryption con IPSec
• Possibile scenario– IPSec tra host dentro lo stesso dominio amministrativo
– Relazione di fiducia prestabilita, chiavi condivise (pre-shared keys)
• Sicurezza non dipendente da SIP
Terminale SIP
con supporto IPSec
Terminale SIP
con supporto IPSec
SIP/UDP/IPSec
SIP proxy server con supporto IPSec
Non si usa IPSec nelle
trusted networks,
eventualmente altri
meccanismi di sicurezza
2008 Aldo Campi
SIP e TLS
SIP/TLS/TCP
Rapporti di fiducia intermedi
• 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
68
Thanks
Aldo Campi
aldo.campi (at) ieee.org
