<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi,<br>
      Turns out there was a very easy fix. I was not running t_newtran()
      at the AUTH step in the config so the ACK did not have a
      transaction to match.<br>
      Adding a t_newtran() before the challenge has solved the problem.<br>
      <br>
      Thanks for the help,<br>
      Hugh<br>
      <br>
      On 17/07/2013 13:16, Daniel-Constantin Mierla wrote:<br>
    </div>
    <blockquote cite="mid:51E68B26.2010506@gmail.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      Hello,<br>
      <br>
      I tested with a call between jitsi and csipsimple, authenticating
      an INVITE for a call on hold and the ACK for 407 is intercepted by
      tm.<br>
      <br>
      I used openrcs.com which runs kamailio from few days ago, see the
      trace below (note that I reverted to the old config, so no more
      auth for re-invites on openrcs.com, if you think of trying
      yourself, but should just go the same with the default config file
      -- for me was easier as I had two phones already configured).<br>
      <br>
      Again, be sure the r-uri for ACK is not changed (this check can be
      turned off, look at the sources of t_lookup_request() function in
      tm/t_lookup.c to understand better how the ack is matched to the
      invite transaction).<br>
      <br>
      Cheers,<br>
      Daniel<br>
      <br>
      U 2013/07/17 13:37:18.672912 91.64.193.7:5060 ->
      78.47.51.102:5060<br>
      INVITE <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="sip:micondax@91.64.193.7:47944;ob">sip:micondax@91.64.193.7:47944;ob</a>
      SIP/2.0.<br>
      CSeq: 1 INVITE.<br>
      From: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
        href="sip:daniel@openrcs.com"><sip:daniel@openrcs.com></a>;tag=eec0288f.<br>
      To: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
        href="sip:micondax@openrcs.com"><sip:micondax@openrcs.com></a>;tag=QmVmF5nduqQ2agp8SF8dMRCT-ix11.w3.<br>
      Call-ID: WrJ6SbNtgM51yqPAEr9BChJhbgFzbZHw.<br>
      Max-Forwards: 70.<br>
      Route: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
        href="sip:78.47.51.102;lr=on;did=7d2.5f5;nat=yes"><sip:78.47.51.102;lr=on;did=7d2.5f5;nat=yes></a>.<br>
      Via: SIP/2.0/UDP
192.168.178.31:5060;branch=z9hG4bK-353538-3ca2602df68a86071a1c105f5659404e.<br>
      Contact: "daniel"
      <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="sip:daniel@192.168.178.31:5060;transport=udp;registering_acc=openrcs_com"><sip:daniel@192.168.178.31:5060;transport=udp;registering_acc=openrcs_com></a>.<br>
      User-Agent: Jitsi2.3.4690.9793Mac OS X.<br>
      Content-Type: application/sdp.<br>
      Content-Length: 601.<br>
      .<br>
      <br>
      U 2013/07/17 13:37:18.674008 78.47.51.102:5060 ->
      91.64.193.7:5060<br>
      SIP/2.0 407 Proxy Authentication Required.<br>
      CSeq: 1 INVITE.<br>
      From: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
        href="sip:daniel@openrcs.com"><sip:daniel@openrcs.com></a>;tag=eec0288f.<br>
      To: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
        href="sip:micondax@openrcs.com"><sip:micondax@openrcs.com></a>;tag=QmVmF5nduqQ2agp8SF8dMRCT-ix11.w3.<br>
      Call-ID: WrJ6SbNtgM51yqPAEr9BChJhbgFzbZHw.<br>
      Via: SIP/2.0/UDP
192.168.178.31:5060;branch=z9hG4bK-353538-3ca2602df68a86071a1c105f5659404e;rport=5060;received=91.64.193.7.<br>
      Proxy-Authenticate: Digest realm="openrcs.com",
      nonce="UeaDGlHmge5QrNqex8mLThI/UGoO/wyB".<br>
      Server: kamailio (4.1.0-dev7 (x86_64/linux)).<br>
      Content-Length: 0.<br>
      .<br>
      <br>
      <br>
      U 2013/07/17 13:37:18.713261 91.64.193.7:5060 ->
      78.47.51.102:5060<br>
      ACK <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="sip:micondax@91.64.193.7:47944;ob">sip:micondax@91.64.193.7:47944;ob</a>
      SIP/2.0.<br>
      Call-ID: WrJ6SbNtgM51yqPAEr9BChJhbgFzbZHw.<br>
      Max-Forwards: 70.<br>
      From: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
        href="sip:daniel@openrcs.com"><sip:daniel@openrcs.com></a>;tag=eec0288f.<br>
      To: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
        href="sip:micondax@openrcs.com"><sip:micondax@openrcs.com></a>;tag=QmVmF5nduqQ2agp8SF8dMRCT-ix11.w3.<br>
      Via: SIP/2.0/UDP
192.168.178.31:5060;branch=z9hG4bK-353538-3ca2602df68a86071a1c105f5659404e.<br>
      CSeq: 1 ACK.<br>
      Route: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
        href="sip:78.47.51.102;lr=on;did=7d2.5f5;nat=yes"><sip:78.47.51.102;lr=on;did=7d2.5f5;nat=yes></a>.<br>
      Content-Length: 0.<br>
      .<br>
      <br>
      U 2013/07/17 13:37:18.713278 91.64.193.7:5060 ->
      78.47.51.102:5060<br>
      INVITE <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="sip:micondax@91.64.193.7:47944;ob">sip:micondax@91.64.193.7:47944;ob</a>
      SIP/2.0.<br>
      CSeq: 2 INVITE.<br>
      From: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
        href="sip:daniel@openrcs.com"><sip:daniel@openrcs.com></a>;tag=eec0288f.<br>
      To: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
        href="sip:micondax@openrcs.com"><sip:micondax@openrcs.com></a>;tag=QmVmF5nduqQ2agp8SF8dMRCT-ix11.w3.<br>
      Call-ID: WrJ6SbNtgM51yqPAEr9BChJhbgFzbZHw.<br>
      Max-Forwards: 70.<br>
      Route: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
        href="sip:78.47.51.102;lr=on;did=7d2.5f5;nat=yes"><sip:78.47.51.102;lr=on;did=7d2.5f5;nat=yes></a>.<br>
      Contact: "daniel"
      <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="sip:daniel@192.168.178.31:5060;transport=udp;registering_acc=openrcs_com"><sip:daniel@192.168.178.31:5060;transport=udp;registering_acc=openrcs_com></a>.<br>
      User-Agent: Jitsi2.3.4690.9793Mac OS X.<br>
      Content-Type: application/sdp.<br>
      Via: SIP/2.0/UDP
192.168.178.31:5060;branch=z9hG4bK-353538-13263d273bd563595f7035d30c733ec6.<br>
      Proxy-Authorization: Digest
username="daniel",realm="openrcs.com",nonce="UeaDGlHmge5QrNqex8mLThI/UGoO/wyB",uri=<a
        moz-do-not-send="true" class="moz-txt-link-rfc2396E"
        href="sip:micondax@91.64.193.7:47944;ob">"sip:micondax@91.64.193.7:47944;ob"</a>,response="8d508c695fb767349115fbe816b50170".<br>
      Content-Length: 601.<br>
      .<br>
      <div class="moz-cite-prefix">On 7/16/13 6:59 PM, Daniel-Constantin
        Mierla wrote:<br>
      </div>
      <blockquote cite="mid:51E57C01.5010407@gmail.com" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        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 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>
      </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>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.</pre>
  </body>
</html>