# HG changeset patch
# User Mychaela Falconia <falcon@freecalypso.org>
# Date 1670720177 0
# Node ID 6fd49f73b0251dec35ef2c19a144f52992cf40f3
# Parent  2b3f612a5fe5bf40aab2c08282ccda23fb5dd3d3
doc/RTP-BFI-extension: add note about GSM-HR and RFC 5993

diff -r 2b3f612a5fe5 -r 6fd49f73b025 doc/RTP-BFI-extension
--- 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