[Freeswitch-users] Outbound codecs preference

Wed Aug 25 10:58:02 PDT 2010

2010/8/25 David Ponzone <david.ponzone at ipeva.fr>

> Juan,
>
> I see your issue now.
>
> Well, first solution is to only send to the provider the codec you want.
> If you prefer G729 for a phone, it's likely the provider will support that,
> so offer only G729.
> If you prefer PCM for another phone, it's likely the provider will support
> that, so offer only PCM.
>

I think a parameter may be called 'outbound-codec-negotiation' would be a
better solution. This way, when you will offer several codecs to the
provider and the provider offer several codecs to you, you could set that
your codec preferences have higher priority than the providers' as done with
inbound calls.

>
> The strange thing, but I guess it depends, is that your provider sends you
> back several codecs (is that even acceptable ?).
> When I sent them a list of codecs, my providers always replies with only
> one, the one they want, generally it's the first one in the list I offered.
>

I suppose similar we offer several codecs to our registered ip phones.

> It seems your provider is trying to refuse your preference, which is not
> very nice.
> I don't think there is any other way than offering them only the codec you
> want.
>
> David Ponzone  Direction Technique
> email: david.ponzone at ipeva.fr
> tel:      01 74 03 18 97
> gsm:   06 66 98 76 34
>
> Service Client IPeva
> tel:      0811 46 26 26
> www.ipeva.fr  -   www.ipeva-studio.com
>
> *Ce message et toutes les pièces jointes sont confidentiels et établis à
> l'intention exclusive de ses destinataires. Toute utilisation ou diffusion
> non autorisée est interdite. Tout message électronique est susceptible
> d'altération. **IPeva** décline toute responsabilité au titre de ce
> message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas
> destinataire de ce message, merci de le détruire immédiatement et d'avertir
> l'expéditeur.*
> *
> *
>
>
>
> Le 25/08/2010 à 17:45, Juan Antonio Ibañez Santorum a écrit :
>
> It applies to inboud leg forcing not outbound. Tested and call fails :(
>
> 2010/8/25 David Ponzone <david.ponzone at ipeva.fr>
>
>> Try:
>>
>> <param name="inbound-codec-negotiation" value="greedy"/>
>>
>>
>>  David Ponzone  Direction Technique
>> email: david.ponzone at ipeva.fr
>> tel:      01 74 03 18 97
>> gsm:   06 66 98 76 34
>>
>> Service Client IPeva
>> tel:      0811 46 26 26
>> www.ipeva.fr  -   www.ipeva-studio.com
>>
>> *Ce message et toutes les pièces jointes sont confidentiels et établis à
>> l'intention exclusive de ses destinataires. Toute utilisation ou diffusion
>> non autorisée est interdite. Tout message électronique est susceptible
>> d'altération. **IPeva** décline toute responsabilité au titre de ce
>> message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas
>> destinataire de ce message, merci de le détruire immédiatement et d'avertir
>> l'expéditeur.*
>> *
>> *
>>
>>
>>
>> Le 25/08/2010 à 17:02, Juan Antonio Ibañez Santorum a écrit :
>>
>> It doesn't worked as I thought. I'd like caller codecs priority has
>> preferente over provider codecs preference:
>>
>> Now, doing inbound late negotiation and adding code you suggest:
>>
>> IP phone offers:
>>    G729,PCMA (${ep_codec_string}= G729 at 8000h,PCMA at 8000h)
>>
>> FS codecs prefs:
>>   global_codec_prefs=G729,G7221 at 32000h,G7221 at 16000h,G722,PCMU,PCMA,GSM"
>>   outbound_codec_prefs=G729,PCMU,PCMA,GSM
>>
>> Provider offers:
>>    PCMU,PCMA,G729
>>
>> Doing above config FS selects PCMA instead G729.
>> Disabling inboud-late-negotiation FS select G729 for A-leg and PCMU for
>> B-leg hanging up the call because there is no g729 licenses installed. It
>> could use G729 not dropping the call...
>>
>> Regards
>>
>>
>> 2010/8/25 David Ponzone <david.ponzone at ipeva.fr>
>>
>>> The best way is probably to use inbound-late-negotiation, and in the
>>> dialplan before bridging to add:
>>>        <action application="export"
>>> data="absolute_codec_string=${ep_codec_string}" />
>>>        <action application="set" data="inherit_codec=true" />
>>>
>>>  David Ponzone  Direction Technique
>>> email: david.ponzone at ipeva.fr
>>> tel:      01 74 03 18 97
>>> gsm:   06 66 98 76 34
>>>
>>> Service Client IPeva
>>> tel:      0811 46 26 26
>>> www.ipeva.fr  -   www.ipeva-studio.com
>>>
>>> *Ce message et toutes les pièces jointes sont confidentiels et établis à
>>> l'intention exclusive de ses destinataires. Toute utilisation ou diffusion
>>> non autorisée est interdite. Tout message électronique est susceptible
>>> d'altération. **IPeva** décline toute responsabilité au titre de ce
>>> message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas
>>> destinataire de ce message, merci de le détruire immédiatement et d'avertir
>>> l'expéditeur.*
>>> *
>>> *
>>>
>>>
>>>
>>> Le 24/08/2010 à 20:00, Juan Antonio Ibañez Santorum a écrit :
>>>
>>> I can see when I try to stablish one B-leg call FS gives more precedence
>>> to remote codecs order. This way it is difficult to avoid transcoding in
>>> some situations where it could be possible. Is there any way to get a
>>> behaviour similar inbound-codec-negotiation=greedy for outbounds calls? What
>>> would be the best way to avoid transcoding? May be to use
>>> inbound-late-negotiation and rewrite codecs strings?
>>>
>>> Regards
>>> _______________________________________________
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>> _______________________________________________
>> 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
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> 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/20100825/3c920b82/attachment-0001.html 