<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hello,<br>
    <br>
    I looked over the code and should match if no changes to r-uri were
    done.<br>
    <br>
    If convenient for you, send me the logs for ACK with debug=3. I will
    try to reproduce these days.<br>
    <br>
    The ack for 200ok is considered separate from invite transaction
    (because it can have different path than the invite).<br>
    <br>
    Cheers,<br>
    Daniel<br>
    <br>
    <div class="moz-cite-prefix">On 7/15/13 7:04 PM, Hugh Waite wrote:<br>
    </div>
    <blockquote cite="mid:51E42BB8.5050109@crocodile-rcs.com"
      type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">Hi,<br>
        This is happening in the WITHINDLG route of our config. For
        gruu'd clients, we run t_check_trans and then do the location
        lookup. I added some extra debug and found it is returning -1
        for ACKs to both 407 and 200 in-dialog responses.<br>
        <blockquote><tt>route[WITHINDLG] {</tt><br>
          <tt>  if (has_totag()) {</tt><br>
          <tt>    if (is_method("ACK")) {</tt><br>
          <tt>      xlog("L_WARN", "Handling ACK...\n");</tt><br>
          <tt>      t_check_trans();</tt><br>
          <tt>      xlog("L_WARN", "...</tt><tt>return</tt><tt>ed
            $rc\n");</tt><tt><br>
          </tt><tt>    }</tt><tt><br>
          </tt><tt>    ...</tt><tt><br>
          </tt><tt>    # lookup/forward etc.</tt><tt><br>
          </tt><tt>  }</tt><br>
          <tt>}</tt><br>
        </blockquote>
        Hugh<br>
        <br>
        On 15/07/2013 15:18, Daniel-Constantin Mierla wrote:<br>
      </div>
      <blockquote cite="mid:51E404B5.40800@gmail.com" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        Hello,<br>
        <br>
        because of the route headers, I guess there is a different path
        in config file, not hitting t_check_trans() from config for ACK
        (or at least the one I expected), ending in looking up the r-uri
        via location, like normal requests within dialog.<br>
        <br>
        Can you try to hanlde the ack with t_check_trans() on that
        config path as well, before changing r-uri?<br>
        <br>
        Cheers,<br>
        Daniel<br>
        <br>
        <div class="moz-cite-prefix">On 7/15/13 10:28 AM, Hugh Waite
          wrote:<br>
        </div>
        <blockquote cite="mid:51E3B2AE.90604@crocodile-rcs.com"
          type="cite">Hi, <br>
          I've attached the signalling trace of this call. <br>
          The ACK does have a Route set, but we think this is correct
          according to §17.1.1.3 of RFC3261. <br>
          "  If the INVITE request whose response is being acknowledged
          had Route header fields, those header fields MUST appear in
          the ACK. This is to ensure that the ACK can be routed properly
          through any downstream stateless proxies.  " <br>
          <br>
          A failure response to an INVITE does not have a Contact header
          and a reINVITE does not Record-Route, so the ACK needs to be
          constructed in the same way as the INVITE w.r.t. request URI
          and Route set. <br>
          When the ACK for the 407 arrives, can kamailio detect that the
          transaction is in the 'Completed' state and drop it [1]? <br>
          <br>
          Hugh <br>
          <br>
          [1] RFC 6026 §8.6 which updates RFC3261 §17.2.1 <br>
          <br>
          <br>
          On 12/07/2013 16:22, Daniel-Constantin Mierla wrote: <br>
          <blockquote type="cite">Hello, <br>
            <br>
            iirc, ACKs for negative replies should be hop-by-hop,
            without any route set. Maybe you can paste a ngrep with
            invite/407/ack to see exactly what is there. <br>
            <br>
            On the other hand, t_check_trans() for ack returns true if
            there is an active invite transaction associated with it,
            because ack itself does not create transaction, being a
            request that doesn't take a reply. <br>
            <br>
            Cheers, <br>
            Daniel <br>
            <br>
            On 7/12/13 5:11 PM, Hugh Waite wrote: <br>
            <blockquote type="cite">Hello, <br>
              I have a question on the use of t_check_trans for
              in-dialog requests. <br>
              <br>
              If an in-dialog INVITE is challenged by kamailio (sending
              a 407 response), the ACK should be absorbed. However, the
              t_check_trans function does not terminate the script. In
              our config, this means the ACK gets sent to the client due
              to the route-set. <br>
              <br>
              Should t_check_trans recognise that this transaction was
              rejected locally, even though there is an onward
              route-set? <br>
              <br>
              Hugh <br>
              <br>
            </blockquote>
            <br>
          </blockquote>
          <br>
          <br>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <br>
          <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">-- 
Daniel-Constantin Mierla - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://twitter.com/#%21/miconda">http://twitter.com/#!/miconda</a> - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
</pre>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <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>
      <br>
      <pre class="moz-signature" cols="72">-- 
Hugh Waite
Principal 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>
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
</pre>
  </body>
</html>