New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kamailio not compatible with registration refresh by lax UAs #280
Comments
Have you changed the maching_mode parameter for usrloc module: |
I have not, @miconda, because that would be only a workaround for this bug, rather than a solution. My claim is that the current configuration should work. Am I mistaken? |
I don't think it's a work around but rather a way of handling RFC 3261 via strict adhesion or lessened for non-compliant UAs, etc as described in http://kamailio.org/docs/modules/stable/modules/usrloc.html#contact-matching-algs |
@fredposner Do you have any more details regarding "so be careful how you deal with REGISTER retransmissions in this case"? Also, even considering a UA which is compliant with RFC3261's recommendation, the |
What do you refer as current configuration? Default config? The fact is that many options in various modules are there to cope with real world, rather than specs. If implementing strictly the specs, it will be very rare cases when all it works -- eg, nat traversal, by specs sdp should not changed, therefore rtp relaying is not something 'compliant'. If you try to suggest that some other value should be the default one, then it is ok, I am open to discuss and change it. but i think that should be done on users mailing list to get the feedback of what is most common/most desired option. |
My suggestion, I think, is that |
A quick check in the code and the UPDATE is using only contact. No call-id involved. Have you checked with the source code or grabbed the sql queries that showed call-id being used? |
The SQL queries are above in the original bug report. |
Indeed -- the log messages went out of view size, needing scrolling. However, the issue has been fixed, the code is ok. You probably run an old version, upgrade to latest version in 4.1. |
Oh, how embarrassing. I guess this server might not have got updated :/ Sorry guys, I'll make sure my house is in order again and close this assuming it is indeed fixed. |
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.The text was updated successfully, but these errors were encountered: