Conoscere i protocolli di voce a pacchetti

Transcript

1 White Paper Conoscere i protocolli di voce a pacchetti Negli ultimi 10 anni, lo stile di comunicazione delle persone e delle organizzazioni è cambiato molto rapidamente. Molti di questi cambiamenti sono dovuti alla crescita esplosiva di Internet e delle applicazioni basate sul protocollo IP. Internet è diventato un mezzo universale di comunicazione e la quantità totale del traffico a pacchetti ha rapidamente surclassato quella del traffico vocale tradizionale (DataQuest, 1998). Alla luce di questi progressi tecnologici, è evidente a chiunque operi nel settore delle telecomunicazioni (carrier, aziende e vendor) che il traffico e i servizi vocali saranno una delle prossime applicazioni principali a sfruttare appieno le potenzialità del protocollo IP. Questa aspettativa si basa sull impatto di un nuovo gruppo di tecnologie, comunemente note come voice over IP (oip) o telefonia IP. La tecnologia oip offre molte funzionalità uniche ai carrier e ai clienti che dipendono dal protocollo IP o da altre reti a pacchetti. Tra i benefici più importanti figurano: Risparmio sui costi Trasferendo il traffico vocale alle reti IP, le aziende possono ridurre o eliminare le spese delle telefonate su linea analogica (PSTN). I service provider e gli utenti finali possono inoltre risparmiare larghezza di banda investendo in capacità extra solo quando è veramente necessario, grazie alla natura distribuita del oip e al contenimento dei costi di operatività che è possibile conseguire facendo confluire il traffico vocale e di dati in un unica rete. Standard aperti e interoperabilità multivendor Adottando standard aperti, sia le aziende che i service provider possono acquistare nuovi prodotti da più vendor ed eliminare così la dipendenza da soluzioni proprietarie. Reti integrate di linee vocali e di dati Trasformando la voce in un altra applicazione IP, le aziende possono effettivamente creare reti integrate di linee vocali e di dati, che non solo offrono la qualità e l affidabilità delle attuali linee analogiche, ma consentono anche alle aziende di sfruttare, in modo rapido e flessibile, le nuove opportunità offerte dalle continue evoluzioni del settore delle comunicazioni. Nel 1995 hanno fatto la loro comparsa sul mercato i primi prodotti oip commerciali, rivolti a quelle aziende che volevano ridurre i costi associati alle telecomunicazioni migrando il traffico vocale sulle reti a pacchetti. I primi a passare alle reti oip hanno adottato soluzioni che consentivano di risparmiare sulle spese di telefonia per sfruttare le normative in favore del traffico IP. Queste prime reti erano supportate soprattutto da tecnologia proprietaria, poiché non erano stati ancora stabiliti degli standard universali. Con l evoluzione di queste reti di telefonia a pacchetti e l emergere delle dipendenze di interconnessione, è sorta la necessità di protocolli oip standard. Diversi gruppi di lavoro hanno accettato la sfida e hanno prodotto standard differenti, ciascuno con le proprie caratteristiche distintive. In particolare, le aziende e i loro clienti si sono ritrovati a dover confrontare le analogie e le differenze tra quattro diversi protocolli con funzione di segnalazione e controllo delle chiamate per il oip: H.323 Media Gateway Control Protocol (MGCP) Copyright Tutti i diritti riservati. Avvisi importanti e dichiarazione di riservatezza. Pag. 1 di 7

