Post a Reply
4451 views

Problema con estados de agentes en queue

  1. 12 years ago

    diego_casanova

    5 Mar 2012

    Hola a todos, tengo la versión completa del FOP 2.25 corriendo en un Trixbox v2.8.0.4 con asterisk 1.6.0.26 y dos queues con agentes dinámicos. Desde hace unos días (sin modificar nada en la configuración del server) ha comenzado a mostrar erroneamente el status de los agentes logeados. Aparecen en color verde, cuando en realidad están hablando y deberían aparecer en color rojo. Parecería ser que cuando un agente corta una llamada, queda en verde y deja a todos los otros agentes de la misma cola en color verde aun cuando estos tienen un llamado en curso, como si el evento de hangup lo recibieran todos los agentes. A partir de esto queda desincronizado y no muestra correctamente el status hasta que se reinicia el fop y vuelve a ocurrir.
    Las dos queues están configuradas de la siguiente manera:

    announce-frequency=0
    announce-holdtime=no
    announce-position=no
    autofill=yes
    eventmemberstatus=yes
    eventwhencalled=yes
    joinempty=yes
    leavewhenempty=no
    maxlen=0
    music=IVR
    periodic-announce-frequency=30
    queue-callswaiting=silence/1
    queue-thereare=silence/1
    queue-youarenext=silence/1
    retry=0
    strategy=rrmemory
    timeout=15
    weight=0
    wrapuptime=0

    También en el archivo sip_general_custom.conf tenemos la entrada:
    callevents=yes

    Muchas gracias.

  2. admin

    5 Mar 2012 Administrator

    Hola Diego,

    Que tipo de agentes tenes en las colas? Podrias mostrar el output de

    asterisk -rx "queue show"

    ?

    Gracias,

  3. diego_casanova

    7 Mar 2012

    Hola Nicolás, gracias por responder, la salida del comando es:

    5000 has 0 calls (max unlimited) in 'rrmemory' strategy (3s holdtime), W:0, C:3, A:1, SL:0.0% within 0s
    Members:
    SIP/1012 (dynamic) (Busy) has taken 6 calls (last was 298 secs ago)
    No Callers

    5100 has 5 calls (max unlimited) in 'rrmemory' strategy (56s holdtime), W:0, C:5, A:30, SL:0.0% within 0s
    Members:
    SIP/1004 (dynamic) (Busy) has taken 1 calls (last was 113 secs ago)
    SIP/1002 (dynamic) (Busy) has taken 30 calls (last was 161 secs ago)
    Callers:
    1. DAHDI/9-1 (wait: 1:35, prio: 0)
    2. DAHDI/11-1 (wait: 1:21, prio: 0)
    3. DAHDI/21-1 (wait: 1:03, prio: 0)
    4. DAHDI/1-1 (wait: 0:50, prio: 0)
    5. DAHDI/13-1 (wait: 0:27, prio: 0)

  4. admin

    8 Mar 2012 Administrator

    No veo nada raro, fijate que tengas completos los permisos en el manager.conf, lo mas simple es que le pontas "all" al read para probar. La falta de un permiso puede generar que no se reciban todos los eventos del manager. El estado de agentes funciona normalmente siempre y cuando tengas el eventwhencalled y mejor si tienes el eventmemberstatus, ambos en yes, en el queues.conf.

  5. diego_casanova

    8 Mar 2012

    Probé poniendole "all" a los permisos pero sigue ocurriendo lo mismo, tendrá que ver la cantidad de extensiones que muestra el fop?, porque funcionaba correctamente y lo único que se hizo fue agregar extensiones y comenzó a mostrar los status incorrectos. Te adjunto una captura de pantalla donde se ve claramente el problema.

    [url=http://imageshack.us/photo/my-images/268/statuslg.jpg/:3njlfxvv]http://img268.imageshack.us/img268/4267/statuslg.jpg[/url:3njlfxvv]

    Muchas Gracias.

  6. admin

    8 Mar 2012 Administrator

    La cantidad de extensiones no es relavante, el estado de miembros de cola se configura de acuerdo a eventos de AMI que genera la cola, asi que da igual. Lo que se me ocurre es que quizas el eventmemberstatus en asterisk 1.6 es diferente a 1.8 y 10. Prueba desactivando el eventmemberstatus, en cualquier caso deberia ver una captura del manager para probarlo localmente. El soporte de eventmemberstatus fue incluido en fop 2.24 (o fue ahora en 2.25?). Mi sospecha es que el manager NO esta enviando los eventos de agente. Para iniciar la captura de eso debes probar

    service fop2 stop
    cd /usr/local/fop2
    script capture.log
    ./fop2_server -X 1
    (dejalo correr, has algunos llamados en la cola, verifica que el estado se ve mal).
    ctrl-C
    exit
    service fop2 start

    Ahi ya tendras el archivo capture.log que podria analizar.

  7. diego_casanova

    8 Mar 2012

    Desactivé la opción eventmemberstatus de las queues y parece funcionar correctamente ahora. Muchas Gracias!

or Sign Up to reply!