[Freeswitch-users] Oubound ESL: unbridge

[Peter Olsson]

Are you using event-lock when executing the bridge from ESL as well?
event-lock means it won't handle any more events until that application is
finished.

/Peter


2014-04-24 15:28 GMT+02:00 Grant Bagdasarian <GB at cm.nl>:

> Hello,
>
>
>
> I've managed to bridge the call and return the control back to my
> application for monitoring and further control. All using async.
>
> When the call is bridged (third party answered) and I try to send another
> event to freeswitch, nothing happens.
>
>
>
> This is the event I'm sending to FS:
>
>
>
>             string legArguments = string.Format("{0} {1} {2}",
> inboundChannel.UUID, ServiceConfiguration.WelcomePrompt, "both");
>
>
>
>             ESLevent uuidBroadcastEvent = new ESLevent("sendmsg",
> inboundChannel.UUID);
>
>             uuidBroadcastEvent.AddHeader("call-command", "execute");
>
>             uuidBroadcastEvent.AddHeader("execute-app-name",
> "uuid_broadcast");
>
>             uuidBroadcastEvent.AddHeader("execute-app-arg", legArguments);
>
>             uuidBroadcastEvent.AddHeader("event-lock", "true");
>
>             eslConnection.sendMSG(uuidBroadcastEvent, inboundChannel.UUID);
>
>
>
> All I get is the following debug in freeswitch:
>
>
>
> 2014-04-24 15:21:42.193042 [DEBUG] switch_core_session.c:1134 Send signal
> sofia/inbound/MYPHONENUMBER at OURIP [BREAK]
>
>
>
> The bridged call isn't affected by this, both ends still connected to each
> other.
>
>
>
> I've even tried sending a hangup event, but that also didn't hangup the
> call.
>
>
>
> It seems like FS isn't processing any events sent to it when the call is
> bridged.
>
>
>
> Any ideas?
>
>
>
> Regards,
>
>
>
> Grant
>
>
>
> *From:* freeswitch-users-bounces at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *On Behalf Of *Ian McMaster
> *Sent:* Tuesday, April 8, 2014 3:09 PM
> *To:* FreeSWITCH Users Help
> *Subject:* Re: [Freeswitch-users] Oubound ESL: unbridge
>
>
>
> Grant,
>
>
>
> I have no experience specifically in what you want, but can suggest this
> as a strategy which seems to work in principal:
>
>
>
> 1)  Handle the incoming call with ESL (you now have uuid_1).  You can ask
> the caller his destination, tell him his minutes remaining, etc.
>
> 2)  When you know the target caller number, bridge the caller (after the
> bridge, you still have only 1 uuid -> uuid_1).
>
> 3)  When you want to make an announcement, use uuid_broadcast <uuid_1>
> <voice_file> both (or a separate uuid_broadcast for each leg if voice file
> is different for each)
>
> 4)  Now to break apart the call for individual control, use uuid_transfer
> <uuid_1> -both <extension which parks>  -OR-  uuid_dual_transfer <uuid_1>
> <ALEG ext> <BLEG ext>.
>
> Either way you now have two uuid <uuid_1> and now <uuid_2>.  You can play
> MOH to your bleg (using uuid_2), and ask A leg for more money (using
> uuid_1).
>
> 5)  Now to re-connect, use uuid_bridge <uuid_1> <uuid_2> and they are back
> talking (or tell uuid_2 that the call will drop, and hangup both).
>
>
>
> Hope this helps, or a more experienced user can provide a better approach.
>
>
>
> Cheers,
>
> Ian.
>
>
>
>
>
>
>
> On Tue, Apr 8, 2014 at 7:54 AM, Grant Bagdasarian <GB at cm.nl> wrote:
>
> I'm trying to implement a custom calling card application. I looked at
> mod_nibblebill but our refilling of credits is done in a custom way, using
> one of our own APIs.
>
>
>
> The caller buys X minutes for Y euro. Once X minutes has passed, they get
> the option to buy another X minutes for Y euros by pressing 1 for example.
>
> I want to play the caller an audio file and let him decide whether he
> wants another X minutes after the previous X minutes have (almost) passed.
> The destination which he was initially bridged to will be put on hold until
> the caller has paid.
>
> Once paid, they get connected again.
>
>
>
> *From:* freeswitch-users-bounces at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *On Behalf Of *Michael
> Jerris
> *Sent:* Tuesday, April 8, 2014 12:37 PM
> *To:* FreeSWITCH Users Help
> *Subject:* Re: [Freeswitch-users] Oubound ESL: unbridge
>
>
>
>
>
> I'd go with 2, let freeswitch handle your call progress properly.
>
>
>
> Do you really want to unbridge?  you could just broadcast possibly.  what
> exactly are you trying to do?
>
>
> On Apr 8, 2014, at 6:32 AM, Grant Bagdasarian <GB at cm.nl> wrote:
>
> Hello,
>
>
>
> Could anyone with Outbound ESL experience help me out with this matter?
>
>
>
> Thanks,
>
>
>
> Grant
>
>
>
> *From:* freeswitch-users-bounces at lists.freeswitch.org [
> mailto:freeswitch-users-bounces at lists.freeswitch.org<freeswitch-users-bounces at lists.freeswitch.org>]
> *On Behalf Of *Grant Bagdasarian
> *Sent:* Monday, March 31, 2014 1:11 PM
> *To:* FreeSWITCH Users Help (freeswitch-users at lists.freeswitch.org)
> *Subject:* [Freeswitch-users] Oubound ESL: unbridge
>
>
>
> Hello,
>
>
>
> I'm working on a C# application which takes control over an inbound call
> in Freeswitch using ESL outbound and it works like a charm! I can answer
> the call, play something, get digits, etc.
>
> Now I'm at the point of implementing bridge functionality in the
> application.
>
>
>
> Which one is the best approach and why?
>
> 1)      >From the Outbound ESL Application use the originate command to
> create a new outbound call and then use uuid_bridge to connect both
> incoming and outgoing?
>
> 2)      Use the bridge command from the esl application?
>
>
>
> I would assume the first option would give me control over the b leg
> created as well, and the second option would not? This also brings me to my
> next question:
>
> -          Is there a way to "unbridge" both call legs, do some stuff on
> the incoming (a) leg, and then bridge them back without disconnecting any
> of the legs?
>
>
>
> Regards,
>
>
>
> Grant
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> 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
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> 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
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> 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/20140424/076f55ee/attachment-0001.html