Sip

SIP - Session Initiation Protocol

Anno Accademico 2010/11
VoIP Slide 95

Descrive solo come aprire una sessione multimediale tra due utenti.

Introduzione - 1 Poi ci faccio quello che voglio

•! Sviluppato nel gruppo mmusic del IETF (RFC 2543, marzo 1999) e
aggiornato nel gruppo sip (RFC 3261, giugno 2002)
•! Protocollo di controllo sviluppato a livello di applicazione, che permette
di instaurare, modificare e abbattere chiamate o sessioni multimediali
•! Protocollo client server, che utilizza molte funzionalità del protocollo
HTTP 1.1 (RFC 2616) messaggi che hanno un formato testuale. Molto esplicativo

–! Testuale, Request/Response, Codici di risposta, Alcuni campi
dell’intestazione ha i codici di risposta simili all'HTTP. se ho un codice sul 400 c'è un errore.

•! Funzioni molto flessibili per lo sviluppo di servizi avanzati
–! L’utilizzo delle funzionalità del protocollo HTTP 1.1 permette lo sviluppo di
applicazioni integrate in server SIP/web gestiti da un singolo amministratore
•! Indipendentemente dal protocollo di trasporto utilizzato (TCP o UDP),
viene garantita l'affidabilità della segnalazione UDP senza stare risposta TCP e tutti i suoi problemi. Se non
faccio rischiesta
a usare
a livello applicativo. Posso usare

ricevo la risposta, lo rimando.
•! Protocollo leggero
–! Prima versione con 6 metodi, 37 campi di intestazione, la maggior parte è
autodescrittivo
VoIP Slide 96

Introduzione - 2
in H323 erano 3 fasi ben distinte. Qui mando un solo messaggio che trova l'utente, lo
invita e dice le caratteristiche della chiamata. In un singolo RTT io posso già chiamare.

•! Fase di setup della connessione molto veloce
–! combina “ricerca posizione utente/invito/caratteristiche della chiamata” in un RTT
•! Scalabile, Modulare e Semplice
–! utilizza altri protocolli IP per aggiungere funzionalità
•! Protocolli impiegati per altre funzionalità
–! RSVP ReSource reserVation Protocol (RFC 2205) per la prenotazione delle risorse di
rete
–! RTP Real Time Protocol (RFC 1889/RFC 3550) per il trasporto di informazioni real
time e riscontro al trasmettitore sulla QoS a livello di rete osservato dal ricevitore
–! RTSP Real Time Streaming Protocol (RFC 2326) per il controllo del trasporto di
streaming di dati multimediali
–! SAP Session Announcement Protocol (RFC 2974) per l’annuncio di sessioni
multimediali attaverso comunicazioni multicast
–! SDP Session Description Protocol (RFC 2327) per la descrizione delle sessioni
multimediali
–! MEGACO Media GAteway Control (RFC 3525) per la descrizione del protocollo
utilizzato per la comunicazioni fra elementi di gateway decomposti
–! TLS Transmission Layer Security (RFC 2246) per comunicazioni sicure
VoIP Slide 97

Introduzione - 3

•! Caratteristiche fondamentali del protocollo
–! L’identificativo è dell’utente e non del terminale, come per l’e-
mail. Quindi l’utente può accedere al servizio da terminali diversi
(personal mobility) o l’identificativo di utente può essere associato
a diversi terminali con funzionalità diverse
–! Approccio client-server testuale simile al protocollo HTTP
–! Il protocollo è disaccoppiato dalla descrizione della sessione da
instaurare. La descrizione è fatta mediante l’uso del protocollo SDP.
Questa caratteristica rende possibile invitare ad una sessione da un
host senza che questo sia coinvolto nella sessione stessa

•! Implementazioni
–! http://www.cs.columbia.edu/sip/implementations.html
–! http://www.pulver.com/products/sip/
–! http://www.iptel.org/views/Product_Database
–! http://jcp.org/en/jsr/detail?id=289

VoIP Slide 98

Funzionalità del protocollo - 1

•! User location
–! determinazione del sistema con il quale instaurare la comunicazione
•! User capabilities
–! determinazione dei media e dei loro parametri da utilizzare durante
la comunicazione
•! User availability
–! determinazione della disponibilità del chiamato ad instaurare la
comunicazione
•! Call setup
–! suoneria e instaurazione dei parametri della chiamata in entrambi i
lati della comunicazione
•! Call handling
–! trasferimento e chiusura della chiamata

VoIP Slide 99

Funzionalità del protocollo - 2
•! Estensione del protocollo per svolgere le funzioni
necessarie per la richiesta ed il trasporto di
informazioni dei servizi di messaggistica istantanea
e presence service. Queste funzioni sono
–! distribuzione ed impostazione delle informazioni per
presence service;
–! notifica di eventi associati ai presence service (come per
esempio la notifica del cambiamento di stato di un
utente, da on line a off line o viceversa);
–! trasporto di informazioni dei servizi di messaggistica
istantanea

VoIP Slide 100

Componenti dell’architettura SIP - 1

•! RFC 3261 definisce alcuni elementi base
–! User Agent Client (UAC)
•! Entità logica che crea una nuova richiesta, e utilizza la macchina a
stati finiti del terminale utente per trasmetterla
–! User Agent Server (UAS)
•! Entità logica che genera una risposta alla ricezione di una richiesta.
La risposta può accettare, rifiutare o ridirigere su un’altro UAS la
richiesta
–! Proxy Server
•! Server di rete che determina il prossimo server (UAS o Proxy) a cui
inoltrare la richiesta e la inoltra (l’UA può funzionare come Proxy
server).
–! Può spedire le richieste su diversi server, creando un albero per
l’inoltro della chiamata all’utente chiamato
–! Riveste il ruolo di UAS, quando risponde direttamente ad una
richiesta dello UAC

VoIP Slide 101

•! I SIP Proxy Server si possono classificare

–! Stateless, il proxy elabora le richieste e le risposte SIP utilizzando
solo le informazioni contenute nel messaggio. Una volta inoltrata la
richiesta, viene cancellata qualunque informazione che la riguarda

–! Stateful, il proxy mantiene le informazioni raccolte nelle richieste e
nelle risposte elaborate, e le utilizza per l’elaborazione di messaggi
successivi
•! Uso di timer per la gestione dell’affidabilità del messaggio trasmesso
•! Procedure per l’autenticazione dello UA

–! Transaction stateful, il proxy mantiene le informazioni solo per il
tempo necessario alla conclusione della transazione in atto

VoIP Slide 102

Elementi derivati da quelli base
–! User Agent (UA)
•! Entità logica che si comporta sia come UAC che UAS (UA = UAC + UAS)
•! Terminali Software
–! X-Lite / X-pro / Eyebeam, Siemens SCS, Linphone, kphone
•! Terminali Hardware: CISCO 7960, 7920, …, Snom 190, Zyxel Wi-Fi phone
–! Presence Agent
•! Applicazione capace di ricevere delle richieste di controllo e di generare
i messaggi necessari per i presence service

CISCO 7960
Zyxel Wi-Fi phone Estara Softphone

eyeBeam
VoIP Slide 103

