[bug]: queue_log + virtual agent + bridge broke all about asterisk HOT 8 OPEN

Okay. As I said, this issue is now open.

from asterisk.

This is the Asterisk project, not the FreePBX project. Issues involving FreePBX should be filed with FreePBX first to ensure it is not as a result of FreePBX. If afterwards it is determined that there is an issue in Asterisk then it can be opened with Asterisk.

from asterisk.

@jcolp a bug in the code of answering the call and dialing the device when duplicating the device . Secondly, if you remember me, I used to contribute patches and was even in the top of the comments. I know how the asterisk works inside. I have not looked at the code, but most likely the error is that because of two parallel responses, the bridge application is replaced by a 4+ part version, and this module is buggy with the work of queues and with the state system. FreePBX allowed you to create a configuration with such a case, but you have a bug in the modules, you do not need to translate the arrows.

from asterisk.

I still don't understand. I'll leave this open though.

from asterisk.

I can say, though, that if a Local channel is involved then the Queue application has no idea that transfers occur. Changing this is architecturally difficult.

from asterisk.

@jcolp 1. Why, if 2 calls are answered at the same time, a conference is created,? Why is it that when one call is clearly drop off by the device, then it remains hanging in the system? Why doesn't the channel roll back to SIMPLE mode after all this? Why is a conf channel allowed to be added to the queue app if it puts queue metrics and is not workable? As a workaround, I would split the channels into simple ones and add PCs separate, or wrap them in another simple bridge so that there is always a point-to-point connection supported in app queue.

from asterisk.

There are no such things as conference channels, or simple mode or simple channels, in Asterisk. Channels are channels. Local channels behave differently and have two channels to work within threading requirements. One channel can be transferred elsewhere, while the other channel remains.

If you want to try to improve the specific scenario with them and app_queue feel free.

from asterisk.

@jcolp Again. I see TWO answers in CAL. Cisco hone i have ONE active call (no holds and second line usages). Asterisk don't see second channel halt. Its race condition bug because 50/50 chance to this side effect. Some time astyerisk see first answered call and drip second. But some time its its bridge tru channels (and dead also) but from docs it must save only first answered c channel on multipole dial string./ / Ш I think somewhere deadlock or race becouse asterisk gett 2 events in ope time for one common call in separate threads. I believe this good oint for check race logic!

from asterisk.