[SR-Users] SIP contact matching - location db ops

[Olle E. Johansson]

29 mar 2013 kl. 11:44 skrev Daniel-Constantin Mierla <daniel at asipto.com>:

> 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.

To add to the mess, I would like the ability to match on sip.instance (the UUID). We need a mode where we can say "I want one registration per device" - meaning that if I get a new REGISTER for the same sip.instance (and the same outbound Reg-id) that needs to replace the old one.

One reg per device doesn't mean one contact though - we have reg-id's and possibly different address families, so that amounts to at least four contacts for one device/registration to one AOR.

/O