--- a/doc/RTP-BFI-extension	Sat Dec 10 23:54:11 2022 +0000
+++ b/doc/RTP-BFI-extension	Sun Dec 11 00:56:17 2022 +0000
@@ -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