8 Mar
2014
8 Mar
'14
10:11 p.m.
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
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc. / ООО УмРадио
https://fairwaves.co
9 Mar
9 Mar
10:36 a.m.
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
11:29 a.m.
Hi Holger,
On Sun, Mar 9, 2014 at 10:36 AM, Holger Hans Peter Freyther
<holger(a)freyther.de> wrote:
On Sat, Mar 08, 2014 at 10:11:03PM +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.
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.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc. / ООО УмРадио
https://fairwaves.co
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.
11 Mar
11 Mar
3:10 p.m.
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.
3:21 p.m.
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREKAAYFAlMfG+0ACgkQC30ZhxNccpH8rgD9H9cVaZa+AyO5Xg0Z1UDqCBER
6sVj9/iWEVq6YBWkvloBAI6N+GR8gZ62Qf7mVnivRhn8Dw+PJBVCyiqwxwr92Oo2
=m+p9
-----END PGP SIGNATURE-----
5:22 p.m.
On Tue, Mar 11, 2014 at 6:21 PM, Ciaby <ciaby(a)autistici.org> wrote:
On 03/11/2014 03:10 PM, Holger Hans Peter Freyther
wrote:
[...]
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.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc. / ООО УмРадио
https://fairwaves.co
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? ;)
3710
days inactive
3713
days old
5 comments
3 participants
participants (3)
-
Alexander Chemeris -
Ciaby -
Holger Hans Peter Freyther