Issue with delayed hangup when originating from JS
Hi, I am working on porting an outbound CC app from asterisk to FS. method: I originate a call to the agents phone and if they answer I bridge/originate and then bridge/connect to a conferance and transfer to an outbound line. In all of those scenarios if I use JS to do two seperate originates I have the same issue. problem: If the agent hangs up his phone before a connection on the second originate both lines stay open untill something happens to the second leg. If there is an originate timeout on it and it isent answered then both legs with hangup as soon as the second leg terminates as well. If the client picks up the phone then both will teminate too, this of course leads to a really bad "ring ring, hello?, click" situation with the agent not even aware that it is happening. If I use a single originate directly to a bridge then both legs terminate as soon as the agent/first leg is hung up, with both api_hanguphooks running as expected. It seems to only be an issue if I originate to park() and then connect the two via JS or if I originate directly to a JS file that then generates and bridges the other session. I have managed to work arround it with a fairly rediculous originate api call moving some lcr and balancing code into my frontend rather than a FS JS script. But this means my application has to be aware of the number of calls per lcr route and all sorts of things that I would have prefered to handle in FS directly. I dont know if this is a design feature to alleviate the post hangup code issues that I had in asterisk, or if it is just the way I am implementing it that is messing me arround. So if one of you guys that know the internals really well can help me out with a reason or workarround for this behaviour I would greatly appreciate it. Again there is no urgency to this anymore since my current implementation works fine. But I would like to understand the underlying causes of this behaviour if that is possible to explain without a "go read the code" :-D. Thank you very much, Sias
1) Pass one session as the constructor to another session2 = new Session("sofia/internal/foo@bar.com", session); This will make the originate stop of session hangs up and pass other critical caller info to session2. 2) don't create session2 just use the bridge app This is the same effect with less sessions to worry about. session:execute("bridge", "sofia/internal/foo@bar.com"); 3) use mod_fifo that already does agent ACD On Tue, Jul 27, 2010 at 6:40 AM, Sias Mey <sias@cpdata.co.za> wrote:
Hi,
I am working on porting an outbound CC app from asterisk to FS.
method:
I originate a call to the agents phone and if they answer I bridge/originate and then bridge/connect to a conferance and transfer to an outbound line.
In all of those scenarios if I use JS to do two seperate originates I have the same issue.
problem:
If the agent hangs up his phone before a connection on the second originate both lines stay open untill something happens to the second leg.
If there is an originate timeout on it and it isent answered then both legs with hangup as soon as the second leg terminates as well. If the client picks up the phone then both will teminate too, this of course leads to a really bad "ring ring, hello?, click" situation with the agent not even aware that it is happening.
If I use a single originate directly to a bridge then both legs terminate as soon as the agent/first leg is hung up, with both api_hanguphooks running as expected. It seems to only be an issue if I originate to park() and then connect the two via JS or if I originate directly to a JS file that then generates and bridges the other session.
I have managed to work arround it with a fairly rediculous originate api call moving some lcr and balancing code into my frontend rather than a FS JS script. But this means my application has to be aware of the number of calls per lcr route and all sorts of things that I would have prefered to handle in FS directly.
I dont know if this is a design feature to alleviate the post hangup code issues that I had in asterisk, or if it is just the way I am implementing it that is messing me arround.
So if one of you guys that know the internals really well can help me out with a reason or workarround for this behaviour I would greatly appreciate it.
Again there is no urgency to this anymore since my current implementation works fine. But I would like to understand the underlying causes of this behaviour if that is possible to explain without a "go read the code" :-D.
Thank you very much, Sias
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
Hi Anthony, Hmmmm
1) Pass one session as the constructor to another
session2 = new Session("sofia/internal/[1]foo@bar.com", session);
This will make the originate stop of session hangs up and pass other critical caller info to session2. This one might do exactly what Im looking for, I dont know if I missed it in the documentation but I really didnt know this was possible.
2) don't create session2 just use the bridge app
This is the same effect with less sessions to worry about.
session:execute("bridge", "sofia/internal/[2]foo@bar.com");
I could have sworn I did basically try this.... but Ill give it another try sometime.
3) use mod_fifo that already does agent ACD Im working on a more click to dial type setup with no queueing on either side, but I have used mod_fifo to great effect in some other spots.
Thank you very much for the sugestions. Cheers, Sias
participants (2)
-
Anthony Minessale
-
Sias Mey