<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Times New Roman \(Body CS\)";
        panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><a href="https://sipp.sourceforge.net/doc/reference.html#Actions">https://sipp.sourceforge.net/doc/reference.html#Actions</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:black">Ben Newlin </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Users <users-bounces@lists.opensips.org> on behalf of Thomas Pircher via Users <users@lists.opensips.org><br>
<b>Date: </b>Thursday, October 13, 2022 at 4:26 AM<br>
<b>To: </b>users@lists.opensips.org <users@lists.opensips.org><br>
<b>Cc: </b>John Quick <john.quick@smartvox.co.uk><br>
<b>Subject: </b>Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> EXTERNAL EMAIL - Please use caution with links and attachments <br>
<br>
John Quick wrote:<br>
>The UAS at 10.30.9.11 has failed to process the two Record-Route headers<br>
>sent in the INVITE. It should send the Route Set back as part of the<br>
>Response - i.e. within the 200 OK. But it hasn't. It has just absorbed the<br>
>Record-Route headers and ignored them. I would say that is faulty UAS<br>
>behaviour, but maybe Bogdan could confirm.<br>
<br>
Hi John,<br>
<br>
thanks for the reply. Your explanation makes sense to me; I can see that<br>
in the packet capture file, in the replies from the UAS in packets 4 and<br>
6.<br>
Also, your article explains why OpenSIPS adds two RR headers in this<br>
scenario. <br>
<br>
>Consequently, the ACK has no Route headers. That means OpenSIPS is treated<br>
>as the final destination - it doesn't know that it is meant to relay the ACK<br>
>to 10.30.9.11<br>
<br>
Now I have the right keywords to search for some more information; it<br>
looks like there was an attempt to fix this in 2006:<br>
<a href="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</a><br>
<br>
But then there is<br>
<a href="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</a><br>
and the comment from 2021 at the end suggests others have seen the same<br>
issue relatively recently.<br>
<br>
>If you can't fix the UAS, you could try using the Topology hiding module in<br>
>OpenSIPS. That would probably overcome the problem because Topology hiding<br>
>doesn't send Record-Route headers downstream.<br>
<br>
That gives me a few options; I'll try replacing the SIPp UAS with<br>
FreeSWITCH. This may sound a bit over-engineered, as all I need is a<br>
machine that automatically answers calls to a bunch of usernames and<br>
plays an audio file. But it gives me a scenario that vaguely resembles a<br>
real-world setup, to test against.<br>
<br>
Thanks,<br>
Thomas<br>
<br>
_______________________________________________<br>
Users mailing list<br>
Users@lists.opensips.org<br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><o:p></o:p></p>
</div>
</div>
</body>
</html>