CAPITOLO 3 INTERFACCIARE DEXGATE CON ASTERISK

CAPITOLO 3

INTERFACCIARE DEXGATE CON ASTERISK

In questo capitolo verrà illustrato come configurare il server Asterisk ed il server Dexgate in modo tale che i due centralini possano interfacciarsi fra loro e quindi rendere possibili chiamate interamente VoIP fra i loro utenti. La possibilità da parte di Dexgate di poter interoperare con il centralino Asterisk, come già accennato nell’introduzione, è molto importante, in quanto consente di poter inserire il centralino di CDC all’interno di scenari già esistenti dove sia presente una piattaforma Asterisk, che rappresenta il centralino PBX più comunemente usato, e quindi può rappresentare un aspetto rilevante per una maggiore diffusione del prodotto.

3.1

Creazione banco di prova

Uno schema dell’ambiente di lavoro creato è il seguente:

Figura 3.1 Banco di lavoro

Dexgate

Asterisk

100

780

110

770

Dexgate

Asterisk

100

780

110

770

È stata installata su una macchina Linux con distribuzione Suse 9 la versione 1.2.7 di Asterisk e a questo PC è stato assegnato l’indirizzo IP 192.168.70.75. Su Asterisk sono stati configurati due telefoni con numero interno 770 e 780 e con indirizzo IP rispettivamente 192.168.70.80 e 192.168.70.79.

Dall’altro lato è stato installato il server Dexgate con versione 1.0.2 su una macchina Linux con distribuzione Suse 9 assegnando a tale PC l’indirizzo IP 192.168.70.76. Anche su Dexgate sono configurati due telefoni con interni 100 e 101 e indirizzo IP rispettivamente 192.168.70.81 e 192.168.70.82.

Per essere in grado di monitorare i pacchetti SIP che transitano sia dai telefoni verso i server, sia fra i due server si è reso necessario l’utilizzo di uno sniffer; quindi è stato installato sopra entrambe le macchine, Ethereal, uno sniffer gratuito che consente di catturare tutti i pacchetti entranti e uscenti dal PC su cui è presente.

3.2

Piano di numerazione

Un aspetto rilevante in fase di progetto è il piano di numerazione. L’idea è quella di assegnare ad ogni server un numero identificativo, che viene a costituire una sorta di prefisso. Nel progetto, il server Asterisk è stato identificato dal numero 98, mentre il server Dexgate dal numero 96. In questo modo se l’utente 100 vuole contattare l’utente 770 registrato su Asterisk dovrà digitare 98770. Il 98 gli consentirà di inoltrare la chiamata su di un opportuno trunk che termina su Asterisk ed il 770 è il numero dell’interno di Asterisk a cui la chiamata è destinata.

Un’altra specifica che vogliamo sia rispettata è quella di fare in modo che sul display del telefono della persona chiamata venga visualizzato il numero

del chiamante costituito dal prefisso + numero interno. In questo modo il chiamato può salvare direttamente il numero del chiamante in rubrica senza dover aggiungere nessun prefisso, ed inoltre è possibile capire immediatamente da quale server la chiamata sta provenendo grazie alla visualizza zione del numero identificativo del server.

L’aver scelto come prefisso per Asterisk il numero 98 non è stato casuale. Questa decisione è stata dettata dal fatto che Dexgate consente di creare interni il cui numero inizi con una delle cifra comprese fra 1 e 6. Come detto nel capitolo 1, la regola URI che si genera automaticamente quando è creato un interno relativo ad un certo utente ha priorità 0. Nel caso in cui fosse stato scelto come prefisso identificativo di Asterisk il 10, poiché la regola URI che mi consente di inoltrare i pacchetti verso Asterisk ha una priorità maggiore di 0, ogni chiamata verso un numero che inizia con il 10 sarebbe diretta verso Asterisk e quindi di fatto avrei isolato tutti quegli utenti interni il cui numero inizia per 10 (es.100, 101, 102…)

Per sopperire al problema sopra illustrato, sarebbe stato sufficiente assumere come prefisso per Asterisk semplicemente il numero 7,8, 9 oppure lo 0. È stata effettuata una scelta di un prefisso su due cifre (98) per rendere la soluzione più scalabile e flessibile, infatti così facendo posso identificare altri server o trunk con i prefissi 97 oppure 94 oppure 93 e cosi via.

Infine un ultimo vantaggio portato da questo piano di numerazione è la possibilità di poter creare utenti con il solito numero interno ma appartenenti rispettivamente all’uno e all’altro server; cioè posso avere l’interno 100 sia su Dexgate, che su Asterisk. Se per esempio da un interno su Dexgate avessi voluto contattare un utente su Asterisk direttamente digitando il suo interno, al fine di evitare conflitti nella scelta delle regole di inoltro da parte del

server, non avrei potuto aver nessun utente su Dexgate con il solito interno dell’utente Asterisk chiamato.

3.3

Configurazione Centralini

In questa sezione viene descritto un possibile modo di configurare i due centralini in modo tale da permettere ai messaggi di segnalazione ed ai flussi RTP di transitare da un server all'altro; sarà messo in evidenza una prima problematica che impedirà ad Asterisk e Dexgate di propagare il flusso RTP da una parte all'altra e quindi ne verrà illustrata una possibile soluzione.

Configuriamo Dexgate :

§ il primo step da eseguire e quello di creare degli utenti.

Per fare questo è necessario loggarsi sul server con login e password dell'amministratore, che è l'unico a cui è concesso di creare utenti e gestire i file di configurazione.

Per creare un utente dobbiamo entrare nella sezione Gestione, quindi in Gestione utenti e in Crea utenti.

Nel nostro test abbiamo creato due utenti: il 100 ed il 110.

A seguito di questa operazione verranno create automaticamente le seguenti regole URI:

La seconda e la terza colonna della prima regola specificano che se al server Dexgate arriva una chiamata per il numero 100, questa deve essere instradata su di un trunk sip, in particolare sul trunk interno tegate verso l'utente che è identificato con il numero 100.Viceversa analizzando la quarta e quinta colonna si capisce che se sul trunk sip arriva una chiamata proveniente dall'utente 100, questa dovrà essere visualizzata sul display del telefono come 100.

§ il secondo step da eseguire è la modifica del file di configurazione jswitch.properties, quel file che viene letto ad ogni avvio del server e dove sono definiti i trunk da caricare e abilitare.

L'idea è quella di creare un nuovo trunk esterno senza registrazione, che chiameremo Micro, il cui compito è quello inoltrare i pacchetti che gli vengono passati dal Dexgate verso un'altra destinazione che in questo caso sarà proprio il server Asterisk.

Il nuovo trunk che verrà inserito nel jswitch.properties sarà il seguente:

#Trunk-Micro channels.phone.jswitch.trunks.trunk-Micro.classname=it.tradesoft.tegate.channels.CorbaChannel.jswitch.trunks.sip.SipTrunk channels.phone.jswitch.trunks.trunk-Micro.port=4006 channels.phone.jswitch.trunks.trunk-Micro.checkbusytable=no channels.phone.jswitch.trunks.trunk-Micro.limbo.enable=no channels.phone.jswitch.trunks.trunk-Micro.registration.table.classname= it.tradesoft.tegate.ssip.registration.ssipPatternIPRegistrationTable channels.phone.jswitch.trunks.trunk-Micro.registration.table.args=sip:(.*)@192.168.70.75 sip:$1@192.168.70.75:5060 channels.phone.jswitch.trunks.trunk-Micro.video.enable=no channels.phone.js witch.trunks.trunk-Micro.codec.0.classname=it.tradesoft.tegate.rtp.codec.gsm channels.phone.jswitch.trunks.trunk-Micro.codec.1.classname=it.tradesoft.tegate.rtp.codec.alaw #channels.phone.jswitch.trunks.trunk-Micro.callernmber.default=(.+) channels.phone.jswitch.trunks.trunk-Micro.callernumber.pattern=(.+) channels.phone.jswitch.trunks.trunk-Micro.callernumber.result=96$1 channels.phone.jswitch.trunks.trunk-Micro.sessionprogress.ignoring=yes channels.phone.jswitch.trunks.trunk-Micro.response4xx.action=LOCAL_BUSY Analizziamo il trunk-Micro:

