[Freeswitch-users] ESL socket outbound: the execution of answer has not effect

Stephen Wilde wstephen80 at gmail.com
Tue Feb 22 17:18:15 MSK 2011


Than you Antony,
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.

Stephen

On Tue, Feb 22, 2011 at 3:42 AM, Anthony Minessale <
anthony.minessale at gmail.com> wrote:

> If you bridge them, the bridge app will already pass the  answer for
> you when the B leg is answered.
> If you are seeing that message it means you are supplying the uuid in
> reverse order where the A leg is not the one with media.
>
> That reversing the order message can only be true if you pass a leg
> with media as the 2nd leg and one without as the 1st to uuid_bridge.
>
> When you pre_answer the A leg, do you wait for it to actually happen
> before you call bridge?
> sendmsg execute only queues the app to be executed, you need to get
> the event confirming it actually happened before you can be sure it
> did.
>
> Try adding the header
>
> async: true
>
> to your sendmsg to indicate you want to execute the app instantly and
> wait for it to finish.
>
>
>
> On Mon, Feb 21, 2011 at 5:39 PM, Stephen Wilde <wstephen80 at gmail.com>
> wrote:
> > I'm running an esl socket outbound application and I have a systematic
> > problem: in a particular situation, the execution of answer on incoming
> call
> > has no effect.
> > This happens always when (and only in this case):
> > 1. an incoming call is received (legA) and via dialplan I send the call
> to
> > my socket outbound application
> > 2. I make an outbound call with originate (legB)
> > 3. I receive a CHANNEL_PROGRESS_MEDIA on legB
> > 4. I do a "pre_answer" on legA
> > 5, I do a "uuid_bridge" between legA and legB
> > in this phase, legA can hear the progress tone coming from legB (an
> in-band
> > ringback)
> > 5. legB answer the call and I receive a CHANNEL_ANSWER on legB
> > 6. I do an execute of "answer" on legA
> > This "answer" has no effect!
> > I do both pre_answer and answer specifying the UUID parameter (sendmsg
> > <uuid>), obviously using legA uuid .
> > I do the bridge specifying inbound uuid as first parameter and outbound
> uuid
> > as second parameter: uuid_bridge <inbound_uuid> <outbound_uuid>
> > In fs_cli I see:  [WARNING] switch_ivr_bridge.c:1412 reversing order of
> > channels so this will work!
> > To me it seems that in uuid_bridge is done an inversion with my
> > inbound/outbound channels and because I do an answer to the incoming
> uuid,
> > probably (due to the inversion) is treated as outbound so the answer is
> > ignored.
> > Attached to this email the .pcap file related to tcp traffic between
> > Freeswitch and my socket outbound application where at time 8.562639
> there
> > is my sendmsg with the answer.
> > Stephen
> > _______________________________________________
> > 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
> >
> >
>
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
> Twitter: http://twitter.com/FreeSWITCH_wire
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org
> googletalk:conf+888 at conference.freeswitch.org
> pstn:+19193869900
>
> _______________________________________________
> 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/20110222/ef803001/attachment.html 


More information about the FreeSWITCH-users mailing list