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