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 Zecke,
On Wed, Sep 30, 2009 at 04:12:36AM +0200, Holger Freyther wrote:
> I would like to implement the following.
> - Remove the refcount from lchan
> - Replace it with the "transaction" concept. On certain 04.08 messgaes
> (e.g. paging response, various MM messages) open a transaction
> from BSC to MSC code. The channel is bound to the transaction.
yes, this makes a lot of sense, of course.
> The lchan is getting released when the transaction is finished, in
> case of the "RSL chan" is going away too early there will be a
> "clear" signal/method called from the BSC and the MSC side is asked
> to let it go.
well, what we need to somehow ensure is a situation where multiple transactions
are pending / ongoing for one MS, i.e. a call is already established (or in the
process of being established), while another call is to be signalled, or while
SMS are to be delivered, etc.
How would this fit into your new concept?
> The benefit of this:
> - BSC and MSC are better separated
> - My MSC code could wrap the transaction into a SCCP connection
> - Channel leak == transaction_free not getting called.
There is one additional benefit: faster clearing of channels. Right now,
we still keep the lchan open for a very long time even after e.g. location
update or MT SMS have completed. In a real network, those timeouts are at least
a factor of 10 faster. This also means that we're more susceptible to DoS until
we have quicker closing of lchans.
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)