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.