[Spce-user] Missing ACK after T.38 re-INVITE from provider

[Nate Baker]

Hi Daniel,

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.

Thanks again!
Nate Baker

On Fri, Mar 8, 2019 at 3:45 AM Daniel Grotti <dgrotti at sipwise.com> wrote:

> Hi,
> there is no ACK at all in the trace for the Re-invite transaction.
> 200 OK looks good.
> 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.
>
> This is a problem on your provider, as far as I can see.
>
> Daniel
>
>
>
>
>
> On 3/7/19 6:16 PM, Nate Baker wrote:
>
> Hello Everyone,
>
> 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!
>
> 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).
>
> Thanks,
> Nate Baker
>
> _______________________________________________
> Spce-user mailing listSpce-user at lists.sipwise.comhttps://lists.sipwise.com/listinfo/spce-user
>
>
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> https://lists.sipwise.com/listinfo/spce-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20190308/17408167/attachment-0001.html>