Thanks for the response. I did drop the uniqueness on the expires_idx INDEX for the pua table.

Now I see this error in the syslog: Oct 23 10:33:42 RCS-Presence /usr/local/sbin/kamailio[26439]: ERROR: db_mysql [km_dbase.c:122]: driver error on query: Duplicate entry '2ee709f03a582d75-26439@127.0.0.1-533cb9e91f4b999cf76861cbb9ed54e' for key 'pua_idx'

Also, as I reported earlier as soon as my client connects to the server there are tons of entries for the same pres_uri in the pua and rls_watchers table.

For instance: | 2386 | sip:8475551001@10.50.251.12 | 8475551001 | 10.50.251.12 | 8475551001 | 10.50.251.12 | presence | | a6a1c5f60faecf035a1ae5b6e96e979a-fc8a | 533cb9e91f4b999cf76861cbb9ed54ed-ccda | 2ee709f03a582f8a-26438@127.0.0.1 | 0 | 10 | sip:10.50.251.12:5060 | | 1351013694 | 0 | | 1 | udp:10.50.251.12:5060 | sip:10.50.251.12:5060 | 8475551001 | 10.50.251.12 | -1 |

| 2387 | sip:8475551001@10.50.251.12 | 8475551001 | 10.50.251.12 | 8475551001 | 10.50.251.12 | presence | | a6a1c5f60faecf035a1ae5b6e96e979a-9fd1 | 533cb9e91f4b999cf76861cbb9ed54ed-0f88 | 2ee709f03a582f77-26441@127.0.0.1 | 0 | 10 | sip:10.50.251.12:5060 | | 1351013694 | 0 | | 1 | udp:10.50.251.12:5060 | sip:10.50.251.12:5060 | 8475551001 | 10.50.251.12 | 16 |

| 2388 | sip:8475551001@10.50.251.12 | 8475551001 | 10.50.251.12 | 8475551001 | 10.50.251.12 | presence | | a6a1c5f60faecf035a1ae5b6e96e979a-12d0 | 533cb9e91f4b999cf76861cbb9ed54ed-c4da | 2ee709f03a582f70-26440@127.0.0.1 | 0 | 10 | sip:10.50.251.12:5060 | | 1351013694 | 0 | | 1 | udp:10.50.251.12:5060 | sip:10.50.251.12:5060 | 8475551001 | 10.50.251.12 | 0 |

This is what I have in my config file:

# ------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@<kamailioip>:5060")

#!endif

and modparam("pua_reginfo", "default_domain", "ip") modparam("pua_reginfo", "server_address", "sip:reginfo@<kamailioip>") modparam("pua", "db_mode", 2)

Is this correct? Am I missing something. Why are so many entries getting created in these two tables for the same presentity? I don't see any other errors in the syslog. I have Kamailio v 3.3.1

Thanks, Sangeeta

On Tue, Oct 23, 2012 at 12:44 AM, Juha Heinanen jh@tutpro.com wrote:

Sangeeta Shah writes:

...

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'

if this comes from pua table, check that the index has been defined like this:

CREATE INDEX expires_idx ON pua (expires)

i.e., the index should not be unique. if i remember correctly, the index was unique at some point, which it should not have been.

-- juha

---

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

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.waite@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@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

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@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@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@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.waite@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@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

-- Peter Dunkley Technical Director 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

26 okt 2012 kl. 19:07 skrev Peter Dunkley peter.dunkley@crocodile-rcs.com:

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.

Peter, 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...

Thanks, /O

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@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.waite@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@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

-- Peter Dunkley Technical Director 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

Peter/Hugh, After a bit more debugging and playing around with the server, I have a few more follow up questions:

1. Purpose of rls_handle_notify: I understand the purpose of rls_handle_subscribe and rls_update_subs. What's the purpose of rls_handle_notify? If I have kamailio configured as a presence server+rls server with integrated xcap do I need to add code in the config file to handle notifies? I had this code and noticed that it was being called, Wasn't sure if it is necessary to trigger notifies when the resource list is updated?

2. When I add a contact (8475551004), I see rls_update_subs being called and a back end subscription being inserted into the watchers table as follows:

| 21 | sip:8475551004@domain | 8475551001 | domain | presence | 2 | | 1351545844 |

Does an insertion into this table trigger a notify to the presentity to request authorization? I see that only when I restart the client for 8475551004.

When 8475551001 is authorized by 8475551004, I see rls_update_subs being called for 8475551004 since it updates its resource list, but the status of the entry in the watchers table never changes from 2 (pending) to active? What should trigger that?

Any help is appreciated.

Thanks, Sangeeta

On Fri, Oct 26, 2012 at 6:03 PM, Peter Dunkley peter.dunkley@crocodile-rcs.com wrote:

...

Peter, 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...

It's all a matter of perspective. If you are writing the documentation and there is lots to do it can certainly seem like TOO MUCH :-)

I'll add it to my list though, probably do something next time I am in there.

