Re: [sr-dev] [SR-Users] rtpproxy (k): removal of force_rtpproxy

force_rtp_proxy does not handle properly 200ok/ACK renegotiation (the s flag is obsolete). I am using offer/answer (the new rtpproxy module) in bridging mode without any issues. Migrating from force_rtp_proxy to offer/answer model is quite straight forward. Maintaing both force rtp and ofer/answer is just extra work load (given the fact that both are just wrappers around a single function). I would go for a clean layout ... but ... Vox Populi, Vox Dei :)

Regards, Ovidiu Sas On Tue, Sep 21, 2010 at 11:32 AM, Alex Balashov <abalashov(a)evaristesys.com> wrote: > On 09/21/2010 11:27 AM, Daniel-Constantin Mierla wrote: > >> personally I haven't tested much those functions. Maybe is better for >> now to mark it obsolete and add a warning message at startup (via >> fixup), then remove it with next release, allowing some maturity tests >> for new ones. I am saying that also because most of existing configs >> out there are using this function and new people will look for it. > I agree. > > All of our configs use force_rtp_proxy(), but I would be happy to migrate > them; however, I need some reasonable assurance that > rtpproxy_offer/answer() will actually work. > > As can be seen from a number of previous threads on the list, I had to call > force_rtp_proxy() to get several common scenarios to work, even though > supposedly rtpproxy_offer/answer() are just wrappers (the code would suggest > that), and even though the 'nathelper' documentation says that supposedly > they will accept and use the same flags as those listed for > force_rtp_proxy() the same way. It has not been true in my experience. > > -- > Alex Balashov - Principal > Evariste Systems LLC > 1170 Peachtree Street > 12th Floor, Suite 1200 > Atlanta, GA 30309 > Tel: +1-678-954-0670 > Fax: +1-404-961-1892 > Web: http://www.evaristesys.com/ >