[Freeswitch-users] Multiple endpoints bridge issue

['Yemi Obembe]

I totally understand that it should cancel all others. If Call A comes in and rings across user/xxxxx1,user/xxxxx2,user/xxxxx3 and xxxxx1 picks, I know ~2 and ~3 should be dropped. What I'd assume is that if Call B comes in (as Call A is engaged to xxxxx1), xxxxx2 and xxxxx3 should also be able to pick as they are available. As it is now, Call B will ring on them, but once they pick, as long as an existing call (A) exists, Call B drops. In other words, there can't be concurrent calls on the system.
(What I am trying to create is a call center system where multiple agents can be engaged with different calls at the same time).


Bridge is not a conferencing app.
Bridge is used, normally within a dial plan to link an incoming a-leg call to an outgoing b-leg which is created to the endpoint’s specified in the bridge command. 
So the behaviour your experiencing is correct when specifying multiple endpoints, as soon as an endpoint/user answers the call the bridge command cancels all others.


On 21 Jul 2017, at 13:04, 'Yemi Obembe <fickledreams at yahoo.com> wrote:




I am using bridge via mod_httapi to call multiple endpoints via an xml response like this:




<document type="text/freeswitch-httapi"><work>

<execute application="bridge" data="user/xxxxx1,user/xxxxx2,user/xxxxx3" />

</work></document>




What I notice is that this works for one or two connected endpoints. But once there are three or four endpoints, other incoming calls drop. I changed to enterprise originate (i.e, :_:) and noticed that once a call is engaged, other calls don't come in till that one ends. Same if I separate users with pipe (user/xxxxx1|user/xxxxx2|user/xxxxx3). Even when I bridge just a user at time, <execute application="bridge" data="user/xxxxx1" /> the other calls drop once one is engaged.




What am I missing?




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170722/04d5341e/attachment.html>