<div dir="ltr"><div class="gmail_extra"><div><div dir="ltr"><div>List,</div><div><br></div><div>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.</div><div><br></div><div>All the details are in the thread.</div><div><br></div><div>Thanks in advance for any suggestions.</div><div><br></div><div><br></div><div>- Jeff</div><div><br>
<br></div></div></div>
<br><div class="gmail_quote">On Thu, Feb 6, 2014 at 7:57 PM, Jeff Pyle <span dir="ltr"><<a href="mailto:jpyle@fidelityvoice.com" target="_blank">jpyle@fidelityvoice.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div dir="ltr"><div>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.</div><span class="HOEnZb"><font color="#888888">
<div><br></div><div><br></div><div>- Jeff</div><div><br></div></font></span></div></div><div><div class="h5"><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 10:06 AM, Jeff Pyle <span dir="ltr"><<a href="mailto:jpyle@fidelityvoice.com" target="_blank">jpyle@fidelityvoice.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div dir="ltr"><div>Hello,</div><div><br></div><div>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.</div>
<div><br></div><div>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:</div>
<div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><div>v=0.</div></div></div></div><div><div><div><div>o=userX 198 2 IN IP4 10.1.30.219.</div></div></div></div>
<div>
<div><div><div>s=-.</div></div></div></div><div><div><div><div>c=IN IP4 10.1.30.219.</div></div></div></div><div><div><div><div>t=0 0.</div></div></div></div><div><div><div><div>m=audio <b>50460</b> RTP/AVP 0.</div></div>
</div></div><div><div><div><div>a=ptime:20.</div></div></div></div><div><div><div><div>a=rtpmap:0 PCMU/8000.</div></div></div></div></blockquote><div><div dir="ltr"><div><br></div><div>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:</div>
<div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><div>v=0.</div></div></div></div><div><div><div><div>o=userX 198 3 IN IP4 10.1.30.219.</div></div></div></div>
<div>
<div><div><div>s=-.</div></div></div></div><div><div><div><div>c=IN IP4 10.1.30.219.</div></div></div></div><div><div><div><div>t=0 0.</div></div></div></div><div><div><div><div>m=image <b>50462</b> udptl t38.</div></div>
</div></div><div><div><div><div>a=T38FaxVersion:0.</div></div></div></div><div><div><div><div>a=T38MaxBitRate:14400.</div></div></div></div><div><div><div><div>a=T38FaxRateManagement:transferredTCF.</div></div></div></div>
<div><div><div><div>a=T38FaxMaxBuffer:262.</div></div></div></div><div><div><div><div>a=T38FaxMaxDatagram:176.</div></div></div></div><div><div><div><div>a=T38FaxUdpEC:t38UDPRedundancy.</div></div></div></div></blockquote>
<div><div dir="ltr"><div><br></div><div>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 <a href="http://10.1.30.219" target="_blank">10.1.30.219</a>:<b>50462</b>.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div><div>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. </div>
<span><font color="#888888">
<div><br></div><div><br></div><div>- Jeff</div><div><br></div></font></span></div></div>
</div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>