LEXO | We don't learn for the school, we learn for life.

There’s just a “issue” for better configuration of Asterisk PBX/DAHDI with OpenVox A400P card under Slackware GNU/Linux 13.1 and here we’re going to see how to fix it.

Lets go… Obviously, we need to install first (this isn’t a topic of installation):
DAHDI
Asterisk

For setup the card OpenVox A400P we need to disable these modules (we need use wctdm module of DAHDI):

hisax
netjet

So well, we just add these next lines into /etc/modprobe.d/blacklist.conf and next boot there won’t be more conflicts between these modules.

blacklist netjet
blacklist hisax

And that’s all, now we can configure/start the Asterisk IP PBX.

Druid is an open source unified communications platform, built around technology such as Asterisk, IMAP, XMPP. Druid gives your organization access to the best available IP communications platform that bringing together voicemail, VOIP, mobile phone, faxes and instant messaging.

Source:
http://www.voiceroute.org

About Opal

Opal is a full-featured library that supports a variety of protocols and multi-media fornats. Features include:

* Low latency RTP stack designed specifically for real-time multimedia
* Full featured H.323, SIP and IAX2 protocol stacks
* Audio codecs including G.711, GSM06.10, Speex and iLBC.
* Video codecs including H.261 and H.263
* Run-time loadable codec interface for proprietary or codecs such as G.729, H.263, H.264 and MPEG4
* Completely Open Source using the commercially friendly MPL 1.1 license

Through the use of a platform isolation library called PTLIB, Opal can run on tiny embedded systems or multi-processor servers.

Source:
http://www.opalvoip.org/

I was searching something about integration of Arduino with Asterisk PBX and I found this interesting article:

Using Asterisk to Control your Arduino

This article is how to control Arduino over Ethernet using Asterisk PBX, making a call and controlling over it comm channel.

So then, you can make a IVR and control your Arduino calling it wherever you are.

Source:
http://www.nerdybynature.com/index.php/2009/03/using-asterisk-to-controll-your-arduino

Today I was installing DAHDI Linux 2.1.0.4 with OSLEC support and this is my little experience with it…

I needed modify drivers/dahdi/Kbuild

# Only enable this if you think you know what you’re doing. This is not
# supported yet:
obj-m += dahdi_echocan_oslec.o
#
# A quick and dirty way to build OSLEC, if you happened to place it
# yourself in the dahdi source tree. This is experimental. See README
# regarding OSLEC.
#obj-m += ../staging/echo/
obj-m += ../staging/echo/echo.o

After I did it, I needed copy echo directory from the kernel linux-2.6.28.7 sources indahdi-linux-2.1.0.3/drivers/staging

cd dahdi-linux-2.1.0.3/
mkdir drivers/staging
cp -r /usr/src/linux-2.6.28.7/drivers/staging/echo drivers/staging

So… I installed the package and enabled the card with OSLEC echo canceller.

Hace apenas unos días he recibido un correo por parte de un proveedor de servicio de telefonía ip (V2 de MCM – Megacable Comunicaciones de México), que por 1 peso mas iva te ofrecía la posibilidad de elegir entre un numero telefónico del df, gdl, o mty. Ahora llega a su muerte para el 31 de Diciembre del 2008.

En lo personal puedo decir que ya veía venir su muerte, pues desde un inicio el soporte no fue bueno, y unos meses mas tarde se torno pésimo. Pues era imposible conseguir soporte.

Ahora si que todo aquello parecía y parece, un lugar muerto. Y no se como es que duro de pie tanto tiempo, ya que nunca vi invirtieran en estrategias comerciales, y aun peor, sus tarifas no fueron nunca competitivas, y una de las estrategias que los condeno desde sus inicios fue, que nos querían hacer dependientes de un software para hacer uso del servicio(aunque existían formas de evitarlo).

Lastima, por 3 pesos tenia presencia telefónica local en 3 estados de la república.

-

http://v2.com.mx/

http://www.mcmtelecom.com.mx

