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 <bran...@cryy.com> wrote:
> 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 <will.fer...@switchsoft.com>
> wrote:
>
> 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 <
> mico...@gmail.com> wrote:
>
>> 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 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 this was causing and issue with
>> voip monitor. So the issue was not with the Async module.
>>
>> All the best.
>>
>> Will Ferrer
>>
>> Switchsoft
>>
>> On Mon, Jan 19, 2015 at 8:43 PM, Will Ferrer <will.fer...@switchsoft.com>
>> wrote:
>>
>>> 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 we are having
>>> issues with the dialog module that we are discussing in another thread).
>>>
>>> After running this on our deploy servers, the delays before sending on
>>> the byes get longer and longer, and then kamailio goes down. Then the
>>> receive udp buffer fills up.
>>>
>>> We tried it with both 4 and 400 async workers, and it made no difference.
>>>
>>> I am including a screen capture of the servers stats when this happens
>>> taken from voip monitor.
>>>
>>> Here are the relevant parts of the config:
>>>
>>> ...
>>> loadmodule "async.so"
>>> ...
>>> modparam("async", "workers", ASYNC_THREADS)
>>> ...
>>> request_route {
>>> ...
>>> route(DELAYED_BYE_STATIC);
>>> ...
>>> route[DELAYED_BYE_STATIC] {
>>> xlog("L_DEBUG","route DELAYED_BYE_STATIC");
>>> #!ifdef WITH_DELAYED_BYE_STATIC
>>> if (is_method("BYE")) {
>>> xlog("L_DEBUG","route DELAYED_BYE_STATIC, from self \n");
>>> #if (from_uri == myself) {
>>> if ((allow_trusted() || allow_source_address()) && from_uri == myself)
>>> {
>>> xlog("L_DEBUG","route DELAYED_BYE_STATIC, Bye detected, from self \n");
>>> send_reply("200", "OK");
>>> xlog("L_DEBUG","route DELAYED_BYE_STATIC, sent 200 about to sleep \n");
>>> setflag(FLT_ACC); # do accounting ...
>>> setflag(FLT_ACCFAILED); # ... even if the transaction fails
>>> if (has_totag()) {
>>> xlog("L_DEBUG","route DELAYED_BYE_STATIC, sleeping to
>>> WITHINDLG_DELAYED \n");
>>> async_route("WITHINDLG_DELAYED", MIN_DURATION);
>>> } else {
>>> xlog("L_DEBUG","route DELAYED_BYE_STATIC, sleeping to WITHINDLG \n");
>>> async_route("WITHINDLG", MIN_DURATION);
>>> }
>>> xlog("L_DEBUG","route DELAYED_BYE_STATIC, slept\n");
>>> exit;
>>> }
>>> }
>>> #!endif
>>> return;
>>> }
>>> ...
>>> route[WITHINDLG_DELAYED] {
>>> xlog("L_DEBUG", "route WITHINDLG_DELAYED: triggered \n");
>>> $avp(was_delayed) = 1;
>>> route(WITHINDLG);
>>> }
>>> ...
>>> route[WITHINDLG] {
>>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG triggered, request
>>> method: $rm \n");
>>> #!ifdef WITH_DISPATCHER
>>> if(is_method("BYE|CANCEL")) {
>>> xlog("L_DEBUG","route WITHINDLG: cancel or bye detected, request
>>> method: $rm \n");
>>> #!ifdef WITH_DISPATCHER_LOAD_AWARE
>>> xlog("L_DEBUG","route WITHINDLG: running ds_load_update, request
>>> method: $rm \n");
>>> ds_load_update();
>>> #dlg_get ("$ci","$ft","$tt");
>>> #dlg_bye ("all");
>>> #!endif
>>> }
>>> #!endif
>>>
>>> if (has_totag() || $avp(was_delayed) == 1) {
>>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG has totag or
>>> was_delayed: $avp(was_delayed) \n");
>>> # sequential request withing a dialog should
>>> # take the path determined by record-routing
>>> if (loose_route()) {
>>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG has loose route \n");
>>> route(DLGURI);
>>> if (is_method("BYE")) {
>>> xlog("L_DEBUG","route WITHINDLG: BYE detected");
>>> setflag(FLT_ACC); # do accounting ...
>>> setflag(FLT_ACCFAILED); # ... even if the transaction fails
>>> xlog("L_DEBUG","route WITHINDLG: ACC flag set");
>>> }
>>> else if ( is_method("ACK") ) {
>>> # ACK is forwarded statelessy
>>> route(NATMANAGE);
>>> }
>>> else if ( is_method("NOTIFY") ) {
>>> # Add Record-Route for in-dialog NOTIFY as per RFC 6665.
>>> record_route();
>>> }
>>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG RELAY 1\n");
>>> route(RELAY);
>>> } else {
>>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG else \n");
>>> if (is_method("SUBSCRIBE") && uri == myself) {
>>> # in-dialog subscribe requests
>>> route(PRESENCE);
>>> exit;
>>> }
>>> if ( is_method("ACK") ) {
>>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG is ack \n");
>>> if ( t_check_trans() ) {
>>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG t_check_trans \n");
>>> # no loose-route, but stateful ACK;
>>> # must be an ACK after a 487
>>> # or e.g. 404 from upstream server
>>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG RELAY 2\n");
>>> route(RELAY);
>>> exit;
>>> } else {
>>> # ACK without matching transaction ... ignore and discard
>>> exit;
>>> }
>>> }
>>> sl_send_reply("404","Not here");
>>> }
>>> exit;
>>> }
>>> }
>>> ...
>>>
>>>
>>>
>>> Does any one know if this is a bug or a leak with in the async module,
>>> or perhaps something I am doing in my config?
>>>
>>> Thanks in advance for an assistance you can offer me.
>>>
>>> All the best.
>>>
>>> Will Ferrer
>>> Switchsoft
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>> --
>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda -
>> http://www.linkedin.com/in/miconda
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users@lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
