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/.
Harald Welte laforge at gnumonks.orgHi mike, On Mon, Aug 24, 2009 at 04:05:43PM +0100, Mike wrote: > first let me say what a hugely impressive achievement OpenBSC is - I was > AMAZED to be able to get a test network up and running within a day, and make > a call from one handset to another! thanks :) > A slight problem though - I can only make ONE call. After that, I get > "CHANNEL ACTIVATE NACK CAUSE=0x30(Transcoding not available)" if I try > to make another call, or even if I just switch off a handset. I'm using > an IpAccess nanoBTS - is it likely that this is an IpAccess-specific > issue? This is really strange. I have not observed this problem. Until July I did a lot of development and testing on the nanoBTS. Though in August a lot of last minute code was written for HAR2009 and only tested on the BS-11. I am now again travelling and only have my nanoBTS with me. I can give some testing, but maybe somebody else on the list can confirm that the current git version works well on nanoBTS, too. > I'm still at an early stage in understanding the OpenBSC code, but in time I > hope to be able to contribute some patches... that's great, thanks a lot for wanting to help out! It would also be interesting to know what exactly you're using it for :) > The information contained in this message (and any attachments) may > be confidential and is intended for the sole use of the named addressee. > Access, copying, alteration or re-use of the e-mail by anyone other > than the intended recipient is unauthorised. Are you aware that you are posting to a publci mailinglist with a large number of subscribers, whihc has a public, world-readable archive? > (wait a while, then try making another call) > > Mon Aug 24 15:30:04 2009 <0010> abis_rsl.c:1110 Activating ARFCN(600) TS(2) SS(0) lctype TCH/F chan_nr=0x0a r=OTHER ra=0xfd > Mon Aug 24 15:30:04 2009 <0010> abis_rsl.c:943 channel=(bts=0,trx=0,ts=2) chan_nr=0x0a CHANNEL ACTIVATE NACK > CAUSE=0x30(Transcoding not available) Mon Aug 24 15:30:14 2009 <0010> abis_rsl.c:667 RF Channel Release CMD channel=(bts=0,trx=0,ts=2) chan_nr=0x0a > Mon Aug 24 15:30:14 2009 <0010> abis_rsl.c:943 channel=(bts=0,trx=0,ts=2) chan_nr=0x0a RF CHANNEL RELEASE ACK > > (wait a while, then try making another call) > > Mon Aug 24 15:30:34 2009 <0010> abis_rsl.c:1110 Activating ARFCN(600) TS(2) SS(0) lctype TCH/F chan_nr=0x0a r=OTHER ra=0xe7 > Mon Aug 24 15:30:34 2009 <0010> abis_rsl.c:943 channel=(bts=0,trx=0,ts=2) chan_nr=0x0a CHANNEL ACTIVATE NACK > CAUSE=0x30(Transcoding not available) Mon Aug 24 15:30:44 2009 <0010> abis_rsl.c:667 RF Channel Release CMD channel=(bts=0,trx=0,ts=2) chan_nr=0x0a This message definitely relates to the speech encoding algorithm that we specify in ipaccess BIND and/or CONNECT. Maybe the BTS keeps track of the transcoding that we specified the last time, and now we are asking it to use a different codec? Basically the BTS thinks that the IP/UDP/RTP side is configured to use one codec (e.g. FR) and the RF side is nwo configured to a different codec (e.g. EFR). Since the BTS does not have a transcoder, it rejects it. Maybe this helps you to debug... basically there are three parts where the same codec needs to be used 1) in the 04.08 bearer capability 2) in the RSL channel activation (RF side activation) 3) in the ipaccess bind and connect. Regards. -- - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)