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

[Jeff Pyle]

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/20140204/3f5e7a77/attachment.htm>