29 Mar
2013
29 Mar
'13
8:18 a.m.
29 mar 2013 kl. 11:44 skrev Daniel-Constantin Mierla <daniel(a)asipto.com>om>:
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