Outbound call test question: local and remote codecs differ...

[KMorley]

I am experimenting with codec priorities in an attempt to get the best audio quality. I am currently testing with Flowroute and they support G722, PCMU and PCMA. In the trunk configuration under options, I have the codecs prioritized in that order. I click the Check SIP Trunk button and place an outbound test call, which completes as expected. The summary shown after the test completes shows:



I would appreciate some clarification on what this means. It seems like Local would be the 3CX PBX (hosted at Digital Ocean) and Remote would be the SIP provider (Flowroute). But I don't think that's possible, since the two ends negotiate and select a mutually acceptable codec. Further, there is nothing between the 3CX PBX and the carrier that could do transcoding. Therefore, I think that both 3CX and the carrier negotiated and used G722 for this test.

That leaves my question: what is the Remote that is using PCMU? Is that a carrier further upstream from Flowroute like Peerless? Does this mean that Flowroute is transcoding between the 3CX PBX and that upstream carrier?

I appreciate the education!

Ken Morley

 

[BrunoI_3CX]

In the Check SIP Trunk test call, the codecs displayed represent the codecs used on each leg of the call as seen by the PBX, and may not necessarily reflect the full path of a real call through the provider network.

If you would like to verify the codec used during an actual call, we recommend performing a test call while enabling the Call Quality Monitor feature for one of your extensions.

To do this:
1. Login as System Owner and navigate to the 'Team' page.
2. Locate the desired extension, click it's three-dot menu, and select Monitor Connection Quality.
3. Place a test call using that extension.
4. Then go to Admin > Reports > Call Log.
5. Locate the test call entry, click the three-dot menu on the right side, and select Show Call Quality Report.

This report will display detailed information about the call, including the codec used.

 

[paulodagraca]

Hello @KMorley,

Your SIP provider is sending the order of available codecs with on top the PCMU.

We did found the same here, however the provider we use does have a login panel to change the codecs and the order.
However it did not do this correctly.

To prove this, we did the following:
On the Edge browser we started a SIP capture on the 3CX and on the Chrome browser we started the SIP Trunk test.

Then looked at the SIP pakkets and saw the 3CX SIP Trunk test is 100% right.
The provider did not set the order of codecs in the order we did setup the configuration.
So we end up changing it at the 3CX to get this right.

This means: Now i always trust the 3CX SIP Trunk test and not any SIP provider setup or statement, without testing it.

Paulo

 

[VoIPTools]

I know this is obvious, but the endpoint you are calling may have different priorities as well, so you can prioritize G722 on your end, but there are others in the negotiation that may say "I do not support G722". You cannot control what the people you are calling support, and in fact you may force transcoding somewhere along the way.

 

[paulodagraca]

Hello,

Basically, the 3CX Phone System has two "legs" when making a call:
The leg from the IP Phone to the 3CX server.
The leg from the 3CX server to the SIP Trunk (provider).
The "Check SIP Trunk" function tests this second connection. While it's true that a call will still connect even if the codec priorities don't match—since the system will find a compatible codec—that doesn't mean the test is pointless.
You might ask, "Why should I make any changes?" (a fair question).
Let me try to answer this another way...
If you know you will always use this trunk for calls and the trunk’s codec priority never changes, you can expect the same codec matching result every time. So, why not align the codec lists from the start? By making them match 1:1, there is no guesswork about which codec will be used, and no negotiation is needed.
For example, if you know your provider will always set G711U as their first choice, why would you set G711A as the first choice in your trunk setup?
If you set both codec priority lists the same, everything will be correct, simple, fast, and predictable—just the way I like it!
So, that's my attempt to justify the 3CX SIP Trunk test, even if a mismatch isn't necessarily a show-stopper.

Paulo

 

[ivank]

Also, if SIP trunk does not support re-INVITEs (IsSupportReinvite="0"), PBX will have to force transcoding mode even if the codecs of both legs match.