Hello,
I'm looking for this event (LEG B CHANNEL_ANSWER) just to update a UI.  Right now, I'm shifting my logic to use the inbound mode where I see all events including when Leg B is answered.
Thanks Again


From: lakshmanan ganapathy <lakindia89@gmail.com>
To: freeswitch-dev@lists.freeswitch.org
Sent: Thu, August 12, 2010 12:44:03 AM
Subject: Re: [Freeswitch-dev] Socket - bridge answered event

Ok. I understand your point.

One more way is, when the LEG B answers the call, you will get CHANNEL_BRIDGE event in the A LEG. There you will have all the informations regarding the LEG B ( including the UUID of the LEG B ).

May I know What you want to do when LEB B is answered??, so that I can suggest better ways.



On Thu, Aug 12, 2010 at 1:00 PM, Ali R. <aroumie@yahoo.com> wrote:
Thank you so much for your response!
I have not tried what you suggested but don’t you think sending the command
"events plain all" on an outbound socket creates lots of overhead on my app
and the FS event socket module? 
Correct me if I'm wrong, in outbound socket mode FS spawns a new socket
connection for each Leg A into my listening server ? Also if I pass
"events plain all" or the other handy command "events xml all" on each
socket, FS will push the same TCP stream over all connected sockets. 
For example, if I got 50 connected Leg A, FS will push the same event 50
times to my listening socket?  My app is very sensitive to bandwidth and
that's the reason I set the filter to just filter out the events that are
sufficient
for my application logic.
I'm still experiencing with FS and I might be wrong.

P.S: Regarding my issue, I noticed when Leg B is answered the fs_cli logs this
event and that's the one I'm looking for at my end point socket.
Thanks,
Ali,



________________________________
From: lakshmanan ganapathy <lakindia89@gmail.com>
To: freeswitch-dev@lists.freeswitch.org
Sent: Wed, August 11, 2010 9:24:32 PM
Subject: Re: [Freeswitch-dev] Socket - bridge answered event

Hi

You register for myevents only.
So you will receive events only for LEG A.
Just try
    events plain all





On Wed, Aug 11, 2010 at 8:00 AM, Ali Roumie <aroumie@yahoo.com> wrote:

Hello All,
>This is my first post to this list and many thanks to all contributors to this
>state of art project. I'm using outbound socket and everything is going
>wonderful with me except one thing so far.
>My logic is simple, collect a PIN from Leg A and once the PIN is authorized, I
>bridge the call with a SIP provider. Everything is great, call got bridged
>successfully (and I was supper exited when it worked) but my problems is FS is
>not sending my socket an event when the Leg B is answered.  I get an event only
>when Leg B is hangup.  I must mention, I set filters on the socket to avoid
lots
>of the many generated events by FS
>Here is my command list on the socket.
> 
>connect
>myevents
>filter Event-Name CHANNEL_ANSWER
>filter Event-Name CHANNEL_CREATE
>filter Event-Name CHANNEL_EXECUTE_COMPLETE
>filter Event-Name CHANNEL_BRIDGE
>filter Event-Name CHANNEL_UNBRIDGE
>filter Event-Name CHANNEL_HANGUP
>sendmsg
>call-command: execute
>execute-app-name: answer
>sendmsg
>call-command: execute
>execute-app-name: sleep
>execute-app-arg:1000
>event-lock:true
>sendmsg
>call-command: execute
>execute-app-name: play_and_get_digits
>execute-app-arg:2 5 3 5000 # ivr/ivr-please_enter_pin_followed_by_pound.wav
>ivr/ivr-please_reenter_your_pin.wav chanDTMF ^\d{5}$
>event-lock:true
>sendmsg
>call-command: execute
>execute-app-name: bridge
>execute-app-arg:[sip_auth_username=XXXX,sip_auth_password=*******]sofia/internal/123456789@PROVIDER.COM
>
>
>
>
>event-lock:true
> 
>Many Thanks,
>Ali R.
>
>
>
>
>_______________________________________________
>FreeSWITCH-dev mailing list
>FreeSWITCH-dev@lists.freeswitch.org
>http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>http://www.freeswitch.org
>






_______________________________________________
FreeSWITCH-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org