On Mon, Nov 14, 2016 at 02:55:30PM +0000, Mrinal Mishra wrote: 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. Since the ip.access nanoBTS is not capable of TCH/H, it is pretty much the only hardware where you actually want to use TCH/F_PDCH. Nevertheless, if TCH/F_PDCH is broken for other BTS models that support it, it should be fixed. Of course TCH/F_PDCH is a valid channel configuration, which you may use if you insist on TCH/F -- as long as it is implemented for your BTS model. There is no unit test available. Testing pchan types involves using a NITB and actual BTS hardware. At some point, we would like to test this in our osmo-gsm-tester setup, which still needs a lot of work. See: https://osmocom.org/projects/cellular-infrastructure/wiki/Roadmap#Build-and… Kindly state which BTS hardware you are using. And I am looking forward to your logs and/or bisect, if you can spare the time. As always, let me plug the possibility of directly sponsoring any of above mentioned issues via sysmocom, to anyone reading this and interested in quick progress. ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

On Mon, Nov 14, 2016 at 07:59:16PM -0800, Alexander Chemeris wrote: IMHO twice the number of timeslots qualifies for saying "more efficiently using the available timeslots" :) But thanks for this clarification. My impression so far was that AMR on TCH/H has fair enough quality that the voice call experience isn't noticeably different to TCH/F and "everyone is using it anyways"...? Also how do "people use" TCH/F? Is it a choice the MS user is able to make? Or is this always a choice on the CN side? ~N -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

I have tested the CS voice call using 1 TCH/H channel in osmo-bts-trx using USRP B210 board and CS voice call was not successful. When I configure 2 TCH/H channel in the TRX then CS voice call works fine. BSC commit version used was " 87ef68eb33d463d8aad1511a272cbdb779f1ba19" As per your explanation 1 TCH/H channel is sufficient for 1 CS voice call( Mobile originated and Mobile terminated CS call). Please correct me if I am wrong. Thanks and Regards, Mrinal

On Tue, Nov 15, 2016 at 10:32:59AM +0100, Neels Hofmeyr wrote: this is true. the concern is primarily about handsets too old to support AMR, so they would only be able to do HRv1. And that is really crappy. So on such handsets, you typically try to fall back to TCH/F. At least whenever I did traces here in Berlin with German operators, it was pretty standard that AMR/HR was used at all time [with phones that support it], irrespective on which Operator. please see the various discussions and tickets on codec selection. * the MS reports its codec capability * the BTS has a codec capability * the BSC and MSC/MGW might have codec capabilities * there is operator policy involved so you need to find the common codec sub-set accross all components in the path, and then take operator policy into consideration, as well as current channel load in the cell, etc. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)