[Freeswitch-users] Getting call leg details

Steven Ayre steveayre at gmail.com
Wed Sep 15 10:04:20 PDT 2010


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

> I think I am undertaning better now what you said.
>
> For a call( connected between both ends) that gets disconnected there will
> be seperate hang up events genereated, one from each leg and each leg has
> its own UUID
>

Yes, that's correct. Each leg is a separate channel which are really
separate calls from the caller to freeswitch, and from freeswitch to the
caller. Each has it's own UUID and events. You join the two together by
bridging them, at which point their signalling and media are joined
together.


> In that case I understand the incoming is assigned a UUID as soon as it
> comes in.
>

Yes. The UUID is assigned as soon as the channel is created.


> In regards to my original needs in identifity the legs, I am thinking I
> could set a channel variable to indicate the leg. This could be done as soon
> as the call is anwsered for the a leg.
>

This already exists. There is a direction variable which will be set to
inbound on the A-leg and outbound on the B-leg. AFAIK it exists as soon as
the channel is created.


>
> So now I am trying to work out how to access the b leg variables?
>

The variables will be in the CHANNEL_HANGUP_COMPLETE event for the B-Leg. If
you want variable_sip_hangup_disposition you only need it for one of the
legs:

A-Leg:
cancel : caller hung up before the call was answered
recv_bye : was answered, caller (aleg) hung up
send_bye : was answered, callee (bleg) hung up

B-Leg (bye direction swapped compared to aleg)
cancel : caller hung up before the call was answered
recv_bye : was answered, callee (aleg) hung up
send_bye : was answered, caller (bleg) hung up

-Steve


>
> --- On *Wed, 15/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: Wednesday, 15 September, 2010, 12:24
>
>
>
>
> On 15 September 2010 10:05, Nigel Kent <ktngl at yahoo.co.uk<http://mc/compose?to=ktngl@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<http://mc/compose?to=steveayre@gmail.com>
> >* wrote:
>
>
> From: Steven Ayre <steveayre at gmail.com<http://mc/compose?to=steveayre@gmail.com>
> >
> Subject: Re: [Freeswitch-users] Getting call leg details
> To: "FreeSWITCH Users Help" <freeswitch-users at lists.freeswitch.org<http://mc/compose?to=freeswitch-users@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://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/ba6213af/attachment-0001.html 


More information about the FreeSWITCH-users mailing list