[PATCH 4/5] msc: Do not store received id in the SMS database.

[Alexander Chemeris]

On Tue, Oct 8, 2013 at 2:08 PM, Alexander Chemeris
<alexander.chemeris at gmail.com> wrote:
>
> On Tue, Oct 8, 2013 at 12:03 PM, Holger Hans Peter Freyther
> <holger at freyther.de> wrote:
> > On Tue, Oct 08, 2013 at 03:17:32AM +0200, Alexander Chemeris wrote:
> >> That was a bad idea from the very beginning. A visible result of this is a wrong
> >> SMS routing when you change subscriber extensions, while having queued SMS. It's
> >> also a very wrong thing from the code layering perspective.
> >>
> >> I think the next logical step should be to remove "receiver" pointer from
> >> the gsm_sms structure into a structure, special for the internal SMS queue.
> >
> > how much extra effort is it to remove ->receiver right now?
>
> We should create a new structure, new functions to
> create/free/populate it, and translate sms_queue.c to using it.

I looked into the code more closely and actually we already have a
gsm_sms_pending structure in the SMS queue implementation, which also
holds a pointer to the receiver subscriber. So the task is trivial
from the architecture perspective - just move from using the pointer
in the gsm_sms structure to using the pointer in gsm_sms_pending
structure. But this requires careful thought and thus still quite time
consuming.

On the similar venue, I'm thinking about delivering SMS to SMPP over
unstable links (e.g. satellite), where the link may be inaccessible
for non-negligible amounts of time. To make this usable, we need a
queue in front of the SMPP interface. I see two options - introducing
a dedicated queue for SMPP and modifying existing sms_queue to
support delivery not only to local subscribers, but to SMPP and other
future transports as well. I would be glad to know opinions on this.

-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru