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 <[email protected]> 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~

Reply via email to