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 <[email protected]> on behalf of Thomas
Pircher via Users <[email protected]>
*Date: *Thursday, October 13, 2022 at 4:26 AM
*To: *[email protected] <[email protected]>
*Cc: *John Quick <[email protected]>
*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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
