# HG changeset patch # User Mychaela Falconia # Date 1676689505 28800 # Node ID a851bde42d8286ea12c3420c3bf23d0997a9880a # Parent f5c4f9a764be1168afe4d73ed53711bf463e9eff doc/RTP-BFI-extension: update for the current situation diff -r f5c4f9a764be -r a851bde42d82 doc/RTP-BFI-extension --- a/doc/RTP-BFI-extension Fri Feb 17 18:27:03 2023 -0800 +++ b/doc/RTP-BFI-extension Fri Feb 17 19:05:05 2023 -0800 @@ -59,6 +59,13 @@ RTP payload format, it just needs to be a configurable option in the IP-based BTS or in OsmoMGW converting from an E1-based BTS to RTP. +The same situation holds for the rarely-used HR1 codec: RFC 5993 extends GSM-HR +RTP representation with a ToC byte modeled after the one defined for AMR in RFC +4867. Just like in AMR, GSM-HR ToC byte allows the possibility of a No_Data +frame (FT=7 for GSM-HR), with exactly the same semantics - and exactly the same +argument as above applies for sending such No_Data frames against the general +SHOULD NOT. + But what about the older FR and EFR codecs? In the case of existing standard RTP payload formats for FR and EFR, there is no defined way to represent a BFI condition as distinct from any possible good traffic frame, and there lies our @@ -142,18 +149,14 @@ current patch has the following outstanding issues which will need to be fixed before it can be proposed for merging: -* Setting of TAF based on the frame number remains to be implemented - right - now we always send TAF=0. - -* The code will need to be extended to support AMR, and to skip out gracefully - in the case of totally unsupported codecs like HR1 - our current patch always - emits our FR/EFR BFI, implicitly assuming that the speech codec is either FR - or EFR, as that is how we currently run our network. +* The code will need to be extended to support AMR, and possibly HR1 too - our + current patch always emits our FR/EFR BFI, implicitly assuming that the speech + codec is either FR or EFR, as that is how we currently run our network. * A configuration option will need to be implemented, to be controlled from - OsmoBSC, enabling or disabling the non-standard behavior of sending explicit - BFI packets instead of gaps in the RTP stream. It would probably be best - implemented as a tristate option, with the choices being no BFI packets at - all (default), sending BFI packets only for AMR (where a standard encoding - exists) or sending BFI packets for AMR and also for FR & EFR, using - Themyscira encoding for the latter. + OsmoBSC or from the BTS' own vty, enabling or disabling the non-standard + behavior of sending explicit BFI packets instead of gaps in the RTP stream. + It would probably be best implemented as a tristate option, with the choices + being no BFI packets at all (default), sending BFI packets only for AMR + (where a standard encoding exists) or sending BFI packets for AMR and also + for FR & EFR, using Themyscira encoding for the latter.