In a production system we should not store messages longer than needed, as it will quickly bloat our DB. In case one wants to store messages for debug purposes, we could add one of the following capabilities later: - hexdump to a log file - send to an SMPP entry on delivery - send to Wireshark
On Sat, Mar 08, 2014 at 10:11:03PM +0100, Alexander Chemeris wrote:
Good Morning,
In a production system we should not store messages longer than needed, as it will quickly bloat our DB. In case one wants to store messages for debug purposes, we could add one of the following capabilities later:
- hexdump to a log file
- send to an SMPP entry on delivery
- send to Wireshark
there are several aspects in "production". There is billing and privacy. For privacy we should clear the text/user_data after the SMS has been delivered. For billing one might need to keep the meta data up to X (e.g. 90) days. As we don't have a "CDR" mdoule the only way to handle it is to keep that in the DB.
So I wouldn't want to remove this right now.
holger
Hi Holger,
On Sun, Mar 9, 2014 at 10:36 AM, Holger Hans Peter Freyther holger@freyther.de wrote:
On Sat, Mar 08, 2014 at 10:11:03PM +0100, Alexander Chemeris wrote:
In a production system we should not store messages longer than needed, as it will quickly bloat our DB. In case one wants to store messages for debug purposes, we could add one of the following capabilities later:
- hexdump to a log file
- send to an SMPP entry on delivery
- send to Wireshark
there are several aspects in "production". There is billing and privacy. For privacy we should clear the text/user_data after the SMS has been delivered. For billing one might need to keep the meta data up to X (e.g. 90) days. As we don't have a "CDR" mdoule the only way to handle it is to keep that in the DB.
So I wouldn't want to remove this right now.
If you want billing, you could route all messages to SMPP, route/ACL/bill there and send them back to the internal SMSC. That's what Rhizomatica guys are doing and it works well. In this outside SMPP entity you could do whatever CDR and storage you want, without touching the OpenBSC code, which is in line with our discussions with Harald.
PS I have more DB changes pending. One is storing Message Reference in the DB to be able to generate delivery reports (commited to my branch). The other is not finished yet, which will allow store delivery reports in the DB.
On Sun, Mar 09, 2014 at 11:29:09AM +0100, Alexander Chemeris wrote:
If you want billing, you could route all messages to SMPP, route/ACL/bill there and send them back to the internal SMSC. That's what Rhizomatica guys are doing and it works well. In this outside SMPP entity you could do whatever CDR and storage you want, without touching the OpenBSC code, which is in line with our discussions with Harald.
The same argument applies to your initial patch. I am not comfortable with deleting SMS from the database right away. I understand the privacy issue we have for XX3C events where we would want to clear the user content after the SMS has been sent. And I understand the need for cleaning the DB to save space. But the immediate removal troubles me.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 03/11/2014 03:10 PM, Holger Hans Peter Freyther wrote: [...]
The same argument applies to your initial patch. I am not comfortable with deleting SMS from the database right away. I understand the privacy issue we have for XX3C events where we would want to clear the user content after the SMS has been sent. And I understand the need for cleaning the DB to save space. But the immediate removal troubles me.
Could it be defined as a config option? ;) Cheers
Ciaby
On Tue, Mar 11, 2014 at 6:21 PM, Ciaby ciaby@autistici.org wrote:
On 03/11/2014 03:10 PM, Holger Hans Peter Freyther wrote: [...]
The same argument applies to your initial patch. I am not comfortable with deleting SMS from the database right away. I understand the privacy issue we have for XX3C events where we would want to clear the user content after the SMS has been sent. And I understand the need for cleaning the DB to save space. But the immediate removal troubles me.
Could it be defined as a config option? ;)
Yeah, I think I'll add a config option for that. It'll take some time, as I'm swamped with e-mail after two weeks of travel now.
-
Alexander Chemeris -
Ciaby -
Holger Hans Peter Freyther