Altro elemento derivato da quelli base, RFC 3261
•! Back-to-Back User Agent (B2BUA)
–! apparato che ha il compito di ricevere una richiesta/risposta SIP, di
formulare e trasmettere una nuova richiesta/risposta attraverso
l’elaborazione di quella ricevuta
–! il B2BUA può permettere la comunicazione fra due UA SIP,
nascondendo gli indirizzi URI ed altre informazioni sensibili
–! le modifiche fatte nella descrizione SDP contenuta nel corpo dei
messaggi saranno tali da far terminare sul B2BUA i canali logici
•! Svantaggi del suo utilizzo
–! eliminazione della natura end-to-end del protocollo SIP
–! la creazione nel B2BUA di un punto critico per il servizio
–! l’inserimento di un elemento che deve inoltrare il traffico relativo ai
media coinvolti nelle diverse sessioni SIP attive
•! Uso di una rete di B2BUA

VoIP Slide 104


Altri elementi derivati da quelli base e che assumono nomi diversi,RFC
3261
•! Registrar server
–! Un tipo speciale di UAS che accetta le richieste di registrazione fatte dagli
utenti e inserisce le informazioni contenute in esse nel location service del
dominio a cui appartiene
–! Mantiene la posizione dell’utente interagendo con un Location Server (come
HLR del GSM)
•! Gateway SIP
–! Apparato per interfacciare utenti SIP con quelli che usufruiscono di servizi
simili usando altre tecnologie
–! Sul lato SIP, il Gateway è semplicemente uno UA che invece di interagire
direttamente con un essere umano interagisce con un protocollo
–! Diversamente da uno UA, un gateway supporta un numero di utenti elevato
che può essere anche nell’ordine di migliaia
–! Esempi: SIP-H.323, SIP-PSTN

VoIP Slide 105


•! Altri elementi derivati da quelli base e che assumono nomi diversi,
(non definiti come elementi standard nella RFC 3261)

–! Redirect Servers
•! Tipo speciale di UAS che interrogando il location service
determina e comunica a chi gli ha inoltrato la richiesta (UAC o
Proxy Server) il prossimo server a cui ridirigere tale richiesta
(usato per migliorare la scalabilità)

–! Outbound proxy
•! Un tipo speciale di proxy che riceve le richieste da un UAC ed inoltra I
messaggi di segnalazione associati alle richieste (viene generalmente
configurato manualmente su un UA ed usato per assistere il terminale
in presenza di firewall e/o certe tipologie di NAT)

VoIP Slide 106

Architettura SIP

SIP Redirect
Server
Richiesta
Risposta Location
Server

SIP Proxy SIP Proxy

UAC SIP
SIP Proxy
UAS SIP

VoIP Slide 107

Indirizzi SIP
•! SIP offre degli indirizzi di raggiungibilità globale (sia
temporale che spaziale)
–! Il chiamato associa il suo indirizzo locale a quello globale utilizzando
il metodo REGISTRER
–! Il chiamante utilizza l’indirizzo globale per contattare il chiamato
•! Gli indirizzi SIP sono URL (Uniform Resource Locators, RFC
1738)
–! Usati per indicare nei messaggi SIP il chiamante (From), la
destinazione corrente (Request-URI), il chiamato (To) e l’eventuale
indirizzo di ridirezione (Contact)
•! Formato SIP:user:password@host:port;option
–! sip:rgarroppo@unipi.it:5067
–! sip:rosario:passwd@unipi.it
–! sip: +390502217621@gateway.unipi.com;user=phone
–! sip: rgarroppo@unipi.it;transport=tcp
VoIP Slide 108

Metodi SIP
•! INVITE
–! indica che l’utente o il servizio è invitato a partecipare ad una sessione
–! permette la modifica delle caratteristiche della sessione in corso
•! BYE
–! serve per comunicare agli altri partecipanti l’intenzione di abbandonare la sessione
•! CANCEL
–! serve per cancellare una richiesta pendente (cioè quando il UAC non ha ricevuto la
risposta dal UAS). La richiesta è individuata dai campi Call-ID, To, From e Cseq
•! OPTIONS
–! il UAC chiede al UAS o ad un Proxy SIP le sue funzionalità
•! ACK
–! conferma che il UAC ha ricevuto una risposta finale ad una sua richiesta di INVITE
•! REGISTER
–! permette al UAC di notificare ad un server SIP a quale indirizzo può essere raggiunto.
Può essere usato all’accensione di un UAC , o durante spostamenti di un utente,
utilizzando l’indirizzo multicast 224.0.1.75 (sip.mcast.net) o unicast (qualora venisse
indicato nella fase di configurazione l’indirizzo del Registar di riferimento)

•! Metodi di estensione del SIP (REFER, INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY/ MESSAGE)

VoIP Slide 109

Sintassi dei messaggi SIP: Richieste
•! Molti campi dell’intestazione Metodo Request-URI
sono presi dal protocollo HTTP
1.1 INVITE sip:homer@psrt.it SIP/2.0 Start-line
Via: SIP/2.0/UDP 10.0.0.3:5060;
From: Bart Simpson <sip:bart@psrt.it>;tag=125831

Intestazione
•! Alcuni sono specifici del To: <sip:homer@psrt.it>
Contact: <sip:bart@10.0.0.3:5060>
protocollo SIP (Also, Replaces, Call-ID: 4F33BACA-52EE@10.0.0.3
Via) CSeq: 51702 INVITE
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 301
•! Il campo dati contiene una
descrizione dei media utilizzati v: 0
Campo Dati o: bart 1679674672 1679674672 IN IP4 10.0.0.3
s: SIP Call
c: IN IP4 10.0.0.3
•! SDP - Session t: 0 0
Description Protocol m: audio 3000 RTP/AVP 0 8

VoIP Slide 110

Sintassi dei messaggi SIP: Risposte
Status code Reason Phrase
Status Code
SIP/2.0 200 OK Start-line •!1XX (Provisional): richiesta ricevuta,
Via: SIP/2.0/UDP 10.0.0.3:5060 richiesta in fase di elaborazione
Intestazione

To: <sip:homer@psrt.it>;tag=73149de9 •!2XX (Success): richiesta accettata
Call-ID: 4F33BACA-52EE@10.0.0.3
CSeq: 51702 INVITE
•!3XX (Redirection): altre azioni sono
Content-Type: application/sdp necessarie per soddisfare la
Content-Length: 301 richiesta
•!4XX (Request Failure): la richiesta
o: homer 1357281516 1357281516 IN IP4 10.0.1.4
Campo Dati

s: SIP Call contiene errori o non può essere
c: IN IP4 10.0.1.4 soddisfatta
t: 0 0
m: audio 3002 RTP/AVP 0 8 •!5XX (Server Failure): si è verificato
un errore nel server
•!6XX (Global Failure): la richiesta
non può essere soddisfatta in nessun
server

VoIP Slide 111

Esempi di Codici di risposte SIP
•! 1yz Informational •! 4yz Client error
–! 100 Trying –! 400 Bad Request
–! 180 Ringing (processed –! 401 Unauthorized
locally) –! 482 Loop Detected
–! 181 Call is Being –! 486 Busy Here
Forwarded
•! 5yz Server failure
•! 2yz Success –! 500 Server Internal Error
–! 200 ok
•! 6yz Global Failure
•! 3yz Redirection –! 600 Busy Everywhere
–! 300 Multiple Choices
–! 301 Moved Permanently
–! 302 Moved Temporarily

VoIP Slide 112

Alcuni concetti importanti
•! SIP transaction
–! Un messaggio SIP (e qualunque altra
sua ritrasmissione) e la relativa
risposta diretta
–! I messaggi di una particolare SIP
transaction sono individuati dal
campo CSeq dell’intestazione
•! SIP dialog
–! Una relazione tra almeno due
terminali SIP che rimane attiva per
un certo tempo
–! I messaggi di un SIP dialog sono
individuati dal campo Call-ID, “From
tag” e “To tag”
•! SIP Session
–! Una trasmissione di informazioni
multimediali fra terminali SIP

