Closed benlangfeld closed 9 years ago
@benlangfeld please move this to the upstream: https://github.com/kamailio/kamailio/
oO Sorry! I always thought this was the upstream repo. Perhaps you could add it to the repo description which currently reads "Kamailio SIP Proxy with Sipwise patches http://www.kamailio.org/" to make it more obvious?
Re-filed as https://github.com/kamailio/kamailio/issues/280. Thanks @linuxmaniac
First, a spec reference: https://tools.ietf.org/html/rfc3261#section-10.2.4
On the surface is is then reasonable for Kamailio to default to contact lookup by contact and Call-ID. It does, however, default to contact only lookup.
In a repeat registration scenario like this:
~15:32:28
~15:34:28
I see the following queries in the Kamailio logs:
Evidently the contact-only nature of usrloc lookup is not being respected when a follow-up registration is attempted. This means that every pre-expiry registration for a static contact from a UA which does not comply with RFC3621's normative
SHOULD
will silently fail. This is not a big deal; most do comply and I could fix mine to comply.What is a bigger deal is that if the UA is restarted, it is not to be reasonably expected to maintain the same CallID. It will use a new CallID (precisely the same way as my "faulty" UA does) on its first registration. If this occurs while there is an active registration for the same Contact, this new registration will effectively be ignored.
I think, though I'm likely to be corrected, that we should only be including the CallID in the UPDATE's WHERE clause if we used it in the SELECT and got a result. In my "faulty" UA case, this would at least leave me with duplicate registrations rather than 0 registrations. I could then follow the normative
SHOULD
and eliminate the duplication.Caveat that I have only tested with usrloc's
dbmode
parameter as3
. I am using Postgres.