[sr-dev] Possible PUA bug
Daniel-Constantin Mierla
miconda at gmail.com
Thu Jun 9 08:33:27 CEST 2011
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>
More information about the sr-dev
mailing list