You were right, thanks a lot for the report and fix, it is fixed in cvs
now.
Jan.
On 02-05-2005 14:34, Cesc Santasusana wrote:
Hi,
I think i found it!
I attach three files ... the most important i think is lookup.c.registered_func.c.
It contains a modified version of registered() function in lookup.c (registrar module),
in which after obtaining the urecord from the database, all the contacts that it contains
are checked for validity (which was not done before!!). I think that this is the cause of
lookup and registered not returning the same values. Lookup() returned the correct value,
registered() did not. Now, they both return the same ... i mean ... they both return the
correct value :)
The problem was small, in the transition period (in db_mode=1) when the user deregisters
and SER still has not erased the contact from the location table (it keeps it in
CS_ZOMBIE_S in mode=1, _D in mode=2).
The other two files are a dump of the location table and a piece of the SER log file.
Version is 0.9.0.
Regards,
Cesc
>> Jan Janak <jan(a)iptel.org> 04/29/05
03:08PM >>>
On 28-04-2005 17:03, Cesc Santasusana wrote:
Hi,
After de-registration, a contact in the location table is marked as zombie, and after
some time, it is deleted from the table. Right?
You should not see any contacts in a ZOMBIE_* state. zombie states
were used for user location replication some time ago with a special
module.
If you use db_mode 2 then the contacts should appear as SYNC or DIRTY
in the location table and they will be deleted after a while by timer.
Ok, what happens when this user receives a call
... i mean, he is in the location table (as zombie), but he is not registered really on
the phone?
He will not receive the message, because in the memory cache the
contact is marked as deleted.
What do the lookup('location") and
registered('location") in this scenario return?
If the user does not have any other contact registered then they will
return a negative value.
In my config ... a first call to lookup(loc)
returns false, and then calling registered(loc) returns true. Is that right? Shouldn't
the two functions do the same, just lookup rewrites the uri?
They should return the same value. If that does not happen then there
is a bug somewhere, in which case I would like to ask you to provide
me with more information (SER version, dump of the location table,
and so on).
Jan.
Unclassified
# User "gerben" still registerd
#
#
root@cesc:/sip/ser/cafesConf/> serctl ul show
DB backend selected (SER_DB): dbtext
Path to dbtext backend DB (DBTEXT_PATH): /usr/local/etc/ser/dbtext
Dumping all contacts may take long: are you sure you want to proceed? [Y|N] y
===Domain list===
....Record(0x403d7578)...
domain: 'aliases'
..../Record...
---/Domain---
---Domain---
....Record(0x403d40c8)...
domain: 'location'
aor : 'theo'
~~~Contact(0x403d4128)~~~
domain : 'location'
aor : 'theo'
Contact : 'sip:theo@192.0.2.249'
Expires : 3090
q :
Call-ID : '9c080cc-b231172e-e81d70f3(a)192.0.2.249'
CSeq : 386
replic : 0
User-Agent: 'PolycomSoundPointIP-SPIP_500-UA/1.4.1'
received : ''
State : CS_SYNC
Flags : 0
next : (nil)
prev : (nil)
~~~/Contact~~~~
..../Record...
....Record(0x403d4238)...
domain: 'location'
aor : 'gerben'
~~~Contact(0x403d4298)~~~
domain : 'location'
aor : 'gerben'
Contact : 'sip:gerben@192.0.2.250:5062;transport=udp'
Expires : 448
q :
Call-ID : '810911792(a)192.0.2.250'
CSeq : 6289
replic : 0
User-Agent: 'kphone/4.1.0'
received : ''
State : CS_SYNC
Flags : 0
next : (nil)
prev : (nil)
~~~/Contact~~~~
..../Record...
---/Domain---
===/Domain list===
#Here, user gerben has unregistered. It still is in the table
#(db mode is 1).
root@cesc:/sip/ser/cafesConf/> serctl ul show
DB backend selected (SER_DB): dbtext
Path to dbtext backend DB (DBTEXT_PATH): /usr/local/etc/ser/dbtext
Dumping all contacts may take long: are you sure you want to proceed? [Y|N] y
===Domain list===
---Domain---
name : 'aliases'
....Record(0x403d7578)...
---/Domain---
---Domain---
name : 'location'
....Record(0x403d3f58)...
....Record(0x403d40c8)...
domain: 'location'
aor : 'theo'
~~~Contact(0x403d4128)~~~
domain : 'location'
aor : 'theo'
Contact : 'sip:theo@192.0.2.249'
Expires : 3063
q :
Call-ID : '9c080cc-b231172e-e81d70f3(a)192.0.2.249'
CSeq : 386
replic : 0
User-Agent: 'PolycomSoundPointIP-SPIP_500-UA/1.4.1'
received : ''
State : CS_SYNC
Flags : 0
next : (nil)
prev : (nil)
~~~/Contact~~~~
..../Record...
....Record(0x403d4238)...
domain: 'location'
aor : 'gerben'
~~~Contact(0x403d4298)~~~
domain : 'location'
aor : 'gerben'
Contact : 'sip:gerben@192.0.2.250:5062;transport=udp'
Expires : 421
q :
Call-ID : '810911792(a)192.0.2.250'
CSeq : 6289
replic : 0
User-Agent: 'kphone/4.1.0'
received : ''
State : CS_ZOMBIE_S
Flags : 0
next : (nil)
prev : (nil)
~~~/Contact~~~~
..../Record...
---/Domain---
===/Domain list===
#User gerben is still in location table ... no problem
2(12715) registered(): usrloc domain is #location#
2(12715) TOI: rewrite_uri: Rewriting Request-URI with
'sip:gerben@192.0.2.250:5062;transport=udp'
2(12715) LOG: lookup location is TRUE
2(12715) registered(): usrloc domain is #location#
2(12715) registered(): 'gerben' found in usrloc
#User gerben de-registers ... it gets marked as CS_ZOMBIE_S,
#and after a while, it is deleted. But, meanwhile it receives an INVITE,
#this is the log
2(12715) registered(): usrloc domain is #aliases#
2(12715) lookup(): 'gerben' Not found in usrloc
2(12715) lookup()(): usrloc domain is #location#
2(12715) LOG: lookup location is FALSE
2(12715) registered(): usrloc domain is #location#
2(12715) registered(): 'gerben' found in usrloc
5(12718) removing spare zombie (wt)
'gerben','sip:gerben@192.0.2.250:5062;transport=udp'
5(12718) DBT:dbt_delete: deleting a row!