[OpenSIPS-Users] asymetric rtp problems with mediaproxy

[Adrian Georgescu]

I remember that there were some settings about asymmetric_clients, you must check the docs.

Adrian

On Jun 17, 2010, at 7:42 PM, Brett Nemeroff wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20100617/f5920d24/attachment.htm