Queue member status not updated

13 years ago

fopmiv

22 Mar 2011

Hi,

I have the following setup:

Asterisk 1.8.3.2
Queues are realtime
Queuemembers are realtime
FOP2.20

With in the dialplan a user can call the PauseQueuemember or UnPauseQueuemember application for his SIP device. When the member is paused or unpaused this status change is not reflected in FOP2. Also when a member unregisters or registers his state is not changed. It is only updated in fop2 when the poll_interval is reached.

I scanned the forum all ready for a solution but none found.

I debugged FOP2 with debug value 511 and following is present in the debuglines.

10.2.1.27       <- Event: QueueMemberPaused
10.2.1.27       <- Privilege: agent,all
10.2.1.27       <- Queue: test
10.2.1.27       <- Location: SIP/michelv_pc
10.2.1.27       <- MemberName: michelv_pc
10.2.1.27       <- Paused: 1
10.2.1.27       <- Server: 0

** MAIN AMI event received...
** MAIN There's an 'Event' in the event block
** MAIN Event detected block_count = 1 (Event: QueueMemberPaused)
** MAIN There are 1 blocks for processing
** MAIN Answer block cleared

** DIGEST_EVENT: start

** PROCESA_BLOQUE  0
** PROCESA_BLOQUE QUEUEMEMBERPAUSED 0

Not a reference at all

** QUEUE MEMBER LIST start
** QUEUE MEMBER LIST devuelve <div class='memberinvalid myclick' id='qm!QUEUE/TEST!SIP/michelv_desk'></div><span>michelv_desk</span><br class='clear'/><div class='memberready myclick' id='qm!QUEUE/TEST!SIP/michelv_pc'></div><span>michelv_pc</span><br class='clear'/>

Following is in the buttons.cfg file:

[QUEUE/test]
type=queue
context=
label=test

And the interface from which the PauseQueueMemeber application is initiated is SIP/michelv_pc.

Only thing I could find in the debug lines is that is says QUEUE/TEST (in uppercase) instead of QUEUE/test (lowercase) and mentions "Not a reference at all".

Regards,

Michel Verbraak

admin
22 Mar 2011 Administrator

Hi,
To see if that is actually a fop2 bug try to use a numeric queue name, example: Queue/100.
Question: are you using FOP 2.20 final?

fopmiv

23 Mar 2011

Hi Nicolás,

We use FOP2 2.20 final. (Debian 64bits)
OS is Debian Squeeze

I created a number only queue as you requested:

[QUEUE/100]
type=queue
context=
label=100

The update in the panel is still only happening when the poll_interval is reached.

Following is what I see in the debuglines (member is allready paused and I do unpause):

10.2.1.27       <- Event: QueueMemberPaused
10.2.1.27       <- Privilege: agent,all
10.2.1.27       <- Queue: 100
10.2.1.27       <- Location: SIP/michelv_pc
10.2.1.27       <- MemberName: michelv_pc
10.2.1.27       <- Paused: 0
10.2.1.27       <- Server: 0

** MAIN AMI event received...
** MAIN There's an 'Event' in the event block
** MAIN Event detected block_count = 1 (Event: QueueMemberPaused)
** MAIN There are 1 blocks for processing
** MAIN Answer block cleared

** DIGEST_EVENT: start

** PROCESA_BLOQUE  0
** PROCESA_BLOQUE QUEUEMEMBERPAUSED 0

Not a reference at all

** QUEUE MEMBER LIST start
** QUEUE MEMBER LIST devuelve <div class='memberpaused myclick' id='qm!QUEUE/100!SIP/michelv_desk'></div><span>michelv_desk</span><br class='clear'/><div class='memberpaused myclick' id='qm!QUEUE/100!SIP/michelv_pc'></div><span>michelv_pc</span><br class='clear'/>

As you can see still the same result. When you need more info I'm happy to provide it.

Regards,

Michel.

admin
24 Mar 2011 Administrator

