Using g722 and Twilio without transcoding

[haanc2]

Hi all, I've been experimenting with this for a while and haven't gotten very far. Maybe some of you can help, or tell me if this is even possible?

What I want:
I would like to be able to use g722 internally and use g711 for outgoing/external calls WITHOUT transcoding.

What I have:
All desk phones are Yealink T46S and are connected to an SBC. The PBX is on AWS. I am using Twilio for SIP trunking.

The problem:
The phones work just fine extension-to-extension with g722, however Twilio only supports g711. When trying to dial out, it appears that the phone-to-PBX leg of the call is g722 and the PBX is transcoding to g711, and this sounds significantly worse that leaving everything with only g711 enabled. If I tick the "Supports Re-Invites" box in the SIP Trunk settings the phones will behave as desired, but any external call that is transferred or placed on hold looses audio.

Is there something else to try?

 

[leejor]

Unless things have changed since November, probably not...

https://www.3cx.com/community/threads/codec-priority-priority.61967/

 

[eddv123]

Also please define "SBC" are we talking 3CX SBC or a proper SBC such as an Edgemarc or Audiocodes?

I only as as these do have B2BUA capability and thus control the complete dialogue of the call so could offer more control.

 

[JohnS_3CX]

Hi @haanc2,

As you have correctly noted, the internal leg will follow your codec priority, but since the provider only does G.711 there will be transcoding whenever provider calls are involved.

I think in this case you will either have to use your provider's G.711 globally to avoid transcoding, or keep it as is and accept the transcoded quality when making external calls.

 

[simply7]

Have you gotten a good capture of a call where it loses audio? I have seen where providers are not getting the message back that the call is on hold.

 

[JohnS_3CX]

Hi @haanc2

Twilio should not have "Supports Re-Invite" enabled, it will cause undesired behavior. Please retain the default Twilio profile settings that we validated with them in order to avoid issues with your external calls via this provider.

 

[ucme4now]

First you cannot run two different codecs and NOT do transcoding. I run G.722 on all of my clients T46S phones and I run G.711u on the service provider SIP trunk. They are MUTUALLY exclusive call legs, one has NOTHING to do with the other. They are both signaled separately and they both negotiate the codec separately. It works as designed and it works well.

100% of all SIP Providers in the USA support G.711uLaw very few support G.722, the ones that do are usually smaller Tier-4 players. I digress.

Here is one important factor that may have been missed here, you do not want any signaling or audio to flow between the handset and the SIP Provider directly. Ever. The handset must always signal the PBX then the SIP Provider. The audio path must ALWAYS come back through the PBX then to the handset, always.

You may want to check: PBX Delivers Audio in your configuration and make sure that is is enabled. You do not want audio coming from the SIP provider to the handset directly for this reason plus others. You should have a well defined call path /flow that you manage and control as you support each customer and or your own instance.

A true Session Border Controller (SBC) can easily address transcoding issues or enforce codec selection based on what you use or want to use. If you do not use or want a codec in the selection either delete it or move it to the bottom of the list. Yes, you have that level of control and you'll find it makes life supporting this stuff a lot easier. Codec selection is purely negotiation based and you do have a say in the matter.

Lastly, read up on SIP re-invites, it is nothing what you think it is for the most part and in my experiences the majority of SIP providers do not support it. Then you'll understand why the call is dropped.