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.orgOn Tue, Jun 15, 2010 at 04:15:58PM +0800, Holger Freyther wrote: > Regarding new (SMS) code, the main lesson to learn is probably: Have > Success/Failure/Timeout in mind and free the channel in any of these > states... sure. The current SMS implementation was always only a quick hack to make it work at all. At some point, new code should be written with MAP SMS semantics in mind, i.e. anticipate that SMS are sent from an external process by procedures that resemble the SMS-MAP as defined in Section 4 of 03.47. I'm not referring to the actual encoding, but by the flow of events / procedures, i.e. : * Forward MT SMS * Forward MO SMS * SC Alert This basically means an external entity (the Service Center SC) sends a SMS to the MSC, identifying the subscriber by its MSISDN. The MSC needs to decide if there is already a radio channel or if it needs to do paging. It does the paging (if needed), delivers the message and if everything works fine, it reports back to the SC. The timer at the SC side is specified between 15 to 180 seconds in total. MO-SMS is relatively similar, but in inverse direction. The SC Alert seems to be used for notifying the SC that a MS (that previously was unreachable or had a memory-full condition) is now available again. -- - 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)