sms bugfix

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.de
Sun Apr 17 18:06:54 UTC 2011


Hi,
* 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>


More information about the OpenBSC mailing list