[Freeswitch-users] To Proxy Media or Not

[Max Clark]

Advantages of Proxy Media:

1) Support codecs not natively supported by FreeSWITCH
2) Lower CPU resources on FreeSWITCH

So for 1) I'm really only concerned with t38/fax over g711. With our
current configuration faxing (although unsupported) is working just
fine. What should I expect if I revert to media mode?

2) If I disable transcoding, what kind of difference in resource
utilization should I expect? Nominal (less than 10%), Moderate
(11-30%), or more?

Thanks,
Max

On Wed, Mar 9, 2011 at 9:02 AM, Kristian Kielhofner <kris at kriskinc.com> wrote:
> If your intention is to *strictly* hide topology proxy media will
> rewrite the IP address in the SDP but that's about it.  Technically
> that counts as "topology hiding".  Other SDP parameters, however, will
> pass through and leak various bits of information about the endpoints
> behind the SBC:
>
> - Codec support
> - Payload types
> - Other "random" various SDP parameters
>
> Most real SBCs will rewrite the entire SDP (as FS does by default).
>
> Another thing to consider - the vast majority of FS users do not use
> proxy media (and most that do use it incorrectly).  This leaves you
> open to the possibility that you'll experience strange edge case bugs
> using a media mode different from the majority of the rest of the FS
> user base.
>
> On Wed, Mar 9, 2011 at 10:52 AM, Max Clark <max.clark at gmail.com> wrote:
>> Hello,
>>
>> I have a couple of FreeSWITCH boxes functioning as SBCs on our
>> network. We need them to:
>>
>> - Route Calls
>> - Function as B2BUAs for call logging
>> - Hide topology from the endpoints
>>
>> They do not need to:
>>
>> - Intercept/play audio
>> - Manipulate the SDP
>> - Transcode
>> - Process anything other than SIP
>>
>> So these machines have been running with Proxy Media enabled in the
>> dialplan. Is the the proper/recommended way of configuring for our
>> environment/needs? Is the minimal gain of resources by not processing
>> the RTP worth it?
>>
>> Thanks,
>> Max
>
>
>
> --
> Kristian Kielhofner
>