Per associare una risposta alla corretta richiesta è necessario individuare sia il
SIP dialog sia il SIP transaction
L’assocciazione richiesta-risposta viene fatta usando i campi Call-ID, “From (tag)”,
“To (tag)” e Cseq
VoIP Slide 113

Indirizzi nelle intestazioni dei messaggi SIP

•! From: indirizzo di chi ha generato il messaggio
•! To: indirizzo del destinatario finale del messaggio
•! Request-URI: indirizzo del destinatario corrente del
messaggio; può essere modificato durante il percorso
•! Contact: è presente nei messaggi di richiesta INVITE,
OPTIONS, ACK e REGISTER, e nelle relative risposte. Indica
l’indirizzo diretto dove trasmettere i successivi messaggi.
–! Un UA può trasmettere messaggi BYE o ACK all’indirizzo Contact
–! Può indicare gli indirizzi di ridirezione nelle risposte 3xx e 485
–! Può indicare informazioni addizionali alle risposte di errore 4xx, 5xx
e 6xx
–! Può indicare la posizione corrente dell’utente che invia una
richiesta REGISTER
–! Possono essere inclusi più campi Contact

VoIP Slide 114

Informazioni trasportate dal protocollo SDP - 1
•! Tipo di media stream (audio, video, v protocol version
applicazione, controllo) o owner/creator CODICI
s session name
•! Indirizzi per ogni stream (stream diversi u URL description
possono avere indirizzi diversi, es. video su una e email address
workstation, audio su un PC) p phone number
•! Numero di porta UDP/TCP per ogni stream c connection information
b bandwidth available/required (Kbps)
•! Tipo di formato del media (codificatore etc.) k encryption key
•! Per sessioni broadcast (es. diffusione TV) a attributes
–! Start e stop time t start and stop time
m media name and transport address
–! Originator
u=http://www.ietf.org
•! N.B.: SDP è un formato di rappresentazione di m=audio 3456 RTP/AVP 96
dati piuttosto che un protocollo m=video 3458 RTP/AVP 31
a=orient:portrait
v=0 t=0 3086272736
o=user1 53655765 279957765 IN IP4 128.3.4.5
s= Mbone audio
e=mbone@somewhere.com
m=audio 3456 RTP/AVP 0
http://www.iana.org/assignments/rtp-parameters
http://www.iana.org/numbers.htm
VoIP Slide 115

Informazioni trasportate dal protocollo SDP - 2

Status code Reason Phrase

SIP/2.0 200 OK Start-line
Via: SIP/2.0/UDP 10.0.0.3:5060
Header

To: <sip:homer@psrt.it>;tag=73149de9
Call-ID: 4F33BACA-52EE@10.0.0.3
CSeq: 51702 INVITE
Content-Type: application/sdp
Content-Length: 301 Il chiamato (che ha trasmesso questa
risposta) informa il chiamante che è
o: homer 1357281516 1357281516 IN IP4 10.0.1.4 disponibile a ricevere informazioni
s: SIP Call
audio, codificate “0” o “8”
Body

c: IN IP4 10.0.1.4
t: 0 0 all’indirizzo IP 10.0.1.4 (campo “c”)
m: audio 3002 RTP/AVP 0 8 ed alla porta (3002) mediante il
protocollo RTP

VoIP Slide 116

Localizzazione di un Utente
Il Location Service permette di localizzare l’utente che si vuole
contattare

•! I server Proxy devono determinare la posizione dell’utente
–! L’utente può cambiare il terminale e la sua posizione nella rete
–! Questi server usano il Location Service
•! Registrar accetta le richieste REGISTER, con le quali gli utenti
aggiornano la loro posizione nella rete. Esso può essere co-locato in un
Proxy Server e interagisce con il Location Server
•! Il Location Service è fuori dagli scopi del protocollo SIP
–! Esso può essere fornito tramite diverse soluzioni
•! LDAP (Lightweight Directory Access Protocol, RFC 1777) , rwhois (RFC
2167), finger (RFC 1288)
•! richieste a database dell’Intranet
•! file locali

VoIP Slide 117

Localizzazione di un server SIP

Quando il client SIP vuole effettuare una chiamata ha due
possibilità
•! trasmettere il messaggio INVITE ad un server SIP locale
•! trasmettere il messaggio INVITE all’indirizzo IP ed alla
porta del UAS, dove si trova l’utente che si vuole
contattare
–! In questo caso, il client deve determinare il protocollo di trasporto,
la porta e l’indirizzo IP dell’UAS a cui mandare la richiesta
–! Parametri di default: UDP, porta 5060

–! Per recuperare l’indirizzo o gli indirizzi dell’agente UAS del
chiamato
•! Se la parte host dell’indirizzo chiamato è un indirizzo IP, il chiamante
prova a contattare il server a questo indirizzo
•! Altrimenti, il chiamante contatta un server DNS

VoIP Slide 118

Interazione SIP-DNS
•! La RFC 3263 indica che l'indirizzo IP, la porta e il protocollo
di trasporto da usare per dialogare con server SIP (UAS o
Proxy) devono essere determinati attraverso un server DNS"
•! Tipologie di record DNS usate da SIP: SRV e NAPTR"
–! I record SRV, RFC 2782 [5], sono nella forma"

_Service._Proto.Name TTL Class SRV Priority Weight Port Target
_sip._udp.psrt.it 40000 IN SRV 10 10 5060 proxy.psrt.it

–! Come indicato nella RFC 3263, record NAPTR servono per
determinare la tipologia di trasporto da usare per accedere ad un
servizio. I record NAPTR sono nella forma"

domain-name TTL Class NAPTR order pref flags service regexp replacement
psrt.it 43000 IN NAPTR 60 50 “s” “SIP+D2U” “” _sip._udp.psrt.it
VoIP Slide 119

Risoluzione di un indirizzo SIP
•! Situazione Normale
–! Query NAPTR
–! Query SRV
–! Query A/AAA
•! Casi particolari
–! L’utente indica la porta, oppure l’indirizzo è numerico
•! Viene al più risolto l’indirizzo con una query A/AAA senza
interessare i record NAPTR/SRV
–! Record non esistenti
•! NAPTR: se non esiste viene richiesto il SRV
–! La scelta del protocollo di trasporto viene demandata all’utente (UDP)
•! SRV: se non esiste, si prova con A/AAA
–! Viene usata la porta standard

VoIP Slide 120

Esempio configurazione di un server DNS

VoIP Slide 121

Architettura a trapezio (solo indirizzi SIP)

Server Location
DNS Server

DNS

Outbound SIP Inbound
SIP Proxy SIP Proxy

SIP SIP

SIP

UAC UAS
Media (RTP)

VoIP Slide 122

Chiamata tra utenti SIP con indirizzi E.164

Senza ENUM PSTN

proxy.opA.int
proxy.opB.int

gw.opA.int gw.opB.int
Operatore A
Operatore B

VoIP Slide 123

Chiamata tra utenti SIP con indirizzi E.164
Soluzione con ENUM (Electronic Numbering), RFC 3761

DNS Server

INVITE verso SIP user ricavato da NAPTR

proxy.opA.int
proxy.opB.int

gw.opA.int gw.opB.int
Operatore A
Operatore B

VoIP Slide 124

