Hi,
In my situation I just want to use two codecs (G729 and ulaw).
There are 6 extensions that can speak G729 and ulaw, one needs to speak in G729 only because it is places far away (other continent).
I am using Asterisk 1.4.35-rc1-BRIstuffed-0.4.0-RC7 and right now I just forced all the extensions to speak in G729.
Obvious this is not what I want; What are general guides to set this up correct so G729 only is used on calling with the only extension that needs it. In all other cases alle the extensions can talk ulaw.
I think an extra factor that makes it complex; I have a mix of SIP and asterisk extensions.
Please, some guidelines are welcome…
Maarten
You need to allow: ulaw, G729 - for all, except oversee - there you can allow G729.
Thanks for your reply…
One of them is SIP the other IAX.
SIP side:
canreinvite=no
disallow=all
allow=ulaw
allow=g729
IAX side:
disallow=all
allow=g729
I have the following behavious.
calling from IAX to SIP = good call, nicely in G729
calling from SIP to IAX = aborted call with the following messages.
[quote][Aug 22 21:24:17] WARNING[29641] channel.c: Unable to find a codec translation path from 0x100 (g729) to 0x4 (ulaw)
[Aug 22 21:24:17] WARNING[29641] channel.c: Unable to find a codec translation path from 0x100 (g729) to 0x4 (ulaw)
[Aug 22 21:24:31] WARNING[30205] chan_iax2.c: Unable to create translator path for g729 to ulaw on IAX2/3008-3936
[Aug 22 21:24:31] WARNING[30205] app_dial.c: Unable to create channel of type ‘IAX2’ (cause 0 - Unknown)
[/quote]
It seems that it wants to transcode, even if there is technically no need is for trancoding.
So, wrapping up, bounding them both to G729, there’s no problem. But giving one out of two another option (ULAW) doesnt make asterisk to select the codec both extensions fit, no it just want to transcode?
In theory, they should negotiate codec - not sure if it need some additional setting.
By the way - what is wrong if all extensions use G729?
Unfortunately - I never had SIP/IAX with “different” codecs.
I think - you can plane upgrade - may be this problem is solved in next versions. Or try to use at least only SIP, of course - you can get some G729 license voip-info.org/wiki/view/Aste … +Licensing
[quote=“bira_more”]In theory, they should negotiate codec - not sure if it need some additional setting.
By the way - what is wrong if all extensions use G729?
Unfortunately - I never had SIP/IAX with “different” codecs.
I think - you can plane upgrade - may be this problem is solved in next versions. Or try to use at least only SIP, of course - you can get some G729 license voip-info.org/wiki/view/Aste … +Licensing[/quote]
Using G927 does not work well with Skype for Asterisk, also I have DID in other countries and sometimes I cannot call certain numbers and certain number cannot call me on the DID and I am suspecting that G729 is not allways supported. That is why I want to have two common codecs, G729 (native) and where possible ulaw, also native.
I use IAX on two remote locations, simply because it is more convenient in relation to NAT en firewalling.
At the main location I use Nortel and Cisco IP phones, which are SIP.
Of course I am not a programmer, but why a mechanism that makes a simple table during call setup about the codec capabilities and preferences from both sides and then simply select the best option for both sides, it doesnt looks rocket sience to me… 
IAX is primarily done for communication between 2 asterisk servers. It has many benefits in such situation. SIP - is “other beer”. And two protocols have different priorities…
Yes - it should not be “rocket science” negotiation of codecs between sip and iax, but if this is rare situation, it could be missed from developers. I mean they just could miss this bug, this is why I think about upgrade.
Long ago we spent long time fixing reverse polarity, and just we fixed - there came upgrade with fixed reverse polarity 
Your version is old, and that problem could be fixed in newer ones.
1.4.35 is the current 1.4 branch, which is a supported branch.
1.4.35-rc1 is probably the same except for the version string, as there is no -rc2. Nonetheless, people should not be packaging -rc* versions for use by normal users.
This bit - -BRIstuffed-0.4.0-RC7 - suggests an unofficial release by a third party, and strictly speaking support requests should go through that third party, as only they know how they have patched the code.
I am going to consider upgrading to a newer version, right now I am thinking about the current asterisknow version, because its an complete ditro.
It will also involve upgrading my HW, cuz I dont thing my small embedded box running with AMD Geode @500MHz and 2GB CF card is going to support it… 
However, have used it for some years with full satisfaction.
Thanks for your help.