<div dir="ltr"><div dir="ltr">Hi Daniel,<div><br></div><div>Thanks for looking at this, I appreciate it! I was just confused as to why in the 200 OK for the re-INVITE, the first Record-Route header is for 127.0.0.1, where in all previous messages with Record-Route headers, the 50.xx.xx.xx (public IP) is the first Record-Route header. You're correct there is no ACK in the re-INVITE transaction because we never receive it on our end. The provider is claiming that the Record-Route headers are causing them to route it improperly. I wasn't sure how those Record-Route headers would affect their routing, so I just wanted to check here to be sure.</div><div><br></div><div>Thanks again!</div><div>Nate Baker</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 8, 2019 at 3:45 AM Daniel Grotti <<a href="mailto:dgrotti@sipwise.com">dgrotti@sipwise.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div 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">
<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="gmail-m_2455671192607354263mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_2455671192607354263moz-quote-pre">_______________________________________________
Spce-user mailing list
<a class="gmail-m_2455671192607354263moz-txt-link-abbreviated" href="mailto:Spce-user@lists.sipwise.com" target="_blank">Spce-user@lists.sipwise.com</a>
<a class="gmail-m_2455671192607354263moz-txt-link-freetext" href="https://lists.sipwise.com/listinfo/spce-user" target="_blank">https://lists.sipwise.com/listinfo/spce-user</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
Spce-user mailing list<br>
<a href="mailto:Spce-user@lists.sipwise.com" target="_blank">Spce-user@lists.sipwise.com</a><br>
<a href="https://lists.sipwise.com/listinfo/spce-user" rel="noreferrer" target="_blank">https://lists.sipwise.com/listinfo/spce-user</a><br>
</blockquote></div>