Cellular Network Infrastructure » Radio Access Network » OsmoBTS

• look at the dsp trace log (Play with the flags) to see if there's anything useful in it
• capture what's actually happening on the air interface using osmocomBB fixeria/burst_ind for detailed analysis.

Question: was this problem seen at CCC? I seem to recall hearing that the GSM network at CCC was run with sysmoBTS units, and I definitely remember reading that they used the AMR codec exclusively, not supporting FR1 or EFR. Did they perhaps disable DTXu, or did the combo of sysmoBTS+AMR+DTXu actually work for other people?

I just checked the congress config.

DTXu, unsurprisingly, was not enabled.

laforge wrote in #note-1:

Some Random Ideas (not saying Keith should do all of that):

• look at the dsp trace log (Play with the flags) to see if there's anything useful in it
• capture what's actually happening on the air interface using osmocomBB fixeria/burst_ind for detailed analysis.

I did play around with the dsp trace flags, including piping that output into pcaps to correlate with gsmtap/osmo-bts-sysmo logging.
So far that did not reveal anything extra about what was happening.

So capturing the uplink off the air would reveal more. I'm not sure I have the hardware to do that. I haven't looked at it in a long time.

Assuming, for the moment, (giving everything I tried with hacking on osmo-bts) the problem is in the L1 and therefore might be a cannot_fix issue, sniffing the UL might be a nice investigation project for somebody with a lot of free time.

AFAIR, there are several modes in which the L1 can be operated. We're using a mode where we get more or less the RTP payload, as that's rather convenient. So I wouldn't give up on not being able to fis this at all.

Getting air interface traces via osmocom-bb tnt/burst_ind is rather easy, I've just done it very recently for getting CSD call traces. Still not saying that you (Keith) should do that.

I really cannot explain some parts of the trace. I cannot reconcile how our code would behave that way. Do you have some local modifications to the AMR DTX logic in place?

Fore example, packet 828..830 seem to indicate that an ONSET received from the PHY would generate a RTP packet. Based on the osmo-bts code in master, I fail to see how that could ever happen. The ONSET would not set any rmsg, and hence add_l1sap_header() should never be called.

possibly related: https://gitlab.com/nrw_noa/osmo-bts/-/commit/0aa2a89af15fa532c585873aaa95da6353e670f8

Another oddity:

1481    0    22:52:02.595433279    GSMTAP        258366/194/04/00/10 Rx PH-DATA.ind TCH/H (hL2 000200bb): 09 04 00 50 44 00 00 00 00 0a , Meas: RSSI -43.97 dBm, Qual 20.41 dB, BER 0.00, Timing -3 
1482    0    22:52:02.595491257    GSMTAP        258366/194/04/00/10 DTX: received SID_FIRST_P1 from L1 (9 bytes) 
1483    0    22:52:02.595612741    AMR        PT=AMR, SSRC=0x4178B092, Seq=32959, Time=2092022532

• SID_FIRST_P1 is signaled as Amr_SidFirstP1 (instead of expected Amr)
• 9 bytes of payload 09 04 00 50 44 00 00 00 00 0a
  • 09: Amr_SidFirstP1
  • 04: CMI
  • 00: CMR
  • 50 44 00 00 00 00 0a is actually the RTP payload the L1 sends us
• our code ignores this and instead calls osmo_amr_rtp_enc(sid_first, 0, AMR_SID, AMR_GOOD) which appears to render @50 44 00 00 00 without the 00 0a suffix. This seems an artefact of first merging c3fb0dcc8cd01a84942d06267003478b972feadb and then c77b574d1fbe43ca19db0e5e041b3b5e2a71b856 by msuraev in 2016. While P2 indeed has no payload, P1 does!
  • Why is the RTP payload from L1 different than our osmo_amr_rtp_enc?
• our transmitted RTP payload is (after RTP header) is 50 44 00 00 00
  • this is wrong. There is no CMR and no TOC bytes preceding. The total packet size should be 7 bytes: CMR (1) + TOC (1) + 39bits-SID+padbits (5).

