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: <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list name="rcs"> <display-name>All Contacts</display-name> <external anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22doubango%22%5D" /> <entry uri="sip:8475551001@ip" /> </list> <list name="rcs_blockedcontacts"> <display-name>Blocked Contacts</display-name> </list> <list name="rcs_revokedcontacts"> <display-name>Revoked Contacts</display-name> </list> <list name="oma_allcontacts"> <display-name>OMA All Contacts</display-name> </list> <list name="oma_blockedcontacts"> <display-name>OMA Blocked Contacts</display-name> <external anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs_blockedcontacts%22%5D" /> <external anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs_revokedcontacts%22%5D" /> </list> <list name="oma_buddylist"> <display-name>OMA BuddyList</display-name> <external anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs%22%5D" /> <external anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22oma_pocbuddylist%22%5D" /> </list> <list name="oma_grantedcontacts"> <display-name>OMA Granted Contacts</display-name> <external anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22rcs%22%5D" /> <external anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22oma_buddylist%22%5D" /> </list> <list name="oma_pocbuddylist"> <display-name>OMA POC BuddyList</display-name> </list> <list name="doubango"> <display-name>My Default Contacts</display-name> </list> </resource-lists> 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 sip:8475551001@ip SIP/2.0 Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK6596.773f3d36.0 To: sip:8475551001@kamailio-ip From: sip:8475551001@kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-404e CSeq: 10 PUBLISH Call-ID: 3a1e3ea20824a642-1670@127.0.0.1 Content-Length: 499 User-Agent: kamailio (3.3.2 (x86_64/linux)) Max-Forwards: 70 Event: reg Expires: 3601 Content-Type: application/reginfo+xml <?xml version="1.0"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="0" state="full"> <registration aor="sip:8475551001@kamailio-ip" id="0x7f62677013a0" state="active"> <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"> <uri>sip:8475551001@10.51.2.181:63311;transport=udp</uri> </contact> </registration> </reginfo> SIP/2.0 200 OK Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK6596.773f3d36.0 To: sip:8475551001@kamailio-ip;tag=a6a1c5f60faecf035a1ae5b6e96e979a-a070 From: sip:8475551001@kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-404e CSeq: 10 PUBLISH Call-ID: 3a1e3ea20824a642-1670@127.0.0.1 Expires: 3600 SIP-ETag: a.1351264309.1668.1.0 Server: kamailio (3.3.2 (x86_64/linux)) Content-Length: 0 SUBSCRIBE sip:8475551001@kamailio-ip SIP/2.0 Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK761d.6ebf4355.0 To: sip:8475551001@kamailio-ip From: sip:8475551001@kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-bfdd CSeq: 10 SUBSCRIBE Call-ID: 3a1e3ea20824a642-1668@127.0.0.1 Content-Length: 0 User-Agent: kamailio (3.3.2 (x86_64/linux)) Max-Forwards: 70 Event: presence Contact: <sip:kamailio-ip:5060> 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: sip:8475551001@kamailio-ip;tag=a6a1c5f60faecf035a1ae5b6e96e979a-8fd4 From: sip:8475551001@kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-bfdd CSeq: 10 SUBSCRIBE Call-ID: 3a1e3ea20824a642-1668@127.0.0.1 Expires: 7200 Contact: <sip:kamailio-ip:5060> Require: eventlist Server: kamailio (3.3.2 (x86_64/linux)) Content-Length: 0 SUBSCRIBE sip:8475551001@kamailio-ip SIP/2.0 Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK25f.0e3d3f64.0 To: sip:8475551001@kamailio-ip From: sip:8475551001@kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-62f4 CSeq: 10 SUBSCRIBE Call-ID: 3a1e3ea20824a642-1672@127.0.0.1 Content-Length: 0 User-Agent: kamailio (3.3.2 (x86_64/linux)) Max-Forwards: 70 Event: presence Contact: <sip:kamailio-ip:5060> 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: sip:8475551001@kamailio-ip;tag=a6a1c5f60faecf035a1ae5b6e96e979a-ceeb From: sip:8475551001@kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-62f4 CSeq: 10 SUBSCRIBE Call-ID: 3a1e3ea20824a642-1672@127.0.0.1 Expires: 7200 Contact: <sip:kamailio-ip:5060> 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: <list name="rcs"> <display-name>All Contacts</display-name> <external anchor="http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22doubango%22%5D" /> <entry uri="sip:8475551001@ip" /> </list> 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 <hugh.wa...@crocodile-rcs.com> wrote: > Hi, > > I don't know what might cause exactly the issues you are seeing, but here's > what I would do to track it down. > > 1. If no xcap documents exist on the system, the client will get a 404 and > should usually PUT some new (empty) documents. > > Assuming these 'empty' documents exist, the following should happen when the > client logs in. > a. When the SUBSCRIBE to presence.winfo arrives it should create a single > entry in the 'active-watchers' table. It should show a single subscription > to presence.winfo where the watcher and presentity URI are the same user. > c. When the SUBSCRIBE to RLS arrives, it should create a single entry in > 'rls_watchers'. As there are no contacts in the resource-list doc, there are > no rls subscriptions. > > My questions to try and debug would be: > 1. Does the above happen when starting from a clean database and not having > any contacts or external links in the resource-list? > > 2. If that works, can you add contacts directly to the resource-list (like > below) and try again. Does that cause a problem? You should see entries in > 'pua' and 'active-watchers' for the added contacts. > > <?xml version="1.0" encoding="UTF-8"?> > <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> > <list name="oma_buddylist"> > <entry uri="sip:160...@example.com"> > <display-name>160000</display-name> > </entry> > <entry uri="sip:160...@example.com"> > <display-name>160001</display-name> > </entry> > </list> > </resource-lists> > > 3. Finally add the external documents and external anchors and try again. > > I haven't personally used anything that uses the external anchors feature, > but if it is only the external URIs that are causing the problem, kamailio > may think it is subscribing to the same URI each time causing a recursive > loop. This may be visible on a network trace taken on the loopback > interface. > > Regards, > Hugh > > > > On 26/10/2012 13:36, Sangeeta Shah wrote: > > Did anyone get a chance to look at this post. I upgraded to Kamailio > 3.3.2 since the changelog indicated several RLS fixes. But as soon as > I bring my client up I see 4000 entries in my PUA table and about 500+ > entries in the rls_watchers table for the same presentity. > > What would trigger behavior like this? Either I have an error or am > missing something in the config file or it's my XML. Any thoughts. I > have included my config params in this email chain and my > rls-services, pres-rules and resource-lists documents are from the OMA > specs with external anchors etc. > > Thanks, > Sangeeta > > On Mon, Oct 22, 2012 at 3:32 PM, Sangeeta Shah <sangeeta.s...@gmail.com> > wrote: > > Hello All, > I am hoping the authors of the RLS/PUA modules can answer this > question since I am not sure what's going on. I have the rls module > enabled, with the following config spec: > > # ------rls module params ------ > modparam("rls", "db_url", DBURL) > modparam("rls", "db_mode", 2) > modparam("rls", "integrated_xcap_server", 1) > modparam("rls", "to_presence_code" ,10) > modparam("rls", "server_address", "sip:rls@ip:5060") > > > #!endif > > and > modparam("pua_reginfo", "default_domain", "ip") > modparam("pua_reginfo", "server_address", "sip:reginfo@ip") > modparam("pua", "db_mode", 2) > > So for both I have DB_MODE set to DB ONLY. For whatever reason, even > though all I am doing is bringing up my client I see over 250+ entries > in the rls_watchers table for the same watcher and over 100 entries in > the pua list table for the same presentity? > > Anyone have any idea what would be triggering this. There is > definitely not anymore more than the normal messaging going on between > the client and the server. > > Only error I see in the syslog: > Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11745]: ERROR: > db_mysql [km_dbase.c:122]: driver error on query: Duplicate entry > '1350937406' for key 'expires_idx' > Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11744]: DEBUG: > presence [subscribe.c:1216]: subs->contact= sip:rls@ip:5060 - len = 25 > Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11761]: DEBUG: > <core> [db_val.c:117]: converting STRING [8475551001] > Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11746]: DEBUG: > <core> [parser/msg_parser.c:626]: method: <SUBSCRIBE> > Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11745]: ERROR: > <core> [db_query.c:210]: error while submitting query > Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11744]: DEBUG: > rls [rls.h:241]: did= > 41826031568472f9-11752@127.0.0.1;533cb9e91f4b999cf76861cbb9ed54ed-93a3;a6a1c5f60faecf035a1ae5b6e96e979a-464d > Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11761]: DEBUG: > <core> [db_val.c:117]: converting STRING [10.50.251.12] > Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11746]: DEBUG: > <core> [parser/msg_parser.c:628]: uri: <sip:8475551001@ip> > Oct 22 15:22:22 RCS-Presence /usr/local/sbin/kamailio[11745]: ERROR: > pua [pua_db.c:1149]: DB insert failed > > > > -- > Sangeeta Shah > > > > > -- > Hugh Waite > Principal Design Engineer > Crocodile RCS Ltd. > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > -- Sangeeta Shah _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users