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

[Răzvan Crainea]

Hi, Ben!

The default uas scenario of sipp does not properly treat Record-Route. 
If you are using it, you should drop it and write your own scenario that 
does handle RR, just as Ben suggested.

Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 10/13/22 16:11, Ben Newlin wrote:
> Our servers also use double Record-Route headers and we have always used 
> SIPp in our testing with no issues. There are no inherent faults in the 
> most recent version of SIPp with Record-Route/Route handling as far as I 
> know.
> 
> As long as you are properly setting “rrs=true” on the received INVITE, 
> and including the “<routes>” variable in your replies it all works 
> perfectly.
> 
> https://sipp.sourceforge.net/doc/reference.html#Actions 
> <https://sipp.sourceforge.net/doc/reference.html#Actions>
> 
> Ben Newlin
> 
> *From: *Users <users-bounces at lists.opensips.org> on behalf of Thomas 
> Pircher via Users <users at lists.opensips.org>
> *Date: *Thursday, October 13, 2022 at 4:26 AM
> *To: *users at lists.opensips.org <users at lists.opensips.org>
> *Cc: *John Quick <john.quick at smartvox.co.uk>
> *Subject: *Re: [OpenSIPS-Users] Problem proxying a SIP connection with 
> t_relay
> 
>   EXTERNAL EMAIL - Please use caution with links and attachments
> 
> 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 <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 <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
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users 
> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users