laforge wrote in #note-8:

I really cannot explain some parts of the trace. I cannot reconcile how our code would behave that way. Do you have some local modifications to the AMR DTX logic in place?

Yes!, As I wrote in the description: "The pcap comes from an osmo-bts with some modifications to logging and RTP marking, (ignore the BAD AMR frames following ONSET"

I should have been more explicit, or include a link to the actual source used. I've since been hacking on that without making any commits so I don't actualy have whatever was used at the time, but as I said in the description also, I didn't think that this RTP packet you are seeing generated as a result of the ONSET is relevant to the issue.

Fore example, packet 828..830 seem to indicate that an ONSET received from the PHY would generate a RTP packet. Based on the osmo-bts code in master, I fail to see how that could ever happen. The ONSET would not set any rmsg, and hence add_l1sap_header() should never be called.

Correct, I was playing around with many things at the time, trying to understand and eliminate the cause of so much "RTP clock out of sync with lower layer"

What I was doing was counting from 0 to 10, along with the "LSB" of wall clock seconds. I try to maintain silence between the numbers and I'm listening to the B-leg and I note which numbers I did not hear. This helps to look at the trace and identify where I need to look. This one worked quite well, but I happened to be running code at the time that was sending this RTP packet you identify.

Now you might say, oh well this is invalid if you are sending RTP packets that osmo-bts master would never send. You'll have to believe me, it makes NO difference whatsoever.

At the time I made this pcap, I had already spent about 3 days!! (granted, of my rather slow process of analysis and understanding) looking at the osmo-bts code related to RX from L1 and generation of RTP. So at this point I am 99.9999% convinced that it has nothing to do with that, what I wanted to demonstrate here is that I am speaking, but the L1 is not sending any speech data. This is why I wrote "that's a hack but not relevant".

I'm sorry if this is confusing or has caused you to waste valuable debugging time, but I think I am quite explicit in the description that this is not osmo-bts master

laforge wrote in #note-10:

• this is wrong. There is no CMR and no TOC bytes preceding. The total packet size should be 7 bytes: CMR (1) + TOC (1) + 39bits-SID+padbits (5).

Untested fix in https://gerrit.osmocom.org/c/osmo-bts/+/32088

laforge wrote in #note-7:

Really a generic AMR or only a TCH/H only problem?¶

First of all, can you please clarify whether the problem only appers on TCH/H?

I have clarified, that the problem only exists on TCH/H.

Using TCH/F, I did various (listening) tests of MS -> MS calls and also MS -> Sip Endpoint (with libopencore-amrnb)

Audio is clear and complete.

laforge wrote in #note-15:

occurred virtually at every word after a period of silence. So the MS is sending CMI=2 (5.9kbps) but the active codec set doesn't contain that? This looks rather odd and deserves further analysis.

• ICMI: implicit
• Start Mode: 0
• 5.90k is the only mode part of the subset

The same is also sent to the MS in the RR ASSIGNMENT COMMAND. So if there's any miscommunication/misinterpretation, it appears to be between osmo-bts and the DSP.

laforge wrote in #note-15:

I was counting up from 1 to 32 (or so), with long breaks between the words. About 5 of those words spoken on the caller side didn't make it to the called party.

5 out of ~30, sounds similar to my experience.

regarding the CMI not in ACS messages, I'm now dumping how we configure the DSP/PHY during MPH-ACTIVATE.req:

• amrCmiPhase=1 (GsmL1_AmrCmiPhase_Odd)
• amrInitCodec=0 (GsmL1_AmrCodecMode_1; first mode of the modeset)
• amrActriveCodecSet={3,0,0,0} (GsmL1_AmrCodec_5_9, GsmL1_AmrCodec_Unset, GsmL1_AmrCodec_Unset, GsmL1_AmrCodec_Unset, GsmL1_AmrCodec_Unset)

This looks all good, and as expected. Not sure why we get those strange log messages from the DSP.