[Freeswitch-users] Codec Negotiation Help

[Spencer Thomason]

After some testing,
A little clarification on the matter...

[DEBUG] switch_ivr_originate.c:404 Codec string PCMU at 8000h@20i not supported on sofia/internal/5000 at pbx.myserver.com, skipping inheritance

So.. If the codec isn't supported Freeswitch transcodes :-)  You guys rock, who knew something could actually make sense.

Spencer


On May 26, 2011, at 4:20 PM, Spencer Thomason wrote:

> That's what I was thinking.  I don't actually have any devices like this but a few of our phones do support iLBC and we have be toying with the idea of using that on a few links that are slower.  Is there any option to setting inherit_codec=true that would "fall back" to transcoding if need be?
> 
> Spencer
> 
> 
> On May 26, 2011, at 4:05 PM, Michael Collins wrote:
> 
>> I believe in the scenario you describe that the call would fail since the incoming call cannot inherit the only codec supported by the b leg device (GSM).
>> 
>> -MC
>> 
>> On Thu, May 26, 2011 at 10:56 AM, Spencer Thomason <spencer at 5ninesolutions.com> wrote:
>> Thanks for you help, I'll try that.  So I'm a little confused with the negotiation process with two profiles.  Lets say for  example that I have a device that only supports GSM on the internal profile and a call comes in on the external profile as ULAW, G729.  If I set  would Freeswitch then transcode?  How does the disable-transcoding option work in regards to two profiles?  I.e. Only one profile has transcoding disabled but a call traverses both of them.. (2 legs, one bridge).  Which profile would the transcoding need to be enabled (or not disabled rather)?
>> 
>> Thanks,
>> Spencer
>> 
>> 
>> On May 26, 2011, at 11:47 AM, DJB International wrote:
>> 
>>> Your profile has late negotion enabled.  I believe you can set inherit_codec=true, so that it will force A leg to use the same codec as B leg offered.
>>> 
>>> 
>>> On Thu, May 26, 2011 at 9:04 AM, Spencer Thomason <spencer at 5ninesolutions.com> wrote:
>>> Hello all,
>>> I have a problem regarding the codec negotiation on an outbound call.  My setup is like this:
>>> 
>>> Polycom IP 650 (1-n) -NAT-> FS  --> Our Signaling Proxy --> ITSP Proxy ---> ITSP Cisco GW
>>> 
>>> I'd like to use different codecs for different call paths (in order of pref), g729 in passthru only:
>>> IP-650         ->  IP-650   G722, PCMU, G729
>>> Inbound      ->  IP-650   PCMU
>>> IP-650         ->  Outbound PCMU,G729
>>> 
>>> I have two sofia profiles, internal, public IPv4:5060 and external, public:IPv4:5080.
>>> 
>>> The phones use the internal profile and the external profile only communicates with our signaling proxy (no media proxy).
>>> On the internal one:
>>> CODECS IN               G722,PCMU,G729,GSM
>>> CODECS OUT              G722,PCMU,G729,GSM
>>> NOMEDIA                 false
>>> LATE-NEG                true
>>> 
>>> External:
>>> CODECS IN               PCMU,G729
>>> CODECS OUT              PCMU,G729
>>> NOMEDIA                 false
>>> LATE-NEG                true
>>> 
>>> I have inbound-codec-negotiation set to greedy on both profiles and on outbound calls set absolute_codec_string=PCMU,G729 to prevent transcoding.  Note that mod_g729 is enabled for passthru only.
>>> 
>>> The problem I have is this:
>>> We use the dynamic routing module in OpenSIPS to select an outbound provider/GW, all support PCMU and G729.  On one of the routes, the Cisco IOS GW on this route has G729, PCMU configured as its codec pref.
>>> 
>>> I have included a ladder diagram to better illustrate the problem but in a nutshell, the polycom negotiates PCMU with FS, FS asks for both PCMU and G729, the cisco GW sends G729 and FS sends a 488 because it can't transcode.  I would like to keep G729 in the outbound prefs because some routes might not support PCMU.  Should I set one of the profiles to generous, and if so which one?
>>> 
>>> When someone makes an outbound call the following happens (ladder diagram):
>>> http://pastebin.freeswitch.org/16380
>>> 
>>> 
>>> Sorry for the novella, :-)
>>> 
>>> Thanks!
>>> Spencer
>>> 
>>> 
>>> _______________________________________________
>>> 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/20110527/7505c610/attachment.html