Esempio di integrazione con XML definitions: un service flag con Asterisk

Transcript

1 Esempio di integrazione con XML definitions: un service flag con Asterisk Questo articolo è un primo pezzo introduttivo su di una feature molto potente: le XML definitions, vedremo come creare un service flag con notifica in stile BLF ma completamente personalizzato. I BLF (Busy Lamp Field) sono spesso sotto-utilizzati: vengono generalmente impiegati per monitorare altri interni, come speed dial, o al più per effettuare il pickup di una chiamata, in questo articolo vedremo come possiamo utilizzare il meccanismo alla base dei BLF per scopi diversi. Il sistema su cui si basa il funzionamento dei BLF è definito dall RFC 4235, questa specifica descrive un meccanismo di notifiche legate a sessioni SIP iniziate con una richiesta INVITE. I telefoni implementano i BLF associando i vari stati al comportamento del led luminoso corrispondente: in genere un led lampeggiante significa che l interno sta squillando, acceso fisso significa che l interno è occupato. Ora, un BLF può anche essere utilizzato per monitorare qualcosa di più generico, come ad esempio un service flag detto anche servizio notte. Un servizio notte è un servizio che modifica delle regole di call routing su base oraria oppure può essere attivato o disattivato manualmente, per fare un esempio pratico le chiamate dirette al numero principale devono dovranno essere destinate ad un interno nel caso in cui il servizio notte è disattivo, mentre saranno inviate ad una casella di posta se il servizio è attivo.

2 Esempio con Asterisk Il seguente stralcio di dialplan implementa il feature code *500 il quale fa in modo di abilitare o disabilitare un servizio notte chiamato main_flag : ;Feature code: *500 exten => *500,1,Answer() ; check the main_flag/enable DB value: same => n,gotoif($["${db(main_flag/enabled)}" = "1"]?disable:enable) ; ; the flag is disabled: enable it same => n(enable),verbose(enabling the flag main_flag) same => n,set(db(main_flag/enabled)=1) ; set the hint to BUSY state same => n,set(device_state(custom:main_flag)=busy) same => n,playback(enabled) same => n,hangup() ; ; the flag is enabled, disable it same => n(disable),verbose(disabling the flag main_flag) same => n,set(db(main_flag/enabled)=0) ; set the hint to NOT_INUSE same => n,set(device_state(custom:main_flag)=not_inuse) same => n,playback(disabled) same => n,hangup() ; Main receptionist routing exten => 500,1,Verbose(Inbound call to main number - checking if night mode or normal) same => n,set(nightmode=${db(main_flag/enabled)}) same => n,gotoif($["${nightmode}" = "1"]?nightmode) same => n,verbose(main_flag is enabled) same => n,dial(sip/150) same => n(nightmode),verbose(main_flag is disabled) same => n,voic (150,su) same => n,hangup() include => hints [hints] ; BLF for main_flag exten => *500,hint,Custom:main_flag

3 Descrizione dettagliata Il PBX quando riceve una chiamata destinata all interno *500 per prima cosa verifica il valore della chiave di database main_flag/enabled: se il valore è 1 (il servizio notte è abilitato) viene eseguito il dialplan alla priority n(disable), altrimenti il flusso continua da n(enable). Nel caso in cui il servizio notte è disabilitato il servizio viene abilitato impostando la chiave main_flag/enabled a 1, viene invece impostata a 0 nel caso in cui il servizio risulta abilitato. Inoltre viene sincronizzato un custom device state di nome main_flag: viene impostato a BUSY se il servizio notte è attivo e NOT_INUSE se il servizio è disattivo. Il dialplan che gestisce l extension 500 fa in modo di ruotare la chiamata al peer SIP/150 se il servizio notte è disabilitato oppure ad una voic se il servizio è abilitato. Il context hints invece gestisce le subscriptions per il feature code. Funzionamento Una volta caricato il dialplan possiamo testarne il funzionamento: chiamando l interno *500 potremo abilitare o disabilitare il servizio notte. Chiamando invece l interno 500 la telefonata verrà gestita a seconda dello stato del servizio: se attivo verremo rediretti alla Voic , altrimenti l interno 150 verrà fatto squillare. NB: i file audio enabled e disabled dovranno essere caricati nel sistema altrimenti non sarà possibile udire il messaggio di conferma Monitoraggio tramite BLF In queste applicazioni risulta fondamentale avere uno stato visualizzabile del servizio: i BLF in questa situazione fanno al caso nostro: Configuriamo sul telefono un tasto funzione BLF con number *500: BLF feature key

4 Configurato questo il telefono invierà una SUBSCRIBE per il SIP URI se non ci sono problemi la SUBSRCIBE verrà accettata con un 200 OK e verrà notificato lo stato dello user agent monitorato: Qui di seguito la SIP trace dopo aver configurato il BLF: BLF SIP trace

