28 Nov
2022
28 Nov
'22
10:40 a.m.
Hi Pau,
https://datatracker.ietf.org/doc/html/rfc3267#section-4.3.2
"""
Note that packets containing only NO_DATA frames SHOULD NOT be
transmitted.
"""
Yes, I am fully aware of that callout in the RFCs (the newer RFC 4867
says the same), but it is a SHOULD NOT rather than a MUST NOT.
Quoting RFC 2119:
SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
And as I wrote in my RTP-BFI-extension document:
: Our situation is just that: in our particular circumstance (desire to
: implement a traditional GSM TRAU in an RTP-to-RTP environment with no
: TDM network to act as a rigid timing governor) a valid reason exists
: why this "SHOULD NOT" behavior is not only acceptable, but becomes
: necessary.
My guess is that you should indicate it with Q bit set
to 0 and put
whatever you want in the payload, maybe padding of zeroes of expected
length based on pyaload type.
https://datatracker.ietf.org/doc/html/rfc3267#section-4.3.2
I don't see how this approach would be any better than simply sending
a NO_DATA frame. When those RFC authors wrote that NO_DATA frames
SHOULD NOT be sent, they surely meant that the sender should leave a
gap in the RTP stream instead (as you say yourself further below), not
a roundabout way of saying "NO DATA" by way of Q=0.
In any case, in RTP you have seq nums and timestamps,
which should allow
you to find out if there were gaps (just check non-consecutive jumps of
seq, or non-consecutive jumps of 160ms of timestamp).
Except that it will be too late at that point - seeing an increment of
more than 160 timestamp units while the sequence number incremented
only by 1 would indicate *after the fact* that the sender produced an
intentional gap in its output stream, but after-the-fact doesn't do me
any good - I want to have a BFI-signaling packet arrive *at the same
time* when a good traffic frame would otherwise be expected.
But we are straying from the topic of my original question - my
question to the lists was and still is about FR and EFR, not about
AMR. In the case of FR & EFR, there is existing code in osmo-bts-trx
that generates a frame of all zero bits (260 of them for FR or 244 for
EFR) to signal BFI, and there is existing code in GAPK (ECU tie-in)
that interprets an FR frame of 260 zero bits as BFI. My question
still stands: is this representation of BFI for FR & EFR an Osmocom
invention, or is there some (presumably newer) spec from 3GPP etc that
specifies such?
M~