<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Hugh,<br>
    <br>
    thanks for investigating and providing the patch. It is applied on
    master and 3.1 branches.<br>
    <br>
    Cheers,<br>
    Daniel<br>
    <br>
    On 10/5/11 5:58 PM, Hugh Waite wrote:
    <blockquote cite="mid:4E8C7E89.3030301@crocodile-rcs.com"
      type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      I have found the problem.<br>
      <br>
      When msg_apply_changes() copies the sip_msg structure, it copies
      msg_flags which includes FL_HASH_INDEX indicating that the
      hash_index is valid (which is now zero).<br>
      <br>
      I have attached a patch which updates the msg_apply_changes()
      function to copy the hash_index as it is in the original msg. This
      will be valid if the flag is set, and therefore avoid unecessary
      hash calculation.<br>
      <br>
      Hugh<br>
      <br>
      On 05/10/2011 15:25, Hugh Waite wrote:
      <blockquote cite="mid:4E8C68E2.5010008@crocodile-rcs.com"
        type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        We have discovered the cause of the problem I described, but we
        still do not understand why.<br>
        <br>
        After a SIP request arrives we make some changes to the
        P-Preferred/Asserted-Identity headers after our own validation.
        To allow these changes to be visible later (e.g. in $hdr()
        variables) we call msg_apply_changes(). It seems that calling
        this function causes the transaction matching to fail for
        subsequent messages (e.g. ACK and CANCEL).<br>
        <br>
        <b>Non-Working Example:</b><tt><br>
          append_hf("My-Header: yes\r\n");<br>
          msg_apply_changes();<br>
          if (is_present_hf("My-Header"))<br>
          {<br>
          &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; # log("Found my header") - this gets run<br>
          }<br>
          t_relay();</tt><br>
        If the destination responds with a 4XX then the ACK does not
        match and the 4XX is retransmitted.<br>
        If a CANCEL is sent, then it does not match and is not relayed.<br>
        <br>
        <b>Working Example:</b><tt><br>
          append_hf("My-Header: yes\r\n");<br>
          if (is_present_hf("My-Header"))<br>
          {<br>
          &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; # log("Found my header") - this does not get run<br>
          }<br>
          t_relay();</tt><br>
        In this example, the header is not found, but the transaction
        matching works properly<br>
        <br>
        Is this something to do with re-parsing the request? And is it a
        bug to be investigated?<br>
        <br>
        Regards,<br>
        Hugh<br>
        <br>
        On 04/10/2011 15:15, Hugh Waite wrote:
        <blockquote cite="mid:4E8B151F.2000305@crocodile-rcs.com"
          type="cite">We are seeing an issue with ACKs to failure
          responses. <br>
          <br>
          Our config is set up to forward an INVITE to another
          destination. It replies with a 407 Auth Required. Kamailio
          sends an ACK to the destination and relays the 407 back to the
          source. The source sends an ACK, but this always fails the
          transaction match, so kamailio keeps retransmitting the 407
          (when using UDP) <br>
          <br>
          UA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KAM&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UA <br>
          <br>
          &nbsp;-- INVITE --&gt;&nbsp;&nbsp; -- INVITE --&gt; <br>
          &lt;--&nbsp;&nbsp; 407&nbsp; -- <br>
          &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --&nbsp;&nbsp; ACK&nbsp; --&gt; <br>
          &lt;--&nbsp;&nbsp; 407&nbsp; -- <br>
          &nbsp;--&nbsp;&nbsp; ACK&nbsp; --&gt; <br>
          &nbsp;... <br>
          &lt;--&nbsp;&nbsp; 407&nbsp; -- (retrans) <br>
          &nbsp;--&nbsp;&nbsp; ACK&nbsp; --&gt; <br>
          <br>
          I wondered if it was the same issue as the stateless reply
          (Flyspray #154), but this happens when we do a t_relay. <br>
          <br>
          Basically, when t_check_trans() is called for the ACK, it does
          not terminate the script. I have worked my way into the
          t_check_trans() code and found that it does not find a
          matching transaction; matching_3261() in t_lookup.c returns 0
          because there are no entries in that hash bucket. <br>
          <br>
          Does anyone understand why this may be happening? <br>
          <br>
          Regards, <br>
          Hugh <br>
          <br>
        </blockquote>
        <br>
        <pre class="moz-signature" cols="72">-- 
--
Hugh Waite
Senior Design Engineer
Crocodile RCS Ltd.</pre>
        <pre wrap="">_______________________________________________
sr-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a>
</pre>
      </blockquote>
      <br>
      <pre class="moz-signature" cols="72">-- 
--
Hugh Waite
Senior Design Engineer
Crocodile RCS Ltd.</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
sr-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a>
</pre>
    </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>
Kamailio Advanced Training, Dec 5-8, Berlin: <a class="moz-txt-link-freetext" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a>
<a class="moz-txt-link-freetext" href="http://linkedin.com/in/miconda">http://linkedin.com/in/miconda</a> -- <a class="moz-txt-link-freetext" href="http://twitter.com/miconda">http://twitter.com/miconda</a></pre>
  </body>
</html>