Project

General

Profile

Actions

Bug #5895

open

LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b96fa86c77458c

Added by keith about 1 year ago. Updated about 1 year ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
osmo-bts-litecell15
Target version:
-
Start date:
02/07/2023
Due date:
% Done:

0%

Spec Reference:

Description

Writing this up now while it's a bit fresh...

I have spent the last 12 hours or so working with people on site to try to track down these problems:

Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)

Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.

However, today I discovered the extent of how bad this was on local MS to MS calls.

After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.

Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.

Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.

So what to do? Well note it at least. I don't have another lc15 to test on.
Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.

There's the chance that this was fixed since 1.4.0 or in another lib.

Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)