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.matching_mode).
In a repeat registration scenario like this:
~15:32:28
```
REGISTER sip:ben-test.callix.com.br SIP/2.0
Call-ID: [email protected]
CSeq: 2 REGISTER
From:
<sip:[email protected]>;tag=61616278_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To: <sip:[email protected]>
Max-Forwards: 70
Contact: <sip:[email protected]: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: [email protected]
CSeq: 2 REGISTER
From:
<sip:[email protected]>;tag=61616278_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To:
<sip:[email protected]>;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:[email protected]: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: [email protected]
CSeq: 2 REGISTER
From:
<sip:[email protected]>;tag=10060555_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To: <sip:[email protected]>
Max-Forwards: 70
Contact: <sip:[email protected]: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: [email protected]
CSeq: 2 REGISTER
From:
<sip:[email protected]>;tag=10060555_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To:
<sip:[email protected]>;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:[email protected]: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:[email protected]:5080','2015-08-05
15:35:28',-1.00
,'[email protected]',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:[email protected]:5080'
where username='destination_007' AND
contact='sip:[email protected]:5080' AND
callid='[email protected]' 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_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
