Re: [SR-Users] ASYNC Module

2015-06-12 Thread Aaron Hamstra
7:13 PM To: sr-users@lists.sip-router.org Subject: Re: [SR-Users] ASYNC Module On 06/12/2015 07:07 PM, Aaron Hamstra wrote: > Jun 12 22:55:41 /usr/local/sbin/kamailio[23297]: DEBUG: > [tcp_main.c:2552]: tcpconn_do_send(): tcp_send: > aft£Y;ùô0#}¤V|#031Y#037$kÍlJ8CÂ}F’å«Õ=661 fd=12 &g

Re: [SR-Users] ASYNC Module

2015-06-12 Thread Alex Balashov
On 06/12/2015 07:07 PM, Aaron Hamstra wrote: Jun 12 22:55:41 /usr/local/sbin/kamailio[23297]: DEBUG: [tcp_main.c:2552]: tcpconn_do_send(): tcp_send: aft£Y;ùô0#}¤V|#031Y#037$kÍlJ8CÂ}F’å«Õ=661 fd=12 Jun 12 22:55:41 /usr/local/sbin/kamailio[23297]: DEBUG: tm [t_hooks.c:288]: run_trans_callbacks

Re: [SR-Users] ASYNC Module

2015-06-12 Thread Alex Balashov
Aaron, On 06/12/2015 07:10 PM, Aaron Hamstra wrote: I tried to just add a #!define ENABLE_ASYNC_MUTEX and the issue remains In this case, the committer's comment that "it can be enabled by defining ENABLE_ASYNC_MUTEX" does not refer to preprocessor #!defines within the Kamailio route sc

Re: [SR-Users] ASYNC Module

2015-06-12 Thread Aaron Hamstra
expiration event I tried to just add a #!define ENABLE_ASYNC_MUTEX and the issue remains -Original Message- From: sr-users [mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Alex Balashov Sent: Friday, June 12, 2015 4:27 PM To: Aaron Hamstra Subject: Re: [SR-Users] ASYNC

Re: [SR-Users] ASYNC Module

2015-06-12 Thread Aaron Hamstra
I think this is the section from log when I increase debug up a notch ... I see it mentions in the trace below that the sip_trace module is the line above the 500 response. I just tried disabling that to see if it changed anything and it did not .. still get the 500 response... Jun 12 22:55

Re: [SR-Users] ASYNC Module

2015-06-12 Thread Alex Balashov
It is strange that you should see this change between minor point releases. That does suggest a possible regression. -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direc

Re: [SR-Users] ASYNC Module

2015-06-12 Thread Alex Balashov
: http://www.evaristesys.com/, http://www.csrpswitch.com/ Sent from my BlackBerry.   Original Message   From: Aaron Hamstra Sent: Friday, June 12, 2015 17:22 To: Kamailio (SER) - Users Mailing List Reply To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] ASYNC Module Thanks for the

Re: [SR-Users] ASYNC Module

2015-06-12 Thread Aaron Hamstra
ehalf Of Alex Balashov Sent: Friday, June 12, 2015 4:11 PM To: sr-users@lists.sip-router.org Subject: Re: [SR-Users] ASYNC Module Aaron, Thanks. You seem to be getting automatic errors from TM, even though your calling code neither creates a transaction nor calls t_relay(). This is because the wra

Re: [SR-Users] ASYNC Module

2015-06-12 Thread Alex Balashov
Aaron, Thanks. You seem to be getting automatic errors from TM, even though your calling code neither creates a transaction nor calls t_relay(). This is because the wrappers provided by the 'async' module utilise TM internally; async_route() really 1) creates a transaction in TM 2) t_suspends

Re: [SR-Users] ASYNC Module

2015-06-12 Thread Aaron Hamstra
send_reply("405", "Method Not Allowed"); exit; } } # when routing via usrloc, log the missed calls also if (is_method("INVITE")) { setflag(FLT_ACCMISSED); }

Re: [SR-Users] ASYNC Module

2015-06-12 Thread Alex Balashov
Aaron, Where is the call to async_route() situated in the core request route? That is, what is called before and after the async_route? -- Alex On 06/12/2015 03:38 PM, Aaron Hamstra wrote: We just updated our development environment from 4.2.2 to 4.2.5 and started noticing the server sendin

[SR-Users] ASYNC Module

2015-06-12 Thread Aaron Hamstra
We just updated our development environment from 4.2.2 to 4.2.5 and started noticing the server sending a 500 I'm terribly sorry, server error occurred (1/TM) error back as soon as the async_route block gets called. I have removed everything from our async route other than an xlog statement try

Re: [SR-Users] Async module taking down our server

2015-01-30 Thread Will Ferrer
Hi Brandon The feature fixed some issues one of our clients auto dialer were having. I hope you have a great weekend. All the best. Will On Thu, Jan 29, 2015 at 5:06 AM, Brandon Armstead wrote: > Why not just kill the call and have billing fix up for minimum duration > occur during CDR creat

Re: [SR-Users] Async module taking down our server

2015-01-29 Thread Brandon Armstead
Why not just kill the call and have billing fix up for minimum duration occur during CDR creation? Does not make sense to delay Hangup just to meet minimum duration. Sent from my iPhone > On Jan 28, 2015, at 5:37 PM, Will Ferrer wrote: > > Hi Daniel > > Yeah I am happy to be able to report

Re: [SR-Users] Async module taking down our server

2015-01-28 Thread Will Ferrer
Hi Daniel Yeah I am happy to be able to report the success. Thanks for everything as always! I hope you are well. Will On Wed, Jan 28, 2015 at 5:54 AM, Daniel-Constantin Mierla wrote: > Hello, > > great that it was sorted out and it was not on Kamailio side :-) > > Also, glad to hear that as

Re: [SR-Users] Async module taking down our server

2015-01-28 Thread Daniel-Constantin Mierla
Hello, great that it was sorted out and it was not on Kamailio side :-) Also, glad to hear that async processing did increase capacity to handle more concurrent calls, even it was causing troubles to other applications ... Cheers, Daniel On 28/01/15 05:40, Will Ferrer wrote: > Hello > > I wante

Re: [SR-Users] Async module taking down our server

2015-01-27 Thread Will Ferrer
Hello I wanted to give an update on this. My business partner that found the issue and has been monitoring the problem has tracked down the issue. It turns out that the features we implemented using the async module were leading to more calls going on con currently (as they were intended to) and

[SR-Users] Async module taking down our server

2015-01-19 Thread Will Ferrer
Hi All We are trying to use the async module to to delay sending a bye on from one end of the call to the other. We are using async_route(routename, seconds) to delay the WITHINDLG route. The idea is that in the future we want to be able to have our billing min duration enforced (though currently