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

[Daniel-Constantin Mierla]

On 9/21/10 5:42 PM, Ovidiu Sas wrote:
> 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 :)
Good to know that you tested and you are probably right regarding the code.

There won't be more load if we remove with next version -- as now we are 
in testing phase, once 3.1 is released, we can drop it from master branch.

I will look over it and push it with default config in 3.1 -- somehow I 
missed the fact that 's' was deprecated, because I never used it :-)

Cheers,
Daniel

>
> Regards,
> Ovidiu Sas
>
> On Tue, Sep 21, 2010 at 11:32 AM, Alex Balashov
> <abalashov at 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/
>>

-- 
Daniel-Constantin Mierla
http://www.asipto.com