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/.
Dennis Wehrle openbsc at wehrle.itHi Holger wrote: > Yes, please change the database. I think you want to increase the version of > the database schema but I would not worry about having a migration inside the > db.c code itself (we can have a script to update the schema and drop the SMS > table..). Ok, sounds good. But unfortunally i have no time for the next 2 weeks. Nico wrote: > Imho the current database scheme for SMS is rather suboptimal in general > because it attempts to mix incomplete sms encoding values with decoded > user data. As we have to properly encode the message anyway when sending > from the vty it seems only reasonable to me to store UDL in the db as well. > This way it is very easy to do the decoding/encoding step with the already > present data_coding_scheme value. > > But thinking more about this... does it really make sense to store > anything but control data and the actual PDU in the database? When sending > a message from the vty the message is encoded anyway, so just inserting > the PDU + control data should be sufficient. I'm not sure if OpenBSC has > to be aware of things like UDHI, UDH, PID and thelike. > > The only place where this is useful so far is for the debugging output. > But what about moving this decoding for mere visual purposes to > libosmocore completely and not store this information in the database at > all? > > Cheers > Nico > P.S. attached is a submit decoder I used in the past one > could use as a basis for the proposed libosmocore function. Thx for your explanatory notes. And thx for your code. I will see how i can use it. Harald wrote: > well, what you definitely want aside from the PDU is 'valid_until', which is a > result of PDU parsing... > > But yes, generally, > * there should be no decoded SMS in the database (and if it is, only for > debugging, i.e. no code should ever use the human-readable decode > * there should be no direct references to the subscriber table > (sender_id/receiver_id). Rather, the actual phone number (MSISDN) should > be used. I will keep this in mind. Best Regards Dennis