<div dir="ltr"><a href="https://github.com/OpenSIPS/opensips/issues/1702">https://github.com/OpenSIPS/opensips/issues/1702</a><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 20 May 2019 at 13:49, 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"><div dir="ltr">Hi Răzvan,</div><div dir="ltr"><br></div><div>Very kind of you to review this problem. I will go ahead and raise an issue as requested. </div><div><br></div><div>I can confirm that I have had some success using the offer/answer model but it certainly adds a level of complexity which would be best dealt with behind the scenes by the module especially where I am operating in bridge mode - the module e/i flags get a bit more challenging when you are implementing in the reply routes for example.</div><div><br></div><div>Many thanks,</div><div><br></div><div>Callum</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 20 May 2019 at 13:28, Răzvan Crainea <<a href="mailto:razvan@opensips.org" target="_blank">razvan@opensips.org</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">Hi, Callum!<br>
<br>
I've just checked this and this looks like a bug in the <br>
rtpproxy_engage() function, not handling properly  scenarios where late <br>
negociation is happening in the middle of the call. Please open a bug <br>
report for this on our tracking system[1].<br>
In the meantime, the only solution is to work rtpproxy manually, using <br>
the offer/answer model.<br>
<br>
[1] <a href="https://github.com/OpenSIPS/opensips/issues" rel="noreferrer" target="_blank">https://github.com/OpenSIPS/opensips/issues</a><br>
<br>
Best regards,<br>
Răzvan<br>
<br>
On 5/15/19 7:36 PM, Callum Guy wrote:<br>
> Hi All,<br>
> <br>
> I am working on a problem where for a few destinations my OpenSIPs is <br>
> receiving RE-INVITE messages with late SDP. This is causing a breakdown <br>
> in the rtpproxy engagement and causing the audio to fail mid call.<br>
> <br>
> The OpenSIPs deployment is acting as a SIP proxy which traverses NAT and <br>
> rtpproxy is used in bridging mode. I am using rtpproxy_engage to tie the <br>
> integration to the dialog session and this is for all other purposes <br>
> working as expected.<br>
> <br>
> My failure scenario is when the remote system sends a RE-INVITE message <br>
> which includes no SDP. This passes through to my FreeSWITCH server which <br>
> responds with a 200 including SDP. This message is processed fine and <br>
> interacts with rtpproxy as expected and provides the remote with the <br>
> correct public IP and port for RTP (the same as returned during call <br>
> setup). In response the remote system returns an ACK with SDP which <br>
> triggers an OpenSIPs error message (below) which results in the remotes <br>
> public IP being passed through in SDP which causes the FreeSWITCH to <br>
> start sending RTP direct resulting in one way audio as the media server <br>
> is not publicly accessible.<br>
> <br>
> *ERROR:rtpproxy:engage_force_rtpproxy: not a late negotiation - ACK <br>
> cannot have SDP body*<br>
> <br>
> As I understand it the FreeSWITCH behaviour is OK, although I am not <br>
> clear why it feels the need to resend the SDP. All I want to happen in <br>
> this scenario is for rtpproxy module to re-write the SDP in the way it <br>
> has for all previous messages. I am very interested to hear if there is <br>
> any reason for rtpproxy to disallow late negotiation in this scenario, <br>
> if anyone can point to a relevant RFC that would be interesting!<br>
> <br>
> Is there any way around this other than some sort of manual SDP re-write <br>
> (not helpful to me as I am using a pool of rtpproxy instances)? Might I <br>
> have more luck with offer/answer or indeed rtpengine?<br>
> <br>
> I've illustrated the scenario better on the following link (sngrep paste):<br>
> <br>
> <a href="https://gist.githubusercontent.com/spacetourist/ef0478c0bf4e2d736f9b5663042087dd/raw/6f0a984a1a2838e7e2c4539f059fd68935a3b0b1/gistfile1.txt" rel="noreferrer" target="_blank">https://gist.githubusercontent.com/spacetourist/ef0478c0bf4e2d736f9b5663042087dd/raw/6f0a984a1a2838e7e2c4539f059fd68935a3b0b1/gistfile1.txt</a><br>
> <br>
> Thanks, looking forward to any advice!<br>
> <br>
> Best regards,<br>
> <br>
> Callum<br>
> <br>
> <br>
> <br>
> <br>
> *^0333 332 0000  | <a href="http://www.x-on.co.uk" rel="noreferrer" target="_blank">www.x-on.co.uk</a> <<a href="http://www.x-on.co.uk" rel="noreferrer" target="_blank">http://www.x-on.co.uk</a>>  | <br>
> _**_^<<a href="https://www.linkedin.com/company/x-on" rel="noreferrer" target="_blank">https://www.linkedin.com/company/x-on</a>> <br>
> <<a href="https://www.facebook.com/XonTel" rel="noreferrer" target="_blank">https://www.facebook.com/XonTel</a>> <<a href="https://twitter.com/xonuk" rel="noreferrer" target="_blank">https://twitter.com/xonuk</a>> *<br>
> <br>
> X-on is a trading name of Storacall Technology Ltd a limited company <br>
> registered in England and Wales.<br>
> Registered Office : Avaland House, 110 London Road, Apsley, Hemel <br>
> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478.<br>
> The information in this e-mail is confidential and for use by the <br>
> addressee(s) only. If you are not the intended recipient, please notify <br>
> X-on immediately on +44(0)333 332 0000 and delete the<br>
> message from your computer. If you are not a named addressee you must <br>
> not use, disclose, disseminate, distribute, copy, print or reply to this <br>
> email. Views or opinions expressed by an individual<br>
> within this email may not necessarily reflect the views of X-on or its <br>
> associated companies. Although X-on routinely screens for viruses, <br>
> addressees should scan this email and any attachments<br>
> for viruses. X-on makes no representation or warranty as to the absence <br>
> of viruses in this email or any attachments.<br>
> <br>
> <br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
> <br>
<br>
-- <br>
Răzvan Crainea<br>
OpenSIPS Core Developer<br>
   <a href="http://www.opensips-solutions.com" rel="noreferrer" target="_blank">http://www.opensips-solutions.com</a><br>
Meet the OpenSIPS team at the next OpenSIPS Summit:<br>
   <a href="https://www.opensips.org/events" rel="noreferrer" target="_blank">https://www.opensips.org/events</a><br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div>
</blockquote></div>

<br>
<p dir="ltr" style="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><img src="https://www.x-on.co.uk/email/footer/banner-surgeryconnect-jun-sep-19.jpg"></div><div><br></div><div><div><div><font size="4"><b><sup><font face="Verdana">0333 332 0000  |  <a href="http://www.x-on.co.uk" target="_blank">www.x-on.co.uk</a>  |  <sub> </sub></font></sup></b></font><font size="4"><b><sub><sup><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></sup></sub> </b></font><br><p><span style="font-size:6.0pt;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 : Avaland House, 110 London Road, Apsley, Hemel Hempstead,
Herts, HP3 9SD. 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:6.0pt;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><span style="font-size:6.0pt;font-family:Verdana;color:black"></span><font size="2"><span style="font-size:6.0pt;font-family:Verdana;color:black"></span></font></p></div></div></div>