Hace tiempo realizaba la comunicación entre ATAs Sipura SPA, ahora Linksys SPA, haciendo uso del speed dial con el que vienen integrados. Ahora dejo en este post otra forma de manejar la la conf. punto a punto entre equipos Sipura/Linksys.

jcgalvezv:

Algunas veces necesitamos configurar nuestros ATA para poder realizar llamadas directas sin necesidad de un servidor (proxy) SIP.

Quiero sugerirles una configuración con llamadas basadas en direcciones IP que se ha vericado que funciona.

La configuración sería la siguiente asumiendo estas premisas: Tenemos 2 dispositivos A y B (PAP2 o SPAxxxx) , el dispositivo A tiene la dirección IP 192.168.1.50 y el dispositivo B tiene la dirección IP 192.168.1.51.

Configuramos estos parámetros en los dispositivos A y B:

- En la pestaña Line 1, sección SIP Settings ajuste el campo SIP port: 5060.

- En la pestaña Line 2, sección SIP Settings ajuste el campo SIP port: 5061.

– En las pestañas Line 1 y Line 2, sección Proxy and Registration
ajuste todos los campos en blanco o en NO excepto Make Call Without Reg: YES y Ans Call Without Reg: YES.

– En las pestañas Line 1 y Line 2, sección Subscriber Information ajuste el campo Display Name: <lo que quiere que aparezca como identificador de llamada>, User ID: en blanco y deje los demás campos vacíos.

– En las pestañas Line 1 y Line 2, ajuste Dial Plan:
(<21:>S0<:@192.168.1.51:5060>|<22:>S0<:@192.168.1.51:5061>|
<11:>S0<:@192.168.1.50:5060>|<12:>S0<:@192.168.1.50:5061>) y Enable IP Dialing: YES

Ahora, como trabaja?:

- Para llamar a la línea 1 del dispositivo A marque 11.
- Para llamar a la línea 2 del dispositivo A marque 12.
- Para llamar a la línea 1 del dispositivo B marque 21.
- Para llamar a la línea 2 del dispositivo B marque 22.

Se podrían adicionar más dispositivos. Lo único que se necesita es
adicionarlos en los planes de marcado. Suponiendo que se tuviera un tercer dispositivo C con dirección IP 192.168.1.52, entonces el plan de marcado cambiaría a:

(<31:>S0<:@192.168.1.52:5060>|<32:>S0<:@192.168.1.52:5061>|
<21:>S0<:@192.168.1.51:5060>|<22:>S0<:@192.168.1.51:5061>|
<11:>S0<:@192.168.1.50:5060>|<12:>S0<:@192.168.1.50:5061>)

- Para llamar a la línea 1 del dispositivo C marque 31.
- Para llamar a la línea 2 del dispositivo C marque 32.

Fuente: recursosvoip

Los últimos días he estado realizando algunas pruebas de integración de este equipo (Axesstel AXW-T800) con Asterisk IP-PBX. Hasta hoy he tenido problemas con la detección del colgado. Cuando el usuario destino cuelga la llamada y el “llamante” queda a la espera(sin colgar), obtiene tono para una nueva llamada. Haciendo imposible una tarificación correcta de la llamada en estos casos.

Características del equipo:
Tecnología CDMA
2 puertos RJ-11 (FAX/TEL)
Opciones para FAX
Capacidad para conectar a la Internet (CDMA 1xTTR).

Dentro de las pruebas que he realizado, he conectado directo al telular un teléfono “analógico”; para determinar si aun así continua regenerándose el tono que permite realizar una nueva llamada. Y en efecto me ha dado el mismo resultado.

He mirado el manual, y no he encontrado alguna función que me corte por completo el canal; cuando el otro extremo cuelga. Así que aparentemente como conclusión este equipo no tendría un buen funcionamiento con Asterisk IP-PBX.

Nota: Las pruebas se han realizado con ayuda de una clona FXO.

No soy muy adepto a este tipo de sistemas integrados con sus webmin y mas monadas para su administración; aunque confieso que en algún momento he llegad a instalar un Tixbox para un cliente. El caso es que apenas hoy me entero de la existencia de este proyecto llamado “PBX in a Flash”, mantenido principalmente por Ward Mundy; que fuera uno de los principales desarrolladores del proyecto Trixbox.

