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 <[email protected]> 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 > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
