Attention is currently required from: pespin, dexter.
5 comments:
Commit Message:
It might be helpful to mention DTX to make more clear what this is about. […]
I will cover this topic in proper detail in June OsmoDevCall, but here is a shorter version: the problem being solved here is one of TrFO rather than DTX. DTX is defined and enabled/disabled separately for UL and DL directions; DTXu is always allowed and almost always desired, but DTXd is only possible if you have a cell with more than just C0. The problem is TrFO: what do we do when the RTP output of call leg A (which has DTXu enabled) goes to the RTP input of call leg B, which does not have DTXd? (Right now no OsmoBTS model has correctly working DTXd for non-AMR, but this lack of support is a separate problem, and a low-priority one because it matters only for users with lots of spectrum and multi-TRX hw.)
The scenario where a BTS receives DTX SIDs in its RTP input but does not do physical DTXd on the radio DL was not envisioned at all in any of the non-AMR DTX specs (not FR, not HR, not EFR), hence we have to improvise. My solution is to effect a kind of fake DTXd: in those frame positions where real DTXd would transmit nothing at all (physical Tx off), transmit something that would cause a BFI condition in the GSM MS receiver. It just so happens that all of our BTS models already transmit such induced-BFI conditions when fed a zero-length payload: osmo-bts-trx sends dummy FACCH, whereas sysmoBTS PHY appears to invert the CRC3 bits of GSM 05.03 section 3.1.2.1.
I should also note that in the case of FR1 and HR1 codecs this fake DTXd approach is not the only feasible one - the alternative would be to implement the rules of TS 28.062 section C.3.2.1.1 - these rules are written for in-band TFO, but can be applied just as well to TrFO. However, implementing those rules seems infeasible (or at least inordinately difficult) for EFR, leaving fake DTXd as the only feasible approach. And if we have to do fake DTXd for EFR, why not do it for all 3 classic non-AMR codecs?
I shall give your comment some thought - how to reflect in the commit message and code comments that we are dealing with DTX SIDs going to a BTS that may not have DTXd. Although when and if we do implement real DTXd for non-AMR, the same logic will apply there, so at least there's that.
File include/osmo-bts/lchan.h:
Patch Set #2, Line 281: } nonamr;
I would rename it to fr_efr too. […]
I'll go with dexter's suggestion of dtx_fr_efr for the new substruct, plus renaming the old dtx substruct to dtx_amr.
I should also mention that the correct non-AMR DTX logic for HR1 is almost exactly the same as for FR & EFR, hence when and if someone extends my FR/EFR logic to also cover HR1, the same substruct will likely be used. Why am I not fully covering HR1 from the get-go? In addition to OS#5688, there are some extra difficulties with HR1 which I shall cover in my OsmoDevCall presentation in June.
Patch Set #2, Line 282: uint8_t last_cmr;
Its a sub struct "tch", so the location should be fine.
dexter's comment is correct - the last_cmr member is in the larger tch substruct, not in either of the two DTX substructs.
File src/common/l1sap.c:
Patch Set #2, Line 1315: if (lchan->type == GSM_LCHAN_TCH_F)
"switch (lchan->type)" should make this function less cryptic imho.
I'll change this code to use nested switch statements for lchan->type and lchan->nr in the next version.
Patch Set #2, Line 1334: bool is_nonamr_sid = false;
better rename this to is_fr_efr_sid as well.
Will do.
To view, visit change 32714. To unsubscribe, or for help writing mail filters, visit settings.