Hi Pasi, > > I'd like to see a status_report assembly similar to how the sms_assembly > > is done. This should exist in smsutil.c/.h so that we can easily unit > > test this functionality (which I would also like to see.) > > > > Another desirable feature for the status report assembly is to save off > > the status report fragments on disk, so that status reports (for > > multi-fragment SMSes) received across oFono / system reboots and crashes > > are handled appropriately. > > Could you clarify a bit what do you mean by "status_report assembly > silmilar to how the sms_assembly is done"?
The function of sms_assembly is twofold: - It takes care of all the de-fragmentation logic and only gives back a list of sms fragments once the entire list is received. This is done outside of src/sms.c so that we can easily unit test this functionality and to keep clutter out of the main core logic. - It takes care of writing fragments out to disk, so that in case of reset / reboot the received fragments are not lost. This storage is keyed by the IMSI of SIM card, so even if the SIM is removed and a new inserted things just work. For status reports I'd like something similar. E.g. if I send a concatenated message with 3 fragments, and only 2 status reports come in before reboot, the next time I startup and receive the 3rd status report, the message state should be updated appropriately. > > Currently I have a belief that status-report, which relates to sent > concatenated message, does not know anything about other status-reports > which relate to the same concatenated message. I have to admit that I am > not sure if this belief is correct. Is it? You are correct in that each status report is handled / delivered separately. However, just relying on MR is not enough. If you're sending lots of messages it is quite easy to overflow the MR. So you must at least take the destination address into account. Also, for sms fragments containing a udh, you can set some bits indicating to the SMSC to preserve the outgoing headers. This way you can actually correlate the outgoing fragmentation information to the incoming status reports. See Service Center Control Parameters IEI. Whether this is useful in practice, I'm not sure... > > If the status-reports of the concatenated message know about each other, > then I might have some kind of picture what you are looking for concidering > the status_report assembly. Otherwise I am little bit lost what you are > after if my current solution does not satisfy you at all. If the SMSC sends you the original headers, then you have a pretty good chance of reliably correlating between sent message fragments and incoming status reports. If you don't, then fall back to the regular MR + destination address approach. The status_report_assembly can actually take some information as input. Such as the fragment concatentation header, message reference, outgoing address and expiration time. So in summary: - should be in src/smsutil.c - store intermediate state on disk and restore the state as needed on startup - takes mr + destination address into account - only notifies once all fragments are received or first fails Regards, -Denis _______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
