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