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

[Callum Guy]

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.










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