**** BEGIN LOGGING AT Mon May 23 02:59:58 2011 May 23 08:36:17 akiniemi: ping May 23 10:09:19 aruravi: pong May 23 10:15:20 ping May 23 10:15:39 anyone that knows anything about the support of SIM atk in ofono? May 23 10:22:59 dylf1: you should probably wait a few hours for the US west coast to wake up May 23 10:23:10 ok. May 23 10:23:13 thanks May 23 10:23:22 bunch of folks are at the MeeGo conf that are in the know about STK May 23 10:34:33 akiniemi: regarding the patch i mailed last week. May 23 10:34:58 aruravi: yup May 23 10:35:34 aruravi: my main question was about the updating call reason when it is not going to be reported to core May 23 10:35:58 can that be removed, i.e., is this a final state, or is it going to be reported to core later? May 23 10:36:08 My understanding is that CALL_STATUS_TERMINATED, need to be handled for disconnect reason, because for error cases. May 23 10:36:46 or is it that the MT_RELEASE will always come for all cases, before moving to CALL_STATUS_TERMINATED and then to IDLE May 23 10:38:16 core needs only IDLE as other states are not there for +CLCC May 23 10:38:38 i mean the MT_RELEASE, CALL_STATUS_TERMINATED etc May 23 10:39:06 What was the original problem your patch was fixing? May 23 10:39:30 Was it that a disconnect was getting reported twice, i.e., MT_RELEASE and TERMINATED? May 23 10:40:01 https://bugs.meego.com/show_bug.cgi?id=17403#c6 May 23 10:40:52 comment 6, was the analysis May 23 10:41:06 where the missed calls are notified only if the previous call status is May 23 10:41:07 incoming or waiting. May 23 10:41:39 for isimodem, the previous status is not incoming or waiting, but release states May 23 10:42:56 Ah, I see. So that is what the first hunk of the patch is fixing. May 23 10:43:17 That looks fine. May 23 10:45:42 so i need to fix only the white space issue right? May 23 10:48:34 I would still add at least some clarifying comment on why on MT_RELEASE the disconnect reason is set, but the status is not reported to core May 23 10:48:52 (that is, because it will ultimately be reported once TERMINATED) May 23 10:50:59 (or the other way around, but you get my point ;) May 23 10:51:22 oh ok, i shall add that.. May 23 15:30:05 denkenz: ping May 23 15:30:14 fdalleau: pong May 23 15:30:32 hi, there is an CE4A item in the TODO May 23 15:31:18 the item states : support extensions to HFP emulator, does it mean have a mechanism to support extensions? or effectively implement the CE4A AT commands? May 23 15:31:55 Can be either, depends on the particular feature May 23 15:32:05 Though CE4A commands are mostly rubbish May 23 15:32:39 since plugins can register AT commands already, the mechanism to support extension can be said done May 23 15:33:17 That particular task is just about supporting CE4A extensions to HFP May 23 15:33:49 Not really about our internal implementation May 23 15:33:54 so it means adding the extra AT commands, like AT+CGMI AT+CIMI AT+CPBS= May 23 15:33:54 May 23 15:34:00 And yeah, the wording can be a little better May 23 15:34:11 yep, basically May 23 15:36:30 There are some commands for phonebook access May 23 15:36:44 do you have any ideas already about these ? May 23 15:36:59 or simply leave this to PBAP? May 23 15:37:26 Nothing really concrete May 23 15:37:50 The last time we talked about this with Johan and Marcel there was a heated discussion May 23 15:38:18 I think just supporting the SIM contacts would be where I start May 23 15:39:32 do you think sim contacts could be used to implement ATD> since this is a mandatory command? May 23 15:41:18 We have to figure out what 'mandatory' means here May 23 15:41:58 I mean mandatory for HFP specification May 23 15:42:20 yeah I know, but there's mandatory and there's 'mandatory' May 23 15:42:26 ;) May 23 15:42:48 As long as there is a PTS test for it, it has to be implement, even in a very simple form May 23 15:44:03 What does the PTS test do? May 23 15:44:14 e.g. is reporting invalid index error enough? May 23 15:44:42 i don't think so, let me check that May 23 15:48:01 This feature pretty much assumes one has PBAP support or somehow the user magically remembers their index locations May 23 15:50:17 ok so there are two test : May 23 15:50:28 one checks that a number at a specific location can be called May 23 15:50:44 one checks that if there is no number at a specific location, then there is an error May 23 15:51:07 if you always say error, first test will be inconclusive but the other will pass May 23 15:51:54 However, the range of the memory positions is fully product dependent May 23 15:52:28 I mean worst case we can make our ATD only accept index 1 May 23 15:52:36 and stuff something in there May 23 15:52:48 having position 0 doing dial last number could be enough to pass the test in PTS May 23 15:52:52 similar to what BlueZ does, they just use a voicemail box environment var May 23 15:53:00 Or even that May 23 15:53:05 denkenz: It was just supporting SIM phonebook read for SIM contacts only. May 23 15:53:17 Which is funny since we will not be using the SIM phonebook. So you get an empty list. May 23 15:53:54 holtmann: The CE4A stuff? May 23 15:54:04 Yes. May 23 15:54:28 well you could get SIM contacts if your SIM was pre-populated May 23 15:54:40 but yeah, overall a stupid feature May 23 15:59:29 maybe having something hackish into ATD>0 stuff could be discussed with a certification organism as long as the protocol is ok, but that doesn't solve the issue for CE4A May 23 16:03:09 CE4A is not a priority now anyway May 23 16:03:25 for sure May 23 16:03:52 It is an old Nokia standard, and doubt anyone cares these days May 23 16:05:44 Car manufactures want PBAP and MAP. May 23 16:05:56 Just do the BlueZ style hack for memory dialing May 23 16:05:57 CE4A AT commands is pretty much pointless. May 23 16:06:37 You can add new API to sim atom to request the voicemail box number May 23 16:06:56 Or do the last dialed number thing you wanted May 23 16:07:10 No headset is going to use this anyhow May 23 16:07:42 the voicemail seems a good idea May 23 16:08:30 holtmann: that's good to know for sure, in this case do you mind some cleanup in TODO file? May 23 16:09:06 You can leave things in the TODO, but mark them as low priority or just add a comment to it. May 23 16:09:25 I personally prefer even having long time or future or maybe tasks in the TODO to just remind us. May 23 16:09:37 So just go ahead and send patches for it. May 23 16:09:45 ok i'll do that May 23 16:12:49 holtmann: denkenz: since you are both there, for testing with PTS, i'm still using an agent design May 23 16:14:17 I need to connect from oFono to PTS, and also disconnect May 23 16:14:53 'agent design'? May 23 16:15:27 exactly what gustavo did for Handsfree May 23 16:16:05 bluez handles profile registration and just send the fd to oFono for AT commands processing. oFono register an agent to BlueZ to be notified May 23 16:17:08 ah, is the current design not good enough? May 23 16:17:51 current design is able to receive incoming connections May 23 16:18:29 Ah you want to test AG-initiated ones May 23 16:18:30 but testing with PTS requires being able to establish connection to a remote handsfree device May 23 16:18:39 denkenz: right May 23 16:19:08 So the big issue here is that if we move this to BlueZ, we need to rip out audio/telephony-* May 23 16:19:22 not really May 23 16:19:29 So that is a can of worms I wanna postpone ;) May 23 16:19:47 we don't _have_ to, but we should and we will May 23 16:19:54 Vudentz proposed to add a RegisterAgent/UnregisterAgent method to existing Headset implementation May 23 16:20:37 if the agent is registered, then oFono can receive the socket May 23 16:21:01 if the agent is not registered, then whatever plugin is configured in BlueZ can be used May 23 16:21:20 BlueZ has only ~7 or so releases to go until 5.0 May 23 16:21:30 After that I think we can rip all of this stuff out May 23 16:22:23 So I'd just do this properly from the beginning May 23 16:23:40 that is a good reason to wait May 23 16:24:05 So you are right about AG initiated ones May 23 16:24:32 So you can do two things: introduce an experimental API to BlueZ that is separate from the current BlueZ HFP stuff May 23 16:24:42 And then that becomes the official one May 23 16:24:54 Or just add a simple connect API to the hfp-ag plugin May 23 16:25:28 there is one big drawback to the experimental API, there is a lot of DBUS API calls to maintains the list of paired devices May 23 16:26:45 Somebody has to clean that stuff up anyway May 23 16:27:34 oFono would have to watch for all pairings, and register for every handsfree devices (HFP_AG role), and also for every phone (HFP_HF role), or even every computer for DUN May 23 16:28:21 Don't we do this nicely already? May 23 16:28:42 When I talk about experimental API, I mean similar to HandsfreeAudioGateway thingy May 23 16:30:10 or whatever it is called these days :) May 23 16:31:43 yes it is done already, you're right, but i'm wondering if instead of registering an agent for every instance of an headset/handsfree object, it could be possible to register an agent for a profile (or set of profile) May 23 16:32:47 That is a discussion you need to have with jhe and holtmann May 23 16:32:52 yeah for sure May 23 16:33:06 Certainly would make oFono's job easier **** ENDING LOGGING AT Tue May 24 01:08:22 2011 **** BEGIN LOGGING AT Tue May 24 05:32:15 2011 **** ENDING LOGGING AT Wed May 25 02:59:57 2011