Propuestas de parches Asterisk-RSP
José Ferney Franco Baquero
Trabajando con RSP nos hemos encontrado con algunos parches que nos gustaría poner a consideración comunidad de Asterisk RSP. ¿Qué debo hacer para contribuir?
Los siguientes son las funcionalidades que tienen en consideración:
1. A nuestro juicio hace falta un campo en el evento ADDMEMBER del QueueLog el cual permita relacionar la interfaz que acaba de agregarse como miembro de una cola con el membername asignado a dicha interfaz. Así si el dispositivo SIP/401 ingreso a la cola Queue-Lite con membername 909 y recibe una llamada en esta del número 123456789 se tendrán los siguientes eventos:
1266937746|1266937738.14105|Queue-Lite|SIP/401|ADDMEMBER|
1266937760|1266937759.14111|Queue-Lite|NONE|ENTERQUEUE||123456789
1266937766|1266937759.14111|Queue-Lite|909|CONNECT|7|1266937760.14112
1266937845|1266937822.14130|Queue-Lite|912|TRANSFER|909|Internal|3|20
Lo anterior se debe a que actualmente el evento ADDMEMBER es:
ast_queue_log(args.queuename, chan->uniqueid, args.interface, "ADDMEMBER", "%s", "");
Pensamos que debería ser algo como:
ast_queue_log(args.queuename, args.membername, "ADDMEMBER", "%s", chan->uniqueid, args.interface);
De esta manera los eventos para el ejemplo anterior serían:
1266937746|1266937738.14105|Queue-Lite|SIP/401|ADDMEMBER|SIP/401
1266937760|1266937759.14111|Queue-Lite|NONE|ENTERQUEUE||123456789
1266937766|1266937759.14111|Queue-Lite|909|CONNECT|7|1266937760.14112
1266937845|1266937822.14130|Queue-Lite|909|TRANSFER|123|Internal|3|20
Con lo que es posible determinar el miembro (mediante su alias o membername) que contesto la llamada y en que dispositivo lo hizo.
Finalmente, se debe tener en cuenta que el evento REMOVEMEMBER se crea mediante:
ast_queue_log(args.queuename, chan->uniqueid, args.interface, "REMOVEMEMBER", "%s", "");
Por lo que el evento sería algo como:
1266956732|CLI|Queue-Lite|SIP/401|REMOVEMEMBER|
Podría ser cualquiera de las siguientes. Ya que en todo caso la relación entre dispositivo y membername ya se tiene:
1266956732|CLI|Queue-Lite|SIP/401|REMOVEMEMBER|
1266956732|CLI|Queue-Lite|909|REMOVEMEMBER|
1266956732|CLI|Queue-Lite|909|REMOVEMEMBER|SIP/401
2. El parche http://svn.digium.com/view/asterisk/team/murf/bug7978/apps/app_queue.c?view=diff&rev=48055&r1=48054&r2=48055 considera la acción demanager QueueLog el cual permite enviar un evento personalizado al queue_log desde el AMI. En estos momentos la única forma de hacerlo es mediante la aplicación QueueLog del plan de marcación.
3. El parche https://issues.asterisk.org/view.php?id=7840 agrega el evento Masquerade al AMI mediante el cual es posible rastrear las transferencias en Asterisk.
Nos gustaría conocer su opinión al respecto y en caso de que consideren que los cambios merecen ser incorporados al repositorio nos dijeran que procedimiento se debe realziar ya que estos cambios nos han ayudado mucho sería muy bueno agregarlos al repositorio.
Cordialmente,
Saúl Ibarra
Comentarios inline :)
2010/2/23 José Ferney Franco Baquero <fer...@gmail.com>:
Tienes razón, tiene sentido. Lo curioso es que recuerdo que esto lo
'solucioné' de otra manera hace tiempo, y no me acuerdo ahora mismo...
a ver si me viene y te comento :) Modificar esos logs no importa
demasiado, siempre que la información se añada al final, para no
romper parsers existentes y tal :)
>
> 2. El parche
> http://svn.digium.com/view/asterisk/team/murf/bug7978/apps/app_queue.c?view=diff&rev=48055&r1=48054&r2=48055
> considera la acción demanager QueueLog el cual permite enviar un evento
> personalizado al queue_log desde el AMI. En estos momentos la única forma de
> hacerlo es mediante la aplicación QueueLog del plan de marcación.
>
Suena bien, pero podrías darme un ejemplo de cuando sería interesante?
Hay que tener en cuenta que en un fichero no importa, pero como
también soportamos RealTime, hay que andar con cuidado.
>
> 3. El parche https://issues.asterisk.org/view.php?id=7840 agrega el evento
> Masquerade al AMI mediante el cual es posible rastrear las transferencias en
> Asterisk.
>
Mola :)
> Nos gustaría conocer su opinión al respecto y en caso de que consideren que
> los cambios merecen ser incorporados al repositorio nos dijeran que
> procedimiento se debe realziar ya que estos cambios nos han ayudado mucho
> sería muy bueno agregarlos al repositorio.
>
Si al resto de la gente le parecen bien, no son excesivamente
intrusivos, y ofrecen una fucnionalidad que a la gente le pueda ayudar
(recordemos que esto es RSP no NACSFP), mandas un mail a la lista con
los diffs contra la RSP y algún admin lo commiteará :)
Gracias y un saludo!
PD: Sorry si a veces me pongo quisquilloso, pero ya no trabajo con
Asterisk y por lo tanto no puedo probar los cambios... y tratándose de
Asterisk no mola eso de 'si compila commit'.
PD2: NACSFP == Nice And Cool Sexy Feature Patchset xD
--
/Saúl
http://saghul.net | http://sipdoc.net
José Ferney Franco Baquero
1. Inicialmente estabamos usando un evento definido por usuario en donde se hace esta relación.
2. Un buen ejemplo es el que te mensiono en el punto 1.
Otro es el que viene en Asterisk: QueueLog(101|${UNIQUEID}|${AGENT}|WENTONBREAK|600)
Uno podría querer hacer las pausas desde una aplicación externa conectada al asterisk a través del AMI. Mediante esta acción podría enviarse el motivo de la pausa después de una pausa exitosa para tener en cuenta en los reportes. Sin está acción es neceasario hacer un 'Originate' para poder enviar dicha información desde el plan de marcación. Lo anterior es muy incomodo ya que incluso genera registros en el CDR y a mi juicio una solución muy chapucera.
3. Es cierto: Aguanta.
Como adjunto envío los .patch para su aprovación y posible commit.
Saludos
--
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es-rsp" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a asteris...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a asterisk-es-r...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/asterisk-es-rsp?hl=es.
José Ferney Franco Baquero
Realizando pruebas al parque del evento ADDMEMBER nos dimos cuenta que cuando no se especifica el membername se envía un (null). Adjunto la corrección para que en lugar de ello se envíe el dispositivo del miembro.
Cordialmente,
Saúl Ibarra
2010/2/26 José Ferney Franco Baquero <fer...@gmail.com>:
> Hola.
>
> Realizando pruebas al parque del evento ADDMEMBER nos dimos cuenta que
> cuando no se especifica el membername se envía un (null). Adjunto la
> corrección para que en lugar de ello se envíe el dispositivo del miembro.
>
Personalmente no tengo objeciones a los parches, me parecen
interesantes. No obstante, me gustaría recibir feedback de quienes
están 'en la línea de fuego', porque yo ya no puedo probar esto, y
molaría mantener el estatus de RSP :)
Dicho lo cual, no estoy en contra de esto siempre que los añadidos
sean al final, ya que no queremos romper los parsers de nadie :)
Así que ¡'call for testing'! Jose Luis, se que lurkeas por éstos lares
;), y Juan Carlos, podríais por favor dar alguna opinión al respecto?
Gracias!
José Ferney Franco Baquero
La verdad no espero menos de los involucrados en este "proyecto" el cual siempre he considerado muy serio. Por lo pronto puedo decir que nosotros ya hemos incorporado los parches y los hemos estado probando. De esta manera cualquier observación que encontremos la estaremos notificando.
Cordialmente,