6 Aug
2015
6 Aug
'15
10:21 p.m.
First, a spec reference: https://tools.ietf.org/html/rfc3261#section-10.2.4
A UA SHOULD use the same Call-ID for all registrations
during a single boot cycle.
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](http://kamailio.org/docs/modules/4.2.x/modules/usrloc.html#usrloc.p….
In a repeat registration scenario like this:
~15:32:28
```
REGISTER sip:ben-test.callix.com.br SIP/2.0
Call-ID: aa26998a7a2648a6243a11eda51a3aa6(a)172.31.31.221
CSeq: 2 REGISTER
From:
<sip:destination_007@ben-test.callix.com.br>;tag=61616278_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To: <sip:destination_007@ben-test.callix.com.br>
Max-Forwards: 70
Contact: <sip:destination_007@172.31.31.221:5080>
User-Agent: Callix/Click2Call
Expires: 180
Via: SIP/2.0/UDP
chandler.localdomain:5080;branch=z9hG4bK13a609f6-c985-463b-b43f-ac43090d221e_7c77d0dd_e6dd0acb-255f-4c1c-afe6-67a360a7f581
Authorization: Digest
username="destination_007",realm="ben-test.callix.com.br",nonce="VcItt1XCLIsaLIdqq1Uo9wYmRIbpfQhP",uri="sip:ben-test.callix.com.br",response="0a014dd4613deb4b89fc9457d43d5cee"
Route: <sip:registrar.oneclick.callix.com.br;lr>
Content-Length: 0
SIP/2.0 200 OK
Call-ID: aa26998a7a2648a6243a11eda51a3aa6(a)172.31.31.221
CSeq: 2 REGISTER
From:
<sip:destination_007@ben-test.callix.com.br>;tag=61616278_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To:
<sip:destination_007@ben-test.callix.com.br>;tag=b27e1a1d33761e85846fc98f5f3a7e58.73ee
Via: SIP/2.0/UDP
chandler.localdomain:5080;branch=z9hG4bK13a609f6-c985-463b-b43f-ac43090d221e_7c77d0dd_e6dd0acb-255f-4c1c-afe6-67a360a7f581;received=172.31.31.221
Contact: <sip:destination_007@172.31.31.221:5080>;expires=180
Supported: outbound
Server: kamailio (4.1.6 (x86_64/linux))
Content-Length: 0
```
~15:34:28
```
REGISTER sip:ben-test.callix.com.br SIP/2.0
Call-ID: d6a13584901f0336dd9f877f125f1574(a)172.31.31.221
CSeq: 2 REGISTER
From:
<sip:destination_007@ben-test.callix.com.br>;tag=10060555_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To: <sip:destination_007@ben-test.callix.com.br>
Max-Forwards: 70
Contact: <sip:destination_007@172.31.31.221:5080>
User-Agent: Callix/Click2Call
Expires: 180
Via: SIP/2.0/UDP
chandler.localdomain:5080;branch=z9hG4bK13a609f6-c985-463b-b43f-ac43090d221e_7c77d0dd_4c667124-f13e-4bae-b637-4f19472bd417
Authorization: Digest
username="destination_007",realm="ben-test.callix.com.br",nonce="VcIuMFXCLQQbB0Z4Q92WkVEu4iM2wjU3",uri="sip:ben-test.callix.com.br",response="8161b70052e50a5e3f51a843080c1eac"
Route: <sip:registrar.oneclick.callix.com.br;lr>
Content-Length: 0
SIP/2.0 200 OK
Call-ID: d6a13584901f0336dd9f877f125f1574(a)172.31.31.221
CSeq: 2 REGISTER
From:
<sip:destination_007@ben-test.callix.com.br>;tag=10060555_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To:
<sip:destination_007@ben-test.callix.com.br>;tag=b27e1a1d33761e85846fc98f5f3a7e58.6229
Via: SIP/2.0/UDP
chandler.localdomain:5080;branch=z9hG4bK13a609f6-c985-463b-b43f-ac43090d221e_7c77d0dd_4c667124-f13e-4bae-b637-4f19472bd417;received=172.31.31.221
Contact: <sip:destination_007@172.31.31.221:5080>;expires=180
Supported: outbound
Server: kamailio (4.1.6 (x86_64/linux))
Content-Length: 0
```
I see the following queries in the Kamailio logs:
```
Aug 5 15:32:28 lexington /usr/sbin/kamailio[12366]: DEBUG: db_postgres [km_dbase.c:230]:
db_postgres_submit_query(): sending query ok: 0x7fc5155669a0 (1) - [insert into location
(username,contact,expires,q,callid,cseq,flags,cflags,user_agent,received,path,socket,methods,last_modified,ruid,instance,reg_id,domain
) values
('destination_007','sip:destination_007@172.31.31.221:5080','2015-08-05
15:35:28',-1.00
,'aa26998a7a2648a6243a11eda51a3aa6@172.31.31.221',2,0,0,'Callix/Click2Call',NULL,NULL,'udp:172.31.26.82:5060',NULL,'2015-08-05
15:32:28','uloc-55c220c7-304e-96',NULL,0,'ben-test.callix.com.br')]
Aug 5 15:34:28 lexington /usr/sbin/kamailio[12364]: DEBUG: db_postgres [km_dbase.c:230]:
db_postgres_submit_query(): sending query ok: 0x7fc5155669a0 (2) - [select
contact,expires,q,callid,cseq,flags,cflags,user_agent,received,path,socket,methods,last_modified,ruid,instance,reg_id
from location where username='destination_007' AND
domain='ben-test.callix.com.br' order by q]
Aug 5 15:34:28 lexington /usr/sbin/kamailio[12364]: DEBUG: db_postgres [km_dbase.c:230]:
db_postgres_submit_query(): sending query ok: 0x7fc5155669a0 (1) - [update location set
expires='2015-08-05 15:37:28',q=-1.00
,cseq=2,flags=0,cflags=0,user_agent='Callix/Click2Call',received=NULL,path=NULL,socket='udp:172.31.26.82:5060',methods=NULL,last_modified='2015-08-05
15:34:28',ruid='uloc-55c220c7-304e-96',instance=NULL,reg_id=0,contact='sip:destination_007@172.31.31.221:5080'
where username='destination_007' AND
contact='sip:destination_007@172.31.31.221:5080' AND
callid='d6a13584901f0336dd9f877f125f1574(a)172.31.31.221' AND
domain='ben-test.callix.com.br']
```
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 as `3`. I am using
Postgres.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/280
7 Aug
7 Aug
3:55 p.m.
Have you changed the maching_mode parameter for usrloc module:
* http://kamailio.org/docs/modules/stable/modules/usrloc.html#usrloc.p.matchi…
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/280#issuecomment-128692897
4:02 p.m.
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?
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/280#issuecomment-128694275
4:08 p.m.
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-matchin…
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/280#issuecomment-128695228
4:12 p.m.
@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 `contact only` mode would fail on UA
restart. What am I missing?
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/280#issuecomment-128695881
4:14 p.m.
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.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/280#issuecomment-128696195
4:22 p.m.
My suggestion, I think, is that `contact only` matching should apply both to the `SELECT`
and `UPDATE` queries. If this were the case in this scenario, the `UPDATE` statement would
have succeeded. Right now it's a no-op because the Call-ID doesn't match.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/280#issuecomment-128697763
4:38 p.m.
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?
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/280#issuecomment-128700933
4:46 p.m.
The SQL queries are above in the original bug report.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/280#issuecomment-128702978
4:50 p.m.
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.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/280#issuecomment-128703772
4:57 p.m.
I fixed that!
56b54a5767a3ad0df446fe181aee0ee5fd64276d
e8a795a6a413ae453f619e3deaf36c26b85b0077
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/280#issuecomment-128706816
4:59 p.m.
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.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/280#issuecomment-128707734
6:09 p.m.
Closed #280.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/280#event-376412049
3402
days inactive
3403
days old
12 comments
4 participants
participants (4)
-
Ben Langfeld -
Daniel-Constantin Mierla
-
Fred Posner
-
Victor Seva