<!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/4/11 3:39 PM, Peter Dunkley wrote:
    <blockquote cite="mid:1301924376.3084.39.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">
      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: &lt;<a moz-do-not-send="true"
          href="sip:rls@46.38.172.248:5060">sip:rls@46.38.172.248:5060</a>&gt;<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: &lt;<a moz-do-not-send="true" href="sip:127.0.0.1:5060">sip:127.0.0.1:5060</a>;transport=udp&gt;<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 cite="mid:1301924376.3084.39.camel@pd-laptop-linux"
      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>
    -- <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>