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
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900