Formazione del nome DNS da ind. E.164
•! ENUM prevede che ogni numero E.164 sia rappresentato
mediante un nome DNS
–! La zona ufficiale è e164.arpa; definizione di zone alternative
private
•! Procedura per il passaggio da E.164 a nome DNS
–! numero di telefono internazionale (ad esempio +39 050 2217621)
–! si eliminano tutti i caratteri che non siano delle cifre
(390502217621)
–! si separano le varie cifre con il carattere “.” e si inverte il loro
ordine (1.2.6.7.1.2.2.0.5.0.9.3)
–! Si aggiunge il suffisso della zona di riferimento, per es.
e164.namex.it ottengo 1.2.6.7.1.2.2.0.5.0.9.3.e164.namex.it

VoIP Slide 125

Risposta ad una query da parte del DNS
Internet Protocol, Src: 131.114.21.15 (131.114.21.15), Dst: 131.114.53.78 (131.114.53.78)
User Datagram Protocol, Src Port: domain (53), Dst Port: isi-irp (3226)
Domain Name System (response)
[Request In: 964]
[Time: 0.224958000 seconds]
Transaction ID: 0x000e
Flags: 0x8180 (Standard query response, No error)
Questions: 1
Answer RRs: 1
Authority RRs: 1
Additional RRs: 1
Queries
0.0.0.9.4.2.6.1.9.4.3.nrenum.net: type NAPTR, class IN
Answers
0.0.0.9.4.2.6.1.9.4.3.nrenum.net: type NAPTR, class IN, order 100, preference 10, flags u
Authoritative nameservers
4.2.6.1.9.4.3.nrenum.net: type NS, class IN, ns vorteX.uc3m.es
Additional records
vorteX.uc3m.es: type A, class IN, addr 163.117.131.31

VoIP Slide 126

Carrier ENUM – Concetto di Federazione
•! VOIP peering secondo concetto di federazione
–! Riduzione al minimo dei costi di interconnessione
–! Set up di un database ENUM condiviso

•! Alternativamente
–! VOIP peering Exchange
•! Unico intermediario per tutte le questioni economiche e
amministrative
•! Servizi aggiungivi: ENUM, QoS, raccolta CDR,…

VoIP Slide 127

ENUM in Italia
•! Nel 2007 MIX offre servizi di carrier ENUM
–! VOIP peering con apparati NexTone
–! Interconnessione di 12 VOIP carrier

•! Trial sperimentale di voipex
–! Zona ENUM: e164.namex.it

VoIP Slide 128

Esempio: Registrazione
REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:watson@bell-tel.com
To: sip:watson@bell-tel.com
Call-ID: 70710@ saturn.bell-tel.com
CSeq: 1 REGISTER
Location
Contact: <sip:watson@saturn.bell-tel.com:3890;transport:udp> server
Expires: 7200

REGISTER sip:bell-tel.com SIP/2.0 Prima registrazione al server
Call-ID: 70710@ saturn.bell-tel.com Cancellazione dal server
CSeq: 2 REGISTER
Contact: * SIP Registrar
Expires: 0 (dominio bell-tel.com)
Registrazione con nuovo indirizzo
REGISTER sip:bell-tel.com SIP/2.0
Call-ID: 70710@ saturn.bell-tel.com
CSeq: 3 REGISTER
Contact: <sip:tawatson@example.com>

VoIP Slide 129

Call Setup attraverso un Proxy server
Location Service
Proxy SIP
Richiesta
Risposta Location
2
Server
3
1 7 tel.unimi.it
8 4
ele.unifi.it 6
9
iet.unipi.it
10
UAC SIP RTP UAS SIP
bia@iet.unipi.it rossi@tel.unimi.it
1 INVITE rossi@ele.unifi.it
2 rossi
3 rossi@tel.unimi.it
4 INVITE rossi@tel.unimi.it
5 Squillo del terminale
6-7 Risposta 200 OK
8-9 ACK
10 Inizio comunicazione
VoIP Slide 130

Procedure di autenticazione
•! Necessarie ai diversi componenti
–! Registrar: un utente potrebbe produrre dei messaggi
REGISTER tali da dirottare verso di esso tutte le
chiamate dirette verso uno qualunque degli utenti
registrati o cancellare le registrazioni
–! Proxy o redirect: la necessità di effettuare
l’autenticazione deriva dal fatto che alcuni utenti
potrebbero avere un accesso limitato ai servizi offerti
dalla rete (gateway SIP-PSTN)
–! UA: per essere sicuri di comunicare con l’utente indicato
nel campo From
•! Come succede con la posta elettronica, questo campo può
essere facilmente modificato

VoIP Slide 131

Meccanismo di autenticazione - 1

Server
(UAS ,
Client
Registrar
(UAC )
Redirect
Proxy )

R ich iesta

