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.
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....
Hi Andreas,
On Mon, Sep 16, 2013 at 5:27 PM, Andreas Eversberg andreas@eversberg.eu wrote:
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.
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.
Alexander Chemeris wrote:
On Mon, Sep 16, 2013 at 5:27 PM, Andreas Eversberg andreas@eversberg.eu wrote:
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.
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.
On Tue, Sep 17, 2013 at 4:02 PM, Andreas Eversberg andreas@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.
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?
On Sat, Sep 21, 2013 at 6:39 PM, Andreas Eversberg andreas@eversberg.eu wrote:
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).
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.
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.
-
Alexander Chemeris -
Andreas Eversberg