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

[Jeff Pyle]

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/20140206/bfc6449e/attachment.htm>