What does "PBX Delivers audio" EXACTLY do...?

[FredyWenger]

Hi
We have migrated to VoIP and 3cx and had a very bad voice quality first.
The reason was, that the option "PBX Delivers audio" was set to all extensions.
=> I think, this was the reason, that the configured codec G.722 was not used by the phones.
As soon, as I have deactivated the option to all extensions, the quality for internal calls have improved massive and I was able to see (in trace) that G.722 is now used end-to-end.
I think, of the option is set, the audio ist transferred fully over the 3cx PBX (instead directly form device to device) - unfortunately, I don't have found any detailed information, what this option does...
We still are not able to use G.722 end-to-end for external voice calls (although the SIP-Trunk provider claims, that G.722 is fully supported over the SIP-Trunk)

Question:
To the SIP-Trunk, the same option (PBX Delivers audio" can be set...
What does this option to the SIP-Trunk do exactly?
-> I have played with it but was not able to see any difference if set or not...
But maybe, some services have to be restarted, so that changes becomes active (if yes, which services)?

Thanks for any detailed and useful answer

 

[eddv123]

In the case of extension:

In a SIP call the SIP signalling along with SDP normally sets up the call with the use of the PBX system, it then passes over the media traffic between the 2 IP endpoints instead of going via the PBX and thus adding more load to the PBX system.

The only time(s) I would recommend having this setting enabled is when call recording or or if you have extensions setup remotely using the "Remote STUN" method.

In both cases they must have this enabled - one of the main downsides (at least in the case of remote STUN) is that it utilizes bandwidth and latency on the VoIP call. Using the 3CX SBC negates this and keeps the audio streams local between the IP endpoints.

In the case of a VoIP Provider have a look at this string:

https://www.3cx.com/community/threads/pbx-delivers-audio-help.21018/

 

[YiannisH_3CX]

Hello @FredyWenger

As mentioned the option PBX Delivers Audio routes all audio traffic through the PBX. This helps in situations that the endpoints cannot talk directly between them or there is a network restriction that this option helps overcome. This does add additional audio to the PBX as all traffic needs to go through the PBX. This can cause audio issue if the server does not have the specs to handle the traffic or if the server and the endpoints use different codecs and the audio has to be transcoded
back and forth which does have an impact on quality.
When Call recording is on then audio is routed through the PBX anyway as it needs to be recorded.
For providers it is recommended that the option is always on as there are rare cases that the call might not have audio when connected to a remote extension.

 

[FredyWenger]

Thanks to @eddv123 and @YiannisH_3CX for the answers...

Unfortunately, my main question is not answered...
As I wrote, I was able to comprehend, that the codec G.722 (best quality until Opus will be supported by 3cx, what should be the case wit the next release was used end to end internally, as soon as I have deactivated the option “PBX Delivers Audio” to all extensions.

If I understand you answers correct, it’s not recommended, to set “PBX delivers Audio”, if there are no special reasons for (old, else not supported devices or audio recording (what we don’t use)).

As I wrote, we are not able to reach a connection over G.722 end-to-end for external calls (although over provider claims that G.722 is fully supported thru the SIP-Trunk).

Therefore once again:
To the SIP-Trunk, the same option (PBX Delivers audio" can be set...
What does this option to the SIP-Trunk do exactly?
-> I have played with it but was not able to see any difference if set or not...
But maybe, some services have to be restarted, so that changes becomes active (if yes, which services)?

Thanks for further answer(s), especially to the setting “PBX Delivers audio” to the SIP-Trunk.

 

[YiannisH_3CX]

As i mentioned the option should be enabled under the trunk settings so rare scenarios that might not have audio.
Generally speaking you should not see any difference in the behaviour when the option is on or off as the PBX will always be negotiating the audio stream. The PBX delivers audio setting ensures this functionality in the extreme cases where the PBX might think that the 2 parties can talk to each other directly and try to connect them.
Now if the provider offers the codec G722 as its first codec in the Invite then we will use G722 as the default codec.
On outbound calls make sure that G722 is the first on the list under the trunk settings.

 

[FredyWenger]

Thanks @YiannisH_3CX for your fast response.
So according to your answer, "PBX delivers Audio" should be set (for security reasons) to the sip trunk (and has no impact to the used codec).
So.. in our case, the G.722 is not supported by the sip trunk provider (although, he claims it is) or some configuration is wrong or not active...
G.722 is set as first codec in the trunk settings...

But maybe the setting is not active, as a service on the 3cx has to be restarted...?
Which service(s) are related to the trunk settings and have to be restartet, if changes were made at the sip trunk configuration (see also my first posting)?
Thanks for a further (last reply...

 

[YiannisH_3CX]

So.. in our case, the G.722 is not supported by the sip trunk provider (although, he claims it is) or some configuration is wrong or not active...

Your provider might support G722 but the codec might not be the first on the list. If the call is initiated by the provider then it is the provider specifying the codecs. So if the providers first codec is G711U for example and this is also supported by the PBX then that is one that will be used.
You could run a wireshark capture and check an incoming Invite message and see what codecs are offered by the provider.

But maybe the setting is not active, as a service on the 3cx has to be restarted...?

You do not need to restart any services to change the order of the codecs, if you however wish to do so to make sure then restart the SIP server service and the Media server service.

 

[FredyWenger]

Many thanks to @YiannisH_3CX for the useful answers.
I have restarted the SIP server service and the Media server service (only to be absolutely sure, that the settings are active).
As I see no difference, It seems as you are right (no restart needed).
I have traced the calls with wireshark.
For internal calls (including mobile App), I can see, that G.722 ist used end to end.
For external calls (two different mobile providers, that both should support G.722 fully), I can see an invite with (g711A g711U G726-32 G729) and the call is established with G711A then (what is logical).
The priority in the invite, is the same, that the SIP trunk provider has posted on his (maybe old) homepage (but claims, that G.722 is fully supported).

So... I think, the invite (without G.722) is generated by the SIP trunk (not the mobile providers) and G.722 is simply not (or at least not correct) supported by the SIP trunk provider (nevertheless what he claims).
Is that correct from your point of view?
Thanks for a further replay

 

[YiannisH_3CX]

If you do not see the G722 codec in the Invite then it cannot be selected as the preferred coded. I would contact the provider with the capture and ask them if G722 needs to be enabled on their side or if it comes with extra cost.

 

[FredyWenger]

Thanks @YiannisH_3CX
So you agree with me, that the problem has to be o the SIP trunk (SIP trunk provider)?

 

[YiannisH_3CX]

Yes from the information i have it looks like your provider is not offering the G722 codec.

 

[FredyWenger]

Final thanks @YiannisH_3CX
You really have helped me

 

[YiannisH_3CX]

Glad i could assist. Let us know if further assistance is required

 

[FredyWenger]

Hi @YiannisH_3CX

I have done further tests (and traces) now...
If I 1.) do an internal call between two provisioned Snom’s directly over the extension number, ONE stream is established with G.722 and the voice quality is good (as it should be with G.722).

If I 2.) do an “internal call” between (the same) two provisioned Snom’s over the external number to the extensions, I can see, that the THREE streams are established and the connection goes over the SIP trunk of the provider.

According to the trace, it seems as G.722 is used for all three streams, but the voice quality is very poor (poorer as with a G.711A connection).
It think, something is going completely wrong on the SIP trunk.

In my understanding - if G.722 would be supported fully on the SIP trunk - the quality should be the same in case 1.) and 2.)

