Archivi tag: telefono

Raggiungibile con tono libero: verifica automatica di un’utenza mobile

Analizzando uno scenario applicativo reale, è possibile incontrare tra le specifiche una esigenza di dover automaticamente telefonare ad un numero ed assicurarsi che risponda con tono libero, in dettaglio riconducibile al seguente estratto:

Dato un numero di utenza telefonica mobile, corrispondente alla SIM utilizzata all’interno di un terminale per telecontrollo, è possibile contattare lo stesso numero con una chiamata voce per verificare la disponibilità della rete mobile sul terminale remoto.

In caso positivo, lo stesso terminale attenderà il tempo equivalente ad uno squillo per poi rifiutare la chiamata, l’equivalente di una linea occupata.

Determinare se il terminale corrispondente al numero ha copertura GSM sufficiente per la gestione in entrata ed uscita di chiamate vocali e SMS.

L’utilizzo di ecosistemi tecnologici M2M più evoluti consentirebbe controlli più efficaci ed immediati, ma l’indicazione in questo caso è quella di rendere operativo un sistema automatico nel breve termine evitando gli interventi di recupero, aggiornamento e reinstallazione del parco terminali già in esercizio, molti dei quali collegati a macchine operatrici a lavoro in cantieri lontani dalla sede aziendale o comunque difficili da poter raggiungere.

Applicazione: controllo del tono libero su terminali installati in cantiere

Condizioni per il tono libero

Il modello del terminale, utilizza una sezione di radiocomunicazione GSM compatibile con rete e SIM ordinarie degli operatori italiani (TIM, Vodafone, Wind) che è possibile interrogare via SMS per ricevere indicazioni sullo stato di ingressi, uscite ed altri dati. L’installazione tipica è eseguita a bordo di macchine da cantiere, a volte la posizione delle stesse a malapena consente una copertura del segnale radiomobile (es. pala meccanica al lavoro in galleria); quindi è indispensabile che un’interrogazione dalla sede sia subordinata alla bontà del segnale di rete agganciato dal terminale, per poter garantire una risposta.

La condizione ideale è che a chiamata vocale diretta, il numero risulti agganciato alla rete (ovvero raggiungibile); il terminale si preoccuperà di attendere poco tempo e rifiutare la chiamata. Quindi al chiamante la centrale telefonica segnalerà almeno un tono libero.

Tutte le altre condizioni differenti sono da considerarsi come eventi che escludono il terminale come al momento raggiungibile.

Tutto questo deve rispondere a logiche programmabili, automatiche o sovrintese da personale aziendale.

FreeSWITCH e tone_detect

Dopo aver percorso alcune opzioni, incluse quelle dei test per il tono libero con modem voce PSTN, ho scelto l’uso di FreeSWITCH poiché consente un apprendimento relativamente rapido, un buon sviluppo di applicazioni personalizzate, non richiede hardware specifico e nonostante la documentazione non sia sempre chiara gli sforzi della comunità alla base della piattaforma sono enormi. Inoltre, con l’integrazione FreeSWITCH si apre il sistema verso scenari applicativi inediti.

Per poter effettuare delle chiamate in uscita, testando alcuni fornitori VoIP, ho integrato i servizi di Messagenet che è risultato quello meglio corrispondente alle aspettative.

Il componente su cui verge l’oggetto dell’articolo è tone_detect al quale passare la frequenza di riferimento del tono libero a 425 Hz ed altri parametri minori. La ricetta è contenuta come configurazione di una extension nel dialplan (prefisso 9900), che vado a richiamare in modo asincrono dal sistema con la riga

fs_cli -x "originate loopback/9900333123456 &echo()"

Proprio all’interno della extension, inserisco delle callback (come ulteriori extension) secondo le quali gestire i diversi casi; segue un estratto della configurazione:

<extension name="ctl_verifica">
 <condition field="destination_number" expression="^9900(\d+)$">
 <action application="set" data="continue_on_fail=true"/>
 <action application="set" data="hangup_after_bridge=true"/>
 <action application="set" data="ctl_chiamato=$1"/>
 <action application="set" data="tone_detect_hits=1"/>
 <action application="set" data="execute_on_tone_detect_1=log 1 *** ONTONEDETECT ***"/>
 <action application="set" data="execute_on_tone_detect_2=transfer ctl_tonolibero"/>
 <action application="set" data="execute_on_media_1=log 1 *** ONMEDIA ***" />
 <action application="set" data="execute_on_media_2=tone_detect tono1 425 w 0"/>
 <action application="set" data="execute_on_media_3=sched_hangup +30 alloted_timeout bleg"/>
 <action application="set" data="execute_on_answer_1=log 1 *** ONANSWER ***" />
 <action application="set" data="execute_on_answer_2=transfer ctl_risponde" />
 <action application="set" data="execute_on_ring_1=log 1 *** ONRING ***" />
 <action application="bridge" data="sofia/gateway/gw_messagenet/$1"/>
 <action application="transfer" data="ctl_inesitato" />
 <action application="log" data="1 B-leg hangup cause: ${bridge_hangup_cause}"/>
 <!--<action application="javascript" data="/opt/freeswitch/report2.js $1 ${bridge_hangup_cause}"/>-->
 </condition>
</extension>

Con la configurazione in uso, viene inoltre superato l’ostacolo della eventuale segreteria dell’operatore telefonico, contenendo le singole extension derivate il comando di hangup prima della chiusura.

Pertanto l’inconveniente relativo ad una singola chiamata è un consumo di 1 secondo nei rari casi che FreeSWITCH non riesca a terminare la chiamata, nell’istante immediatamente successivo all’avviso che introduce il servizio di voicemail dell’operatore di rete. Per evitare questo inconveniente, basta semplicemente che il servizio sia disattivo per ogni SIM della flotta.