Christian, It's good to see that you question has been answered. As for the reason why "bridge" mode asserts asymmetric operation, the logic behind it is that "bridge" mode should be working with any devices, including RTP-asymmetric ones.
Christian Koch wrote: > Thanks!!! With that flag it works without modifying the rtpproxy code. I > simply missed that flag. Sorry for the confusion. > > Ovidiu Sas schrieb: >> OpenSER has a flag 'w' that forces support symmetric RTP. >> http://www.openser.org/docs/modules/1.3.x/nathelper.html#AEN316 >> >> Regards, >> Ovidiu Sas >> >> On Wed, May 21, 2008 at 8:50 AM, Christian Koch >> <[EMAIL PROTECTED]> wrote: >> >>> Hi, >>> >>> I've been facing a problem with rtpproxy in bridging mode where one >>> client is behind a NAT (for details please see >>> http://lists.openser.org/pipermail/users/2008-May/017388.html). The >>> natted client didn't get the RTP data, because it wasn't sent to the NAT >>> hole. It seems the solution is to remove the following line from the >>> rtpproxy code: >>> >>> asymmetric = (bmode != 0) ? 1 : 0; >>> >>> After recompiling everything works fine. Now I'm wondering why rtpproxy >>> assumes clients are asymmetric in bridging mode? Will I get problems >>> when running rtpproxy without above code line? >>> Also I think assuming asymmetric clients shouldn't be the default >>> behaviour. If clients are really asymmetric this can be set with the >>> "a"-flag in force_rtp_proxy(). But if clients are symmetric it can only >>> be fixed by changing the code. At least there should be a flag to force >>> rtpproxy to handle symmetric clients. Or am I missing the point? >>> >>> Thanks for your comments, >>> Christian -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com _______________________________________________ Users mailing list Users@rtpproxy.org http://lists.rtpproxy.org/mailman/listinfo/users
