Re: [OpenSIPS-Users] opensips 2.1 call_center queue position (Jonathan Hunter)
Hello I recently started to explore call_center module and I think that it might not be patch related. here is my experience. I downloaded opensips branch 2.2 commit c8a605b. when agent is registered and there are no clients in line/queue the caller gets connected to the agent almost instantly and everything works fine. If the agent is in wrapup_time and I call again the same flow/queue I get send to the media server and moh starts streaming. Now when the wrapup_time finishes and the caller needs to be connected to the agent or somewhere earlier before that opensips crashes and caller is stuck in moh stream. but if there is no call during wrapup_time period and I call again everything works fine. tested with 1 agent in 2 flows, 1 user and asterisk as media server to stream moh sorry if I high jacket this thread but I think it's relevant to the crash Jonathan Hunter is experiencing. == last few log lines from the crash Nov 2 08:01:12 opensips /sbin/opensips[12152]: b2b_reply BYE : [F=sip:use...@opensips.test R= D=UA= IP=(192.168.116.125:5060 192.168.116.125:5060) ID=B2B.323.7879765.1478070026] Nov 2 08:01:20 opensips /sbin/opensips[12151]: CALLCENTER MODULE: [F=sip:use...@opensips.test R=sip:engl...@opensips.test D= M=INVITE IP=(192.168.69.114:39336 192.168.116.125:5060) ID=zSWAmB.rM89XJB-wKMDABguDJ21SKN3Q] Nov 2 08:01:20 opensips /sbin/opensips[12151]: INFO:b2b_logic:b2bl_add_client: adding entity [0xb33c9c4c]->[B2B.464.2920496.1478070079] to tuple [0xb33c9d40]->[13.0] Nov 2 08:01:20 opensips /sbin/opensips[12152]: INFO:b2b_logic:b2b_add_dlginfo: Dialog pair: [zSWAmB.rM89XJB-wKMDABguDJ21SKN3Q] - [B2B.464.2920496.1478070079] Nov 2 08:01:20 opensips /sbin/opensips[12152]: b2b_reply INVITE : [F=sip:use...@opensips.test R= D= UA= IP=(192.168.117.100:5065 192.168.116.125:5060) ID=B2B.464.2920496.1478070079] Nov 2 08:01:21 opensips /sbin/opensips[12152]: b2b_request ACK : [F=sip:use...@opensips.test R=sip:192.168.116.125:5060 D= UA= IP=(192.168.69.114:39336 192.168.116.125:5060) ID=zSWAmB.rM89XJB-wKMDABguDJ21SKN3Q] Nov 2 08:01:25 opensips /sbin/opensips[12152]: b2b_request INVITE : [F=sip:use...@opensips.test R=sip:192.168.116.125:5060 D= UA= IP=(192.168.69.114:39336 192.168.116.125:5060) ID=zSWAmB.rM89XJB-wKMDABguDJ21SKN3Q] Nov 2 08:01:26 opensips /sbin/opensips[12124]: INFO:core:handle_sigs: child process 12152 exited by a signal 11 Nov 2 08:01:26 opensips /sbin/opensips[12181]: CRITICAL:core:receive_fd: EOF on 34 Nov 2 08:01:26 opensips /sbin/opensips[12124]: INFO:core:handle_sigs: core was generated Nov 2 08:01:26 opensips /sbin/opensips[12124]: INFO:core:handle_sigs: terminating due to SIGCHLD Nov 2 08:01:26 opensips /sbin/opensips[12181]: INFO:core:sig_usr: signal 15 received Nov 2 08:01:26 opensips /sbin/opensips[12173]: INFO:core:sig_usr: signal 15 received On 11/02/2016 10:33 AM, users-requ...@lists.opensips.org wrote: Re: opensips 2.1 call_center queue position (Jonathan Hunter) ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Script execution hanging
Hi Liviu,
I think that it was me that made that happen.
Backtracking my steps what I did was first I call sl_send_reply("100",
"-Trying-")
because I don't know for how long I'm going to talk to the http server.
Second from route(PSTN) I call route(CGR_LCR_REQ) which in turn calls
route(CGR_LCR_REPLY) to finish processing the request, and that route
calls another route down the
chain of routes that I'm calling for that message,that has nothing to do
with the route that I called
in the first place. And by the way I forgot and I quote from Types of
routes page "Default action : if the request is not either forwarded nor
replied, the route will simply discard the request at the end." And
because I thought that it will auto magically continue execution from
the line where I called route(CGR_LCR_REQ) and route(PSTN) in return .
At this point I have a deadlock between Opensips that finished message
processing and a client that is waithing for a reply.
What I did was I rearranged the script execution where I first called
route(CGR_LCR_REQ) instead of route(PSTN) and when that chain of routes
finished successfully I called route(PSTN) at the end which continued
executing the rest of PSTN route logic.
I think that I got it right now but if you think from my elaborate
explanation I did something wrong please correct me.
Hi Koce,
Does the first async rest_post() finish successfully by having its
resume route run? Could you please add some xlog() debugging prints, so
we can better understand where it gets stuck exactly?
Also, do you notice this behaviour with any HTTP server (100%
reproducible), or is it a timing corner-case of your scenario?
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 14.03.2016 23:16, Koce wrote:
>Hello I'm using Opensips 2.1 git version and when I try to execute the
>outline from the routing logic below I get Opensips hanging on
>route(CGR_LCR_REQ) when it finishes executing.What I'm trying to say
>is it hangs on that particular line as it is expecting something.
>So I'm wondering if I need to do a return on the end of that chained
>routing block?
>Also is there some kind of depth limit that Opensips can go in the
>routing route calling logic where it can't find it's way back,because
>If I comment out route(CGR_LCR_REQ) everything continues execution as
>planned?
>##
>if (is_method("INVITE")) {
> sl_send_reply("100", "-Trying-");
> xlog("L_INFO", "LOOKUPLOCATION_INVITE: [F=$fu R=$ru D=$du M=$rm
>IP=($si:$sp $Ri:$Rp) ID=$ci]");
> if ($rU=~"(\+|00)?[0-9]{4,15}") {#PSTN LOGIC
> route(PSTN);
> xlog("L_INFO", "PSTN_PROCESSED_INVITE: [F=$fu R=$ru D=$du M=$rm
>IP=($si:$sp $Ri:$Rp) ID=$ci]");
> }
>#rest of is_method("INVITE") route logic
>##
>route[PSTN]{
> route(CGR_LCR_REQ); #hanging
>#rest of PSTN route logic
>}
>
>route[CGR_LCR_REQ]{
>#var assignment and route logic
>async(rest_post(),,,CGR_LCR_REPLY)
>}
>
>route[CGR_LCR_REPLY]{
>#route logic and var assignment
>async(rest_post(),,,CLI-REQ)
>}
>#and a few more route blocks calling async as outlined between
>CGR_LCR_REQ and CGR_LCR_REPLY
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Script execution hanging
Hello I'm using Opensips 2.1 git version and when I try to execute the
outline from the routing logic below I get Opensips hanging on
route(CGR_LCR_REQ) when it finishes executing.What I'm trying to say is
it hangs on that particular line as it is expecting something.
So I'm wondering if I need to do a return on the end of that chained
routing block?
Also is there some kind of depth limit that Opensips can go in the
routing route calling logic where it can't find it's way back,because If
I comment out route(CGR_LCR_REQ) everything continues execution as planned?
##
if (is_method("INVITE")) {
sl_send_reply("100", "-Trying-");
xlog("L_INFO", "LOOKUPLOCATION_INVITE: [F=$fu R=$ru D=$du M=$rm
IP=($si:$sp $Ri:$Rp) ID=$ci]");
if ($rU=~"(\+|00)?[0-9]{4,15}") {#PSTN LOGIC
route(PSTN);
xlog("L_INFO", "PSTN_PROCESSED_INVITE: [F=$fu R=$ru D=$du M=$rm
IP=($si:$sp $Ri:$Rp) ID=$ci]");
}
#rest of is_method("INVITE") route logic
##
route[PSTN]{
route(CGR_LCR_REQ); #hanging
#rest of PSTN route logic
}
route[CGR_LCR_REQ]{
#var assignment and route logic
async(rest_post(),,,CGR_LCR_REPLY)
}
route[CGR_LCR_REPLY]{
#route logic and var assignment
async(rest_post(),,,CLI-REQ)
}
#and a few more route blocks calling async as outlined between
CGR_LCR_REQ and CGR_LCR_REPLY
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] first async(rest_post) timeout fail
Hello Liviu thank you for your time,you are correct I increased the timeout to 5 sec and once the connections were established everything was working as it should. I feel foolish for this but I think i learned something. Anyway here is the opensips.log with the extra logging just in case Feb 26 13:52:25 /sbin/opensips[2114]: INFO:rest_client:start_async_http_req: curl_multi_timeout(): retry_time is 0ms Feb 26 13:52:25 /sbin/opensips[2114]: INFO:rest_client:start_async_http_req: curl_multi_timeout(): retry_time is 2999ms Feb 26 13:52:28 /sbin/opensips[2114]: INFO:rest_client:start_async_http_req: curl_multi_timeout() returned -1, pausing 500ms... Feb 26 13:52:29 /sbin/opensips[2114]: ERROR:rest_client:start_async_http_req: timeout while connecting to 'http://192.168.100.1:2080/jsonrpc' (3 sec) Feb 26 13:52:29 /sbin/opensips[2114]: INFO:rest_client:start_async_http_req: curl_multi_timeout(): retry_time is 1ms Feb 26 13:52:29 /sbin/opensips[2114]: INFO:rest_client:start_async_http_req: curl_multi_timeout(): retry_time is 2994ms Feb 26 13:52:29 /sbin/opensips[2114]: RETURNED NOT NULL #xlog line for async_request Feb 26 13:52:29 /sbin/opensips[2114]: INFO:rest_client:start_async_http_req: curl_multi_timeout(): retry_time is 1ms Hello koce! Most likely, the issue is due to your restricting "connection_timeout = 1" module parameter. To quote from libcurl's documentation [1]: /"You must not wait too long (more than a few seconds perhaps)". /This is why I chose that 500 ms pause time upon running into that error condition, which is basically 50% of your allowed blocking time already! To better understand how much libcurl expects you to wait, you can apply an extra logging patch: /git apply <(wget -qO - http://opensips.org/patches/rest_client_connect_timeout_logging.patch) /Please re-compile your rest_client and re-run the test, and we'll draw final conclusions afterwards! [1]: https://curl.haxx.se/libcurl/c/curl_multi_timeout.html Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 23.02.2016 15:46, k...@mentalchallenge.tk wrote: Hello I'm using OpenSIPS 2.1 latest from git and every time I call the first async(rest_post) function from my script I experience timeout,and the other calls to async(rest_post) after that point in the script are OK, as if the first call is like a ping to the http server it does not send any data to it,it only completes the TCP handshake. But if I put a dummy rest_post() function in front of the first async(rest_post) it will send the data that is assigned to it and after that the first async(rest_post) call and the rest that follow will execute as planned. To test if there is something wrong with the server that I'm connecting to I tried another server that had nothing to do with the original just to see if I get the same result and YES the async(rest_post) to that server failed but the other async(rest_post) who are interacting with the original server executed without a hitch. Also I think it's related to this https://github.com/OpenSIPS/opensips/issues/493 which is closed. Could this be a possible bug,or am I missing something obvious ? Also I installed curl 7.47.1 just to make sure it wasn't libcurl in question and the same scenario happened again. the errors that I got in opensips.log Feb 23 10:49:43 /sbin/opensips[25985]: INFO:rest_client:start_async_http_req: curl_multi_timeout() returned -1, pausing 500ms... Feb 23 10:49:44 /sbin/opensips[25985]: ERROR:rest_client:start_async_http_req: timeout while connecting to 'http://192.168.100.3:2080/jsonrpc' (1 sec) Feb 23 12:28:08 /sbin/opensips[26219]: INFO:rest_client:start_async_http_req: curl_multi_timeout() returned -1, pausing 500ms... Feb 23 12:28:08 /sbin/opensips[26219]: ERROR:rest_client:start_async_http_req: timeout while connecting to 'http://192.168.100.2:80/jsonrpc' (1 sec) NOTE: the IP's are substituted from the real ones which are public. I'm attaching 2 flows from wireshark. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] first async(rest_post) timeout fail
Hello I'm using OpenSIPS 2.1 latest from git and every time I call the first async(rest_post) function from my script I experience timeout,and the other calls to async(rest_post) after that point in the script are OK, as if the first call is like a ping to the http server it does not send any data to it,it only completes the TCP handshake. But if I put a dummy rest_post() function in front of the first async(rest_post) it will send the data that is assigned to it and after that the first async(rest_post) call and the rest that follow will execute as planned. To test if there is something wrong with the server that I'm connecting to I tried another server that had nothing to do with the original just to see if I get the same result and YES the async(rest_post) to that server failed but the other async(rest_post) who are interacting with the original server executed without a hitch. Also I think it's related to this https://github.com/OpenSIPS/opensips/issues/493 which is closed. Could this be a possible bug,or am I missing something obvious ? Also I installed curl 7.47.1 just to make sure it wasn't libcurl in question and the same scenario happened again. the errors that I got in opensips.log Feb 23 10:49:43 /sbin/opensips[25985]: INFO:rest_client:start_async_http_req: curl_multi_timeout() returned -1, pausing 500ms... Feb 23 10:49:44 /sbin/opensips[25985]: ERROR:rest_client:start_async_http_req: timeout while connecting to 'http://192.168.100.3:2080/jsonrpc' (1 sec) Feb 23 12:28:08 /sbin/opensips[26219]: INFO:rest_client:start_async_http_req: curl_multi_timeout() returned -1, pausing 500ms... Feb 23 12:28:08 /sbin/opensips[26219]: ERROR:rest_client:start_async_http_req: timeout while connecting to 'http://192.168.100.2:80/jsonrpc' (1 sec) NOTE: the IP's are substituted from the real ones which are public. I'm attaching 2 flows from wireshark. |Time | 192.168.100.1 | | | | 192.168.100.3 | |13.478816| 48460 > autodesk-nl |TCP: 48460 > autodesk-nlm [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=1116077461 TSecr=0 WS=16 | |(48460) --> (2080) | |13.479858| autodesk-nlm > 4846 |TCP: autodesk-nlm > 48460 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=1070513 TSecr=1116077461 WS=16 | |(48460) <-- (2080) | |13.479966| 48460 > autodesk-nl |TCP: 48460 > autodesk-nlm [ACK] Seq=1 Ack=1 Win=14608 Len=0 TSval=1116077461 TSecr=1070513 | |(48460) --> (2080) | |16.031527| 48460 > autodesk-nl |TCP: 48460 > autodesk-nlm [FIN, ACK] Seq=1 Ack=1 Win=14608 Len=0 TSval=1116078099 TSecr=1070513 | |(48460) --> (2080) | |16.032326| 48461 > autodesk-nl |TCP: 48461 > autodesk-nlm [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=1116078099 TSecr=0 WS=16 | |(48461) --> (2080) | |16.032378| autodesk-nlm > 4846 |TCP: autodesk-nlm > 48460 [FIN, ACK] Seq=1 Ack=2 Win=14480 Len=0 TSval=1071151 TSecr=1116078099 | |(48460) <-- (2080) | |16.032462| 48460 > autodesk-nl |TCP: 48460 > autodesk-nlm [ACK] Seq=2 Ack=2 Win=14608 Len=0 TSval=1116078100 TSecr=1071151 | |(48460) --> (2080) | |16.033143| autodesk-nlm > 4846 |TCP: autodesk-nlm > 48461 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=1071151 TSecr=1116078099 WS=16 | |(48461) <-- (2080) | |16.033239| 48461 > autodesk-nl |TCP: 48461 > autodesk-nlm [ACK] Seq=1 Ack=1 Win=14608 Len=0 TSval=1116078100 TSecr=1071151 | |(48461) --> (2080) | |16.038013| 48461 > autodesk-nl |TCP: 48461 > autodesk-nlm [PSH, ACK] Seq=1 Ack=1 Win=14608 Len=267 TSval=1116078101 TSecr=1071151 | |(48461) --> (2080) | |16.038613| autodesk-nlm > 4846 |TCP: autodesk-nlm > 48461 [ACK] Seq=1 Ack=268 Win=15552 Len=0 TSval=1071152 TSecr=1116078101 | |(48461) <-- (2080) | |16.045423| autodesk-nlm > 4846 |TCP: autodesk-nlm > 48461 [PSH, ACK] Seq=1 Ack=268 Win=15552 Len=191 TSval=1071154 TSecr=1116078101 | |(48461) <-- (2080) | |16.045572| 48461 > autodesk-nl |TCP: 48461 > autodesk-nlm [ACK] Seq=268 Ack=192 Win=15680 Len=0 TSval=1116078103 TSecr=1071154 | |(48461) --> (2080) | |16.046922| 48461 > autodesk-nl |TCP: 48461 > autodesk-nlm [PSH, ACK] Seq=268 Ack=192 Win=15680 Len=233 TSval=1116078103 TSecr=1071154 | |(48461) --> (2080) | |16.053985| autodesk-nlm > 4846