2 Session Initiation Protocol (SIP) H.248/Megaco Mentre stavano mettendo a punto soluzioni oip attuabili, i tecnici di rete dovevano stabilire in quale misura questi protocolli fossero efficaci e quali fossero più adatti per particolari reti e applicazioni. Di seguito sono fornite alcune indicazioni e informazioni su questi protocolli IP per dissipare parte della confusione che regna sul mercato. Il mito della grande voce Secondo il mito della grande voce esiste un solo modo per costruire reti vocali e dovrebbe esistere un solo protocollo vocale per ciascuna funzione della rete vocale a pacchetti. Per quanto questa concezione di nirvana della rete sia stata discussa in molti circoli accademici, in realtà vi sono diversi protocolli oip e architetture che continueranno ad esistere nel prossimo futuro e saranno utilizzati per costruire molte reti. Proprio come le attuali reti di dati sono state create usando diversi protocolli e applicazioni, quelle oip di oggi e di domani saranno create con i protocolli e le applicazioni più adatti alle tecnologie associate e alle esigenze aziendali. La domanda che un azienda deve porsi non è: Qual è il protocollo migliore?, ma: Quali servizi vogliamo installare e quali protocolli oip sono maggiormente in grado di supportarli?. La risposta alla prima domanda potrebbe rispecchiare l influsso di un vendor o di un ente regolatore. La risposta alla seconda domanda dipende interamente dai requisiti unici di ogni singola implementazione di rete. Poiché non vi sono due business o reti che siano esattamente identici, ogni azienda avrà una risposta personale alla seconda domanda. Orientarsi nel mondo degli standard oip Il oip è fatto di molti standard e protocolli. È necessario conoscere la terminologia di base per comprendere le applicazioni e l uso del oip. Le definizioni fornite di seguito possono essere un utile punto di partenza (i protocolli sono elencati in ordine alfabetico): H.248. È il risultato della collaborazione tra ITU e Internet Engineering Task Force (IETF). Anche noto come IETF RFC 2885 (Megaco), definisce un architettura centralizzata per la creazione di applicazioni multimediali, compreso il oip. Sotto diversi aspetti, l H.248 si basa sul MGCP e ne rappresenta l estensione. H.323. È una raccomandazione ITU che definisce i sistemi di comunicazione multimediale a pacchetto. In altre parole, l H.323 indica un architettura distribuita per la creazione di applicazioni multimediali, compreso il oip. IETF. Fa riferimento all Internet Engineering Task Force ( una comunità di tecnici che si è posta l obiettivo di definire il funzionamento di Internet e dei relativi protocolli e degli standard prevalenti. ITU. È l acronimo di International Telecommunication Union ( un organizzazione internazionale all interno del sistema delle Nazioni Unite ( dove i governi e il settore privato coordinano le reti e i servizi di telecomunicazioni globali. Megaco Anche noto come IETF RFC 2885 e Raccomandazione ITU H.248, definisce un architettura centralizzata per applicazioni multimediali, compreso il oip. Media Gateway Control Protocol (MGCP), o IETF RFC Definisce un architettura centralizzata per applicazioni multimediali, compreso il oip. Real-Time Transport Protocol (RTP), o IETF RFC Indica un protocollo di trasporto per le applicazioni in tempo reale. In particolare, l RTP supporta il traffico audio/media della comunicazione oip. L RTP è utilizzato da tutti i protocolli di segnalazione oip. Session Initiation Protocol (SIP), o IETF RFC Indica un architettura distribuita per applicazioni multimediali, compreso il oip. Copyright Tutti i diritti riservati. Avvisi importanti e dichiarazione di riservatezza. Pag. 2 di 7

3 Architetture centralizzate e distribuite In passato, tutte le reti vocali erano supportate da un architettura centralizzata in cui gli endpoint (i telefoni) erano controllati da switch centralizzati. Sebbene questo modello fosse efficiente per i servizi di base della telefonia, richiedeva un compromesso tra una gestione semplificata e l innovazione degli endpoint e dei servizi. Uno dei benefici offerti dalla tecnologia oip è la possibilità di scegliere tra un architettura centralizzata o distribuita. Questa flessibilità consente alle aziende di creare reti caratterizzate sia dalla gestione semplificata che dall innovazione degli endpoint, a seconda del protocollo utilizzato. In generale, l architettura centralizzata è associata ai protocolli MGCP e H.248/Megaco, che sono stati messi a punto per un dispositivo centralizzato, il media gateway controller o call agent, con funzione di segnalazione e controllo delle chiamate. Il dispositivo centralizzato comunica con i media gateway che instradano e trasmettono le chiamate (le informazioni vocali). In un architettura centralizzata l intelligenza di rete è centralizzata e gli endpoint sono relativamente poco attivi (con funzionalità limitate o addirittura assenti). Sebbene la maggior parte delle architetture centralizzate oip sia supportata da protocolli MGCP o H.248/Megaco, è anche possibile utilizzare protocolli SIP o H.323 con segnalazione da parte di un back-to-back user agent (B2BUA) o di un gatekeeper (GKRCS). Chi è favorevole a un architettura centralizzata oip preferisce questo modello perché consente di centralizzare la gestione, l erogazione e il controllo delle chiamate, semplifica il flusso delle chiamate per replicare le funzionalità vocali precedenti ed è di facile comprensione per i tecnici abituati ai sistemi precedenti. Gli scettici dell architettura centralizzata sostengono che inficia l innovazione degli endpoint e che diventerà un ostacolo nel passaggio ai servizi oip destinati ad abbandonare le funzionalità vocali precedenti. L architettura distribuita è associata ai protocolli H.323 e SIP, che consentono la distribuzione dell intelligenza di rete tra gli endpoint e i dispositivi di controllo delle chiamate. In questo caso, con intelligenza si intende l insieme dello stato e delle funzionalità delle chiamate, l instradamento, la fatturazione o qualsiasi altro aspetto relativo alla gestione delle chiamate. Gli endpoint possono essere gateway oip, telefoni IP, media server o qualsiasi dispositivo che possa dare inizio e concludere una chiamata oip. In una rete H.323 i dispositivi di controllo delle chiamate sono definiti gatekeeper, in una rete SIP sono definiti proxy server o redirect server. Chi è favorevole a un architettura distribuita sostiene che questo modello sia caratterizzato da un elevata flessibilità e che le applicazioni oip possano essere considerate come qualsiasi altra applicazione IP distribuita: consentono di aggiungere intelligenza agli endpoint o ai dispositivi di controllo delle chiamate, a seconda delle esigenze aziendali e tecnologiche della rete. Di solito, l architettura distribuita è ben nota ai tecnici che gestiscono i dati IP. In genere, chi critica l architettura distribuita sostiene che l infrastruttura PSTN esistente è l unico modello di riferimento che dovrebbe essere utilizzato nella replicazione dei servizi vocali precedenti e che le reti distribuite tendono a essere più complesse. H.323 L H.323 è stato originariamente creato per offrire un meccanismo di trasporto delle applicazioni multimediali nelle LAN. Sebbene l H.323 sia ancora utilizzato da numerosi vendor per le applicazioni di videoconferenza, si è evoluto per rispondere alle crescenti esigenze delle reti oip. Per la sua immediata disponibilità e queste caratteristiche innovative, l H.323 è attualmente il protocollo oip più utilizzato per la segnalazione e il controllo delle chiamate, con carrier nazionali e internazionali che lo sfruttano per gestire milioni di minuti di operatività ogni anno. L H.323 è considerato un protocollo contenitore perché definisce tutti gli aspetti della trasmissione delle chiamate, dall esecuzione alla funzione di scambio alla disponibilità di risorse di rete. L H.323 definisce i protocolli RAS (Registration, Admission e Status) per l instradamento delle chiamate, H.225 per l attivazione delle chiamate e H.245 per la funzione di scambio. Copyright Tutti i diritti riservati. Avvisi importanti e dichiarazione di riservatezza. Pag. 3 di 7

4 Figura 1 Reti H.323 Gatekeeper A ACF LRQ LCF Gatekeeper B ACF RRQ/RCF IP Network RRQ/RCF ARQ Gateway A Telefono A H.225 (Q.931) Setup H.225 (Q.931) Segnala e connette H.245 RTP ARQ Gateway B Telefono B L H.323 si basa sul protocollo ISDN (Integrated Services Digital Network) Q.391, che consente di comunicare facilmente con le precedenti reti vocali come la PSTN o SS7 (Signaling System 7). L H.323 viene utilizzato in un architettura distribuita e consente alle aziende di creare reti estese scalabili, resilienti e ridondanti. Rende possibile il collegamento ad altre reti oip e supporta l intelligenza di rete sia a livello di endpoint che di gatekeeper. MGCP/H.248/Megaco I protocolli MGCP e H.248/Megaco sono stati studiati per un architettura che consenta di aggiungere a una rete oip il controllo delle chiamate e i servizi associati. Quindi, un architettura basata su questi protocolli assomiglia molto alle reti e ai servizi PSTN esistenti. I protocolli MGCP e H.248/Megaco definiscono la maggior parte degli aspetti relativi alla segnalazione mediante il modello a pacchetti. I pacchetti identificano la funzionalità attivata più di frequente, come la segnalazione PSTN, la connettività con periferiche di linea e caratteristiche come la trasmissione e la tenuta. Inoltre, il protocollo SDP (Session Definition Protocol) viene impiegato per lo scambio di risorse. Figura 2 Reti MGCP/H.248/Megaco SS7 Call Agent Call Agent IMT PSTN PSTN PRI Gateway di accesso MGCP/H.248/Megaco RTP Copyright Tutti i diritti riservati. Avvisi importanti e dichiarazione di riservatezza. Pag. 4 di 7

5 In un architettura centralizzata, i protocolli MGCP e H.248/Megaco consentono alle aziende di creare reti estese scalabili, resilienti e ridondanti e di comunicare con altre reti oip, aggiungendo intelligenza e caratteristiche al call agent. SIP Il SIP è un protocollo multimediale che potrebbe sfruttare l architettura e i messaggi tipici delle comuni applicazioni Internet. Servendosi di un architettura distribuita che sfrutta gli URL per le definizioni e per gli SMS, SIP tenta di sfruttare il modello Internet per creare reti e applicazioni oip. Inoltre, viene impiegato per il servizio di videoconferenze e per i messaggi in tempo reale. Il protocollo SIP definisce solo la modalità di configurazione e di eliminazione delle sessioni. Usa altri protocolli IETF per definire altri aspetti del oip e delle sessioni multimediali come l SDP per lo scambio di risorse, l URL per gli indirizzi, il DNS (Domain Name System) per l area di provenienza del servizio e il TRIP (Telephony Routing over IP) per l instradamento delle chiamate. Figura 3 Reti SIP Registrazione Trasferimento Database di collocazione SIP Server/servizi Registra "Sono qui" Trasferimento 3xx "Hanno cambiato indirizzo, prova questo" "Dov'è il nome/numero di telefono?" IP SIP Proxy Utente SIP Agenti PROPOSTA "oglio comunicare con un altro UA" Utente SIP Agenti PROPOSTA del proxy "La gestisco io" SIP-GW L IETF ha fatto grandi progressi nella definizione delle estensioni che consentono al SIP di comunicare con le reti vocali convenzionali. Tuttavia, viene impiegato principalmente per creare un ambiente che supporta i modelli di comunicazione di nuova generazione che sfruttano Internet e le relative applicazioni. In un architettura distribuita il SIP consente alle aziende di creare reti estese scalabili, resilienti e ridondanti. Consente inoltre la comunicazione con altre reti oip e aggiunge intelligenza e nuove funzionalità sia a livello di endpoint che di SIP proxy o di redirect server. Protocolli oip di interconnessione Con l installazione delle reti oip a un ritmo sempre più sostenuto, i vendor e i service provider oip continuano ad aggiungere nuove funzionalità. Poiché il supporto cambia a seconda del protocollo e le aziende hanno esigenze diverse, è molto probabile che le reti oip continueranno a basarsi su protocolli multipli. La molteplicità dei protocolli assicura ai clienti la flessibilità necessaria per interconnettere servizi di carrier multipli. L impiego di standard, anche molteplici, semplifica l installazione degli endpoint multivendor e aumenta le opzioni per la gestione e la fornitura delle reti. Copyright Tutti i diritti riservati. Avvisi importanti e dichiarazione di riservatezza. Pag. 5 di 7

6 Le società intenzionate ad estendere la propria rete si trovano a dover scegliere la modalità di interconnessione usando protocolli oip diversi. Spesso queste scelte rientrano in una delle tre categorie: TDM Trasmissione mediante standard TDM (time-division multiplexing Le aziende che adottano questo standard usano strumenti TDM o gateway oip per la comunicazione tra i vari protocolli. Quali sono i benefici di questo modello? Può essere utilizzato fin da oggi. Lo svantaggio è che introduce latenza nella rete oip e richiede un ulteriore passaggio (oip n. 1 <-> TDM <-> oip n. 2). Questo modello è considerato solitamente una soluzione a breve termine fino a quando non saranno disponibili i traduttori di protocollo IP. Architettura di protocollo unica Le aziende che scelgono questo modello adottano un unico protocollo per tutti i sistemi e i servizi oip, semplificando così la gestione dell intera rete. Uno degli svantaggi di questo approccio è l impossibilità di migrare i sistemi esistenti per supportare il nuovo protocollo, con la conseguenza che l azienda potrebbe perdere alcuni dei servizi già attivi. Inoltre, questo modello limita la connettività potenziale verso le altre reti che usano altri protocolli di segnalazione oip. Traduzione del protocollo Le aziende che privilegiano questo modello usano traduttori di protocollo IP per collegare tra loro due o più domini di protocollo oip. I traduttori IP consentono di mantenere la flessibilità associata all utilizzo di due o più protocolli oip, eliminando i problemi di ritardo legati alle interconnessioni TDM extra, e non richiedono la sostituzione completa dei sistemi in uso. Uno degli svantaggi è dato dal fatto che non esiste uno standard per la traduzione del protocollo. Pertanto, non tutti i traduttori di protocollo oip sono identici. L IETF ha tentato di definire un modello per la trasmissione dall H.323 al SIP, ma occorre molto più della creazione di una casella di traduzione del protocollo. Sebbene i protocolli siano simili sotto certi aspetti, presentano anche delle differenze (tabella 1). I vendor dei traduttori di protocollo devono conoscere a fondo tutti i protocolli usati nella rete oip e i diversi componenti oip che sfruttano diversi aspetti del protocollo. Ad esempio, l H.323 e il SIP possono inviare cifre DTMF sia attraverso la segnalazione che il percorso (mediante l RTP). Con l H.323 è possibile usare solo la segnalazione H.245; il SIP non specifica la modalità di trasmissione DTMF. Ciò significa che i dispositivi SIP potrebbero inviare DTMF sul percorso (RFC 2833) e i dispositivi H.323 potrebbero inviare DTMF sulla segnalazione (H.245). Se il traduttore del protocollo oip non è in grado di riconoscere né la segnalazione né il percorso, potrebbe non funzionare in modo appropriato. Tabella 1 I protocolli oip H.323 SIP MGCP/H.248/MEGACO Ente regolatore ITU IETF MGCP/MEGACO IETF; H.248 ITU Architettura Distribuita Distribuita Centralizzata ersione attuale H.323v4 RFC2543-bis07 MGCP 1.0, Megaco, H.248 Controllo delle chiamate Gatekeeper Proxy/Redirect Server Call agent/media gateway controller Endpoint Gateway, terminal User Agent Media gateway Trasporto della segnalazione Protocollo TCP o UDP TCP oder UDP MGCP UDP; Megaco/H.248 entrambi Funzionalità multimediale Sì Sì Sì Trasporto su relay DTMF H.245 (segnalazione) o RFC 2833 (percorso) RFC 2833 (percorso) o INFO (segnalazione) Segnalazione o RFC 2833 (percorso) Trasporto su fax relay T.38 T.38 T.38 Servizi supplementari Forniti dagli endpoint o dall'agente di controllo delle chiamate Forniti dagli endpoint o dall'agente di controllo delle chiamate Forniti dall'agente di controllo delle chiamate Copyright Tutti i diritti riservati. Avvisi importanti e dichiarazione di riservatezza. Pag. 6 di 7

7 Conclusioni - Il Packet oice e il oip riguardano i servizi, non i protocolli Proprio come le aziende scelgono diversi protocolli per le loro reti di dati, sceglieranno diversi protocolli anche per le loro esigenze di oip, a seconda delle necessità aziendali e tecniche. Sebbene la varietà dei protocolli oip abbia portato una certa confusione sul mercato, è proprio la flessibilità dei sistemi vocali oip a fare la differenza rispetto ai sistemi convenzionali. Le aziende sceglieranno i vendor sulla base di tre esigenze fondamentali: i clienti hanno bisogno di vendor che supportino gli standard aperti dei loro prodotti e che sviluppino delle strategie vocali orientate all interoperabilità con tutti i protocolli oip. Senza questa caratteristica, i sistemi oip rischiano di assumere lo stesso carattere proprietario dei precedenti sistemi vocali. I clienti hanno bisogno di prodotti che supportino protocolli multipli. In tal modo, se un azienda ha la necessità di migrare a un protocollo diverso o di aggiungere dispositivi che supportano un altro protocollo, non dovrà effettuare un aggiornamento della rete. I clienti hanno bisogno di soluzioni vocali con supporto end-to-end per tutti i protocolli oip. Pertanto, i vendor devono offrire soluzioni adatte sia ad ambienti monoprotocollo che multiprotocollo La collaborazione con vendor in grado di assicurare questa flessibilità oip consente alle aziende di creare reti scalabili e affidabili con requisiti di nuova generazione Corporate Headquarters 170 West Tasman Drive San Jose, CA USA Tél : NETS (6387) Fax : Europa Cisco Systems Europe 11 Rue Camille Desmoulins Issy-les-Moulineaux Cedex 9 France www-europe.cisco.com Tel.: Fax: America 170 West Tasman Drive San Jose, CA USA Tel.: Fax: Asia-Pacifico Capital Tower 168 Robinson Road N fino a Singapore Tel.: Fax: Le filiali di Cisco Systems sono oltre 200 nel mondo. Gli indirizzi, i numeri di telefono e di fax sono disponibili sul sito Web Arabia Saudita Argentina Australia Austria Belgio Brasile Bulgaria Canada Cile Cina Colombia Corea Costa Rica Croazia Danimarca Emirati Arabi Filippine Finlandia Francia Germania Giappone Grecia Hong Kong India Indonesia Irlanda Israele Italia Lussemburgo Malesia Messico Norvegia Nuova Zelanda Olanda Perù Polonia Portogallo Portorico Regno Unito Repubblica Ceca Romania Russia Scozia Singapore Slovacchia Slovenia Spagna Sud Africa Svezia Svizzera Taiwan Thailandia Turchia U.S.A. Ucraina enezuela ietnam Zimbabwe Copyright Tutti i diritti riservati. Catalyst, Cisco, Cisco IOS, Cisco Systems e il logo Cisco Systems sono marchi registrati di CiscoSystems, Inc. e/o delle sue affiliate negli Stati Uniti e in altri Paesi. Gli altri marchi citati in questo documento o sul sito Web sono di proprietà dei rispettivi detentori. L uso della parola partner non implica una relazione di partnership tra Cisco e un altra società. (0202R) MSH/JSI/03.02