RE: [RFC 0/1] use fsync in storage
Hi, On 08 Feb 2011, Zabaluev Mikhail (Nokia-MS/Helsinki) wrote: I would use fdatasync(). What about ensuring that file metadata are synced as well (e.g. the file itself cannot be lost on the filesystem)? Rémi already responded about fdatasync semantics, but I do wonder a bit about directory flushing (or lack of it). Many filesystems implement special-casing for rename() which in practise solves the problem, but current ofono code does not actually call rename but instead 'link(tmp,real);unlink(tmp)'. This is ok for transaction safety, but possibly problematic for data safety. So AFAIU, even if we flush tmp (with the patch I sent today), and hardlink, the directory inode might not be flushed for a long time. And I just noticed that e.g. btrfs (which is the default in e.g. MeeGo) does not special case rename() in case destination is not overwritten (but it does have a special case for the overwriting-rename case - https://btrfs.wiki.kernel.org/index.php/FAQ). So just using fdatasync+rename won't solve all cases either. Hmm, so fdatasync on the file, rename and fsync on directory should be ok then. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC 2/2] doc: Add description for history agent interface
Hello Marcel, On 02 Feb 2011, Marcel Holtmann wrote: - This relates to another TODO - persistant storage of RX-TPDUs for incomplete messages. If we've acked a TPDU to network, we must have stored it to persistant storage. Where are we not doing this. We do store the fragments. If it is a complete message, we signal it directly. my mistake. I got this impression from some recent discussion on #ofono (related to the recent patches for TX spooling from Lucas De Marchi), and with that in mind, failed to look up what sms_assembly_add_fragment() really does in the end. I thought it was in-memory stuff only, but oh no, commit 06ea6137a30944855ebafe0c8abfb2285eac74b5 added fragment spooling (already in 2009!), so forget this part. - The history agent does not wait until the agent replies it has handled the message, but instead it calls agent_request_dispatch and then already returns to core (which acks the message to modem). I know this actually. The missing piece is the storing to disk here to spool the SMS history and call history in case no agent is present. Ok. I just didn't see any mention of disk/file spooling in this patchset (nor in other existing plugins except the out-of-tree smshistory) one, and was not sure whether it is proposed to have spooling before or after the DBus hop. But yes, if indeed your intention was specifically to add spooling to the ofono-side plugin already, I agree that would work. Although, the plugin needs to store to disk _always_, even if agent is available. Or wait until the Dbus method reply is received (which I don't think is feasible). Otherwise following can happen: - history_sms_received() called - agent available, MessageReceived() called not async so not waiting for reply - history_sms_received() returns to src/sms.c, TPUs cleared/acked - zap, out of battery - message potentially lost This can be solved by spooling always. I'd prefer to have something like: http://people.freedesktop.org/~wjt/telepathy-spec- import_stored_messages/spec/Connection_Interface_Stored_Messages.html How is this any better? If all messages get send when the agents registers to oFono. And we can easily use D-Bus results to either delete messages from the spool or not. Since D-Bus is asynchronous and that will just work out fine. Your plugin patch did not have/mention this functionality (message goes to /dev/null if no agent is registered), but if this is supposed to be there, then agreed, this'd work. So I think this comes down to how the history agent acknowledges the messages over DBus. E.g. single DBus MessageReceived method with ok/nok response, or an explicit acknowledge method/signal (the StoredMessages telepathy implements the latter approach). The main functional difference is the possibility to have multiple agents (as Mikhail noted), but this is perhaps something to debate whether it is really needed or not. Otherwise, what I'm still not sure about is whether it's sane to have possibly very long req-reply roundtrips, and e.g. multiple pending calls of e.g. MessageReceived waiting for reply. I know it _can_ be done, but is it a robust design and will it cause grey hairs to agent implementors.. (I know many dbus bindings have default timeouts of roughly ~30s for method calls - dunno if this can cause havoc). I freely admit my dbus skills/experience is not sufficient, so feedback is welcome. Based on my very informal poll, more people have voted for explicit acks in Telepathy style, but not all, so good arguments for/against are welcome. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC 2/2] doc: Add description for history agent interface
Hi Denis, On 02 Feb 2011, Denis Kenzior wrote: 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. ack, very much agreed. And now that I realized RX fragment spooling is in fact already done (sorry for the hassle), all is good then for this part. 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. So as long as the history plugin spools the message before returning back in (4), the whole path is safe. One corner case missing is: 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. So as ofono_sms_deliver_notify() never returns an error, we can't handle the case where e.g. device has run out of storage, or other severe malfunction (some system component crashed). I guess the main worry is to stop messages going to /dev/null, and less about how to recover. I think these cases are of such severity that the user must anyways at least reboot the device, or even have to take it to customer care (or something in between). Just with normal device usage (e.g. by trying to fill device with user content), this should never happen, so the reason must be something more fatal. So handling this might still be useful even if reliable re-enabling of messages would not work reliably (assumption being that recycling and reregistering will reliably reenable message delivery). Or do you have practical experience of cases where even a power cycle won't help... (e.g. 23.040 specificly handles this scenario so modems should handle this correctly)? Oh well, I have to ask around about this as well... perhaps something we could ignore. 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. I think this is perfectly reasonable. Even if some storage system had some internal caches outside the kernel sync's reach, I'd imagine flushing these would be a prime candidate for last-minute actions done before battery dies (or some sensor detecting the device is about to hit a brick wall in about a few milliseconds ;)). And in general, fsync should just be enough: http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/ ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH v3 2/2] plugins: add ctm create to ifx plugin
Hi, On 14 Jan 2011, Marcel Holtmann wrote: #include drivers/atmodem/atutil.h @@ -700,6 +701,7 @@ static void ifx_post_sim(struct ofono_modem *modem) DBG(%p, modem); +ofono_ctm_create(modem, 0, ifxmodem, data-dlcs[AUX_DLC]); so no emergency calls with CTM are possible? Or do we have to potentially also handle that? a very good point! So yes, TTY-enabled emergency calls are definitely needed. And in fact, that's probably one of the _most_ important use-cases for TTY there is (as you cannot send an SMS to the emergency center [1]). [1] well, actually there are specs for this, and even trials, but it'll take ages before this gets widely deployed ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC 3/5] voicecall: Add ofono_voicecall_tty_notify api
Hello Marcel, On 12 Jan 2011, Marcel Holtmann wrote: Are we expecting that all modems will just establish a normal voice call and only later on signal that it is a TTY call? Any input from different vendors other than IFX. What about STE, ISI? not later, but as part of standard call setup. E.g. on ISI, CTM is a property of a voice call. And this makes sense as TTY calls _are_ essentially voice calls, with just a bit indicating to the network that the voice circuit should be free of any transcoder/audioprocessing/etc that is not compatible with CTM. And this is negotiated as part of standard call setup (same way as supported codecs). My understanding so far has been that TextTelephony.Enabled=TRUE means that the CTM bit is set in all subsequent MO calls, and it is set by default when answering to MT calls. And the one special case is receiving a CTM-enabled call when TTY is not enabled (in oFono). In this case it should be possible to enable TTY (for at least that call) and respond to the call (and ifxmodem seems to provide support for this scenario). This should be standard stuff to all modems as this is a heavily regulated feature. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 1/2] Expose voice call direction synchronously
Hi,
On 10 Jan 2010, Rémi Denis-Courmont wrote:
Currently, the call direction can only be inferred from the signals.
This adds a property to keep it visible also from GetCalls().
just adding one more do { ++votes; } while(0) for this.
telepathy-ring needs this as well when it is (re)started and there
are existing calls:
https://bugs.freedesktop.org/show_bug.cgi?id=32990
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: Discussion on CTM enhancement
Hi, On 22 Dec 2010, Predon, Frederic wrote: 1) First, it might a good proposal to merge the TextTelephony and the AudioSettings atoms. Enabling and disabling CTM on a platform require to configure the audio settings on the modem side (audio routing parameters changes). Today, in my patches, I have nearly the same code this area is slightly confusing as there are many atoms related to calls (e.g org.ofono.CallVolume, AudioSettings, CallSettings). The AudioSettings is AFAIK meant for modems where the audio is routed to/from the host (e.g. N900/isimodem or ifxmodem), and to me it would be a good idea to keep it clean (only features that affect modems of this type). Controlling TTY/CTM applies to all kinds of modems, independently of how they manage (or don't manage audio), so that to me hints that the TextTelephony should be a separate atom. Of course if the CTM implementation needs cooperation with the host audio stack (in case host is involved in the audio path), then CTM support will impact other atoms as well (AudioSettings in case of ifxmodem). 2) Secondly, I think that 2 properties can be added in the TextTelephony atom and/or the AudioSetting atom (or the merged atom described in 1). The first property is when the device receives an incoming CTM call. Even if the type is still a voice call, upper layers Now continuing the above reasoning, I'd say this should go to TextTelephony as modems not implementing AudioSettings can still implement this, and this property is useful to show in the UI despite the audio implementation details. But as the ifxmodem interface is per-call (I guess this maps to the CTM bearer capability flag in SETUP and its replies), this could perhaps be a property of org.ofono.VoiceCall as well. The second property is for MO calls. Remote user can accept the call as a TTY enable device or not. This is supported by the standard. In our So same for this (either to TextTelephony, or perhaps also a property of voicecalls). ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Voice call audio routing
Hi, On 16 Dec 2010, Nicola Mfb wrote: While testing an e169 huawei card I was able to make voice calls and hear something with aplay and /dev/ttyUSB1. On the openmoko/freerunner is a matter of HW switches, on the n900 IIRC is done with pulseaudio. I guess that voice call audio routing is not in oFono plans, if I'm correct is there a reference project (may be not depending deeply on meego) that abstracts that task in an extensible/pluggable way? not really I'm afraid, no reference project yet. The MeeGo stack for N900 is the closest thing at the moment: http://wiki.meego.com/ARM/N900/Features/CallAudio There's nothing inherently specific to MeeGo in the above, but of course some parts of it are very specific to N900 and its modem. Fortunately these are mostly isolated into a separate PA modules (so the rest of the stuff could be shared with other modems). More generally, the speech interface to modems is currently not at all standard, and the differences are fairly big among the current modems that supports this (the low-level hw interfaces are different, the protocols are different, the kernel drivers are different and so forth). E.g. USB might be used as the interface in dongles for laptops, but it is not really suitable as the primary interface when building a phone (it might be used as a secondary channel to record calls, but that's different). USB audio can still be supported of course, but just as an example why not all modems will have an interface such as the e169 has. But e.g. if you got the e169 working with aplay, then in theory it fits quite nicely to the N900 stack mentioned above. The same pipeline (on N900) is already used for CS (with the device modem) and VoIP calls (with gstreamer/farsight), so architecture is in that sense ready to support other network source/destinations for voice streams. The integration to oFono AudioSettings interface is also there (so that the audio pipeline is automatically set up when there is a call). br, -- Kai Vehmanen ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 0/5] Call Counters (2nd)
Hello Marcel, I'll answer to two separates mails (of this thread) in one go: On 10 Dec 2010, Marcel Holtmann wrote: Kai Vehmanen wrote: So whether this code is in oFono or elsewhere, does not matter much (to overall power consumption). The main question is of course how often the counters are synced. actually it does matter since you have no extra context switch and in addition you not accidentally wake up PA and then ofonod. You have one centralized wakeup of one thread. You cannot do this with one thread wakeup. The real-time parts implementing voice data path in pulseaudio (and ones waking up to hw interrupts) need to follow soft-realtime practises to maximize execution determinism. I.e. these threads are run with SCHED_FIFO/RR and any calls to possibly-blocking system calls must be avoided (this includes dynamic memory allocation, access to file/sokcets, etc, etc). See e.g. JACK audio server project's guidelines for client apps for a good overview of what these limitations mean in practise. Storing the call counters requires file/socket i/o, so doing this from a real-time thread is a big no-no (and if done anyways, would be a likely cause to audio hickups). So you need to wake up another thread in any case (e.g. PA has separate threads for DBus and talking to PA clients). Of course an explicit wake-up is better than relying on timer slack to coalesce the wakeup of ofonod and pulseaudio, so I agree using a PA thread is technically better and more robust way to ensure no extra wakeups occur, but if/when implemented properly, waking up ofonod really has no penalty either. But the above is really a minor issue I think. I think the most important argument against doing this in PA is (quoting my earlier reply): --cut-- - lots of modems still handle all audio and PA will know nothing about calls at all with these modems --ct--- This needs to be done in a component that is tracking calls, independently of what modem is used. And then one further comment to a more recent mail in this thread: On 12 Dec 2010, Marcel Holtmann wrote: is actually everybody in agreement here that we talk about actual time spent on the phone talking? Denis and myself clearly see it that this is a sensible approach to overall call counters. And if that is the case, then this maps closely to what PA has to track anyway. No, no. Surely what matters are the individual calls, and their state w.r.t. signaling. And this is what the patches Andras' has sent are tracking. PA on the other hand tracks the traffic channel state and that cannot be used. E.g. in common real-life cases (handovers), the traffic channel can be temporarily disconnected during an active call (PA will see this, but it is _not_ visible in either the phone UI nor in billing). For to PA to implement call counters, it would have to be extended to track individual call state. Br, -- Kai Vehmanen ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 0/5] Call Counters (2nd)
Hello, On 11 Dec 2010, Denis-Courmont Remi wrote: let me repeat my question here. Does this suppose to be represent spent time on calls (what I called talk time) or actual billing minutes. As said earlier, this is about the talk time. The scenario is a user ejects the battery during an already long-standing call or gets the device to crash or reset, gets billed, and comes and complain to its operator that (s)he gets overcharged. The counters will be much more wrong if we do not I'm no longer sure what you guys mean with billing minutes and talk time here, so maybe we should talk in terms of code. E.g. look at the patches Andras sent to the list to see what is tracked and how: - each call is tracked separately (e.g. counter still running for held calls) - tracking separately for MO/MT calls - call starts when state goes to ACTIVE (from INCOMING/ALERTING/DIALING/WAITING) - call terminates to DISCONNECTED In case of conflict, what's actually in Andras' patches overrides my interpretation above. ;) This concept is already in oFono core (call-start_time is created when calls start, and __ofono_history_call_ended is called when calls end, matching the above). That said, I do believe the stored value has to be more precise than minutes. Otherwise per call error may add up far too quickly. Yes, but I agree with Marcel that a 60sec update interval sounds reasonable (so higher resolution for stored values, but updates at e.g. every minute). Even better if the refresh rate can be tuned. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 0/5] Call Counters (2nd)
Hi, On 09 Dec 2010, Marcel Holtmann wrote: - lots of modems still handle all audio and PA will know nothing about calls at all with these modems actually Denis raised the same question, but then again this is for a product specific requirement. And for that product we know that PA will do the audio processing. not really. We need modem adaptation for call counters and need an API that works with all modems. And I'd assume other handset vendors need such an API as well (either in oFono or somewhere else). Important for me is to weight the extra costs of IO and CPU consumption when doing this inside oFono. And since ofonod itself would actually not wake up during a phone call, I think this is not a good fit. I share the concern for the IO/CPU cost, but I don't think it matters much in which daemon this is done. Especially if some slack is allowed for the timers (which should be the case), ofonod will be scheduled when the CPU is anyways woken up (e.g. modem/audio interrupts wake up pulseaudio). So the big cost of bringing CPU, memories et al online are already taken at this point, and the additional cost of running ofonod for a while is minimal (compared to waking up some non-realtime thread of pulseaudio, or some other component, to do the same). But yeah, there is a IO/CPU cost in any case, I agree about that. Br, -- Kai Vehmanen ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 0/5] Call Counters (2nd)
Hello Marcel, On 09 Dec 2010, Marcel Holtmann wrote: I share the concern for the IO/CPU cost, but I don't think it matters much in which daemon this is done. Especially if some slack is allowed for the timers (which should be the case), ofonod will be scheduled when the CPU is anyways woken up (e.g. modem/audio interrupts wake up pulseaudio). this is not really true. We can not wakeup ofonod every single second. You might wanna start running powertop. uhm, but I'm not claiming that. I was just stating that moving the timers to e.g. pulseaudio in this case won't save much if anything (the CPU will be woken up anyways, and the cost between scheduling ofonod or a thread from PA, has really no difference to overall consumption.. the CPU is woken up anyways and roughly the same code to handle the timer is run). So whether this code is in oFono or elsewhere, does not matter much (to overall power consumption). The main question is of course how often the counters are synced. Personally I think the every-10sec interval is too short. It's also highly system specific when wakeups start to get too costly, so picking up one value seems difficult. br, -- Kai Vehmanen ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 0/5] Call Counters (2nd)
Hi, On 08 Dec 2010, Marcel Holtmann wrote: So I am actually thinking that doing that inside PulseAudio is a lot more efficient solution. The idea is that PA already runs in the user session and has to monitor the uplink/downlink state (and additionally could monitor call states as well if needed). So it knows when a call is active and it is active anyway doing the audio processing. So it could just then go ahead and write your call accounting into Tracker. Pulseaudio (or the meego PA modules for voice) isn't really an option for at least the following reasons: - lots of modems still handle all audio and PA will know nothing about calls at all with these modems - PA does not really care about individual calls, but whether the audio traffic channel is connected or not - multi-call cases, cases were traffic channel is reconnected mid-call, etc, etc, PA simply does not know enough (and should not) I guess this could be done in higher layers on top of oFono (telepathy-ring, dialer app, policy framework, etc), but I don't really know enough about the call timer stuff to comment on the pro/cons of this. br, -- Kai Vehmanen ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH v2 5/7] text-telephony: add documentation
Hi, On 23 Nov 2010, Lucas De Marchi wrote: +Interfaceorg.ofono.TextTelephony [...] +Properties boolean Powered [readwrite] + + This property will enable or disable the text + telephony feature in the modem. + + Text telephony (TTY), also known as TDD, is a feature + present in some modems that allow them to be used by + hearing impaired people. just to clarify, I guess this covers all aspects of TTY support handled by the modem? E.g. for modems, TTY/CTM support can mean: - signaling TTY/CTM support as a capability (e.g. in Bearer Capability of 24.008 at the start of calls) -all modems that support TTY do this - above plus: performing CTM coding on modem -some modems - above plus: handling audio input/output -some modems So depending on the modem, enabling TTY with this new oFono interface enables all of the above (those the apply), right? This makes sense as AFAIK there is no need to control the different aspects separately (and is analogous to handling voice calls in general with oFono), but just making sure I understand the semantics correctly. If in the future ofono clients need more information about the speech data path processing (w.r.t. TTY), that can be then added to org.ofono.AudioSettings interface (e.g. whether modem does CTM coding, whether it supports HCO/VCO (does voice go through at all when TTY mode is enabled). But until we have a modem (and use case) that needs this, it's too early to add these. E.g. Nokia N900 does not support TTY, but if the support was added, in theory it could technically do CTM coding both on modem and/or on Linux side. br, -- Kai Vehmanen ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 2/2] n900: Enable audio settings atom
Hi, On 01 Oct 2010, Kai Vehmanen wrote: Subject: [PATCH 2/2] n900: Enable audio settings atom plugins/n900.c |2 ++ FYI, I've now added a minimal test/example application, cmtspeech_test_ofono, to upstream libcmtspeechdata repository [1]. The app uses oFono (and the new audio settings atom) to set up the speech data path on e.g. Nokia N900 (currently libcmtspeechdata only supports the N900 modem speech interface, but the door is open to support other modems as well). In short, you run this app, make a call with oFono, and once the call is up, the test app simply loops back any audio from downlink to uplink (so the remote party will get its uplink audio routed back). The app is at: http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/utils/cmtspeech_ofono_test.c This might be useful if you want to test/develop oFono on N900, and/or for developing speech path support to other modems (either with libcmtspeechdata or with some other kernel/lib adaptation). PS On N900, you need to stop pulseaudio before testing as access to the speech path kernel driver is exclusive. [1] http://gitorious.org/+meego-cellular/meego-cellular/libcmtspeechdata Br, -- Kai Vehmanen ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
