Sinologic

Etiqueta: tutoriales

  • Cómo organizar y controlar los logs de Asterisk

    logsJon Bonilla ha publicado un estupendo tutorial sobre cómo organizar el log de Asterisk, realmente imprescindible para sistemas de alta carga o que generan muchos mensajes y que necesitamos controlar para saber qué está haciendo Asterisk en ese momento.

    Asterisk incluye un archivo de configuración llamado logger.conf donde podemos decirle qué tipo de mensajes queremos que almacene y dónde, pero esta herramienta se nos puede quedar pequeña en ciertos momentos, así que este tutorial es realmente interesante en esos casos.

    Podeis ver el tutorial aquí:
    http://blog.voz-ip.com/2009/log-en-asterisk/

  • Resumen del día de la Comunidad del VoIP2DAY

    Ayer por la tarde terminó la segunda edición del VoIP2DAY con un completo éxito, si bien es cierto que la crisis hizo que el SIMO no tuviera tanto éxito como años anteriores, el día de ayer confirmó que la VoIP sigue en alza y es que en determinados momentos el salón estaba completamente lleno.

    Me alegró poder ver a la gente que conozco y que nos vemos de año en año gracias a estos eventos. También me encantó haber conocido a muchas personas que no conocía o bien los conocía de oídas.

    Siempre es un placer conocer gente interesada y con la compartir conocimientos y el hecho de poder charlar y compartir experiencias es uno de los mayores alicientes que tiene este tipo de eventos.

    Mi charla iba sobre Comunicaciones Unificadas en Grandes Infraestructuras, y como ya comenté, aquí la pongo para el uso y disfrute de todos aquellos que lo deseen.
    Aunque no pude ver todas las conferencias, pude ir el último día y sí que estuve paseándome e intentando atender tanto como me fuese posible y he de decir que todas estuvieron sencillamente geniales:

    La charla de Alberto Sagredo, que era prácticamente un curso acelerado de Asterisk en 45 minutos con bastantes notas curiosas, las del trío SIPDOC (Saúl, Iñaki y Jon) que juntas eran una auténtica bomba digna de repasar tranquilamente y por separado seguían siendo una fuente vital de información, a la vez que muy divertida y bastante friki (ejem… 42 ;P), las Frikadas de la pareja MiniCong con Asterisk recorriendo el mundo con destino Mongolia, la de Nicolás Gudiño mostrándonos la increible evolución del famoso y conocido Flash Operator Panel y por supuesto la de Jesús Rodriguez que dejó nuevamente asombrado a todos los presentes con sus conocimientos sobre SIP y lo que puede dar de sí un procolo como este. Por último y no por ello menos importante, Kevin P. Flemming y Olle Johansson, como siempre, increibles y demostrando porqué son conocidos en todo el mundo.

    Aunque las conferencias se emitieron en directo vía streaming, también se grabaron a alta calidad para ser publicadas en breve en la web oficial del VoIP2DAY, así que, mientras se preparan las grabaciones, aquí teneis la documentación de mi charla.

  • Por qué decimos GUI cuando queremos decir Front-end

    En ocasiones, dos palabras cuyo significado se parecen, a menudo es utilizado por distintas personas como si fueran sinónimos, lo que puede llevar a dos posibles interpretaciones: Que habla de algo que no es, o que no tiene ni idea. Esto es lo que a veces pienso cuando leo algunas noticias y artículos, publicidad variada y abundante por no tildarla de SPAM-consentido.

    En este artículo voy a referirme principalmente a dos conceptos que se parecen, pero no son lo mismo y la diferencia puede llegar a ser realmente abrumadora e incluso, viéndolo desde un punto de vista objetivo, casi insultante.

    GUI son unas siglas que vienen a significar Graphical User Interface (o en español: Interfaz gráfica para el usuario).
    FRONT-END es un término inglés que viene a señalar un «frontal» para utilizar una aplicación final «fín«.

    Estos dos conceptos son muy parecidos, y de hecho, cualquiera sin experiencia pensaría que es lo mismo (siempre y cuando haya utilizado alguna vez ambos términos) pero nada más lejos de la realidad y para mostrarlo pondré un ejemplo bastante curioso y didáctico para el que no lo conozca:

    Cuando una persona instala Debian por primera vez, una de las primeras cosas que aprende, es que los paquetes donde se encuentran las aplicaciones, utilidades, librerías y todo, viene en archivos con extensión .deb la forma de instalar dichos paquetes (archivos paquetizadores) se hace SIEMPRE mediante una aplicación llamada dpkg. (des-packager) y mediante esta herramienta con una serie de parámetros, descomprimirá el paquete .deb y colocará cada archivo en el directorio donde debe estar.

    Con un simple vistazo a la herramienta dpkg podemos ver estos parámetros (he puesto la letra muy pequeña para que ocupe lo mínimo posible).

    dpkg-help
    Click para ampliar

    Se podría decir que trabajar con esta aplicación puede llegar a ser algo tedioso cuando para instalar un paquete, antes debemos instalar otros, y para instalar estos otros, antes hay que instalar otros… un usuario novato puede llegar a perder la paciencia.

    Para ello, se inventó una aplicación front-end llamada dselect. Esta aplicación tenía como objetivo facilitar el uso de la herramienta dpkg a los usuarios de manera que se simplificara su utilización y no tuvieran que estar peleándose con los distintos parámetros, a la vez que se automatizaba la búsqueda e instalación de dependencias (de manera que solo había que indicar qué paquete querías instalar y él instalaba sólo y automáticamente todos los paquetes que eran necesarios tener instalado previamente). El front-end en el fondo hace uso de la aplicación final: dpkg y sólo utiliza unos pocos parámetros.

    El comando dselect para muchos se convirtió en una bendición, para otros… en un doble suplicio. Como se solía decir, a veces era más difícil aprender a utilizar el front-end que la propia aplicación ‘end’.

    dselect-help
    Click para ampliar

    La herramienta dselect fue rechazada por gran parte de los usuarios de Debian por ser un front-end al que le faltaba una característica esencial: la aplicación Front-end debe ser INTUITIVA (Del lat. mediev. intuitĭo). Así que, como este front-end no terminó de satisfacer a los usuarios de Debian, se creó una herramienta nueva: apt-get que, no únicamente era mucho más sencilla de utilizar, si no que realmente eran tan útil, fácil y rápida de aprender que hoy día es la herramienta por excelencia que todo usuario de Debian conoce a la perfección.

    apt-get-help
    Click para ampliar

    Por ahora tenemos que dpkg es la herramienta principal y apt-get un front-end del dpkg que facilita la instalación de paquetes.
    Como aún así, el apt-get puede llegar a ser difícil de utilizar para alguien nuevo, se crearon otras herramientas: aptitude y una GUI llamada synaptic.
    Si uno se fija en las opciones de synaptic, puede ver que están TODAS y cada una de las opciones de la herramienta apt-get (NO una simplificación de los parámetros del apt-get).

    synaptic
    Click para ampliar

    Bien, después de este rollo, ¿que intento sacar en claro?

    – Una GUI es una transformación de una aplicación a un entorno gráfico.
    – Un Front-End es una simplificación para facilitar el uso de una aplicación. Un requisito de los Front-End es que deben ser INTUITIVOS.

    Ahora una reflexión:

    – Cuando un cliente dice que quiere una GUI, realmente quiere un Front-End?, un Front-End no tiene porqué ser gráfico, simplemente debe ser más sencillo, intuitivo para no tener que esforzarse en aprender todos los parámetros de la aplicación final.
    – Un Front-end no suele incluir todas las ventajas que la aplicación final por lo tanto, su uso generalmente está limitado.

    ¿Eso significa que si alguien utiliza un Front-End no puede hacer lo mismo que alguien que utilice una aplicación final?
    – No, si alguien utiliza una aplicación final de forma tan simple que hasta lo podría hacer con un Front-end.
    – Si, si alguien utiliza la aplicación final para hacer cosas complejas y más profesionales y no simplemente a nivel ‘usuario’.

    ¿Qué pasa si alguien no sabe manejar una herramienta Front-end?
    – No pasa nada, solo que si esa persona no sabe manejar una herramienta intuitiva, imaginate algo más complicado.

    ¿Qué pasa si alguien quiere hacer cosas complejas con un Front-end?
    – Pues, evidentemente hay cosas que el front-end no podrá hacer y tendrá que utilizar la aplicación final.

    Así que, chicos, chicas, espero que hayais entendido la diferencia entre GUI y FRONT-END a partir de ahora hablemos con propiedad conociendo la diferencia. 😀

  • Disponibles las transparencias de la Astricon 2008

    Casi por casualidad, encontré una transparencia muy interesante sobre una charla que se dió en la Astricon 2008 y viendo la web donde la encontré, me puse a buscar y ví que pertenecía a un directorio no enlazado en la web de la Astricon, pero como están todas las transparencias de este evento, me pareció buena idea guardarlas y ponerlas a disposición de la comunidad, seguro que a muchos les gustará. 😀

    Son de la Astricon 2008, el evento de usuarios de Asterisk celebrado en los EEUU del año pasado, posiblemente muchos ya las tengais, pero para los que acaban de descubrirlo como yo, es bastante valioso, de hecho varias charlas que se dieron son bastante interesantes. Una vez conseguido el material y con la ayuda de un par de aplicaciones de Linux, he sacado las portadas para hacerlas más atractivas a la vista de todos y las teneis disponible aquí.

    Que las disfruteis. 🙂

    Material de la Astricon 2008

  • Alternativa al AgentCallBackLogin en Asterisk 1.6

    Uno de los cambios más dramáticos de Asterisk 1.6 es sin duda la desaparición del comando AgentCallBackLogin, este comando sirve para loguear y desloguear agentes en una cola permitiendo al agente colgar el teléfono sin que este se desloguee (como ocurre con el AgentLogin) y así los usuarios pueden recibir llamadas enviadas a una cola y utilizar el terminal como si fueran usuarios normales y no exclusivamente agentes de recepción de llamadas.

    En Asterisk 1.6 este comando desapareció como por arte de magia (sin llegar al punto ‘deprecated’) y era debido a que «supuestamente» la misma lógica que se conseguía hacer mediante esta aplicación de Asterisk, se podía hacer con un poco de programación de dialplan.

    Kevin P. Flemming comentaba esto en la lista:
    «We have already been discussing the idea of just turning chan_agent into only ‘always connected’ mode, and removing all support for callback mode. It seems on the surface that everything that chan_agent does in ‘callback’ mode can be accomplished using dialplan logic and dynamic queue members (which did not exist when chan_agent was created).»

    Esto no gustó a muchos ya que este comando es básico y fundamental cuando alguien configura un «callcenter» con Asterisk y mucho menos cuando decide leer la «alternativa» que proponen los desarrolladores a esa «lógica de dialplan».

    Para aquellos que utilicen el AgentCallBackLogin en 1.4, al pasar a 1.6 deben leer este documento que explica qué hay que hacer:
    http://svn.digium.com/svn/asterisk/branches/1.4/doc/queues-with-callback-members.txt

    Si después de leer este documento os habeis quedado igual que yo, intentaré explicar cómo se puede hacer para que sea menos traumático el cambio a continuación: (más…)

  • Publicados los vídeos de las conferencias del VoIP2DAY

    Me avisan que ya están disponibles TODAS las conferencias realizadas durante el VoIP2DAY para todos aquellos que no pudieron verlas ahora pueden sentarse cómodamente con un cubo de palomitas y disfrutar de más de 18 horas de vídeo sobre VoIP. 😀

    Agradecimiento a todos los que han hecho posible disfrutar de estas extraordinarias ponencias, conferencias, charlas y material para el uso y disfrute de todos los aficionados a la VoIP y Asterisk.

    – Vídeos de las charlas del día del Call Center.

    – Vídeos de las charlas del día de las Comunicaciones Avanzadas.

    – Vídeos de las charlas del día de la Comunidad Asterisk.

    Habrá que conectar el ordenador a la televisión y sentarse a verlas porque todas son muy, muy interesantes.

  • Instalación desde cero de Asterisk y Asterisk-GUI

    Pese a que Alberto Sagredo se me ha adelantado con el vídeo de VoIPSupply, ya tenía preparado un vídeo donde pongo los pasitos para la instalación completa de un Asterisk y su interfaz, así como la configuración básica para registrar un softphone y hacer llamadas externas, configurar un Meetme, etc.

    La explicación es más bien escasa, ya que viendo el vídeo y los pasos que he dado se puede entender fácilmente qué hay que hacer, no obstante y como siempre digo, la experiencia es algo que uno debe adquirir personalmente por lo que, hasta que uno no haga el esfuerzo y lo instale, no se dará cuenta de lo sencillo que es y las posibilidades/limitaciones que va a encontrar.

  • Cómo configurar un fax virtual T38 en Asterisk

    Partiendo que no lo he probado aún (a ver si durante estas necesarias vacaciones puedo dedicarle un ratito), he visto un artículo muy interesante sobre el T38modem, una especie de IAXmodem pero con soporte para enviar faxes mediante T38 con Asterisk.

    Asterisk soporta T38 en modo passthrough en SIP, esto es, lo deja pasar, pero no iniciar ni acabar una llamada.

    Justamente, el T38modem se basa en la misma filosofía que el IAXmodem por lo que sería posible disponer de esta ventaja tal y como comentan utilizando Hylafax como servidor de faxes de la misma manera que podríamos tenerlo con el IAXmodem pero con T38 en lugar de T30. Suena bien, ¿verdad? 😀

    Vamos a ver cómo se hace:

    cd ~
    cvs -z9 -d :pserver:anonymous@openh323.cvs.sourceforge.net:/cvsroot/openh323 co ptlib_unix
    cvs -z9 -d :pserver:anonymous@openh323.cvs.sourceforge.net:/cvsroot/openh323 co -D «5/21/2007 23:59:59» opal
    cvs -z9 -d :pserver:anonymous@openh323.cvs.sourceforge.net:/cvsroot/openh323 co t38modem

    Con esto habremos descargado las librerías y la aplicación t38modem.
    Ahora vamos a compilar:

    cd ~/pwlib
    ./configure
    make
    sudo make install

    cd ~/opal
    ./configure
    make
    sudo make install
    sudo ldconfig

    cd ~/t38modem
    make USE_OPAL=1 USE_UNIX98_PTY=1 opt
    make USE_OPAL=1 USE_UNIX98_PTY=1 install

    Vamos a probar que realmente se ha instalado y funciona…

    /usr/local/bin/t38modem -tt -o /var/log/t38modem.log –no-h323 -u T38modem –sip-listen udp\$127.0.0.1:6060 –sip-redundancy 3 –ptty +/dev/ttyT38-1,+/dev/ttyT38-2,+/dev/ttyT38-3 –route «modem:.*=sip:<dn>@127.0.0.1» –route «sip:.*=modem:<dn>»

    Ahora vamos a preparar la configuración para 3 módems, para lo que supondremos que hemos instalado previamente el servidor Hylafax como indica Julian en su web y continuaremos:

    cp ~/t38modem/HylaFAX/config.ttyx /var/spool/hylafax/etc/config.ttyT38-1
    ln -s /var/spool/hylafax/etc/config.ttyT38-1 /var/spool/hylafax/etc/config.ttyT38-2
    ln -s /var/spool/hylafax/etc/config.ttyT38-1 /var/spool/hylafax/etc/config.ttyT38-3

    Como en el IAXmodem, vamos a modificar el archivo inittab para que esté siempre activa esta aplicación:

    echo «t1:2345:respawn:/usr/sbin/faxgetty ttyT38-1» >> /etc/inittab
    echo «t2:2345:respawn:/usr/sbin/faxgetty ttyT38-2» >> /etc/inittab
    echo «t3:2345:respawn:/usr/sbin/faxgetty ttyT38-3» >> /etc/inittab
    kill -HUP 1

    Reiniciamos el servidor Hylafax:

    /etc/init.d/hylafax restart

    Y chequeamos que todo está funcionando corréctamente:

    cat /var/spool/hylafax/status/ttyT38-1

    Lo que nos debería mostrar un mensaje como este: Running and idle

    Ahora vamos a ver cómo conectamos el T38modem a Asterisk, para lo que crearemos un usuario SIP propio en /etc/asterisk/sip.conf

    [T38modem]
    type=friend
    host=127.0.0.1
    permit=127.0.0.1
    context=outgoing
    port=6060
    allow=all
    canreinvite=no

    y en este mismo archivo, en el contexto [general]:

    t38pt_udptl=yes

    Para enviar faxes, tan solo hay que utilizar algún cliente Hylafax y será el usuario T38modem el que se encargue de hacer la llamada mediante T38 por SIP. 🙂
    Para recibir faxes, como siempre, enviando el fax entrante a SIP/${EXTEN}@T38modem.

    Si a alguien le funciona, se agradece un comentario.
    Si teneis problemas, lo que he dicho antes… a pelearse y googlear un poco. 😛

    Enlace: http://voip-info.org/wiki/view/T38modem+configuration+with+Asterisk

  • Cómo configurar el envío de emails desde Asterisk

    Es una pregunta bastante común y pese a que su respuesta es la misma, voy intentar dejarlo tan claro como sea posible.

    Asterisk es una aplicación, como cualquier otra que corra bajo Linux, y por lo tanto sigue una norma que siguen todas las aplicaciones en Linux: Asterisk NO ENVIA EMAILS, si no que se comunica con el servidor SMTP que tengamos instalado en nuestro sistema local y es este el que envía el email. Incluso si queremos utilizar un servidor remoto con una cuenta, el procedimiento sigue siendo el mismo.

    Por este motivo, y por que todas las aplicaciones en linux funcionan prácticamente igual (apache, pureftpd, syslog, etc…) suelen darle los emails que quieren enviar a una aplicación bastante conocida: SendMail.

    SendMail es un servidor de envío de emails (SMTP) y fue uno de los primeros y más avanzados servidores de este tipo, pero su poca fiabilidad (demasiados bugs para los administradores de redes) unido a su complejidad si queríamos configurar un servidor serio, hizo que apareciesen otros servidores SMTP más ligeros, simples y rápidos que Sendmail.

    No obstante, todos los sistemas continúan intentando enviar emails dejándolos a Sendmail y es por esto por lo que los nuevos y más sencillos servidores SMTP utilizan un truco para hacerse pasar por Sendmail y poder «suplantarlo», esto es, crean un enlace simbólico en el sistema con el nombre «sendmail», de manera que cuando una aplicación intenta acceder a «sendmail», realmente quien contesta es esta aplicación. 🙂

    Como ya he comentado, casi todas las aplicaciones que tienen la necesidad o la opción de enviar emails utilizan el servidor SMTP local, esto ha hecho que muchas distribuciones, para facilitar la configuración y envío de emails, instalen por defecto algunos sustitutos de sendmail como por ejemplo exim o postfix son las más conocidas.

    El principal problema de utilizar el servidor SMTP local es el proveedor: Debido al aumento de correos SPAM, los proveedores y los servidores de correo que van a recepcionar tu email comprobarán si realmente el servidor del que procede el email es realmente un servidor «oficial» o bien un servidor que se dedica a enviar SPAM, y como el servidor local no es realmente un servidor en toda regla (no tiene registros MX en el DNS de algún dominio, tiene una dirección IP dinámica, o ha sido utilizado por otro spamer) es por lo que se aconseja encarecidamente utilizar una cuenta de algún servidor de emails ya verificado y seguro.

    Posiblemente, tras la instalación de nuestra distribución preferida, podremos enviar emails con el comando:

    echo «Prueba de email» |mail -s «Prueba de email» miUsuario@miDominio.com

    Pero cuando hayamos enviado varios de este tipo y empecemos a confiarnos, veremos como nuestro cliente de correo empezará a considerarlo spam, o puede que ni llegue. Es entonces cuando tendremos que configurar nuestro servidor SMTP local para que envíe los emails mediante una cuenta autentificada.

    Para el ejemplo de configuración voy a hacerlo con Exim (el servidor que viene por defecto con Debian), quizá sea uno de los más sencillos de configurar y de manejar, aunque personalmente siempre he preferido Qmail por ser mucho más seguro, no obstante, como nuestro objetivo no es configurar un servidor de correos en toda regla, vamos a hacerlo con Exim (versión 4) que es la que trae Debian (y Ubuntu) de serie.

    Lo primero que tenemos que hacer es asegurarnos que lo tenemos instalado:

    apt-get install exim4 exim4-config

    Una vez que lo hayamos instalado, aparecerá una pantalla de configuración. Si no aparece, podremos acceder a ella en cualquier momento ejecutando el comando:

    dpkg-reconfigure exim4-config

    ¿Sencillo verdad? 🙂

    Será entonces cuando nos pregunte por distintas opciones de configuración:

    – ¿Quiere utilizar archivos separados para la configuración?
    Respondemos SI

    – ¿De qué forma queremos configurar nuestro servidor?
    Respondemos «enviar por SMARTHOST, y recibir por SMTP o Fetchmail»

    – Escriba el nombre del sistema:
    Respondemos con nuestro dominio: miDominio.com

    – Escriba la dirección IP desde donde va a atender las conexiones al SMTP:
    Respondemos: 127.0.0.1

    – Escriba otros servidores destino que el SMTP será aceptado:
    Aquí no respondemos nada, lo dejamos en blanco.

    – Sistemas a los que reenviar emails ?
    No piques, esto también hay que dejarlo en blanco. 😛

    – Escribe el sistema que gestionará el correo saliente de este sistema:
    (Aquí escribimos nuestro servidor SMTP remoto, por ejemplo…)
    smtp.miDominio.com

    Si queremos utilizar una cuenta de gmail, el servidor SMTP de gmail hay que especificarlo junto con el puerto que va a utilizar, y sería esto: smtp.gmail.com::587 (ojo que lleva dos simbolos de dos puntos antes del puerto)

    – ¿Quiere ocultar el nombre local del sistema local del email saliente?
    Pues NO.

    – Quiere cachear las peticiones DNS para ahorrar ancho de banda?
    Pues NO.

    Bien, hasta ahora tenemos algunos parámetros básicos configurados, pero no hemos indicado el usuario ni la contraseña con el que queremos autentificarnos para enviar emails. Si probásemos a enviar emails, seguramente nuestro servidor remoto recibiría un email de un tal root@localhost y nos lo rechazaría. 🙂

    Vamos a configurar los datos importantes:

    1º. – Editamos el archivo /etc/exim4/passwd.client y escribimos algo como esto:

    smtp.miDominio.com:usuario:contraseña

    En el caso de que queramos utilizar la cuenta de email, deberíamos poner algo como esto:

    gmail-smtp.l.google.com:usuario@gmail.com:contraseña
    *.google.com:usuario@gmail.com:contraseña
    smtp.gmail.com:usuario@gmail.com:contraseña

    De esta manera, sea cual sea el nombre del servidor SMTP que utilicemos en gmail, le enviaremos los parámetros correctos y nos aceptará el envío.

    2º.- Protegemos el archivo para que nadie tenga acceso a leer nuestros datos:

    chown root:Debian-exim /etc/exim4/passwd.client

    3º.- Si estamos configurando nuestra cuenta de Gmail, hay que indicarle (otra vez) que el envío debe hacerlo por el puerto 587 en lugar del estandar (el 25), por lo que tendremos que editar el archivo:

    /etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost

    y justo encima de la línea que dice algo como: (hosts_try_auth…) añadir lo siguiente:
    port=587

    4º.- Por último, vamos a configurar nuestra identificación saliente:

    echo «root@localhost: usuario@miDominio.com" >> /etc/exim4/email-addresses

    Y listo, lo último que nos queda es recargar la configuración:

    ejecutamos: update-exim4.conf (es un comando 🙂

    Y probamos a enviar un email como hemos hecho antes…

    echo «Prueba de email» |mail -s «Prueba de email» miUsuario@miDominio.com

    y veremos cómo nos llega con el usuario y dominio correcto. 😀

    Bueno, parece más complicado de lo que realmente es. Una vez que se ha configurado unos cuantos sistemas con esta técnica, se hace todo diréctamente y sin tener que recordar los pasitos.

    Una vez tengamos esto hecho y podamos enviar emails con nuestra cuenta oficial, entonces podremos recibir los emails que hayamos configurado en el buzón de voz de Asterisk, o incluso nuestras alertas de arranque de asterisk o incluso enviar faxes mediante Hylafax,…

    Más información:
    http://www.exim.org/
    http://wiki.debian.org/GmailAndExim4
    http://wiki.debian.org/PkgExim4

  • Como ejecutar aplicaciones durante una llamada

    En la lista de Asterisk-ES a veces se comenta una utilidad que parece que no mucha gente conoce llamada «dynamic features». Oficialmente esta característica forma parte del conjunto de «recursos» que componen Asterisk y que, como su nombre indica, son añadidos dinámicos, lo que realmente significan, recursos que pueden ser accedidos dinámicamente durante una llamada.

    Estos añadidos son por ejemplo, las transferencias, el parking de llamadas y el mapa de aplicaciones (applicationmap), entre otros, y se definen en el archivo features.conf donde vamos a encontrar opciones y una serie de parámetros junto con un código de tecla que debemos pulsar para poder utilizarlos.

    Como ejemplo de estos añadidos encontramos los básicos como:

    • blindxfer (transferencia ciega)
    • atxfer (transferencia atendida)
    • automon (grabación bajo demanda)
    • pickupexten (captura de llamadas que suenan en los terminales del «grupo»)
    • automixmon (grabación bajo demanda y posterior mezcla de las locuciones)

    Hay una parte muy interesante llamada applicationmap que consiste en una serie de combinaciones que podemos modificar para ejecutar aplicaciones básicas de dialplan, durante una conversación.

    Por ejemplo: testfeature => #9,peer,Playback,tt-monkeys

    Este comando permitirá que cuando el llamante como el llamado durante una conversación, pulse las teclas # y 9, se reproduzca la locución tt-monkeys, algo muy gracioso, pero muy interesante en ciertos momentos.

    Existe una limitación para este tipo de comandos, y es que no es recomendable utilizarlo para ejecutar aplicaciones relacionadas con el dialplan directo, es decir: Macro, Goto, Background, WaitExten y algunas de este tipo, pero en cambio sí que se puede ejecutar un «AGI(aplicacion.agi)» 😛

    Para evitar el uso accidental de este tipo de comandos on-line, se hace necesario habilitar dicho comando mediante una variable llamada DYNAMIC_FEATURES justo antes de hacer la llamada: Set(DYNAMIC_FEATURES=testfeature)

    En Asterisk 1.6, nos encontramos algunas novedades bastante interesantes, como:

    • atxferdropcall (permite no perder la llamada en caso de que la transferencia no se realice corréctamente, en cuyo caso volvería a sonar en el usuario que inició la transferencia)
    • atxfernoanswertimeout (permite cambiar el timeout que una llamada transferida esté a la espera antes de volver a la extensión que inició la transferencia)
    • Grupos para habilitar varios applicationmaps sin necesidad de definirlos todos:
      Set(DYNAMIC_FEATURES=grupo)

      donde:
      [grupo]
      testfeature=>#9

    Grandes cosas se pueden llegar a hacer utilizando estas ventajas de Asterisk que son poco conocidas pero muy, muy útiles si se conocen.

    Que lo disfruteis. 😀