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]

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@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"?>

</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@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]

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@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]

[...]

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@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]
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?

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.

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

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.