Hello, I have a php esl outbound deamon which is contactet by socket application when a caller hit the dialplan. The php deamon originates a call and waits after that for events. During ringing I cancel the callers call via caller's phone. Now the odd thing: Sometimes I got a HANGUP event so i can react on it, and sometimes not. In each case I can't write any command into the esl connection because it blocks endlessly. So I guess that FS has already torn down the socket in both cases. I wonder why I got no event from esl when this happens. Checking the esl connection with "connected()" returns always true resp. '1' in both cases. When I don't start an originate bgapi command, everything works and esl->connected() returns 0 resp false. Any ideas where I'm wrong? regards Helmut
Hi, here the loop code which is not working. To get it working comment the bgapi command. [...] $agent_chan_vars="origination_caller_id_name='Queue 1',origination_caller_id_number=$caller_id_number"; $agent="2850"; $con->bgapi("originate", "[origination_uuid=$a_uuid,$agent_chan_vars]sofia/internal/$agent@$sipdomain &playback(kuper/celt.mp3)"); do { acd_log(LOG_DEBUG, "Loop $l\n"); $e = $con->recvEventTimed(1000); echo $con->connected()."\n"; } while ($con->connected()); [...] On 22.06.2010 17:54, Helmut Kuper wrote:
Hello,
I have a php esl outbound deamon which is contactet by socket application when a caller hit the dialplan. The php deamon originates a call and waits after that for events. During ringing I cancel the callers call via caller's phone.
Now the odd thing: Sometimes I got a HANGUP event so i can react on it, and sometimes not. In each case I can't write any command into the esl connection because it blocks endlessly. So I guess that FS has already torn down the socket in both cases. I wonder why I got no event from esl when this happens. Checking the esl connection with "connected()" returns always true resp. '1' in both cases.
When I don't start an originate bgapi command, everything works and esl->connected() returns 0 resp false.
Any ideas where I'm wrong?
regards Helmut
_______________________________________________ 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
What is the reason to use "bgapi" instead of "api"? Your code just waits for the connection completion. Also you code doesn't take into account that the connection could fail for some reason. On Tuesday 22 June 2010, Helmut Kuper wrote:
Hi,
here the loop code which is not working. To get it working comment the bgapi command.
[...] $agent_chan_vars="origination_caller_id_name='Queue 1',origination_caller_id_number=$caller_id_number"; $agent="2850"; $con->bgapi("originate", "[origination_uuid=$a_uuid,$agent_chan_vars]sofia/internal/$agent@$sipdomai n &playback(kuper/celt.mp3)"); do { acd_log(LOG_DEBUG, "Loop $l\n"); $e = $con->recvEventTimed(1000); echo $con->connected()."\n"; } while ($con->connected()); [...]
On 22.06.2010 17:54, Helmut Kuper wrote:
Hello,
I have a php esl outbound deamon which is contactet by socket application when a caller hit the dialplan. The php deamon originates a call and waits after that for events. During ringing I cancel the callers call via caller's phone.
Now the odd thing: Sometimes I got a HANGUP event so i can react on it, and sometimes not. In each case I can't write any command into the esl connection because it blocks endlessly. So I guess that FS has already torn down the socket in both cases. I wonder why I got no event from esl when this happens. Checking the esl connection with "connected()" returns always true resp. '1' in both cases.
When I don't start an originate bgapi command, everything works and esl->connected() returns 0 resp false.
Any ideas where I'm wrong?
regards Helmut
_______________________________________________ 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
_______________________________________________ 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
Hi Sergey, On 22.06.2010 18:14, Sergey Okhapkin wrote:
What is the reason to use "bgapi" instead of "api"? Your code just waits for the connection completion.
Well, bgapi allows my code *not* to wait until originate connected or fails. Instead I want to get events about connect or failure...
Also you code doesn't take into account that the connection could fail for some reason.
yes, I know, the code sippet is only for demonstrating the problem. regards helmut
Why not analyze the return code of "api" call? Without events loop? On Tuesday 22 June 2010, Helmut Kuper wrote:
Hi Sergey,
On 22.06.2010 18:14, Sergey Okhapkin wrote:
What is the reason to use "bgapi" instead of "api"? Your code just waits for the connection completion.
Well, bgapi allows my code *not* to wait until originate connected or fails. Instead I want to get events about connect or failure...
Also you code doesn't take into account that the connection could fail for some reason.
yes, I know, the code sippet is only for demonstrating the problem.
regards helmut
_______________________________________________ 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
Hi, hm well, yes, indeed that works, too. Maybe even better. But I still have the problem of a hanging command which doesn't comes back until timeout, answer, cancel, ... on callee's side. I need to have two channels controlled. The originating caller channel and the 2nd channel originated by my deamon. I have to playback some files to caller while searching for a free callee. Once callee has answered the call the deamon bridges both channels. On 22.06.2010 20:02, Sergey Okhapkin wrote:
Why not analyze the return code of "api" call? Without events loop?
On Tuesday 22 June 2010, Helmut Kuper wrote:
Hi Sergey,
On 22.06.2010 18:14, Sergey Okhapkin wrote:
What is the reason to use "bgapi" instead of "api"? Your code just waits for the connection completion.
Well, bgapi allows my code *not* to wait until originate connected or fails. Instead I want to get events about connect or failure...
Also you code doesn't take into account that the connection could fail for some reason.
yes, I know, the code sippet is only for demonstrating the problem.
regards helmut
On Tue, Jun 22, 2010 at 11:34 AM, Helmut Kuper <helmut.kuper@ewetel.de>wrote:
Hi,
hm well, yes, indeed that works, too. Maybe even better.
But I still have the problem of a hanging command which doesn't comes back until timeout, answer, cancel, ... on callee's side.
Which command doesn't come back? I'm assuming you mean the "originate" itself and not the bgapi. I don't see how you can avoid a "hang" while you wait for the 2nd channel (the callee) to be contacted since you have to wait for him/her to answer. In any case, this should be quite doable either with api or with bgapi. The difference with bgapi is that you can do other stuff in your script (if you need to) while api will wait for the result of the originate before it returns. -MC
Hi Michael, On 22.06.2010 20:41, Michael Collins wrote:
On Tue, Jun 22, 2010 at 11:34 AM, Helmut Kuper <helmut.kuper@ewetel.de>wrote:
Hi,
hm well, yes, indeed that works, too. Maybe even better.
But I still have the problem of a hanging command which doesn't comes back until timeout, answer, cancel, ... on callee's side.
Which command doesn't come back? I'm assuming you mean the "originate" itself and not the bgapi. I don't see how you can avoid a "hang" while you wait for the 2nd channel (the callee) to be contacted since you have to wait for him/her to answer. In any case, this should be quite doable either with api or with bgapi. The difference with bgapi is that you can do other stuff in your script (if you need to) while api will wait for the result of the originate before it returns.
What I currently do is this: 1. caller calls in 2. FS calls my deamon via socket app (async full) 3. Deamon connects the call via ESLconnection 4. executing answer 5. executing playback 6. subscribing to all events 7. originate b-leg via bgapi 9. waiting for events (this is a loop using esl->recvEventsTimed(1000)) 9.1 replaying caller's playback 9.2 checking for caller's Hangup 9.3 checking for esl->connected=false 9.4 checking for b-leg's result (Answer or deny) 9.4.1 bridge both legs 9.4.2 release esl-socket 9.4.3 done When caller hangs up somewhere after step 7 I got sometimes a HANGUP event but more often nothing. Trying to write into the esl->socket then seems to block until originate has finished. I guess FS has torn down the socket half way or so in this state. regards Helmut
Hi again, I added now an inbound esl socket back to FS through which I execute the originate command. And this way it works. When caller hang up during originate ringing I get the HANGUP event and I can uuid_kill the originate session. :) hmmm... So bgapi originate seems so stick with the channel's outbound socket when it is called via outbound socket. regards helmut On 23.06.2010 08:57, Helmut Kuper wrote:
Hi Michael,
On 22.06.2010 20:41, Michael Collins wrote:
On Tue, Jun 22, 2010 at 11:34 AM, Helmut Kuper <helmut.kuper@ewetel.de>wrote:
Hi,
hm well, yes, indeed that works, too. Maybe even better.
But I still have the problem of a hanging command which doesn't comes back until timeout, answer, cancel, ... on callee's side.
Which command doesn't come back? I'm assuming you mean the "originate" itself and not the bgapi. I don't see how you can avoid a "hang" while you wait for the 2nd channel (the callee) to be contacted since you have to wait for him/her to answer. In any case, this should be quite doable either with api or with bgapi. The difference with bgapi is that you can do other stuff in your script (if you need to) while api will wait for the result of the originate before it returns.
What I currently do is this:
1. caller calls in 2. FS calls my deamon via socket app (async full) 3. Deamon connects the call via ESLconnection 4. executing answer 5. executing playback 6. subscribing to all events 7. originate b-leg via bgapi 9. waiting for events (this is a loop using esl->recvEventsTimed(1000)) 9.1 replaying caller's playback 9.2 checking for caller's Hangup 9.3 checking for esl->connected=false 9.4 checking for b-leg's result (Answer or deny) 9.4.1 bridge both legs 9.4.2 release esl-socket 9.4.3 done
When caller hangs up somewhere after step 7 I got sometimes a HANGUP event but more often nothing. Trying to write into the esl->socket then seems to block until originate has finished.
I guess FS has torn down the socket half way or so in this state.
regards Helmut
_______________________________________________ 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
try running the "linger" command. that tells FS to not disconnect when the channel hangs up and instead wait for you to disconnect. On Wed, Jun 23, 2010 at 3:26 AM, Helmut Kuper <helmut.kuper@ewetel.de>wrote:
Hi again,
I added now an inbound esl socket back to FS through which I execute the originate command. And this way it works. When caller hang up during originate ringing I get the HANGUP event and I can uuid_kill the originate session. :)
hmmm... So bgapi originate seems so stick with the channel's outbound socket when it is called via outbound socket.
regards helmut
On 23.06.2010 08:57, Helmut Kuper wrote:
Hi Michael,
On 22.06.2010 20:41, Michael Collins wrote:
On Tue, Jun 22, 2010 at 11:34 AM, Helmut Kuper <helmut.kuper@ewetel.de wrote:
Hi,
hm well, yes, indeed that works, too. Maybe even better.
But I still have the problem of a hanging command which doesn't comes back until timeout, answer, cancel, ... on callee's side.
Which command doesn't come back? I'm assuming you mean the "originate" itself and not the bgapi. I don't see how you can avoid a "hang" while you wait for the 2nd channel (the callee) to be contacted since you have to wait for him/her to answer. In any case, this should be quite doable either with api or with bgapi. The difference with bgapi is that you can do other stuff in your script (if you need to) while api will wait for the result of the originate before it returns.
What I currently do is this:
1. caller calls in 2. FS calls my deamon via socket app (async full) 3. Deamon connects the call via ESLconnection 4. executing answer 5. executing playback 6. subscribing to all events 7. originate b-leg via bgapi 9. waiting for events (this is a loop using esl->recvEventsTimed(1000)) 9.1 replaying caller's playback 9.2 checking for caller's Hangup 9.3 checking for esl->connected=false 9.4 checking for b-leg's result (Answer or deny) 9.4.1 bridge both legs 9.4.2 release esl-socket 9.4.3 done
When caller hangs up somewhere after step 7 I got sometimes a HANGUP event but more often nothing. Trying to write into the esl->socket then seems to block until originate has finished.
I guess FS has torn down the socket half way or so in this state.
regards Helmut
_______________________________________________ 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
_______________________________________________ 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
As a workaround I armed caller's channel with api_hangup_hook which does a uuid_kill on the b-leg. I wonder why the esl socket is blocking although I use bgapi for originate ... On 22.06.2010 20:34, Helmut Kuper wrote:
Hi,
hm well, yes, indeed that works, too. Maybe even better.
But I still have the problem of a hanging command which doesn't comes back until timeout, answer, cancel, ... on callee's side.
I need to have two channels controlled. The originating caller channel and the 2nd channel originated by my deamon. I have to playback some files to caller while searching for a free callee. Once callee has answered the call the deamon bridges both channels.
Do not use async "bg" commands. Use their sync counterparts. Anyway you need to complete one command before issuing the next one. What you are doing now looks like event-based GUI window programming style. Switch your mind to procedural-style actions sequence programing model which is more suitable for the task you need to accomplish. On Tuesday 22 June 2010, Helmut Kuper wrote:
Hi,
hm well, yes, indeed that works, too. Maybe even better.
But I still have the problem of a hanging command which doesn't comes back until timeout, answer, cancel, ... on callee's side.
I need to have two channels controlled. The originating caller channel and the 2nd channel originated by my deamon. I have to playback some files to caller while searching for a free callee. Once callee has answered the call the deamon bridges both channels.
On 22.06.2010 20:02, Sergey Okhapkin wrote:
Why not analyze the return code of "api" call? Without events loop?
On Tuesday 22 June 2010, Helmut Kuper wrote:
Hi Sergey,
On 22.06.2010 18:14, Sergey Okhapkin wrote:
What is the reason to use "bgapi" instead of "api"? Your code just waits for the connection completion.
Well, bgapi allows my code *not* to wait until originate connected or fails. Instead I want to get events about connect or failure...
Also you code doesn't take into account that the connection could fail for some reason.
yes, I know, the code sippet is only for demonstrating the problem.
regards helmut
_______________________________________________ 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
participants (4)
-
Anthony Minessale
-
Helmut Kuper
-
Michael Collins
-
Sergey Okhapkin