On Thursday 08 October 2015 10:03:52 Daniel Tryba wrote:
> Yes, the (shared) memory used shows the same trend as tm.current/number of
> dialogs. See attachment.
BTW the graph contains the kamcmd core.shmmem stats (total/free/used).
___
SIP Express Rout
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
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
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.
Th
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 proce
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
On 10/07/2015 11:48 AM, Daniel Tryba wrote:
Accounting logged a BYE for all these calls.
Was the BYE statefully processed?
--
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
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 transa
