Codec priority broken

[dmetech]

When selecting a codec priority list the PBX will not negotiate down the list.

An example is :
PBX extension 100 available codecs
G.711 u-law
G729

Phone SPA942 latest firmware 6.1.5(a)
G729
G711 u-law

all in and out calls will fail. it will not negitiate down the list of available codecs.
Same is true with an Aastra 57i.

[user469]

Apart from the g729 license , Giovanni has explained in a post that asterisk does not it very well .
It is better to use always the same available codecs on the most of the phones and or trunk .

[dmetech]

Yes I know about the g729 Lic.

The codec priority has been working long ago.
Elastix, Trixbox. PIAF can all do this.
Example is Asterisk 1.6.2.10, it works no problem.

I have never had a problem with this and it is quite an important feature, especially at the moment since we dont have any translation for asterisk sounds from ulaw to g729.

this means we can use g729 on a phone and trunk but cannot access voice mail or and feature codes and on hold music.

Another situation is being able to use g722 internally with is a high quality wideband codec (HD Codec) internally and use g729 on outgoing calls to save bandwith.

So what your saying is use u/alaw on the phone and trunk. I dont think many will have the bandwith to support 20 simultaneous calls on the upload.
Well, at least in Australia.

I think this is especially important in a office enviroment.

Dave.

[rrr]

I have the same problem with codec priority. The call will only be initiated if the first codec of one phone matches the first codec of the other phone.

When will this bug be fixed?

[giovanni.v]

PBX extension 100 available codecs
G.711 u-law
G729

Phone SPA942 latest firmware 6.1.5(a)
G729
G711 u-law

all in and out calls will fail. it will not negitiate down the list of available codecs.

Yes, sure will fail. That because asterisk will negotiate G.711 ulaw in the extension 100 call leg then will negotiate G.729 in the SPA942 call leg, this require G.711<->G.729 trascoding so the call can't be established if G.729 is not available in asterisk.

The codec priority has been working long ago.
Elastix, Trixbox. PIAF can all do this.
Example is Asterisk 1.6.2.10, it works no problem.

Hard to believe, no configuration can change the core asterisk features... using the exact same codec priorities above the call will contitue to fail everytime G.729 isn't available. What you're asking for is a typical SIP proxy feature but unfortunately Asterisk does not implement a proxy.

Not convinced yet? Here is a quote from a Digium developer (Kevin P. Fleming):

You are looking for a SIP proxy; Asterisk is not a SIP proxy, and no
amount of configuration will convince it to act like one.

Asterisk never “sends along” re-INVITEs, because the two channels
involved in an Asterisk “call” are distinct. If the codecs are
mismatched between the two call legs, Asterisk will try to transcode them.

The ‘directrtpsetup’ feature is still marked *experimental*, and that is
primarily because it defeats much of Asterisk’s normal behavior; in
addition, there a quite a few normal, working call scenarios for which
it will fail… so it’s there, but if you use it, you can expect
difficulties.