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

Mon May 20 08:57:35 EDT 2019

https://github.com/OpenSIPS/opensips/issues/1702

On Mon, 20 May 2019 at 13:49, Callum Guy <callum.guy at x-on.co.uk> wrote:

> Hi Răzvan,
>
> Very kind of you to review this problem. I will go ahead and raise an
> issue as requested.
>
> 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.
>
> Many thanks,
>
> Callum
>
> On Mon, 20 May 2019 at 13:28, Răzvan Crainea <razvan at opensips.org> wrote:
>
>> 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
>> > Users at lists.opensips.org
>> > 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
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>

-- 

*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/20190520/e89504ec/attachment-0001.html>