<div dir="ltr">Hi All,<br><div><br></div><div>Following up on this following another media server crash.</div><div><br></div><div>Since the previous email it was discovered that on occasion RTPEngine would be delayed in responding to OpenSIPs and therefore a second RTP server was tried triggering the failure scenario (unnecessary DTLS renegotiation mid-call).</div><div><br></div><div>This time there was no detectable delay, a call was simply established through OpenSIPs however a RE-INVITE arriving at the 1 minute mark engaged a separate RTP server. Can anyone explain the mechanism by which a RTP server which was selected during the dialog setup is attached to the dialog data for subsequent requests, and identify any possible weakness where this would not be recorded? In over 99.99% of situations it certainly selects the RTP server previously engaged however there must be a weakness for this to occur.</div><div><br></div><div>Any thoughts on debugging/mitigation would be appreciated! The affected system is running 3.2.4 - happy to upgrade if there has been any work in this area!</div><div><br></div><div>Thanks,</div><div><br></div><div>Callum</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 22 Feb 2023 at 21:40, Callum Guy <<a href="mailto:callum.guy@x-on.co.uk">callum.guy@x-on.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi All,<br><div><br></div><div>I operate OpenSIPs in front of a bank of FreeSWITCH instances and I'm currently seeing an issue with FreeSWITCH crashing during a SRTP DTLS renegotiation triggered by a RE-INVITE.</div><div><br></div><div>I've tracked this down to a WSS registrar which is issuing rtpengine_offer(...) for the INVITE and any subsequent RE-INVITE. This happens thousands of times a day without issue however on occasion OpenSIPs sends that RE-INVITE request to a different rtpengine server from the pool. This writes in the new RTP proxy IP and initiates a new ICE negotiation, the client fails to handle this and the DTLS negotiation breaks down - RTPEngine warns "<i>Received invalid STUN packet from <a href="http://1.8.4.1:58184" target="_blank">1.8.4.1:58184</a>: MESSAGE_INTEGRITY attribute missing</i>" and FreeSWITCH segfaults.</div><div><br></div><div>Can anyone advise on what might be causing OpenSIPs to pick an unrelated RTP instance for the dialog? Any ideas for preventing that would be appreciated! I could conceivably save the socket after the initial offer against the dialog and use that for additional offers but hopefully that can be avoided. I use RTPEngine only as a proxy, perhaps I should simply prevent RE-INVITE's from sending additional offers so I only have one offer/answer/delete per call?</div><div><br></div><div>Thanks,</div><div><br></div><div>Callum</div></div>
</blockquote></div>

<br>
<p dir="ltr" style="font-family:Arial,Helvetica,sans-serif;font-size:1.3em;line-height:1.38;margin-top:0pt;margin-bottom:0pt;text-align:justify"><font size="3" face="Verdana"><span style="font-size:8px;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span></font></p><div style="font-family:Arial,Helvetica,sans-serif;font-size:1.3em"><img src="https://www.x-on.co.uk/email/footer/banner-03-2023.jpg"><br></div><div style="font-family:Arial,Helvetica,sans-serif;font-size:1.3em"><br></div><div><font size="4" style="font-family:Arial,Helvetica,sans-serif;font-size:1.3em"><b>^{<font face="Verdana">0333 332 0000  |  <a href="https://www.x-on.co.uk" target="_blank">x-on.co.uk</a>  |  </font>}</b></font><font size="4" style="font-family:Arial,Helvetica,sans-serif;font-size:1.3em"><b>_{^{<font face="Verdana"><a href="https://www.linkedin.com/company/x-on" target="_blank"><img src="http://www.x-on.co.uk//images/icon/linkedin.png" width="24" height="24"></a>  <a href="https://www.facebook.com/XonTel" target="_blank"><img src="http://www.x-on.co.uk//images/icon/facebook.png" width="24" height="24"></a>  <a href="https://twitter.com/xonuk" target="_blank"><img src="http://www.x-on.co.uk//images/icon/twitter.png" width="24" height="24"></a></font>}} </b></font><b style="font-family:Arial,Helvetica,sans-serif;font-size:large">^{<font face="Verdana">  |  </font>}</b><b style="font-size:16.9px">^{<font face="Verdana"><a href="https://practiceindex.co.uk/gp/x-on" target="_blank">Practice Index Reviews</a></font>}</b><p><font face="Verdana" color="#ff0000" size="1"><b>Our new office address: 22 Riduna Park, Melton IP12 1QT.</b></font></p><p style="font-family:Arial,Helvetica,sans-serif;font-size:1.3em"><span style="font-size:6pt;font-family:Verdana;color:black">X-on
is a trading name of Storacall Technology Ltd a limited company registered in
England and Wales.<br>
Registered Office : Glebe Farm, Down Street, Dummer, Basingstoke, Hampshire, England RG25 2AD. Company Registration No. 2578478.<br>
The information in this e-mail is confidential and for use by the addressee(s)
only. If you are not the intended recipient, please notify X-on immediately on <span>+44(0)333 332 0000</span> and delete the<br>message from your computer. If you are not a named addressee you must not use,
disclose, disseminate, distribute, copy, print or reply to this email. </span><span style="font-size:6pt;font-family:Verdana;color:black">Views
or opinions expressed by an individual<br>within this email may not necessarily
reflect the views of X-on or its associated companies. Although X-on routinely
screens for viruses, addressees should scan this email and any attachments<br>for
viruses. X-on makes no representation or warranty as to the absence of viruses
in this email or any attachments.</span></p>





<p style="font-family:Arial,Helvetica,sans-serif;font-size:1.3em"><span style="font-size:6pt;font-family:Verdana;color:black"></span><font size="2"><span style="font-size:6pt;font-family:Verdana;color:black"></span></font></p></div>