It is my pleasure to inform that I have a WIP patch for OsmoMSC that allows, for the first time, full MO<->MT codecs negotiation to flexibly achieve TFO (Transcoding-Free Operation).
It would be great if OsmoMSC users could give the patch a spin (in a setup that is allowed to fail because of the patch) and see if 2G calls now adjust the MO call leg to MT's codecs limitations for you. Looking forward to feedback!
This task was idling on my list because I assumed it would be a big effort, but now I realized that it is actually simple, not even a new FSM state required. So I could no longer resist to finally complete this long long quest.
The result is this WIP patch: https://gerrit.osmocom.org/c/osmo-msc/+/35051 Related patch series, uncluding ttcn3 test: https://gerrit.osmocom.org/q/topic:reass
This patch requires full SDP on MNCC, so if using osmo-sip-connector, it should be current master -- the relevant patch was merged but is not released yet: https://gerrit.osmocom.org/c/osmo-sip-connector/+/16222
Before this patch, MO was eternally stuck on the initially assigned codec. Now we adjust MO's codec if MT needs it. (MT already intelligently chooses codecs before this patch.)
For example, if MO is AMR capable and MT is not, - the MO side will start out with assigning an AMR codec (not matching). - Once MT responds (MNCC_ALERT_REQ), the MO side notices that MT does not support the assigned codec. It sends another Assignment Command to the BSC, offering only the codecs that MT supports. - If MO has at least one matching codec (say GSM-FR), the result is a TFO call using a matching codec.
We still need to check: - does OsmoBSC play along nicely with the re-assignment (it should AFAICT). - effects on MGCP: there may now be more codecs than just the assigned one in the MGCP towards the MGW. See if that checks out. - effects on 3G: make sure the feature doesn't confuse IuUP handling.
The patch passes all MSC_Tests.ttcn for me (but that doesn't necessarily imply proper codecs choices, the tests are not very strict there it seems).
~N
Hi Neels! great that you took a look at this again and it is finally near completion.
I'll take a look at it, in at least a shorter time span than it took to implement. ;-)
Once this finally gets through, I can rebase and present to CR some ideas about PBX controlled LCLS, that is, where osmo-msc controls LCLS depending on whether or not SDP from the PBX indicates that the PBX needs to be in the audio loop. Combined with osmo-bsc's bts-loop configuration, this allows us keep the RTP stream local at the BTS again.
There are quite a lot a features now to be tested at the next gsm event.. congress?
BTW, on mncc.h all over the place, attending to this was actually one of my first patch attempts (2018), before the intricacies of such a thing were explained to me in comments on:
https://gerrit.osmocom.org/c/libosmocore/+/11185, 11186, 11187
keith/
On Fri, Nov 17, 2023 at 09:54:44AM -0600, Keith wrote:
Once this finally gets through, I can rebase and present to CR some ideas about PBX controlled LCLS, that is, where osmo-msc controls LCLS depending on whether or not SDP from the PBX indicates that the PBX needs to be in the audio loop. Combined with osmo-bsc's bts-loop configuration, this allows us keep the RTP stream local at the BTS again.
That sounds great!
There are quite a lot a features now to be tested at the next gsm event.. congress?
I'm not sure that i'll be physically present... remote access would work.
before the intricacies of such a thing were explained to me in comments on:
https://gerrit.osmocom.org/c/libosmocore/+/11185, 11186, 11187
The explaining I can find there are a) backwards compat and b) some naming. Looks solvable to me =) But reconsidering, IMHpersonalO I'd not sink my time into that... (thoughts wander to jolly's OsmoCC)
~N
-
Keith -
Neels Hofmeyr