Attention is currently required from: fixeria, pespin.
4 comments:
Commit Message:
by emitting two RTP packets
directly back-to-back for UL, and pulling two RTP packets at a time
from the Rx jitter buffer at the needed times for DL.
I understand your idea now. […]
You are correct: if we were implementing a new E1 BTS, there would be no other way to handle the present issue except by buffering the bits and emitting them at the TDM-controlled rate. However, E1 BTS do similar buffering at all times, not just in this one corner case. Consider what happens with all other TCH types besides CSD-HR, i.e., consider CSD-FR and all speech modes. For those "traditional" TCH, osmo-bts (all models, not just trx) emits an RTP packet statistically every 20 ms - but it is not perfect 20 ms, it has TDMA jitter, with the actual time deltas between emitted RTP packets being TDMA*4 or TDMA*5 per multiframe structure. E1 BTS are different in this regard: their internal buffering fully conceals TDMA jitter from the external TDM connection, and the timing of TRAU frames on Abis is perfect 20 ms for each frame.
This aspect of osmo-bts (the fact that we normally expose our TDMA jitter in RTP output) is the main reason why I felt it would make no sense to try to replicate the exact behavior of E1 BTS here. Suppose we wanted to artificially delay the second half of CSD-HR frames by 20 ms to make our RTP output more E1-like - would it be a delay of exactly 20 ms per Linux system clock? Or would be 4 TDMA frames? Or 5 TDMA frames? Exactly which FNs would produce an artificial delay of 4 vs 5 frames? There won't be an answer in the specs as we talking about purely artificial delay here. So why delay at all, why not simply emit both packets right away...
File src/common/l1sap.c:
`ARRAY_SIZE(input_msg)` here and below, please.
Will do.
I would put a comment that it's an IDLE frame (all bits set to 1).
Will do.
Patch Set #2, Line 2098: switch (lchan->tch_mode) {
As a further improvement, I suggest sharing `csd_v110_lchan_desc[]`, so that it can be used here (`d […]
Not sure if I agree - let me handle all other feedback first, then I'll get back to this one.
To view, visit change 38553. To unsubscribe, or for help writing mail filters, visit settings.