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/.
Andreas Eversberg andreas at eversberg.euAlexander Chemeris wrote: > On Mon, Sep 16, 2013 at 5:27 PM, Andreas Eversberg <andreas at 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.