[SR-Users] pua_usrloc, PUBLISH not send when contact is deleted or expires

Fri Jan 27 17:08:32 CET 2012

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 at 192.168.142.1:15348;rinstance=b1cd596c8f03cc95;transport=TCP>.
To: "GV_XLite"<sip:gvsip001 at 192.168.142.133>.
From: "GV_XLite"<sip:gvsip001 at 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 at 127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 192.168.142.133;branch=z9hG4bK38df.22189b63.0.
To: sip:gvsip001 at 127.0.0.1.
From: sip:gvsip001 at 127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-3e09.
CSeq: 10 PUBLISH.
Call-ID: 3fbf2f18-21027 at 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 at 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 at 127.0.0.1;tag=a6a1c5f60faecf035a1ae5b6e96e979a-3301.
From: sip:gvsip001 at 127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-3e09.
CSeq: 10 PUBLISH.
Call-ID: 3fbf2f18-21027 at 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 at 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 at 192.168.142.1:15348;rinstance=b1cd596c8f03cc95;transport=TCP>.
To: "GV_XLite"<sip:gvsip001 at 192.168.142.133>.
From: "GV_XLite"<sip:gvsip001 at 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 at 127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 192.168.142.133;branch=z9hG4bKcdd3.7a00dd97.0.
To: sip:gvsip001 at 127.0.0.1.
From: sip:gvsip001 at 127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-ecb2.
CSeq: 10 PUBLISH.
Call-ID: 3fbf2f19-21025 at 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 at 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 at 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 at 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 at 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 at 127.0.0.1 SIP/2.0.
Via: SIP/2.0/UDP 192.168.142.133;branch=z9hG4bK96eb.7dba84f7.0.
To: sip:gvsip001 at 127.0.0.1.
From: sip:gvsip001 at 127.0.0.1;tag=533cb9e91f4b999cf76861cbb9ed54ed-4956.
CSeq: 10 PUBLISH.
Call-ID: 3fbf2f18-21021 at 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 at gmail.com]<mailto:[mailto:miconda at 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=bdbacf559134022856f5723a91fe7e130ceada29
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=266fa4e2cd62f58ee1f2eec2a5a83bc3028d194a

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_builds

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?