17 Sep
2013
17 Sep
'13
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.