Hi, Callum!
I've just checked this and this looks like a bug in the
rtpproxy_engage() function, not handling properly scenarios where late
negociation is happening in the middle of the call. Please open a bug
report for this on our tracking system[1].
In the meantime, the only solution is to work rtpproxy manually, using
the offer/answer model.
[1] https://github.com/OpenSIPS/opensips/issues
Best regards,
Răzvan
On 5/15/19 7:36 PM, Callum Guy 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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com
Meet the OpenSIPS team at the next OpenSIPS Summit:
https://www.opensips.org/events
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
