<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Peter,<br>
<br>
On 4/7/11 11:42 AM, Peter Dunkley wrote:
<blockquote cite="mid:1302169333.3048.4.camel@pd-laptop-linux"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="GENERATOR" content="GtkHTML/3.32.2">
Hi Daniel,<br>
<br>
This SUBSCRIBE is a back-end SUBSCRIBE generated by RLS and
directed to PRESENCE.<br>
<br>
The RLS module sends that SUBSCRIBE and gets a 202 back from
PRESENCE. The PRESENCE module is then sending that NOTIFY back to
the RLS module after the unSUBSCRIBE is complete.<br>
</blockquote>
ok, now I have the proper message flow.<br>
<br>
<blockquote cite="mid:1302169333.3048.4.camel@pd-laptop-linux"
type="cite">
So:<br>
- Either the PRESENCE module should not send this NOTIFY to the
RLS after the unSUBSCRIBE, or<br>
- The RLS module should be prepared to receive a NOTIFY from
PRESENCE after the unSUBSCRIBE<br>
</blockquote>
<br>
Perhaps the best will be to have delayed delete of un-SUBSCRIBEd
dialogs. The quick solution is to reply 200ok for NOTIFY requests
with state terminated. I will make a patch for the later.<br>
<br>
Thanks,<br>
Daniel<br>
<br>
<blockquote cite="mid:1302169333.3048.4.camel@pd-laptop-linux"
type="cite">
<br>
Thanks,<br>
<br>
Peter<br>
<br>
On Thu, 2011-04-07 at 11:34 +0200, Daniel-Constantin Mierla wrote:<br>
<blockquote type="CITE"> Hi Peter,<br>
<br>
On 4/4/11 3:39 PM, Peter Dunkley wrote: <br>
<blockquote type="CITE"> Hello Daniel,<br>
<br>
I have looked into the new error message. I now get:<br>
<br>
7(21352) ERROR: rls [resource_notify.c:250]: record not
found<br>
<br>
This looks very similar to the previous issue. What appears
to be happening is that the RLS is successfully un-subscribing
from the presence module with a SUBSCRIBE that looks like:<br>
<br>
<blockquote> SUBSCRIBE <a moz-do-not-send="true"
href="sip:alice@crocodile-rcs.com">sip:alice@crocodile-rcs.com</a>
SIP/2.0<br>
Via: SIP/2.0/UDP
46.38.172.248;branch=z9hG4bKf89b.b9ec2180000000000000000000000000.0<br>
To: <a moz-do-not-send="true"
href="sip:alice@crocodile-rcs.com.">sip:alice@crocodile-rcs.com</a><br>
From: <a moz-do-not-send="true"
href="sip:bob@crocodile-rcs.com">sip:bob@crocodile-rcs.com</a>;tag=533cb9e91f4b999cf76861cbb9ed54ed-8c1c<br>
CSeq: 10 SUBSCRIBE<br>
Call-ID: <a moz-do-not-send="true"
href="mailto:6c60e3f8-21440@127.0.0.1.">6c60e3f8-21440@127.0.0.1</a><br>
Content-Length: 0<br>
User-Agent: Crocodile SuperNode 1.1<br>
Max-Forwards: 70<br>
Event: presence<br>
Contact: <<a moz-do-not-send="true"
href="sip:rls@46.38.172.248:5060">sip:rls@46.38.172.248:5060</a>><br>
Expires: 0<br>
Supported: eventlist<br>
Accept: application/pidf+xml, application/rlmi+xml,
application/watcherinfo+xml, multipart/related<br>
</blockquote>
<br>
After accepting (with 202) this SUBSCRIBE the presence module
tries to send a NOTIFY back to the RLS module:<br>
<br>
<blockquote> NOTIFY <a moz-do-not-send="true"
href="sip:rls@46.38.172.248:5060">sip:rls@46.38.172.248:5060</a>
SIP/2.0<br>
Via: SIP/2.0/UDP
127.0.0.1;branch=z9hG4bK7a28.7240a060000000000000000000000000.0<br>
To: <a moz-do-not-send="true"
href="sip:bob@crocodile-rcs.com">sip:bob@crocodile-rcs.com</a>;tag=533cb9e91f4b999cf76861cbb9ed54ed-8c1c<br>
From: <a moz-do-not-send="true"
href="sip:alice@crocodile-rcs.com">sip:alice@crocodile-rcs.com</a>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-5cd7<br>
CSeq: 1 NOTIFY<br>
Call-ID: <a moz-do-not-send="true"
href="mailto:6c60e3f8-21440@127.0.0.1.">6c60e3f8-21440@127.0.0.1</a><br>
Content-Length: 0<br>
User-Agent: Crocodile SuperNode 1.1<br>
Max-Forwards: 70<br>
Event: presence<br>
Contact: <<a moz-do-not-send="true"
href="sip:127.0.0.1:5060">sip:127.0.0.1:5060</a>;transport=udp><br>
Subscription-State: terminated;reason=timeout<br>
</blockquote>
This NOTIFY is passed into the RLS module using
rls_handle_notify() and the error message from above appears
in the log file. There is no final response sent to the
NOTIFY so the error message appears repeatedly for 32 seconds
until the presence module times out.<br>
<br>
I think there are two issues here:
<ul>
<li>After completing the unSUBSCRIBE the RLS module removes
the dialog from the hash table. This means that the
NOTIFY from presence doesn't match a dialog - hence the
error message. </li>
</ul>
</blockquote>
is this SBSCRIBE request handled by RLS module, not by presence
(ie, it is for a resource list or for an user)?<br>
<br>
<blockquote type="CITE">
<ul>
<li>rls_handle_notify() does not send an Fxx (or at least
does not in this case) when it receives a validly formed
NOTIFY that still causes an error. </li>
</ul>
<br>
Can you suggest a work-around?<br>
</blockquote>
rls_handle_notify() sends 200ok only when returning true to
config. In this case, since it hasn't found the proper dialog,
will return false.<br>
<br>
Try:<br>
<br>
if(!rls_handle_notify()) {<br>
send_reply("404", "Not found");<br>
exit;<br>
}<br>
<br>
Perhaps will be nicer to differentiate between the cases of
internal error, whether it is some server fault (e.g., out of
memory, broken db connection) or the dialog is not found, to be
able to send back either 500 or 404.<br>
<br>
Cheers,<br>
Daniel<br>
--
<pre>Daniel-Constantin Mierla
<a moz-do-not-send="true" href="http://www.asipto.com">http://www.asipto.com</a>
</pre>
</blockquote>
<br>
<table cellpadding="0" cellspacing="0" width="100%">
<tbody>
<tr>
<td>
<pre>--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</pre>
</td>
</tr>
</tbody>
</table>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a></pre>
</body>
</html>