Peter

-- Peter Dunkley Technical Director 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

Hello All, Did anyone get a chance to look at my question below?

Can anyone explain what will happen when the next hop is the rls server address? How will this notify get handled.

Thanks, Sangeeta

On Tue, Oct 30, 2012 at 5:01 PM, Sangeeta Shah sangeeta.shah@gmail.com wrote:

I have another follow up question on RLS behavior/implementation based on some additional debugging today:

Client A (8475551001) starts up and registers with the presence server

1. It sends a subscribe with event=presence.winfo
2. Puts the following xml documents: pres-rules, rls-services, resource-list Resource list has an entry for the client itself: 8475551001
   • rls_update_subs is called and triggers a backend subscription for

8475551001 3. Sends a subscribe with event=presence, supported=eventlist

• rls_handle_subscribe is called for the subscribe above
• entry is inserted in the pua and rls_watchers table for the above subscribe
• notify is being sent from the rls module with the full state resource list: xmlns=urn:ietf:params:xml:ns:rlmi

4. Sends a publish
   • handle publish request is called and an entry is inserted into

the presentity table for 8475551001

I see a notify being generated from the "presence" module (notify.c) - which I think is triggered from the back end subscription above. The next hop for this message is the rls server address. What does that imply? Where is this notify going to end up? Earlier I thought rls_handle_notify was being called...but I verified that it's not.

I see the following info in the syslog: Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG: presence_xml [notify_body.c:65]: Missy: In preg_add_nobdy

Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG: presence_xml [notify_body.c:81]: [user]=8475551001 [domain]=

<server-ip>

Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG: presence_xml [notify_body.c:463]: Missy: In aggregate_xmls: 1 8475551001@<server-ip> <server-ip>

Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG: presence [notify.c:827]: Missy: Notify body: ....

Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG: presence [notify.c:1539]: headers:#012Max-Forwards: 70#015#012 Event: presence#015#012Contact: <sip:<server-ip>:5060;transport=udp>#015#012Subscription-State: active;expires=3599#015#012Content- Type: application/pidf+xml#015#012

Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG: presence [notify.c:927]: CONTACT = sip:rls@<server-ip>:5060

ct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG: tm [uac.c:243]: DEBUG:tm:t_uac: next_hop=<sip:rls@<server-ip>:5060>

Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: DEBUG: tm [uac.c:182]: DEBUG: dlg2hash: 3999

Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13364]: DEBUG: <core> [parser/msg_parser.c:624]: SIP Request: Oct 30 16:44:00 RCS-Presence2 /usr/local/sbin/kamailio[13382]: INFO: presence [notify.c:1576]: NOTIFY sip:8475551001@<server-ip> via sip:rls@<server-ip>:5060 on behalf of sip:8475551001@<server-ip> for event presence

Can anyone please shed any light on where the notify from the presence module will end up. Maybe it's somehow supposed to make it back to the rls module which would enter the info in the rls_presentity table and then trigger the full notify to the client. But that is not happening.

What is the expected behavior based on what's been described above.

Again thanks for taking the time to read/respond to the email.

Sangeeta

On Mon, Oct 29, 2012 at 6:35 PM, Sangeeta Shah sangeeta.shah@gmail.com wrote:

...

Peter/Hugh, After a bit more debugging and playing around with the server, I have a few more follow up questions:

1. Purpose of rls_handle_notify: I understand the purpose of

rls_handle_subscribe and rls_update_subs. What's the purpose of rls_handle_notify? If I have kamailio configured as a presence server+rls server with integrated xcap do I need to add code in the config file to handle notifies? I had this code and noticed that it was being called, Wasn't sure if it is necessary to trigger notifies when the resource list is updated?

2. When I add a contact (8475551004), I see rls_update_subs being

called and a back end subscription being inserted into the watchers table as follows:

| 21 | sip:8475551004@domain | 8475551001 | domain | presence | 2 | | 1351545844 |

Does an insertion into this table trigger a notify to the presentity to request authorization? I see that only when I restart the client for 8475551004.

When 8475551001 is authorized by 8475551004, I see rls_update_subs being called for 8475551004 since it updates its resource list, but the status of the entry in the watchers table never changes from 2 (pending) to active? What should trigger that?

Any help is appreciated.

Thanks, Sangeeta

On Fri, Oct 26, 2012 at 6:03 PM, Peter Dunkley peter.dunkley@crocodile-rcs.com wrote:

...

...

Peter, 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...

It's all a matter of perspective. If you are writing the documentation and there is lots to do it can certainly seem like TOO MUCH :-)

I'll add it to my list though, probably do something next time I am in there.

Peter

-- Peter Dunkley Technical Director 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

-- Sangeeta Shah

Sangeeta Shah writes:

When client A authorizes client B to see it's presence information - it adds an entry for client B in its resource list and updates it's resource list on the server.

authorizing someone to see my presence status has nothing to do with my resource lists, which i may not even have any.

-- juha