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

[Răzvan Crainea]

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 Solutions
www.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 
> <mailto: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 <mailto: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
>         <http://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
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20140912/89beb647/attachment-0001.htm>