FreeCalypso > hg > themwi-system-sw
annotate doc/RTP-BFI-extension @ 267:81958b35f74d
NANP validation: allow made-up area codes of N9X form
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Mon, 13 Nov 2023 15:28:09 -0800 |
parents | 185225722714 |
children |
rev | line source |
---|---|
207
185225722714
doc: new extended RTP format
Mychaela Falconia <falcon@freecalypso.org>
parents:
177
diff
changeset
|
1 NOTE: This document describes the old BFI representation format that was used |
185225722714
doc: new extended RTP format
Mychaela Falconia <falcon@freecalypso.org>
parents:
177
diff
changeset
|
2 by Themyscira Wireless for a few months from late 2022 into early 2023. We no |
185225722714
doc: new extended RTP format
Mychaela Falconia <falcon@freecalypso.org>
parents:
177
diff
changeset
|
3 longer use this format, instead we have a new, bolder extended payload format |
185225722714
doc: new extended RTP format
Mychaela Falconia <falcon@freecalypso.org>
parents:
177
diff
changeset
|
4 for FR & EFR codecs, defined and described in the new RTP-TRAUlike-format |
185225722714
doc: new extended RTP format
Mychaela Falconia <falcon@freecalypso.org>
parents:
177
diff
changeset
|
5 document. |
185225722714
doc: new extended RTP format
Mychaela Falconia <falcon@freecalypso.org>
parents:
177
diff
changeset
|
6 |
185225722714
doc: new extended RTP format
Mychaela Falconia <falcon@freecalypso.org>
parents:
177
diff
changeset
|
7 Original document follows |
185225722714
doc: new extended RTP format
Mychaela Falconia <falcon@freecalypso.org>
parents:
177
diff
changeset
|
8 ========================= |
185225722714
doc: new extended RTP format
Mychaela Falconia <falcon@freecalypso.org>
parents:
177
diff
changeset
|
9 |
173
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
10 We (Themyscira Wireless) have invented our own non-standard extension to the |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
11 generally accepted standard for RTP-based transport of GSM FR and EFR traffic |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
12 within a GSM RAN, on stretches running from a BTS to a TRAU-like component. |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
13 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
14 The fundamental question is: when the radio subsystem of the BTS does not have |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
15 any good traffic frame to send in a given 20 ms window, what should it do? The |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
16 generally accepted standard behavior is that no packet is sent, an intentional |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
17 gap is created in the RTP stream (the next time an RTP packet does go out, the |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
18 timestamp increments over the gap while the sequence number increments only by |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
19 1, indicating an intentional gap rather than packet loss), and apparently the |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
20 intent was/is that this gap in the RTP stream serves as the BFI (bad frame |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
21 indication). |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
22 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
23 The problem with this generally accepted gap-as-BFI approach is that it deprives |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
24 the downstream transcoding MGW (a "soft TRAU" of sorts) of its timing source. |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
25 If the TRAU-like entity on the receiving end of the RTP stream originating from |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
26 the BTS were an RTP to TDM gateway, there would be no problem - such a gateway |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
27 would have to buffer received RTP packets in order to synchronize to fixed TDM |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
28 timing, and the absence of an RTP packet arriving in time would serve just fine |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
29 as the BFI marker, signaling BFI condition to the Rx DTX handler. But what if |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
30 the G.711 interface on the 64 kbps side of the TRAU is also an RTP stream, this |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
31 time going to a PSTN-via-SIP connectivity provider? Now the TRAU-like component |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
32 becomes a transcoding RTP forwarding MGW without any inherently fixed timing. |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
33 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
34 If the desire is to implement a traditional TRAU in every way except for an |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
35 RTP-based implementation instead of TDM-based, i.e., if the desire is to emit a |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
36 fully continuous G.711 RTP stream from the MGW toward PSTN with comfort noise |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
37 generation and in-band DTMF insertion happening inside the MGW, rather than |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
38 emit gaps in the outgoing stream or punt CN generation (and DTMF) to VoIP |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
39 network elements, this task becomes dramatically easier if the BTS can be |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
40 forced to send an RTP packet in every 20 ms window, be it rain or shine, |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
41 conveying either a good traffic frame or a BFI marker. |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
42 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
43 Representing BFI markers in an RTP stream |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
44 ========================================= |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
45 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
46 In the case of AMR codec, the existing standard RTP payload format already |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
47 provides an obvious way to send a BFI marker: it is the NO_DATA frame type, |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
48 i.e., FT=15 - see RFC 4867 section 4.3.2. That same section also categorizes |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
49 what we seek to do here as a "SHOULD NOT": |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
50 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
51 Note that packets containing only NO_DATA frames SHOULD NOT be |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
52 transmitted in any payload format configuration, [...] |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
53 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
54 However, the just-quoted directive is a SHOULD NOT rather than a MUST NOT, |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
55 and RFC 2119 states: |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
56 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
57 SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
58 there may exist valid reasons in particular circumstances when the |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
59 particular behavior is acceptable or even useful, but the full |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
60 implications should be understood and the case carefully weighed |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
61 before implementing any behavior described with this label. |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
62 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
63 Our situation is just that: in our particular circumstance (desire to implement |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
64 a traditional GSM TRAU in an RTP-to-RTP environment with no TDM network to act |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
65 as a rigid timing governor) a valid reason exists why this "SHOULD NOT" behavior |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
66 is not only acceptable, but becomes necessary. Thus in the case of AMR, we are |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
67 good - there is no need to invent our own totally non-standard extensions to |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
68 RTP payload format, it just needs to be a configurable option in the IP-based |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
69 BTS or in OsmoMGW converting from an E1-based BTS to RTP. |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
70 |
177
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
71 The same situation holds for the rarely-used HR1 codec: RFC 5993 extends GSM-HR |
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
72 RTP representation with a ToC byte modeled after the one defined for AMR in RFC |
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
73 4867. Just like in AMR, GSM-HR ToC byte allows the possibility of a No_Data |
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
74 frame (FT=7 for GSM-HR), with exactly the same semantics - and exactly the same |
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
75 argument as above applies for sending such No_Data frames against the general |
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
76 SHOULD NOT. |
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
77 |
173
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
78 But what about the older FR and EFR codecs? In the case of existing standard |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
79 RTP payload formats for FR and EFR, there is no defined way to represent a BFI |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
80 condition as distinct from any possible good traffic frame, and there lies our |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
81 challenge. |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
82 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
83 Inventing an RTP BFI marker for FR and EFR |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
84 ========================================== |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
85 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
86 The existing code in osmo-bts-trx (but not in the osmo-bts-sysmo version of |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
87 interest to us) already contains a partial implementation of what we seek to do |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
88 here: it runs its own ECU instance in the case of a BFI from the channel |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
89 decoding layer, and if there is still no luck, there is code present to send a |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
90 BFI packet. The implemented behavior is not useful for us because RTP output |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
91 is still fully suppressed when the uplink is expected to be in DTX, and there |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
92 is a higher-level check in common/l1sap.c (l1sap_tch_ind() function) that also |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
93 suppresses RTP output, but still, the point is that someone did already write |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
94 code for sending an RTP packet intended to serve as a BFI. In the case of AMR, |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
95 that code sends out the expected NO_DATA (aka AMR_BAD) frame type - but what |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
96 about FR and EFR? |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
97 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
98 The existing code in osmo-bts-trx sends its FR codec BFI as a valid-looking FR |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
99 frame with all 260 content bits set to 0, and it sends its EFR codec BFI as a |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
100 valid-looking EFR frame with all 244 content bits set to 0. I (Mother Mychaela) |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
101 have given consideration to using this all-zeros in-band BFI representation as |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
102 our RTP BFI marker for ThemWi, but then rejected this idea and decided to |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
103 implement our own non-standard extension to RTP payload format instead, |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
104 described further below. |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
105 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
106 The fundamental philosophical problem which I (Mother Mychaela) have with this |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
107 in-band BFI representation is that in the world of ETSI and 3GPP standards, BFI |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
108 has always been meant to be out-of-band, not in-band. In the TRAU frame format |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
109 defined in GSM 08.60 there is an explicit control bit that carries BFI - the |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
110 condition is NOT to be derived from the 260 or 244 traffic frame bits carried |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
111 in data bit positions. Abusing one particular bit pattern within the regular |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
112 260-bit or 244-bit frame, even if it happens to be all zeros, goes against the |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
113 spirit of classic GSM and 3GPP. Per the specs, an FR codec frame of all zeros |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
114 would be a SID frame with all LAR coefficients set to 0, and standards-compliant |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
115 FR decoders would accept it as a valid SID frame, not as BFI. The situation is |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
116 likely to be even worse with EFR, where a frame of all zeros would not be |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
117 treated as SID (EFR SID code word is 95 ones instead of 95 zeros) and would |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
118 probably produce garbage at the decoder output. |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
119 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
120 Themyscira Wireless implemented solution |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
121 ======================================== |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
122 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
123 We have invented our own non-standard extension to RTP payload format for GSM |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
124 FR and EFR codecs. Our extension is as follows: wherever a BTS needs to send a |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
125 BFI marker in the place of a traffic frame, instead of sending a 33-byte payload |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
126 beginning with 0xD nibble or a 31-byte payload beginning with 0xC nibble, it |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
127 needs to send a 2-byte payload formatted as follows: |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
128 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
129 byte 0: 0xBF signature; |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
130 byte 1: least-significant bit encoding TAF per GSM 06.31 or GSM 06.81, |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
131 section 6.1.1 in both documents; other bits are reserved. |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
132 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
133 In the uplink direction, with an RTP stream going from a BTS to our "soft TRAU" |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
134 MGW, our themwi-mgw recognizes these BFI packets and acts accordingly, feeding |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
135 BFI and TAF to the spec-prescribed Rx DTX handler for FR or EFR. However, if a |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
136 BTS receives these BFI marker packets in the downlink direction as a result of |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
137 TrFO (the RTP stream comes from the uplink of another GSM call), it simply |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
138 discards them without any processing - because a BTS always runs on its own TDMA |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
139 timing, there is no difference between receiving a BFI packet vs receiving no |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
140 RTP packet at all for that 20 ms frame. |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
141 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
142 Our patch to osmo-bts |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
143 ===================== |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
144 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
145 Our current BTS is a sysmoBTS, as opposed to a T1/E1-based BTS interfaced via |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
146 OsmoBSC and OsmoMGW, hence the software component in need of patching is |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
147 osmo-bts. The patch in osmo-patches/osmo-bts-rtp-bfi.patch in the present |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
148 repository applies to the common part of osmo-bts, hence it should theoretically |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
149 work with all models, but it has only been tested with osmo-bts-sysmo. If |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
150 anyone wishes to play with this patch in an osmo-bts-trx environment, they will |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
151 probably need to remove TRX-specific ECU and BFI code from |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
152 osmo-bts-trx/sched_lchan_tchf.c, otherwise the two implementations will "fight": |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
153 the TRX-specific code will kick in on "unexpected" bad frames and times of FACCH |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
154 stealing, whereas the common code will fill in the new form of BFI during times |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
155 of uplink DTX. |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
156 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
157 Aside from the just-described incompatibility with osmo-bts-trx version, our |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
158 current patch has the following outstanding issues which will need to be fixed |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
159 before it can be proposed for merging: |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
160 |
177
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
161 * The code will need to be extended to support AMR, and possibly HR1 too - our |
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
162 current patch always emits our FR/EFR BFI, implicitly assuming that the speech |
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
163 codec is either FR or EFR, as that is how we currently run our network. |
173
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
164 |
36cce9b0bbe2
doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
165 * A configuration option will need to be implemented, to be controlled from |
177
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
166 OsmoBSC or from the BTS' own vty, enabling or disabling the non-standard |
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
167 behavior of sending explicit BFI packets instead of gaps in the RTP stream. |
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
168 It would probably be best implemented as a tristate option, with the choices |
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
169 being no BFI packets at all (default), sending BFI packets only for AMR |
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
170 (where a standard encoding exists) or sending BFI packets for AMR and also |
a851bde42d82
doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
173
diff
changeset
|
171 for FR & EFR, using Themyscira encoding for the latter. |