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/e6ad428f6699621b7ee622984eeea3e…). 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 2^nd issue yet. Is it too late to get these into 4.3.0? Regards, Hugh ------------------------------------------------------------------------ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding. _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev