No response from action QueueAdd

[open-dynaMIX]

When sending the action QueueAdd I get no response and it just hangs.

I was able to fix this with overriding Action and removing the lines 64 & 65:

        elif msg.startswith('added') and msg.endswith('to queue'):
            return True

from def multi().

I'm not sure, if this breaks other functionality though.

Asterisk 13.16.0

[gawel]

I dont think removing those line is a good idea. You'd rather track the msg and add the right condition

[ludovic-gasc]

Hi @open-dynaMIX, we are aware about this problem with the latest version of Asterisk.
We have planned to fix that next month. If you have time to do that before us, be my guest ;-)
@gawel has right, it isn't a good idea to remove that, it used to detect the end of a multi-event command.

If you have time to take a trace with tcpdump on port 5038 when you launch this command and share here, it will be easier to fix.

[open-dynaMIX]

Hi @gawel and @GMLudo

Thanks for your responses!

I absolutely agree, that removing those lines is not a fix, but rather a temporary hack for me, to get the functionality I need atm.

Here you can find the tcpdump from performing this action in the telnet console:
ami.pcap.tar.gz

This is the console output:

Action: QueueAdd
Queue: 921
Interface: Local/11@from-queue/n

Response: Success
Message: Added interface to queue

Event: QueueMemberAdded
Privilege: agent,all
Ringinuse: 1
Penalty: 0
StateInterface: Local/11@from-queue/n
PausedReason: 
Queue: 921
MemberName: Local/11@from-queue/n
Interface: Local/11@from-queue/n
Membership: dynamic
CallsTaken: 0
InCall: 0
LastCall: 0
Status: 1
Paused: 0

Event: DeviceStateChange
Privilege: call,all
Device: Queue:921_avail
State: NOT_INUSE

I hope this helps.

Thank you very much for providing this library!

[ludovic-gasc]

Hi @open-dynaMIX,

I'm in a bus right now, complicated to test.
However, if you replace the line of code you have removed by:

elif msg.lower().startswith('added') and msg.endswith('to queue'):
            return True

You might have some chance that it will run again automagically ;-)

Interested in by your feedback.

[open-dynaMIX]

Thank you @GMLudo for the suggestion, but this can't have any effect, because: msg = resp.message.lower().

This is the whole method in master:

    @property
    def multi(self):
        resp = self.responses[0]
        msg = resp.message.lower()
        if resp.subevent == 'Start':
            return True
        elif 'EventList' in resp and resp['EventList'] == 'start':
            return True
        elif 'will follow' in msg:
            return True
        elif msg.startswith('added') and msg.endswith('to queue'):
            return True
        elif msg.endswith('successfully queued') and self.async != 'false':
            return True
        elif self.as_list:
            return True
        return False

[ovv]

After looking at this it seems to be a bug in multi messaging with QueueAdd and Originate actions. For Originate no OriginateResponse is received. This is either a bug in asterisk or a bad configuration. We will contact asterisk.

In the meantime I suggest you add a condition in def multi so that panoramisk doesn't wait for an event that isn't comming.

    @property
    def multi(self):
        resp = self.responses[0]
        msg = resp.message.lower()
        if resp.subevent == 'Start':
            return True
        elif 'EventList' in resp and resp['EventList'] == 'start':
            return True
        elif 'will follow' in msg:
            return True
        elif msg == 'added interface to queue':
            return False
        elif msg.startswith('added') and msg.endswith('to queue'):
            return True
        elif msg.endswith('successfully queued') and self.async != 'false':
            return True
        elif self.as_list:
            return True
        return False

[open-dynaMIX]

Thank you @ovv. I can confirm that it's working that way.

[gawel]

PR has been merged a while ago. I guess this can be closed

[open-dynaMIX]

Hi!

Finally I was able to test version 1.2 today, but unfortunately the problem seems to persist.

Thanks a lot for looking into this!

[starlessboi]

Hi
I have the same problem, did the problem solved?
I am using latest stable version

[gawel]

Looks like it's not

[open-dynaMIX]

I'm not working on this project anymore, so I'm not able to help much.

But I did get it working with the suggestion from this comment.

[starlessboi]

Hi
I did it working with that change, but I want to know if it has been merged to master or 1.3 release..I think it is not?

[gawel]

Nope, I thought it was fixed with another way in the PR

The weird thing is that it seems that there is no ActionID when you send a QueueAdd (when looking at the trace). panoramisk is supposed to always send one to be able to follow responses

[gawel]

Instead of trying to handle weird/buggy cases, is it ok to add a follow argument to send_action ?

Means that send_action(... follow=False) will just send and forget the action

Another option seem to use the Queue id to follow responses but this is much more tricky...

[ldo]

It seems to me you shouldn’t be including events as part of the response to an action. I think if you tell Asterisk that you don’t want events on the connection, then you won’t get them anyway.

So, to me, that initial proposed fix seems right: QueueAdd is not a multi-response action, so take out that “added to queue” message match for identifying a multi-response situation. And similarly with Originate.

Events should be handled separately, independent of responses to actions. Because remember, you can get events that are triggered by actions requested by other clients of the same Asterisk server.