[sr-dev] [kamailio] Kamailio not compatible with registration refresh by lax UAs (#280)

Ben Langfeld notifications at github.com
Thu Aug 6 21:21:29 CEST 2015


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: aa26998a7a2648a6243a11eda51a3aa6 at 172.31.31.221
CSeq: 2 REGISTER
From: <sip:destination_007 at ben-test.callix.com.br>;tag=61616278_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To: <sip:destination_007 at ben-test.callix.com.br>
Max-Forwards: 70
Contact: <sip:destination_007 at 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 at 172.31.31.221
CSeq: 2 REGISTER
From: <sip:destination_007 at ben-test.callix.com.br>;tag=61616278_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To: <sip:destination_007 at 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 at 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 at 172.31.31.221
CSeq: 2 REGISTER
From: <sip:destination_007 at ben-test.callix.com.br>;tag=10060555_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To: <sip:destination_007 at ben-test.callix.com.br>
Max-Forwards: 70
Contact: <sip:destination_007 at 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 at 172.31.31.221
CSeq: 2 REGISTER
From: <sip:destination_007 at ben-test.callix.com.br>;tag=10060555_117e27da_7c77d0dd_13a609f6-c985-463b-b43f-ac43090d221e
To: <sip:destination_007 at 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 at 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 at 172.31.31.221:5080','2015-08-05 15:35:28',-1.00     ,'aa26998a7a2648a6243a11eda51a3aa6 at 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 at 172.31.31.221:5080' where username='destination_007' AND contact='sip:destination_007 at 172.31.31.221:5080' AND callid='d6a13584901f0336dd9f877f125f1574 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20150806/ecf580e2/attachment.html>


More information about the sr-dev mailing list