12 Sep
2013
12 Sep
'13
12:06 p.m.
Hi Andreas,
We were testing TCH/H yesterday and stumbled upon an issue when a call
is made between TCH/F and TCH/H.
- When the call is from TCH/F to TCH/H, it doesn't connect.
- When the call is from TCH/H to TCH/F, it connects, but voice
quality is bad - sounds like 50% packet loss.
Logs and localhost Wireshark captures of calls in both directions are here:
http://ipse.chemeris.ru/osmo-captures/dumps.tar.xz
Do you see what's wrong with them?
Our configuration was
* Dual-TRX with 1 TCH/F and 14 TCH/H channels. We have to keep some
TCH/F channels, since there are old phones which doesn't support
TCH/H.
* Codecs enabled were FR, AFS and AHS.
* LCR was connected to the MNCC socket, but in the case of
TCH/F->TCH/H call I didn't see it coming to LCR at all.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
16 Sep
16 Sep
3:27 p.m.
Alexander Chemeris wrote:
* LCR was connected to the MNCC socket, but in the
case of
TCH/F->TCH/H call I didn't see it coming to LCR at all.
hi alexander,
the case you described is a bit weird. as long as you use the "-m"
option of openbsc, you will get the mncc socket to be connected (as your
logs show). then every call setup is routed to LCR.
i cannot see a problem, since there are so many calls. it would help, if
you start all applications, then do one call (which does not connect)
and get a set of logs.
regards,
andreas
p.s. sorry for the late reply....
17 Sep
17 Sep
8:44 a.m.
Hi Andreas,
On Mon, Sep 16, 2013 at 5:27 PM, Andreas Eversberg <andreas(a)eversberg.eu> wrote:
Alexander Chemeris wrote:
Wireshark logs in the archive have only two calls (one in each
direction). You should be able to relate them to logs, correlating
Wireshark timestamps and timestamps in logs. You could enable absolute
time display in Wireshark for that purpose.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
* LCR was connected to the MNCC socket, but in
the case of
TCH/F->TCH/H call I didn't see it coming to LCR at all.
the case you described is a bit weird. as long as you use the "-m"
option of openbsc, you will get the mncc socket to be connected (as your
logs show). then every call setup is routed to LCR.
i cannot see a problem, since there are so many calls. it would help, if
you start all applications, then do one call (which does not connect)
and get a set of logs.
2:02 p.m.
Alexander Chemeris wrote:
On Mon, Sep 16, 2013 at 5:27 PM, Andreas Eversberg
<andreas(a)eversberg.eu> wrote:
Wireshark logs in the archive have only two
calls (one in each
direction). You should be able to relate them to logs, correlating
Wireshark timestamps and timestamps in logs. You could enable absolute
time display in Wireshark for that purpose.
i can see both calls. the first call "FR_to_HR-not_working.pcap":
the MO phone requests a channel with the request reference that TCH/H is
also supported.
the openbsc assigns a TCH/H channel.
the BSC find out that the phone supports only half rate V1 codec on
the connection timed out after service request.
the second call "HR_to_FR-working-bad_audio.pcap":
the MO phone requests a channel with the request reference that TCH/H is
also supported.
the openbsc assigns a TCH/H channel.
the MT phone gets paged with the information that TCH/F shall be used.
the MT phone requests a channel with the request reference that TCH/H is
also supported, but was paged with TCH/F only.
the openbsc assigns a TCH/F channel.
here are the problems:
the first call timed out, but i really don't the setup message. i
suggest to retry that call. maybe it was an issue cause by radio
interference (low MS power or high power, but too close to the bts).
the audio of the second call is bad, so do you use rtpbridge feature of
lcr? if so, how are the amr codecs define in openbsc.conf? be sure that
they are equal for AFS and AHS, since a bridge does not transcode.
also there is a general problem: the TCH/F is assigned for all MT calls
from LCR->BSC. there are cases where we don't know the phone's codec
support, unless we assign a channel and get setup information about
supported codecs. but we cannot get setup message before assigning a
channel. to solve this, late assignment is used. i suggest to use the
jolly/new_handover branch. (you also need handover branch of lcr.) even
with handover function disabled, it will do late assignment after codec
negotiation.
Alexander
Chemeris wrote:
> *
LCR was connected to the MNCC socket, but in the case of
> TCH/F->TCH/H call I didn't see it coming to LCR at all.
the case you described is a bit weird. as long as you use the "-m"
option of openbsc, you will get the mncc socket to be connected (as your
logs show). then every call setup is routed to LCR.
i cannot see a problem, since there are so many calls. it would help, if
you start all applications, then do one call (which does not connect)
and get a set of logs.
21 Sep
21 Sep
8:02 a.m.
On Tue, Sep 17, 2013 at 4:02 PM, Andreas Eversberg <andreas(a)eversberg.eu> wrote:
the first call timed out, but i really don't the
setup message. i
suggest to retry that call. maybe it was an issue cause by radio
interference (low MS power or high power, but too close to the bts).
Radio is fine and the issue was 100% reproducible.
the audio of the second call is bad, so do you use
rtpbridge feature of
lcr? if so, how are the amr codecs define in openbsc.conf? be sure that
they are equal for AFS and AHS, since a bridge does not transcode.
Rtpbridge was off.
Codecs where set to "fr afs ahs", since we don't want to cut off
phones without AMR support.
also there is a general problem: the TCH/F is assigned
for all MT calls
from LCR->BSC. there are cases where we don't know the phone's codec
support, unless we assign a channel and get setup information about
supported codecs. but we cannot get setup message before assigning a
channel. to solve this, late assignment is used. i suggest to use the
jolly/new_handover branch. (you also need handover branch of lcr.) even
with handover function disabled, it will do late assignment after codec
negotiation.
We could try that, but I think the issue is elsewhere, as everything
works in single-trx mode.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
4:39 p.m.
Alexander Chemeris wrote:
We could try that, but I think the issue is elsewhere,
as everything
works in single-trx mode.
dual-trx seems to be the issue. i would like to try that
out. the
problem is that i have two umtrx, one has bad reception, but dual trx
work (the first one you sent me), the second umtrx works good, but there
is no rx/tx on second trx (second transceiver keeps cold).
you offered me to repair the umtrx. i would like to send back the first
umtrx, so you can check it. i could also send you both umtrx for a
check. can you provide shipping address?
22 Sep
22 Sep
1:28 p.m.
On Sat, Sep 21, 2013 at 6:39 PM, Andreas Eversberg <andreas(a)eversberg.eu> wrote:
Alexander Chemeris wrote:
The second case is weird, since we test both channels at the fab.
You're sure that you're using the latest stable firmware, latest
UHD-Fairwaves and osmo-trx with "umtrx_dual_test" branch?
Have you tried to check the second channel with GnuRadio or
rx_samples_to_file or tx_waveforms console utils? If this doesn't work
- send it to us for repair. May be something was damaged during
transportation.
We could try that, but I think the issue is elsewhere, as everything
works in single-trx mode.
dual-trx seems to be the issue. i would like to try that out. the problem is
that i have two umtrx, one has bad reception, but dual trx work (the first
one you sent me), the second umtrx works good, but there is no rx/tx on
second trx (second transceiver keeps cold). you offered me to repair the umtrx. i would like to
send back the first
umtrx, so you can check it. i could also send you both umtrx for a check.
can you provide shipping address?
I will send in a separate e-mail.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
3871
days inactive
3881
days old
6 comments
2 participants
participants (2)
-
Alexander Chemeris -
Andreas Eversberg