<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <tt>Hi,<br>
      there is no ACK at all in the trace for the Re-invite transaction.<br>
      200 OK looks good.<br>
      The ACK from the provider should have as RURI the Contact header
      in the 200OK and he must contains the Route headers taken from the
      Record-Route headers in the 200OK, in reverse order, as per
      RFC3261.<br>
      <br>
      This is a problem on your provider, as far as I can see.<br>
      <br>
      Daniel<br>
      <br>
      <br>
      <br>
      <br>
      <br>
    </tt>On 3/7/19 6:16 PM, Nate Baker wrote:<br>
    <blockquote type="cite"
cite="mid:CADwrbY0fGavRhQ69qitdXzdEeiLvNN0_BmErkOnmoq3AGn2eiQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Hello Everyone,
        <div><br>
        </div>
        <div>I'm having an issue with sending faxes using T.38
          (receiving works fine) when the provider sends the re-INVITE. 
          This is with SPCE 6.5.3, and the problem is that after sending
          the 200 OK for the re-INVITE, we never get an ACK back.  After
          looking at packet captures and working with the provider, we
          think it has to do with the record-route headers.  The
          provider says we shouldn't send them at all, but I think they
          might just be reversed.  Could someone please take a look at
          the attached exchange and let me know if the record-route
          headers in the 200 OK after re-INVITE look correct?  It seems
          to me that they are reversed, since in the original INVITE and
          ACK they are in opposite order, so I'm thinking they can't
          route the ACK back to us.  Then our SPCE keeps resending the
          200 OK, and eventually the call hangs up.  If there's a better
          way to send the trace let me know!</div>
        <div><br>
        </div>
        <div>If I make the provider not send the re-INVITE, and our end
          sends it instead, the call works fine.  I've also tried using
          "topos" to hide the record-route headers, but in that case
          SPCE sends ACKs from the wrong interface so it doesn't work
          either (probably separate problem).</div>
        <div><br>
        </div>
        <div>Thanks,</div>
        <div>Nate Baker</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Spce-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Spce-user@lists.sipwise.com">Spce-user@lists.sipwise.com</a>
<a class="moz-txt-link-freetext" href="https://lists.sipwise.com/listinfo/spce-user">https://lists.sipwise.com/listinfo/spce-user</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>