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/.

Dennis Wehrle openbsc at wehrle.it
Tue Apr 19 10:24:17 UTC 2011


Hi

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





More information about the OpenBSC mailing list