I'm really starting to think that no amount of documentation will ever make this clear: FreeSWITCH default media mode: - RTP proxied by FreeSWITCH - FreeSWITCH controls codec negotiation - If endpoints agree on same codec, no transcoding is performed - All features enabled - recording, DTMF interception, etc, etc Proxy media mode: - RTP proxied by FreeSWITCH (c= modified, that's it) - FreeSWITCH has no control or even understanding of other SDP parameters (pass through) - Endpoints *MUST* agree on same codec because FreeSWITCH can't help them - Virtually no features available Bypass media mode: - RTP *NOT* proxied by FreeSWITCH - FreeSWITCH has no control over anything SDP related - it's completely pass through from one leg to next (including c=) - Endpoints must agree on same codec because FreeSWITCH doesn't even see the media or SDP - Virtually no features available On Fri, Apr 15, 2011 at 5:48 AM, Sam <u2nsam@gmail.com> wrote:
Hello,
AS freeswitch modifies SDP ( Media Description & Media Attributes) so is there any way to just bypass that process.
Regards Sam
On Thu, Apr 14, 2011 at 6:32 PM, Steven Ayre <steveayre@gmail.com> wrote:
I don't mean they're equivalent, because proxy_media has other sideaffects such as disabling many features.
I mean there are different better ways to avoid transcoding.
What you suggested with bridge should indeed avoid it. Without the absolute_codec_string the bleg would be offered all codecs supported by FS which may be more than supported by the caller, however with that setting it would only offer those supported by both the caller and FS. The callee will pick one it supports (or return 488 Not Acceptable Here). The aleg will then use the same codec as the bleg, so at that point both legs will be using the same codec so no transcoding will take place (unless you try using something like eavesdrop/record). You could then if you wanted handle the 488 Not Acceptable Here by redialing without absolute_codec_string to try again, this time the bleg could use a different codec than the aleg (transcoding).
-Steve
On 14 April 2011 13:28, Sergey Okhapkin <sos@sokhapkin.dyndns.org> wrote:
Do you mean
set proxy_media=true
is the equivalent of
set late_negotiation=true bridge {absolute_codec_string=${ep_codec_string}}blah
and transcoding will never happen?
On Thursday 14 April 2011, Steven Ayre wrote:
Proxy media is not required for 2 NAT clients to talk to each other.
Transcoding won't be used if both legs use the same codec, and you can use late-negotation/absolute_codec_string to encourage that.
-Steve
On 14 April 2011 11:22, Sergey Okhapkin <sos@sokhapkin.dyndns.org> wrote:
Proxy media is useful not for T38 only. It's a way for 2 NATed clients to communicate with each other if there are common codecs, no transcoding involved.
On Thursday 14 April 2011, Steven Ayre wrote:
You misunderstand I think... it *isn't* needed for T38 any longer. Only
in
very old versions.
-Steve
On 13 April 2011 23:17, Madovsky <infos@madovsky.org> wrote: > maybe change the param name to proxy_media_t38 ;) > > ----- Original Message ----- > From: "Kristian Kielhofner" <kris@kriskinc.com> > To: "FreeSWITCH Users Help" > <freeswitch-users@lists.freeswitch.org> > Sent: Wednesday, April 13, 2011 2:10 PM > Subject: Re: [Freeswitch-users] proxy SDP > > > Brian, > > For all of the confusion proxy media creates I still see cases > where > > it is useful... It shouldn't be removed completely. > > On Tue, Apr 12, 2011 at 8:55 PM, Brian West > <brian@freeswitch.org>
wrote:
> > We aren't a proxy... we have transcended into this quasi proxy > > in
some
> > scenarios which mostly involve t.38... as for proxy media DO > > NOT > > USE IT. Just saying it might go away since the purpose of it is > > now not needed since we have full t.38. > > > > Thanks, > > Brian > > -- > Kristian Kielhofner > > _______________________________________________ > FreeSWITCH-users mailing list > FreeSWITCH-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org > > > _______________________________________________ > FreeSWITCH-users mailing list > FreeSWITCH-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Kristian Kielhofner