Config Question - Optimising Codecs

[Lewis]

Morning All

In a solution I am working on we have scenarios where the SIP Device side RTPengine is using G.722 and the Trunk side G.711. I am struggling to work out how to optimise this flow so that the SIP Device to Trunk will match G.711 all the way through. It is often in the pool of RTPengines the Trunk and Access side of the call will be on different RTPengines and possibly different FreeSWITCH's.

This is roughly how it looks.

Priority Ordering
SIP Devices (G.722 | G.711)
FreeSWITCH (G.722 | G.711)

Media Path Trunk Call
SIP Device G.722 > Edge SBC > RTPengine (1) || FreeSWITCH || < RTPengine (2) < Edge SBC

I appreciate that this could be handled at multiple points in this chain but my question is, is there a way to have the 2 x RTPengine know about each other and ping the G.711 all the way through?

We are using separate Kamailio build for Registration and Trunk between the 2 Edge SBC's for setup.

rtpengine_manage

"RTP/AVP replace-session-connection replace-origin port-latching ICE=remove"

If this was SIP Device > SIP Device it is G.722 all the way through

Does anyone have any thoughts on this? Any advice or thought provoking questions welcome.

[Richard Fuchs]

Just to make sure I understand your question: In your scenario the codec that ends up being used is G.722 end-to-end, but you want to force usage of G.711 end-to-end instead?

The easiest way to do this would be to simply remove G.722 from the offer, leaving G.711 as the only option that the answerer can accept. You can do this with rtpengine by adding `codec-strip-G722` to the offer flags.

Cheers

Does anyone have any thoughts on this? Any advice or thought provoking questions welcome. --
You received this message because you are subscribed to the Google Groups "rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/cb56299a-2d3a-489b-a40f-bf943660e0cbn%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lewis]

Hi Richard

Sorry what you have described is not quite right although what you have provided is useful and may form part of a solution, for clarity the below is what I am trying to achieve.

I want to keep it so that SIP Device to SIP Device via RTPengine will continue to use G.722 end to end but when a SIP Device Calls the Trunk (UK Mobile for Example) to ensure G.711 end to end.

But what we see is ( i.e for a inbound/outbound call from SIP Device to UK Mobile or Vice versa)

Leg 1 G.722 from SIP Device to RTPengine (1) --- INBOUND to PBX 
Leg 2 G.711 from RTPengine (2) to Trunk --- OUTBOUND to Trunk

Media Path Trunk Call
SIP Device G.722 > Edge SBC G.722 > RTPengine (1) G.722 ---- || FreeSWITCH || ----  < RTPengine (2) G.711 < Edge SBC G.711

[Richard Fuchs]

On 07/11/2022 09.27, [EXT] Lewis wrote:

Hi Richard

Sorry what you have described is not quite right although what you have provided is useful and may form part of a solution, for clarity the below is what I am trying to achieve.

I want to keep it so that SIP Device to SIP Device via RTPengine will continue to use G.722 end to end but when a SIP Device Calls the Trunk (UK Mobile for Example) to ensure G.711 end to end.

But what we see is ( i.e for a inbound/outbound call from SIP Device to UK Mobile or Vice versa)

Leg 1 G.722 from SIP Device to RTPengine (1) --- INBOUND to PBX 
Leg 2 G.711 from RTPengine (2) to Trunk --- OUTBOUND to Trunk

Media Path Trunk Call
SIP Device G.722 > Edge SBC G.722 > RTPengine (1) G.722 ---- || FreeSWITCH || ----  < RTPengine (2) G.711 < Edge SBC G.711

That looks like it's FreeSwitch doing the conversion? If the telco rejects G.722 and accepts G.711, then that rejection should be passing through FreeSwitch and back to the SIP device, which would then lead to G.711 end to end. If FreeSwitch accepts G.722 separately and doesn't or cannot pass through the G.711 answer from the telco, then a G.711 re-invite from FreeSwitch would be in order. If neither of these are possible, then the only solution I can think of is to selectively remove G.722 from the offer if you know that the call will be going to the telco.

Cheers

[Lewis]

Hi Richard

I have had a look at FreeSWITCH and the Devices, both are set to pick G.722 then G.711

FreeSWITCH config

  <X-PRE-PROCESS cmd="set" data="global_codec_prefs=G722,PCMA"/>
  <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=G722,PCMA"/>

But I 'think' the issue is the Leg 1 and Leg 2 are anchored to separate RTPengine and FreeSWITCH so when the SIP Device wants G.722 it gets it with is  FreeSWITCH and RTPengine pair and when the Trunk leg is setup and wants G.711 it gets it with its FreeSWITCH and RTPengine pair without considering what the other leg has, as a result there is no codec negotiation.

I feel like there is a number of options here to handle this but I was wondering if there is a way for RTPengine to learn the call is on another RTPengine instance in the pool and try and solve this. RTPengine is not my strongest suit so wanted to check I wasn't missing something.

Your reply earlier has been helpful because i can work through the scenarios and selectively remove the G722 if required. 

[Richard Fuchs]

On 07/11/2022 10.03, [EXT] Lewis wrote:

Hi Richard

I have had a look at FreeSWITCH and the Devices, both are set to pick G.722 then G.711

FreeSWITCH config

  <X-PRE-PROCESS cmd="set" data="global_codec_prefs=G722,PCMA"/>
  <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=G722,PCMA"/>

But I 'think' the issue is the Leg 1 and Leg 2 are anchored to separate RTPengine and FreeSWITCH so when the SIP Device wants G.722 it gets it with is  FreeSWITCH and RTPengine pair and when the Trunk leg is setup and wants G.711 it gets it with its FreeSWITCH and RTPengine pair without considering what the other leg has, as a result there is no codec negotiation.

I feel like there is a number of options here to handle this but I was wondering if there is a way for RTPengine to learn the call is on another RTPengine instance in the pool and try and solve this. RTPengine is not my strongest suit so wanted to check I wasn't missing something.

Well, not as such. The way you would normally have two rtpengine instances communicate to each other like this would be through the SDP negotiation. By default rtpengine just passes through codec information, so if the first call leg has G.722 in the offer, which then gets rejected by the answer in the second call leg (leaving G.711), then that answer would/should go back to the first call leg, where both rtpengine and the original caller would eventually see G.722 being rejected and so use G.711. But it sounds like FreeSwitch is interfering with this process and is manipulating the codecs in the SDP.

If the two call legs are logically two separate calls, with separate offer/answer negotiation, then it would be up to FreeSwitch in the middle to handle the codec negotiation. In generally there should be a final re-invite between A and B to settle the codecs after the call legs have been connected.

Cheers

[Lewis]

Agreed. Many thanks for sense checking and providing feedback. Will look at some options but think all should be good as have a plan for moving forward.