la prima riga, identificata dalla parola classname, permette di classificare il trunk che stiamo definendo. In questo caso il trunk Micro è stato configurato in modo tale da appartenere alla categoria dei SipTrunk.

La seconda riga caratterizzata dalla parola port indica la porta, sul server Dexgate, sulla quale il trunk Micro, che abbiamo definito, sta in ascolto e in attesa di eventuali messaggi o pacchetti da inoltrare. La scelta del valore 4006 per la porta non è obbligatoria ma è importante prestare attenzione a non selezionarne una delle porte già utilizzate da Dexgate per gli altri trunk. La sesta riga caratterizzata dalla stringa registration.table.args è sicuramente la più significativa e, attraverso le regular expression, indica che nel caso in cui un pacchetto venga passato a questo trunk con il campo to espresso nella seguente forma (.*)@192.168.70.75, dove (.*) sta ad significare qualsiasi valore, il trunk-Micro deve inoltrare il pacchetto verso una nuova destinazione che in questo caso è 192.168.70.75:5060, dove il 192.168.70.75 è l'indirizzo IP del server Asterisk, mentre la porta 5060 è quella su cui di default (secondo lo standard SIP) il centralino Asterisk sta in ascolto per gli eventuali messaggi di segnalazione di chiamata.

Di default un trunk esterno senza registrazione presenta una stringa caratterizzata dall'identificativo callernumber.default la quale avrebbe il compito di inserire nel campo from del pacchetto da inviare verso la destinazione definita nella riga registration.table.args, ciò che viene definito

