[OpenSIPS-Users] rtpproxy - preserve original session after rejected reinvite

[Jeff Pyle]

Hi Răzvan,

I feared something like this might be the case.  I'll look into filing the
bug reports.

My application is near-side NAT traversal in a proxy configuration,
relaying RTP and SIP between LAN and WAN.  Are you aware of any way around
this issue with something other than rtpproxy?  something other than
OpenSIPS?  Can I ask that on this list?   :)

Before using OpenSIPS and rtpproxy for this I used FreeSWITCH with
proxy-media, and while I don't believe it suffered from this particular
issue, it caused other incompatibilities.  My goal is to keep this system
as light and unobtrusive as possible.  Any suggestions you might have would
be great.


- Jeff


On Fri, Sep 12, 2014 at 3:22 AM, Răzvan Crainea <razvan at opensips.org> wrote:

>  Hi, Jeff!
>
> The main problem is that nor opensips neither rtpproxy can differentiate
> between the first SDP streams and the second one. The reason is that both
> OpenSIPS and RTPProxy only consider the order the streams are in the SDP
> packet, and in your case, both of them are first.
> Solving this on OpenSIPS side is quite challenging, since we have to keep
> a state between the first SDP stream (remember it is an audio session and
> mark it as stream no. 1) and when the second SDP stream comes in, check
> whether it is a new one or not (in your case determine it is a different
> one, T.38, and mark it as stream no. 2). We will definitely not implement
> this in OpenSIPS, since it is not the correct approach.
> Ideally each SDP should have an unique identifier that is passed to
> RTPProxy by OpenSIPS, but unfortunately this is not supported in RTPProxy.
> So with the current code, I can't see how your issue can be solved. The
> only think you can do is add a bug report for both projects, detailing the
> problem.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 09/12/2014 04:11 AM, Jeff Pyle wrote:
>
>   List,
>
>  I was never able to truly solve this issue.  Instead I worked around it
> by preventing the ports from changing between the G711 and the T38
> sessions.  Well, now I've encountered situations I can't control.  I need
> to ask again if anyone has any thoughts on how to handle a refused
> re-invite in rtpproxy when the proposed session was going to use different
> RTP port numbers than the existing one.
>
>  All the details are in the thread.
>
>  Thanks in advance for any suggestions.
>
>
>  - Jeff
>
>
>
> On Thu, Feb 6, 2014 at 7:57 PM, Jeff Pyle <jpyle at fidelityvoice.com> wrote:
>
>>   Just for grins I tried the engage_rtp_proxy() approach instead.  It
>> has the same problem, using the newly indicated ports on the old session.
>>  This sounds like a bug to me.
>>
>>
>>  - Jeff
>>
>>
>> On Tue, Feb 4, 2014 at 10:06 AM, Jeff Pyle <jpyle at fidelityvoice.com>
>> wrote:
>>
>>>   Hello,
>>>
>>>  This is on Opensips 1.10 and rtpproxy 1.2.1.  I have them dual-homed
>>> on public and private networks with rtpproxy in bridge mode.  Overall,
>>> things work well.  I've recently encountered a problem I don't know how to
>>> solve relating to a T.38 reinvite that is rejected by the public side.
>>>  rtpproxy uses the new ports in the T.38 SDP even though it was rejected,
>>> effectively killing the G.711 session that should be maintained.
>>>
>>>  Here's a specific call flow.  A call comes in from the public side and
>>> is routed to the private side, having rtpproxy_offer run on it.  The
>>> private UA 10.1.30.219 answers the G.711 call with this SDP in its 200 OK:
>>>
>>>     v=0.
>>>    o=userX 198 2 IN IP4 10.1.30.219.
>>>    s=-.
>>>    c=IN IP4 10.1.30.219.
>>>    t=0 0.
>>>    m=audio *50460* RTP/AVP 0.
>>>    a=ptime:20.
>>>    a=rtpmap:0 PCMU/8000.
>>>
>>>
>>>  rtpproxy_answer happens on this; the call establishes with two-way RTP
>>> and all is well.  A few moments later the private UA re-invites to T.38
>>> with this SDP:
>>>
>>>     v=0.
>>>    o=userX 198 3 IN IP4 10.1.30.219.
>>>    s=-.
>>>    c=IN IP4 10.1.30.219.
>>>    t=0 0.
>>>    m=image *50462* udptl t38.
>>>    a=T38FaxVersion:0.
>>>    a=T38MaxBitRate:14400.
>>>    a=T38FaxRateManagement:transferredTCF.
>>>    a=T38FaxMaxBuffer:262.
>>>    a=T38FaxMaxDatagram:176.
>>>    a=T38FaxUdpEC:t38UDPRedundancy.
>>>
>>>
>>>  You'll notice the UA has changed its port from 50460 to 50462.
>>>  rtpproxy_offer("frocl") is called on this re-INVITE and rtpproxy redirects
>>> the inbound RTP to 10.1.30.219:*50462*.
>>>
>>>  A few milliseconds later a 488 comes in from the public side.  We're
>>> left with our original G.711 session, which is fine, but the RTP is now
>>> going to 50462 instead of 50460 and the UA doesn't see it.
>>>
>>>  I'm struggling with an rtpproxy_offer/rtpproxy_answer configuration to
>>> allow the session to revert in the event the re-invite is rejected like
>>> this.  I've tried rtpproxy_offer without the "l" lookup flag - no effect.
>>>  Any thoughts?
>>>
>>>  Another detail... I use rtpproxy_offer/rtpproxy_answer to manage mixed
>>> early and late negotiation scenarios that engage_rtp_proxy() cannot handle.
>>>  The automatic function isn't an option unfortunately.
>>>
>>>
>>>  - Jeff
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20140912/adf2268e/attachment-0001.htm>