[OpenSIPS-Users] Problem proxying a SIP connection with t_relay

[Thomas Pircher]

John Quick wrote:
>The UAS at 10.30.9.11 has failed to process the two Record-Route headers
>sent in the INVITE. It should send the Route Set back as part of the
>Response - i.e. within the 200 OK. But it hasn't. It has just absorbed the
>Record-Route headers and ignored them. I would say that is faulty UAS
>behaviour, but maybe Bogdan could confirm.

Hi John,

thanks for the reply. Your explanation makes sense to me; I can see that
in the packet capture file, in the replies from the UAS in packets 4 and
6.
Also, your article explains why OpenSIPS adds two RR headers in this
scenario. 

>Consequently, the ACK has no Route headers. That means OpenSIPS is treated
>as the final destination - it doesn't know that it is meant to relay the ACK
>to 10.30.9.11

Now I have the right keywords to search for some more information; it
looks like there was an attempt to fix this in 2006:
https://sourceforge.net/p/sipp/mailman/sipp-users/thread/200606071744.k57HiPJ4002550%40mail.zserv.tuwien.ac.at/#msg9012298

But then there is
http://yuminstallgit.blogspot.com/2011/03/record-route-and-route-fun-in-sipp.html
and the comment from 2021 at the end suggests others have seen the same
issue relatively recently.

>If you can't fix the UAS, you could try using the Topology hiding module in
>OpenSIPS. That would probably overcome the problem because Topology hiding
>doesn't send Record-Route headers downstream.

That gives me a few options; I'll try replacing the SIPp UAS with
FreeSWITCH. This may sound a bit over-engineered, as all I need is a
machine that automatically answers calls to a bunch of usernames and
plays an audio file. But it gives me a scenario that vaguely resembles a
real-world setup, to test against.

Thanks,
Thomas