Jeff,<div>For what it's worth, it appears through initial testing that RTP proxy works for this scenario. We had the offending carrier force the condition where the ports didn't match and still had media. </div><div>
<br></div><div>Thanks for all the feedback guys,</div><div>Brett</div><div><br><br><div class="gmail_quote">On Thu, Jun 17, 2010 at 12:46 PM, Ovidiu Sas <span dir="ltr"><<a href="mailto:osas@voipembedded.com">osas@voipembedded.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Long time ago I tested rtpproxy with asymmetric clients and it worked ok.<br>
IIRC, the 'a' flag must be used while forcing RTP packets through the rtpproxy.<br>
<br>
Regards,<br>
<font color="#888888">Ovidiu Sas<br>
</font><div><div></div><div class="h5"><br>
On Thu, Jun 17, 2010 at 1:41 PM, Adrian Georgescu <<a href="mailto:ag@ag-projects.com">ag@ag-projects.com</a>> wrote:<br>
> We dropped support for asymmetric routing in MediaProxy 2.0.<br>
> RTP proxy might be able to do such trick, you must check the documentation<br>
> as it has some corner features that might cover this scenario.<br>
> Last solutions would be some SBC or an old openser 1.3 +mediaproxy 1.0.<br>
><br>
> Adrian<br>
><br>
> On Jun 17, 2010, at 7:35 PM, Brett Nemeroff wrote:<br>
><br>
> Adrian,<br>
> I appreciate your quick reply.<br>
> I totally agree with your assessment that building such a fix<br>
> only exacerbates this problem by making it "acceptable".<br>
> However, the "powers that be" are not going to fix themselves. You know how<br>
> this is. The offending carrier is Qwest.<br>
> If it wasn't such a large company, I could see isolating them and saying<br>
> that they just don't get the traffic. However, companies like Qwest simply<br>
> don't care if your stuff doesn't work with theirs. So what I'm looking for<br>
> is without question a work around.<br>
> I don't disagree that it's a bad model, but it's all they offer. Which kinda<br>
> makes "MediaProxy" incompatible with Qwest.<br>
> What would you recommend? Do you think rtpproxy operates any differently?<br>
> Thanks,<br>
> Brett<br>
><br>
><br>
><br>
><br>
> On Thu, Jun 17, 2010 at 12:30 PM, Adrian Georgescu <<a href="mailto:ag@ag-projects.com">ag@ag-projects.com</a>><br>
> wrote:<br>
>><br>
>> Brett,<br>
>><br>
>> Is simply bad practice to use asymmetric ports for both signaling and<br>
>> media. Actually there is an RFC that mandates the use of this model for<br>
>> signaling (rfc3581) but then they must honor it. For media there might be<br>
>> another one if I am not mistaken.<br>
>><br>
>> All in all, is a poor choice that lead to investment into equipment that<br>
>> does not use symmetric model and this will only yield this sort of defensive<br>
>> response because there is nobody around to fix that implementation or due to<br>
>> prohibitive costs of moving away from it.<br>
>><br>
>> Adrian<br>
>><br>
>><br>
>><br>
>> On Jun 17, 2010, at 6:44 PM, Brett Nemeroff wrote:<br>
>><br>
>> > Hello All,<br>
>> ><br>
>> > Jeff Pyle brought this issue up some time ago. Using Mediaproxy,<br>
>> > basically I have a provider that says in SDP to use one port, but sources<br>
>> > it's own RTP from a different port.<br>
>> ><br>
>> > I'm not sure if this *actually* breaks any kind of RFC.. What happens is<br>
>> > Mediaproxy tries to stuff RTP into the port it SEEs RTP coming from<br>
>> > (symmetrically). So it's basically completely ignoring the SDP which very<br>
>> > clearly says to use a different port.<br>
>> ><br>
>> > The provider states that this is our lack of compliance and that we<br>
>> > aren't following the SDP. Which is true.<br>
>> ><br>
>> > So who's at fault here? Mediaproxy? Or the provider? This is direct to a<br>
>> > major Tier-1 provider (fwiw).<br>
>> ><br>
>> > Just browsing the Mediaproxy code, it *appears* to not use the SDP port<br>
>> > for anything other than the logs.<br>
>> ><br>
>> > How would RTPProxy handle this call? Will it work the same way? Or will<br>
>> > it honor the SDP properly?<br>
>> ><br>
>> > Thanks!<br>
>> > -Brett<br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > Users mailing list<br>
>> > <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
>> > <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Users mailing list<br>
>> <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
>> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
><br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
><br>
><br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div>