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 Neels, as Holger has indicated, we definitely need to keep BS-11 compatibility. On Tue, Feb 09, 2016 at 10:30:15PM +0100, Neels Hofmeyr wrote: > Who is this Mister PCI anyway? ;) I just Googled 'Siemens Abis MRPCI' and found an old question + response I posted some years ago: http://www.erlang.com/forum/erlang/thread.htx?thread=3168 I don't think it neccessarily needs to be sent at a very specific point in time, but it needs to be sent after dedicated channel establishment and before T_MSRFPCI expires. However, to put reasonable values into the message, we need to know the classmark of the MS. > The gsm48_handle_paging_resp() function leads me to another, more general > question: often, there are two bts pointers around, namely the > gsm_subscriber_connection->bts > as well as the > lchan->ts->trx->bts > Are these typically/always/never expected to be the same bts struct? I would assume that both pointers are the same in all cases. > (In this function, both bts pointers are used, and I'd like to understand why.) When I created OpenBSC, we only had the lchan->ts->trx->bts pointers, and we had the subscriber point directly to the lchan. IIRC, Holger later introduced the subscriber_connection when he created OsmoBSC. So there might be some cases where a field was not removed but could be removed? The lchan/ts/trx/bts hierarchy is always present when a dedicated channel is established. It is a very BSC-centric data structure. The subscriber/subscriber_conn is a MSC-centric data structure. And basically on the BSC side we have lchan's that are mapped over the A interface to a subscriber_conn on the MSC side. Thus, the MSC shouldn't referernce the lchan. -- - 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)