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