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.
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" />
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.