--- 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.