[sr-dev] Possible PUA bug

Peter Dunkley peter.dunkley at crocodile-rcs.com
Wed Jun 8 15:48:22 CEST 2011


Hello,

I am working with Kamailio RLS which uses PUA as a library to send
SUBSCRIBEs.

Whenever Kamailio receives an RLS subscription it calls
rls_handle_subscribe().  rls_handle_subscribe() calls the function
resource_subscriptions() which in turn calls send_resource_subs() (via
process_list_and_exec()).  resource_subscriptions() and
send_resource_subs() fill in a subs_info_t structure that is passed into
the PUA module send_subscribe() function.

The key part is that send_resource_subs() sets the subs_info_t
remote_target field to the pres_uri.  The PUA send_subscribe() function
uses the remote_target as the remote_contact (in the ua_pres_t
structure) that is used to lookup the dialog in the PUA hash table.
Unfortunately, this lookup always fails because the PUA module correctly
updates the remote contact in the hash table when it gets a response
back from the (Kamailio) presence server.

The effect that this has is that any re-SUBSCRIBE requests from the RLS
module are treated as new initial SUBSCRIBEs.  This causes the pua and
(presence) watchers tables in my Kamailio database to grow rapidly, and
can result in multiple notifications on a presence status change.

I noticed this because I am currently adding a new API to RLS which will
allow me to update my RLS subscriptions whenever my resource list
documents change.  This is needed so that subscribers receive an
immediate presence authorisation request when someone adds them to their
contact list.  The client I am testing with tends to update the RLS
documents frequently (often for superficial changes) and this combined
with the PUA issue described above means with just two clients on the
system (with only each other in the contact list) I can end up with many
10s of records in pua and watchers within a few minutes.

This issue will also have a lesser effect when RLS re-SUBSCRIBEs from
clients occur.  There will be a window (until the original SUBSCRIBE
expires) when there are multiple back-end SUBSCRIBE dialogs for each
contact.

Can anyone advise on this issue and suggest a solution?

Regards,

Peter

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110608/1fcdea76/attachment.htm>


More information about the sr-dev mailing list