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~ _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community