What do you think...?

 

[lneblett]

There are few providers in the U.S. that support g.722. In order for g.722 to be effective, it requires that all carriers/providers between the endpoints also support g.722. As many are not yet using SIP, but copper or T1, the frequency that g.722 can accommodate is unable to be accommodated by non-SIP lines and needs to be transcoded to a lower rate codec such as g.711 or g.729. So while your provider may support it, the delivering provider may not.

 

[FredyWenger]

The delivering provider is the same...
The 3cx is hosted by the same provider, that also supports the SIP trunk.
So... there is no other provider in the game (3cx <-> SIP trunk <-> 3cx)

 

[YiannisH_3CX]

If you are familiar with wireshark you can break down the call legs and export the audio to see where the quality drops. You can also check if the provider sends the codec G722 in the SDP.

 

[FredyWenger]

I would not say, that I really am "familiar" with wireshark, but I know, how to do a trace on the 3cx, download the log and view it in wireshark...
I already have done, what you suggest (see older posting) and see in the trace, that for all three streams, G.722 was used...
If I play the streams, all three sounds similar to me...
I think, better than at the real life call, but worse as when I establish an internal call with only ONE stream and G.722...
Therefore I think, something went wrong on the SIP trunk...

 

[YiannisH_3CX]

Can you try the same scenario with a different provider and see if the audio quality is better?

 

[FredyWenger]

I hoped for an answer (what may be the reason of the issue):

• Is the behavior (three streams with G.722, if the external number is called) normal from your point of view?
• Do you have an idea, what can cause the bad voice quality (although, it seems as G.722 is used) - I don't think this is normal / a known issue?

It's not as easy to try a different provider (as the 3cx is hosted by the same provider)...
But I will check out, if I can do later.
As soon as 3cx support Opus fully (should be with the next release, which will come out soon hopefully) and Opus works fully for internal calls, I will change to a provider that also supports Opus on his SIP trunk (to be ready for the future ....