[OpenSIPS-Users] rtpengine_offer on REINVITE

[Callum Guy]

Hi All,

Following up on this following another media server crash.

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).

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.

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!

Thanks,

Callum

On Wed, 22 Feb 2023 at 21:40, Callum Guy <callum.guy at x-on.co.uk> wrote:

> Hi All,
>
> 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.
>
> 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 "*Received invalid STUN packet from
> 1.8.4.1:58184 <http://1.8.4.1:58184>: MESSAGE_INTEGRITY attribute missing*"
> and FreeSWITCH segfaults.
>
> 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?
>
> Thanks,
>
> Callum
>

-- 






*0333 332 0000  |  x-on.co.uk <https://www.x-on.co.uk>  |   ** 
<https://www.linkedin.com/company/x-on>   <https://www.facebook.com/XonTel> 
  <https://twitter.com/xonuk> **  |  **Practice Index Reviews 
<https://practiceindex.co.uk/gp/x-on>*

*Our new office address: 22 Riduna 
Park, Melton IP12 1QT.*

X-on
is a trading name of Storacall Technology Ltd 
a limited company registered in
England and Wales.

Registered Office : 
Glebe Farm, Down Street, Dummer, Basingstoke, Hampshire, England RG25 2AD. 
Company Registration No. 2578478.

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 +44(0)333 332 0000 
and delete the
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. Views
or opinions expressed by an individual
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
for
viruses. X-on makes no 
representation or warranty as to the absence of viruses
in this email or 
any attachments.








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20230313/a80e15eb/attachment.html>