18 Jan
2012
18 Jan
'12
10:53 a.m.
Hi all,
I've made a clean installation of kamailio 3.2.0 from
'http://deb.kamailio.org/kamailio32 squeeze main'
repository, on a squeeze debian machine (2.6.32-5-686).
Installed also kamailio-presence-modules, same version.
I'm just using the default kamailio.cfg that comes with the package, with these
minimal additions:
loadmodule "db_text.so"
loadmodule "pua.so"
loadmodule "pua_usrloc.so"
...
modparam("pua", "db_url",
"text:///usr/share/kamailio/dbtext/kamailio")
modparam("pua_usrloc", "default_domain", "192.168.142.130")
Inside the registration management logic I've added pua_set_publish() right before
saving the location:
route[REGISTRAR] {
if (is_method("REGISTER"))
{
...
pua_set_publish();
if (!save("location"))
sl_reply_error();
exit;
}
}
When I first register (XLite 4.1 for Windows), pua_usrloc correctly gets the callback and
is able to generate a PUBLISH request through pua.
But when there's an un-registration, or when the contact expires, even if the
callbacks are correctly fired, the PUBLISH (which I'd expect with status
'closed') is not generated.
From the logs (debug level 4), an un-registration:
8(7652) DEBUG: usrloc [ul_callback.h:89]: contact=0xb50ae7cc, callback type 4/4, id 3
entered
8(7652) DEBUG: pua_usrloc [ul_publish.c:216]:DELETE type
8(7652) DEBUG: pua_usrloc [ul_publish.c:255]: uri= sip:20701090@192.168.142.130
8(7652) DEBUG: pua_usrloc [ul_publish.c:66]: publ:
8(7652) DEBUG: pua_usrloc [ul_publish.c:67]: uri= sip:20701090@192.168.142.130
8(7652) DEBUG: pua_usrloc [ul_publish.c:68]:
id=UL_PUBLISH.NmY5Zjc2YjcwNzEwNTk4YTY1NzA2Y2Y0MWQyMGRhOGY.
8(7652) DEBUG: pua_usrloc [ul_publish.c:69]: expires= 0
8(7652) DEBUG: pua [send_publish.c:403]: pres_uri=sip:20701090@192.168.142.130
8(7652) DEBUG: pua [hash.c:121]: core_hash= 444
8(7652) DEBUG: pua [hash.c:174]: record not found
8(7652) DEBUG: pua [send_publish.c:444]: insert type
8(7652) DEBUG: pua [send_publish.c:448]: UPDATE_TYPE and no record found
8(7652) DEBUG: pua [send_publish.c:454]: request for a publish with expires 0 and no
record found
8(7652) DEBUG: sl [sl.c:278]: reply in stateless mode (sl)
As an additional information, the pua table in
/usr/share/kamailio/dbtext/kamailio/pua has not been populated.
The AOR was correctly displayed with 'ul show' while the registration was valid.
Any suggestion on what am I be doing wrong?
Would it be worth testing the same scenario using mysql as DB?
Thanks in advance for your time.
Giacomo
Truphone Limited is a limited liability company registered in England & Wales,
registered office: 5 New Street Square, London EC4A 3TW. Registered No. 04187081. VAT No.
GB 851 5278 19.
Tru is a brand name of Truphone and is a Truphone Communications Service. Truphone is a
trading name for a number of distinct legal entities that operate in combination.
www.truphone.com<http://www.truphone.com>om>.
This e-mail, and any attachment(s), may contain information which is confidential and/or
privileged, and is intended for the addressee only. If you are not the intended recipient,
you may not use, disclose, copy or distribute this information in any manner whatsoever.
If you have received this e-mail in error, please contact the sender immediately and
delete it.
18 Jan
18 Jan
11:25 a.m.
New subject: pua_usrloc, PUBLISH not send when contact is deleted or expires
Hello,
On 1/18/12 10:53 AM, Giacomo Vacca wrote:
Hi all,
I've made a clean installation of kamailio 3.2.0 from
'http://deb.kamailio.org/kamailio32 squeeze main'
repository, on a squeeze debian machine (2.6.32-5-686).
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? The
repo are listed at:
http://www.kamailio.org/wiki/packages/debs#kamailio_32_-_nightly_builds
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.
Cheers,
Daniel
Installed also kamailio-presence-modules, same
version.
I'm just using the default kamailio.cfg that comes with the package,
with these minimal additions:
loadmodule "db_text.so"
loadmodule "pua.so"
loadmodule "pua_usrloc.so"
...
modparam("pua", "db_url",
"text:///usr/share/kamailio/dbtext/kamailio")
modparam("pua_usrloc", "default_domain",
"192.168.142.130")
Inside the registration management logic I've added pua_set_publish()
right before saving the location:
route[REGISTRAR] {
if (is_method("REGISTER"))
{
...
pua_set_publish();
if (!save("location"))
sl_reply_error();
exit;
}
}
When I first register (XLite 4.1 for Windows), pua_usrloc correctly
gets the callback and is able to generate a PUBLISH request through pua.
But when there's an un-registration, or when the contact expires, even
if the callbacks are correctly fired, the PUBLISH (which I'd expect
with status 'closed') is not generated.
From the logs (debug level 4), an un-registration:
8(7652) DEBUG: usrloc [ul_callback.h:89]: contact=0xb50ae7cc, callback
type 4/4, id 3 entered
8(7652) DEBUG: pua_usrloc [ul_publish.c:216]:DELETE type
8(7652) DEBUG: pua_usrloc [ul_publish.c:255]: uri=
sip:20701090@192.168.142.130
8(7652) DEBUG: pua_usrloc [ul_publish.c:66]: publ:
8(7652) DEBUG: pua_usrloc [ul_publish.c:67]: uri=
sip:20701090@192.168.142.130
8(7652) DEBUG: pua_usrloc [ul_publish.c:68]:
id=UL_PUBLISH.NmY5Zjc2YjcwNzEwNTk4YTY1NzA2Y2Y0MWQyMGRhOGY.
8(7652) DEBUG: pua_usrloc [ul_publish.c:69]: expires= 0
8(7652) DEBUG: pua [send_publish.c:403]:
pres_uri=sip:20701090@192.168.142.130
8(7652) DEBUG: pua [hash.c:121]: core_hash= 444
8(7652) DEBUG: pua [hash.c:174]: record not found
8(7652) DEBUG: pua [send_publish.c:444]: insert type
8(7652) DEBUG: pua [send_publish.c:448]: UPDATE_TYPE and no record found
8(7652) DEBUG: pua [send_publish.c:454]: request for a publish with
expires 0 and no record found
8(7652) DEBUG: sl [sl.c:278]: reply in stateless mode (sl)
As an additional information, the pua table in
/usr/share/kamailio/dbtext/kamailio/pua has not been populated.
The AOR was correctly displayed with 'ul show' while the registration
was valid.
Any suggestion on what am I be doing wrong?
Would it be worth testing the same scenario using mysql as DB?
Thanks in advance for your time.
Giacomo
Truphone Limited is a limited liability company registered in England
& Wales, registered office: 5 New Street Square, London EC4A 3TW.
Registered No. 04187081. VAT No. GB 851 5278 19.
Truis a brand name of Truphone and is a Truphone Communications
Service. Truphone is a trading name for a number of distinct legal
entities that operate in combination. www.truphone.com
<http://www.truphone.com>.
This e-mail, and any attachment(s), may contain information which is
confidential and/or privileged, and is intended for the addressee
only. If you are not the intended recipient, you may not use,
disclose, copy or distribute this information in any manner
whatsoever. If you have received this e-mail in error, please contact
the sender immediately and delete it.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
12:50 p.m.
New subject: pua_usrloc, PUBLISH not send when contact is deleted or expires
Thanks Daniel,
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?
Cheers,
Giacomo
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: 18 January 2012 10:25
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Cc: Giacomo Vacca
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is deleted or expires
Hello,
On 1/18/12 10:53 AM, Giacomo Vacca wrote:
Hi all,
I've made a clean installation of kamailio 3.2.0 from
'http://deb.kamailio.org/kamailio32 squeeze main'
repository, on a squeeze debian machine (2.6.32-5-686).
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? The repo are listed at:
http://www.kamailio.org/wiki/packages/debs#kamailio_32_-_nightly_builds
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.
Cheers,
Daniel
Installed also kamailio-presence-modules, same version.
I'm just using the default kamailio.cfg that comes with the package, with these
minimal additions:
loadmodule "db_text.so"
loadmodule "pua.so"
loadmodule "pua_usrloc.so"
...
modparam("pua", "db_url",
"text:///usr/share/kamailio/dbtext/kamailio")
modparam("pua_usrloc", "default_domain", "192.168.142.130")
Inside the registration management logic I've added pua_set_publish() right before
saving the location:
route[REGISTRAR] {
if (is_method("REGISTER"))
{
...
pua_set_publish();
if (!save("location"))
sl_reply_error();
exit;
}
}
When I first register (XLite 4.1 for Windows), pua_usrloc correctly gets the callback and
is able to generate a PUBLISH request through pua.
But when there's an un-registration, or when the contact expires, even if the
callbacks are correctly fired, the PUBLISH (which I'd expect with status
'closed') is not generated.
From the logs (debug level 4), an un-registration:
8(7652) DEBUG: usrloc [ul_callback.h:89]: contact=0xb50ae7cc, callback type 4/4, id 3
entered
8(7652) DEBUG: pua_usrloc [ul_publish.c:216]:DELETE type
8(7652) DEBUG: pua_usrloc [ul_publish.c:255]: uri= sip:20701090@192.168.142.130
8(7652) DEBUG: pua_usrloc [ul_publish.c:66]: publ:
8(7652) DEBUG: pua_usrloc [ul_publish.c:67]: uri= sip:20701090@192.168.142.130
8(7652) DEBUG: pua_usrloc [ul_publish.c:68]:
id=UL_PUBLISH.NmY5Zjc2YjcwNzEwNTk4YTY1NzA2Y2Y0MWQyMGRhOGY.
8(7652) DEBUG: pua_usrloc [ul_publish.c:69]: expires= 0
8(7652) DEBUG: pua [send_publish.c:403]: pres_uri=sip:20701090@192.168.142.130
8(7652) DEBUG: pua [hash.c:121]: core_hash= 444
8(7652) DEBUG: pua [hash.c:174]: record not found
8(7652) DEBUG: pua [send_publish.c:444]: insert type
8(7652) DEBUG: pua [send_publish.c:448]: UPDATE_TYPE and no record found
8(7652) DEBUG: pua [send_publish.c:454]: request for a publish with expires 0 and no
record found
8(7652) DEBUG: sl [sl.c:278]: reply in stateless mode (sl)
As an additional information, the pua table in
/usr/share/kamailio/dbtext/kamailio/pua has not been populated.
The AOR was correctly displayed with 'ul show' while the registration was valid.
Any suggestion on what am I be doing wrong?
Would it be worth testing the same scenario using mysql as DB?
Thanks in advance for your time.
Giacomo
Truphone Limited is a limited liability company registered in England & Wales,
registered office: 5 New Street Square, London EC4A 3TW. Registered No. 04187081. VAT No.
GB 851 5278 19.
Tru is a brand name of Truphone and is a Truphone Communications Service. Truphone is a
trading name for a number of distinct legal entities that operate in combination.
www.truphone.com<http://www.truphone.com>om>.
This e-mail, and any attachment(s), may contain information which is confidential and/or
privileged, and is intended for the addressee only. If you are not the intended recipient,
you may not use, disclose, copy or distribute this information in any manner whatsoever.
If you have received this e-mail in error, please contact the sender immediately and
delete it.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Truphone Limited is a limited liability company registered in England & Wales,
registered office: 5 New Street Square, London EC4A 3TW. Registered No. 04187081. VAT No.
GB 851 5278 19.
Tru is a brand name of Truphone and is a Truphone Communications Service. Truphone is a
trading name for a number of distinct legal entities that operate in combination.
www.truphone.com<http://www.truphone.com>om>.
This e-mail, and any attachment(s), may contain information which is confidential and/or
privileged, and is intended for the addressee only. If you are not the intended recipient,
you may not use, disclose, copy or distribute this information in any manner whatsoever.
If you have received this e-mail in error, please contact the sender immediately and
delete it.
10:17 p.m.
New subject: pua_usrloc, PUBLISH not send when contact is deleted or expires
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?
19 Jan
19 Jan
11:22 a.m.
New subject: pua_usrloc, PUBLISH not send when contact is deleted or expires
Hi Daniel,
Thanks for your feedback. Yes, using mysql and enabling presence made it work for
un-registrations too.
Just for the purpose of this scenario I'm sending the PUBLISH back to the same entity,
and it's being handled as a presentity.
I still have a missing piece though (which is in fact the reason for this configuration):
having PUBLISH requests triggered by the expiration of a contact.
When a contact expires, pua_usrloc is now logging:
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: INFO: pua_usrloc [ul_publish.c:211]:
should not send ul publish
(please see below for traces and details).
Since I'm marking a registration with pua_set_publish(), why is that flag not seen as
true when usrloc fires an EXPIRE callback?
I've tried marking every REGISTER request with pua_set_publish(), and not just the
first one, before calling save("location") but the result was the same.
Thanks again,
Giacomo
First registration and PUBLISH:
U 2012/01/19 10:08:46.867546 192.168.142.1:13752 -> 192.168.142.131:5060
REGISTER sip:192.168.142.131 SIP/2.0.
Via: SIP/2.0/UDP
192.168.142.1:13752;branch=z9hG4bK-d8754z-6dcc94d7866db11d-1---d8754z-;rport.
Max-Forwards: 70.
Contact: <sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6>.
To: "GV_XLite"<sip:2070109@192.168.142.131>.
From: "GV_XLite"<sip:2070109@192.168.142.131>;tag=0c957d3f.
Call-ID: ZmI1OGFhMzIyYTExNTYzOTIzNDRiZmI1NjQzZGZhZDI..
CSeq: 1 REGISTER.
Expires: 3600.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
User-Agent: X-Lite 4 release 4.1 stamp 63214.
Content-Length: 0.
.
U 2012/01/19 10:08:46.870154 192.168.142.131:5060 -> 127.0.0.1:5060
PUBLISH sip:2070109@127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 192.168.142.131;branch=z9hG4bK0722.77d94013.0.
To: sip:2070109@127.0.0.1.
From: sip:2070109@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-168c.
CSeq: 10 PUBLISH.
Call-ID: 7fedefec-4355(a)127.0.0.1.
Content-Length: 338.
User-Agent: kamailio (3.2.1 (i386/linux)).
Max-Forwards: 70.
Event: presence.
Expires: 61.
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="2070109(a)127.0.0.1">
<tuple id="0xb727ad14">
<status>
<basic>open</basic>
</status>
</tuple>
</presence>
U 2012/01/19 10:08:46.872917 127.0.0.1:5060 -> 192.168.142.131:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.142.131;branch=z9hG4bK0722.77d94013.0.
To: sip:2070109@127.0.0.1;tag=a6a1c5f60faecf035a1ae5b6e96e979a-106f.
From: sip:2070109@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-168c.
CSeq: 10 PUBLISH.
Call-ID: 7fedefec-4355(a)127.0.0.1.
Expires: 60.
SIP-ETag: a.1326967203.4352.2.0.
Server: kamailio (3.2.1 (i386/linux)).
Content-Length: 0.
.
U 2012/01/19 10:08:46.874271 192.168.142.131:5060 -> 192.168.142.1:13752
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
192.168.142.1:13752;branch=z9hG4bK-d8754z-6dcc94d7866db11d-1---d8754z-;rport=13752.
To:
"GV_XLite"<sip:2070109@192.168.142.131>;tag=b27e1a1d33761e85846fc98f5f3a7e58.4cd5.
From: "GV_XLite"<sip:2070109@192.168.142.131>;tag=0c957d3f.
Call-ID: ZmI1OGFhMzIyYTExNTYzOTIzNDRiZmI1NjQzZGZhZDI..
CSeq: 1 REGISTER.
Contact: <sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6>;expires=60.
Server: kamailio (3.2.1 (i386/linux)).
Content-Length: 0.
.
Registration refresh and PUBLISH:
U 2012/01/19 10:09:41.599554 192.168.142.1:13752 -> 192.168.142.131:5060
REGISTER sip:192.168.142.131 SIP/2.0.
Via: SIP/2.0/UDP
192.168.142.1:13752;branch=z9hG4bK-d8754z-4e5bc39865a12b22-1---d8754z-;rport.
Max-Forwards: 70.
Contact: <sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6>.
To: "GV_XLite"<sip:2070109@192.168.142.131>.
From: "GV_XLite"<sip:2070109@192.168.142.131>;tag=0c957d3f.
Call-ID: ZmI1OGFhMzIyYTExNTYzOTIzNDRiZmI1NjQzZGZhZDI..
CSeq: 2 REGISTER.
Expires: 3600.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
User-Agent: X-Lite 4 release 4.1 stamp 63214.
Content-Length: 0.
.
U 2012/01/19 10:09:41.605967 192.168.142.131:5060 -> 127.0.0.1:5060
PUBLISH sip:2070109@127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 192.168.142.131;branch=z9hG4bK568c.a38addc4.0.
To: sip:2070109@127.0.0.1.
From: sip:2070109@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-001d.
CSeq: 10 PUBLISH.
Call-ID: 7fedefed-4357(a)127.0.0.1.
Content-Length: 0.
User-Agent: kamailio (3.2.1 (i386/linux)).
Max-Forwards: 70.
Event: presence.
Expires: 61.
SIP-If-Match: a.1326967203.4352.2.0.
.
U 2012/01/19 10:09:41.617174 127.0.0.1:5060 -> 192.168.142.131:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.142.131;branch=z9hG4bK568c.a38addc4.0.
To: sip:2070109@127.0.0.1;tag=a6a1c5f60faecf035a1ae5b6e96e979a-70c8.
From: sip:2070109@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-001d.
CSeq: 10 PUBLISH.
Call-ID: 7fedefed-4357(a)127.0.0.1.
Expires: 60.
SIP-ETag: a.1326967203.4351.2.1.
Server: kamailio (3.2.1 (i386/linux)).
Content-Length: 0.
.
U 2012/01/19 10:09:41.620221 192.168.142.131:5060 -> 192.168.142.1:13752
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
192.168.142.1:13752;branch=z9hG4bK-d8754z-4e5bc39865a12b22-1---d8754z-;rport=13752.
To:
"GV_XLite"<sip:2070109@192.168.142.131>;tag=b27e1a1d33761e85846fc98f5f3a7e58.9769.
From: "GV_XLite"<sip:2070109@192.168.142.131>;tag=0c957d3f.
Call-ID: ZmI1OGFhMzIyYTExNTYzOTIzNDRiZmI1NjQzZGZhZDI..
CSeq: 2 REGISTER.
Contact: <sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6>;expires=60.
Server: kamailio (3.2.1 (i386/linux)).
Content-Length: 0.
.
Now pua table contains:
SELECT * FROM pua\G
***************************
1. row ***************************
id: 12
pres_uri: sip:2070109@127.0.0.1
pres_id: UL_PUBLISH.ZmI1OGFhMzIyYTExNTYzOTIzNDRiZmI1NjQzZGZhZDI.
event: 1
expires: 1326967841
desired_expires: 1326967841
flag: 1
etag: a.1326967203.4351.2.1
tuple_id: 0xb727ad14
watcher_uri:
call_id:
to_tag:
from_tag:
cseq: 0
record_route:
contact:
remote_contact:
version: 1
extra_headers:
1 row in set (0.00 sec)
Then I kill the client, and wait for the contact expiration. This is logged (debug level
4), and no PUBLISH issued:
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: DEBUG: usrloc [ul_callback.h:89]:
contact=0xb4db7638, callback type 8/8, id 1 entered
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: INFO: pua_usrloc [ul_publish.c:211]:
should not send ul publish
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: DEBUG: usrloc [urecord.c:246]: Binding
'2070109','sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6' has
expired
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: 18 January 2012 21:17
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Cc: Giacomo Vacca
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is deleted or expires
Hello,
On 1/18/12 12:50 PM, Giacomo Vacca wrote:
Thanks Daniel,
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.
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?
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?
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@127.0.1.1<mailto:1106651003@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@127.0.0.1<mailto:53162b3d3a4cff50-20164@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@127.0.0.1"<mailto:test@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@127.0.1.1<mailto:1106651003@127.0.1.1>.
CSeq: 1 REGISTER.
Contact: <sip:test@127.0.1.1:5080><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@127.0.0.1<mailto:53162b3d3a4cff50-20164@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@127.0.1.1<mailto:792417331@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@127.0.0.1<mailto:53162b3d3a4cff51-20163@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@127.0.1.1<mailto:792417331@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@127.0.0.1<mailto:53162b3d3a4cff51-20163@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.
.
Truphone Limited is a limited liability company registered in England & Wales,
registered office: 5 New Street Square, London EC4A 3TW. Registered No. 04187081. VAT No.
GB 851 5278 19.
Tru is a brand name of Truphone and is a Truphone Communications Service. Truphone is a
trading name for a number of distinct legal entities that operate in combination.
www.truphone.com<http://www.truphone.com>om>.
This e-mail, and any attachment(s), may contain information which is confidential and/or
privileged, and is intended for the addressee only. If you are not the intended recipient,
you may not use, disclose, copy or distribute this information in any manner whatsoever.
If you have received this e-mail in error, please contact the sender immediately and
delete it.
11:37 a.m.
New subject: pua_usrloc, PUBLISH not send when contact is deleted or expires
Hello,
On 1/19/12 11:22 AM, Giacomo Vacca wrote:
Hi Daniel,
Thanks for your feedback. Yes, using mysql and enabling presence made
it work for un-registrations too.
Just for the purpose of this scenario I'm sending the PUBLISH back to
the same entity, and it's being handled as a presentity.
I still have a missing piece though (which is in fact the reason for
this configuration): having PUBLISH requests triggered by the
expiration of a contact.
When a contact expires, pua_usrloc is now logging:
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: INFO: pua_usrloc
[ul_publish.c:211]: should not send ul publish
(please see below for traces and details).
Since I'm marking a registration with pua_set_publish(), why is that
flag not seen as true when usrloc fires an EXPIRE callback?
I've tried marking every REGISTER request with pua_set_publish(), and
not just the first one, before calling save("location") but the result
was the same.
the PUBLISH for registration expiration does not make sense, as PUBLISH
has also an expire interval, so the record in the presence server should
expire at the same time. A publish with update state to close will
eventually hit the presence server when there is no record for it.
Presence server will send notifications when the record in its table
expires.
Cheers,
Daniel
Thanks again,
Giacomo
First registration and PUBLISH:
U 2012/01/19 10:08:46.867546 192.168.142.1:13752 -> 192.168.142.131:5060
REGISTER sip:192.168.142.131 SIP/2.0.
Via: SIP/2.0/UDP
192.168.142.1:13752;branch=z9hG4bK-d8754z-6dcc94d7866db11d-1---d8754z-;rport.
Max-Forwards: 70.
Contact: <sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6>.
To: "GV_XLite"<sip:2070109@192.168.142.131>.
From: "GV_XLite"<sip:2070109@192.168.142.131>;tag=0c957d3f.
Call-ID: ZmI1OGFhMzIyYTExNTYzOTIzNDRiZmI1NjQzZGZhZDI..
CSeq: 1 REGISTER.
Expires: 3600.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
SUBSCRIBE, INFO.
User-Agent: X-Lite 4 release 4.1 stamp 63214.
Content-Length: 0.
.
U 2012/01/19 10:08:46.870154 192.168.142.131:5060 -> 127.0.0.1:5060
PUBLISH sip:2070109@127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 192.168.142.131;branch=z9hG4bK0722.77d94013.0.
To: sip:2070109@127.0.0.1.
From: sip:2070109@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-168c.
CSeq: 10 PUBLISH.
Call-ID: 7fedefec-4355(a)127.0.0.1.
Content-Length: 338.
User-Agent: kamailio (3.2.1 (i386/linux)).
Max-Forwards: 70.
Event: presence.
Expires: 61.
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="2070109(a)127.0.0.1">
<tuple id="0xb727ad14">
<status>
<basic>open</basic>
</status>
</tuple>
</presence>
U 2012/01/19 10:08:46.872917 127.0.0.1:5060 -> 192.168.142.131:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.142.131;branch=z9hG4bK0722.77d94013.0.
To: sip:2070109@127.0.0.1;tag=a6a1c5f60faecf035a1ae5b6e96e979a-106f.
From: sip:2070109@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-168c.
CSeq: 10 PUBLISH.
Call-ID: 7fedefec-4355(a)127.0.0.1.
Expires: 60.
SIP-ETag: a.1326967203.4352.2.0.
Server: kamailio (3.2.1 (i386/linux)).
Content-Length: 0.
.
U 2012/01/19 10:08:46.874271 192.168.142.131:5060 -> 192.168.142.1:13752
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
192.168.142.1:13752;branch=z9hG4bK-d8754z-6dcc94d7866db11d-1---d8754z-;rport=13752.
To:
"GV_XLite"<sip:2070109@192.168.142.131>;tag=b27e1a1d33761e85846fc98f5f3a7e58.4cd5.
From: "GV_XLite"<sip:2070109@192.168.142.131>;tag=0c957d3f.
Call-ID: ZmI1OGFhMzIyYTExNTYzOTIzNDRiZmI1NjQzZGZhZDI..
CSeq: 1 REGISTER.
Contact:
<sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6>;expires=60.
Server: kamailio (3.2.1 (i386/linux)).
Content-Length: 0.
.
Registration refresh and PUBLISH:
U 2012/01/19 10:09:41.599554 192.168.142.1:13752 -> 192.168.142.131:5060
REGISTER sip:192.168.142.131 SIP/2.0.
Via: SIP/2.0/UDP
192.168.142.1:13752;branch=z9hG4bK-d8754z-4e5bc39865a12b22-1---d8754z-;rport.
Max-Forwards: 70.
Contact: <sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6>.
To: "GV_XLite"<sip:2070109@192.168.142.131>.
From: "GV_XLite"<sip:2070109@192.168.142.131>;tag=0c957d3f.
Call-ID: ZmI1OGFhMzIyYTExNTYzOTIzNDRiZmI1NjQzZGZhZDI..
CSeq: 2 REGISTER.
Expires: 3600.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
SUBSCRIBE, INFO.
User-Agent: X-Lite 4 release 4.1 stamp 63214.
Content-Length: 0.
.
U 2012/01/19 10:09:41.605967 192.168.142.131:5060 -> 127.0.0.1:5060
PUBLISH sip:2070109@127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 192.168.142.131;branch=z9hG4bK568c.a38addc4.0.
To: sip:2070109@127.0.0.1.
From: sip:2070109@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-001d.
CSeq: 10 PUBLISH.
Call-ID: 7fedefed-4357(a)127.0.0.1.
Content-Length: 0.
User-Agent: kamailio (3.2.1 (i386/linux)).
Max-Forwards: 70.
Event: presence.
Expires: 61.
SIP-If-Match: a.1326967203.4352.2.0.
.
U 2012/01/19 10:09:41.617174 127.0.0.1:5060 -> 192.168.142.131:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.142.131;branch=z9hG4bK568c.a38addc4.0.
To: sip:2070109@127.0.0.1;tag=a6a1c5f60faecf035a1ae5b6e96e979a-70c8.
From: sip:2070109@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-001d.
CSeq: 10 PUBLISH.
Call-ID: 7fedefed-4357(a)127.0.0.1.
Expires: 60.
SIP-ETag: a.1326967203.4351.2.1.
Server: kamailio (3.2.1 (i386/linux)).
Content-Length: 0.
.
U 2012/01/19 10:09:41.620221 192.168.142.131:5060 -> 192.168.142.1:13752
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
192.168.142.1:13752;branch=z9hG4bK-d8754z-4e5bc39865a12b22-1---d8754z-;rport=13752.
To:
"GV_XLite"<sip:2070109@192.168.142.131>;tag=b27e1a1d33761e85846fc98f5f3a7e58.9769.
From: "GV_XLite"<sip:2070109@192.168.142.131>;tag=0c957d3f.
Call-ID: ZmI1OGFhMzIyYTExNTYzOTIzNDRiZmI1NjQzZGZhZDI..
CSeq: 2 REGISTER.
Contact:
<sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6>;expires=60.
Server: kamailio (3.2.1 (i386/linux)).
Content-Length: 0.
.
Now pua table contains:
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
SELECT * FROM pua\G
*************************** 1. row ***************************
id: 12
pres_uri: sip:2070109@127.0.0.1
pres_id: UL_PUBLISH.ZmI1OGFhMzIyYTExNTYzOTIzNDRiZmI1NjQzZGZhZDI.
event: 1
expires: 1326967841
desired_expires: 1326967841
flag: 1
etag: a.1326967203.4351.2.1
tuple_id: 0xb727ad14
watcher_uri:
call_id:
to_tag:
from_tag:
cseq: 0
record_route:
contact:
remote_contact:
version: 1
extra_headers:
1 row in set (0.00 sec)
Then I kill the client, and wait for the contact expiration. This is
logged (debug level 4), and no PUBLISH issued:
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: DEBUG: usrloc
[ul_callback.h:89]: contact=0xb4db7638, callback type 8/8, id 1 entered
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: INFO: pua_usrloc
[ul_publish.c:211]: should not send ul publish
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: DEBUG: usrloc
[urecord.c:246]: Binding
'2070109','sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6'
has expired
*From:*Daniel-Constantin Mierla [mailto:miconda@gmail.com]
*Sent:* 18 January 2012 21:17
*To:* SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing List
*Cc:* Giacomo Vacca
*Subject:* Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is
deleted or expires
Hello,
On 1/18/12 12:50 PM, Giacomo Vacca wrote:
Thanks Daniel,
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.
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?
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?
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 <mailto:1106651003@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
<mailto:53162b3d3a4cff50-20164@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"
<mailto:test@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 <mailto:1106651003@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
<mailto:53162b3d3a4cff50-20164@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 <mailto:792417331@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
<mailto:53162b3d3a4cff51-20163@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 <mailto:792417331@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
<mailto:53162b3d3a4cff51-20163@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.
.
Truphone Limited is a limited liability company registered in England
& Wales, registered office: 5 New Street Square, London EC4A 3TW.
Registered No. 04187081. VAT No. GB 851 5278 19.
Truis a brand name of Truphone and is a Truphone Communications
Service. Truphone is a trading name for a number of distinct legal
entities that operate in combination. www.truphone.com
<http://www.truphone.com>.
This e-mail, and any attachment(s), may contain information which is
confidential and/or privileged, and is intended for the addressee
only. If you are not the intended recipient, you may not use,
disclose, copy or distribute this information in any manner
whatsoever. If you have received this e-mail in error, please contact
the sender immediately and delete it.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11:49 a.m.
New subject: pua_usrloc, PUBLISH not send when contact is deleted or expires
Ah thanks Daniel,
So I had a wrong expectation on the behaviour of pua_usrloc.
It does make sense that the PUBLISH already carries its expiry and so the expiration
moment is implicit and should/can be handled elsewhere.
I think what confused me were two things: the pua_usrloc documentation and the fact that
pua_usrloc does register for EXPIRE callbacks with usrloc.
I'm referring to:
"The pua_usrloc module is the connector between the usrloc and pua modules. It
creates the environment to send PUBLISH requests for user location records, on specific
events (e.g., when new record is added in usrloc, a PUBLISH with status open (online) is
issued; when expires, it sends closed (offline))."
Thanks for clarifying this.
Regards,
Giacomo
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: 19 January 2012 10:37
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Cc: Giacomo Vacca
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is deleted or expires
Hello,
On 1/19/12 11:22 AM, Giacomo Vacca wrote:
Hi Daniel,
Thanks for your feedback. Yes, using mysql and enabling presence made it work for
un-registrations too.
Just for the purpose of this scenario I'm sending the PUBLISH back to the same entity,
and it's being handled as a presentity.
I still have a missing piece though (which is in fact the reason for this configuration):
having PUBLISH requests triggered by the expiration of a contact.
When a contact expires, pua_usrloc is now logging:
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: INFO: pua_usrloc [ul_publish.c:211]:
should not send ul publish
(please see below for traces and details).
Since I'm marking a registration with pua_set_publish(), why is that flag not seen as
true when usrloc fires an EXPIRE callback?
I've tried marking every REGISTER request with pua_set_publish(), and not just the
first one, before calling save("location") but the result was the same.
the PUBLISH for registration expiration does not make sense, as PUBLISH has also an expire
interval, so the record in the presence server should expire at the same time. A publish
with update state to close will eventually hit the presence server when there is no record
for it. Presence server will send notifications when the record in its table expires.
Cheers,
Daniel
Thanks again,
Giacomo
First registration and PUBLISH:
U 2012/01/19 10:08:46.867546 192.168.142.1:13752 -> 192.168.142.131:5060
REGISTER sip:192.168.142.131 SIP/2.0.
Via: SIP/2.0/UDP
192.168.142.1:13752;branch=z9hG4bK-d8754z-6dcc94d7866db11d-1---d8754z-;rport.
Max-Forwards: 70.
Contact:
<sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6><sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6>.
To:
"GV_XLite"<sip:2070109@192.168.142.131><sip:2070109@192.168.142.131>.
From:
"GV_XLite"<sip:2070109@192.168.142.131><sip:2070109@192.168.142.131>;tag=0c957d3f.
Call-ID: ZmI1OGFhMzIyYTExNTYzOTIzNDRiZmI1NjQzZGZhZDI..
CSeq: 1 REGISTER.
Expires: 3600.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
User-Agent: X-Lite 4 release 4.1 stamp 63214.
Content-Length: 0.
.
U 2012/01/19 10:08:46.870154 192.168.142.131:5060 -> 127.0.0.1:5060
PUBLISH sip:2070109@127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 192.168.142.131;branch=z9hG4bK0722.77d94013.0.
To: sip:2070109@127.0.0.1.
From: sip:2070109@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-168c.
CSeq: 10 PUBLISH.
Call-ID: 7fedefec-4355@127.0.0.1<mailto:7fedefec-4355@127.0.0.1>.
Content-Length: 338.
User-Agent: kamailio (3.2.1 (i386/linux)).
Max-Forwards: 70.
Event: presence.
Expires: 61.
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="2070109@127.0.0.1"<mailto:2070109@127.0.0.1>>
<tuple id="0xb727ad14">
<status>
<basic>open</basic>
</status>
</tuple>
</presence>
U 2012/01/19 10:08:46.872917 127.0.0.1:5060 -> 192.168.142.131:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.142.131;branch=z9hG4bK0722.77d94013.0.
To: sip:2070109@127.0.0.1;tag=a6a1c5f60faecf035a1ae5b6e96e979a-106f.
From: sip:2070109@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-168c.
CSeq: 10 PUBLISH.
Call-ID: 7fedefec-4355@127.0.0.1<mailto:7fedefec-4355@127.0.0.1>.
Expires: 60.
SIP-ETag: a.1326967203.4352.2.0.
Server: kamailio (3.2.1 (i386/linux)).
Content-Length: 0.
.
U 2012/01/19 10:08:46.874271 192.168.142.131:5060 -> 192.168.142.1:13752
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
192.168.142.1:13752;branch=z9hG4bK-d8754z-6dcc94d7866db11d-1---d8754z-;rport=13752.
To:
"GV_XLite"<sip:2070109@192.168.142.131><sip:2070109@192.168.142.131>;tag=b27e1a1d33761e85846fc98f5f3a7e58.4cd5.
From:
"GV_XLite"<sip:2070109@192.168.142.131><sip:2070109@192.168.142.131>;tag=0c957d3f.
Call-ID: ZmI1OGFhMzIyYTExNTYzOTIzNDRiZmI1NjQzZGZhZDI..
CSeq: 1 REGISTER.
Contact:
<sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6><sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6>;expires=60.
Server: kamailio (3.2.1 (i386/linux)).
Content-Length: 0.
.
Registration refresh and PUBLISH:
U 2012/01/19 10:09:41.599554 192.168.142.1:13752 -> 192.168.142.131:5060
REGISTER sip:192.168.142.131 SIP/2.0.
Via: SIP/2.0/UDP
192.168.142.1:13752;branch=z9hG4bK-d8754z-4e5bc39865a12b22-1---d8754z-;rport.
Max-Forwards: 70.
Contact:
<sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6><sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6>.
To:
"GV_XLite"<sip:2070109@192.168.142.131><sip:2070109@192.168.142.131>.
From:
"GV_XLite"<sip:2070109@192.168.142.131><sip:2070109@192.168.142.131>;tag=0c957d3f.
Call-ID: ZmI1OGFhMzIyYTExNTYzOTIzNDRiZmI1NjQzZGZhZDI..
CSeq: 2 REGISTER.
Expires: 3600.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
User-Agent: X-Lite 4 release 4.1 stamp 63214.
Content-Length: 0.
.
U 2012/01/19 10:09:41.605967 192.168.142.131:5060 -> 127.0.0.1:5060
PUBLISH sip:2070109@127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 192.168.142.131;branch=z9hG4bK568c.a38addc4.0.
To: sip:2070109@127.0.0.1.
From: sip:2070109@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-001d.
CSeq: 10 PUBLISH.
Call-ID: 7fedefed-4357@127.0.0.1<mailto:7fedefed-4357@127.0.0.1>.
Content-Length: 0.
User-Agent: kamailio (3.2.1 (i386/linux)).
Max-Forwards: 70.
Event: presence.
Expires: 61.
SIP-If-Match: a.1326967203.4352.2.0.
.
U 2012/01/19 10:09:41.617174 127.0.0.1:5060 -> 192.168.142.131:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.142.131;branch=z9hG4bK568c.a38addc4.0.
To: sip:2070109@127.0.0.1;tag=a6a1c5f60faecf035a1ae5b6e96e979a-70c8.
From: sip:2070109@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-001d.
CSeq: 10 PUBLISH.
Call-ID: 7fedefed-4357@127.0.0.1<mailto:7fedefed-4357@127.0.0.1>.
Expires: 60.
SIP-ETag: a.1326967203.4351.2.1.
Server: kamailio (3.2.1 (i386/linux)).
Content-Length: 0.
.
U 2012/01/19 10:09:41.620221 192.168.142.131:5060 -> 192.168.142.1:13752
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
192.168.142.1:13752;branch=z9hG4bK-d8754z-4e5bc39865a12b22-1---d8754z-;rport=13752.
To:
"GV_XLite"<sip:2070109@192.168.142.131><sip:2070109@192.168.142.131>;tag=b27e1a1d33761e85846fc98f5f3a7e58.9769.
From:
"GV_XLite"<sip:2070109@192.168.142.131><sip:2070109@192.168.142.131>;tag=0c957d3f.
Call-ID: ZmI1OGFhMzIyYTExNTYzOTIzNDRiZmI1NjQzZGZhZDI..
CSeq: 2 REGISTER.
Contact:
<sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6><sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6>;expires=60.
Server: kamailio (3.2.1 (i386/linux)).
Content-Length: 0.
.
Now pua table contains:
SELECT * FROM pua\G
***************************
1. row ***************************
id: 12
pres_uri: sip:2070109@127.0.0.1
pres_id: UL_PUBLISH.ZmI1OGFhMzIyYTExNTYzOTIzNDRiZmI1NjQzZGZhZDI.
event: 1
expires: 1326967841
desired_expires: 1326967841
flag: 1
etag: a.1326967203.4351.2.1
tuple_id: 0xb727ad14
watcher_uri:
call_id:
to_tag:
from_tag:
cseq: 0
record_route:
contact:
remote_contact:
version: 1
extra_headers:
1 row in set (0.00 sec)
Then I kill the client, and wait for the contact expiration. This is logged (debug level
4), and no PUBLISH issued:
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: DEBUG: usrloc [ul_callback.h:89]:
contact=0xb4db7638, callback type 8/8, id 1 entered
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: INFO: pua_usrloc [ul_publish.c:211]:
should not send ul publish
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: DEBUG: usrloc [urecord.c:246]: Binding
'2070109','sip:2070109@192.168.142.1:13752;rinstance=f949af25d45274c6' has
expired
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: 18 January 2012 21:17
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Cc: Giacomo Vacca
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is deleted or expires
Hello,
On 1/18/12 12:50 PM, Giacomo Vacca wrote:
Thanks Daniel,
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.
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?
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?
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@127.0.1.1<mailto:1106651003@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@127.0.0.1<mailto:53162b3d3a4cff50-20164@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@127.0.0.1"<mailto:test@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@127.0.1.1<mailto:1106651003@127.0.1.1>.
CSeq: 1 REGISTER.
Contact: <sip:test@127.0.1.1:5080><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@127.0.0.1<mailto:53162b3d3a4cff50-20164@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@127.0.1.1<mailto:792417331@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@127.0.0.1<mailto:53162b3d3a4cff51-20163@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@127.0.1.1<mailto:792417331@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@127.0.0.1<mailto:53162b3d3a4cff51-20163@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.
.
Truphone Limited is a limited liability company registered in England & Wales,
registered office: 5 New Street Square, London EC4A 3TW. Registered No. 04187081. VAT No.
GB 851 5278 19.
Tru is a brand name of Truphone and is a Truphone Communications Service. Truphone is a
trading name for a number of distinct legal entities that operate in combination.
www.truphone.com<http://www.truphone.com>om>.
This e-mail, and any attachment(s), may contain information which is confidential and/or
privileged, and is intended for the addressee only. If you are not the intended recipient,
you may not use, disclose, copy or distribute this information in any manner whatsoever.
If you have received this e-mail in error, please contact the sender immediately and
delete it.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Truphone Limited is a limited liability company registered in England & Wales,
registered office: 5 New Street Square, London EC4A 3TW. Registered No. 04187081. VAT No.
GB 851 5278 19.
Tru is a brand name of Truphone and is a Truphone Communications Service. Truphone is a
trading name for a number of distinct legal entities that operate in combination.
www.truphone.com<http://www.truphone.com>om>.
This e-mail, and any attachment(s), may contain information which is confidential and/or
privileged, and is intended for the addressee only. If you are not the intended recipient,
you may not use, disclose, copy or distribute this information in any manner whatsoever.
If you have received this e-mail in error, please contact the sender immediately and
delete it.
20 Jan
20 Jan
11:58 a.m.
New subject: pua_usrloc, PUBLISH not send when contact is deleted or expires
Hi Giacomo,
On 1/19/12 11:49 AM, Giacomo Vacca wrote:
Ah thanks Daniel,
So I had a wrong expectation on the behaviour of pua_usrloc.
It does make sense that the PUBLISH already carries its expiry and so
the expiration moment is implicit and should/can be handled elsewhere.
I think what confused me were two things: the pua_usrloc documentation
and the fact that pua_usrloc does register for EXPIRE callbacks with
usrloc.
I'm referring to:
"The pua_usrloc module is the connector between the usrloc and pua
modules. It creates the environment to send PUBLISH requests for user
location records, on specific events (e.g., when new record is added
in usrloc, a PUBLISH with status open (online) is issued; when
expires, it sends closed (offline))."
perhaps the documentation is misleading a bit with its phrasing. It send
offline (closed) when it is an un-register, before the expiration. I
haven't looked in the code, but based on log messages and correlated
with the expired carried by PUBLISH, the behavior is correct over all.
There is another aspect, usrloc cleans up expired records on timer, so
usrloc callback can be executed later than actual expiration. A publish
at that time could be late. Of course, presence does cleanup on timer as
well, but it may be more accurate to handle expiration there. It is like
when an UA with presence support disappears from networks, without
sending any PUBLISH updates.
Cheers,
DAniel
*From:*Daniel-Constantin Mierla
[mailto:miconda@gmail.com]
*Sent:* 19 January 2012 10:37
*To:* SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing List
*Cc:* Giacomo Vacca
*Subject:* Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is
deleted or expires
Hello,
On 1/19/12 11:22 AM, Giacomo Vacca wrote:
Hi Daniel,
Thanks for your feedback. Yes, using mysql and enabling presence made
it work for un-registrations too.
Just for the purpose of this scenario I'm sending the PUBLISH back to
the same entity, and it's being handled as a presentity.
I still have a missing piece though (which is in fact the reason for
this configuration): having PUBLISH requests triggered by the
expiration of a contact.
When a contact expires, pua_usrloc is now logging:
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: INFO: pua_usrloc
[ul_publish.c:211]: should not send ul publish
(please see below for traces and details).
Since I'm marking a registration with pua_set_publish(), why is that
flag not seen as true when usrloc fires an EXPIRE callback?
I've tried marking every REGISTER request with pua_set_publish(), and
not just the first one, before calling save("location") but the result
was the same.
the PUBLISH for registration expiration does not make sense, as
PUBLISH has also an expire interval, so the record in the presence
server should expire at the same time. A publish with update state to
close will eventually hit the presence server when there is no record
for it. Presence server will send notifications when the record in its
table expires.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
12:56 p.m.
New subject: pua_usrloc, PUBLISH not send when contact is deleted or expires
Thanks Daniel.
What I'd like to achieve is this: given a cluster of kamailio-based proxy/registrar,
notify a separate entity whenever a contact is inserted or removed (either by deletion or
expiration).
I'd like this separate entity to be stateless (i.e. don't manage expiry time),
avoid using a DB as shared information and have asynchronous notifications.
This is why I thought pua_usrloc could help me, without the need of a full presence server
in the architecture to manage expiry times for presentities.
What do you think could be used to achieve this?
From my point of view the ideal solution is
implementing reg-info events (RFC 3680), where the separate entity mentioned above acts as
watcher for reg-info events on all kamailio instances.
But I'm really looking at
a simpler, lighter solution.
Regards,
Giacomo
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: 20 January 2012 10:58
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Cc: Giacomo Vacca
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is deleted or expires
Hi Giacomo,
On 1/19/12 11:49 AM, Giacomo Vacca wrote:
Ah thanks Daniel,
So I had a wrong expectation on the behaviour of pua_usrloc.
It does make sense that the PUBLISH already carries its expiry and so the expiration
moment is implicit and should/can be handled elsewhere.
I think what confused me were two things: the pua_usrloc documentation and the fact that
pua_usrloc does register for EXPIRE callbacks with usrloc.
I'm referring to:
"The pua_usrloc module is the connector between the usrloc and pua modules. It
creates the environment to send PUBLISH requests for user location records, on specific
events (e.g., when new record is added in usrloc, a PUBLISH with status open (online) is
issued; when expires, it sends closed (offline))."
perhaps the documentation is misleading a bit with its phrasing. It send offline (closed)
when it is an un-register, before the expiration. I haven't looked in the code, but
based on log messages and correlated with the expired carried by PUBLISH, the behavior is
correct over all.
There is another aspect, usrloc cleans up expired records on timer, so usrloc callback can
be executed later than actual expiration. A publish at that time could be late. Of course,
presence does cleanup on timer as well, but it may be more accurate to handle expiration
there. It is like when an UA with presence support disappears from networks, without
sending any PUBLISH updates.
Cheers,
DAniel
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: 19 January 2012 10:37
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Cc: Giacomo Vacca
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is deleted or expires
Hello,
On 1/19/12 11:22 AM, Giacomo Vacca wrote:
Hi Daniel,
Thanks for your feedback. Yes, using mysql and enabling presence made it work for
un-registrations too.
Just for the purpose of this scenario I'm sending the PUBLISH back to the same entity,
and it's being handled as a presentity.
I still have a missing piece though (which is in fact the reason for this configuration):
having PUBLISH requests triggered by the expiration of a contact.
When a contact expires, pua_usrloc is now logging:
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: INFO: pua_usrloc [ul_publish.c:211]:
should not send ul publish
(please see below for traces and details).
Since I'm marking a registration with pua_set_publish(), why is that flag not seen as
true when usrloc fires an EXPIRE callback?
I've tried marking every REGISTER request with pua_set_publish(), and not just the
first one, before calling save("location") but the result was the same.
the PUBLISH for registration expiration does not make sense, as PUBLISH has also an expire
interval, so the record in the presence server should expire at the same time. A publish
with update state to close will eventually hit the presence server when there is no record
for it. Presence server will send notifications when the record in its table expires.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Truphone Limited is a limited liability company registered in England & Wales,
registered office: 5 New Street Square, London EC4A 3TW. Registered No. 04187081. VAT No.
GB 851 5278 19.
Tru is a brand name of Truphone and is a Truphone Communications Service. Truphone is a
trading name for a number of distinct legal entities that operate in combination.
www.truphone.com<http://www.truphone.com>om>.
This e-mail, and any attachment(s), may contain information which is confidential and/or
privileged, and is intended for the addressee only. If you are not the intended recipient,
you may not use, disclose, copy or distribute this information in any manner whatsoever.
If you have received this e-mail in error, please contact the sender immediately and
delete it.
27 Jan
27 Jan
10:03 a.m.
New subject: pua_usrloc, PUBLISH not send when contact is deleted or expires
Hi Giacomo,
I patched few days ago to make pua_usrloc sending the PUBLISH also for
location record expiration.
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=bdbacf5…
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=266fa4e…
The idea is to set a branch flag for marking the contact for publishing
-- pua_set_publish() can be still used actually, it sets also the branch
flag internally, if the module parameter specifying the flag is set --
alternative is to use directly setbflag(index).
I was out of office and couldn't try it yet, maybe you can test and
report if it is working fine.
You have to install devel version, either from git or from nightly debs:
http://www.kamailio.org/wiki/packages/debs#kamailio_development_-_nightly_b…
Cheers,
Daniel
On 1/20/12 12:56 PM, Giacomo Vacca wrote:
Thanks Daniel.
What I'd like to achieve is this: given a cluster of kamailio-based
proxy/registrar, notify a separate entity whenever a contact is
inserted or removed (either by deletion or expiration).
I'd like this separate entity to be stateless (i.e. don't manage
expiry time), avoid using a DB as shared information and have
asynchronous notifications.
This is why I thought pua_usrloc could help me, without the need of a
full presence server in the architecture to manage expiry times for
presentities.
What do you think could be used to achieve this?
From my point of view the ideal solution is implementing reg-info
events (RFC 3680), where the separate entity mentioned above acts as
watcher for reg-info events on all kamailio instances.
But I'm really looking at a simpler, lighter solution.
Regards,
Giacomo
*From:*Daniel-Constantin Mierla [mailto:miconda@gmail.com]
*Sent:* 20 January 2012 10:58
*To:* SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing List
*Cc:* Giacomo Vacca
*Subject:* Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is
deleted or expires
Hi Giacomo,
On 1/19/12 11:49 AM, Giacomo Vacca wrote:
Ah thanks Daniel,
So I had a wrong expectation on the behaviour of pua_usrloc.
It does make sense that the PUBLISH already carries its expiry and so
the expiration moment is implicit and should/can be handled elsewhere.
I think what confused me were two things: the pua_usrloc documentation
and the fact that pua_usrloc does register for EXPIRE callbacks with
usrloc.
I'm referring to:
"The pua_usrloc module is the connector between the usrloc and pua
modules. It creates the environment to send PUBLISH requests for user
location records, on specific events (e.g., when new record is added
in usrloc, a PUBLISH with status open (online) is issued; when
expires, it sends closed (offline))."
perhaps the documentation is misleading a bit with its phrasing. It
send offline (closed) when it is an un-register, before the
expiration. I haven't looked in the code, but based on log messages
and correlated with the expired carried by PUBLISH, the behavior is
correct over all.
There is another aspect, usrloc cleans up expired records on timer, so
usrloc callback can be executed later than actual expiration. A
publish at that time could be late. Of course, presence does cleanup
on timer as well, but it may be more accurate to handle expiration
there. It is like when an UA with presence support disappears from
networks, without sending any PUBLISH updates.
Cheers,
DAniel
*From:*Daniel-Constantin Mierla [mailto:miconda@gmail.com]
*Sent:* 19 January 2012 10:37
*To:* SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing List
*Cc:* Giacomo Vacca
*Subject:* Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is
deleted or expires
Hello,
On 1/19/12 11:22 AM, Giacomo Vacca wrote:
Hi Daniel,
Thanks for your feedback. Yes, using mysql and enabling presence made
it work for un-registrations too.
Just for the purpose of this scenario I'm sending the PUBLISH back to
the same entity, and it's being handled as a presentity.
I still have a missing piece though (which is in fact the reason for
this configuration): having PUBLISH requests triggered by the
expiration of a contact.
When a contact expires, pua_usrloc is now logging:
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: INFO: pua_usrloc
[ul_publish.c:211]: should not send ul publish
(please see below for traces and details).
Since I'm marking a registration with pua_set_publish(), why is that
flag not seen as true when usrloc fires an EXPIRE callback?
I've tried marking every REGISTER request with pua_set_publish(), and
not just the first one, before calling save("location") but the result
was the same.
the PUBLISH for registration expiration does not make sense, as
PUBLISH has also an expire interval, so the record in the presence
server should expire at the same time. A publish with update state to
close will eventually hit the presence server when there is no record
for it. Presence server will send notifications when the record in its
table expires.
Cheers,
Daniel
--
Daniel-Constantin Mierla --http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Truphone Limited is a limited liability company registered in England
& Wales, registered office: 5 New Street Square, London EC4A 3TW.
Registered No. 04187081. VAT No. GB 851 5278 19.
Truis a brand name of Truphone and is a Truphone Communications
Service. Truphone is a trading name for a number of distinct legal
entities that operate in combination. www.truphone.com
<http://www.truphone.com>.
This e-mail, and any attachment(s), may contain information which is
confidential and/or privileged, and is intended for the addressee
only. If you are not the intended recipient, you may not use,
disclose, copy or distribute this information in any manner
whatsoever. If you have received this e-mail in error, please contact
the sender immediately and delete it.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
10:17 a.m.
New subject: pua_usrloc, PUBLISH not send when contact is deleted or expires
Hi Daniel,
This is just great. I'll test asap and report back.
Cheers,
Giacomo
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: 27 January 2012 09:03
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Cc: Giacomo Vacca
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is deleted or expires
Hi Giacomo,
I patched few days ago to make pua_usrloc sending the PUBLISH also for location record
expiration.
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=bdbacf5…
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=266fa4e…
The idea is to set a branch flag for marking the contact for publishing --
pua_set_publish() can be still used actually, it sets also the branch flag internally, if
the module parameter specifying the flag is set -- alternative is to use directly
setbflag(index).
I was out of office and couldn't try it yet, maybe you can test and report if it is
working fine.
You have to install devel version, either from git or from nightly debs:
http://www.kamailio.org/wiki/packages/debs#kamailio_development_-_nightly_b…
Cheers,
Daniel
On 1/20/12 12:56 PM, Giacomo Vacca wrote:
Thanks Daniel.
What I'd like to achieve is this: given a cluster of kamailio-based proxy/registrar,
notify a separate entity whenever a contact is inserted or removed (either by deletion or
expiration).
I'd like this separate entity to be stateless (i.e. don't manage expiry time),
avoid using a DB as shared information and have asynchronous notifications.
This is why I thought pua_usrloc could help me, without the need of a full presence server
in the architecture to manage expiry times for presentities.
What do you think could be used to achieve this?
From my point of view the ideal solution is
implementing reg-info events (RFC 3680), where the separate entity mentioned above acts as
watcher for reg-info events on all kamailio instances.
But I'm really looking at
a simpler, lighter solution.
Regards,
Giacomo
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: 20 January 2012 10:58
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Cc: Giacomo Vacca
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is deleted or expires
Hi Giacomo,
On 1/19/12 11:49 AM, Giacomo Vacca wrote:
Ah thanks Daniel,
So I had a wrong expectation on the behaviour of pua_usrloc.
It does make sense that the PUBLISH already carries its expiry and so the expiration
moment is implicit and should/can be handled elsewhere.
I think what confused me were two things: the pua_usrloc documentation and the fact that
pua_usrloc does register for EXPIRE callbacks with usrloc.
I'm referring to:
"The pua_usrloc module is the connector between the usrloc and pua modules. It
creates the environment to send PUBLISH requests for user location records, on specific
events (e.g., when new record is added in usrloc, a PUBLISH with status open (online) is
issued; when expires, it sends closed (offline))."
perhaps the documentation is misleading a bit with its phrasing. It send offline (closed)
when it is an un-register, before the expiration. I haven't looked in the code, but
based on log messages and correlated with the expired carried by PUBLISH, the behavior is
correct over all.
There is another aspect, usrloc cleans up expired records on timer, so usrloc callback can
be executed later than actual expiration. A publish at that time could be late. Of course,
presence does cleanup on timer as well, but it may be more accurate to handle expiration
there. It is like when an UA with presence support disappears from networks, without
sending any PUBLISH updates.
Cheers,
DAniel
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: 19 January 2012 10:37
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Cc: Giacomo Vacca
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is deleted or expires
Hello,
On 1/19/12 11:22 AM, Giacomo Vacca wrote:
Hi Daniel,
Thanks for your feedback. Yes, using mysql and enabling presence made it work for
un-registrations too.
Just for the purpose of this scenario I'm sending the PUBLISH back to the same entity,
and it's being handled as a presentity.
I still have a missing piece though (which is in fact the reason for this configuration):
having PUBLISH requests triggered by the expiration of a contact.
When a contact expires, pua_usrloc is now logging:
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: INFO: pua_usrloc [ul_publish.c:211]:
should not send ul publish
(please see below for traces and details).
Since I'm marking a registration with pua_set_publish(), why is that flag not seen as
true when usrloc fires an EXPIRE callback?
I've tried marking every REGISTER request with pua_set_publish(), and not just the
first one, before calling save("location") but the result was the same.
the PUBLISH for registration expiration does not make sense, as PUBLISH has also an expire
interval, so the record in the presence server should expire at the same time. A publish
with update state to close will eventually hit the presence server when there is no record
for it. Presence server will send notifications when the record in its table expires.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Truphone Limited is a limited liability company registered in England & Wales,
registered office: 5 New Street Square, London EC4A 3TW. Registered No. 04187081. VAT No.
GB 851 5278 19.
Tru is a brand name of Truphone and is a Truphone Communications Service. Truphone is a
trading name for a number of distinct legal entities that operate in combination.
www.truphone.com<http://www.truphone.com>om>.
This e-mail, and any attachment(s), may contain information which is confidential and/or
privileged, and is intended for the addressee only. If you are not the intended recipient,
you may not use, disclose, copy or distribute this information in any manner whatsoever.
If you have received this e-mail in error, please contact the sender immediately and
delete it.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Truphone Limited is a limited liability company registered in England & Wales,
registered office: 4 Royal Mint Court, London, EC3N 4HJ. Registered No. 04187081. VAT No.
GB 851 5278 19.
Tru is a brand name of Truphone and is a Truphone Communications Service. Truphone is a
trading name for a number of distinct legal entities that operate in combination.
www.truphone.com<http://www.truphone.com>om>.
This e-mail, and any attachment(s), may contain information which is confidential and/or
privileged, and is intended for the addressee only. If you are not the intended recipient,
you may not use, disclose, copy or distribute this information in any manner whatsoever.
If you have received this e-mail in error, please contact the sender immediately and
delete it.
5:08 p.m.
New subject: pua_usrloc, PUBLISH not send when contact is deleted or expires
As promised test results for pua_usrloc: it's working correctly (devel version from
git, Linux debian 2.6.32-5-686).
Please see below traces and logs extracts (just for the purpose of the test the PUBLISH is
sent to localhost as configured).
Module configuration was:
modparam("pua", "db_url", DBURL); # mysql
modparam("pua_usrloc", "default_domain", "127.0.0.1")
modparam("pua_usrloc", "branch_flag", 9)
Just for completeness I've verified that pua_usrloc keeps working OK for contact
deletes.
Thanks!
Giacomo
---
Initial registration:
T 2012/01/27 15:12:19.465839 192.168.142.1:60712 -> 192.168.142.133:5060 [AP]
REGISTER sip:192.168.142.133 SIP/2.0.
Via: SIP/2.0/TCP
192.168.142.1:15348;branch=z9hG4bK-d8754z-1c734517dce8d6d2-1---d8754z-;rport.
Max-Forwards: 70.
Contact:
<sip:gvsip001@192.168.142.1:15348;rinstance=b1cd596c8f03cc95;transport=TCP>.
To: "GV_XLite"<sip:gvsip001@192.168.142.133>.
From: "GV_XLite"<sip:gvsip001@192.168.142.133>;tag=a35dbef7.
Call-ID: MmI3NTA5MjU4NDliODc3YThhOTQ1YzY3NWE5NWRkMGM..
CSeq: 1 REGISTER.
Expires: 3600.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
User-Agent: X-Lite 4 release 4.1 stamp 63214.
Content-Length: 0.
.
U 2012/01/27 15:12:19.469144 192.168.142.133:5060 -> 127.0.0.1:5060
PUBLISH sip:gvsip001@127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 192.168.142.133;branch=z9hG4bK38df.22189b63.0.
To: sip:gvsip001@127.0.0.1.
From: sip:gvsip001@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-3e09.
CSeq: 10 PUBLISH.
Call-ID: 3fbf2f18-21027(a)127.0.0.1.
Content-Length: 338.
User-Agent: kamailio (3.3.0-dev5 (i386/linux)).
Max-Forwards: 70.
Event: presence.
Expires: 61.
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="gvsip001(a)127.0.0.1">
<tuple id="0xb720872c">
<status>
<basic>open</basic>
</status>
</tuple>
</presence>
U 2012/01/27 15:12:19.470741 127.0.0.1:5060 -> 192.168.142.133:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.142.133;branch=z9hG4bK38df.22189b63.0.
To: sip:gvsip001@127.0.0.1;tag=a6a1c5f60faecf035a1ae5b6e96e979a-3301.
From: sip:gvsip001@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-3e09.
CSeq: 10 PUBLISH.
Call-ID: 3fbf2f18-21027(a)127.0.0.1.
Expires: 60.
SIP-ETag: a.1327676609.21015.2.0.
Content-Length: 0.
.
T 2012/01/27 15:12:19.472570 192.168.142.133:5060 -> 192.168.142.1:60712 [AP]
SIP/2.0 200 OK.
[...]
CSeq: 1 REGISTER.
Contact:
<sip:gvsip001@192.168.142.1:15348;rinstance=b1cd596c8f03cc95;transport=TCP>;expires=60.
[...]
Registration refresh:
T 2012/01/27 15:13:12.402912 192.168.142.1:60712 -> 192.168.142.133:5060 [AP]
REGISTER sip:192.168.142.133 SIP/2.0.
Via: SIP/2.0/TCP
192.168.142.1:15348;branch=z9hG4bK-d8754z-05f5f507327ed10e-1---d8754z-;rport.
Max-Forwards: 70.
Contact:
<sip:gvsip001@192.168.142.1:15348;rinstance=b1cd596c8f03cc95;transport=TCP>.
To: "GV_XLite"<sip:gvsip001@192.168.142.133>.
From: "GV_XLite"<sip:gvsip001@192.168.142.133>;tag=a35dbef7.
Call-ID: MmI3NTA5MjU4NDliODc3YThhOTQ1YzY3NWE5NWRkMGM..
CSeq: 2 REGISTER.
Expires: 3600.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
User-Agent: X-Lite 4 release 4.1 stamp 63214.
Content-Length: 0.
.
U 2012/01/27 15:13:12.416524 192.168.142.133:5060 -> 127.0.0.1:5060
PUBLISH sip:gvsip001@127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 192.168.142.133;branch=z9hG4bKcdd3.7a00dd97.0.
To: sip:gvsip001@127.0.0.1.
From: sip:gvsip001@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-ecb2.
CSeq: 10 PUBLISH.
Call-ID: 3fbf2f19-21025(a)127.0.0.1.
Content-Length: 0.
User-Agent: kamailio (3.3.0-dev5 (i386/linux)).
Max-Forwards: 70.
Event: presence.
Expires: 61.
SIP-If-Match: a.1327676609.21015.2.0.
.
T 2012/01/27 15:13:12.423807 192.168.142.133:5060 -> 192.168.142.1:60712 [AP]
SIP/2.0 200 OK.
[...]
CSeq: 2 REGISTER.
[...]
U 2012/01/27 15:13:12.441273 127.0.0.1:5060 -> 192.168.142.133:5060
SIP/2.0 200 OK.
[...]
CSeq: 10 PUBLISH.
[...]
---
Another registration refresh:
T 2012/01/27 15:14:05.197789 192.168.142.1:60712 -> 192.168.142.133:5060 [AP]
REGISTER sip:192.168.142.133 SIP/2.0.
[...]
Contact expires. Logs:
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: usrloc [ul_callback.h:89]:
contact=0xb4d2c06c, callback type 8/8, id 1 entered
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua_usrloc
[ul_publish.c:235]: #012EXPIRE type
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua_usrloc
[ul_publish.c:265]: uri= sip:gvsip001@127.0.0.1
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua_usrloc
[ul_publish.c:71]: publ:
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua_usrloc
[ul_publish.c:72]: uri= sip:gvsip001@127.0.0.1
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua_usrloc
[ul_publish.c:73]: id= UL_PUBLISH.MmI3NTA5MjU4NDliODc3YThhOTQ1YzY3NWE5NWRkMGM.
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua_usrloc
[ul_publish.c:74]: expires= 0
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua [send_publish.c:464]:
pres_uri=sip:gvsip001@127.0.0.1
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua [hash.c:134]:
core_hash= 210
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua [hash.c:176]: no etag
restriction
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua [hash.c:185]: found
record
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua [send_publish.c:543]:
record found in hash_table
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua [send_publish.c:582]:
expires= 0- delete from hash table
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua [send_publish.c:631]:
etag:a.1327676609.21016.3.2
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua [send_publish.c:110]:
UPDATE_TYPE [etag]= a.1327676609.21016.3.2
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua [send_publish.c:641]:
publ->pres_uri:#012sip:gvsip001@127.0.0.1#012
Jan 27 15:15:29 debian6 /usr/local/sbin/kamailio[21021]: DEBUG: pua [send_publish.c:642]:
str_hdr:#012Max-Forwards: 70#015#012Event: presence#015#012Expires: 0#015#012SIP-If-Match:
a.1327676609.21016.3.2#015#012 85#012
[...]
PUBLISH correctly sent, with 'Expires: 0':
U 2012/01/27 15:15:29.879263 192.168.142.133:5060 -> 127.0.0.1:5060
PUBLISH sip:gvsip001@127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 192.168.142.133;branch=z9hG4bK96eb.7dba84f7.0.
To: sip:gvsip001@127.0.0.1.
From: sip:gvsip001@127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-4956.
CSeq: 10 PUBLISH.
Call-ID: 3fbf2f18-21021(a)127.0.0.1.
Content-Length: 0.
User-Agent: kamailio (3.3.0-dev5 (i386/linux)).
Max-Forwards: 70.
Event: presence.
Expires: 0.
SIP-If-Match: a.1327676609.21016.3.2.
.
[...]
.
From: Giacomo Vacca
Sent: 27 January 2012 09:17
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Subject: RE: [SR-Users] pua_usrloc, PUBLISH not send when contact is deleted or expires
Hi Daniel,
This is just great. I'll test asap and report back.
Cheers,
Giacomo
From: Daniel-Constantin Mierla
[mailto:miconda@gmail.com]<mailto:[mailto:miconda@gmail.com]>
Sent: 27 January 2012 09:03
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Cc: Giacomo Vacca
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is deleted or expires
Hi Giacomo,
I patched few days ago to make pua_usrloc sending the PUBLISH also for location record
expiration.
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=bdbacf5…
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=266fa4e…
The idea is to set a branch flag for marking the contact for publishing --
pua_set_publish() can be still used actually, it sets also the branch flag internally, if
the module parameter specifying the flag is set -- alternative is to use directly
setbflag(index).
I was out of office and couldn't try it yet, maybe you can test and report if it is
working fine.
You have to install devel version, either from git or from nightly debs:
http://www.kamailio.org/wiki/packages/debs#kamailio_development_-_nightly_b…
Cheers,
Daniel
On 1/20/12 12:56 PM, Giacomo Vacca wrote:
Thanks Daniel.
What I'd like to achieve is this: given a cluster of kamailio-based proxy/registrar,
notify a separate entity whenever a contact is inserted or removed (either by deletion or
expiration).
I'd like this separate entity to be stateless (i.e. don't manage expiry time),
avoid using a DB as shared information and have asynchronous notifications.
This is why I thought pua_usrloc could help me, without the need of a full presence server
in the architecture to manage expiry times for presentities.
What do you think could be used to achieve this?
From my point of view the ideal solution is
implementing reg-info events (RFC 3680), where the separate entity mentioned above acts as
watcher for reg-info events on all kamailio instances.
But I'm really looking at
a simpler, lighter solution.
Regards,
Giacomo
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: 20 January 2012 10:58
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Cc: Giacomo Vacca
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is deleted or expires
Hi Giacomo,
On 1/19/12 11:49 AM, Giacomo Vacca wrote:
Ah thanks Daniel,
So I had a wrong expectation on the behaviour of pua_usrloc.
It does make sense that the PUBLISH already carries its expiry and so the expiration
moment is implicit and should/can be handled elsewhere.
I think what confused me were two things: the pua_usrloc documentation and the fact that
pua_usrloc does register for EXPIRE callbacks with usrloc.
I'm referring to:
"The pua_usrloc module is the connector between the usrloc and pua modules. It
creates the environment to send PUBLISH requests for user location records, on specific
events (e.g., when new record is added in usrloc, a PUBLISH with status open (online) is
issued; when expires, it sends closed (offline))."
perhaps the documentation is misleading a bit with its phrasing. It send offline (closed)
when it is an un-register, before the expiration. I haven't looked in the code, but
based on log messages and correlated with the expired carried by PUBLISH, the behavior is
correct over all.
There is another aspect, usrloc cleans up expired records on timer, so usrloc callback can
be executed later than actual expiration. A publish at that time could be late. Of course,
presence does cleanup on timer as well, but it may be more accurate to handle expiration
there. It is like when an UA with presence support disappears from networks, without
sending any PUBLISH updates.
Cheers,
DAniel
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: 19 January 2012 10:37
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
Cc: Giacomo Vacca
Subject: Re: [SR-Users] pua_usrloc, PUBLISH not send when contact is deleted or expires
Hello,
On 1/19/12 11:22 AM, Giacomo Vacca wrote:
Hi Daniel,
Thanks for your feedback. Yes, using mysql and enabling presence made it work for
un-registrations too.
Just for the purpose of this scenario I'm sending the PUBLISH back to the same entity,
and it's being handled as a presentity.
I still have a missing piece though (which is in fact the reason for this configuration):
having PUBLISH requests triggered by the expiration of a contact.
When a contact expires, pua_usrloc is now logging:
Jan 19 10:12:03 debian6 /usr/sbin/kamailio[4359]: INFO: pua_usrloc [ul_publish.c:211]:
should not send ul publish
(please see below for traces and details).
Since I'm marking a registration with pua_set_publish(), why is that flag not seen as
true when usrloc fires an EXPIRE callback?
I've tried marking every REGISTER request with pua_set_publish(), and not just the
first one, before calling save("location") but the result was the same.
the PUBLISH for registration expiration does not make sense, as PUBLISH has also an expire
interval, so the record in the presence server should expire at the same time. A publish
with update state to close will eventually hit the presence server when there is no record
for it. Presence server will send notifications when the record in its table expires.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Truphone Limited is a limited liability company registered in England & Wales,
registered office: 5 New Street Square, London EC4A 3TW. Registered No. 04187081. VAT No.
GB 851 5278 19.
Tru is a brand name of Truphone and is a Truphone Communications Service. Truphone is a
trading name for a number of distinct legal entities that operate in combination.
www.truphone.com<http://www.truphone.com>om>.
This e-mail, and any attachment(s), may contain information which is confidential and/or
privileged, and is intended for the addressee only. If you are not the intended recipient,
you may not use, disclose, copy or distribute this information in any manner whatsoever.
If you have received this e-mail in error, please contact the sender immediately and
delete it.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Truphone Limited is a limited liability company registered in England & Wales,
registered office: 4 Royal Mint Court, London, EC3N 4HJ. Registered No. 04187081. VAT No.
GB 851 5278 19.
Tru is a brand name of Truphone and is a Truphone Communications Service. Truphone is a
trading name for a number of distinct legal entities that operate in combination.
www.truphone.com<http://www.truphone.com>om>.
This e-mail, and any attachment(s), may contain information which is confidential and/or
privileged, and is intended for the addressee only. If you are not the intended recipient,
you may not use, disclose, copy or distribute this information in any manner whatsoever.
If you have received this e-mail in error, please contact the sender immediately and
delete it.
4486
days inactive
4495
days old
11 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Giacomo Vacca