Hello, apparently all the db operations to update/delete contacts are done by matching on username, contact, call-id and domain (when use_domain=1) -- it is like this for way many years, therefore needs some debate if/how to change. While the module has a matching_mode parameter for various contact matching algorithms, it is used for in-memory matching only. - http://kamailio.org/docs/modules/stable/modules/usrloc.html#matching-mode IIRC, for initial SIP specs (with no GRUU extensions, etc), aor contact address should be used for matching. Call-Id has a relevance only when CSeq is lower than previous received REGISTER with same call-id. Do I miss any specs requirements? Following the report on tracker FS#278, matching on path value for db ops will be probably very inefficient. Matching on call id for this case should be sufficient if the REGISTER comes from different UA. Can it happen that same UA sends same REGISTER via two paths? With this question I mean if anyone is aware of an UA able to do this. Relying on previous hop address to use in the db key, would not be enough, as the different path can be in the hops before. I plan to keep for now call-id for db operations when matching mode involves path, one way to fix it properly could be usage of ruid as db key, but needs further analysis. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com