5 E possibile anche visualizzare lo stato della subscription tramite il menu Subscriptions: Outgoing Subscriptions Configurato il BLF il telefono accenderà o spegnerà il LED del tasto funzione a seconda dello stato del servizio notte: acceso se il servizio è attivo, spento se il servizio è disattivo, premendo il tasto sarà possibile cambiare lo stato del servizio. Di seguito come appare lo schermo di uno snom821 con il tasto 1 configurato come BLF per il servizio notte: Servizio disattivo (il tasto è spento): Servizio attivo (il tasto è acceso di rosso fisso): Un BLF personalizzato Questo tasto si comporta a tutti gli effetti come un normale BLF, ora vorremmo però avere un comportamento più specifico per questo BLF particolare, ad esempio vorremmo che il tasto fosse verde se il servizio notte è disattivato e che l info di stato nel line info layer non fosse talking o idle ma notte e giorno. Per implementare questo comportamento personalizzato non basta un semplice BLF ma occorrono delle regole sul telefono in grado di creare degli stati personalizzati (nel nostro caso notte e giorno) a cui associare dei led behaviors. Queste regole possono essere definite tramite XML Definitions, queste regole possono creare delle subscriptions di vario tipo, parsare il contenuto delle NOTIFY e definire degli stati in base al contenuto e delle azioni.

6 L XML definition Area Culturale Per prima cosa occorre preparare in un file di testo l XML definition da applicare al tasto funzione, questa definition farà in modo di: 1. effettuare una subscription di tipo dialog-info per il feature code (*500) 2. definire lo stato notte quando la NOTIFY definisce uno stato confirmed (corrispondente all Asterisk device state BUSY) 3. definire lo stato giorno in tutti gli altri casi 4. alla pressione del tasto il telefono deve chiamare il SIP URI associato al feature code Qui di seguito l XML definition, nei commenti la spiegazione dei vari tag (eventualmente le variabili service_code e domain vanno modificate) <!-- XML definition start: the name and the identity is defined here: --> <general type="servizio Notte" identity="1"/> <initialization> <!-- define the initial status --> <state value="initial"/> <!-- The service code --> <variable name="service_code" value="*500"/> <!-- The domain --> <variable name="domain" value=" "/> <variable name="subscr_uri" value="sip:$(service_code)@$(domain)"/> </initialization> <!-- create the dialog type subscription --> <subscription type="dialog" to="<$(subscr_uri)>" for="$(subscr_uri)"/> <!-- first parsing rules: apply this definition --> <!-- to the well related NOTIFY --> <NotifyParsingRules type="applies"> <level1 translates_to='ok'>/dialog-info[@entity="$(subscr_uri)"]</level1> </NotifyParsingRules> <NotifyParsingRules type="state"> <!-- define the state "notte" if dialog state is confirmed --> <level1 translates_to="notte">/dialog-info/dialog/state[.="confirmed"]</level1> <!-- go to "giorno" state in all others states --> <level2 translates_to="giorno"/> </NotifyParsingRules> <action> <!-- dial the URI when pressed --> <dial target="$(subscr_uri)" when="on press"/> </action> L XML definition può essere applicata tramite provisioning oppure via interfaccia web,:

7 Via interfaccia web occorre selezionare XML definition come tipo tasto e incollare l XML nel campo number: XML definition via WUI Via provisioning occorre invece definire il tasto nella seguente sintassi: <functionkeys e="2"> <fkey idx="0" context="1" label="segreteria" perm=""> <general type="servizio Notte" identity="1"/> <initialization> <variable name='service_code' value='*500'/> <variable name='domain' value=' '/> <variable name='service_name' value='servizio Notte'/> <variable name='subscr_uri' value='sip:$(service_code)@$(domain)'/> <state value="initial"/> </initialization> <subscription type="dialog" to="<$(subscr_uri)>" for="$(subscr_uri)"/> <NotifyParsingRules type="applies"> <level1 translates_to="ok">/dialog-info[@entity="$(subscr_uri)"]</level1> </NotifyParsingRules> <NotifyParsingRules type="state"> <level1 translates_to="notte">/dialog-info/dialog/state[.="confirmed"]</level1> <level2 translates_to="giorno"/> </NotifyParsingRules> <action> <dial target="$(subscr_uri)" when="on press"/> </action> </fkey> </functionkeys>

8 Definizione del LED behavior Ora occorre fare in modo che il tasto sia verde nello stato giorno e rosso nello stato notte, per fare questo abbiamo a disposizioni i settings che definiscono il led behavior e nello specifico ci interessano i prametri: led_on, led_green e led_red. Aggiungendo gli stati giorno e notte attiveremo i led con i colori voluti nei relativi stati: led_on=giorno notte ON BUSY IN_A_CALL CALLING IN_A_MEETING URGENT_INTERRUPTIONS_ONLY HOLDING DND ACTIVE INACTIVE BE_RIGHT_BACK AWAY UNAVAILABLE AVAILABLE PhoneHasCall CurrentIdentityHasVoiceMessages PhoneHasVoiceMessages led_green=giorno AVAILABLE Wrap-Up led_red=notte BUSY IN_A_CALL CALLING IN_A_MEETING URGENT_INTERRUPTIONS_ONLY HOLDING DND PS: i parametri led_on, led_green, led_red non sono gestibili tramite interfaccia web, vanno quindi configurati tramite provisioning oppure tramite richiesta HTTP a notte ON BUSY.. Ora il tasto associato al servizio notte è completamente integrato con il servizio: Quando il servizio notte non è attivo (il LED è verde): Quando il servizio notte è attivo (il LED è rosso): Chiaramente questa feature può essere impiegata per qualsiasi tipo di notifica (ricezione , consegna merci, ecc..). Grazie alla potenza delle XML definitions i snom possono implementare features molto specifiche e totalmente personalizzate utilizzando dei protocolli standard, garantendo così la totale interoperabilità e compatibilità.