Half sided calls

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Alexander Chemeris alexander.chemeris at gmail.com
Sat Sep 19 18:09:54 UTC 2015


Hi Sipos,

On Sat, Sep 19, 2015 at 5:05 PM, Sipos Csaba
<sipos.csaba at kvk.uni-obuda.hu> wrote:
> I am in the process of creating the Wiki page for Ettus B200/B210 with OpenBSC, GPRS and Asterisk.

Any reason it's specific to B2x0? Configuration should be 99% common
for all SDR devices and I think it makes more sense to have a single
page for that, like the old network_from_scratch.

> I am quite close, both data and calls are working, but the voice calls are half sided. The downlink direction works, but the uplink does not.
>
> I tried without Asterisk and LCR (between two phones) and still the calls are half sided.
>
> In the mean time I got these messages in the Osmo-BTS log:
>
> <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284768 ts=2 tr                                                                             x=0
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f                                                                             n=1284764 to transmit.
> <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f                                                                             n=1284764 to transmit.

Log message suggests that downlink doesn't receive a frame from RTP
side and thus transmits a filler frame. So it seems like your downlink
doesn't work rather than uplink.

It's not clear what do you mean that a call is half sided? According
to the logs, downlink frames are not served at both timeslots, so you
should not hear anything on both sides of the call.

I'd suggest checking that your uplink works, e.g. by looking at
osmo-trx logs. If you have the latest one, it should output a warning
if Rx side is saturated, which is the most possible reason for the
issue.

Another possible issue is codec. I have tested only with GSM-FR so
far. If you enable more debugging in osmo-bts, you should be able to
see decoding result at least for gsm-fr codec. I recommend you enable
at least NOTICE level for L1C and see if there are any fail messages
from here:
http://cgit.osmocom.org/osmo-bts/tree/src/osmo-bts-trx/gsm0503_coding.c?h=201509-fairwaves-rebase

One more thing - which branch are you testing with? I've been testing
201509-fairwaves-rebase. If you're using something else - I'd be
curious what happens if you try 201509-fairwaves-rebase.

-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co

 



More information about the OpenBSC mailing list