FreeCalypso > hg > gsm-codec-lib
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. |