in questa stringa. Se per esempioci fosse l’esigenza che ogni chiamata uscente dal server Dexgate verso server Asterisk si presentasse con un campo from uguale a 058733, si dovrebbe inserire questo valore al termine della riga callernumber.default al posto di (.+). Poiché nelle specifiche di progetto non viene richiesto questo, possiamo commentare (cioè inserire il carattere # davanti) questa stringa; in tal modo quando all'avvio del server sarà caricato il trunk, questa riga non verrà letta.

Le specifiche di progetto richiedevano invece che il campo from fosse caratterizzato dal prefisso del server seguito dal numero di interno del chiamante.

Per rispettare tali richieste è necessario inserire due nuove stringhe nel trunk-Micro. Queste sono quelle caratterizzate dalle parole callernumber.pattern e callernumber.result.

La prima riga ha il compito di estrarre il campo from dal pacchetto che il terminale registrato su Dexgate ha inviato al proprio server. Tale campo sarà costituito dal numero di interno del telefono chiamante. La seconda riga deve invece anteporre al campo from estratto dal callernumber.pattern il prefisso 96, che identifica il Dexgate, e quindi inserire questo numero, costituito da 96+l'interno del chiamante, nel campo from del pacchetto che deve essere inoltrato verso Asterisk.

Affinché il trunk definito sopra sia caricato è necessario riavviare il Dexgate.

§ Il terzo step da compiere è quello di creare su Dexgate una regola di trasformazione URI che permetta di gestire le chiamate in entrata e in uscita sul trunk precedentemente definito.

Per fare questo è necessario loggarsi sul server come amministratore e selezionare Gestione=>GestioneAvanzata=>regole di trasformazione

URI. Si accederà ad una interfaccia che permette di inserire la regola URI. Valorizziamo i campi nei seguenti modi:

ü Priorità=1000 ;

ü Match in avanti=virtual:///98(.*) ;

ü Trasformazione in avanti=sip://trunk-Micro/$1@192.168.70.75; ü Match all’indietro=sip://trunk-Micro/(.*)@(.*);

ü Trasformazione all’indietro=virtual:///98$1

La stringa Match in Avanti indica quale deve essere la condizione sul numero chiamato affinché questa regola URI sia verificata e quindi eseguita. La regola sopra scritta viene verificata ogni volta che viene composto un numero che inizia con il 98, che è proprio il prefisso che identifica Asterisk. Nel caso in cui il Match in avanti sia verificato la chiamata viene inoltrata verso il trunk -Micro (che abbiamo creato), seguendo quanto è definito nella Trasformazione in avanti e cioè inserendo nel campo to del pacchetto solamente quelle cifre che seguono il 98; infatti il $1 indica il valore contenuto nelle parentesi tonde della stringa Match in avanti. È quindi il server Dexgate che si occupa di togliere il prefisso 98 dal campo to prima di inoltrare il pacchetto sul trunk-Micro e quindi verso Asterisk.

Il Match all’indietro si verifica invece ogni volta che arriva un messaggio dall’esterno sul trunk-Micro; infatti l’espressione regolare (.*)@(.*) indica che qualsiasi sia il numero chiamante e a qualunque dominio esso appartenga, il Match all’indietro è verificato; in tal caso il numero che verrà visualizzato sul display del telefono sarà quello definito nella stringa Trasformazione all’indietro, e cioè sarà anteposto un 98 davanti al campo from del pacchetto proveniente dal chiamante.

È possibile notare quindi che è ancora una volta il server Dexgate ad inserisce il prefisso, quindi il pacchetto che arriva sul trunk-Micro

proveniente dal server Asterisk dovrà essere tale da avere nel campo from solamente il numero di interno dell’utente registrato su Asterisk.

Passiamo ora alla configurazione di Asterisk. I passi da seguire sono due:

§ Come primo step configuriamo due utenti. Per fare questo è necessario aprire il file sip.conf ed inserire quanto segue:

[general] context=mytest [770] type=friend username=770 secret=1234 context=mytest host=dynamic [780] type=friend username=780 secret=1333 context=mytest host=dynamic

La voce context=mytest della sezione general indica che ogni chiamata che arriva su Asterisk, proveniente da un numero che non appartiene a nessuno dei contesti che si trovano nel file extensions.conf, deve essere inoltrate nel contesto mytest che sarà definito successivamente. Sono stati definiti poi due utenti di tipo friend, cioè che possono sia effettuare che ricevere chiamate. L’utente può essere di tre tipi: friend, come definito sopra, peer, che può solo ricevere le chiamate e user, il quale può solamente effettuare le chiamate. Ad ognuno degli utenti che abbiamo inserito nel file sip.conf è associata una password

770 192.168.70.80 Asterisk 192.168.70.75 Dexgate 192.168.70.76 INVITE sip :96100@192.168.70.75 407 P R O X Y AUTHENTICATION REQUIRED INVITE sip :96100@192.168.70.75 A C K TRYING INVITE sip :100@192.168.70.76 770 192.168.70.80 Asterisk 192.168.70.75 Dexgate 192.168.70.76 INVITE sip :96100@192.168.70.75 407 P R O X Y AUTHENTICATION REQUIRED INVITE sip :96100@192.168.70.75 A C K TRYING INVITE sip :100@192.168.70.76

rappresentata dal campo secret. Questa password sarà richiesta ai terminali da Asterisk al momento in cui essi richiedono di effettuare una chiamata, cioè quando inviano un messaggio di invite. Questo messaggio non è immediatamente inoltrato da parte dal server ma, come si può vedere dalla traccia ethereal di figura 3.3, prima di fare ciò Asterisk richiede al terminale chiamante di autenticarsi utilizzando appunto la password opportunamente codificata che è inserita nel file sip.conf e nel file di configurazione dei telefoni.

Figura 3.3 Traccia Autenticazione di Asterisk

Rispetto al primo invite spedito dal 770, nel secondo si trova una stringa di questo tipo:

ProxyAuthorization:Digestnonce=”42a7e26d”,realm=”asterisk”,response=”a75f5099533f7c8b7f111dd 81c8905e2”,uri:”sip;96100@192.168.70.75:5060”,username=”770”

Questa riga permette al terminale 770 di autenticarsi sul server e grazie a questo gli sarà consentito di effettuare una chiamata.

Entrambi gli utenti vengono fatti appartenere al contesto mytest per mezzo della stringa context=mytest che si trova sotto il campo secret. § Il secondo passo da fare è la configurazione del file extensions.conf nel

seguente modo: [mytest]

exten=>770,1,Dial(SIP/770) exten=>780,1,Dial(SIP/780)

exten=>_96.,1,Dial(SIP/${EXTEN:2}@192.168.70.76:4006)

In questo file è stato definito un contesto chiamato mytest; all’interno di questo contesto sono state definite le prime due stringhe che consentono, nel caso in cui arrivi una chiamata in questo contesto per il l’estensione 770 o 780, di lanciare con priorità 1 l’applicazione Dial che contatterà sul canale SIP rispettivamente l’utente 770 o l’utente 780 precedentemente definiti nel file sip.conf.

La terza stringa necessita di un maggiore approfondimento.

Prima di tutto il carattere _ posto davanti al 96 indica che questa è una regola di matching cioè che potrà essere verificata per una molteplicità di valori delle estensioni. Per questa stringa possono quindi essere utilizzate le espressioni regolari di Asterisk che differiscono in parte da quelle standard. Facciamo un elenco dei caratteri più comunemente utilizzati da Asterisk per effettuare il matching:

Ø X effettua un matching con le cifre da 0 a 9

Ø Z effettua un matching con le cifre da 1 a 9 Ø N effettua un matching con le cifre da 2 a 9

Ø [15-7] il matching in questo esempio si ha con le cifre 1,5,6,7 Ø . effettua il matching con uno o più cifre

Per la regola definita sopra è stato utilizzato il carattere . che sta ad indicare che dopo il 96 può esserci un numero qualsiasi di cifre; in generale ci sarà il numero interno del Dexgate a cui è destinata la chiamata.

Proseguendo nell’analisi della terza stringa si nota che nel caso in cui l’estensione sia verificata la chiamata viene inoltrata verso il terminale con indirizzo IP 192.168.70.76, che è l’indirizzo del server Dexgate, e sulla porta 4006, che è la porta dove il trunk-Micro è in ascolto. In più l’applicazione Dial inoltra la chiamata sul canale SIP, inserendo nel campo to del pacchetto il valore di ${EXTEN:2}; EXTEN rappresenta una variabile interna di Asterisk e assume il valore del numero che viene composto dal chiamante. Il numero EXTEN:2 rappresenta il numero che il chiamante ha digitato privo delle prime due cifre che rappresentano nel nostro esempio il prefisso identificativo del Dexgate.

In questo modo la chiamata verrà inoltrata verso Dexgate con un indirizzo di questo tipo:

INTERNO_DEXGATE@192.168.70.76:4006

Per esempio nel caso in cui il 770 chiami il 96100 la chiamata verrà passata da Asterisk a Dexgate con indirizzo 100@192.168.70.76:4006.

Come si può vedere, il server Asterisk non modifica il campo from del pacchetto, quindi al Dexgate arriverà un invite con campo from uguale a 770; sarà ancora il server Dexgate a preoccuparsi di porre davanti al 770 il prefisso 98 prima di visualizzarlo sul dislpay del telefono del chiamato.

Questo compito è ciò che è definito nella seconda parte (trasformazione all’indietro e match all’indietro) della regola URI precedentemente creata. Il campo from del pacchetto è possibile modificarlo anche attraverso Astrerisk, semplicemente aggiungendo nel file sip.conf al momento di configurare un utente, la stringa callerid. Di seguito un esempio:

[770] type=friend username=770 secret=1234 context=mytest host=dynamic callerid=333

In questo esempio il server Asterisk prima di inviare il pacchetto proveniente dal 770 cambierebbe il campo from da 770 a 333. È stato scelto di fare inserire e togliere i prefissi al server Dexgate, in quanto l’idea di base è quella di rendere minime le modifiche sul server Asterisk (che in teoria è già inserito in un contesto voip funzionante) per evitare che queste possano implicare ulteriori cambiamenti da apportare ad altri dispositivi collegati a questo.

Configurando come sopra i due server, andiamo a vedere se è possibile effettuare una chiamata da un utente Dexgate ad un utente Asterisk; per vedere i pacchetti che vengono scambiati, catturiamo una traccia di Ethereal su entrambi i server mentre viene generata una chiamata fra l’utente 100 di Dexgate e il 770 di Asterisk.

Uno schema della traccia Ethereal è illustrato nella figura 3.4:

100 192.168.70.81 Dexgate 192.168.70.76 Asterisk 192.168.70.75 INVITE sip:98770@192.168.70.76 770 192.168.70.80 INVITE INVITE s i p:770@192.168.70.76:5060 INVITE sip:770@192.168.70.80 100 TRYING 100 TRYING 100 TRYING 180 RINGING 180 RINGING 180 RINGING 200 OK-SDP 200 OK-SDP 200 OK-SDP ACK ACK ACK ACK ACK BYE BYE BYE ACK INVITE 100 TRYING ACK 200 OK-SDP 100 192.168.70.81 Dexgate 192.168.70.76 Asterisk 192.168.70.75 INVITE sip:98770@192.168.70.76 770 192.168.70.80 INVITE INVITE s i p:770@192.168.70.76:5060 INVITE sip:770@192.168.70.80 100 TRYING 100 TRYING 100 TRYING 180 RINGING 180 RINGING 180 RINGING 200 OK-SDP 200 OK-SDP 200 OK-SDP ACK ACK ACK ACK ACK BYE BYE BYE ACK INVITE 100 TRYING ACK 200 OK-SDP

Figura 3.4 Traccia di una chiamata dal 100 verso il 770 con il problema dei RE -INVITE

Ciò che viene percepito esternamente dagli utenti finali è questo:

il 100 dopo aver composto il numero 98770 sente squillare il telefono del chiamato; al momento che quest’ultimo alza la cornetta, al 100 viene inviato il tono di occupato, e la chiamata è quindi abbattuta.

Analizzando i pacchetti è possibile accorgersi che la causa dell’abbattimento della chiamata è da addossare al server Dexgate. Infatti a seguito del 200 OK il server Dexgate risponderà ad Asterisk con un ACK; ricevuto ciò, Asterisk invia un invite (evidenziati di verde nel disegno) verso le macchine

con le quali è in contatto (in questo caso verso il telefono dell’utente 770 e verso il centralino Dexgate).

Questi due invite, definiti anche re-invite, hanno il compito di comunicare ai destinatari di tale pacchetto l’indirizzo e la porta a cui poter inviare il flusso RTP diretttamente senza più attraversare il server Asterisk.

Nel pacchetto di re-invite inoltrato verso il terminale 770 verrà immessa una Session Description Protocol di questo tipo:

Figura 3.5 SDP del pacchetto di RE -INVITE indirizzato al 770

Sono stati evidenziati in rosso due campi che rappresentano l’indirizzo IP e la porta dove il terminale 770 deve inviare il traffico RTP. La porta 12014 è esattamente quella che era stata dichiarata dal server Dexgate nell’invite che questo aveva inoltrato verso Asterisk. In maniera del tutto simmetrica nel re-invite destinato al Dexgate si troverà una parte SDP dove sarà presente l’indirizzo IP del terminale 770 e la porta dove il telefono è in ascolto per il traficco RTP. Anche in questo caso la porta è quella che era stata dichiarata dal 770 nel pacchetto 200 OK-SDP che esso aveva inviato verso Astersik.

Un comportamento di questo tipo, cioè fare in modo che i pacchetti di segnalazione attraversino il server, mentre il flusso RTP venga scambiato direttamente fra i due end-point della comunicazione, è quello adottato di default da Asterisk. Questo modo di comportarsi è dovuto al fatto che in caso di molte chiamate contemporanee ci sarebbe un grosso carico sul server se si dovesse processare anche tutto il flusso RTP; mentre attraverso i re-invite, quindi permettendo al chiamante e al chiamato di scambiarsi il flusso RTP direttamente, Asterisk tenta di alleggerire la mole di carico da processare.

Purtroppo, come si vede dai log qui sotto, a seguito del re-invite il CommThread relativo a questa chiamata, notifica uno stato di Release, il che implica l’abbattimanto della chiamata e quindi l’invio di un Bye sia verso Asterisk che verso il terminale 100.

[ssipSessionLeg-Thread-8877] it.tradesoft.tegate.ssip.ssipSessionLeg Received RE -INVITE

[CommThread- Thread-8876] it.tradesoft.tegate.channels.CorbaChannel.commpool.CommThread -- -Release (2873,3) ---

Questo fenomeno si verifica perché il Dexgate non è in grado di gestire i pacchetti di Re-invite, perciò quando si trova processare tale pacchetto, abbatte la chiamata.

Come abbiamo visto Asterisk di default è programmato per effettuare delle chiamate non_routed (cioè dove solo la segnalazione passa dal server); questa politica è in contrapposizione con la filosofia centralizzata con cui è stato progettato Dexgate, il quale esige che, oltre la segnalazione, anche il flusso RTP debba passare dal server. Si è resa necessaria questa scelta per poter implementare dei servizi come la Conference, che richiede l’apporto del server per la miscelazione dei vari flussi audio provenienti dai partecipanti, la registrazione delle chiamate, la cui traccia viene salvata sul

server che quindi necessita di conoscere anche dal flusso RTP, oppure il semplice trasferimento di chiamata .

Dall’analisi svolta sopra è stato dedotto che la causa dell’abbattimento della chiamata è stato l’invio da parte di Asterisk dei re-invite che il Dexgate non riesce a gestire. La soluzione al problema consiste nel evitare che Asterisk generi questi messaggi in modo tale che anche esso, come Dexgate, accetti di processare il flusso RTP.

Questa soluzione, che apparentemente può sembrare un limite alle funzionalità di Asterisk, in realtà non lo è infatti, come sarà illustrato meglio in seguito, affinché Asterisk possa effettuare dei rinvii di chiamata ha la necessità di processare anche il flusso RTP e quindi durante la fase di instaurazione della chiamata non inoltrerà più pacchetti di re -invite.

I modi per far si che Asterisk, al momento in cui la chiamata è stata accettata, non invii i re-invite sono tre:

Ø il primo è quando i due end-point della comunicazione non supportano nessun codec comune e quindi è indispensabile l’operazione di transcodifica da parte del server sui pacchetti RTP affinché il chiamante ed il chiamato possano comunicare.

Ø Il secondo è quello di aggiungere la stringa canreinvite=no nel file sip.conf al momento di creare gli utenti.

Perciò il file sip.conf si presenterà così: [general] context=mytest [770] type=friend username=770 secret=1234 context=mytest host=dynamic canreinvite=no [780] type=friend username=780 secret=1333 context=mytest host=dynamic canreinvite=no

Asterisk quando almeno uno dei partecipanti alla comunicazione ha settato il campo canreinvite=no, non genera i reinvite.

Ø Il terzo è quello di inserire all’interno dell’applicazione Dial(), quindi nel file extensions.conf, una delle seguenti opzioni: t, T, w, W, h, H, L.

Per risolvere il problema dell’invio da parte di Asterisk dei re-invite viene utilizzato il secondo metodo, quindi sarà modificato il file sip.conf nella maniera descritta sopra.

Una volta riavviato Asterisk in modo da caricare la nuova configurazione, viene ripetuta la prova eseguita in precedenza, cioè una chiamata dall’utente 100 verso il 770.

Uno schema della traccia Ehtereal catturata è rappresentato in figura 3.6. Con le modifiche apportate al file sip.conf, la chiamata va a buon fine, non vengono più inviati i re -invite da parte di Asterisk ed il flusso RTP viene ad attraversare entrambi i centralini. È interessante osservare che il traffico RTP subisce, nel passare dal chiamante al chiamato un cambiamento di codifica; infatti i centralini con i rispettivi terminali comunicano con il

100 192.168.70.81 Dexgate 192.168.70.76 Asterisk 192.168.70.75 INVITESDP(G711A,g711U,g729,g723) sip:98770@192.168.70.76 770 192.168.70.80 INVITE SDP( GSM, g711A) sip:770@192.168.70.76:5060 INVITESDP(g711A,g711u,GSM) sip:770@192.168.70.80 100 TRYING 100 TRYING 100 TRYING 180RINGING 180 RINGING 180 RINGING BYE 200 OKSDP(g711A) 200 OKSDP(g711A,GSM) ACK ACK ACK ACK BYE BYE 200 OK 200 OK 200 OKSDP(g711A) RTPg711A RTPg711A RTPg711A RTPGSM RTPGSM RTPg711A 100 192.168.70.81 Dexgate 192.168.70.76 Asterisk 192.168.70.75 INVITESDP(G711A,g711U,g729,g723) sip:98770@192.168.70.76 770 192.168.70.80 INVITE SDP( GSM, g711A) sip:770@192.168.70.76:5060 INVITESDP(g711A,g711u,GSM) sip:770@192.168.70.80 100 TRYING 100 TRYING 100 TRYING 180RINGING 180 RINGING 180 RINGING BYE 200 OKSDP(g711A) 200 OKSDP(g711A,GSM) ACK ACK ACK ACK BYE BYE 200 OK 200 OK 200 OKSDP(g711A) RTPg711A RTPg711A RTPg711A RTPGSM RTPGSM RTPg711A

codec g711A, mentre sul trunk-Micro, quello che unisce i due server, la comunicazione avviene utilizzando il codec GSM

.

Figura 3.6 Traccia di una chiamata dal 100 verso il 770

Questa scelta è dovuta al fatto che il codec GSM comprime molto di più i dati rispetto al g711A e quindi porta ad una minore occupazione di banda. Ovviamente più un codec è aggressivo in termini di compressione, peggiore sarà la qualità della telefonata che nella tabella seguente è espressa con l’indice MOS:

CODEC BANDA Kbit/s MOS

G.711 80 4.3-4.7 G.726-32 48 3.9-4.2 G.729A 24 3.6-3.7 G.732.1 17 3.4-3.5 GSM 27 3.7-3.9 ILBC 27 3.7-4.1

Figura 3.7 Tabella codec / banda / MOS

Per come sono stati configurati i due centralini è stato osservato che l’utente 100 ed il 770 possono comunicare fra loro sia nel caso in cui il 100 sia il chiamante, sia nel caso in cui questo sia il chiamato e, per come abbiamo definito le regole URI e il Trunk-Micro sul Dexgte, che sul display del telefono chiamato compare il numero del chiamante nella forma prefisso +interno.

Lo step successivo è quello di permettere all’utente del Dexgate (in questo caso il 100) di poter salvare in rubrica il numero visualizzato del chiamante (in questo caso potrebbe essere il 98770).

Affinché questa operazione avvenga in maniera corretta, cioè in modo tale che l’utente 100 possa generare successivamente una chiamata verso il 770, facendo semplicemente un click sul nome con cui lo ha salvato in rubrica, è necessario effettuare una modifica in un altro file di configurazione di Dexgate. Questo file, la cui parte coinvolta è inserita qui sotto, si chiama default.properties ed al suo interno si trova una stringa che automaticamente inserisce uno 0 davanti al numero che viene salvato in rubrica proveniente da un trunk esterno.

default.phonebook.prefix=0

Nel nostro caso, se lasciassi scommentata questa riga, il numero del chiamante sarebbe salvato in rubrica come 098770 e non come 98770. Così facendo, al momento in cui l’utente 100 volesse chiamare il 770 cliccando sul nome associatogli in rubrica, non ci riuscirebbe in quanto la chiamata sarebbe inoltrata verso lo 098770 che quindi non verificherebbe la regola URI che è stata definita per inoltrare la chiamata sul trunk-Micro. Per evitare questo problema basta commentare questa riga nel file default.properties e quindi riavviare il servizio.

L’utilità della riga che è stata commentata la si può vedere nel caso in cui in Dexgate fosse presente un solo trunk esterno, per esempio un trunk che punta verso un gateway FXO, la cui regola URI per esempio abbia la parte di Match in avanti e di Trasformazione in avanti nel seguente modo:

Match in avanti=virtual:///0(.*)

Trasformazione in avanti=sip://trunk -FXO/$1@dexgate

Nel caso in cui si riceva una chiamata da un cellulare (per esempio 3992222222) il numero che verrà salvato sarà 03992222222. Così facendo al momento che si clicca sul nome dell’utente con cui è stato salvato questo cellulare, partirà una chiamata per lo 03992222222; questo andrà a verificare la regola URI sopra scritta che quindi inoltrerà la chiamata sul trunk-FXO che a sua volta attraverso il gateway FXO la invierà sulla rete PSTN.

In presenza di più trunk esterni, per far sì che sia ancora possibile salvare il numero visualizzato del chiamante in rubrica senza doverlo modificare manualmente, è sufficiente definire la trasformazione all’indietro e il match all’indietro della regola URI relativa a tale trunk esterno, in modo tale da

anteporre al numero del chiamante, prima della visualizzazione sul display, il prefisso che permetta di uscire dal trunk dal quale la chiamata è arrivata. Nel caso del gateway FXO la regola andrebbe modificata nel seguente modo:

Trasformazione all’indietro=sip://trunk -FXO/(.*)@(.*) Match all’indietro=virtual:///0$1

In questo modo il numero di ogni chiamata in arrivo sul trunk-FXO sarà visualizzato con uno 0 davanti, così da poterlo salvare direttamente in rubrica e quindi anche in presenza di più trunk esterni c’è la possibilità di commentare la riga del file default.properties prestando attenzione a effettuare il piccolo accorgimento sopra descritto per le regole URI.

Per rendere completa l’interoperabilità fra i due centralini, è necessario verificare che le funzione come il rinvio di chiamata con o senza offerta, siano garantite su questo trunk.

Per verificare questo sono state svolte quatto prove di rinvio con o senza offerta e ne è stato osservato l’esito.

Come primo test è stata instaurata una chiamata dall’utente 770 all’utente 100, il quale ha effettuato un rinvio di chiamata senza offerta verso il 780. Questo test ha avuto esito positivo, infatti al momento che l’utente 100 ha premuto *3 98780 # ( dove *3 NUMERO A CUI RINVIARE # è il modo per effettuare il rinvio di chiamata da tastierino, sfruttando i toni DTMF, per un utente Dexgate),viene instaurata una comunicazione fra l’utente 770 ed il 780.

Come secondo test la chiamata è stata ancora effettuata dal 770 verso il 100, che però questa volta ha rinviato la chiamata con offerta verso l’utente

780. L’esito di questo test, del quale è riportato sotto uno schema della traccia Ethereal, è stato negativo.

Figura 3.8 Traccia di una chiamata dal 770 verso il 100 con rinvio con offerta verso 780 che non va a buon fine

780 192.168.70.79 Asterisk 192.168.70.75 Dexgate 192.168.70.76 100 192.168.70.81 770 192.168.70.80 INVITE (1) INVITE (3) INVITE (2) TRYING TRYING TRYING RINGING RINGING RINGING 200 OK ACK 200 OK ACK 200 OK ACK RTP INFO 200 OK INVITE (4) TRYING INVITE (5) TRYING RINGING 200 OK ACK RINGING 200 OK ACK BYE 200 OK BYE 200 OK BYE 200 OK INVITE (6) TRYING INVITE (7) 486 BUSY HERE ACK BYE 200 OK 200 OK CANCEL 487 REQUEST TERMINATED 200 OK RTP RTP RTP RTP RTP BYE 780 192.168.70.79 Asterisk 192.168.70.75 Dexgate 192.168.70.76 100 192.168.70.81 770 192.168.70.80 INVITE (1) INVITE (3) INVITE (2) TRYING TRYING TRYING RINGING RINGING RINGING 200 OK ACK 200 OK ACK 200 OK ACK RTP INFO 200 OK INVITE (4) TRYING INVITE (5) TRYING RINGING 200 OK ACK RINGING 200 OK ACK BYE 200 OK BYE 200 OK BYE 200 OK INVITE (6) TRYING INVITE (7) 486 BUSY HERE ACK BYE 200 OK 200 OK CANCEL 487 REQUEST TERMINATED 200 OK RTP RTP RTP RTP RTP BYE

In viola sono evidenziati i pacchetti sip di INFO che vengono generati a seguito di una pressione di un tasto del telefono il quale genera un tono che viene interpretato dal server Dexgate.

In questo caso il telefono preme *7 98780 # ( dove *7 NUMERO A CUI RINVIARE # è il modo per effettuare il rinvio di chiamata con offerta da tastierino). Il primo pacchetto di INFO sarà così strutturato:

In questo pacchetto viene comunicato al Dexgate che l’utente 100 ha premuto il tasto *. Quando il server vedrà dal secondo pacchetto che l’utente ha digitato 7, allora capisce che si sta richiedendo di effettuare un rinvio di chiamata con offerta ed il numero a cui verrà rinviata la chiamata sarà quello compreso fra il tono 7 ed il tono #.

Il rinvio con offerta è composto da tre step: Ø Il 770 chiama il 100

Ø Il 100 mette in attesa il 770 ed entra in comunicazione con il 780

Ø Se il 780 accetta la comunicazione con il 770, allora quando il 100 attacca il telefono viene creata la chiamata fra i due utenti; se il 780 rifiuta di parlare con il 770, allora nel momento in cui aggancerà la cornetta verrà nuovamente ripresa la chiamata fra il 100 ed il 770.

Dalla traccia Ethereal si può vedere che i primi due step del rinvio con offerta sono andati a buon fine mentre il terzo no; infatti una volta che il 100 ha attaccato la cornetta viene creato un invite dal Dexgate (nel disegno è l’invite 6) che ha come destinatario il 780 e come mittente il 9698770 (96 che viene sempre inserito nel campo from di un pacchetto uscente da Dexgate e 98770 che è il numero da cui l’utente 100 è stato contattato e che deve essere messo in comunicazione con il 780).

Dopo che l’utente 100 avrà attacato il telefono, Asterisk si vedrà arrivare quello che nella figura 3.8 è l’invite 6; quando Asterisk inoltrerà tale invite verso il 780 (invite 7), avendo esso la cornetta alzata, si vedrà rispondere con un 486 Busy Here e quindi propagherà verso Dexgate un Bye che porta all’abbattimento della chiamata; infatti Dexgate inoltrerà ora un cancel verso Astersk e la richiesta di chiamata verso il 780 verrà terminata.

Per risolvere questo problema deve essere effettuata una modifica nel file extensions.conf in modo tale da consentire alle estensioni coinvolte di poter gestire eventuali rinvii di chiamata. Tali modifiche consistono nell’aggiungere delle opzioni da passare all’applicazione Dial nel momento in cui questa viene invocata. Queste opzioni sono le seguenti:

§ T § t

aggiungendo questa due opzioni l’utente ha la possibilità di gestire un rinvio di chiamata sia nel caso in cui è egli stesso a rinviarla sia nel caso in cui si trova ad essere il destinatario del rinvio.

Il file extensions.conf risulterà dunque il seguente: [mytest]

exten=>770,1,Dial(SIP/770,30,tT) exten=>780,1,Dial(SIP/780,30,tT)

exten=>_96.,1,Dial(SIP/${EXTEN:2}@192.168.70.76:4006,30,tT) è stato aggiunto anche il valore 30 nella stringa. Questo numero rappresenta un time -out ed indica che dopo 30 secondi si deve passare al comando con priorità due (non presente nel diaplan sopra illustrato) se l’applicazione Dial non è riuscita a contattare ancora l’utente 770. Nell’esempio sopra non essendoci il comando a priorità 2 la chiamata dopo 30 secondi viene abbattuta.

Affinché sia possibile effettuare il trasferimento di chiamata con offerta è necessario effettuare anche una modifica nel file jswitch.properties del server Dexgate. Questa modifica consiste nell’abilitare uno stato particolare della chiamata che viene definitochiamato Limbo.

Senza questo stato, nel momento in cui l’utente 100 aggancia la cornetta, viene abbattuta la comunicazione fra il 100 ed il 780 con la conseguente chiusura delle porte RTP negoziate attraverso i pacchetti di invite e 200 OK scambiati in precedenza. A conferma di tutto questo è da notare il fatto che il pacchetto di BYE, a seguito del quale vengono chiusi i canali audio, inviato dal 100 viene propagato fino ad arrivare all’utente 780. Questo implica che al momento in cui il 770 deve essere messo in contatto con il 780, è necessaria una nuova negoziazione del canali audio e quindi un

nuovo invite con SDP da parte del Dexgate verso il 780, che come è stato verificato, risulterà essere occupato.

Per abilitare il limbo sul trunk-Micro è necessario settare a YES la riga identificata da limbo.enable e aggiungere una nuova riga dove è definita la durata del limbo che in questo caso è stata settata ad 1 secondo. Il trunk-Micro in conclusione apparirà nel seguente modo (in rosso sono evidenziati i cambiamenti da apportare rispetto al trunk-Micro definito in precedenza): #Trunk-Micro channels.phone.jswitch.trunks.trunk-Micro.classname=it.tradesoft.tegate.channels.CorbaChannel.jswitch.trunks.sip.SipTrunk channels.phone.jswitch.trunks.trunk-Micro.port=4006 channels.phone.jswitch.trunks.trunk-Micro.checkbusytable=no channels.phone.jswitch.trunks.trunk-Micro.limbo.enable=yes channels.phone.jswitch.trunks.trunk-Micro.limbo.time=1 channels.phone.jswitch.trunks.trunk-Micro.registration.table.classname= it.tradesoft.tegate.ssip.registration.ssipPatternIPRegistrationTable channels.phone.jswitch.trunks.trunk-Micro.registration.table.args=sip:(.*)@192.168.70.75 sip:$1@192.168.70.75:5060 channels.phone.jswitch.trunks.trunk-Micro.video.enable=no channels.phone.jswitch.trunks.trunk-Micro.codec.0.classname=it.tradesoft.tegate.rtp.codec.gsm channels.phone.jswitch.trunks.trunk-Micro.codec.1.classname=it.tradesoft.tegate.rtp.codec.alaw #channels.phone.jswitch.trunks.trunk-Micro.callernmber.default=(.+) channels.phone.jswitch.trunks.trunk-Micro.callernumber.pattern=(.+) channels.phone.jswitch.trunks.trunk-Micro.callernumber.result=96$1 channels.phone.jswitch.trunks.trunk-Micro.sessionprogress.ignorino=yes channels.phone.jswitch.trunks.trunk-Micro.response4xx.action=LOCAL_BUSY

Se viene ripetuto nuovamente il test due, cioè il 770 chiama il 100 che rinvia con offerta verso il 780, dopo aver riavviato Asterisk e Dexgate in modo da caricare le modifiche appartate, si ottiene la traccia Ethereal illustrata in figura 3.9.

Da un analisi del disegno è possibile notare che al momento in cui l’utente 100 attacca la cornetta, viene generato un pacchetto sip di BYE, che però questa volta non si propaga fino all’utente 780 ma soltanto fino

al server Dexgate il quale provvederà a chiudere le porte RTP aperte per comunicare con l’utente 100.

Figura 3.9 Traccia di una chiamata dal 770 verso il 100 con rinvio con offerta verso 780

780 192.168.70.79 Asterisk 192.168.70.75 Dexgate 192.168.70.76 100 192.168.70.81 770 192.168.70.80 INVITE (1) INVITE (3) INVITE (2) TRYING TRYING TRYING RINGING RINGING RINGING 200 OK ACK 200 OK ACK 200 OK ACK RTP INFO 200 OK INVITE (4) TRYING INVITE (5) TRYING RINGING 200 OK ACK RINGING 200 OK ACK BYE 200 OK BYE 200 OK BYE 200 OK BYE 200 OK RTP RTP RTP RTP RTP RTP BYE 200 OK RTP RTP 780 192.168.70.79 Asterisk 192.168.70.75 Dexgate 192.168.70.76 100 192.168.70.81 770 192.168.70.80 INVITE (1) INVITE (3) INVITE (2) TRYING TRYING TRYING RINGING RINGING RINGING 200 OK ACK 200 OK ACK 200 OK ACK RTP INFO 200 OK INVITE (4) TRYING INVITE (5) TRYING RINGING 200 OK ACK RINGING 200 OK ACK BYE 200 OK BYE 200 OK BYE 200 OK BYE 200 OK RTP RTP RTP RTP RTP RTP BYE 200 OK RTP RTP

A seguito di questo Bye l’utente 770 è messo immediatamente in comunicazione con il 780, senza la necessità da parte di Dexgate di inviare un nuovo invite verso di esso, che abbiamo visto essere la causa dell’abbattimento della chiamata nella prova precedente.

Poiché la chiamata è stata rinviata da un utente appartenete al Dexgate, nonostante che la comunicazione finale sia fra il 770 ed il 780, cioè fra due utenti di Asterisk, il traffico RTP attraverserà anche il server Dexgate.

Con i disegni sotto è possibile approfondire meglio che cosa succede al flusso RTP durante le tre fasi del rinvio con offerta di questa chiamata.

La chiamata è generata dall’utente 770 verso l’utente 100; attraverso i pacchetti di invite e di 200 OK, i quali contengono la parte SDP di descrizione di come e dove trasmettere il flusso audio, vengono negoziate le porte sulle quali inviare il flusso RTP. Tale flusso per la chiamata fra il 770 ed il 100 attraversa quelle porte che in figura 3.10 sono colorate in rosso, mentre la successiva chiamata fra l’utente 100 ed il 780 le porte che sono rappresentate in nero:

Figura 3.10 Porte utilizzate nella comunicazione

Dexgate

Asterisk

100

780

770

Dexgate

Asterisk

100

780

770

È da notare che le porte con cui il 100 parla con Dexgate e viceversa restano immutate e vengono negoziate soltanto una volta attraverso l’invite che nel disegno è rappresentato come invite(3) ed il rispettivo 200 OK. A seguito del Bye da parte del 100 vengono chiuse le porte fra il 100 ed il Dexgate, ed il 770 e messo in comunicazione con il 780. Il flusso RTP seguirà il percorso rappresentato dalla linea gialla in figura 3.11:

Figura 3.11 Percorso del flusso RTP dal 770 al 780

Il centralino Dexgate una volta chiusi i canali con l’utente 100 a seguito del BYE effettua, nell’esempio sopra rappresentato, una richiusura della porta 12056 sulla 12060 in modo tale che tutto ciò che arriva sulla prima porta viene inviato sulla seconda e viceversa.

Le altre due prove testate sono quelle in cui è Asterisk a gestire il rinvio della chiamata.

La terza prova consiste perciò nell’effettuare una chiamata dall’utente 100 verso il 770, il quale la rinvierà senza offerta all’utente 110.

Per poter effettuare il rinvio di una chiamata con o senza offerta attraverso un terminale registrato su Asterisk, deve essere configurato un file che si

Dexgate

Asterisk

100

780

770

Dexgate

Asterisk

100

780

770

chiama feature.conf. In questo file è possibile definire a quale combinazione di tasti associare un certo servizio. Per esempio configurare il file feature.conf come illustrato sotto fa sì che attraverso la combinazione di tasti *1 NUMERO A CUI RINVIARE venga effettuato un rinvio di chiamata blind (senza offerta), mentre con *7 NUMERO A CUI RINVIARE è generato un rinvio attend (con offerta).

[featuremap] blindxfer => *1 atxfer => *7

La quarta prova consiste nell’effettuare una chiamata dal 100 per il 770, il quale la rinvierà con offerta verso il 110.

Sia la terza che la quarta prova, a seguito delle modifiche apportate in precedenza su Dexgate e Asterisk, hanno fornito esito positivo.

Osservando lo schema della traccia Ethereal sotto illustrato in figura 3.12 catturata in occasione dello svolgimento della quarta prova, è da rilevare come il comportamento di Asterisk sia del tutto simmetrico rispetto a quello del Dexgate; infatti anche Asterisk, a seguito del bye inviato dal 770, si preoccupa di richiudere i canali audio usati per la comunicazione fra il 100 ed il 770 su quelli usati per la comunicazione fra il 770 ed il 110;

Figura 3.12 Traccia del rinvio di chiamata con offerta gestito da Asterisk

Anche in questo caso, nonostante la comunicazione finale sia fra due utenti appartenenti a Dexgate, poichè questa è nata a seguito di un rinvio di chiamata effettuato da un utente Asterisk, si avrà che il traffico RTP attraverserà ancora Asterisk come illustrato nel disegno in figura 3.13.

192.168.70.82 192.168.70.81 192.168.70.76 192.168.70.75 192.168.70.80 INVITE (1) INVITE (3) INVITE (2) TRYING TRYING TRYING RINGING RINGING RINGING 200 OK ACK 200 OK ACK 200 OK ACK RTP RTP DTMF *9 96110 INVITE (4) TRYING INVITE (5) TRYING RINGING 200 OK ACK RINGING 200 OK ACK BYE 200 OK BYE 200 OK BYE 200 OK BYE 200 OK RTP RTP RTP RTP RTP RTP BYE 200 OK RTP RTP 192.168.70.82 192.168.70.81 192.168.70.76 192.168.70.75 192.168.70.80 INVITE (1) INVITE (3) INVITE (2) TRYING TRYING TRYING RINGING RINGING RINGING 200 OK ACK 200 OK ACK 200 OK ACK RTP RTP DTMF *9 96110 INVITE (4) TRYING INVITE (5) TRYING RINGING 200 OK ACK RINGING 200 OK ACK BYE 200 OK BYE 200 OK BYE 200 OK BYE 200 OK RTP RTP RTP RTP RTP RTP BYE 200 OK RTP RTP

Figura 3.13 Percorso del flusso RTP dal 100 al 110 dopo il rinvio con offerta compiuto da Asterisk

Una differenza che è possibile notare fra quest’ultima traccia Ethereal e la precedente è nel modo con cui il telefono comunica al server la volontà di effettuare un rinvio di chiamata con offerta. Mentre il l’utente 100 è configurato in modo tale da inviare ad Dexgte i toni premuti sul tastierino del telefono all’interno di pacchetti sip, il 770 invece invia questi toni all’interno dei pacchetti RTP.

È da sottolineare inoltre che entrambi i centralini sono in grado di gestire tutte e due le modalità di inoltro dei toni DTMF

3.4

Architettura centralini con un centro stella

Attraverso il paragrafo precedente sono state illustrate le modalità per collegare e rendere interoperabili fra di loro il centralino Asterisk e quello Dexgate.

Una volta preso atto di questo, una possibile richiesta può essere quella di collegare fra di loro varie sedi (aziende) periferiche, ognuna della quale gestite da un centralino Dexgate.

Supponiamo di avere N sedi che debbano essere messe in comunicazione fra loro. Per raggiungere questo scopo esistono due tipi di soluzioni:

Dexgate

Asterisk

770

100

110

Dexgate

Asterisk

770

100

110

§ configurare il centralino Dexgate di ogni azienda in modo tale da inserire nel file Jswitch.properties N-1 trunk, ognuno dei quali abbia come altro estremo una delle restanti sedi.

Questa soluzione comporta in fase di configurazione la definizione di un numero elevato di trunk dell’ordine di N2 ed inoltre ad ogni trunk deve essere associata la relativa regola URI che consenta di inoltrare la chiamata verso l’opportuna sede.

Per ogni sede si viene a creare uno scenario di questo tipo:

Figura 3.14 Scenario per collegare una sede alle altre N-1

Adottare questa soluzione comporta anche un ulteriore problematica da affrontare allorchè venga introdotta una nuova sede. In tal caso infatti si dovrebbe aggiungere in ognuna delle N sedi un nuovo trunk che abbia come estremo terminale la nuova sede introdotta; inoltre affinché sia possibile uscire da questo trunk si ha bisogno di una regola URI che lo permetta. Sede 2 Sede 6 Sede 5 Sede 1 Sede 4 Sede 3 TRUNK 3 TRUNK 2 TRUNK 5 TRUNK 4 TRUNK 1 Sede 2 Sede 6 Sede 5 Sede 1 Sede 4 Sede 3 TRUNK 3 TRUNK 2 TRUNK 5 TRUNK 4 TRUNK 1

Riepilogando, all’introduzione della sede N+1 segue la creazione di N trunk e N regole URI, quindi deve essere modificato il jswitch.properties e la configurazione di tutti i centralini Dexgate coinvolti.

§ La seconda soluzione possibile è quella di introdurre un centralino, al quale tutti i Dexgate periferici sono collegati, con una intelligenza superiore che abbia la capacità di smistare fra le varie sedi le chiamate.

Figura 3.15 Scenario per il collegamento di N sedi con un Centro Stella

In questo caso viene unita ogni sede a questo centralino attraverso un trunk e quindi la complessità del numero dei trunk è dell’ordine di N e non più N2_.

Un altro vantaggio di questa soluzione rispetto alla precedente sta nel fatto che se viene introdotta la nuova sede N+1, non c’è la necessità di creare nessun trunk aggiuntivo sugli N centralini già esistenti, e di

Sede 2 Sede 6 Sede 5 Sede 1 Sede 4 Sede 3 TRUNK 3 TRUNK 2 TRUNK 5 TRUNK 4 TRUNK 1 Centro stella TRUNK 6 Sede 2 Sede 6 Sede 5 Sede 1 Sede 4 Sede 3 TRUNK 3 TRUNK 2 TRUNK 5 TRUNK 4 TRUNK 1 Centro stella TRUNK 6 Asterisk 99 Dexgate 93 Dexgate 95 Dexgate 92 Dexgate 96 Dexgate 94 Dexgate 91 100 200 Asterisk 99 Dexgate 93 Dexgate 95 Dexgate 92 Dexgate 96 Dexgate 94 Dexgate 91 100 200

conseguenza non occorre creare nessun altra regola URI. Adottando questa soluzione la nascita di una nuova sede aziendale risulta del tutto trasparente alle altre aziende.

3.5

Implementazione architettura con Asterisk centro

stella

Per creare un’architettura, come quella illustrata sopra, che unisca le N sedi periferiche gestite da centralini Dexgate, è possibile utilizzare come centro stella il centralino Asterisk.

PIANO DI NUMERAZIONE

Il piano di numerazione svolge sempre un ruolo importante in fase di progetto ed in questo caso è tale da identificare sia i centralini periferici Dexgate, sia il centro stella Asterisk attraverso un prefisso. Lo scenario, dove sono rappresentati per semplicità solamente due utenti (il 100 ed il 200) si presenterà nel modo rappresentato in figura 3.16.

Questa numerazione implica che se l’utente 100 appartenente al Dexgate con prefisso 95 desidera contattare il 200 che invece appartiene al Dexgate con prefisso 93, dovrà digitare il seguente numero:

Ø 99 93 200

dove attraverso il 99 la chiamata viene inoltrata verso Asterisk il quale per mezzo del prefisso 93 la indirizza verso l’opportuno centralino Dexgate di periferia.

In questo progetto con architettura a centro stella una specifica richiesta è quella di fare in modo che il numero visualizzato sul display del telefono chiamato sia composto da prefisso Asterisk + prefisso Dexgate chiamante + interno Dexgate chiamante. In questo modo il numero può essere salvato direttamente in rubrica e quindi ricontattato semplicemente cliccando sul nome ad esso associato.

3.6

Configurazione Centralini

In questo paragrafo verrà descritto prima come configurare un generico centralino Dexgate di periferia caratterizzato per esempio da un prefisso uguale a 95, dopo di che sarà illustrato come configurare Asterisk in modo tale che possa smistare le varie chiamate verso i server periferici.

DEXGATE:

per prima cosa deve essere definito un trunk, che in questo progetto è chiamato Stella, che colleghi il Degate ad Asterisk. Supponendo che, come nel progetto precedente, la macchiana Asterisk abbia indirizzo IP 192.168.70.75, il trunk Stella sarà il seguente:

#Trunk-Stella channels.phone.jswitch.trunks.trunk-Stella.classname=it.tradesoft.tegate.channels.CorbaChannel.jswitch.trunks.sip.SipTrunk channels.phone.jswitch.trunks.trunk-Stella.port=4006 channels.phone.jswitch.trunks.trunk-Stella.checkbusytable=no channels.phone.jswitch.trunks.trunk- Stella.limbo.enable=yes channels.phone.jswitch.trunks.trunk- Stella.limbo.time=1 channels.phone.jswitch.trunks.trunk-Stella.registration.table.classname= it.tradesoft.tegate.ssip.registration.ssipPatternIPRegistrationTable channels.phone.jswitch.trunks.trunk-Stella.registration.table.args=sip:(.*)@192.168.70.75 sip:$1@192.168.70.75:5060 channels.phone.jswitch.trunks.trunk- Stella.video.enable=no channels.phone.jswitch.trunks.trunk- Stella.codec.0.classname=it.tradesoft.tegate.rtp.codec.gsm channels.phone.jswitch.trunks.trunk- Stella.codec.1.classname=i t.tradesoft.tegate.rtp.codec.alaw #channels.phone.jswitch.trunks.trunk- Stella.callernmber.default=(.+)

channels.phone.jswitch.trunks.trunk- Stella.callernumber.pattern=(.+) channels.phone.jswitch.trunks.trunk- Stella.callernumber.result=95$1 channels.phone.jswitch.trunks.trunk- Stella.sessionprogress.ignorino=yes channels.phone.jswitch.trunks.trunk- Stella.response4xx.action=LOCAL_BUSY

Questo trunk è esattamente uguale al trunk-Micro (valgono quindi tutte le considerazioni fatte per quel trunk), a meno del prefisso che viene inserito nel campo from che in questo caso è il 95.

Riassumendo rapidamente è possibile vedere da questo trunk-Stella che il Dexgate con prefisso 95 è in ascolto verso Asterisk sulla porta 4006; inoltre ha il Limbo abilitato con una durata di un secondo per consentire i trasferimenti di chiamata; infine, ancora una volta, è il server Dexgate che antepone il proprio prefisso al campo from dei pacchetti da inoltrare verso Asterisk.

Quando viene creato un trunk è necessario definire anche una regola URI che consenta al centralino di inoltrare la chiamata su tale trunk.

ü Priorità=1000 ;

ü Match in avanti=virtual:///99(.*) ;

ü Trasformazione in avanti=sip://trunk-Stella/$1@192.168.70.75; ü Match all’indietro=sip://trunk-Stella/(.*)@(.*);

ü Trasformazione all’indietro=virtual:///99$1

Da questa regola si può vedere che le chiamate destinate ad un numero che inizia con le cifre 99 vengono inoltrate su trunk-Stella con il campo to privo di tale prefisso. Dal match all’indietro e dalla trasformazione all’indietro si osserva invece che il numero del chiamante che viene visualizzato sul display, per una chiamata proveniente da questo trunk-Stella, sarà costituito da 99 + ciò che è presente nel campo from del pacchetto di invite arrivato.

ASTERISK:

per fare in modo che il centralino Asterisk svolga le funzione di centro stella è necessario configurare i file sip.conf ed extensions.conf.

Nel file sip.conf è sufficiente definire in quale contesto debbano essere inviate le chiamate provenienti da utenti non appartenenti ad Asterisk (in questo caso tutte le chiamate visto che è stato supposto che non ci sia nessun utente registrato su Asterisk). Per implementare ciò si dovrà modificare il sip.conf nel seguente modo:

[general] context=stella

nel caso in cui nascesse l’esigenza di avere degli utenti anche su Asterisk, dovranno essere definiti in questo file sip.conf e fatti appartenere al contesto stella.

Nel file extensions.conf deve essere configurato il dialplan che consenta ad Asterisk di inoltrare le chiamate verso l’opportuno Dexgate di destinazione. Questo file , nel caso in cui si avesse soltanto i server periferici identificati dai prefissi 91, 92, 93, … , 9i e con indirizzi IP pari a 192.168.70.91, 192.168.70.92, 192.168.70.93, 192.168.70.9i, e nessun utente su Asterisk, si presenterebbe così: [stella] exten=>_91.,1,Dial(SIP/${EXTEN:2}@192.168.70.91:4006) exten=>_92.,1,Dial(SIP/${EXTEN:2}@192.168.70.92:4006) exten=>_93.,1,Dial(SIP/${EXTEN:2}@192.168.70.93:4006) ………… ………… exten=>_9i.,1,Dial(SIP/${EXTEN:2}@192.168.70.9i:4006)

In questo file è stato definito un contesto stella e le regole di matching con i vari prefissi dei server Dexgate periferici. In questo caso si è supposto che per tutti i Dexgate il trunk-stella sia stato configurato in modo da essere in ascolto sulla porta 4006. Questa non rappresenta una scelta obbligatoria; è importante però che esso sia in ascolto su una porta non occupata da altri trunk o da altre applicazioni.

È importante sottolineare che la nascita di una nuova sede periferica, supponiamo caratterizzata da prefisso 9i+1 e indirizzo IP 192.168.70.9i+1, comporta la sola aggiunta della seguente stringa nel file extensions.conf:

exten=>_9i+1.,1,Dial(SIP/${EXTEN:2}@192.168.70.9i+1:4006)

La seconda soluzione illustrata, a differenza della prima, evita di intervenire su tutti i server periferici al momento in cui viene creata una nuova sede.

Di seguito è illustrato come vengono gestiti i prefissi dai vari centralini: il test che è stato effettuato è una chiamata dall’utente 100 appartenente al Dexgate con prefisso identificativo pari a 95 verso il 200 il quale è registrato sul Dexgate con prefisso 93.

L’invite della chiamata partirà dal terminale 100 verso il Dexgate 95 con:

Ø Campo from=100 Ø Campo to=9993200

Una volta che l’invite arriva al Dexgate 95, verrà spedito sul trunk -stella e quindi verso Asterisk con i seguenti campi:

Ø from=95100 Ø to=93200

Dexgate si preoccupa di toglire il 99 dal campo to e di inserire il prefisso 95 nel campo from.

Una volta che l’invite della chiamata arriva ad Asterisk, esso lo inoltrerà verso il Dexgate 93 con i seguenti campi:

Ø from=95100 Ø to=200

Asterisk modifica soltanto il campo from. Ora la chiamata giungerà al centralino Dexgate 93, il quale la inoltrerà verso il terminale da contattare. L’invite sarà indirizzato verso l’interno 200, che quindi squillerà, con i seguenti campi:

Ø from=9995100 Ø to=200

in questo modo il terminale 200 visualizzerà, come numero chiamato, proprio quello che era stato richiesto, cioè 99 95 100,i quali numeri indicano prefisso Asterisk + prefisso Dexgate chiamante + interno chiamante.