[Freeswitch-users] originated_legs

[Tihomir Culjaga]

anyone ? :=)

On 30 May 2017 at 14:40, Tihomir Culjaga <tculjaga at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20170601/40c0bca1/attachment.html>