[Freeswitch-users] Possible to disable core codecs?
Malay Thakershi
mthakershi at gmail.com
Fri Apr 13 09:39:54 MSD 2012
When I do "sofia global siptrace on", my console just doesn't stop. I
get text so fast, I can't even paste the originate command. So I can't
produce what will hep you help me on this.
Is there a way I can divert the whole thing to a text file?
Thanks.
Malay
On Thu, Apr 12, 2012 at 10:55 PM, Vitalie Colosov <vetali100 at gmail.com> wrote:
> 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
>
>
>
> _________________________________________________________________________
> 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