<html><body bgcolor="#FFFFFF"><div>Hi Daniel,</div><div><br></div><div>I was thinking of adding a modparam to pua to simply not compare the remote_contact when checking for SUBSCRIBE dialogs. When not set the current pua behaviour will remain.</div><div><br></div><div>The RLS back-end dialogs should be unique across pres_uri and pres_id. The current check is on pres_uri, pres_id, watcher_uri, and remote_contact. So, I don't think remote_contact really needs to be checked here at all.</div><div><br></div><div>This change shouldn't cause problems with anything else that uses pua because the same check should be OK for them too (they may even suffer from the same problem). However, putting in the modparam so the old behaviour is still used by default seems safer for now.</div><div><br></div><div>Perer</div><div><br>On 9 Jun 2011, at 07:33, Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>
Hello,<br>
<br>
On 6/8/11 3:48 PM, Peter Dunkley wrote:
<blockquote cite="mid:1307540902.3252.18.camel@pd-laptop-linux" type="cite">
Hello,<br>
<br>
I am working with Kamailio RLS which uses PUA as a library to send
SUBSCRIBEs.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Can anyone advise on this issue and suggest a solution?<br>
</blockquote>
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.<br>
<br>
Cheers,<br>
Daniel<br>
<blockquote cite="mid:1307540902.3252.18.camel@pd-laptop-linux" type="cite">
<br>
Regards,<br>
<br>
Peter<br>
<br>
<table cellpadding="0" cellspacing="0" width="100%">
<tbody>
<tr>
<td>
<pre>--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</pre>
</td>
</tr>
</tbody>
</table>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
sr-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-dev@lists.sip-router.org"><a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a></a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev"><a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a></a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla -- <a class="moz-txt-link-freetext" href="http://www.asipto.com"><a href="http://www.asipto.com">http://www.asipto.com</a></a>
<a class="moz-txt-link-freetext" href="http://linkedin.com/in/miconda"><a href="http://linkedin.com/in/miconda">http://linkedin.com/in/miconda</a></a> -- <a class="moz-txt-link-freetext" href="http://twitter.com/miconda"><a href="http://twitter.com/miconda">http://twitter.com/miconda</a></a></pre>
</div></blockquote></body></html>