Running 4.3.x (both .1 and .2) I have seen it happening twice sofar that dialogs (the module) will not end, resulting in to calls failing due to call limits based on active dialogs. Accounting logged a BYE for all these calls.
kamcmd tm.stats shows an increasing number of current/waiting transactions (as grphed in attachment).
Has anyone seen this problem?
On 10/07/2015 11:48 AM, Daniel Tryba wrote:
Accounting logged a BYE for all these calls.
Was the BYE statefully processed?
On Wednesday 07 October 2015 11:55:34 Alex Balashov wrote:
Accounting logged a BYE for all these calls.
Was the BYE statefully processed?
All I can say, based on acc, is it was processed.
But maybe not according to this logs: ERROR: tm [t_fwd.c:755]: add_uac(): ERROR: add_uac: maximum number of branches exceeded ERROR: tm [t_fwd.c:1711]: t_forward_nonack(): ERROR: t_forward_nonack: failure to add branches ERROR: tm [tm.c:1466]: _w_t_relay_to(): ERROR: w_t_relay_to: t_relay_to failed ERROR: sl [sl_funcs.c:363]: sl_reply_error(): ERROR: sl_reply_error used: Forking capacity exceeded (12/SL)
uac_replace_from/to is being used, this config always worked fine with pre-4.3.0 releases.
How many outgoing branches can there be? More than 12?
Daniel
On 07/10/15 18:07, Daniel Tryba wrote:
On Wednesday 07 October 2015 11:55:34 Alex Balashov wrote:
Accounting logged a BYE for all these calls.
Was the BYE statefully processed?
All I can say, based on acc, is it was processed.
But maybe not according to this logs: ERROR: tm [t_fwd.c:755]: add_uac(): ERROR: add_uac: maximum number of branches exceeded ERROR: tm [t_fwd.c:1711]: t_forward_nonack(): ERROR: t_forward_nonack: failure to add branches ERROR: tm [tm.c:1466]: _w_t_relay_to(): ERROR: w_t_relay_to: t_relay_to failed ERROR: sl [sl_funcs.c:363]: sl_reply_error(): ERROR: sl_reply_error used: Forking capacity exceeded (12/SL)
uac_replace_from/to is being used, this config always worked fine with pre-4.3.0 releases.
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
On Wednesday 07 October 2015 18:19:25 Daniel-Constantin Mierla wrote:
How many outgoing branches can there be? More than 12?
I didn't configure this, so the default whatever that is. There are no explicit branches, the called trunk might have more that 1 AoR, so there may be parallel forks.
This worked fine for a couple of million testcalls, but field testing with an actual trunk that makes less that 100 calls per day this problem triggered twice in 3 weeks (out of nowhere as far as I can see).
Can you add log_prefix to print the callid, message type (request/reply) and cseq header with each log message? That should reveal what sip message is processed when such case happens.
I will look also at the code, maybe the stats are not decreased in such case. If the transactions are staying in memory, then the share memory usage is going to increase as well. Have you observed share memory evolution?
Cheers, Daniel
On 07/10/15 18:52, Daniel Tryba wrote:
On Wednesday 07 October 2015 18:19:25 Daniel-Constantin Mierla wrote:
How many outgoing branches can there be? More than 12?
I didn't configure this, so the default whatever that is. There are no explicit branches, the called trunk might have more that 1 AoR, so there may be parallel forks.
This worked fine for a couple of million testcalls, but field testing with an actual trunk that makes less that 100 calls per day this problem triggered twice in 3 weeks (out of nowhere as far as I can see).
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
On Wednesday 07 October 2015 19:54:43 Daniel-Constantin Mierla wrote:
Can you add log_prefix to print the callid, message type (request/reply) and cseq header with each log message? That should reveal what sip message is processed when such case happens.
Will do.
I will look also at the code, maybe the stats are not decreased in such case. If the transactions are staying in memory, then the share memory usage is going to increase as well. Have you observed share memory evolution?
Yes, the (shared) memory used shows the same trend as tm.current/number of dialogs. See attachment. Interesting is the spike in usage a couple of hours before the problems appear. I'll try to see what the cause was.
-
Alex Balashov -
Daniel Tryba -
Daniel-Constantin Mierla