Hello Callum, Can you share how you are doing late negotiation?
Regards, David Villasmil email: david.villasmil.w...@gmail.com phone: +34669448337 On Wed, May 15, 2019 at 6:37 PM Callum Guy <callum....@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@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users