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(a)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
I'm trying to finish developing a kamailio server cluster using database replication (db_mode=3). One of the issues is "split brain" when there is network connection problem that prevents the database servers from replicating data to each other for some time. This is especially bad for the serial int type primary keys defined in current kamailio tables. When there is a conflict in serial int primary keys, the record with the latest timestamp would win, but that record may not always be the correct one, or may not even for the same user. It seem the best solution to this problem is to use globally unique id as primary key instead of serial int.
I have tried to change the id in location table from serial int to uuid, and tested with pjsib clients. Things seem to work. uuid is supported by most common databases now (postgresql and mysql at least). Wonder if it is a good idea to change all serial int to uuid for all kamailio tables. I didn't verify all modules, but it seems the db modules can handle all db types without any code change. If I missed anything, or there is some spot we need to make code change, please let me know.
Here is the change I made to location table (postgresql).
current id:
id SERIAL PRIMARY KEY NOT NULL,
to:
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/274
Module: kamailio
Branch: master
Commit: b48bbd377a9dd9c8d18e4f6642f785659848ff2c
URL: https://github.com/kamailio/kamailio/commit/b48bbd377a9dd9c8d18e4f6642f7856…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2015-08-07T10:39:04+02:00
Merge pull request #277 from fredposner/master
etc: simple typo fixes in kamailio.cfg
---
Modified: etc/kamailio.cfg
---
Diff: https://github.com/kamailio/kamailio/commit/b48bbd377a9dd9c8d18e4f6642f7856…
Patch: https://github.com/kamailio/kamailio/commit/b48bbd377a9dd9c8d18e4f6642f7856…
---
diff --git a/etc/kamailio.cfg b/etc/kamailio.cfg
index 1190e80..e906795 100644
--- a/etc/kamailio.cfg
+++ b/etc/kamailio.cfg
@@ -546,7 +546,7 @@ route[RELAY] {
# Per SIP request initial checks
route[REQINIT] {
#!ifdef WITH_ANTIFLOOD
- # flood dection from same IP and traffic ban for a while
+ # flood detection from same IP and traffic ban for a while
# be sure you exclude checking trusted peers, such as pstn gateways
# - local host excluded (e.g., loop to self)
if(src_ip!=myself) {
@@ -721,7 +721,7 @@ route[PRESENCE] {
return;
}
-# IP authorization and user uthentication
+# IP authorization and user authentication
route[AUTH] {
#!ifdef WITH_AUTH
@@ -771,7 +771,7 @@ route[NATDETECT] {
return;
}
-# RTPProxy control and singaling updates for NAT traversal
+# RTPProxy control and signaling updates for NAT traversal
route[NATMANAGE] {
#!ifdef WITH_NAT
if (is_request()) {
@@ -827,7 +827,7 @@ route[PSTN] {
#!ifdef WITH_PSTN
# check if PSTN GW IP is defined
if (strempty($sel(cfg_get.pstn.gw_ip))) {
- xlog("SCRIPT: PSTN rotuing enabled but pstn.gw_ip not defined\n");
+ xlog("SCRIPT: PSTN routing enabled but pstn.gw_ip not defined\n");
return;
}