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.comOn Mon, Nov 14, 2016 at 5:42 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote: > On Mon, Nov 14, 2016 at 02:55:30PM +0000, Mrinal Mishra wrote: >> As per the channel configuration defined in the code TCH/F_PDCH is a valid >> channel configuration and it should work as TCH/F or PDCH channel >> dynamically. I tested even with TCH/F_TCH/H_PDCH and it works fine only as >> TCH/H or PDCH it does not get used as TCH/F. > > I am glad to hear that TCH/F_TCH/H_PDCH works as TCH/H. > The reason why this pchan type is not used as TCH/F is OS#1778 > https://osmocom.org/issues/1778 > > Fixing OS#1778 is not a top priority at the moment. The perspective that TCH/H > is more efficiently using the available timeslots than TCH/F and the fact that > most MS are capable of TCH/H makes this not very urgent. The reason why people use TCH/F is because it offers higher quality than TCH/H. E.g. if you're using AMR, you can go only up to 7.95 mode in TCH/H (see https://en.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_codec). So just saying that TCH/H is "more efficient" is not correct. It's more efficient in exchange to some loss in quality. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co