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

Ovidiu Sas osas at voipembedded.com
Tue Sep 21 17:42:41 CEST 2010


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 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/
>



More information about the sr-dev mailing list