[SR-Users] Entries in PUA List and RLS Watchers List
Sangeeta Shah
sangeeta.shah at gmail.com
Fri Oct 26 20:37:25 CEST 2012
Peter,
Appreciate your detailed response. The client we are using is compliant
with the GSM RCS spec and the xml (including the use of external anchors)
comes straight from the specs. Are you aware of any RLS capable clients
that doesn't use external anchors but comply with the RCS specifications
for presence? We've used Jitsi - but that doesn't seem to support rls.
Your description below got me thinking on how the back end subscribes would
get routed. Since the code would find the clients own entry in the
resource-list (see below) it initiates a back-end subscribe to it - and
when it was coming to my routing logic in the config file since it was a
subscribe with a supported "eventlist" header - it was calling
rls_handle_subscribe again causing the looping issue. So the way I resolved
that was by adding the following code in my routing logic:
<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
<http://10.50.251.13:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/%7E%7E/resource-lists/list%5B@name=%22doubango%22%5D>"
/>
<entry uri="sip:8475551001 at ip" />
</list>
if( is_method("SUBSCRIBE"))
{
#xdbg("======== Handling subscribe request ==== \n");
if ($hdr("User-Agent") =~"IM-client")
{
$var(ret_code) = rls_handle_subscribe();
#xdbg("========= RLS Handle subscriber returned with ret
code: $var(ret_code) ===\n");
if ($var(ret_code) == 10)
{
xdbg("======== Calling Handle subscribe ===== \n");
handle_subscribe();
}
}
else
{
handle_subscribe();
}
t_release();
}
This seems to resolve the looping issue. However, now I don't see an entry
for the dialog in the rls_watchers table. I see the following entries in
the respective tables:
- One presentity in the presentity table - *Yes*
- One presence.winfo dialog in the active_watchers table- *Yes* *+ 1
presence entry *
- One presence dialog in the rls_watchers table- *No entries after the
change*
- One presence dialog for each <entry /> in the resource-list in the pua
table- *Yes* (just itself for now)
- One presence dialog for each <entry /> in the resource-list in the
active_watchers table- *Yes (just itself for now)*
- 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- *Yes (just itself for now)*
I am pretty sure if I add a contact this is not going to work because of
the external anchors. But not sure why an entry is not getting added to the
rls_watchers table after my change. I would think it should get added for
the initial subscribe from the client.
Again appreciate you taking the time to respond. Is there any plan to add
support for external anchors in the new future?
Thanks,
Sangeeta
On Fri, Oct 26, 2012 at 12:07 PM, Peter Dunkley <
peter.dunkley at crocodile-rcs.com> wrote:
> **
> Hi,
>
> External anchors are not currently supported by the Kamailio RLS module.
> 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.
>
> For each <entry /> in your resource list the RLS module will create a
> back-end subscription (using the PUA module) to a Presence Server. 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).
>
> After logging in with an RLS capable client you should end up with the
> following:
>
> - One presentity in the presentity table
> - One presence.winfo dialog in the active_watchers table
> - One presence dialog in the rls_watchers table
> - One presence dialog for each <entry /> in the resource-list in the
> pua table
> - One presence dialog for each <entry /> in the resource-list in the
> active_watchers table
> - 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
>
> The rls_presentity table will be empty until you have multiple clients
> signed in concurrently and are sharing presence between them.
>
> Regards,
>
> Peter
>
>
> On Fri, 2012-10-26 at 10:44 -0500, Sangeeta Shah wrote:
>
> 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
> >
>
>
>
>
>
> --
> Peter Dunkley
> Technical Director
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121026/61be1898/attachment-0001.htm>
More information about the sr-users
mailing list