[Freeswitch-users] Possible to disable core codecs?
Malay Thakershi
mthakershi at gmail.com
Fri Apr 13 04:20:01 MSD 2012
Thanks.
Before I do what you said, I have another problem. Sorry about that.
I use different mechanism to make outgoing calls (originate calls from
ESL). So I do not use bridge.
I tried to put "{absolute_codec_string=GSM}" in originate call along
with other parameters I pass but it throws error.
My originate call looks like:
originate {absolute_codec_string=GSM,ignore_early_media=true,origination_caller_id_name=CH,origination_caller_id_number=1877XXXXXXX,originate_timeout=45,chivr_outbound=true,other_var=1}sofia/gateway/vitelity-outbound/1972XXXXXXX
1056 XML default
Error thrown on the log: -ERR INCOMPATIBLE_DESTINATION
2012-04-12 19:14:01.589739 [NOTICE] sofia.c:6332 Hangup
sofia/sipinterface_1/1972XXXXXXX [CS_CONSUME_MEDIA]
[INCOMPATIBLE_DESTINATION]
Call without absolute_codec_string works fine.
The way this works is: call gets originated -- it goes to default dial
plan extension 1056 -- mod_managed is called from this point to handle
call flow.
<extension name="CH1">
<!-- Calls from public.xml will come with 1056 extension and will
be handled here -->
<condition field="destination_number" expression="^1056$">
<!-- codec trial setting -->
<!-- <action application="set" data="absolute_codec_string=GSM"/> -->
<!-- <action application="log" data="codec debug: codec_string is
${codec_string}" />
<action application="log" data="codec debug: originator_codec is
${originator_codec}" />
<action application="log" data="codec debug: absolute_codec_string
is ${absolute_codec_string}" />
-->
<action application="sleep" data="1000" />
<action application="managed" data="clsAsmtApp" />
</condition>
</extension>
As you can see, I tried setting absolute string from here too but it
didn't work.
Let me know what can be done if you can.
Thanks.
Malay
On Wed, Apr 11, 2012 at 5:48 PM, Vitalie Colosov <vetali100 at gmail.com> wrote:
> Lets forget for a minute about vars.xml and what is there (when you use
> absolute_codec_string=GSM, it overrides any settings from vars.xml), and
> concentrate at the OUTGOING call from FreeSWITCH to your sip provider first.
>
> Try to change your bridge to the following string:
> <action application="bridge">
> data="{absolute_codec_string=GSM}sofia/gateway/your_provider/12345678901_example"/>
>
> (obviously use your sip provider and phone number :)
>
> And do one outgoing call to this sip provider.
>
> Then, reply back whether the call was successful or not (did you hear the
> voice and whether the other party did hear you). And paste the log to the
> pastebin (http://pastebin.freeswitch.org/) and reply back with the link.
>
>
>
>
>
> 2012/4/11 Malay Thakershi <mthakershi at gmail.com>
>>
>> > 1.You need OUTGOING leg to use GSM codec, right? (You wont be able to
>> > use
>> > G729 right now as it needs the license). By OUTGOING I mean call from
>> > FreeSWITCH to your provider, and not back.
>> Yes. I want to try some codec that will use less bandwidth and see how
>> much audio quality is compromised. So I chose GSM because G729 has
>> license requirements.
>>
>> I want this to work when someone calls my DID or my FS program calls
>> someone via DID. So both for incoming calls as well as outgoing calls.
>>
>> > 2. If #1 is true, then inbound-codec-negotiation is not much useful at
>> > this point. Because this setting is for INCOMING leg, and not for
>> > OUTGOING. And even if it _might_ be using GSM for INCOMING leg, but
>> > still
>> > transcode to the OUTGOING PCMA/PCMU by some reason (this is what we need
>> > to
>> > find out - why).
>> I am not very familiar with internals of FS so having lot of trouble
>> figuring this out.
>>
>> Weird thing is, even if I do not have any mention of G729, it is being
>> negotiated and used. Here are my configuration lines:
>> vars.xml
>> <X-PRE-PROCESS cmd="set" data="global_codec_prefs=GSM,PCMU,PCMA"/>
>> <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=GSM,PCMU,PCMA"/>
>>
>> sip profile has:
>> <param name="inbound-codec-negotiation" value="greedy"/>
>>
>> dial plan
>> <extension name="CH">
>> <condition field="destination_number" expression="^105\d$">
>> <action application="set"
>> data="absolute_codec_string=GSM"/>
>> <action application="sleep" data="1000"/>
>> <action application="managed" data="clsAsmtApp"/>
>> </condition>
>> </extension>
>>
>>
>> <extension name="vitel-outbound">
>> <condition field="destination_number" expression="^(1{0,1}\d{10})$">
>> <action application="set" data="absolute_codec_string=GSM"/>
>> <action application="set"
>> data="effective_caller_id_number=18770001111"/>
>> <action application="bridge"
>> data="sofia/gateway/vitelity-outbound/$1"/>
>> </condition>
>> </extension>
>>
>> > 3. Try using absolute_codec_string before bridging your call to your SIP
>> > provider:
>> >
>> > <action application="set" data="absolute_codec_string=GSM"/>
>> > <action application="bridge"
>> > data="sofia/gateway/your_provider/12345678901_example"/>
>> >
>> I did as you said. But found what I described above. If I remove
>> "greedy" setting, system simply uses PCMU codec like before.
>>
>> This thing is so confusing. Even my SIP provider is saying they can't
>> help out with FS because some guy quit who knew the configurations.
>>
>> Thanks for help.
>>
>> On Wed, Apr 11, 2012 at 4:12 PM, Vitalie Colosov <vetali100 at gmail.com>
>> wrote:
>> >
>> > Lets confirm the following statements now:
>> >
>> > 1.You need OUTGOING leg to use GSM codec, right? (You wont be able to
>> > use
>> > G729 right now as it needs the license). By OUTGOING I mean call from
>> > FreeSWITCH to your provider, and not back.
>> >
>> > 2. If #1 is true, then inbound-codec-negotiation is not much useful at
>> > this point. Because this setting is for INCOMING leg, and not for
>> > OUTGOING. And even if it _might_ be using GSM for INCOMING leg, but
>> > still
>> > transcode to the OUTGOING PCMA/PCMU by some reason (this is what we need
>> > to
>> > find out - why).
>> >
>> > 3. Try using absolute_codec_string before bridging your call to your SIP
>> > provider:
>> >
>> > <action application="set" data="absolute_codec_string=GSM"/>
>> > <action application="bridge"
>> > data="sofia/gateway/your_provider/12345678901_example"/>
>> >
>> >
>> > And reply back if this changes anything...
>> >
>> > Vitalie
>> >
>> > 2012/4/11 Malay Thakershi <mthakershi at gmail.com>
>> >>
>> >> Under my sipinterface_1 profile that I use for these calls, I have:
>> >>
>> >> <param name="inbound-codec-negotiation" value="greedy"/>
>> >>
>> >> On Wed, Apr 11, 2012 at 1:43 PM, Bzzz <lazyvirus at gmx.com> wrote:
>> >>>
>> >>> On Wed, 11 Apr 2012 13:31:45 -0500
>> >>> Malay Thakershi <mthakershi at gmail.com> wrote:
>> >>>
>> >>> > Understood your point about G722. But if my list has GSM at higher
>> >>> > priority
>> >>> > over PCMU/PCMA and far-end SDP supports GSM then why isn't the call
>> >>> > using
>> >>> > GSM?
>> >>> >
>> >>> > I don't know where G726 comparisons are coming from. If I haven't
>> >>> > mentioned
>> >>> > it in vars.xml and far-end SDP doesn't support it then why would it
>> >>> > even
>> >>> > consider that codec?
>> >>>
>> >>> From: wiki.freeswitch.org/wiki/Sofia_Configuration_Files
>> >>> (inbound-codec-negotiation):
>> >>> 'generous' permits the remote codec list have precedence and 'win'
>> >>> the codec negotiation and selection process
>> >>>
>> >>> JY
>> >>> --
>> >>> Don't drop acid -- take it pass/fail.
>> >>> -- Seen in a Ladies' Room at Harvard
>> >>>
>> >>>
>> >>>
>> >>> _________________________________________________________________________
>> >>> Professional FreeSWITCH Consulting Services:
>> >>> consulting at freeswitch.org
>> >>> http://www.freeswitchsolutions.com
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> Official FreeSWITCH Sites
>> >>> http://www.freeswitch.org
>> >>> http://wiki.freeswitch.org
>> >>> http://www.cluecon.com
>> >>>
>> >>> FreeSWITCH-users mailing list
>> >>> FreeSWITCH-users at lists.freeswitch.org
>> >>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> >>>
>> >>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> >>> http://www.freeswitch.org
>> >>
>> >>
>> >>
>> >>
>> >> _________________________________________________________________________
>> >> Professional FreeSWITCH Consulting Services:
>> >> consulting at freeswitch.org
>> >> http://www.freeswitchsolutions.com
>> >>
>> >>
>> >>
>> >>
>> >> Official FreeSWITCH Sites
>> >> http://www.freeswitch.org
>> >> http://wiki.freeswitch.org
>> >> http://www.cluecon.com
>> >>
>> >> FreeSWITCH-users mailing list
>> >> FreeSWITCH-users at lists.freeswitch.org
>> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> >>
>> >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> >> http://www.freeswitch.org
>> >>
>> >
>> >
>> >
>> > _________________________________________________________________________
>> > Professional FreeSWITCH Consulting Services:
>> > consulting at freeswitch.org
>> > http://www.freeswitchsolutions.com
>> >
>> >
>> >
>> >
>> > Official FreeSWITCH Sites
>> > http://www.freeswitch.org
>> > http://wiki.freeswitch.org
>> > http://www.cluecon.com
>> >
>> > FreeSWITCH-users mailing list
>> > FreeSWITCH-users at lists.freeswitch.org
>> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> > http://www.freeswitch.org
>> >
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>>
>>
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
>
>
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users
mailing list