direct)
ized ( UAS, R egis trar , Re
401 Una uthor ticatio n R equ
ir ed (Proxy
hen
407 P rox y A ut
Richiesta co
n creden zial i
cc esso
S uccess o/Insu
ne
Autenticazio

VoIP Slide 132

Meccanismo di autenticazione - 2
•! Digest Authentication Scheme
–! Prevede il calcolo da parte dello UAC di un messaggio crittografato a 128-
bit, ottenuto applicando l’algoritmo MD5 (Message Digest number 5) ai
dati di ingresso
–! Questi dati sono in parte noti allo UAC ed in parte trasmessi dal server
–! Alla ricezione della richiesta dello UAC che contiene le sue credenziali, il
server applica l’algoritmo MD5 ai dati di ingresso e confronta il risultato
con il valore riportato dal parametro response contenuto nelle credenziali
ricevute
–! Se il valore ottenuto coincide con quello riportato in questo parametro, il
server deduce che lo UAC conosce la password e quindi autentica l’utente
–! In caso contrario, genera una risposta di errore che informa lo UAC che
l’autenticazione non è andata a buon fine
–! Una volta che l’utente ha inserito i valori username e password, a seguito
della prima richiesta di autenticazione per l’accesso ad un determinato
dominio, questi saranno registrati nella cache del terminale ed utilizzati
per autenticare in modo automatico tutti gli altri messaggi che saranno
scambiati durante le diverse fasi della sessione

VoIP Slide 133

Chiamata tra due utenti con Proxy

UAC SIP Proxy Proxy UAS SIP
Pippo INVITE 1 tel.com phone.com Pluto
INVITE 2
100 Trying 3 INVITE 4
100 Trying 5
180 Ringing 6
180 Ringing 7
180 Ringing 8 200 OK 9
200 OK 10
200 OK 11
ACK 12
Media
BYE 13
200 OK 14
INVITE 1 200 OK 9 BYE 13
SIP/2.0 200 OK BYE sip: pippo@homer.tel.com SIP/2.0
INVITE sip:pluto@phone.com SIP/2.0 Via: SIP/2.0/UDP abc.phone.com Via: SIP/2.0/UDP 101.1.1.1
Via: SIP/2.0/UDP homer.tel.com Via: SIP/2.0/UDP burt.tel.com From: sip:pluto@phone.com
From: sip:pippo@tel.com Via: SIP/2.0/UDP homer.tel.com To: sip:pippo@tel.com
To: sip:pluto@phone.com From: sip:pippo@tel.com Call-ID: 344453@homer.tel.com
Call-ID: 344453@homer.tel.com To: sip:pluto@phone.com CSeq: 22 BYE
CSeq: 1 INVITE Call-ID: 344453@homer.tel.com
Content-Type: application/sdp CSeq: 1 INVITE 200 OK 14
Contact: <sip:pippo@homer.tel.com> Content-Type: application/sdp SIP/2.0 200 OK
Via: SIP/2.0/UDP 101.1.1.1
… INVITE 2 Contact: <sip:pluto@101.1.1.1> From: sip:pluto@phone.com
Via: SIP/2.0/UDP burt.tel.com … 200 OK 11 To: sip:pippo@tel.com
Via: SIP/2.0/UDP homer.tel.com Via: SIP/2.0/UDP homer.tel.com Call-ID: 344453@homer.tel.com
…
VoIP … Anno Accademico 2010/11 CSeq: 22 BYE Slide 134

Macchina a stati - Client Transaction

VoIP Slide 135

Macchina a stati - Server Transaction

VoIP Slide 136

Affidabilità della consegna dei messaggi

Meccanismo di ritrasmissione
CLIENT Trans. SERVER Trans.
INVI
TE

TA
INVI
TE
osta
Risp

VoIP Slide 137

Timer del SIP
Timer Valore Significato
T1 500ms RTT stimato
T2 4s Massimo intervallo di
ritrasmissione per
richieste non-INVITE
e risposte all’INVITE
T4 5s Massima permanenza
di un messaggio i n
rete
Timer A Valore iniziale :T1 Intervallo di
ritrasmissione
dell’INVITE
Timer B 64*T1 Time o u t per la
transazione associata
all’INVITE
Timer C > 3 min Timeout del proxy pe r
la transazione
associata all’INVITE
Timer D > 32 s per UDP Tempo di attesa per
0 per TCP/STCP eventuali risposte
ritrasmesse
Timer E Valore iniziale :T1 Intervallo di
ritrasmissione della
richiesta non-INVITE
Timer F 64*T1 Time o u t per la
transazione associate
a messaggi non-
INVITE
Timer G Valore iniziale :T1 Intervallo di
risposta all’INVITE
Timer H 64*T1 Time o u t per la
risposta all’INVITE
Timer I > 32 s per UDP Tempo di attesa per
0 per TCP/STCP eventuali ACK
ritrasmessi
Timer J T4 per UDP Tempo di attesa per
0 per TCP/STCP eventuali richieste
non-INVITE
ritrasmesse
Timer K T4 per UDP Tempo di attesa per
0 per TCP/STCP eventuali risposte
ritrasmesse

VoIP Slide 138

Prove Sperimentali SIP

VoIP Slide 139

Introduzione
•! Analisi dei messaggi SIP scambiati durante prove
sperimentali
–! registrazione con e senza autenticazione di uno User Agent (UA)
–! instaurazione di una sessione tra due UA
–! instaurazione di una sessione tra uno UA ed un utente ISDN
–! chiusura di una sessione attiva
–! cancellazione di una richiesta pendente
–! negoziazione dei parametri dei flussi multimediali di una sessione
•! Il Proxy/Registar SIP Server ottenuto con Sip Express Router
–! Dominio psrt.it
–! DNS Server per risoluzione diretta degli URI SIP
•! Gateway ottenuto con scheda ISDN-BRI e Asterisk
•! Analizzatore di protocollo Ethereal

VoIP Slide 140

Scenario sperimentale
sip :homer@psrt .it
UA 2 marconi.psrt .it
(10.0.1.4)
Bridge

UA 1 Switch 1 Switch 2

Ethereal
sip:burt@psrt .it IPS/IDS
meucci.psrt .it
(10.0.0.3) gateway.psrt .it
(10.0.0.2)

proxy.psrt .it
(10.0.1.2)
1 ISDN BRI
PSTN Network

Gateway Proxy SIP
SIP2PSTN Registrar SIP
DNS server
VoIP Slide 141

Registrazione con autenticazione
Proxy SIP
Registrar SIP
DNS server

UA 1
proxy.psrt .it
sip:bart@psrt .it (10.0.1.2)
meucci.psrt .it
(10.0.0.3)

R EGI STER

100: Trying

or ized
401: Unauth

R EGISTER

100: Trying

200: Ok

VoIP Slide 142

Chiamata tra utenti SIP
Proxy SIP
Registrar SIP
DNS server
UA 1 UA 2
proxy.psrt .it
sip:bart@psrt .it sip :homer@psrt .it
(10.0.1.2)
meucci.psrt .it marconi.psrt .it
(10.0.0.3) (10.0.1.4)
IN VITE

100: Trying IN VI TE

100: Trying

180: R inging

…….
180: R inging
…….

200: Ok

200: Ok
ACK

ACK

VoIP Slide 143

Chiamata tra utente SIP e ISDN

VoIP Slide 144

Chiusura di una sessione

Proxy SIP
Registrar SIP
DNS server
UA 1 UA 2
proxy.psrt .it
(10.0.1.2)
(10.0.0.3) (10.0.1.4)

BYE

BYE

200: Ok

200: Ok

VoIP Slide 145

Utilizzo del metodo CANCEL
Proxy SIP
Registrar SIP
DNS server
UA 1 UA 2
proxy.psrt .it
(10.0.1.2)
(10.0.0.3) (10.0.1.4)
IN VITE

100: Trying IN VITE

100: Trying
g
180: Ringin

180: R inging
….

CAN CEL

ing C ANC EL
200: cancel
200: Ok
t T ermin ated
487: Reques
AC K
t Terminated
487: R eques
AC K

VoIP Slide 146

Confronto H.323-SIP

VoIP Slide 147

Confronto H.323-SIP - 1
•! Il punto di partenza nella definizione delle due architetture è
fondamentalmente diverso
•! L’architettura H.323 sviluppata da ITU-T risente dell’esperienza nella
definizione delle reti PSTN
–! codifica binaria delle informazioni di segnalazione
–! parti della segnalazione ISDN
–! filosofia di sviluppo di tipo top-down: spesso macchinoso
•! L’architettura SIP sviluppata dalla comunità IETF con un approccio
uguale a quello usato per tutti i servizi di Internet
–! Sono stati definiti gli elementi architetturali strettamente necessari per la
gestione delle sessioni (apertura, modifica, chiusura etc.) multimediali
–! La definizione di questi elementi è stata condotta considerando la loro
integrazione con l’insieme completo di funzioni e servizi già definiti per
Internet.
–! Approccio di progettazione di tipo bottom-up utilizzato dalla comunità
IETF: flessibile, ma possibile formazione di ambiguità (interoperabilità)

VoIP Slide 148


•! Differenze molto evidenti nelle prime versioni delle due
architetture
–! successivamente, IETF e ITU-T hanno aggiornato la loro architettura
cercando di migliorare i rispettivi punti deboli

•! In questa evoluzione ognuna delle due architetture ha
cercato di migliorare la propria struttura cercando di
inglobare le funzionalità che con l’esperienza
dell’architettura concorrente risultavano migliori di quelle
adottate
–! le differenze fra le due architetture si vanno riducendo, mano a mano
che sono rilasciate nuove versioni dei due protocolli

VoIP Slide 149

•! Gli aspetti da considerare nel confronto sono

•! Funzionalità del protocollo
•! Procedure per l’instaurazione e la chiusura della chiamata
•! Servizi di chiamata
•! Meccanismi per lo scambio delle funzionalità dei terminali
•! Meccanismi per il supporto della Qualità del Servizio
•! Complessità

•! Affermazione recente su SIP
–! We have made every effort to read RFC 3261 closely and interpret it correctly, but this is difficult to do because the
RFC is informal, incomplete, and vague in many place - Pamela Zave et alii. “articolo sottomesso a IPTCOMM 2010

VoIP Slide 150

RTP/RTCP
(Real Time Transport Protocol/Real Time Control Protocol)
RFC 3550/3551

VoIP Slide 151

•! J. Rey, D. Leon, A. Miyazaki, V. Varsa, R.
Hakenberg, RFC 4588: RTP Retransmission
Payload Format, July 2006

VoIP Slide 152

Introduzione - 1

•! RTP è stato progettato per fornire servizio di trasporto end-
to-end per dati con caratteristiche real-time
•! Non dipende dal protocollo di trasporto, cioè può essere
usato su UDP, IPX, AAL5/ATM etc.. In reti IP si basa su UDP
•! Non è un protocollo di livello applicativo, sebbene è in
stretta relazione con le applicazioni
•! Non offre nessun meccanismo di affidabilità e di controllo
di flusso/congestione
•! Fornisce funzionalità adatte per trasportare informazioni
real-time, ma non assicura la consegna real-time
•! RTP consiste di una parte dati e una parte di controllo,
denominata RTCP (Real Time Control Protocol)

VoIP Slide 153

Introduzione - 2
•! I servizi offerti dal protocollo RTP sono:
–! Identificazione del tipo di dati trasportati
–! Numero di sequenza, per l’identificazione di eventuali perdite di
pacchetti e arrivi fuori sequenza
–! Timestamping, per la ricostruzione della sincronizzazione tra le
sorgenti
–! Monitoraggio della qualità della comunicazione

•! RTCP fornisce informazioni sui partecipanti a conferenze
real-time tra gruppi di utenti in reti IP. Inoltre, tra i servizi
offerti da RTCP:
–! source identification
–! la fornitura di un riscontro sui parametri di QoS a livello di rete
(percentuale di pacchetti persi, jitter) osservati dai ricevitori
VoIP Slide 154

Formato dei messaggi RTP
V P X CC M Payload Type Sequence Number
4 byte
2b 1b 1b 4b 1b 7b 16 b
4 byte RTP Timestamp

4 byte Synchronization Source (SSRC) ID

4 byte Contributing Source (CSRC) ID (Optional)
•! V: versione del protocollo RTP
•! P: padding, indica se ci sono byte di padding nel pacchetto (posti alla fine del payload)
•! X: extension, se settato, l’intestazione è seguita da un’estensione (non ancora definite)
•! CC: CSRC Count, contiene il numero di identificatori CSRC posti nella parte finale
dell’intestazione
•! M, Marker, messo a disposizione dell’applicazione
•! Payload type, identifica il formato del payload RTP e determina la sua interpretazione da
parte dell’applicazione (http://www.iana.org/numbers.htm)
•! Sequence number, usato affinché il ricevitore possa riconoscere la perdita di pacchetti e
l’arrivo di pacchetti fuori sequenza
•! Timestamp, usato per la ricostruzione della sincronizzazione tra codificatore e
decodificatore
•! SSRC, Identificatore della sorgente di sincronizzazione (sorgente del messaggio)
•! CSRC, rappresenta un identificativo della sorgente (utilizzato in presenza di mixer)
VoIP Slide 155

Definizione del campo Timestamp
•! Indica l’istante di campionamento del primo ottetto o l’istante in cui
viene creato il frame a cui appartiene il primo ottetto del segmento RTP.
Deriva da un clock (temporizzatore) che si incrementa nel tempo in
maniera lineare. Segmenti consecutivi
–! possono avere lo stesso timestamp se sono generati allo stesso istante (per
esempio se appartengono allo stesso frame video)
–! possono contenere timestamp che non sono strettamente crescenti se i dati
non vengono trasmessi nell’ordine di campionamento, come nel caso di frame
video MPEG
–! Se i pacchetti RTP vengono generati periodicamente, deve essere usato
l’istante di campionamento nominale del clock di campionamento

Segnale Analogico Campioni
160 T 160 T 160 T

t t
Pacc. RTP Pacc. RTP
Timestamp Timestamp
Flusso
600 920
Pacchetti RTP

Calcolo del Timestamp per dati campionati periodicamente
VoIP Slide 156

Traslatori e Mixer
Router Router
Utente: A Utente: B Frame Relay

SSRC: A SSRC: B

SSRC: A
SSRC: C SSRC: B
SSRC: C
Utente: C
Traslatore D

Router Router
Utente: A Utente: B Frame Relay

SSRC: A SSRC: B

SSRC: E
SSRC: A
CSRC: A, B, C
SSRC: C SSRC: B
SSRC: C
Utente: C
Mixer E

VoIP Slide 157

Funzioni del protocollo RTCP

•! Riscontro sulla qualità della distribuzione dei dati

•! Identificazione della sorgente RTP, mediante il nome
canonico o CNAME del tipo user@host oppure host, se non
è disponibile un nome user
–! il CNAME può essere usato per associare i flussi di diversi media ad
una stessa sessione (per esempio per sincronizzare audio e video).

•! Controllo del rate di trasmissione dei pacchetti RTCP

•! Trasporto di informazioni minime per il controllo della
sessione, per esempio l’identificazione dei partecipanti
da visualizzare sull’interfaccia utente
VoIP Slide 158

Formato dei messaggi RTCP

•! La porta UDP del flusso RTCP è pari alla porta del flusso RTP controllato
più 1

•! Esistono 5 tipologie di messaggi RTCP
–! Sender Report: trasmissione periodica da parte di partecipanti attivi nella
conferenza per portare a conoscenza degli altri di cosa questi avrebbero
dovuto ricevere (cioè numero di pacchetti e byte trasmessi)

–! Receiver Report: trasmissione periodica da parte di partecipanti passivi nella
conferenza di statistiche relative alla loro ricezione (cioè numero di pacchetti
persi e jitter)

–! Source Description (SDES): utilizzati per la descrizione della sessione. Include
anche l’identificatore CNAME, nome unico della sorgente

–! Bye: indica l’intenzione di voler abbandonare la conferenza

–! Application Specific: ideato per usi sperimentali di nuove applicazioni

VoIP Slide 159

Formato Sender Report
0 2 3
Header 8 16 31
V P RC PT=200 Length
SSRC del trasmettitore
NTP Timestamp, bit più significativi
Sender

NTP Timestamp, bit meno significativi
Info

RTP Timestamp
Packet count del trasmettitore
Octect count del trasmettitore
SSRC_1
Reception

Numero di pacchetti persi
Report 1

Fract Lost
Numero di sequenza più alto ricevuto
Interarrival Jitter
Ultimo SR (LSR, Last SR)
Ritardo dall’ultimo SR (DLSR)
Reception
Report 2

SSRC_2
…

Sender Report
VoIP Slide 160

Formato Receiver Report
0 2 3 8 16 31
Report 1 Header
V P RC PT=201 Length
SSRC del trasmettitore
SSRC_1
Reception

Fract Lost Numero di pacchetti persi
Numero di sequenza più alto ricevuto
Interarrival Jitter
Ultimo SR (LSR, Last SR)
Ritardo dall’ultimo SR (DLSR)
Reception
Report 2

SSRC_2
…

VoIP
Anno Accademico 2010/11 Receiver Report Slide 161

Formato SDES (Source Descriptor)

0 2 3 8 16 31
Header

V P SC PT=202 Length
SSRC/CSRC_1
Chunk 1

SDES Item
…
Chunk 2

SSRC/CSRC_2
SDES Item

SDES
VoIP Slide 162

Pacchetto RTCP composto

Prefisso di
SR o RR RR SDES
criptazione APP BYE
obbligatorio addizionali CNAME obbl.
32 bit

•! prefisso di criptazione: solo se il pacchetto è criptato esso è
preceduto da una quantità random di 32-bit ricalcolata per ogni
pacchetto (vedi RFC1321 e RFC2437 per chiarimenti sulla
criptazione).
•! SR o RR: il primo pacchetto deve essere uno fra questi due per
facilitare la validazione.
•! RRs addizionali: pacchetti che vanno aggiunti, se il numero di
sorgenti di cui si sono fatte le statistiche supera 31.
•! SDES: un pacchetto SDES contenente CNAME deve essere presente in
ogni pacchetto composto. Altri SDES opzionali possono essere inclusi.
•! BYE o APP: in particolare il pacchetto BYE deve essere l’ultimo.

VoIP Slide 163

Aspetti legati alla QoS

VoIP Slide 164

Definizione di QoS percettiva
•! La QoS percettiva è riferita alla qualità del servizio così come viene
percepita dall’utente
–! Listening quality (LQ): chiarezza con la quale il segnale vocale acquisito
tramite l’altoparlante del trasmettitore, viene ricevuto dall’ascoltatore
–! Conversational quality (CQ): include fenomeni bidirezionali, come il
ritardo con il quale il segnale arriva al ricevitore e l’eco dell’altoparlante

•! Tecniche di misura della QoS percettiva
–! Attive
–! Passive
•! Tecniche attive di misura della QoS percettiva
–! Soggettive: definite in due raccomandazioni ITU-T, P.800 e P.830,
permettono di quantificare la qualità del servizio percepita dall’utente
mediante il Mean Opinion Scores (MOS), che è rappresentato da una scala
di 5 valori, da 1 (qualità pessima, Bad) a 5 (qualità eccellente, Excellent);
le misure soggettive includono sia test sulla listening quality che sulla
conversational quality
–! Oggettive: cercano di fornire in maniera automatizzata i valori ottenuti
con il MOS. In ordine temporale le tecniche definite sono state Perceptual
Speech Quality Measurement (PSQM), Perceptual Analysis Measurement
System (PAMS) e Perceptual Evaluation of Speech Quality (PESQ)

VoIP Slide 165

Tecnica PESQ
•! La tecnica PESQ è stata definita nel 2001 (ITU-T P.862)
–! Tecnica basata su conoscenze di psico-acustica
•! Approccio
–! inserire un campione di audio nella rete, e confrontare il campione
originale con quello ricevuto in uscita dalla rete o da un suo componente.
Il confronto viene quantificato mediante un valore numerico nell’intervallo
di valori del MOS.
•! Le due caratteristiche chiave di questa tecnica sono
–! sia il segnale di ingresso che quello di uscita sono modellati da un punto di
vista percettivo;
–! il confronto è orientato alla valutazione della distanza dei due segnali dal
punto di vista della percezione umana.
•! Le tecniche PSQM, PAMS e PESQ sono accurate, ma risultano costose in
termini di implementazione in quanto, per eseguire il test, richiedono
l’uso di un canale telefonico della rete da analizzare. Questo spesso
significa l’utilizzo di apparecchiature hardware o software
specializzate per supportare le interfacce di segnalazione e
telefoniche della rete da analizzare.
VoIP Slide 166

E-Model - 1
•! Proposto nel 1990 dall’ITU-T con le raccomandazioni G.107 e G.108 per
mettere a disposizione dei progettisti uno strumento di pianificazione
•! Questa tecnica fornisce come risultato principale il cosiddetto R-factor
(o R-value), funzione di 20 parametri d’ingresso: i fattori responsabili
della degradazione della qualità
•! Tecnica passiva per la misura della QoS percettiva
–! Molto criticata per via dell’approccio additivo nella stima del R-
factor

R User Satisfation MOS
G.107 100
Default Value 94 Very Satisfied 4.4
90 4.3
Satisfied
80 4.0
Some Users Dissatisfied
70 3.6
Many Users Dissatisfied
60 3.1
Nearly All Users Dissatisfied
50 2.6
Not Recommended
0 1.0
VoIP Slide 167

E-Model - 2
•! R-factor=Ro–Is–Id–Ie–A
Fattore Nome Sottofat. Effetti considerati dal sottofattore
Basic signal-to-noise
Ro SLR End-to-end signal attenuation, expressed as a signal loudness rating
ratio
Noise from a variety of sources including room noise, expressed as
No
dBm using psophometric noise measurement
Simultaneous Iolr Low outbound volume factor
Is impairment Ist Non optimum sidetone
Iq Quantizing distortion
Id,te Talker echo
Id Delay impairment factor Id,le Listener echo
Excessive absolute delay, which can disrupt natural conversational
Id,d
rhythms
Type of Speech distortion caused by factor low-bit-rate codecs, expressed as an
Ie Equipment impairment
codec assigned value for varieties of encoding collected in ITU G.113
User accommodation of inferior quality in return for ability to use
the telephone when:
Type of •! Moving about in buildings;
A Expectation factor
connection •! Moving about in a geographic area, or in a vehicle;
•! One end of the connection is in a hard-to-reach location.
Expressed as an assigned value to be taken from ITU G.113

VoIP Slide 168

QoS e Parametri di Sistema

S u b je ctive q u a lity
Liste n in g M O S C o n ve rsatio n al M O S
a sse ssm e n t

O b je ctive q u a lity
Lo u d n e ss D isto rtio n D e lay E ch o a sse ssm e n t

Jitte r b u ffe r Ne tw o rk Ne tw o rk
d e lay p acke t lo ss jitte r
T e rm in a l Ne tw o rk
Jitte r b u ffe r q u ality
q u a lity
p a ra m e te rs o ve rflo w p aram e te rs Ne tw o rk d e lay E ch o Network
can ce llatio n
C o d in g
d isto rtio n Packet loss

C o d e r/ IP p acke t d e lay
D e co d e r
T e rm in al
D e jitte r
Ne tw o rk
d e sign / Network
d e sign Jitte r E ch o can ce lle r
p aram e te rs
b u ffe r m an age m e n t
p aram e te rs
jitter
P acke t size Lin k u tilizatio n

Network
Delay
1 2 3
IP N e tw o r k 1 2 3
4 5 6 4 5 6
7 8 9 7 8 9
8 # 8 #
* *

IP P h o n e IP P h o n e

VoIP Slide 169

VoIP QoS: Fattori importanti
•! Perdita dei pacchetti
–! Il protocollo di trasporto da utilizzare non può essere il TCP, quindi non
possono essere recuperati eventuali pacchetti persi.
–! Strategie per ridurre il problema: introdurre informazioni ridondanti che
permettono di ricavare informazioni perse (funzionanti fino a perdite del
10%) – Es. tecniche di FEC (Forward Error Correction).
•! Codifica della voce
–! Diversi algoritmi disponibili con diverse caratteristiche
–! Tecniche per la soppressione dei silenzi
•! Ritardo
–! Problemi legati alla sovrapposizione delle informazioni, che diventano
significativi quando il ritardo end-to-end è intorno a 250 ms.
•! Jitter (variazione del ritardo)
–! Per rimuovere questo problema è necessario introdurre un buffer (e quindi
ritardo) che permette di raccogliere i pacchetti e rileggere le informazioni a
velocità costante

VoIP Slide 170

Perdita di pacchetti - 1
•! Studi sperimentali approvati dagli enti di standardizzazione hanno
dimostrato che se nella rete il tasso di perdita dei pacchetti VoIP
supera una certa soglia, si possono verificare distorsioni audio che
inducono un abbassamento della qualità dell’audio percepita
dall’utente all’aumentare del tasso di perdita.
•! In ogni chiamata, questo effetto generale è modulato
–! dalla distribuzione della perdita di pacchetti
–! dall’eventuale algoritmo di Packet Loss Concealment (PLC) usato in fase
di decodifica per rimediare alla perdita di pacchetti VoIP

Bursty: U[1, 8] pks

Prestazioni del G.711 con PLC nel caso di perdite casuali e a blocchi
VoIP Slide 171

Perdita di pacchetti - 2

VoIP Slide 172

Alcuni algoritmi di PLC - 1
•! Pensati per lavorare con il codec G.711
•! Receiver based: non necessitando di una cooperazione con il
sender

INSERTION TECHNIQUES: in queste tecniche il
pacchetto perso è semplicemente rimpiazzato con un
pacchetto sostitutivo. Sono tecniche semplici da
implementare ma caratterizzate da performance
relativamente basse

!! Silence Substitution
!! Noise Substitution
!! Packet Repetition

VoIP Slide 173

Alcuni algoritmi di PLC - 2
INTERPOLATION TECHNIQUES: permettono di stimare l'informazione
che sarebbe dovuta essere trasportata nei pacchetti andati persi
!! ANSI (American National Stand. Inst.) Rec. ATIS-0152100.2005 (Annex B)
!! ITU-T Recommendation G.711 (Appendix I)

VoIP Slide 174

Confronto prestazionale tra algoritmi PLC
PESQ
5
Noise Substitution
ANSI Standard
4,5 Silence Substitution
Packet Repetition
4 NO PLC
ITU-T Standard

3,5

Delay= 20 ms
3
Jitter= 0 ms

2,5

2

1,5

1

0,5

0
1 2 3 5 7 10 15 20 30 40

% Loss

VoIP Slide 175

Codifica della Voce - 1
•! I codec a basso bit rate, ovviamente, hanno una maggiore efficienza in
fase di codifica del segnale audio al prezzo di una qualità percettiva del
segnale audio deteriorato dopo i processi di codifica/decodifica

•! Codec non basati sulla forma d’onda del segnale, questi algoritmi sono
ulteriormente penalizzati dal fatto che presentano una maggiore
complessità nei processi di codifica/decodifica che portano spesso ad un
maggiore ritardo di elaborazione.

•! Esempi (codec Cisco) MOS: G.711 (PCM) a 64 Kbps MOS=4.1, G.729 a 8
Kbps MOS=3.7, G.723.1 a 5.3 Kbps CELP MOS=3.65

•! Fenomeno Coder tandeming, impiego di diversi codec nel percorso
seguito dai pacchetti relativi ad una certa chiamata, questo perchè le
diverse reti attraversate (reti VoIP, PSTN, Cellulari, accesso a larga
banda) utilizzano spesso tecniche di codifica differenti

VoIP Slide 176

Codifica della Voce - 2

RETE IP
Decod Decod
Cod. Perdita G.72x Cod. PSTN Decod.
PSTN G.711 Cod.
G.711 Pacchetti G.711
G.72x G.711

VoIP Slide 177

Soppressione dei Silenzi
•! Osservazione 1: se uno dei due interlocutori sta parlando, l’altro tipicamente
resta in ascolto
•! Osservazione 2: la tecnica di commutazione a pacchetto permette di sfruttare
la “multiplazione statistica”
•! Per sfruttare al meglio queste due osservazioni, è necessario che il
trasmettitore non produca l’invio di informazione nei momenti in cui l’utente
resti in silenzio.
–! Voice Activity Detector (VAD)

•! Problemi
–! I primi algoritmi VAD sono stati caratterizzati dal difetto di tagliare la parte iniziale
del segnale audio, dopo il periodo di silenzio (fenomeno di speech clipping)
–! A causa dello speech clipping, le tecniche di soppressione del silenzio hanno lo
svantaggio di rappresentare un ulteriore fattore di degrado della qualità percettiva
–! Per mantenere all’ascoltatore la sensazione che l’interlocutore risulti ancora
connesso, si introduce un rumore artificiale, chiamato comfort noise
–! Le caratteristiche di questo rumore artificiale raramente riescono ad essere molto
simili a quelle del reale rumore di ambiente

VoIP Slide 178

Ritardo di collegamento
•! Gli effetti sulla qualità percettiva di servizi telefonici indipendentemente
dal tipo di tecnologia si possono classificare in due aree
–! problemi associati con la corretta interazione fra gli utenti della chiamata
(problemi che intaccano la qualità della conversazione, conversational
quality)
–! problemi di eco
•! Specificatamente ai servizi VoIP
–! problemi relativi alla variazione del ritardo, detto jitter, in quanto questo
fenomeno può essere sorgente di perdita di pacchetti e di introduzione di
ulteriore ritardo di connessione attraverso il buffer di dejitter, che mira
all’eliminazione del jitter stesso

0 100 200 300 400 500 600 700 800
Time (msec)
ITU’s G.114 Recommendation = 0 – 150msec 1-way delay
VoIP Slide 179

Ritardo di collegamento: problemi di eco - 1
•! Eco di tipo elettrico
–! L’aggiunta di un collegamento VoIP introduce il problema dell’eco iniziale, dovuto
principalmente all’incremento del ritardo end-to-end. In questo modo, il residuo di
eco viene percepito dall’utente
–! L’impatto sulla qualità percettiva del problema dell’eco iniziale è limitato a causa del
fatto che è un fenomeno che si verifica solo all’inizio della chiamata.
•! In presenza di Media Terminal Adaptor (MTA) che interfacci il telefono utente
con la sua rete a larga banda i problemi di eco che persistono per l’intera
chiamata
–! L’apparato MTA contiene un circuito ibrido (4fili-2fili) ed un cancellatore di eco
•! Nel caso di un’elevata amplificazione effettuata sul segnale ricevuto dal
terminale ricevente (telefono), si generano
–! eco elettrico Sottrattore
–! eco acustico Eco Eco Residuo
+ !" NLP
-
Eco Segnale verso l’apparato remoto
Eco Stimato

2 fili Stimatore
Circuito Eco
4 fili
Ibrido Filtro
Adattivo

Segnale dall’apparato remoto
VoIP Slide 180

Ritardo di collegamento: problemi di eco - 2

MILANO ROMA
FXO/FXS E&M FXO/FXS

E&M
Utente A PBX PBX Utente B
GATEWAY WAN GATEWAY

Analogico Digitale Analogico - tratta finale
(eco non percepibile in quanto (Introduzione di un ritardo (eco percepibile in quanto il
il ritardo è troppo basso) “elevato”) ritardo è relativamente elevato)

•! FXO - Foreign eXchange Office (linea analogica a due fili)
•! FXS - Foreign eXchange Station (linea analogica a due fili)
•! PBX - Private Branch eXchange
•! E&M - recEive and transMit (linea analogica a 4 fili)

VoIP Slide 181

Ritardo di collegamento: problemi di jitter - 1

•! Il processo che considera l’elaborazione dei pacchetti che
trasportano informazioni di fonia nei gateway e la loro
trasmissione nella rete che collega due gateway, non è tempo-
invariante
–! significative variazioni del ritardo
–! eliminabili mediante un buffer dove mantenere temporaneamente i
pacchetti in arrivo

•! Tipologia di Buffer di dejitter
–! buffer di dejitter di dimensione fissa
–! buffer di dejitter che autoregolano la loro dimensione in base
all’osservazione del jitter misurato

VoIP Slide 182

Ritardo di collegamento: problemi di jitter - 2

Periodo di campionamento: 20ms
TS: Valore del timestamp RTP
A B C
Router B
con buffer
Trasmettitore
Router A di dejiitter
Ricevitore
RETE IP

A B C
A B C
Usando i valori di RTP Timestamp
Il buffer di dejitter elimina le variazioni

VoIP Slide 183

Sip

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Sip

Similar to Sip (20)

Recently uploaded

Recently uploaded (18)

Sip