[sr-dev] Possible PUA bug

[Daniel-Constantin Mierla]

Hello,

On 6/8/11 3:48 PM, Peter Dunkley wrote:
> 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?
had no time to look into the code, you should have it fresh in mind -- 
is any other unique key that could be used to match the dialog in pua 
hash table? If not, then maybe adding a new field to keep the initial 
remote_contact is a solution, so if matching on remote contact does not 
return, lookup again on initial field.

Cheers,
Daniel
>
> Regards,
>
> Peter
>
> -- 
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110609/22829755/attachment.htm>