FreeCalypso > hg > themwi-system-sw

comparison doc/RTP-BFI-extension @ 177:a851bde42d82

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/RTP-BFI-extension: update for the current situation
author Mychaela Falconia <falcon@freecalypso.org>
date Fri, 17 Feb 2023 19:05:05 -0800
parents 36cce9b0bbe2
children 185225722714
comparison
equal deleted inserted replaced
176:f5c4f9a764be 177:a851bde42d82
56 as a rigid timing governor) a valid reason exists why this "SHOULD NOT" behavior 56 as a rigid timing governor) a valid reason exists why this "SHOULD NOT" behavior
57 is not only acceptable, but becomes necessary. Thus in the case of AMR, we are 57 is not only acceptable, but becomes necessary. Thus in the case of AMR, we are
58 good - there is no need to invent our own totally non-standard extensions to 58 good - there is no need to invent our own totally non-standard extensions to
59 RTP payload format, it just needs to be a configurable option in the IP-based 59 RTP payload format, it just needs to be a configurable option in the IP-based
60 BTS or in OsmoMGW converting from an E1-based BTS to RTP. 60 BTS or in OsmoMGW converting from an E1-based BTS to RTP.
61
62 The same situation holds for the rarely-used HR1 codec: RFC 5993 extends GSM-HR
63 RTP representation with a ToC byte modeled after the one defined for AMR in RFC
64 4867. Just like in AMR, GSM-HR ToC byte allows the possibility of a No_Data
65 frame (FT=7 for GSM-HR), with exactly the same semantics - and exactly the same
66 argument as above applies for sending such No_Data frames against the general
67 SHOULD NOT.
61 68
62 But what about the older FR and EFR codecs? In the case of existing standard 69 But what about the older FR and EFR codecs? In the case of existing standard
63 RTP payload formats for FR and EFR, there is no defined way to represent a BFI 70 RTP payload formats for FR and EFR, there is no defined way to represent a BFI
64 condition as distinct from any possible good traffic frame, and there lies our 71 condition as distinct from any possible good traffic frame, and there lies our
65 challenge. 72 challenge.
140 147
141 Aside from the just-described incompatibility with osmo-bts-trx version, our 148 Aside from the just-described incompatibility with osmo-bts-trx version, our
142 current patch has the following outstanding issues which will need to be fixed 149 current patch has the following outstanding issues which will need to be fixed
143 before it can be proposed for merging: 150 before it can be proposed for merging:
144 151
145 * Setting of TAF based on the frame number remains to be implemented - right 152 * The code will need to be extended to support AMR, and possibly HR1 too - our
146 now we always send TAF=0. 153 current patch always emits our FR/EFR BFI, implicitly assuming that the speech
147 154 codec is either FR or EFR, as that is how we currently run our network.
148 * The code will need to be extended to support AMR, and to skip out gracefully
149 in the case of totally unsupported codecs like HR1 - our current patch always
150 emits our FR/EFR BFI, implicitly assuming that the speech codec is either FR
151 or EFR, as that is how we currently run our network.
152 155
153 * A configuration option will need to be implemented, to be controlled from 156 * A configuration option will need to be implemented, to be controlled from
154 OsmoBSC, enabling or disabling the non-standard behavior of sending explicit 157 OsmoBSC or from the BTS' own vty, enabling or disabling the non-standard
155 BFI packets instead of gaps in the RTP stream. It would probably be best 158 behavior of sending explicit BFI packets instead of gaps in the RTP stream.
156 implemented as a tristate option, with the choices being no BFI packets at 159 It would probably be best implemented as a tristate option, with the choices
157 all (default), sending BFI packets only for AMR (where a standard encoding 160 being no BFI packets at all (default), sending BFI packets only for AMR
158 exists) or sending BFI packets for AMR and also for FR & EFR, using 161 (where a standard encoding exists) or sending BFI packets for AMR and also
159 Themyscira encoding for the latter. 162 for FR & EFR, using Themyscira encoding for the latter.