[OpenSIPS-Users] RTP proxy RE-INVITE with late SDP (ACK cannot have SDP body)
david.villasmil.work at gmail.com
Wed Sep 7 07:45:07 UTC 2022
Can you share how you are doing late negotiation?
email: david.villasmil.work at gmail.com
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):
> Thanks, looking forward to any advice!
> Best regards,
> *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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users