comparison doc/RTP-BFI-extension @ 126:6fd49f73b025

doc/RTP-BFI-extension: add note about GSM-HR and RFC 5993
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 11 Dec 2022 00:56:17 +0000
parents 2b3f612a5fe5
children
comparison
equal deleted inserted replaced
125:2b3f612a5fe5 126:6fd49f73b025
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.