Than you Antony, <div>waiting the completition of "pre_anser" before bridging (CHANNEL_PROGRESSING_MEDIA event from legA) and with a correct uuid order in the "uuid_bridge" all works fine.</div><div><div>
<br></div><div>Stephen <br><br><div class="gmail_quote">On Tue, Feb 22, 2011 at 3:42 AM, Anthony Minessale <span dir="ltr"><<a href="mailto:anthony.minessale@gmail.com">anthony.minessale@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">If you bridge them, the bridge app will already pass the answer for<br>
you when the B leg is answered.<br>
If you are seeing that message it means you are supplying the uuid in<br>
reverse order where the A leg is not the one with media.<br>
<br>
That reversing the order message can only be true if you pass a leg<br>
with media as the 2nd leg and one without as the 1st to uuid_bridge.<br>
<br>
When you pre_answer the A leg, do you wait for it to actually happen<br>
before you call bridge?<br>
sendmsg execute only queues the app to be executed, you need to get<br>
the event confirming it actually happened before you can be sure it<br>
did.<br>
<br>
Try adding the header<br>
<br>
async: true<br>
<br>
to your sendmsg to indicate you want to execute the app instantly and<br>
wait for it to finish.<br>
<div><div></div><div class="h5"><br>
<br>
<br>
On Mon, Feb 21, 2011 at 5:39 PM, Stephen Wilde <<a href="mailto:wstephen80@gmail.com">wstephen80@gmail.com</a>> wrote:<br>
> I'm running an esl socket outbound application and I have a systematic<br>
> problem: in a particular situation, the execution of answer on incoming call<br>
> has no effect.<br>
> This happens always when (and only in this case):<br>
> 1. an incoming call is received (legA) and via dialplan I send the call to<br>
> my socket outbound application<br>
> 2. I make an outbound call with originate (legB)<br>
> 3. I receive a CHANNEL_PROGRESS_MEDIA on legB<br>
> 4. I do a "pre_answer" on legA<br>
> 5, I do a "uuid_bridge" between legA and legB<br>
> in this phase, legA can hear the progress tone coming from legB (an in-band<br>
> ringback)<br>
> 5. legB answer the call and I receive a CHANNEL_ANSWER on legB<br>
> 6. I do an execute of "answer" on legA<br>
> This "answer" has no effect!<br>
> I do both pre_answer and answer specifying the UUID parameter (sendmsg<br>
> <uuid>), obviously using legA uuid .<br>
> I do the bridge specifying inbound uuid as first parameter and outbound uuid<br>
> as second parameter: uuid_bridge <inbound_uuid> <outbound_uuid><br>
> In fs_cli I see: [WARNING] switch_ivr_bridge.c:1412 reversing order of<br>
> channels so this will work!<br>
> To me it seems that in uuid_bridge is done an inversion with my<br>
> inbound/outbound channels and because I do an answer to the incoming uuid,<br>
> probably (due to the inversion) is treated as outbound so the answer is<br>
> ignored.<br>
> Attached to this email the .pcap file related to tcp traffic between<br>
> Freeswitch and my socket outbound application where at time 8.562639 there<br>
> is my sendmsg with the answer.<br>
> Stephen<br>
</div></div>> _______________________________________________<br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Anthony Minessale II<br>
<br>
FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>
ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire" target="_blank">http://twitter.com/FreeSWITCH_wire</a><br>
<br>
AIM: anthm<br>
<a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a> #freeswitch<br>
<br>
FreeSWITCH Developer Conference<br>
<a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:+19193869900<br>
<br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br></div></div>