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@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@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@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@gmx.com> wrote:
>>>
>>> On Wed, 11 Apr 2012 13:31:45 -0500
>>> Malay Thakershi <mthakershi@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@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
>>
>>
>>
>> _________________________________________________________________________
>> 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
>>
>
>
> _________________________________________________________________________
> 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
>

_________________________________________________________________________
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