MFC/R2 (Multi Frecuency Compelled R2) es un protocolo de señalización telefónica peer-to-peer, el cual es utilizado, generalmente, en países de Latinoamérica y Asia.
En este artículo intentaré explicar como instalar el soporte para MFC/R2 en Asterisk. A su vez es importante destacar que esta guía está orientada a aquellos lectores que poseen cierta experiencia instalando y configurando Asterisk y dahdi.
Lo primero que debemos hacer, es ver si la versión de Asterisk que deseamos instalar dispone del parche de R2. Para ello, debemos dirigirnos a la siguiente URL: http://code.google.com/p/openr2/downloads/list
NOTA! En caso de querer instalar, el soporte para R2, en Asterisk-RSP habrá que bajar el
siguiente parche: http://openr2.googlecode.com/files/openr2-asterisk-1.4.24.patch seguramente dará conflictos y habrá que editar a mano chan_dahdi.c para resolverlos.
Una vez determinada y bajada la versión de Asterisk, el parche y la librería openr2. Pasaremos a compilar e instalar todos los paquetes en el siguiente orden:
- libopenr2 (reemplaza la instalación de libpri)
- dahdi-linux
- dahdi-tool
Finalizados los pasos anteriores aplicamos el parche e instalamos Asterisk:
- cd /path/to/asterisk-sources/
- patch -p0 < /path/to/openr2.patch
- ./bootstrap.sh
- ./configure
- make && make install
Para corroborar que chan_dahdi se haya compilado con el soporte para openR2, ejecutamos el siguiente comando: ldd /usr/lib/asterisk/modules/chan_dahdi.so y si todo está bien veremos la siguiente línea:
libopenr2.so.X => /usr/local/lib/libopenr2.so.X
Ahora pasamos a configurar dahdi. Editamos /etc/dahdy/system.conf y configuramos nuestros Spans, de la siguiente manera:
span=1,1,0,cas,hdb3
cas=1-15:1101
cas=17-31:1101
dchan=16
Si poseemos más de una trama, vamos repitiendo el bloque anterior modificando los números de los canales y span, según corresponda. Por ejemplo para el span2 sería:
span=2,2,0,cas,hdb3
cas=32-46:1101
cas=48-62:1101
dchan=47
Por último configuramos chan_dahdi, editando el archivo: /etc/asterisk/chan_dahdi.conf
[channels]
language=es
context=from-pstn
signalling=mfcr2
mfcr2_variant=ar
mfcr2_get_ani_first=no
mfcr2_max_ani=10
mfcr2_max_dnis=4
mfcr2_category=national_subscriber
mfcr2_mfback_timeout=-1
mfcr2_metering_pulse_timeout=-1
mfcr2_logdir=log
mfcr2_logging=all
group=0
channel => 1-15
channel => 17-31
lunes, 15 de noviembre de 2010
miércoles, 10 de noviembre de 2010
Data API Providers
Con el lanzamiento de Asterisk 1.8, en octubre del presente año, se incorporaron varias características nuevas, las cuales iremos comentando a medida que las vallamos testeando. Hoy nos centraremos en una utilidad desarrollada por Eliel Sardañons, un desarrollador Argentino que participó del pasado Google Summer of Code 2010. Esta nueva herramienta permite obtener información detallada sobre Asterisk y cada uno de sus módulos, aplicaciones, channels, etc. los cuales son denominados "Providers".
Sin más preámbulos, vamos a la acción y veamos en funcionamiento esta API. Para acceder a la información que necesitemos, lo primero que debemos saber es cuales son los Providers que disponemos y que nivel de de información nos interesa saber. Para ello debemos ejecutar, el siguiente comando:
*CLI> data show providers
/asterisk/channel/iax2/peers (get) [chan_iax2.c]
/asterisk/channel/iax2/users (get) [chan_iax2.c]
/asterisk/channel/dahdi/version (get) [chan_dahdi.c]
/asterisk/channel/dahdi/status (get) [chan_dahdi.c]
/asterisk/channel/dahdi/channels (get) [chan_dahdi.c]
/asterisk/channel/agent/list (get) [chan_agent.c]
/asterisk/channel/sip/peers (get) [chan_sip.c]
/asterisk/core/hints (get) [pbx.c]
/asterisk/core/channels (get) [channel.c]
/asterisk/core/channeltypes (get) [channel.c]
/asterisk/application/voicemail/list (get) [app_voicemail.c]
/asterisk/application/queue/list (get) [app_queue.c]
/asterisk/application/meetme/list (get) [app_meetme.c]
El resultado del comando anterior nos muestra la lista de Providers con su respectivo nivel de información, separado por barras (/). Por ejemplo, si únicamente nos interesa ver los datos relacionados con los Peers de IAX2, podríamos ejecutar lo siguiente:
*CLI> data get /asterisk/channel/iax2/peers
peers
peer
smoothing: False
pokefreqok: 60000
inkeys: ""
host: "XXX.XXX.XXX.XXX"
encryption: "no"
mailbox: ""
mohinterpret: ""
cid_num: ""
parkinglot: ""
expiry: 60
dbsecret: ""
maxcallno: 0
maxms: 2000
status: "OK (1 ms)"
trunk: True
port: 4569
regexten: ""
outkey: ""
historicms: 1
mask: "255.255.255.255"
dynamic: False
zonetag: ""
username: "USUARIO"
pokefreqnotok: 10000
secret: "CLAVE"
peercontext: ""
callno: 0
mohsuggest: ""
lastms: 1
name: "NOMBRE PEER"
cid_name: ""
context: ""
codecs
codec
frame_length: 80
samplespersecond: 8000
name: "alaw"
description: "G.711 A-law"
A medida que vamos Quitando niveles, nos dará más información. Por ejemplo si nos interesa saber todo lo que pasa en Asterisk en general, solamente debemos ejecutar CLI*> data get /asterisk
Como se podrá apreciar, la información que este devuelve es muy completa y puede ser de gran utilidad para el desarrollo de aplicaciones de monitoreo de Asterisk.
Para cerrar este artículo, voy a mostrar como es posible llamar remotamente a esta API a través del AMI.
Action: Command
ActionID: test
Command: data get Asterisk/channel/iax2/peers \r\n\n
Sin más preámbulos, vamos a la acción y veamos en funcionamiento esta API. Para acceder a la información que necesitemos, lo primero que debemos saber es cuales son los Providers que disponemos y que nivel de de información nos interesa saber. Para ello debemos ejecutar, el siguiente comando:
*CLI> data show providers
/asterisk/channel/iax2/peers (get) [chan_iax2.c]
/asterisk/channel/iax2/users (get) [chan_iax2.c]
/asterisk/channel/dahdi/version (get) [chan_dahdi.c]
/asterisk/channel/dahdi/status (get) [chan_dahdi.c]
/asterisk/channel/dahdi/channels (get) [chan_dahdi.c]
/asterisk/channel/agent/list (get) [chan_agent.c]
/asterisk/channel/sip/peers (get) [chan_sip.c]
/asterisk/core/hints (get) [pbx.c]
/asterisk/core/channels (get) [channel.c]
/asterisk/core/channeltypes (get) [channel.c]
/asterisk/application/voicemail/list (get) [app_voicemail.c]
/asterisk/application/queue/list (get) [app_queue.c]
/asterisk/application/meetme/list (get) [app_meetme.c]
El resultado del comando anterior nos muestra la lista de Providers con su respectivo nivel de información, separado por barras (/). Por ejemplo, si únicamente nos interesa ver los datos relacionados con los Peers de IAX2, podríamos ejecutar lo siguiente:
*CLI> data get /asterisk/channel/iax2/peers
peers
peer
smoothing: False
pokefreqok: 60000
inkeys: ""
host: "XXX.XXX.XXX.XXX"
encryption: "no"
mailbox: ""
mohinterpret: ""
cid_num: ""
parkinglot: ""
expiry: 60
dbsecret: ""
maxcallno: 0
maxms: 2000
status: "OK (1 ms)"
trunk: True
port: 4569
regexten: ""
outkey: ""
historicms: 1
mask: "255.255.255.255"
dynamic: False
zonetag: ""
username: "USUARIO"
pokefreqnotok: 10000
secret: "CLAVE"
peercontext: ""
callno: 0
mohsuggest: ""
lastms: 1
name: "NOMBRE PEER"
cid_name: ""
context: ""
codecs
codec
frame_length: 80
samplespersecond: 8000
name: "alaw"
description: "G.711 A-law"
A medida que vamos Quitando niveles, nos dará más información. Por ejemplo si nos interesa saber todo lo que pasa en Asterisk en general, solamente debemos ejecutar CLI*> data get /asterisk
Como se podrá apreciar, la información que este devuelve es muy completa y puede ser de gran utilidad para el desarrollo de aplicaciones de monitoreo de Asterisk.
Para cerrar este artículo, voy a mostrar como es posible llamar remotamente a esta API a través del AMI.
Action: Command
ActionID: test
Command: data get Asterisk/channel/iax2/peers \r\n\n
martes, 9 de noviembre de 2010
Entendiendo el queue_log
Con el fin de gestionar adecuadamente las colas de ACD (Automatic Call Distribution), es importante hacer un seguimiento detallado de los eventos que se ejecutan en las mismas. Para ello, Asterisk implementa el queue_log, que es un archivo donde se registran dichas acciones en formato de texto plano y por defecto se encuentra en /var/log/asterisk/queue_log.
Por lo general las herramientas de estadísticas de call center, como Asternic y QueueMetrics, entre otras, basan su funcionamiento en la información que es entregada en este archivo. Por lo tanto, en este artículo nos dedicaremos a analizar en profundidad los datos que podremos encontrar en este log.
Al editar el archivo, encontraremos que los registros se encuentran con el siguiente formato:
TIMESTAMP|UNIQUEID|QUEUE_NUMBER|AGENT|EVENT|DATA1|DATA2|DATA3|DATA4|DATA5
Timestamp:
Es la fecha y hora en formato unix time
UniqueID:
El id único que identifica el canal
Queue_number:
El numero de interno de la cola o NONE si se trata de un evento general como AGENTLOGOFF
Agent:
Si el llamado fue asignado a un agente: Tecnología/Interno o NONE si es un evento general como ABANDON
Data n:
Son los valores que retorna cada evento, luego de su ejecución. Por ejemplo la duración de un llamado cuando es finalizado.
Ahora que conocemos la estructura general del archivo queue_log, pasaremos a ver en detalle los eventos y los valores que devuelve cada uno.
ABANDON:
Este evento se produce, cuando una persona abandona su posición en la Cola, antes de ser atendido. Los data que devuelve son:
- Data 1: position, la posición que tenía en la cola cuando realizó el hangup
- Data 2: origposition, la posición en la que entró en la cola
- Data 3: waittime, el tiempo que espero en la cola
AGENTDUMP:
El agente rechazó el llamado, mientras el cliente escuchaba el anuncio de la cola.
AGENTLOGIN:
El agente es logueado.
- Data 1: channel, el canal donde se genero el logueo
AGENTCALLBACKLOGIN:
El agente del tipo "callback" es logueado en la cola. Un agente del tipo "callback", a diferencia de un "agent/" es aquel que espera los llamados con el teléfono colgado, y en el momento que un llamado entra a la cola el teléfono suena y es logueado a la cola.
- Data 1: exten@context, el interno@contexto del agente.
AGENTLOGOFF:
El agente se desloguea
- Data 1: channel, el canal donde se origino el deslogueo
- Data 2: logintime, la cantidad de tiempo que el agente estuvo logueado. (en segundos)
AGENTCALLBACKLOGOFF:
El agente del tipo "callback" es deslogueado de la cola.
- Data 1: exten@context, el interno@contexto utilizado por el agente.
- Data 2: logintime, el tiempo que estuvo logueado
- Data 3: reason, la razón por la cual fue deslogueado, si no es un logoff normal. Ej: Autologoff, Chanunavail
COMPLETEAGENT:
El llamado fue conectado con un agente, y este fue finalizado normalmente por el agente.
- Data 1: holdtime, Tiempo que espero el cliente a ser atendido
- Data 2: holdtime, Duración de la llamada
- Data 3: origposition, Posición donde ingresó en que ingresó el llamado a la cola.
COMPLETECALLER:
El llamado fue conectado con un agente, y este fue finalizado normalmente por el cliente.
- Data 1: holdtime, Tiempo que espero el cliente a ser atendido
- Data 2: holdtime, Duración de la llamada
- Data 3: origposition, Posición donde ingresó en que ingresó el llamado a la cola.
CONFIGRELOAD:
La configuración ha sido re-cargada. (ej: asterisk -rx "reload")
CONNECT:
El llamado fue conectado con un agente.
- Data 1: holdtime, la cantidad de tiempo que el cliente estuvo en hold
- Data 2: bridgedchanneluniqueid, es el uniqueid del canal del agente que toma el llamado
ENTERQUEUE:
Un llamado ha ingresado a la cola.
- Data 1: URL, si es especificada
- Data 2: CallerID, Número de teléfono del cliente
EXITEMPTY:
La llamada es rechazada por la cola, debido a que no existen agentes logueados para atender la misma.
- Data 1: position, posición de la llamada en el momento que fue rechazada
- Data 2: origposition, posición de la llamada cuando ingresó a la cola
- Data 3: waittime, tiempo de espera
EXITWITHKEY:
El cliente utilizó una opción del menú, para salir de la cola.
- Data 1: key, tecla que presionó
- Data 2: position, posición en la que se encontraba en la cola
EXITWITHTIMEOUT:
El cliente estuvo demasiado tiempo en hold, y el tiempo expiró
- Data 1: position, posición del cliente en la cola
QUEUESTART:
El sistema de colas ha sido iniciado.
RINGNOANSWER:
El llamado es conectado a un agente, pero este no lo atiende.
- Data 1: ringtime, tiempo que estuvo sonando el teléfono del agente.
SYSCOMPAT:
La llamada es atendida por el agente, pero el sistema la rechaza porque los canales no son compatibles.
TRANSFER:
La llamada es transferida a otro interno.
- Data 1: extension, interno de destino
- Data 2: context, contexto utilizado
- Data 3: holdtime, tiempo en espera del agente hasta que se realizó la transferencia
- Data 4: calltime, duración de la llamada hasta que fue transferida.
Por lo general las herramientas de estadísticas de call center, como Asternic y QueueMetrics, entre otras, basan su funcionamiento en la información que es entregada en este archivo. Por lo tanto, en este artículo nos dedicaremos a analizar en profundidad los datos que podremos encontrar en este log.
Al editar el archivo, encontraremos que los registros se encuentran con el siguiente formato:
TIMESTAMP|UNIQUEID|QUEUE_NUMBER|AGENT|EVENT|DATA1|DATA2|DATA3|DATA4|DATA5
Timestamp:
Es la fecha y hora en formato unix time
UniqueID:
El id único que identifica el canal
Queue_number:
El numero de interno de la cola o NONE si se trata de un evento general como AGENTLOGOFF
Agent:
Si el llamado fue asignado a un agente: Tecnología/Interno o NONE si es un evento general como ABANDON
Data n:
Son los valores que retorna cada evento, luego de su ejecución. Por ejemplo la duración de un llamado cuando es finalizado.
Ahora que conocemos la estructura general del archivo queue_log, pasaremos a ver en detalle los eventos y los valores que devuelve cada uno.
ABANDON:
Este evento se produce, cuando una persona abandona su posición en la Cola, antes de ser atendido. Los data que devuelve son:
- Data 1: position, la posición que tenía en la cola cuando realizó el hangup
- Data 2: origposition, la posición en la que entró en la cola
- Data 3: waittime, el tiempo que espero en la cola
AGENTDUMP:
El agente rechazó el llamado, mientras el cliente escuchaba el anuncio de la cola.
AGENTLOGIN:
El agente es logueado.
- Data 1: channel, el canal donde se genero el logueo
AGENTCALLBACKLOGIN:
El agente del tipo "callback" es logueado en la cola. Un agente del tipo "callback", a diferencia de un "agent/" es aquel que espera los llamados con el teléfono colgado, y en el momento que un llamado entra a la cola el teléfono suena y es logueado a la cola.
- Data 1: exten@context, el interno@contexto del agente.
AGENTLOGOFF:
El agente se desloguea
- Data 1: channel, el canal donde se origino el deslogueo
- Data 2: logintime, la cantidad de tiempo que el agente estuvo logueado. (en segundos)
AGENTCALLBACKLOGOFF:
El agente del tipo "callback" es deslogueado de la cola.
- Data 1: exten@context, el interno@contexto utilizado por el agente.
- Data 2: logintime, el tiempo que estuvo logueado
- Data 3: reason, la razón por la cual fue deslogueado, si no es un logoff normal. Ej: Autologoff, Chanunavail
COMPLETEAGENT:
El llamado fue conectado con un agente, y este fue finalizado normalmente por el agente.
- Data 1: holdtime, Tiempo que espero el cliente a ser atendido
- Data 2: holdtime, Duración de la llamada
- Data 3: origposition, Posición donde ingresó en que ingresó el llamado a la cola.
COMPLETECALLER:
El llamado fue conectado con un agente, y este fue finalizado normalmente por el cliente.
- Data 1: holdtime, Tiempo que espero el cliente a ser atendido
- Data 2: holdtime, Duración de la llamada
- Data 3: origposition, Posición donde ingresó en que ingresó el llamado a la cola.
CONFIGRELOAD:
La configuración ha sido re-cargada. (ej: asterisk -rx "reload")
CONNECT:
El llamado fue conectado con un agente.
- Data 1: holdtime, la cantidad de tiempo que el cliente estuvo en hold
- Data 2: bridgedchanneluniqueid, es el uniqueid del canal del agente que toma el llamado
ENTERQUEUE:
Un llamado ha ingresado a la cola.
- Data 1: URL, si es especificada
- Data 2: CallerID, Número de teléfono del cliente
EXITEMPTY:
La llamada es rechazada por la cola, debido a que no existen agentes logueados para atender la misma.
- Data 1: position, posición de la llamada en el momento que fue rechazada
- Data 2: origposition, posición de la llamada cuando ingresó a la cola
- Data 3: waittime, tiempo de espera
EXITWITHKEY:
El cliente utilizó una opción del menú, para salir de la cola.
- Data 1: key, tecla que presionó
- Data 2: position, posición en la que se encontraba en la cola
EXITWITHTIMEOUT:
El cliente estuvo demasiado tiempo en hold, y el tiempo expiró
- Data 1: position, posición del cliente en la cola
QUEUESTART:
El sistema de colas ha sido iniciado.
RINGNOANSWER:
El llamado es conectado a un agente, pero este no lo atiende.
- Data 1: ringtime, tiempo que estuvo sonando el teléfono del agente.
SYSCOMPAT:
La llamada es atendida por el agente, pero el sistema la rechaza porque los canales no son compatibles.
TRANSFER:
La llamada es transferida a otro interno.
- Data 1: extension, interno de destino
- Data 2: context, contexto utilizado
- Data 3: holdtime, tiempo en espera del agente hasta que se realizó la transferencia
- Data 4: calltime, duración de la llamada hasta que fue transferida.
Suscribirse a:
Entradas (Atom)