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(a)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(a)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(a)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(a)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(a)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(a)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.waite(a)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@example.com">
<display-name>160000</display-name>
</entry>
<entry uri="sip:160001@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(a)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(a)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(a)lists.sip-router.org