7 Feb
2025
7 Feb
'25
12:14 a.m.
Dear Mychaela,
Thanks for the detailed explanation, I already watched your
presentations in the past, yet I was completely unaware that the E1
based MGW has different capabilities.
I am happy to confirm that your recent Osmo-MGW patches indeed fixed
the EFR call, which now works as expected. I wonder if this also means
we can connect EFR calls through the external MNCC or the
sip-connector to a PBX or that is still FR only for E1 based BTSes?
I have and EDGE capable MetroSite with the latest SW ever released for
them, which means full AMR support, so once you have something I can
give it a try, can provide captures, logs, whatever you need. I wonder
if a similar "hack" with AMR could work, lets say for the normal 12.2
AMR-FR calls (without fallback and other perks).
Regards,
Csaba
Mychaela Falconia <falcon(a)freecalypso.org> ezt írta (időpont: 2025.
febr. 6., Cs, 0:52):
Hi Sipos,
FR calls between mobile phones are working fine,
but when I change the
codec-list to
"codec-list fr2 fr1 fr3" or "codec-list fr3 fr1 fr2", I am getting a
Remote Transcoder Failure:
lchan(0-0-1-TCH_F-0)[0x630d01c78b80]{ESTABLISHED}: (type=TCH_F)
CONNECTION FAIL (cause=Remote Transcoder Failure [ 28 ])
You should have said right away, in your initial post, that your issue
was specifically with E1 BTS, as opposed to OsmoBTS or ip.access
nanoBTS. To me this part was immediately obvious from the Remote
Transcoder Failure cause value (plus having seen your name previously
in the context of E1 BTS), but it looks like Neels missed this key
detail.
In your later follow-up:
This test was on a Nokia InSite (which can only
do FR/EFR), I also
tested it on MetroSite with full AMR capability and it is the same
issue (both EFR and AMR calls fail the same way, FR works as
expected).
Thank you for clarifying. :-)
Now onwards with your actual problem: let us split it into EFR and
AMR, i.e., address each of these newer-than-FRv1 codecs separately.
For EFR, this patch will probably get you closer to working state:
https://gerrit.osmocom.org/c/osmo-mgw/+/39477
To be absolutely clear, it is _not_ a Truly Proper fix - and
furthermore, the Truly Proper fix I wish to implement (TFO transform
per 3GPP TS 28.062 section C.3.2.1.1 for EFR codec) is still very far
away, given the current state of my priority queue. However, it
should get you closer to a working state: with the above patch, you
won't be getting the Remote Transcoder Failure indication from the
BTS, i.e., the BTS will be kept happy in terms of what it sees on E1
Abis downlink. It is the best we can do on a short time scale.
(And yes, I spent today doing this patch series specifically because
I felt prompted by your experience of running into this bug.)
I am fairly sure with Osmo-NITB at least EFR was
working with these
phones and BTS some years ago.
See trau_frame_up2down() function in libosmo-abis (very deprecated
code, but still present in mainline libosmo* suite) - I never played
with the old OsmoNITB (I joined Osmocom well after the split), but I
reason that old TRAU code must be what the old OsmoNITB used. Needless
to say, it is nowhere close to what we need in terms of a proper TFO
transform. I invite you to watch the video of my most recent
OsmoDevCall presentation on this topic (2025 Jan), and/or look at my
posted slides from that talk.
Now onwards to AMR. Here the situation is simpler: OsmoMGW-E1 does
not support AMR at all. Furthermore:
* The work to add AMR support for E1 BTS would need to begin in the
libraries (libosmotrau in libosmo-abis.git) before tackling the
application, as in OsmoMGW-E1 or a wholesale replacement;
* Experimentation will be needed with specific E1 BTS (Ericsson RBS6k
in my case, or Nokia MetroSite in your case) to see if the BTS can
handle the behaviors of TS 26.094 section A.5.1.2.3 (accept
SPEECH_BAD, SPEECH_DEGRADED, SID_BAD and NO_DATA frames in DL)
_without_ involving BTS-controlled TFO-AMR. Again, please refer to
my TFO presentation.
HTH,
M~