typically you would use transfer to the dest then in the dialplan for XXXX you would
set hangup_after_bridge=true try to call the phone transfer back to your ivr you can use channel variables to keep track of state. On Tue, Apr 14, 2009 at 12:02 PM, Peter Olsson < [email protected]> wrote: > Allright – last question :) I’ll try to be a little more specific. Lets > say I whant to do the following; > > > > 1. Dial into FreeSWITCH, to some kind of application (javascript or > whatever). > > 2. Answer that call, and let the user choose what to do; 1: record > message, 2: transfer to XXX etc. The user presses 2. > > 3. I don’t want to release the first call leg yet, since I need to > be really sure that 2 is reachable (or else I will give the user choices > again, with som kind of ”the call could not be transferred”). So lets say I > play some music for the user while trying to connect the call. > > 4. I originate another call – now I understand I have two choices, > either I originate directly to a SIP phone (sofia/internal...), or I let the > dialplan do the work – and if I want the dialplan to be the one to transfer > the call somewhere (maybe to the same extension), I must use loopback – > right? > > 5. If the new call answers, bridge the two calls, if it fails, start > over again, after reading an error message. > > > > Whould this also be possible with transfer? If I understand everything > right I loose control of the call, and won’t be able to handle the failed > transfer? Or is it possible to solve in a better way? > > > > What I guess I’d really want to do is to ask the dialplan ”hey, I want to > dial XXXX – give me the full sofia profile string” so I can originate the > call directly, and I won’t need a loopback. I could of course connect to the > sofia string directly, but it would be nice to leave that kind of lookup > logic to the dialplan. > > > > Thanks for staying with me – I hope you understand my problem :) > > > > Regards, > > > > Peter > > > > > > *Från:* [email protected] [mailto: > [email protected]] *För *Anthony Minessale > *Skickat:* den 14 april 2009 18:26 > > *Till:* [email protected] > *Ämne:* Re: [Freeswitch-users] Use of loopback channels and bridge() in > scripts... > > > > The bridge application will let you bridge right to a destination on > *another* box. > If you want to connect to a local extension like 5000 you can use the > transfer application or method. > > session.transfer("5000"); > exit(); > > or > > session.execute("transfer", "5000"); > exit(); > > > On Tue, Apr 14, 2009 at 10:59 AM, Peter Olsson < > [email protected]> wrote: > > Yes, I’m starting to realize that... :) but you to get everything right – > if I want to bridge a call, using the dialplan, then the only way is to use > loopback, right? If I don’t want a loopback I’m able to bridge to the > destination directly? > > > > //Peter > > > > > > *Från:* [email protected] [mailto: > [email protected]] *För *Anthony Minessale > *Skickat:* den 14 april 2009 17:27 > > > *Till:* [email protected] > *Ämne:* Re: [Freeswitch-users] Use of loopback channels and bridge() in > scripts... > > > > yes, > > But if you plan is to bridge the call, the loopback channel is completely > unnecessary. > Be careful how much control you want =D getting a phone call up and running > is more work > than you think (see switch_ivr_originate.c) > > On Tue, Apr 14, 2009 at 8:24 AM, Peter Olsson < > [email protected]> wrote: > > Anthony, > > > > Yes, it seems to work correct now. I did a couple of test calls, and tha > audio was good – thanks! > > > > Another question about this scenario... > > > > When doing a session.transfer(”5000”), this will transfer the call directly > into the dialplan without the use of loopback-channels. But that way it’s > not possible to do it in a controlled way. Shouldn’t it be possible to do > the same thing with a bridge? As soon as the call is bridged, it gets ”rid > of” unneccecary loopback channels, and connecting the two endpoints directly > – cause by then it should be two ”normal” endpoints talking? > > > > Regards, > > > > Peter > > > > *Från:* [email protected] [mailto: > [email protected]] *För *Anthony Minessale > *Skickat:* den 13 april 2009 20:38 > *Till:* [email protected] > *Ämne:* Re: [Freeswitch-users] Use of loopback channels and bridge() in > scripts... > > > > see how it works in latest trunk 13011 > > nontheless you can just say > > session.execute("bridge", "loopback/5000"); > > and get the same result without touching that other channel. > > when the call fails, you will have an originate_disposition variable in > session you can check. > > On Mon, Apr 13, 2009 at 11:21 AM, Peter Olsson < > [email protected]> wrote: > > 1. The latest trunk I've tried with is 13008. Since I'm not doing > anything for production yet (just testing/evaluating), so I tend to update > as soon as there is new version available.. > 2. Yep, you will find it below. In javascript - my sample for .NET does > basically the same thing, with the same result, except that it also won't > drop the loopback-a call leg. > 3. Hmm.. Not really - I'm just in the middle of learning FS, so I guess > I'm not 100% sure what I'm doing.. :) What I want to be able to do is to > dial into a script, let the script dial another extension, and bridge them > together when the other party answers the call. I also need to take care of > call setup problems - if the other part doesn't respond, is unavailable or > busy in the phone - so I though this was the only way? If I use the > session.execute("bridge"..), will I be able to control the call if it > couldn't be connected? > > --- > > if (session.ready()) { > > session.answer(); > > new_session = new Session("loopback/5000", session); > new_session.waitForAnswer(); > > bridge(session, new_session); > > // Not sure if this is needed - I've tried with it both enabled and > disabled > session.hangup(); > new_session.hangup(); > } > > Peter > > > > On 09-04-13 17.54, "Anthony Minessale" <[email protected]> > wrote: > > 1) When you say latest, which rev does that mean? we change revs pretty > often. > 2) Do you have a minimal script that reproduces your issue. > 3) is there a reason you cannot just session.execute("bridge", dest); > instead of doing it manually (which is a process not for the faint at > heart)? > > > > On Mon, Apr 13, 2009 at 10:29 AM, Peter Olsson < > [email protected]> wrote: > I have two problems that I haven't been able to solve. I've done the same > tests in both javascript, and in .NET. > > The two scripts are pretty simple, they just answer an incomming call, > creates a new session, wait for an answer on the second call leg, and then > bridge the two channels together. > > In both cases everything works just fine, but the audio is distorted. The > destination I'm calling is "loopback/5000" - the sample IVR application > included in FreeSWITCH. I first thought it was a codec issue, but even after > trying to switch to different codecs the problem was the same. It more > sounds like it's a timestamping issue - the voice is not distorted enough to > be a bad codec, but it reads way to fast (mayby twice the "normal" speed). > When doing a direct transfer() to the other destination this works just > fine, but I need to be able to have some extra logic to tell if the > destination is available or not. > > The second problem occurs only in .NET. After doing this sample there is as > loopback channel still hanging around. It seems like the call creates a > loopback-a and loopback-b, the loopback-b dissapears as it should (when the > call has been disconnected), but the other one stays there. When doing the > same in javascript this doesn't seem to occur. > > I'm using the latest SVN trunk, and my OS is Windows XP. > > I found bug FSCORE-349 in Jira, which seems to point in to the direction > that there might be a bug with the loopback channels in some cases, but I > could not find anything about the audio which plays too fast. > > Has anyone else experienced this? > > Regards, > > Peter Olsson > > _______________________________________________ > Freeswitch-users mailing list > [email protected] > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org > > > > > _______________________________________________ > Freeswitch-users mailing list > [email protected] > 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/ > > AIM: anthm > MSN:[email protected] <msn%[email protected]> > GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:[email protected] <sip%[email protected]> > iax:[email protected]/888 > googletalk:[email protected]<googletalk%3aconf%[email protected]> > pstn:213-799-1400 > > > _______________________________________________ > Freeswitch-users mailing list > [email protected] > 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/ > > AIM: anthm > MSN:[email protected] <msn%[email protected]> > GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:[email protected] <sip%[email protected]> > iax:[email protected]/888 > googletalk:[email protected]<googletalk%3aconf%[email protected]> > pstn:213-799-1400 > > > _______________________________________________ > Freeswitch-users mailing list > [email protected] > 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/ > > AIM: anthm > MSN:[email protected] <msn%[email protected]> > GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:[email protected] <sip%[email protected]> > iax:[email protected]/888 > googletalk:[email protected]<googletalk%3aconf%[email protected]> > pstn:213-799-1400 > !DSPAM:49e4bcb132932104520616! > > _______________________________________________ > Freeswitch-users mailing list > [email protected] > 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/ AIM: anthm MSN:[email protected] <msn%[email protected]> GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:[email protected] <sip%[email protected]> iax:[email protected]/888 googletalk:[email protected]<googletalk%3aconf%[email protected]> pstn:213-799-1400
_______________________________________________ Freeswitch-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
