[Freeswitch-users] Getting call leg details

[Steven Ayre]

On 15 September 2010 10:05, Nigel Kent <ktngl at yahoo.co.uk> wrote:

>
> Thanks for the  info, I have a few further questions
>
> Is it on the execution of the bridge that generates the
> CHANNEL_HANGUP_COMPLETE for the first leg.
>

No, it's after the channel hangs up (CHANNEL_HANGUP being sent when it
starts to hang up).
If the caller on the A-leg initiates the hangup, then the B-Leg will hangup
when the A-Leg hangs up.
If the callee on the B-leg initiates the hangup, then the A-Leg will either
hangup (if hangup_on_bridge=true) or return to the dialplan and hangup when
it has no more applications to run.

If you want to know when the bridge starts/finishes look for CHANNEL_BRIDGE
and CHANNEL_UNBRIDGE.


> If so how does it carry the call on to the second leg because I thought
> that CHANNEL_HANGUP_COMPLETE is sent after a call disconnected.
>

It is sent then. Not sure I understand what you mean by 'carry the call on'?

-Steve




>
>
>
> --- On *Sun, 12/9/10, Steven Ayre <steveayre at gmail.com>* wrote:
>
>
> From: Steven Ayre <steveayre at gmail.com>
> Subject: Re: [Freeswitch-users] Getting call leg details
> To: "FreeSWITCH Users Help" <freeswitch-users at lists.freeswitch.org>
> Date: Sunday, 12 September, 2010, 21:43
>
>
> Both the A-Leg and B-Leg will generate a CHANNEL_HANGUP_COMPLETE event.
> Each will have a different UUID so you'll only get both events if you're
> watching both/all UUIDs.
>
> On 12 September 2010 20:53, Nigel Kent <ktngl at yahoo.co.uk<http://mc/compose?to=ktngl@yahoo.co.uk>
> > wrote:
>
> I have a event socket listener that catches CHANNEL_HANGUP_COMPLETE events
> and I want to verify the call leg details
>
> 1. Did the call end in aleg or bleg
>
>
> Check variable_sip_hangup_disposition. Values will be recv_bye, send_bye or
> cancel. Not sure how to do it if you have something other than sofia on
> either leg.
> How to interpret the value probably depends on whether it's on the A or B
> leg.
>
>
>
> 2. What was the call durations in each of the legs
>
>
> Check variable_duration
>
> http://wiki.freeswitch.org/wiki/Event_list#CHANNEL_HANGUP_COMPLETEcontains an example of the event which will be generated, and includes many
> of the channel variables, including several useful timestamp and durations.
> For example there are timestamps for the call starting, ringing (progress),
> answered, and hangup, and a billsec variable as well as the duration (which
> should be the same in almost all cases).
>
>
>
> I am not sure if I am applying the terminology of call legs in the proper
> way but
> what I mean by aleg is that the incoming call was not bridged and bleg
> after being bridged
>
>
> That's the correct terminology. :)
>
> -Steve
>
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org<http://mc/compose?to=FreeSWITCH-users@lists.freeswitch.org>
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
>
> -----Inline Attachment Follows-----
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org<http://mc/compose?to=FreeSWITCH-users@lists.freeswitch.org>
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100915/2747de53/attachment-0001.html