Sip

2,109 views
2,019 views

Published on

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,109
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
79
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Sip

  1. 1. SIP - Session Initiation Protocol Anno Accademico 2010/11VoIP Slide 95
  2. 2. 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 allHTTP. 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 laffidabilità 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 Anno Accademico 2010/11VoIP Slide 96
  3. 3. Introduzione - 2 in H323 erano 3 fasi ben distinte. Qui mando un solo messaggio che trova lutente, 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 Anno Accademico 2010/11VoIP Slide 97
  4. 4. 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 Anno Accademico 2010/11VoIP Slide 98
  5. 5. 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 Anno Accademico 2010/11VoIP Slide 99
  6. 6. 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 Anno Accademico 2010/11VoIP Slide 100
  7. 7. 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 Anno Accademico 2010/11VoIP Slide 101
  8. 8. Componenti dell’architettura SIP - 2 •! 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 Anno Accademico 2010/11VoIP Slide 102
  9. 9. Componenti dell’architettura SIP - 3 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 Anno Accademico 2010/11VoIP Slide 103
  10. 10. Componenti dell’architettura SIP - 4 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 Anno Accademico 2010/11VoIP Slide 104
  11. 11. Componenti dell’architettura SIP - 5 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 Anno Accademico 2010/11VoIP Slide 105
  12. 12. Componenti dell’architettura SIP - 6 •! 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) Anno Accademico 2010/11VoIP Slide 106
  13. 13. Architettura SIP SIP Redirect Server Richiesta Risposta Location Server SIP Proxy SIP Proxy UAC SIP SIP Proxy UAS SIP Anno Accademico 2010/11VoIP Slide 107
  14. 14. 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 Anno Accademico 2010/11VoIP Slide 108
  15. 15. 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) Anno Accademico 2010/11VoIP Slide 109
  16. 16. 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 Anno Accademico 2010/11VoIP Slide 110
  17. 17. 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 elaborazioneIntestazione From: Bart Simpson <sip:bart@psrt.it>;tag=125831 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.4Campo 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 Anno Accademico 2010/11VoIP Slide 111
  18. 18. 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 Anno Accademico 2010/11VoIP Slide 112
  19. 19. 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 Anno Accademico 2010/11VoIP Slide 113
  20. 20. 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 Anno Accademico 2010/11VoIP Slide 114
  21. 21. 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 Anno Accademico 2010/11VoIP Slide 115
  22. 22. 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 From: Bart Simpson <sip:bart@psrt.it>;tag=125831Header 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 Anno Accademico 2010/11VoIP Slide 116
  23. 23. 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 Anno Accademico 2010/11VoIP Slide 117
  24. 24. 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 Anno Accademico 2010/11VoIP Slide 118
  25. 25. Interazione SIP-DNS •! La RFC 3263 indica che lindirizzo 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 Anno Accademico 2010/11VoIP Slide 119
  26. 26. 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 Anno Accademico 2010/11VoIP Slide 120
  27. 27. Esempio configurazione di un server DNS Anno Accademico 2010/11VoIP Slide 121
  28. 28. 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) Anno Accademico 2010/11VoIP Slide 122
  29. 29. 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 Anno Accademico 2010/11VoIP Slide 123
  30. 30. 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 Anno Accademico 2010/11VoIP Slide 124
  31. 31. 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 Anno Accademico 2010/11VoIP Slide 125
  32. 32. 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 Anno Accademico 2010/11VoIP Slide 126
  33. 33. 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,… Anno Accademico 2010/11VoIP Slide 127
  34. 34. 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 Anno Accademico 2010/11VoIP Slide 128
  35. 35. 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 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 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 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: 3 REGISTER Contact: <sip:tawatson@example.com> Anno Accademico 2010/11VoIP Slide 129
  36. 36. 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 SIPbia@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 Anno Accademico 2010/11VoIP Slide 130
  37. 37. 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 Anno Accademico 2010/11VoIP Slide 131
  38. 38. 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 Anno Accademico 2010/11VoIP Slide 132
  39. 39. 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 Anno Accademico 2010/11VoIP Slide 133
  40. 40. Chiamata tra due utenti con ProxyUAC 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
  41. 41. Macchina a stati - Client Transaction Anno Accademico 2010/11VoIP Slide 135
  42. 42. Macchina a stati - Server Transaction Anno Accademico 2010/11VoIP Slide 136
  43. 43. Affidabilità della consegna dei messaggi Meccanismo di ritrasmissione CLIENT Trans. SERVER Trans. INVI TE TA INVI TE osta Risp Anno Accademico 2010/11VoIP Slide 137
  44. 44. 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 ritrasmissione della risposta all’INVITE Timer H 64*T1 Time o u t per la ritrasmissione della 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 Anno Accademico 2010/11VoIP Slide 138
  45. 45. Prove Sperimentali SIP Anno Accademico 2010/11VoIP Slide 139
  46. 46. 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 Anno Accademico 2010/11VoIP Slide 140
  47. 47. 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 Anno Accademico 2010/11VoIP Slide 141
  48. 48. 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 Anno Accademico 2010/11VoIP Slide 142
  49. 49. 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 Anno Accademico 2010/11VoIP Slide 143
  50. 50. Chiamata tra utente SIP e ISDN Anno Accademico 2010/11VoIP Slide 144
  51. 51. Chiusura di una sessione 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) BYE BYE 200: Ok 200: Ok Anno Accademico 2010/11VoIP Slide 145
  52. 52. Utilizzo del metodo CANCEL 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 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 Anno Accademico 2010/11VoIP Slide 146
  53. 53. Confronto H.323-SIP Anno Accademico 2010/11VoIP Slide 147
  54. 54. 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à) Anno Accademico 2010/11VoIP Slide 148
  55. 55. Confronto H.323-SIP - 2•! 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 Anno Accademico 2010/11VoIP Slide 149
  56. 56. Confronto H.323-SIP - 3 •! 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 Anno Accademico 2010/11VoIP Slide 150
  57. 57. RTP/RTCP (Real Time Transport Protocol/Real Time Control Protocol) RFC 3550/3551 Anno Accademico 2010/11VoIP Slide 151
  58. 58. •! J. Rey, D. Leon, A. Miyazaki, V. Varsa, R. Hakenberg, RFC 4588: RTP Retransmission Payload Format, July 2006 Anno Accademico 2010/11VoIP Slide 152
  59. 59. 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) Anno Accademico 2010/11VoIP Slide 153
  60. 60. 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 Anno Accademico 2010/11VoIP Slide 154
  61. 61. 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) Anno Accademico 2010/11VoIP Slide 155
  62. 62. 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 Anno Accademico 2010/11VoIP Slide 156
  63. 63. 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 Anno Accademico 2010/11VoIP Slide 157
  64. 64. 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 Anno Accademico 2010/11VoIP Slide 158
  65. 65. 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 Anno Accademico 2010/11VoIP Slide 159
  66. 66. 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 Anno Accademico 2010/11VoIP Slide 160
  67. 67. Formato Receiver Report 0 2 3 8 16 31 Report 1 Header V P RC PT=201 Length SSRC del trasmettitore SSRC_1Reception 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
  68. 68. 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 Anno Accademico 2010/11VoIP Slide 162
  69. 69. 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. Anno Accademico 2010/11VoIP Slide 163
  70. 70. Aspetti legati alla QoS Anno Accademico 2010/11VoIP Slide 164
  71. 71. 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) Anno Accademico 2010/11VoIP Slide 165
  72. 72. 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. Anno Accademico 2010/11VoIP Slide 166
  73. 73. 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 Anno Accademico 2010/11VoIP Slide 167
  74. 74. 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 Anno Accademico 2010/11VoIP Slide 168
  75. 75. 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 Anno Accademico 2010/11VoIP Slide 169
  76. 76. 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 Anno Accademico 2010/11VoIP Slide 170
  77. 77. 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 Anno Accademico 2010/11VoIP Slide 171
  78. 78. Perdita di pacchetti - 2 Anno Accademico 2010/11VoIP Slide 172
  79. 79. 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 Anno Accademico 2010/11VoIP Slide 173
  80. 80. Alcuni algoritmi di PLC - 2 INTERPOLATION TECHNIQUES: permettono di stimare linformazione 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) Anno Accademico 2010/11VoIP Slide 174
  81. 81. 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 Anno Accademico 2010/11VoIP Slide 175
  82. 82. 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 Anno Accademico 2010/11VoIP Slide 176
  83. 83. 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 Anno Accademico 2010/11VoIP Slide 177
  84. 84. 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 Anno Accademico 2010/11VoIP Slide 178
  85. 85. 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 Anno Accademico 2010/11VoIP Slide 179
  86. 86. 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 Anno Accademico 2010/11VoIP Slide 180
  87. 87. 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) Anno Accademico 2010/11VoIP Slide 181
  88. 88. 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 Anno Accademico 2010/11VoIP Slide 182

×