FreeCalypso > hg > themwi-system-sw

annotate 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
Ignore whitespace changes - Everywhere: Within whitespace: At end of lines:
rev   line source
173
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
1 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
2 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
3 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
4
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
5 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
6 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
7 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
8 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
9 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
10 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
11 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
12 indication).
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 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
15 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
16 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
17 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
18 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
19 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
20 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
21 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
22 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
23 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
24
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
25 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
26 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
27 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
28 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
29 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
30 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
31 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
32 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
33
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
34 Representing BFI markers in an RTP stream
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
35 =========================================
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
36
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
37 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
38 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
39 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
40 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
41
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
42 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
43 transmitted in any payload format configuration, [...]
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 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
46 and RFC 2119 states:
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
47
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
48 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
49 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
50 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
51 implications should be understood and the case carefully weighed
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
52 before implementing any behavior described with this label.
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 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
55 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
56 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
57 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
58 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
59 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
60 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
61
177
a851bde42d82 doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents: 173
diff changeset
62 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
63 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
64 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
65 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
66 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
67 SHOULD NOT.
a851bde42d82 doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents: 173
diff changeset
68
173
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
69 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
70 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
71 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
72 challenge.
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
73
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
74 Inventing an RTP BFI marker for FR and EFR
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
75 ==========================================
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
76
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
77 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
78 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
79 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
80 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
81 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
82 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
83 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
84 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
85 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
86 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
87 about FR and EFR?
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
88
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
89 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
90 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
91 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
92 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
93 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
94 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
95 described further below.
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
96
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
97 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
98 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
99 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
100 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
101 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
102 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
103 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
104 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
105 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
106 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
107 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
108 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
109 probably produce garbage at the decoder output.
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
110
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
111 Themyscira Wireless implemented solution
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
112 ========================================
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
113
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
114 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
115 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
116 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
117 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
118 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
119
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
120 byte 0: 0xBF signature;
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
121 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
122 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
123
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
124 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
125 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
126 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
127 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
128 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
129 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
130 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
131 RTP packet at all for that 20 ms frame.
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 Our patch to osmo-bts
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
134 =====================
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
135
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
136 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
137 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
138 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
139 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
140 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
141 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
142 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
143 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
144 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
145 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
146 of uplink DTX.
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
147
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
148 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
149 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
150 before it can be proposed for merging:
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
151
177
a851bde42d82 doc/RTP-BFI-extension: update for the current situation
Mychaela Falconia <falcon@freecalypso.org>
parents: 173
diff changeset
152 * 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
153 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
154 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
155
36cce9b0bbe2 doc/RTP-BFI-extension: article written
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff changeset
156 * 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
157 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
158 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
159 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
160 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
161 (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
162 for FR & EFR, using Themyscira encoding for the latter.