[Freeswitch-users] Getting call leg details

Wed Sep 15 11:15:48 PDT 2010

Thanks that's helpfull informatiom. I am going do some  practical test now

--- 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, 17:04

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>
 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> 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_COMPLETE contains 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://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://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

-----Inline Attachment Follows-----

_______________________________________________
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

_______________________________________________

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

-----Inline Attachment Follows-----

_______________________________________________
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/d0be6fa4/attachment.html 