Web Site

A expensas de que existen otros métodos, ahora explicare un método que he utilizado para mis usuarios que estas acostumbrados a aquellos antiguos métodos donde antes de teclear alguna extensión esperan escuchar el tono que les indica que tienen linea(pudiendo ser una agradable grabación que les pida la extensión jeje).

Se me ha ocurrido hacer esto con la ayuda del comando DISA(), teniendo en cuenta que no es uno de los mejores métodos pero hasta hoy me funciona .

Ejemplo:

[contexto-0]
exten => _X.,1,Playback(marcando)

[example]
exten => 0,1,DISA(no-password|contexto)
exten => 0,n,Hangup

Aquellos usuarios que pertenezcan al contexto example, al marcar 0 escucharan su clásico tono que les hace entender que tienen tono para marcar, dándoles acceso al contexto-0 donde buscara la extensión que marque el usuario. Así no extrañaran el clásico tono que les hace entender que pueden marcar el numero deseado.

Podemos ayudarnos de Set(TIMEOUT(digit)=10) y Set(TIMEOUT(response)=10)para darle mas tiempo al usuario para teclear el numero.

Para aquellos que por alguna razón ocupen generar determinado tono en su dialplan tenemos el siguiente comando que nos hace el trabajo:

Playtones(tono) Donde tono lo sustituimos por alguno de nuestra lista de indications.conf ya sea por el nombre del tono o especificando la frecuencia del tono que querríamos.

Ejemplo:

[example]
exten => 123,1,Playtones(dial)
exten => 123,n,Wait(5)

Es así como podemos conseguir que la extensión 123 nos genere el tono dial durante 5 segundos.

SIPsak

SIPsak es una aplicación que nos ayuda a testear nuestras aplicaciones y dispositivos SIP.

Dentro de sus características podemos encontrar:

Envió de peticiones OPTIONS.
Envió de archivos de texto (que contengan peticiones SIP).
Traceroute (sección 11 en el RFC3261).
Test de localización de usuarios.
Teste de flooding(inundación).
Simulación de llamadas en modo usrloc.
Soporte para transporte UDP o TCP.

check_zaptel nagios plugin

Es un plugin de nagios monitor que nos permite checar el estado de nuestros dispositivos zaptel. Como indica en su pagina el plugin hace uso del famoso /proc/zaptel encargado de darnos información de nuestros dispositivos zaptel.

Para aquellos que quieran hacer uso de este plugin aqui les dejo el link del plugin.
http://www.uptime.it/mywiki/CheckZaptel

Aquí tenemos una aplicación que nos ayudara a determinar si nuestro firewall esta haciendo el port forward que requerimos para nuestras llamadas de voip.

Se trata de una aplicación que envia un mensaje UDP PING para identificar que el port forward y no este bloqueado por el firewall.

http://www.voipuser.org/port_forward_tester.html

Normalmente cuando manejamos NAT presente en Asterisk es muy necesario hacer uso de la opción qualify en nuestro sip.conf para nuestros peers que se encuentren en situaciones de NAT, osea detrás de un NAT pues.

¿Y porque es útil?
Al hacer uso de qualify Asterisk enviara periódicamente un comando de SIP OPTIONS(rápidamente digamos que es un tipo de ping) para determinar si el usuario continua online. En caso de no responder dentro del tiempo determinado(sea el default o definido por uno mismo) Asterisk pondrá al usuario ofline para llamadas futuras. Así de esta forma hacemos que Asterisk mantenga abierta la sesión UDP de un usuario(peer) que se encuentra detras de un NAT, de tal manera que es usada en conjunto con la opción nat=yes.

Sintaxis de qualify:
qualify=xxx|no|yes

Esta opción por defecto se encuentra es qualify=no, pero podemos definir en yes donde el timeout manejado es de 2 segundos, o en el ultimo de los casos definir nosotros el timeout en segundos.

Saludos.