[SR-Users] update_subs_rlsdb: NO MATCH
Sangeeta Shah
sangeeta.shah at gmail.com
Fri Oct 12 22:40:14 CEST 2012
Daniel,
Appreciate you taking the time to respond. Will do regarding
sending the path to my changes, once I verify that what the client is
sending is standards compliant.
After verifying the xml documents "PUT" by jitsi and boghe (which is
the other client we are testing with) against Kamailio, this is what I
noticed in the error log:
Oct 12 14:21:46 RCS-Presence /usr/local/sbin/kamailio[11001]: DEBUG:
presence_xml [xcap_auth.c:201]: node1->name= rule
Oct 12 14:21:46 RCS-Presence /usr/local/sbin/kamailio[11001]: DEBUG:
presence_xml [xcap_auth.c:209]: cond_node->name= conditions
Oct 12 14:21:46 RCS-Presence /usr/local/sbin/kamailio[11001]: DEBUG:
presence_xml [xcap_auth.c:201]: node1->name= rule
Oct 12 14:21:46 RCS-Presence /usr/local/sbin/kamailio[11001]: DEBUG:
presence_xml [xcap_auth.c:209]: cond_node->name= conditions
Oct 12 14:21:46 RCS-Presence /usr/local/sbin/kamailio[11001]: ERROR:
presence_xml [xcap_auth.c:311]: didn't find identity tag
Now when I closely look at the presence rules xml document inserted by
Boghe I noticed that some of the condition tags under the rule tags do
not have identity tags. Is kamailio not able to handle what's being
put by this client? Based on other examples I've seen I don't think
every condition needs to have an identity tag. Is my understanding
correct. This is the XML that's being inserted:
<cr:ruleset xmlns:ocp="urn:oma:xml:xdm:common-policy"
xmlns="urn:ietf:params:xml:ns:pres-rules"
xmlns:op="urn:oma:xml:prs:pres-rules"
xmlns:cr="urn:ietf:params:xml:ns:common-policy">
<cr:rule id="wp_prs_allow_own">
<cr:conditions>
<cr:identity>
<cr:one id="sip:8475551001 at ip" />
</cr:identity>
</cr:conditions>
<cr:actions>
<sub-handling>allow</sub-handling>
</cr:actions>
<cr:transformations>
<provide-services>
<all-services />
</provide-services>
<provide-persons>
<all-persons />
</provide-persons>
<provide-all-attributes />
<provide-devices>
<all-devices />
</provide-devices>
</cr:transformations>
</cr:rule>
<cr:rule id="rcs_allow_services_anonymous">
<cr:conditions>
<ocp:anonymous-request />
</cr:conditions>
<cr:actions>
<sub-handling>allow</sub-handling>
</cr:actions>
<cr:transformations>
<provide-services>
<all-services />
</provide-services>
<provide-persons>
<all-persons />
</provide-persons>
<provide-all-attributes />
<provide-devices>
<all-devices />
</provide-devices>
</cr:transformations>
</cr:rule>
<cr:rule id="wp_prs_unlisted">
<cr:conditions>
<ocp:other-identity />
</cr:conditions>
<cr:actions>
<sub-handling>confirm</sub-handling>
</cr:actions>
</cr:rule>
<cr:rule id="wp_prs_grantedcontacts">
<cr:conditions>
<ocp:external-list>
<ocp:entry anc="http://ip:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22oma_grantedcontacts%22%5D"
/>
</ocp:external-list>
</cr:conditions>
<cr:actions>
<sub-handling>allow</sub-handling>
</cr:actions>
<cr:transformations>
<provide-services>
<all-services />
</provide-services>
<provide-persons>
<all-persons />
</provide-persons>
<provide-all-attributes />
<provide-devices>
<all-devices />
</provide-devices>
</cr:transformations>
</cr:rule>
<cr:rule id="wp_prs_blockedcontacts">
<cr:conditions>
<ocp:external-list>
<ocp:entry anc="http://ip:5060/xcap-root/resource-lists/users/sip:8475551001@ip/index/~~/resource-lists/list%5B@name=%22oma_blockedcontacts%22%5D"
/>
</ocp:external-list>
</cr:conditions>
<cr:actions>
<sub-handling>block</sub-handling>
</cr:actions>
</cr:rule>
</cr:ruleset>
Thanks,
Sangeeta
On Fri, Oct 12, 2012 at 3:36 AM, Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
> Hello,
>
> can you send the patch of your changes? If you got the sources from git,
> then do:
>
> git diff >/path/to/a/file
>
> and send that file to the mailing list. If downloaded from tarball, then use
> 'diff -u oldfile newfile' to generate the patch.
>
> Once we get it, will be reviewed and committed to fix the reported issues.
>
> The new error you get is due to a broken XML document in the body. Can you
> capture the SIP traces (via ngrep) for the requests that generate such error
> message?
>
> Cheers,
> Daniel
>
>
> On 10/10/12 12:04 AM, Sangeeta Shah wrote:
>>
>> So I fixed a few things today
>> 1. In subscribe.c:rls_get_by_service_uri The code was doing a strlen
>> check as follows:
>> if((uri->len==strlen(val)) && (strncmp(val, uri->s, uri->len)==0))
>> The uri coming in is: sip:8475551001 at 10.50.251.12 and the service
>> uri in the rls-services list is:
>> sip:8475551001 at 10.50.251.12;pres-list=rcs
>> Hence, the above check was failing. So removing the length
>> comparison made it go further
>> 2. In notify.c:rls_get_resource_list the code is looking for %5b and
>> %5d in a case-insensitive fashion. The client xml has %5B and %5D, so
>> making the check case insensitive helped.
>>
>> But now I am seeing the following errors:
>>
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32412]: DEBUG:
>> presence [notify.c:129]: reason:
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32414]: DEBUG:
>> presence [notify.c:117]: pres_uri: sip:8475551004 at myip
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32412]: DEBUG:
>> presence [notify.c:130]: version: 3
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32414]: DEBUG:
>> presence [notify.c:118]: watcher_user at watcher_domain: 8475551001 at myip
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32412]: DEBUG:
>> presence [notify.c:131]: expires: 3510
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32414]: DEBUG:
>> presence [notify.c:119]: to_user at to_domain: 8475551004 at myip
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32412]: DEBUG:
>> presence [notify.c:133]: updated/updated_winfo: 0/0
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32414]: DEBUG:
>> presence [notify.c:120]: from_user at from_domain: 8475551001 at myip
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32412]: DEBUG:
>> presence_xml [xcap_auth.c:201]: node1->name= rule
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32414]: DEBUG:
>> presence [notify.c:121]: callid/from_tag/to_tag:
>> 79d86e7367f04a68-32412 at 127.0.0.1/533cb9e91f
>> 4b999cf76861cbb9ed54ed-a97c/a6a1c5f60faecf035a1ae5b6e96e979a-7ed7
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32412]: DEBUG:
>> presence_xml [xcap_auth.c:209]: cond_node->name= conditions
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32414]: DEBUG:
>> presence [notify.c:122]: local_cseq/remote_cseq: 1/10
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32412]: DEBUG:
>> presence_xml [xcap_auth.c:419]: apply_rule= 1
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32414]: DEBUG:
>> presence [notify.c:123]: local_contact/contact:
>> sip:myip:5060;transport=udp/sip:rls at 10.50.251.12:5060
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32412]: ERROR:
>> presence_xml [notify_body.c:176]: while parsing the xml body message
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32414]: DEBUG:
>> presence [notify.c:124]: record_route:
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32412]: ERROR:
>> presence_xml [notify_body.c:133]: in function get_final_notify_body
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32414]: DEBUG:
>> presence [notify.c:125]: sockinfo_str: udp:myip:5060
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32412]: ERROR:
>> presence [notify.c:1470]: in function apply_auth_nbody
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32414]: DEBUG:
>> presence [notify.c:127]: event: presence
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32412]: ERROR:
>> presence [notify.c:1658]: sending Notify not successful
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32414]: DEBUG:
>> presence [notify.c:128]: status: pending
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32412]: ERROR:
>> presence [notify.c:1282]: Could not send notify for presence
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32414]: DEBUG:
>> presence [notify.c:129]: reason:
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32412]: DEBUG:
>> presence [notify.c:1451]: dialog info:
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32414]: DEBUG:
>> presence [notify.c:130]: version: 1
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32412]: DEBUG:
>> presence [notify.c:117]: pres_uri: sip:8475551001 at myip
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32414]: DEBUG:
>> presence [notify.c:131]: expires: 1349821273
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32412]: DEBUG:
>> presence [notify.c:118]: watcher_user at watcher_domain: 8475551001 at myip
>> Oct 9 16:22:47 RCS-Presence /usr/local/sbin/kamailio[32414]: DEBUG:
>> presence [notify.c:133]: updated/updated_winfo: 0/0
>>
>> Not sure what the issue is now. Is this the notify that's getting send
>> out to Client B requesting auth for presence? What xml is it trying to
>> parse here:
>>
>> doc = xmlParseMemory(notify_body->s, notify_body->len);
>> if(doc== NULL)
>> {
>> LM_ERR("while parsing the xml body message\n");
>> goto error;
>> }
>>
>> Any help is appreciated. We just want to see a notification request
>> being sent out to client B requesting auth for presence. Not sure if
>> the above code is tied to that. Haven't been able to trace
>> when send_last_notify gets triggered.
>>
>> Thanks,
>> Sangeeta
>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
> Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -
> http://asipto.com/u/katu
>
--
Sangeeta Shah
More information about the sr-users
mailing list