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/.
Nico Golde openbsc at ngolde.deHi, * Holger Hans Peter Freyther <holger at freyther.de> [2011-04-17 19:00]: > On 04/04/2011 05:27 PM, Dennis Wehrle wrote: [...] FWIW, your original patch and motivation also looks very reasonable to me! > > The best solution for that is to store the number of septets at the database > > (on the decoding process). Therefore i want to discuss if this is a suitable > > solution. If we don't want to change the structure of the database i could > > possible make a dirty hack (look if the "ud_hdr_ind" is set, get the "user > > data header length" (udhl) from the user_data, count the number of septets > > from "text - 1 - udhl - fill bits"). > > But i strongly recommend to change the database (i could do it). > > 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..). 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: decode_submit.c Type: text/x-csrc Size: 6104 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20110417/88f8cb8a/attachment.bin>