THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#485 - error updating UAC register record
User who did this - Daniel-Constantin Mierla (miconda)
----------
Thanks for troubleshooting and pointing the solution, a fix was pushed to master and 4.2 branches -- hash ids are computed always to be available whenever a new extension there will need them.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=485#comment1680
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Hello,
being brought in discussions many times, including in the recent past
days, I replaced the static define of max branches limit with a core
parameter. It impacts the destination set stored in core and the uac
fields stored in transaction.
It can be set now with global parameter: max_branches
The old limit was 12, now it can be set in the range of 1 to 31.
Few aspects that I would like to discuss to get this refactored to fit
the best of common scenarios:
1) the 31 upper limit comes from tm cancelled branches bitmask, which
now is stored in an integer. Should be easy to get it to 63 (planned
after some testing that proves the concept used now is ok). Would it be
a need for even more?
2) would it make sense to specify the max number of branches per
transaction, in config, before creating the transaction? The upper limit
will be the max_branches value from the core.
3) thinking of common cases of what can be forked a lot, I thought that
we can a simplification of 2) by specifying two limits: one for initial
requests which are very likely to have many branches (think of initial
INVITE via LCR or location) and one for requests within dialog which are
likely to have one or very few branches (e.g., replicating BYE to a peer
server). Opinions?
The main benefit for 2) and 3) would be less memory usage.
Testing and feedback of the new max_branches parameter is very appreciated.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Savolainen Dmitri (snen)
Attached to Project - sip-router
Summary - error updating UAC register record
Task Type - Bug Report
Category - Module
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Medium
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - can’t update existing UAC register record
<code>
[root@sw4 sbin]# ./kamcmd uac.reg_refresh s:000105480
error: 500 - Failed to refresh record - check log messages
</code>
reg->h_user is not initialized berfore using in “reg_ht_update_password“. possible patch is
<code>
diff --git a/modules/uac/uac_reg.c b/modules/uac/uac_reg.c
index 9b2abef..694e8fc 100644
--- a/modules/uac/uac_reg.c
+++ b/modules/uac/uac_reg.c
@@ -543,7 +543,8 @@ int reg_ht_update_password(reg_uac_t *reg)
return -1;
}
- slot = reg_get_entry(reg->h_user, _reg_htable->htsize);
+ unsigned int hash = reg_compute_hash(®->l_username);
+ slot = reg_get_entry(hash, _reg_htable->htsize);
lock_get(&_reg_htable->entries[slot].lock);
ri = _reg_htable->entries[slot].byuser;
while(ri) {
</code>
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=485
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.