In questo articolo ci occuperemo di mettere in comunicazione (trunk) un centralino Avaya Ip Office con il call manager di Cisco usando come protocollo H323. Per i test in laboratorio, sono stati usati i seguenti apparati : 1) Avaya Ip Office 406 Versione software 3.2 2) Cisco Call Manager 4.1 installato su server virtuale Win2000Server Eng [Cisco Call Manager] Per prima cosa è necessario far diventare il call manager un gatekeeper. Dalla console di amministrazione del CCM andiamo su : Device->Gatekeeper Facciamo Add new Gatekeeper
E qui inseriamo i dati del nostro call manager. Se si usa il nome FQDN al posto dell indirizzo ip, accertarsi che venga correttamente risolto dal DNS interno. A questo punto facendo click su Update il nostro gatekeeper è pronto. Il secondo passaggio prevede la creazione di un gateway da usare per reindirizzare le chiamate verso la IpOffice. Selezioniamo Device->Gateway
Facciamo Add new Gateway VoipExperts.it - CISCO <=> AVAYA Selezioniamo come gateway un H323 Gateway Selezioniamo come protocollo H225 Procediamo cliccando il pulsante next
A questo punto è necessario fornire i dati IP del centralino Avaya. Anche qui, se si usa un nome FQDN, è necessario verificare che il nostro server DNS interno lo risolva correttamente nel corrispondente indirizzo IP. Pulsante Update per completare l inserimento del gateway. La terza ed ultima parte della configurazione del CCM prevede la creazione delle route pattern utili a reindirizzare il traffico telefonico desiderato attraverso il gateway IpOffice. Nel nostro esempio abbiamo creato 4 route pattern per le chiamate interne che iniziano con 2, 3, 8 e anche tutte le chiamate PSTN su rete fissa.
Chiaramente, chi conosce il CCM, sa che è possibile creare delle route list/group/pattern molto più complesse ed anche molto potenti. [Avaya IpOffice] Lato IpOffice le operazioni da fare sono identiche. Per prima cosa, dalla console di amministrazione della IpOffice, abilitiamo il gatekeeper : Sistema->Lan1->Gatekeeper Il secondo passaggio prevede la creazione del gateway, che nel caso di IpOffice viene chiamata Linea. Linea->Nuova Linea->Linea IP
Nelle impostazioni IP bisogna specificare l indirizzo IP del CCM Altra cosa importante su Linea Voip è l assegnazione degli ID sia per le chiamate in ingresso che per quelle in uscita, utili a discriminare la linea (gateway) nella definizione delle route. Nel nostro esempio abbiamo assegnato un ID = 90 Terzo ed ultimo passaggio è la definizione delle route, che su IpOffice viene fatta grazie ai codici funzione : Nel nostro esempio diremo al sistema che tutte le chiamate che iniziano con 9 e che sono seguite da due cifre qualsiasi (XX) devono essere inviate sulla linea (Gateway) con ID 90.
Fatto questo, il nostro sistema è pronto e funzionante. [Test Chiamate] Giusto per completare il nostro lavoro, andiamo a verificare che il nostro trunk funzioni correttamente. Per fare i test e per poter mostrare le immagini, abbiamo usato le versioni software sia dei telefoni o Cisco che Avaya, ma resta inteso, che il sistema è perfettamente funzionante da e per qualsiasi telefono connesso ai due PBX. Nei nostri test abbiamo connesso alla centrale IpOffice anche un centralino tradizionale Integral55 con trunk Qsig, rendendo di fatto possibile chiamare da e per I55 e Cisco Call Manager passando attraverso la IpOffice. Per i dettagli si può fare riferimento al documento (STI Sistema di telefonia Integrato) presente sul sito www.voipexperts.it e pubblicato anche sia su www.isaserver.it che sulla technet di microsoft nell ambito dell It Momentum Program. Apriamo il nostro telefono Cisco e chiamiamo un interno della IpOffice :
Chiamata in corso al numero 802 (Interno IpOffice) Il telefono IpOffice squilla : La comunicazione è avvenuta con successo. Ora proviamo a chiamare da IpOffice verso CCM :
Chiamata incorso al numero 901 (Interno CCM) Comunicazione avvenuta con successo.
[Test Servizi] Per quanto riguarda i servizi testati, trovate un riepilogo completo nella sezione del forum di voipexperts.it dedicata proprio a questo articolo. [Conclusioni] I test effettuati sono molto positivi e i due sistemi mostrano la loro potenza e professionalità comunicando anche con servizi avanzati (Es. Conferenza) in maniera ineccepibile. Giusto per completare l opera, andrebbe fatta una considerazione sui codec. In questo esempio abbiamo usato il codec G.711 che come sapete è quello che garantisce una migliore qualità ma che occupa una banda maggiore (circa 80k, 64 di compressione + 12 di overhead). Questo in una LAN ben strutturata potrebbe (dico potrebbe) anche andare bene, ma in una WAN? Bene è possibile usare altri codec (es. G.729) a discapito della qualità e a discapito anche del corretto funzionamento di servizi più avanzati come : Musica su attesa, conferenza, ivr, La soluzione a questi problemi è possibile usando un ambiente misto di codec ed in modo particolare usando dei metodi di conversione dei codec. Ma di questo ne parleremo in un altro articolo dedicato in maniera specifica ai codec.