[SR-Users] Entries in PUA List and RLS Watchers List
Sangeeta Shah
sangeeta.shah at gmail.com
Fri Oct 26 17:44:30 CEST 2012
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 at 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 at ip SIP/2.0
Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK6596.773f3d36.0
To: sip:8475551001 at kamailio-ip
From: sip:8475551001 at kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-404e
CSeq: 10 PUBLISH
Call-ID: 3a1e3ea20824a642-1670 at 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 at 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 at 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 at kamailio-ip;tag=a6a1c5f60faecf035a1ae5b6e96e979a-a070
From: sip:8475551001 at kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-404e
CSeq: 10 PUBLISH
Call-ID: 3a1e3ea20824a642-1670 at 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 at kamailio-ip SIP/2.0
Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK761d.6ebf4355.0
To: sip:8475551001 at kamailio-ip
From: sip:8475551001 at kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-bfdd
CSeq: 10 SUBSCRIBE
Call-ID: 3a1e3ea20824a642-1668 at 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 at kamailio-ip;tag=a6a1c5f60faecf035a1ae5b6e96e979a-8fd4
From: sip:8475551001 at kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-bfdd
CSeq: 10 SUBSCRIBE
Call-ID: 3a1e3ea20824a642-1668 at 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 at kamailio-ip SIP/2.0
Via: SIP/2.0/UDP kamailio-ip;branch=z9hG4bK25f.0e3d3f64.0
To: sip:8475551001 at kamailio-ip
From: sip:8475551001 at kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-62f4
CSeq: 10 SUBSCRIBE
Call-ID: 3a1e3ea20824a642-1672 at 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 at kamailio-ip;tag=a6a1c5f60faecf035a1ae5b6e96e979a-ceeb
From: sip:8475551001 at kamailio-ip;tag=533cb9e91f4b999cf76861cbb9ed54ed-62f4
CSeq: 10 SUBSCRIBE
Call-ID: 3a1e3ea20824a642-1672 at 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 at 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.waite at 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:160000 at example.com">
> <display-name>160000</display-name>
> </entry>
> <entry uri="sip:160001 at 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.shah at 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 at ip:5060")
>
>
> #!endif
>
> and
> modparam("pua_reginfo", "default_domain", "ip")
> modparam("pua_reginfo", "server_address", "sip:reginfo at 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 at 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 at 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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
--
Sangeeta Shah
More information about the sr-users
mailing list