8 Oct
2012
8 Oct
'12
3:32 p.m.
I have Kamailio 3.3 with Presence, RLS and integrated XCAP.
I see this information message in the log file:
Oct 8 14:34:05 RCS-Presence /usr/local/sbin/kamailio[4530]: INFO: rls
[rls_db.c:779]: update_subs_rlsdb: NO MATCH
Anyone know why the application is calling that method if it doesn't
exist in rls_db.c.
I still haven't been able to get presence with rls and integrated xcap
working so not sure if this is an issue or no. Currently for both
presence and RLS i am using "DB-Only" mode.
Any help is appreciated. It seems like when client A adds client B as
a contact, the kamalio server is not sending out an auth request to
client B. Even though it's registered for presence.winfo events.
Thanks,
Sangeeta
--
Sangeeta Shah
8 Oct
8 Oct
6:21 p.m.
Hello,
you should set debug=3 in your config file and watch the logs messages
to get more details about what happens there.
I don't have any sip application that supports rls, so I'm not able to
test, but classic SIMPLE presence should work fine.
Regards,
Daniel
On 10/8/12 9:32 PM, Sangeeta Shah wrote:
I have Kamailio 3.3 with Presence, RLS and integrated
XCAP.
I see this information message in the log file:
Oct 8 14:34:05 RCS-Presence /usr/local/sbin/kamailio[4530]: INFO: rls
[rls_db.c:779]: update_subs_rlsdb: NO MATCH
Anyone know why the application is calling that method if it doesn't
exist in rls_db.c.
I still haven't been able to get presence with rls and integrated xcap
working so not sure if this is an issue or no. Currently for both
presence and RLS i am using "DB-Only" mode.
Any help is appreciated. It seems like when client A adds client B as
a contact, the kamalio server is not sending out an auth request to
client B. Even though it's registered for presence.winfo events.
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
9 Oct
9 Oct
11:44 a.m.
Daniel,
I had debug=4 yesterday and I had to delete my logfiles this
morning because the log partition was full. IT seems like when I have
DB ONLY mode turned on for both presence and RLS there is a lot of
logging causing the disk to fill up.
I have my debug level set to 3 and have also disabled the DB ONLY
mode. If I notice the issue today I'll capture the necessary
information and send it out.
One thing I do have to understand. Based on my understanding of the
RFCs - if the clients subscribe to the presence.winfo event...when
client A adds B to its contact list, the server is support to trigger
a notification to B to request the authorization. I NEVER see that
going out to client B. Is the server capable of doing this, especially
with xcap and rls?
I have the following handling for subscribe in the config file:
else if( is_method("SUBSCRIBE"))
{
xdbg("======== Handling subscribe request ==== \n");
#!ifdef WITH_RLS
$var(ret_code) = rls_handle_subscribe();
xdbg("========= RLS Handle subscriber returned with
ret code: $var(ret_code) ===\n");
if ($var(ret_code) == 10)
#!endif
xdbg("======== Calling Handle subscribe ===== \n");
handle_subscribe();
t_release();
}
Does rls_handle_subscribe create the virtual subscription and then
since B is registered for presence.winfo, trigger a notification to B
for the authorization. Am I missing any necessary logic here? Does the
presence/rls server adhere to RFC 3857? The server has B's presence
information in the presence table, but I think since there is
presence.winfo events and RLS involved some call leg is not getting
triggered to complete the flow.
Any help is appreciated. I am working on getting the trace and any
other information that would be necessary to further debug this issue.
Thanks,
Sangeeta
On Mon, Oct 8, 2012 at 5:21 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
Hello,
you should set debug=3 in your config file and watch the logs messages to
get more details about what happens there.
I don't have any sip application that supports rls, so I'm not able to test,
but classic SIMPLE presence should work fine.
Regards,
Daniel
On 10/8/12 9:32 PM, Sangeeta Shah wrote:
--
Sangeeta Shah
I have Kamailio 3.3 with Presence, RLS and integrated XCAP.
I see this information message in the log file:
Oct 8 14:34:05 RCS-Presence /usr/local/sbin/kamailio[4530]: INFO: rls
[rls_db.c:779]: update_subs_rlsdb: NO MATCH
Anyone know why the application is calling that method if it doesn't
exist in rls_db.c.
I still haven't been able to get presence with rls and integrated xcap
working so not sure if this is an issue or no. Currently for both
presence and RLS i am using "DB-Only" mode.
Any help is appreciated. It seems like when client A adds client B as
a contact, the kamalio server is not sending out an auth request to
client B. Even though it's registered for presence.winfo events.
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
12:25 p.m.
One thing I forgot to include is the handling of the put:
case "PUT":
xdbg("===== xhttp: put received $var(uri)\n");
xcaps_put("$var(uri)", "$hu",
"$rb");
if($xcapuri(u=>auid)=~"pres-rules") {
xdbg("====xhttp: putting
presence rules\n");
pres_update_watchers("$var(uri)", "presence");
pres_refresh_watchers("$var(uri)", "presence", 1);
} else if
($xcapuri(u=>auid)=~"resource-lists"
||
$xcapuri(u=>auid)=~"rls-services") {
xdbg("==== xhttp: putting
resource lists or rls services\n");
xlog("=======xhttp: calling
rls_update_subs with: $var(uri)\n");
rls_update_subs("$var(uri)",
"presence");
}
exit;
break;
So I have verified that when I add a contact it calls rls_update_subs.
But it doesn't seem that this logic is triggering a notify to the
client that I am subscribing to.
Thanks,
Sangeeta
On Tue, Oct 9, 2012 at 10:44 AM, Sangeeta Shah <sangeeta.shah(a)gmail.com> wrote:
Daniel,
I had debug=4 yesterday and I had to delete my logfiles this
morning because the log partition was full. IT seems like when I have
DB ONLY mode turned on for both presence and RLS there is a lot of
logging causing the disk to fill up.
I have my debug level set to 3 and have also disabled the DB ONLY
mode. If I notice the issue today I'll capture the necessary
information and send it out.
One thing I do have to understand. Based on my understanding of the
RFCs - if the clients subscribe to the presence.winfo event...when
client A adds B to its contact list, the server is support to trigger
a notification to B to request the authorization. I NEVER see that
going out to client B. Is the server capable of doing this, especially
with xcap and rls?
I have the following handling for subscribe in the config file:
else if( is_method("SUBSCRIBE"))
{
xdbg("======== Handling subscribe request ==== \n");
#!ifdef WITH_RLS
$var(ret_code) = rls_handle_subscribe();
xdbg("========= RLS Handle subscriber returned with
ret code: $var(ret_code) ===\n");
if ($var(ret_code) == 10)
#!endif
xdbg("======== Calling Handle subscribe ===== \n");
handle_subscribe();
t_release();
}
Does rls_handle_subscribe create the virtual subscription and then
since B is registered for presence.winfo, trigger a notification to B
for the authorization. Am I missing any necessary logic here? Does the
presence/rls server adhere to RFC 3857? The server has B's presence
information in the presence table, but I think since there is
presence.winfo events and RLS involved some call leg is not getting
triggered to complete the flow.
Any help is appreciated. I am working on getting the trace and any
other information that would be necessary to further debug this issue.
Thanks,
Sangeeta
On Mon, Oct 8, 2012 at 5:21 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
--
Sangeeta Shah
Hello,
you should set debug=3 in your config file and watch the logs messages to
get more details about what happens there.
I don't have any sip application that supports rls, so I'm not able to test,
but classic SIMPLE presence should work fine.
Regards,
Daniel
On 10/8/12 9:32 PM, Sangeeta Shah wrote:
--
Sangeeta Shah
I have Kamailio 3.3 with Presence, RLS and integrated XCAP.
I see this information message in the log file:
Oct 8 14:34:05 RCS-Presence /usr/local/sbin/kamailio[4530]: INFO: rls
[rls_db.c:779]: update_subs_rlsdb: NO MATCH
Anyone know why the application is calling that method if it doesn't
exist in rls_db.c.
I still haven't been able to get presence with rls and integrated xcap
working so not sure if this is an issue or no. Currently for both
presence and RLS i am using "DB-Only" mode.
Any help is appreciated. It seems like when client A adds client B as
a contact, the kamalio server is not sending out an auth request to
client B. Even though it's registered for presence.winfo events.
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
6:04 p.m.
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@10.50.251.12 and the service
uri in the rls-services list is:
sip:8475551001@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@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@watcher_domain: 8475551001@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@to_domain: 8475551004@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@from_domain: 8475551001@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(a)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@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@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@watcher_domain: 8475551001@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
12 Oct
12 Oct
4:36 a.m.
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@10.50.251.12 and the service
uri in the rls-services list is:
sip:8475551001@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@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@watcher_domain: 8475551001@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@to_domain: 8475551004@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@from_domain: 8475551001@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(a)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@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@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@watcher_domain: 8475551001@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
4:40 p.m.
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@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(a)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:
--
Sangeeta Shah
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@10.50.251.12 and the service
uri in the rls-services list is:
sip:8475551001@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@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@watcher_domain: 8475551001@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@to_domain: 8475551004@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@from_domain: 8475551001@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(a)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@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@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@watcher_domain: 8475551001@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
4460
days inactive
4464
days old
6 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Sangeeta Shah