[Freeswitch-users] Possible to disable core codecs?

Vitalie Colosov vetali100 at gmail.com
Fri Apr 13 07:55:00 MSD 2012


Could you collect the full siptrace of one call and paste into pastebin?

To do so, type at the cli:

       sofia global siptrace on

Then make 1 call and collect whatever you got at the screen, and paste into
pastebin.

Then, you'll probably want to disable siptrace:

        sofia global siptrace off

Regards,
Vitalie


2012/4/12 Malay Thakershi <mthakershi at gmail.com>

> 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
> >
>
> _________________________________________________________________________
> 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/20120412/5c4ef4d3/attachment-0001.html 


Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users mailing list