Hi Mikhail, > > Am I right in assuming that the SMS history roundtrip is not performed before > acking the constituent TPDUs to the network? If it is, we have problems even > regardless of D-Bus method call timeouts. >
This has been discussed to death a bazillion times. So lets recap very quickly: AT modems have two ways of delivering SMS messages: - CMTI - CMT CMTI delivery means the message goes to the SIM / ME store first, and then signaled up. The modem takes care of automatically acking the message in this case. CMT delivery gives the message straight to the sms driver and expects messages to be acked. Here's the problem, half the modems in this world don't support CMTI delivery, the other half does not support CMT delivery. oFono core does not know or care what mechanism is used. It is the driver's responsibility to ack the received pdu. If CMTI delivery is used, then the core has to care about SIM / ME storage, reading of the SMS store and managing free space -> disaster area. Been there, got the t-shirt. If CMT delivery is used, you have to ack the message in a 'reasonable' period of time. If you do not, then the modem silently (e.g. it does not tell you) turns off SMS delivery. Of course you can send a negative ack, however, there is no mechanism that I'm aware of to tell the network you can receive SMS messages again -> disaster area. Another fun fact about CMT delivery is that if you do not ack in a 'reasonable' amount of time, the modem _silently_ turns off SMS delivery. So putting acks over D-Bus is simply a bad idea. So oFono: 1. Parses the SMS 2. If the SMS is a multi-fragment SMS, it is written to store 2a. If the SMS is the last missing fragment goes to step 2b, otherwise goes to step 5 2b. re-assembles the sms and removes intermediate store 3. Signals the SMS over D-Bus / history 4. Returns control to the driver which is responsible for acking the SMS if needed. All of this happens synchronously. If oFono crashes in steps 1..3, the message is never acked. If your history plugin writes to its intermediate store (which it has to anyway) and fsyncs, there are no issues. So yes, there might be conditions where you crash before fsync really completes and you lose the SMS. However, there's nothing in the world you can do about this case anyway, since both the write and the fsync succeeded. > 1. The history service may be activated on demand by a well-known name. D-Bus service activation on system bus is not available, please stop bringing this up. > If this is in fact mandatory, we'll have problems in making telepathy-ring > serve as the history plugin. We want it in the storage path for architectural > simplicity: commhistory daemon is by design a Telepathy logger that works > basically the same way for all connection managers. > > 2. You don't want multiple entities to observe events pertaining to oFono > communication history and be able to control spooling while not being > regulated by oFono. > If this is a concern, I think it's outweighed by greater simplicity and > flexibility, and the idea that access policy should be defined outside of the > implementation. > > 3. For call history, you need reliable storage of call events before you can > proceed handling the call with the interactive client signaling. > I thought this is entirely up to the application and as such does not have to > be in scope for oFono. Correct me if I'm wrong. > Sorry but I do not understand the above two points. Can you clarify what exactly you mean here? The actual history storage is indeed not in scope of oFono. That is up to the system integrator to figure out. Regards, -Denis _______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
