[Freeswitch-users] Possible to disable core codecs?

Thu Apr 12 02:48:45 MSD 2012

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20120411/c7a45a7f/attachment-0001.html 