Ok. I understand your point.<br><br>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 ).<br>
<br>May I know What you want to do when LEB B is answered??, so that I can suggest better ways.<br><br><br><br><div class="gmail_quote">On Thu, Aug 12, 2010 at 1:00 PM, Ali R. <span dir="ltr"><<a href="mailto:aroumie@yahoo.com">aroumie@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Thank you so much for your response!<br>
I have not tried what you suggested but don’t you think sending the command<br>
"events plain all" on an outbound socket creates lots of overhead on my app<br>
and the FS event socket module? <br>
Correct me if I'm wrong, in outbound socket mode FS spawns a new socket<br>
connection for each Leg A into my listening server ? Also if I pass<br>
"events plain all" or the other handy command "events xml all" on each<br>
socket, FS will push the same TCP stream over all connected sockets. <br>
For example, if I got 50 connected Leg A, FS will push the same event 50<br>
times to my listening socket? My app is very sensitive to bandwidth and<br>
that's the reason I set the filter to just filter out the events that are<br>
sufficient<br>
for my application logic.<br>
I'm still experiencing with FS and I might be wrong.<br>
<br>
P.S: Regarding my issue, I noticed when Leg B is answered the fs_cli logs this<br>
event and that's the one I'm looking for at my end point socket.<br>
Thanks,<br>
Ali,<br>
<br>
<br>
<br>
________________________________<br>
From: lakshmanan ganapathy <<a href="mailto:lakindia89@gmail.com">lakindia89@gmail.com</a>><br>
To: <a href="mailto:freeswitch-dev@lists.freeswitch.org">freeswitch-dev@lists.freeswitch.org</a><br>
Sent: Wed, August 11, 2010 9:24:32 PM<br>
Subject: Re: [Freeswitch-dev] Socket - bridge answered event<br>
<div><div></div><div class="h5"><br>
Hi<br>
<br>
You register for myevents only.<br>
So you will receive events only for LEG A.<br>
Just try<br>
events plain all<br>
<br>
<br>
<br>
<br>
<br>
On Wed, Aug 11, 2010 at 8:00 AM, Ali Roumie <<a href="mailto:aroumie@yahoo.com">aroumie@yahoo.com</a>> wrote:<br>
<br>
Hello All,<br>
>This is my first post to this list and many thanks to all contributors to this<br>
>state of art project. I'm using outbound socket and everything is going<br>
>wonderful with me except one thing so far.<br>
>My logic is simple, collect a PIN from Leg A and once the PIN is authorized, I<br>
>bridge the call with a SIP provider. Everything is great, call got bridged<br>
>successfully (and I was supper exited when it worked) but my problems is FS is<br>
>not sending my socket an event when the Leg B is answered. I get an event only<br>
>when Leg B is hangup. I must mention, I set filters on the socket to avoid<br>
lots<br>
>of the many generated events by FS<br>
>Here is my command list on the socket.<br>
> <br>
>connect<br>
>myevents<br>
>filter Event-Name CHANNEL_ANSWER<br>
>filter Event-Name CHANNEL_CREATE<br>
>filter Event-Name CHANNEL_EXECUTE_COMPLETE<br>
>filter Event-Name CHANNEL_BRIDGE<br>
>filter Event-Name CHANNEL_UNBRIDGE<br>
>filter Event-Name CHANNEL_HANGUP<br>
>sendmsg<br>
>call-command: execute<br>
>execute-app-name: answer<br>
>sendmsg<br>
>call-command: execute<br>
>execute-app-name: sleep<br>
>execute-app-arg:1000<br>
>event-lock:true<br>
>sendmsg<br>
>call-command: execute<br>
>execute-app-name: play_and_get_digits<br>
>execute-app-arg:2 5 3 5000 # ivr/ivr-please_enter_pin_followed_by_pound.wav<br>
>ivr/ivr-please_reenter_your_pin.wav chanDTMF ^\d{5}$<br>
>event-lock:true<br>
>sendmsg<br>
>call-command: execute<br>
>execute-app-name: bridge<br>
>execute-app-arg:[sip_auth_username=XXXX,sip_auth_password=*******]sofia/internal/<a href="mailto:123456789@PROVIDER.COM">123456789@PROVIDER.COM</a><br>
><br>
><br>
><br>
><br>
>event-lock:true<br>
> <br>
>Many Thanks,<br>
>Ali R.<br>
><br>
><br>
><br>
><br>
>_______________________________________________<br>
>FreeSWITCH-dev mailing list<br>
><a href="mailto:FreeSWITCH-dev@lists.freeswitch.org">FreeSWITCH-dev@lists.freeswitch.org</a><br>
><a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
>UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
><a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
><br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
FreeSWITCH-dev mailing list<br>
<a href="mailto:FreeSWITCH-dev@lists.freeswitch.org">FreeSWITCH-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br>