It’s an unusual thing to do. How are you using the information?
I can only suggest working backwards and looking at the device status directly, initially using CLI commands, to make sure it is actually available at that level, and maybe looking into reading it directly with AMI. However, I don’t think I’m going to spend any more time on the code to work out exactly how that handles it.
I checked on the asterisk CLI the device state of the queue member is “inuse” as that member is talking to caller. My point here is when agent has put callers call on hold from his end why queue member's device state is not changing to HOLD from INUSE
Here, what i have tried to replicate the same on local demo setup i could see the device which i am communicating “to” is showing “ONHOLD” but the queue member who is putting call on hold, it’s device state is “INUSE”.
What could be the possible reason for such a behavior?
There is “Hold” event in AMI but our Real time monitoring system is capturing members runtime status by sending AMI Actions and in which we could not identify which agent(queue member) has put caller on hold.
Is there a way by which i can put both the channels on HOLD?
I did wonder if that was the case, but I couldn’t find it documented, one way or the other, and, as noted above, didn’t want to delve too far into the actual code.
If you know the channel name, then you can do core show channel PJSIP/555-1234 on the Asterisk CLI to get the Streams info at the bottom of the output. The State will be sendonly if the channel is on hold. I don’t think there is (yet) any AMI for stream state status query…
Another Asterisk application you might consider is BridgeWait - like a smarter version of HOLD. Since you control the frontend via JsSIP, you could test a new button that redirects the channels using a DTMF code sequence from features.conf