[sr-dev] Issues in usrloc and tm

[Daniel-Constantin Mierla]

Hi Hugh,

indeed, it could be better to keep usrloc attributes bound to the branch
structure. If you have a patch, then make a pull request to review and
merge.

For the 2nd issue, is it about save() or lookup() time? -- somehow I
didn't get it at first read and I will have to go out for a while.
Anyhow, again, if you get a patch, make a pull request, it might be
easier to understand after all.

It is still time to get fixes in 4.3 and bugs can be fixed any time.

Cheers,
Daniel

On 21/05/15 17:50, Waite, Hugh wrote:
>
> 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 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20150521/a3f05f30/attachment-0001.html>