Codec order

Status
Not open for further replies.

datamerge

Gold Partner
Advanced Certified
Joined
Nov 19, 2014
Messages
213
Reaction score
46
Hi all

I am doing some testing with PBXEdition via AWS. My handsets have codec order of G711u, G711A, G722, G729.

I notice when I call between extensions, the PBX transcodes the RTP. No matter what the sending handset requests, the PBX calls the B party with a set of codecs that are ordered GSM,G729,G722, G711u,G711a.

I don't want the primary codec to be one of these compressed codecs, but I can't find a codec list definition for the PBX when it initiates a call as it does when it wants to transcode. There must be an ability to change this somewhere, mustn't there?
 
If it is device to device, then the order is selected (set) in those devices, this can be by a configuration file, or manually. If it is a trunk to a provider, then in the trunk settings. I believe that the initiating device will "suggest" the Codec to use based on it's internal list (order), if match is found, that is the one used.
 
  • Like
Reactions: datamerge
When it is transcoding which it will always do when the PBX is "in the cloud", it ignores the codec order offered by the originating handset (and what is configured as the codec order for the destination handset. Wireshark traces clearly show the INVITE to the desitination handset with an order that is not configured anywhere on the PBX. We end up with (in this case) a g711u call between the originating handset and the PBX and a G729 call between the PBX and the destination handset.
 
Not certain as to why it is transcoding. That should not happen unless the destination does not support one of the codecs that the originator offers. It uses a lot of resources. Are you forcing "PBX delivers audio"? In an "ideal" scenario, the call will be set-up and the handsets "instructed" to connect with each other directly. Given that your PBX is "in the cloud", what sort of set-up do you have at the remote end? Are the sets, all at one location, behind an SBC, using VPN, or simply behind a router?
 
Thanks Lee.

It is transcoding as the two phones are behind NAT to a remote server. I am not concerned about why it is transcoding. I expect it to in this instance. What I want to be able to do is configure a codec order when it DOES transcode. It appears that the PBX does not use the destination handset's codec order. From what I read in the documentation, the PBX should use the codec order of the extension as defined in options to call that handset. I fully understand how all this works. I am aware that if it was a direct non-transcoded call that the codec order specified by the calling handset would be passed through to the destination handset as is.
 
When it is transcoding which it will always do when the PBX is "in the cloud", it ignores the codec order offered by the originating handset (and what is configured as the codec order for the destination handset. Wireshark traces clearly show the INVITE to the desitination handset with an order that is not configured anywhere on the PBX. We end up with (in this case) a g711u call between the originating handset and the PBX and a G729 call between the PBX and the destination handset.
I noticed this too the other day when playing around. Was with grandstream phones I noticed. I corrected the issue by setting only g711u as the only codec and then it uses it. Otherwise it seems to always want g729 on the receiving phone.
 
That is a good find. It does indicate that the PBX is using the codec list, but not following the order, which might indicate a bug. Bugs are not bad because they can usually be easily fixed. :)
 
When the PBX does the transcoding of the RTP (PBX delivers audio) then the PBX is the offeror for the second leg of the call. In this case the invite from the PBX will have the codecs in the order specified in the 3CXPhoneSytem.ini. If the first codec offered matches the codecs of the extension then it will use that. For external calls ( which remote extensions are) the first codec offered by the PBX is GSM. You can use what bigdessert said and remove the codecs from the extensions or change the order of the PBX which will affect all external calls.
 
Wait, so 3CX doesn't honor the codec order under the options section of phones and trunks??????
 
Wait, so 3CX doesn't honor the codec order under the options section of phones and trunks??????

The codec priority is determined by the offeror, so when an extension calls another extension and there is not PBX delivers audio then the codec priority will be determined by the extension that initiates the call . When PBX delivers audio then the first leg of the call from extension to PBX is determined by the extension. for the second leg between the PBX and the extension that's being called the PBX determines the codec because the PBX is the offeror.
Trunks have their own codecs and when you make a call out, the order in your trunk determines the codec.
 
The codec priority is determined by the offeror, so when an extension calls another extension and there is not PBX delivers audio then the codec priority will be determined by the extension that initiates the call . When PBX delivers audio then the first leg of the call from extension to PBX is determined by the extension. for the second leg between the PBX and the extension that's being called the PBX determines the codec because the PBX is the offeror.
Trunks have their own codecs and when you make a call out, the order in your trunk determines the codec.

So when 3CX determines the codec on the leg of the call when PBX delivers audio you say this codec order is specified in the 3CXPhoneSystem.ini? Where about do I find this order?
 
OK. Yiannish. There are two 3CXPhoneSystem.ini files. One is at /var/lib/3cxpbx/Bin/ and the other at /var/lib/3cxpbx/Instance1/bin

Only the one at /var/lib/3cxpbx/Bin has the line
ExternalCodecs = GSM G729 G722 PCMU PCMA

Is it supported for us to reorder these?
 
You can change them just make sure you do not leave any extra spaces or something similar. After you re-order them make sure you restart the media server service.
 
  • Like
Reactions: datamerge
Status
Not open for further replies.

Forum statistics

Threads
111,859
Messages
589,435
Members
164,700
Latest member
Apollo Cloud