18 Jan
2012
18 Jan
'12
4:17 p.m.
Hello,
On 1/18/12 12:50 PM, Giacomo Vacca wrote:
Well, the issue of using db_text might be with storing the xml documents
(publish body) in presence table. db_text keeps a raw per line in a text
file.
Cheers,
Daniel
U 2012/01/18 21:52:40.729795 127.0.0.1:57982 -> 127.0.0.1:5060
REGISTER sip:127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 127.0.1.1:5080;branch=z9hG4bK.29f7bb6d;rport;alias.
From: sip:test@127.0.0.1;tag=41f6277b.
To: sip:test@127.0.0.1.
Call-ID: 1106651003(a)127.0.1.1.
CSeq: 1 REGISTER.
Content-Length: 0.
Max-Forwards: 70.
User-Agent: sipsak 0.9.6.
Expires: 70.
Contact: sip:test@127.0.1.1:5080.
.
U 2012/01/18 21:52:40.732876 127.0.0.1:5060 -> 127.0.0.1:5060
PUBLISH sip:test@127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK25a7.88a7c0d5.0.
To: sip:test@127.0.0.1.
From: sip:test@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-76e3.
CSeq: 10 PUBLISH.
Call-ID: 53162b3d3a4cff50-20164(a)127.0.0.1.
Content-Length: 339.
User-Agent: kamailio (3.3.0-dev5 (x86_64/linux)).
Max-Forwards: 70.
Event: presence.
Expires: 71.
Content-Type: application/pidf+xml.
.
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:c="urn:ietf:params:xml:ns:pidf:cipid"
entity="test(a)127.0.0.1">
<tuple id="0x7f6352b80eb0">
<status>
<basic>open</basic>
</status>
</tuple>
</presence>
U 2012/01/18 21:52:40.733052 127.0.0.1:5060 -> 127.0.0.1:57982
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
127.0.1.1:5080;branch=z9hG4bK.29f7bb6d;rport=57982;alias;received=127.0.0.1.
From: sip:test@127.0.0.1;tag=41f6277b.
To: sip:test@127.0.0.1;tag=b27e1a1d33761e85846fc98f5f3a7e58.12b3.
Call-ID: 1106651003(a)127.0.1.1.
CSeq: 1 REGISTER.
Contact: <sip:test@127.0.1.1:5080>;expires=70.
Server: kamailio (3.3.0-dev5 (x86_64/linux)).
Content-Length: 0.
.
U 2012/01/18 21:52:40.740026 127.0.0.1:5060 -> 127.0.0.1:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK25a7.88a7c0d5.0.
To: sip:test@127.0.0.1;tag=a6a1c5f60faecf035a1ae5b6e96e979a-0f93.
From: sip:test@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-76e3.
CSeq: 10 PUBLISH.
Call-ID: 53162b3d3a4cff50-20164(a)127.0.0.1.
Expires: 71.
SIP-ETag: a.1326919182.20164.3.0.
Server: kamailio (3.3.0-dev5 (x86_64/linux)).
Content-Length: 0.
.
U 2012/01/18 21:53:01.800384 127.0.0.1:36942 -> 127.0.0.1:5060
REGISTER sip:127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 127.0.1.1:5080;branch=z9hG4bK.55f81f68;rport;alias.
From: sip:test@127.0.0.1;tag=2f3b5433.
To: sip:test@127.0.0.1.
Call-ID: 792417331(a)127.0.1.1.
CSeq: 1 REGISTER.
Content-Length: 0.
Max-Forwards: 70.
User-Agent: sipsak 0.9.6.
Expires: 0.
Contact: sip:test@127.0.1.1:5080.
.
U 2012/01/18 21:53:01.802227 127.0.0.1:5060 -> 127.0.0.1:5060
PUBLISH sip:test@127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK2bad.75340815.0.
To: sip:test@127.0.0.1.
From: sip:test@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-e8e8.
CSeq: 10 PUBLISH.
Call-ID: 53162b3d3a4cff51-20163(a)127.0.0.1.
Content-Length: 0.
User-Agent: kamailio (3.3.0-dev5 (x86_64/linux)).
Max-Forwards: 70.
Event: presence.
Expires: 0.
SIP-If-Match: a.1326919182.20164.3.0.
.
U 2012/01/18 21:53:01.802366 127.0.0.1:5060 -> 127.0.0.1:36942
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
127.0.1.1:5080;branch=z9hG4bK.55f81f68;rport=36942;alias;received=127.0.0.1.
From: sip:test@127.0.0.1;tag=2f3b5433.
To: sip:test@127.0.0.1;tag=b27e1a1d33761e85846fc98f5f3a7e58.a177.
Call-ID: 792417331(a)127.0.1.1.
CSeq: 1 REGISTER.
Server: kamailio (3.3.0-dev5 (x86_64/linux)).
Content-Length: 0.
.
U 2012/01/18 21:53:01.806937 127.0.0.1:5060 -> 127.0.0.1:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK2bad.75340815.0.
To: sip:test@127.0.0.1;tag=a6a1c5f60faecf035a1ae5b6e96e979a-2698.
From: sip:test@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-e8e8.
CSeq: 10 PUBLISH.
Call-ID: 53162b3d3a4cff51-20163(a)127.0.0.1.
Expires: 0.
SIP-ETag: a.1326919182.20164.3.0.
Server: kamailio (3.3.0-dev5 (x86_64/linux)).
Content-Length: 0.
.
Thanks Daniel,
I tested with default config, where I enabled mysql and presence
service, plus loaded and configured pua and pua_usrloc similar to your
snippet. All seemed ok, I pasted the ngrep to the end of my reply, first
for register and then for un-register.
In your case, is the publish for registration getting 200ok?
can you switch to nightly builds from branch 3.2
just to be sure it
is not related to something that was fixed since 3.2.0 was
released?
I've switched and now have installed 3.2.1, and moved to sqlite too.
I've spent some time to verify a change in behaviour, but I'm
observing the same.
Registering with a different device (e.g. sipp) gives the same result.
db_text is not
really suitable for dealing with large data and write
to disk when the sip server
is shut down, maybe it is better to use
db_sqlite for this case, at least you can check the content of the db
table with sqlite tools.
My current goal is a proof of concept so I'm not concerned about
performances -- am I right in thinking that the problem in finding the
presentity in pua's hash table is independent from the DB usage, or
may it have an impact?