[OpenSIPS-Users] RTP proxy RE-INVITE with late SDP (ACK cannot have SDP body)

[David Villasmil]

Hello Callum,

Can you share how you are doing late negotiation?

Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337


On Wed, May 15, 2019 at 6:37 PM Callum Guy <callum.guy at x-on.co.uk> wrote:

> Hi All,
>
> I am working on a problem where for a few destinations my OpenSIPs is
> receiving RE-INVITE messages with late SDP. This is causing a breakdown in
> the rtpproxy engagement and causing the audio to fail mid call.
>
> The OpenSIPs deployment is acting as a SIP proxy which traverses NAT and
> rtpproxy is used in bridging mode. I am using rtpproxy_engage to tie the
> integration to the dialog session and this is for all other purposes
> working as expected.
>
> My failure scenario is when the remote system sends a RE-INVITE message
> which includes no SDP. This passes through to my FreeSWITCH server which
> responds with a 200 including SDP. This message is processed fine and
> interacts with rtpproxy as expected and provides the remote with the
> correct public IP and port for RTP (the same as returned during call
> setup). In response the remote system returns an ACK with SDP which
> triggers an OpenSIPs error message (below) which results in the remotes
> public IP being passed through in SDP which causes the FreeSWITCH to start
> sending RTP direct resulting in one way audio as the media server is not
> publicly accessible.
>
> *ERROR:rtpproxy:engage_force_rtpproxy: not a late negotiation - ACK cannot
> have SDP body*
>
> As I understand it the FreeSWITCH behaviour is OK, although I am not clear
> why it feels the need to resend the SDP. All I want to happen in this
> scenario is for rtpproxy module to re-write the SDP in the way it has for
> all previous messages. I am very interested to hear if there is any reason
> for rtpproxy to disallow late negotiation in this scenario, if anyone can
> point to a relevant RFC that would be interesting!
>
> Is there any way around this other than some sort of manual SDP re-write
> (not helpful to me as I am using a pool of rtpproxy instances)? Might I
> have more luck with offer/answer or indeed rtpengine?
>
> I've illustrated the scenario better on the following link (sngrep paste):
>
>
> https://gist.githubusercontent.com/spacetourist/ef0478c0bf4e2d736f9b5663042087dd/raw/6f0a984a1a2838e7e2c4539f059fd68935a3b0b1/gistfile1.txt
>
> Thanks, looking forward to any advice!
>
> Best regards,
>
> Callum
>
>
>
>
> *0333 332 0000  |  www.x-on.co.uk <http://www.x-on.co.uk>  |   **
> <https://www.linkedin.com/company/x-on>   <https://www.facebook.com/XonTel>
>   <https://twitter.com/xonuk> *
>
> X-on is a trading name of Storacall Technology Ltd a limited company
> registered in England and Wales.
> Registered Office : Avaland House, 110 London Road, Apsley, Hemel
> Hempstead, Herts, HP3 9SD. 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.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20220907/1cc01796/attachment.html>