Attention is currently required from: laforge, pespin. falconia has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/32110 )
Change subject: common+trx: add rtp ecu-downstream vty option ...................................................................... Patch Set 3: (2 comments) Commit Message: https://gerrit.osmocom.org/c/osmo-bts/+/32110/comment/2c26fd29_9ec4c4a8 PS3, Line 9: Current osmo-bts-trx includes a provision for invoking ECUs from : libosmocodec in the UL path from the channel decoder to the RTP : output; no other models currently do likewise, but there is no : particular reason why this ECU invokation couldn't be moved into : model-independent code. > Some background knowledge: AFAIR, osmo-bts-sysmo (and hence liekly its > relatives > oc2g + lc15) already do some ECU magic in the DSP. At least in the case of FR1 and EFR codecs, I am very certain that sysmoBTS DSP does NOT apply any kind of ECU on UL, at least not in the GSM 06.11/06.61 sense of this term/concept. Any time there is a BFI condition on the uplink (i.e., the PHY heard radio noise rather than a traffic frame from the MS), the output from the PHY is a zero-length payload, and l1if_tch_rx() pushes this empty payload to l1sap, where we now do the option of "rtp continuous-streaming". An ECU in the GSM 06.11 sense (like the one implemented in libosmocodec) would be substituting a synthetic frame in this condition, which sysmoBTS PHY most certainly does NOT do. I am speaking with such certainty because ever since you graciously sold me that discounted sysmoBTS almost a year ago, I've been working with nothing but FR1 and EFR voice calls, I've been looking at its RTP output from day 1, and I recently started sniffing TCH DL on the MS to see what the PHY puts out in that direction too... > Then some user discovered that audio sounded worse on -trx than on -sysmo, It is entirely possible (and quite likely) that the trx version still has various defects and shortcomings in need of fixing - and because I am very interested in CSD which won't happen in the sysmo version, I would like to acquire some suitable hw for osmo-bts-trx and start improving FR/EFR voice in that version too. Distant plans... > and they implemented the "provision for invoking ECUs" in -trx [only]. Two new problems with this attempt at solving the original perceived problem: * The ECU implemented in libosmocodec is pretty bad - see OS#6027. As promised in that ticket, I will be submitting an improved ECU implementation shortly - but: * Even with a fully proper ECU implementation like Themyscira libgsmfrp, the UL path from the PHY to the RTP output inside OsmoBTS is the wrong place for this ECU. Instead the two correct places for the ECU are (1) in the network-side speech transcoder that turns GSM codecs into G.711 for calls to and from the outside world and (2) in the *downlink* (not uplink!) RTP handler in OsmoBTS or OsmoMGW (for T1/E1 BTS) in the case of TrFO calls, following the principles of TS 28.062 section C.3.2.1.1, adapted for the evolution from TFO to TrFO. The ECU-in-the-wrong-place problem is the main reason why the present patch will remain necessary even after I submit my improved FR codec ECU to libosmocodec and get it merged (hopefully). Patchset: PS1: > I think rather than specifying that an ECU happens somewhere "downstream" I > think it's more logical […] I actually came to the same conclusion myself. Out of your proposed names, I like "rtp internal-uplink-ecu" the most. Emphasizing that it is for UL is important - see my other comment about the current ECU invokation being in the wrong place, and the possibility of doing a more proper (per TS 28.062 section C.3.2.1.1) downlink ECU application at some future point. -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32110 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I0acca9c6d7da966a623287563e0789db9e0fae8e Gerrit-Change-Number: 32110 Gerrit-PatchSet: 3 Gerrit-Owner: falconia <[email protected]> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <[email protected]> Gerrit-CC: laforge <[email protected]> Gerrit-CC: pespin <[email protected]> Gerrit-Attention: laforge <[email protected]> Gerrit-Attention: pespin <[email protected]> Gerrit-Comment-Date: Wed, 10 May 2023 17:13:53 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: falconia <[email protected]> Comment-In-Reply-To: laforge <[email protected]> Comment-In-Reply-To: pespin <[email protected]> Gerrit-MessageType: comment
