<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>26 okt 2012 kl. 19:07 skrev Peter Dunkley &lt;<a href="mailto:peter.dunkley@crocodile-rcs.com">peter.dunkley@crocodile-rcs.com</a>&gt;:</div><br class="Apple-interchange-newline"><blockquote type="cite">


  <meta http-equiv="Content-Type" content="text/html; CHARSET=UTF-8">
  <meta name="GENERATOR" content="GtkHTML/4.4.4">

<div>
Hi,<br>
<br>
External anchors are not currently supported by the Kamailio RLS module.&nbsp; The presence of these do not explain all of the symptoms you are seeing - but you are not going to be able to get your resource-lists working properly if they are in there - at best these will be ignored, at worst they will cause errors.<br>
<br>
For each &lt;entry /&gt; in your resource list the RLS module will create a back-end subscription (using the PUA module) to a Presence Server.&nbsp; When using Kamailio it is often the case that this Presence Server is actually the Kamailio presence module running on the same instance of Kamailio as RLS and PUA - but even in this case Kamailio will create and send a real SUBSCRIBE request (it'll just loop to itself).<br>
<br>
After logging in with an RLS capable client you should end up with the following:
<ul>
    <li>One presentity in the presentity table
    </li><li>One presence.winfo dialog in the active_watchers table
    </li><li>One presence dialog in the rls_watchers table
    </li><li>One presence dialog for each &lt;entry /&gt; in the resource-list in the pua table
    </li><li>One presence dialog for each &lt;entry /&gt; in the resource-list in the active_watchers table
    </li><li>One entry in the watchers table for each watcher/presentity relationship indicating state (active, pending, terminated, etc) - these are the cached (to avoid the overhead of continually re-parsing the same XML document) results of the presence module processing pres-rules for each presence subscription
</li></ul>
The rls_presentity table will be empty until you have multiple clients signed in concurrently and are sharing presence between them.<br>
<br></div></blockquote>Peter,</div><div>I know the weekend is coming up, but I would love seeing this in the RLS README. Could you put that on your to-do list? We can't have TOO MUCH documentation...</div><div><br></div><div>Thanks,</div><div>/O<br><blockquote type="cite"><div>
Regards,<br>
<br>
Peter<br>
<br>
On Fri, 2012-10-26 at 10:44 -0500, Sangeeta Shah wrote:
<blockquote type="CITE">
<pre>Hugh,
   Thanks for the response.

When the client subscribes to the presence.winfo event - it does
result in an entry in the active_watchers table.

Then it is sending a subscribe to the presence event with the
supported header set to "eventlist"

Also I am starting from an empty database. So as you said, the client
is getting a 404 back and then putting the pres-rules, rls-services,
and resource-lists documents. The client that is connecting has no
contacts. All 3 documents have external anchors which I unfortunately
cannot disable :(

So the resource-list XML is as follows:
&lt;resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"&gt;
  &lt;list name="rcs"&gt;
    &lt;display-name&gt;All Contacts&lt;/display-name&gt;
    &lt;external anchor="<a href="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22doubango%22%5D">http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22doubango%22%5D</a>"
/&gt;
    &lt;entry uri="<a href="sip:8475551001@ip">sip:8475551001@ip</a>" /&gt;
  &lt;/list&gt;
  &lt;list name="rcs_blockedcontacts"&gt;
    &lt;display-name&gt;Blocked Contacts&lt;/display-name&gt;
  &lt;/list&gt;
  &lt;list name="rcs_revokedcontacts"&gt;
    &lt;display-name&gt;Revoked Contacts&lt;/display-name&gt;
  &lt;/list&gt;
  &lt;list name="oma_allcontacts"&gt;
    &lt;display-name&gt;OMA All Contacts&lt;/display-name&gt;
  &lt;/list&gt;
  &lt;list name="oma_blockedcontacts"&gt;
    &lt;display-name&gt;OMA Blocked Contacts&lt;/display-name&gt;
    &lt;external anchor="<a href="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs_blockedcontacts%22%5D">http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs_blockedcontacts%22%5D</a>"
/&gt;
    &lt;external anchor="<a href="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs_revokedcontacts%22%5D">http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs_revokedcontacts%22%5D</a>"
/&gt;
  &lt;/list&gt;
  &lt;list name="oma_buddylist"&gt;
    &lt;display-name&gt;OMA BuddyList&lt;/display-name&gt;
    &lt;external anchor="<a href="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs%22%5D">http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs%22%5D</a>"
/&gt;
    &lt;external anchor="<a href="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22oma_pocbuddylist%22%5D">http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22oma_pocbuddylist%22%5D</a>"
/&gt;
  &lt;/list&gt;
  &lt;list name="oma_grantedcontacts"&gt;
    &lt;display-name&gt;OMA Granted Contacts&lt;/display-name&gt;
    &lt;external anchor="<a href="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs%22%5D">http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs%22%5D</a>"
/&gt;
    &lt;external anchor="<a href="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22oma_buddylist%22%5D">http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22oma_buddylist%22%5D</a>"
/&gt;
  &lt;/list&gt;
  &lt;list name="oma_pocbuddylist"&gt;
    &lt;display-name&gt;OMA POC BuddyList&lt;/display-name&gt;
  &lt;/list&gt;
  &lt;list name="doubango"&gt;
    &lt;display-name&gt;My Default Contacts&lt;/display-name&gt;
  &lt;/list&gt;
&lt;/resource-lists&gt;

Now when I run tcpdump on the loopback interface I see a ton of
messages generated from the server - to the server as follows
(excerpt), there are a ton of presence subscribes and corresponding
notifies that are going back to the server, only one instance of the
publish below:

PUBLISH <a href="sip:8475551001@ip">sip:8475551001@ip</a> SIP/2.0

Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK6596.773f3d36.0

To: <a href="sip:8475551001@kamailio-ip">sip:8475551001@kamailio-ip</a>

From: <a href="sip:8475551001@kamailio-ip">sip:8475551001@kamailio-ip</a>;tag=533cb9e91f4b999cf76861cbb9ed54ed-404e

CSeq: 10 PUBLISH

Call-ID: <a href="mailto:3a1e3ea20824a642-1670@127.0.0.1">3a1e3ea20824a642-1670@127.0.0.1</a>

Content-Length: 499

User-Agent: kamailio (3.3.2 (x86_64/linux))

Max-Forwards: 70

Event: reg

Expires: 3601

Content-Type: application/reginfo+xml



&lt;?xml version="1.0"?&gt;
&lt;reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="0" state="full"&gt;
  &lt;registration aor="<a href="sip:8475551001@kamailio-ip">sip:8475551001@kamailio-ip</a>" id="0x7f62677013a0"
state="active"&gt;
    &lt;contact id="0x7f6267701410" state="active" event="created"
expires="600000" callid="ea899804-de89-fdff-2f22-176bd8996221"
cseq="15648" received="" path="" user_agent="IM-client/OMA1.0
Boghe/v2.0.97.687"&gt;
      &lt;uri&gt;<a href="sip:8475551001@10.51.2.181:63311">sip:8475551001@10.51.2.181:63311</a>;transport=udp&lt;/uri&gt;
    &lt;/contact&gt;
  &lt;/registration&gt;
&lt;/reginfo&gt;
SIP/2.0 200 OK

Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK6596.773f3d36.0

To: <a href="sip:8475551001@kamailio-ip">sip:8475551001@kamailio-ip</a>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-a070

From: <a href="sip:8475551001@kamailio-ip">sip:8475551001@kamailio-ip</a>;tag=533cb9e91f4b999cf76861cbb9ed54ed-404e

CSeq: 10 PUBLISH

Call-ID: <a href="mailto:3a1e3ea20824a642-1670@127.0.0.1">3a1e3ea20824a642-1670@127.0.0.1</a>

Expires: 3600

SIP-ETag: a.1351264309.1668.1.0

Server: kamailio (3.3.2 (x86_64/linux))

Content-Length: 0



SUBSCRIBE <a href="sip:8475551001@kamailio-ip">sip:8475551001@kamailio-ip</a> SIP/2.0

Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK761d.6ebf4355.0

To: <a href="sip:8475551001@kamailio-ip">sip:8475551001@kamailio-ip</a>

From: <a href="sip:8475551001@kamailio-ip">sip:8475551001@kamailio-ip</a>;tag=533cb9e91f4b999cf76861cbb9ed54ed-bfdd

CSeq: 10 SUBSCRIBE

Call-ID: <a href="mailto:3a1e3ea20824a642-1668@127.0.0.1">3a1e3ea20824a642-1668@127.0.0.1</a>

Content-Length: 0

User-Agent: kamailio (3.3.2 (x86_64/linux))

Max-Forwards: 70

Event: presence

Contact: &lt;<a href="sip:kamailio-ip:5060">sip:kamailio-ip:5060</a>&gt;

Expires: 7210

Supported: eventlist

Accept: application/pidf+xml, application/rlmi+xml,
application/watcherinfo+xml, multipart/related



SIP/2.0 200 OK

Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK761d.6ebf4355.0

To: <a href="sip:8475551001@kamailio-ip">sip:8475551001@kamailio-ip</a>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-8fd4

From: <a href="sip:8475551001@kamailio-ip">sip:8475551001@kamailio-ip</a>;tag=533cb9e91f4b999cf76861cbb9ed54ed-bfdd

CSeq: 10 SUBSCRIBE

Call-ID: <a href="mailto:3a1e3ea20824a642-1668@127.0.0.1">3a1e3ea20824a642-1668@127.0.0.1</a>

Expires: 7200

Contact: &lt;<a href="sip:kamailio-ip:5060">sip:kamailio-ip:5060</a>&gt;

Require: eventlist

Server: kamailio (3.3.2 (x86_64/linux))

Content-Length: 0



SUBSCRIBE <a href="sip:8475551001@kamailio-ip">sip:8475551001@kamailio-ip</a> SIP/2.0

Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK25f.0e3d3f64.0

To: <a href="sip:8475551001@kamailio-ip">sip:8475551001@kamailio-ip</a>

From: <a href="sip:8475551001@kamailio-ip">sip:8475551001@kamailio-ip</a>;tag=533cb9e91f4b999cf76861cbb9ed54ed-62f4

CSeq: 10 SUBSCRIBE

Call-ID: <a href="mailto:3a1e3ea20824a642-1672@127.0.0.1">3a1e3ea20824a642-1672@127.0.0.1</a>

Content-Length: 0

User-Agent: kamailio (3.3.2 (x86_64/linux))

Max-Forwards: 70

Event: presence

Contact: &lt;<a href="sip:kamailio-ip:5060">sip:kamailio-ip:5060</a>&gt;

Expires: 7210

Supported: eventlist

Accept: application/pidf+xml, application/rlmi+xml,
application/watcherinfo+xml, multipart/related



SIP/2.0 200 OK

Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK25f.0e3d3f64.0

To: <a href="sip:8475551001@kamailio-ip">sip:8475551001@kamailio-ip</a>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-ceeb

From: <a href="sip:8475551001@kamailio-ip">sip:8475551001@kamailio-ip</a>;tag=533cb9e91f4b999cf76861cbb9ed54ed-62f4

CSeq: 10 SUBSCRIBE

Call-ID: <a href="mailto:3a1e3ea20824a642-1672@127.0.0.1">3a1e3ea20824a642-1672@127.0.0.1</a>

Expires: 7200

Contact: &lt;<a href="sip:kamailio-ip:5060">sip:kamailio-ip:5060</a>&gt;

Require: eventlist

Server: kamailio (3.3.2 (x86_64/linux))

Content-Length: 0

I am not sure if it's the nature of the resource-list document or
something in the config file that's causing this loop. I am guessing
it might be the following entry:
  &lt;list name="rcs"&gt;
    &lt;display-name&gt;All Contacts&lt;/display-name&gt;
    &lt;external anchor="<a href="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22doubango%22%5D">http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22doubango%22%5D</a>"
/&gt;
    &lt;entry uri="<a href="sip:8475551001@ip">sip:8475551001@ip</a>" /&gt;
  &lt;/list&gt;

But why would all these subscribes go back to the server? Should I be
handling them in the routing code in the config file. They all have
unique to tags/from tags/and call ids.

I am willing to modify the code with some direction on how to better
handle this.

Thanks,
Sangeeta

On Fri, Oct 26, 2012 at 9:36 AM, Hugh Waite
&lt;<a href="mailto:hugh.waite@crocodile-rcs.com">hugh.waite@crocodile-rcs.com</a>&gt; wrote:
&gt; Hi,
&gt;
&gt; I don't know what might cause exactly the issues you are seeing, but here's
&gt; what I would do to track it down.
&gt;
&gt; 1. If no xcap documents exist on the system, the client will get a 404 and
&gt; should usually PUT some new (empty) documents.
&gt;
&gt; Assuming these 'empty' documents exist, the following should happen when the
&gt; client logs in.
&gt; a. When the SUBSCRIBE to presence.winfo arrives it should create a single
&gt; entry in the 'active-watchers' table. It should show a single subscription
&gt; to presence.winfo where the watcher and presentity URI are the same user.
&gt; c. When the SUBSCRIBE to RLS arrives, it should create a single entry in
&gt; 'rls_watchers'. As there are no contacts in the resource-list doc, there are
&gt; no rls subscriptions.
&gt;
&gt; My questions to try and debug would be:
&gt; 1. Does the above happen when starting from a clean database and not having
&gt; any contacts or external links in the resource-list?
&gt;
&gt; 2. If that works, can you add contacts directly to the resource-list (like
&gt; below) and try again. Does that cause a problem? You should see entries in
&gt; 'pua' and 'active-watchers' for the added contacts.
&gt;
&gt; &lt;?xml version="1.0" encoding="UTF-8"?&gt;
&gt; &lt;resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"&gt;
&gt;     &lt;list name="oma_buddylist"&gt;
&gt;         &lt;entry uri="<a href="sip:160000@example.com">sip:160000@example.com</a>"&gt;
&gt;             &lt;display-name&gt;160000&lt;/display-name&gt;
&gt;         &lt;/entry&gt;
&gt;         &lt;entry uri="<a href="sip:160001@example.com">sip:160001@example.com</a>"&gt;
&gt;             &lt;display-name&gt;160001&lt;/display-name&gt;
&gt;         &lt;/entry&gt;
&gt;     &lt;/list&gt;
&gt; &lt;/resource-lists&gt;
&gt;
&gt; 3. Finally add the external documents and external anchors and try again.
&gt;
&gt; I haven't personally used anything that uses the external anchors feature,
&gt; but if it is only the external URIs that are causing the problem, kamailio
&gt; may think it is subscribing to the same URI each time causing a recursive
&gt; loop. This may be visible on a network trace taken on the loopback
&gt; interface.
&gt;
&gt; Regards,
&gt; Hugh
&gt;
&gt;
&gt;
&gt; On 26/10/2012 13:36, Sangeeta Shah wrote:
&gt;
&gt; Did anyone get a chance to look at this post. I upgraded to Kamailio
&gt; 3.3.2 since the changelog indicated several RLS fixes. But as soon as
&gt; I bring my client up I see 4000 entries in my PUA table and about 500+
&gt; entries in the rls_watchers table for the same presentity.
&gt;
&gt; What would trigger behavior like this? Either I have an error or am
&gt; missing something in the config file or it's my XML. Any thoughts. I
&gt; have included my config params in this email chain and my
&gt; rls-services, pres-rules and resource-lists documents are from the OMA
&gt; specs with external anchors etc.
&gt;
&gt; Thanks,
&gt; Sangeeta
&gt;
&gt; On Mon, Oct 22, 2012 at 3:32 PM, Sangeeta Shah &lt;<a href="mailto:sangeeta.shah@gmail.com">sangeeta.shah@gmail.com</a>&gt;
&gt; wrote:
&gt;
&gt; Hello All,
&gt;    I am hoping the authors of the RLS/PUA modules can answer this
&gt; question since I am not sure what's going on. I have the rls module
&gt; enabled, with the following config spec:
&gt;
&gt; # ------rls module params ------
&gt; modparam("rls", "db_url", DBURL)
&gt; modparam("rls", "db_mode", 2)
&gt; modparam("rls", "integrated_xcap_server", 1)
&gt; modparam("rls", "to_presence_code" ,10)
&gt; modparam("rls", "server_address", "<a href="sip:rls@ip:5060">sip:rls@ip:5060</a>")
&gt;
&gt;
&gt; #!endif
&gt;
&gt; and
&gt; modparam("pua_reginfo", "default_domain", "ip")
&gt; modparam("pua_reginfo", "server_address", "<a href="sip:reginfo@ip">sip:reginfo@ip</a>")
&gt; modparam("pua", "db_mode", 2)
&gt;
&gt; So for both I have DB_MODE set to DB ONLY. For whatever reason, even
&gt; though all I am doing is bringing up my client I see over 250+ entries
&gt; in the rls_watchers table for the same watcher and over 100 entries in
&gt; the pua list table for the same presentity?
&gt;
&gt; Anyone have any idea what would be triggering this. There is
&gt; definitely not anymore more than the normal messaging going on between
&gt; the client and the server.
&gt;
&gt; Only error I see in the syslog:
&gt; Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11745]: ERROR:
&gt; db_mysql [km_dbase.c:122]: driver error on query: Duplicate entry
&gt; '1350937406' for key 'expires_idx'
&gt; Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11744]: DEBUG:
&gt; presence [subscribe.c:1216]: subs-&gt;contact= <a href="sip:rls@ip:5060">sip:rls@ip:5060</a> - len = 25
&gt; Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11761]: DEBUG:
&gt; &lt;core&gt; [db_val.c:117]: converting STRING [8475551001]
&gt; Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11746]: DEBUG:
&gt; &lt;core&gt; [parser/msg_parser.c:626]:  method:  &lt;SUBSCRIBE&gt;
&gt; Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11745]: ERROR:
&gt; &lt;core&gt; [db_query.c:210]: error while submitting query
&gt; Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11744]: DEBUG:
&gt; rls [rls.h:241]: did=
&gt; <a href="mailto:41826031568472f9-11752@127.0.0.1">41826031568472f9-11752@127.0.0.1</a>;533cb9e91f4b999cf76861cbb9ed54ed-93a3;a6a1c5f60faecf035a1ae5b6e96e979a-464d
&gt; Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11761]: DEBUG:
&gt; &lt;core&gt; [db_val.c:117]: converting STRING [10.50.251.12]
&gt; Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11746]: DEBUG:
&gt; &lt;core&gt; [parser/msg_parser.c:628]:  uri:     &lt;<a href="sip:8475551001@ip">sip:8475551001@ip</a>&gt;
&gt; Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11745]: ERROR:
&gt; pua [pua_db.c:1149]: DB insert failed
&gt;
&gt;
&gt;
&gt; --
&gt; Sangeeta Shah
&gt;
&gt;
&gt;
&gt;
&gt; --
&gt; Hugh Waite
&gt; Principal Design Engineer
&gt; Crocodile RCS Ltd.
&gt;
&gt;
&gt; _______________________________________________
&gt; SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
&gt; <a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
&gt; <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
&gt;



</pre>
</blockquote>
<br>
<table cellspacing="0" cellpadding="0" width="100%">
<tbody><tr>
<td>
<pre>-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</pre>
</td>
</tr>
</tbody></table>
</div>

_______________________________________________<br>SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br><a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users<br></blockquote></div><br></body></html>