Hello Daniel / List,
I think I have found some issues with the
usrloc/serial forking/ul attributes functionality. I hope the
following explanation is not too complicated!
The registrar.lookup() function loads
contacts into the ruri and branch[] structures. If there are
ulattrs associated with the record, these are loaded into an
XAVP indexed by branch.
This means that if I immediately run
t_relay(), I can use $xavp(ulattrs[$T_branch_idx]=>key) in
the branch_route to access per-location attributes.
Issue 1:
As far as I see, if I run t_load_contacts()
& t_next_contacts(), the ulattrs XAVP stack is not loaded
along with the branches and may cause the branches and ulattrs
XAVP to be mismatched. I believe the fix is to load each XAVP
along with the branch info, and then reassign back to the
correct index in t_next_contacts/t_next_contact_flow. Does
this sound correct?
Issue 2:
When a usrloc contact record is created,
the XAVP associated with each contact is cloned from the
existing ‘ulattrs’ XAVP if one is already attached to the
transaction. The code in usrloc/ucontact.c lines 53-84 does
this cloning and was added by Daniel in Dec 2012 as part of
the original xavp feature (https://github.com/kamailio/kamailio/commit/e6ad428f6699621b7ee622984eeea3e3e2f6cb80/modules_k/usrloc/ucontact.c).
This code is used when save() is called, to
store the attributes into the record before saving to the
database.
It is also run when lookup() is called and
in some cases this can lead to the attributes loaded from the
database being discarded or incorrect ones being cloned. I
need this xavp cloning to be turned off on a lookup. Was the
intention to have the option to clone changeable depending on
where it was called from? There is a function to set the
option, but it is never called from anywhere.
I don’t have a fix for the 2nd
issue yet. Is it too late to get these into 4.3.0?
Regards,
Hugh