I did several tests and it always worked, are you sure you are using 2.20 final and not a beta? The last thing to check is the sip peer name, use a numeric peer and see what happens, at least to check if this is a case issue or not. There were some case issues on past versions, but I think all of them are fixed on fop 2.20.
fopmiv
24 Mar 2011
I did some more testing and found the following solves the problem for pausing and unpausing queuemembers.
I had the following in my buttons.cfg file
```
[Local/3033@to_sip_client/n]
type=extension
extension=3033
context=from_sip_client
label=Michel Verbraak
channel=SIP/michelv_pc
channel=SIP/michelv_desk

[QUEUE/100]
type=queue
context=
label=100
```
Without a separate extension button for each channel line of the extension button Local/3033@to_sip_client/n.
When I added the following extension button to this file:
```
[SIP/michelv_pc]
type=extension
extension=michelv_pc
context=from_sip_client
label=michelv_pc
```
The FOP2 panel now follows in real time the queuemember status in the queue/100 panel and the extension button michelv_pc when I pause or unpause this extension. The status is not reflected in the Local/3033@to_sip_client/n extension button (this might be a feature request).
Following problem this exists:
When I unregister or register this extension michelv_pc the status does not change of the icon in the QUEUE/100 panel, only after the poll interval, but the status is changed in real time for the extension button in the FOP@ panel.
Regards,
Michel.
admin
24 Mar 2011 Administrator
Hi Michael,
Local channels are not tracked as real channel buttons. They are not real devices and for that reason it is not sane to track them. The AMI is not consistent in any way, so FOP2 treats them like what they are, a kind of proxy channel to reach a real device (or an application, but fop2 does not track applications). Only real devices are tracked in fop2 (with the exception of USER type buttons for the user & device mode in FreePBX, where ). Local channel are troublesome in so many aspects that fop2 will only display activity on the real device button when a local to device mapping event is received.
Not sure why you are trying to use Local as the main channel, in any case, try by removing the /n and see if that makes any difference. But what you really want to do is something like:
```
[SIP/michelv_pc]
type=extension
extension=3033
context=from_sip_client
label=Michel Verbraak
channel=SIP/michelv_desk
```
There is no need and no real point on specifying the Local proxy channel in the config.
As per registration status, that status is for a sip device, not for a queue member. You might see it as related, but they are really not. A queue does not really care if the sip peer is registered or not, even more so if you use local type queue members. There are no AMI queue events that show a queue member registration/qualify status.
Best regards,
fopmiv
26 Mar 2011

hi,
I changed the local to a sip one.
The situation we have is that a person has a personal number but could have multiple devices, sipphone+dect2sip+smartphone+pc, to ring when his personal number is dialed.
I wanted only one extension button per person which signals the multiple devices this person has. I thought I had this solved by adding channel lines to the extension button with a category name Local/..... As you said this category name was not smart and I changed it to a category name SIP/<device1>.
This person is also part of a queue. So we add al his devices to the queue and make his membername the same for all the devices. He only shows up once in the queue panel of fop2.
We also have one pause or unpause extension in the dialplan. When the person dials this number from any one of his devices he will pause or unpause all his devices. Because we first had only the Local/..... button the status icon did not change. When I change the button to a SIP/<device1> button the status did change.
Currently I have per device an extension button in buttons.cfg. This fixed the problem for the realtime updating of the pause and unpause status in the queue panel. So when a person has two devices he has two buttons.
I think it would be better if FOP2 when it sees a pause or unpause queue member event in the ami it does not only try to match it to an extension button but also to the devices/interfaces it has seen for queues.
Other problem:
When a device unregisters and the poll_interval is reached the icon for this member in the queue changes from available (green person) to unavailable (green person with little red and white sign in lower right corner). This does not happen realtime. A queue does care if a person is available or unavailable. When a device (SIP/xxx) unregisters it becomes unavailable in the queues if a member of the queue has it as its interface and when a call is placed into that queue asterisk will not try to dial that unavailable interface.
Your program is great but it would be better if it could handle before mentioned situations better.
Regards,
Michel.
admin
26 Mar 2011 Administrator

Michael,
What you want to do is not standard, fop2 should work in the more standard way possible. What you can do is try to replicate the user&device mode for FreePBX, where you define buttons as
USER/XXXX
And then have two types of astdb entries for relating users with real devices. And also you fire userevents if a user is logged in or logged out from the system. This mode in freepbx is also a "hack" or a "non standard" way of doing things. I am saying it is non standard because you are working it out OUTSIDE of native asterisk applications, and using some kind of dialplan hack. Dialplan hacks are not trackable via AMI.
I do not remember from memory the particularities of User & Device mode, you have the AMPUSER db entries, with the user/extension number, and then the DEVICE entries, with the "dial" value set to the real devices associated with the user, like SIP/4000&SIP/4001
There are things that are not going to work as you expect when you monitor multiple devices in one button, It is just plain NOT POSSIBLE to track them as you would expect. Suppose you have two real devices updating one button, one of them is registered and the other is not. What do you expect the button to show? Registered ? Unregistered ? FOP2 will honor the last status received, and that will be at least confusing.
In your case, if you have more than one device per user/extension, I would expect that device to be reached by dialing the same number, and having just one queue member for it using Local/that-unique-number. Having queue members for every device does not seem correct to me, it will lead to queue_log pollution, the queue application trying to deal with lots of members that are not really needed.
Not sure how you know on what device a user is really logged into, or if it uses several devices at the same time, a kind of followme scenario, but just ONE Local/xxxx queue member is the more correct way to handle it (imho).
Best regards,