[Freeswitch-users] originated_legs

[Tihomir Culjaga]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170530/f95a03dd/attachment.html>