Project

General

Profile

Bug #3104

sysmobts with 201705 image no audio first seconds after call is accepted

Added by pespin 2 months ago. Updated 7 days ago.

Status:
Feedback
Priority:
Urgent
Assignee:
Category:
-
Target version:
-
Start date:
03/23/2018
Due date:
% Done:

30%

Spec Reference:

Description

I have a sysmbots with an entire network running on it (bts, mgw, hlr, bsc, msc, sgsn, ggsn, etc.). It is running 201705 nightly image, with current latest osmocom master code.

I have 2 MS registered on it. I start a call from one MS to the other, and I accept it and I see rtp stream being sent, but during the first 5-10 seconds there's no audio. It can be easily tested by blowing air into the micrphone of one MS since the call is accepted. Once the audio appears, there's no lag on it (like the audio first heard it's not the audio I produced 5 seconds ago).

I think I have the same issue running only osmo-bts-symo in the sysmobts and the rest of the network in my PC.

However, I think (I need to re-confirm) that when I use the same network on my PC, but using osmo-bts-trx with sysmocell5000, I don't see this behavior.

I attach a trace showing the issue (sorry no gsmtap enabled)

call_audio_muted_first_seconds.pcapng (1.11 MB) pespin, 03/23/2018 05:39 PM

History

#1 Updated by dexter about 2 months ago

Since I never experienced such an issue with current master, but quite old sysmobts firmware we suspect that this could be a problem with osmo-bts. I had a quick look at the trace, it looks ok, at least there seem not to be any obvious delays or other quirks. The RTP is there, maybe it contains a lot of silence frames at the beginning of the call?

#2 Updated by dexter 20 days ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 30

I tried to test it with Paus sysmobts, but unfortunately that is not in a working state at the moment, so I upgraded mine to sysmocom-core-image-sysmobts-v2-20170807010027.rootfs.ubi

So far I am not able to reproduce the problem, everything looks fine. I get voice throughput immediately after the call is established.

#3 Updated by dexter 20 days ago

In order to see with if the issue has something to do with the phones (Samsung Galaxy S2) I did another test, also here Audio is immediately there.

#4 Updated by dexter 20 days ago

  • Assignee changed from dexter to pespin

#5 Updated by pespin 10 days ago

Updated to latest 201705 nightly and tested following 2 scenarios:
- Complete CNI running in the sysmobts
- osmo-bts in sysmobts connected to CN in my PC

Both scenarios show the issue I'm describing.

#6 Updated by pespin 10 days ago

It seems the issue also appears when using a sysmocell5k (with osmo-bts-trx) and the core network on my PC.

Using dexter's CN with myt sysmobts doesn't show the issue, so it's probably something related to the CN. We spotted a main difference between his and my setup: I'm using only 1 osmo-mgw (in both my PC and in sysmobts scenarios), while dexter is using 2 (one for the bsc, one for the msc).

#7 Updated by dexter 10 days ago

  • % Done changed from 30 to 90

I managed to reproduce the problem using pespin's osmo-mgw.cfg. I think I managed to pinpoint the problem. It looks like a problem with the SSRC and since there is a VTY option to enable SSRC patching my guess ist that this is a known problem.

Try with:
rtp-patch ssrc

btw.: Even if it seems to have nothing to do with the issue I would also add:
rtp-patch timestamp

#8 Updated by pespin 10 days ago

  • Status changed from In Progress to Feedback
  • % Done changed from 90 to 30

I confirm enabling "rtp-patch ssrc" in osmo-mgw.cfg solves the issue.

However, I think it would be interesting to get an explanation in here on why this option intends to patch the SSRC and how it comes it fixes this issue. I did a look at the code but I couldn't find any documentation explaining it.

#9 Updated by laforge 10 days ago

On Mon, May 14, 2018 at 12:22:57PM +0000, dexter [REDMINE] wrote:

I managed to reproduce the problem using pespin's osmo-mgw.cfg. I think I managed to pinpoint the problem. It looks like a problem with the SSRC and since there is a VTY option to enable SSRC patching my guess ist that this is a known problem.

SSRC patching was implemented only for nanoBTS which have a problem if the SSRC of their peer
suddenly changes within a call. This is the case in hand-over situations.

With OsmoBTS no such issue has existed in the past. And if there was such an issue now,
we have full control over the source code, so we should fix it properly there)

#10 Updated by pespin 7 days ago

  • Assignee changed from pespin to dexter

#11 Updated by laforge 7 days ago

  • Priority changed from Normal to Urgent

Also available in: Atom PDF