DailyAsterisk

Stavo cercando informazioni per sapere di cosa hanno parlato AstriDevCon quando finalmente ho trovato una lista di todo per la prossima 1.6 di cui discuteranno.

Per quanto riguarda il fronte IAX2 gli argomenti sembrano essere stati supporto ipv6, review dell’RFC.

I topic piu generici comprendevano inoltre Multimedia inteso come Video/IM/Presence, Codecs e Wideband, Secutiry, TLS e SRTP.

Ed ancora internazionalizzazioni, supporto UTF 8 sia per le estensioni che per i caller id.

Ma soprattutto Clustering (redundancy e failover), un sistema di bridging tra più Asterisk ed una riscrittura completa del supporto per il realtime.

Come gia annunciato poco tempo fa da Olle in -dev vi sara’ puoi un milgioramento delle AMI con nuove eventi ed informazioni piu dettagliate, oltre che un supporto migliore per controllarne gli acessi.

Relativamente al core di Asterisk troviamo novita per quanto riguarda le API, una nuova gestione dei thread e della memoria (da test eseguiti sino ad ora pare vi sia un mglioramento piu che sensibile sul numero di chiamate concorrenti che si riescono a gestire a pari hardware).

Sembra poi si volglia riscrivere in toto app_voicemail, “modularizzandolo”, e che i messaggi possano essere salvati su file system piuttosto che su mysql o odbc per il quale saranno presenti nuove API.

Chissa’ poi cos’altro bolle in pentola, gia questo non e’ poco

Piccola intro su PickUp, tale applicazione permette ad un interno di rispondere al telefono di un altro interno il cui telefono sta squillando, senza doversi alzare dalla sedia per intendersi

Tipicamente la persona che desidera rispondere al telefono digita un codice piu il numero dell’interno per cui vuole rispondere, ad esmepio:

*8 + 200


Se usate Asterisk1.2 e utilizzate l’applicazione fornita di default app_pickup, non potete non usare app_pickup2, quest’ultima come la pickup di Asterisk 1.4 permette di specificare piu channel/exten ma aggiunge anche delle decisamente piu utili.

Perche e’ utile specificare piu channel, semplice perche se i nostri interni ad esempio sono sia in IAX2 che SIP e non sappiamo quale sta squillando, non possiamo scrivere qualcosa tipo.


exten => _*8., 1, PickUp(SIP/${EXTEN:2)
exten => _*8., n, PickUp(IAX2/${EXTEN:2)


perchè l’applicazione PickUp se fallisce fa un Hangup, non va percio’ ad eseguire la priorità successiva.

Ecco che con PickUp2 possiamo scrivere:


exten => _*8., 1, PickUp(SIP/${EXTEN:2&IAX2/${EXTEN:2)


Ma questo e’ nulla ancora…

Il problema vero di PickUp e’ che se come accade nel 99% delle volte abbiamo un estensione, tipicamente il nostro numero d’ufficio che fa squillare piu interni, questa applicazione diventa assolutamente inutile, perche in una simile situazione il parametro di pickup non deve piu essere l’estensione dell’interno, ma bensi l’estensione che ha generato la dial.

Questo rende tremendamente inusabile l’applicazione, in quanto una persona sente il telefono vicino a lui suonare, ma non sa se e’ una chiamata che arriva da una dial multipla o una telefonata diretta da un’altro interno, dovrebbe percio’ andare a tentativi.

Ecco che PickUp2 ci viene in aiuto, noi gli diciamo che desideriamo rispondere per conto dell’estensione X e lei si occupa di tutto il resto.

Altre applicazioni aggiunte dalla app_pickup2 sono:

• PickDown2
• Steal2

Inoltre l’ultimo update e’ anche piuttosto recente: 2007-01-06

Stavo leggendo gli ultimi ticket presenti nel sistema di tracking di asterisk, trovando qualcosa di interessante e qualcosa meno, quanto sono incappato in questa applicazione scritta da un volenteroso per Asterisk 1.4 0007373: [patch][post-1.4] app_redirect

Ma cerchiamo di capire un po’ melgio, l’applicazione scritta andava a sostituire una fornita da asterisk (quindi forse non e’ il caso piu eclatante) e citandolo :

Similar to app_channelredirect but:

* allows you to specify a device to redirect rather than an exact channel
* allows you to specify two Technology/resources (bridged) and redirect them to two seperate priorities. (essentially unbridging them)

Usage:

redirect(Technology/resource1|Technology/resource2|Exten|Context|Priority1|Priority2|Options)

Technology/resource1 is redirected to priority1
Technology/resource2 is redirected to priority2
options:
a - redirects all channels on specified device instead of single resource.

ed ancora

However when I try this I encounter a bug, I get a thread locking error. I also tried it with the application already in trunk (app_channelredirect) and have exactly the same error, always reproducable

Forse avrebbe potuto segnalare il solo bug dell’app_channelredirect o forse avrebbe potuto anche patchare l’applicazione originale, ad ogni modo questa una delle risposte da digum

timkelly: thanks for contributing and filing a disclaimer. Please review the CODING GUIDELINES file and fix up the app accordingly. Also, new features like these will go into trunk, not 1.2.x once the 1.4 beta branch is forked from the trunk (in the upcoming weeks). Thanks.

le revisioni poi sono state fatte e altre persone hanno scritto

I would like to see this in trunk

(preciso che chi ha scritto quella frase ha ruolo “manager”)

vi intaressa sapere come e’ finita?

La prima patch e’ stata mandata il 06-15-06 19:02 il fax 06-16-06 07:46, la prima risposta 06-16-06 09:57, e poi … 03-20-07 14:39 where do we stand with this issue? …
(in risposta) 05-28-07 03:35 housekeeping

Risultato, l’app_channelredirect ancora soffre degli stessi problemi, dal 2006 c’e’ un soluzione, ma non viene utilizzata, benché in questo caso _anche_ il fax di disclaimer sia stato inviato, mah.

Devo dire che a volte capisco i fork.

Poco tempo fa alla Fiera del Radioamatore a Pordenone avevo visto dagli amici dell’associazione Free-Milk un’integrazione fra Asterisk e un comunissimo citofono; nel loro sito e’ possibile scaricare un pdf con i dettagli del caso.

In breve non vi sono particolari configurazioni da applicare ad asterisk, l’idea alla base consiste un’interfaccia citofonica collegata ad un ATA sip o iax che si voglia.

Davvero una bella idea

Chi ha avuto la necessita di interconnettersi attraverso carrier h323, avra’ notato che Asterisk dopo la compilazione attraverso il comando make non produce il chan_h323. E’ possibile installare alternativamente le ooh323 presenti negli addon, ma il debug prodotto da quest’ultime e’ decisamente scarso e comunque il chan ha molti meno comandi dell’h323; ad esmepio con le ooh323 per ricaricare la configurazione bisogna dare un reload ad Asterisk visto che non esiste il classico technology reload.

Vediamo cosi come compilare le librerie native.
Read the rest of this entry →

VoIPSpeack ha pubblicato un articolo su come risolvere i comuni problemi di Echo su Zap.
L’articolo e’ abbastanza semplice, ma buono per chi si sta avvicinando ad Asterisk e soffre di questo problema