Codec negotiation to avoid transcoding as much as possible
Hi All, Is there a way to configure Freeswitch codec negotiation to be neither of 'generous', 'greedy' or 'scrooge', but keep the possibilities of needing transcoding open. This is what I'm seeing with 'generous' codec negotiation (greedy and scrooge is no different): inbound leg offer (opus, pcmu, g729) --> FS --> outbound leg offer (opus, pcmu) inbound leg answer (opus) <-- FS (transcoding engaged) <-- outbound leg answer (pcmu) But, I want FS to not to do transcoding here as there is a way out as both caller and called party has pcmu in common. If FS can follow this, there is no transcoding needed on FS's part: inbound leg offer (opus, pcmu, g729) --> FS --> outbound leg offer (opus, pcmu) inbound leg answer (pcmu) <-- FS <-- outbound leg answer (pcmu) Question is how can I configure FS to be 'accomodat'-ing (yes, i wish this codec negotiation option is available). Please share your insights. -- Thanks, Dipak
Just want to add that I have the config <action application="set" data="inherit_codec=true"/> before bridging in dialplan. And, also have the inbound-late-negotiation=true. But, I'm not getting the desired result. Thanks, Dipak On Thu, Feb 20, 2014 at 11:24 AM, Biswas, Dipak <dipak.biswas@mezocliq.com>wrote:
Hi All,
Is there a way to configure Freeswitch codec negotiation to be neither of 'generous', 'greedy' or 'scrooge', but keep the possibilities of needing transcoding open.
This is what I'm seeing with 'generous' codec negotiation (greedy and scrooge is no different):
inbound leg offer (opus, pcmu, g729) --> FS --> outbound leg offer (opus, pcmu) inbound leg answer (opus) <-- FS (transcoding engaged) <-- outbound leg answer (pcmu)
But, I want FS to not to do transcoding here as there is a way out as both caller and called party has pcmu in common.
If FS can follow this, there is no transcoding needed on FS's part:
inbound leg offer (opus, pcmu, g729) --> FS --> outbound leg offer (opus, pcmu) inbound leg answer (pcmu) <-- FS <-- outbound leg answer (pcmu)
Question is how can I configure FS to be 'accomodat'-ing (yes, i wish this codec negotiation option is available).
Please share your insights.
-- Thanks, Dipak
-- Thanks, Dipak
Try removing inherit_codec and see what happens. Assuming that both clients offer the codecs in the order that you listed them, it should work. Is this call being made within the same profile? On 2014-02-21 04:53, Biswas, Dipak wrote:
Just want to add that I have the config <action application="set" data="inherit_codec=true"/> before bridging in dialplan. And, also have the inbound-late-negotiation=true.
But, I'm not getting the desired result.
Thanks, Dipak
On Thu, Feb 20, 2014 at 11:24 AM, Biswas, Dipak <dipak.biswas@mezocliq.com> wrote:
Hi All,
Is there a way to configure Freeswitch codec negotiation to be neither of 'generous', 'greedy' or 'scrooge', but keep the possibilities of needing transcoding open.
This is what I'm seeing with 'generous' codec negotiation (greedy and scrooge is no different):
inbound leg offer (opus, pcmu, g729) --> FS --> outbound leg offer (opus, pcmu)
inbound leg answer (opus) <-- FS (transcoding engaged) <-- outbound leg answer (pcmu)
But, I want FS to not to do transcoding here as there is a way out as both caller and called party has pcmu in common.
If FS can follow this, there is no transcoding needed on FS's part:
inbound leg offer (opus, pcmu, g729) --> FS --> outbound leg offer (opus, pcmu)
inbound leg answer (pcmu) <-- FS <-- outbound leg answer (pcmu)
Question is how can I configure FS to be 'accomodat'-ing (yes, i wish this codec negotiation option is available).
Please share your insights. --
Thanks, Dipak
--
Thanks, Dipak
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com [1]
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com [2]
Official FreeSWITCH Sites http://www.freeswitch.org [3] http://wiki.freeswitch.org [4] http://www.cluecon.com [5]
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users [6] UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users [7] http://www.freeswitch.org [3]
Links: ------ [1] http://www.freeswitchsolutions.com [2] http://www.cudatel.com [3] http://www.freeswitch.org [4] http://wiki.freeswitch.org [5] http://www.cluecon.com [6] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users [7] http://lists.freeswitch.org/mailman/options/freeswitch-users
Dipak, If you’re using FS from the dev repo on GIT and installed it at some point between mid December and mid February, run a make current. The issue you are experiencing is a little regression bug that Tony solved a few days ago. Thanks On Feb 20, 2014, at 12:53 PM, Biswas, Dipak <dipak.biswas@mezocliq.com> wrote:
Just want to add that I have the config <action application="set" data="inherit_codec=true"/> before bridging in dialplan. And, also have the inbound-late-negotiation=true.
But, I'm not getting the desired result.
Thanks, Dipak
On Thu, Feb 20, 2014 at 11:24 AM, Biswas, Dipak <dipak.biswas@mezocliq.com> wrote: Hi All,
Is there a way to configure Freeswitch codec negotiation to be neither of 'generous', 'greedy' or 'scrooge', but keep the possibilities of needing transcoding open.
This is what I'm seeing with 'generous' codec negotiation (greedy and scrooge is no different):
inbound leg offer (opus, pcmu, g729) --> FS --> outbound leg offer (opus, pcmu) inbound leg answer (opus) <-- FS (transcoding engaged) <-- outbound leg answer (pcmu)
But, I want FS to not to do transcoding here as there is a way out as both caller and called party has pcmu in common.
If FS can follow this, there is no transcoding needed on FS's part:
inbound leg offer (opus, pcmu, g729) --> FS --> outbound leg offer (opus, pcmu) inbound leg answer (pcmu) <-- FS <-- outbound leg answer (pcmu)
Question is how can I configure FS to be 'accomodat'-ing (yes, i wish this codec negotiation option is available).
Please share your insights.
-- Thanks, Dipak
-- Thanks, Dipak _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
participants (3)
-
Biswas, Dipak
-
Emrah
-
Francis