anyone ? :=) On 30 May 2017 at 14:40, Tihomir Culjaga <tculjaga@gmail.com> wrote:
Hello,
There is something that is bugging me pretty hard and i need to understand how variable_originated_legs in CHANNEL_HANGUP gets populated ?
example:
variable_originated_legs: ARRAY::faf71922-4526-11e7-b0f4-9fb65fdc7341;Outbound Call;888|:faf71922-4526-11e7-b0f4-9fb65fdc7341;Outbound Call;888|:faf76c56-4526-11e7-b0fd-9fb65fdc7341;Outbound Call;0916331550",
the reason :=)
i have a scenario like this:
1. Incoming calls (IN_CALL) are sent to PARK application 2. On CHANNEL_PARK i originate a call to an extension say EXT1
e.g. originate {ogirination_uuid=<ext1_uuid>}user/1002 & park() ... and eventually i do uuid_bridge <in_call_uuid> <ext1_uuid>
3. EXT1 makes a call transfer to EXT2 (using att_xfer) and hangs up the call 4. on CHANNEL_HANGUP from EXT1 i learn EXT2 uuid and.,,, IN_CALL is talking to EXT2 and we are happy :=)
... this is all good if the transfer destination is a single extension (i get enough info from signal_bond etc...). But if i have multiple destination behind EXT2 e.g. user/1002,user/1003,sofia/gateway/gw1/012345 the thing gets complicated.
I was hoping i could exploit variable_originated_leg in CHANNEL_HANGUP from EXT1 to learn all origination legs uuid after an att_xfer to a multiple destination.
is that feasible ? I mean, will this variable contain all UUIDs att_xfer generated on a multi-destination transfer ?
please i would appreciate any heads up here :=)
thanks, Tihomir.