**** BEGIN LOGGING AT Thu Sep 23 02:59:58 2010
Sep 23 04:25:24 <holtmann> denkenz: I am thinking of making a new release. Anything pending on your side.
Sep 23 04:25:41 <denkenz> Yeah, there's one quick fix I can push
Sep 23 04:25:48 <holtmann> Okay. Then please do.
Sep 23 04:25:55 <holtmann> Anything big you have pending.
Sep 23 04:26:12 <denkenz> Ok, pushed
Sep 23 04:26:17 <denkenz> Nothing big pending
Sep 23 04:32:53 <holtmann> Did the GPRS suspended task ever finished. Or why it is still in the TODO list.
Sep 23 04:33:18 <denkenz> I'm leaving it in there since I have no means of testing it
Sep 23 04:33:30 <denkenz> Otherwise I suppose it is 'done'
Sep 23 04:33:36 <holtmann> I see, but with ISI is meant to be working.
Sep 23 04:34:07 <denkenz> I have not heard reports positive or negative
Sep 23 04:34:16 <holtmann> I see.
Sep 23 05:51:38 <akiniemi> holtmann: I tested it with N900, and it seems to work ok
Sep 23 05:53:46 <holtmann> The GPRS suspended code?
Sep 23 06:39:56 <akiniemi> holtmann: yes
Sep 23 06:40:31 <akiniemi> holtmann: if you have an N900 around, easiest is to set it to 2G mode, attach/connect GPRS and make a call to it
Sep 23 06:41:39 <akiniemi> denkenz: still around?
Sep 23 13:52:08 <holtmann> balrog-k1n: What about the STK patch for MBM? Did you forget me?
Sep 23 13:53:44 <balrog-k1n> holtmann: i'm on it, just needed to catch up with git and other stuff, fix my system falling apart after some upgrades etc
Sep 23 13:56:29 <holtmann> I made a release without it :(
Sep 23 13:56:34 <holtmann> balrog-k1n: Please do test it on MBM hardware you have to ensure it is correct and not some weird thing of MBM firmware.
Sep 23 13:58:10 <balrog-k1n> holtmann: the *STKE thing didn't break things because all the envelopes we currently use are sent to the card and accept no response from the card
Sep 23 13:58:26 <holtmann> I see.
Sep 23 13:58:38 <balrog-k1n> there are some envelope types that would return a response and the modem would then send us a %STKE
Sep 23 13:58:42 <balrog-k1n> ..or it should
Sep 23 14:09:54 <holtmann> %STKE or *STKE ???
Sep 23 14:10:52 <balrog-k1n> oops it would send us a *STKE, right
Sep 23 14:29:35 <pessi> akiniemi: suspend works nicely with SMS, too ;)
Sep 23 14:31:12 <denkenz> I'm fine marking that task as done if I get akiniemi's ack
Sep 23 14:32:42 <denkenz> Or pessi's or Mika's, whoever tested it ;)
Sep 23 14:34:34 <holtmann> pessi: Just send a patch that remove it from the TODO list and adds it to features.txt.
Sep 23 14:34:34 <holtmann> Just for the record so we can track it.
Sep 23 14:36:05 <pessi> Mika said it is done
Sep 23 14:36:39 <pessi> should it be removed from the TODO or how it is marked as done?
Sep 23 14:36:52 <pessi> (this seems to be a historical moment)
Sep 23 14:39:47 <holtmann> Remove from TODO and add a feature description to doc/features.txt.
Sep 23 14:41:33 <pessi> what about writing a connection-manager-api.txt?
Sep 23 14:41:52 <pessi> or is it still too fast moving target?
Sep 23 14:46:16 <denkenz> pessi: doc/connman-api.txt not good enough?
Sep 23 14:47:00 <pessi> sure, I add it there?
Sep 23 14:47:35 <denkenz> Suspended property is already documented there
Sep 23 14:47:40 <pessi> oh, it is there, so do we really need a new GPRS section in features?
Sep 23 14:47:51 <denkenz> Yep
Sep 23 14:48:14 <denkenz> I haven't had time to do features properly, only moving marked tasks there as we go along
Sep 23 14:48:25 <denkenz> If you want to update it better, feel free
Sep 23 14:48:35 <holtmann> You mean connman-api.txt
Sep 23 14:48:36 <holtmann> What are you adding there?
Sep 23 14:48:39 <holtmann> Yes, we do.
Sep 23 14:48:41 <holtmann> features.txt is to document the features we do support. Otherwise we loose track with all the features that are already supported.
Sep 23 14:48:44 <holtmann> pessi: If you wanna make some extra credits, then please update that file with all the stuff oFono already does today.
Sep 23 14:49:09 <holtmann> pessi: I buy you a beer for every feature you put in there ;)
Sep 23 14:49:48 <pessi> I realy need that beer for fdn ;) 
Sep 23 14:49:51 <pessi> +l
Sep 23 14:50:23 <holtmann> Don't drink and code FDN ;)
Sep 23 14:57:46 <denkenz> I think you'll need to visit AAA meetings after FDN
Sep 23 14:58:23 <denkenz> And holtmann can't afford that much alcohol on his salary
Sep 23 15:03:57 <pessi> hm can I check if calls are progress from modem->call_ids?
Sep 23 15:04:38 <pessi> one-liner, and the I can ditch the watch on voicecall atom
Sep 23 15:04:49 <denkenz> You can, but that's a bad idea long term
Sep 23 15:05:05 <denkenz> call ids get shared to CSD, so if we ever do VT...
Sep 23 15:06:07 <pessi> I'm not sure if the mmi reference to calls in progress refers to voice calls or does it include csd
Sep 23 15:06:20 <pessi> and csd is sooo legacy 
Sep 23 15:06:33 <denkenz> Yeah, that's the tricky thing
Sep 23 15:06:48 <denkenz> And in general VT is usually treated separately from regular CS Voice
Sep 23 15:07:18 <denkenz> btw, you don't really need a watch
Sep 23 15:07:30 <denkenz> just grabbing the atom and checking for calls is enough
Sep 23 15:07:55 <denkenz> Might be 10 lines more
Sep 23 15:09:04 <pessi> I'd vote for adding a one-line comment explaining the ofono_modem_call_in_progress() usage in modem.c 
Sep 23 15:12:29 <denkenz> I'd vote on doing it properly
Sep 23 15:12:54 <denkenz> And I don't even know wtf call_in_progress is
Sep 23 15:14:29 <pessi> A UE is "in a call" from the time that signalling related to the establishment or attempted establishment of a
Sep 23 15:14:32 <pessi> MO or MT call commences and before the call or call attempt ends, and (if applicable) the ME has stopped
Sep 23 15:14:35 <pessi> generating tones related to this call to the user.
Sep 23 15:15:59 <denkenz> Yeah, so call_ids is not enough anyway
Sep 23 15:16:04 <pessi> hm?
Sep 23 15:16:08 <denkenz> According to that interpretation
Sep 23 15:16:48 <denkenz> The callid list is not updated until the ATD returns
Sep 23 15:17:00 <denkenz> So you could be dialing but callid list is still empty
Sep 23 15:17:37 <denkenz> Trust me, short cuts will not get you very far ;)
Sep 23 15:17:53 <denkenz> If I accept it upstream, I have to maintain it
Sep 23 15:18:06 <denkenz> So hacks are not getting accepted ;)
Sep 23 15:19:07 <pessi> and atd returns (in worst case) only when call is connected?
Sep 23 15:19:24 <pessi> good, this is another thing to fix ;)
Sep 23 15:19:58 <denkenz> No, ATD can return immediately
Sep 23 15:20:05 <denkenz> Or it can return when the call is connected
Sep 23 15:20:21 <denkenz> However, you don't know and you have to account for this properly
Sep 23 15:20:36 <holtmann> balrog-k1n: Another one in MBM STK support. Why is notifier for STKEND not having a :
Sep 23 15:20:47 <pessi> properly definitely is not exposing this maddness to the dialer
Sep 23 15:21:36 <denkenz> pessi: The dialer has a simple semantic, it gets a call object and follows the state changes
Sep 23 15:21:44 <denkenz> So the dialer does not care
Sep 23 15:24:54 <pessi> it dials anf gets the call object either via CallAdded or as a respose to Dial
Sep 23 15:25:00 <pessi> it very much has to care
Sep 23 15:25:46 <denkenz> The Dialer always gets told what happened, no matter what
Sep 23 15:26:04 <denkenz> And if it follows the signals properly, it doesn't matter what order or timing things happen in
Sep 23 15:26:14 <pessi> but via two differnt codepaths that have to be tested and maintained
Sep 23 15:27:03 <denkenz> Not in the Dialer
Sep 23 15:27:15 <pessi> oh yes
Sep 23 15:28:06 <denkenz> Then you have to explain, because in both cases the object path is returned
Sep 23 15:28:14 <denkenz> Then the CallAdded signal is emitted
Sep 23 15:28:45 <pessi> no
Sep 23 15:29:25 <denkenz> Then explain
Sep 23 15:29:36 <pessi> in one code path calladded comes first, in other, dial returns irst
Sep 23 15:29:54 <balrog-k1n> holtmann: i think it's just *STKEND\r\n\r\n and nothing more... i don't remember now, do you have any logs at hand?
Sep 23 15:30:25 <denkenz> pessi: Yeah, I'm looking at the code path, and trust me, it still works in the end
Sep 23 15:30:49 <denkenz> pessi: Unless the driver is totally screwed up
Sep 23 15:35:29 <denkenz> However, this discussion is going away from the original topic, even if you could somehow guarantee atd returns immediately, you still have a race between the ussd check, the dial and the call id since GAtChat still needs to go through the main event loop and out to the modem
Sep 23 15:35:36 <denkenz> So you have to do this properly regardless
Sep 23 15:36:05 <denkenz> The time arguing about this could have been spent with you doing it
Sep 23 15:36:46 <pessi> oh. my plan is to add new call state, "created", and return from Dial immediately after sending atd
Sep 23 15:37:20 <denkenz> Nope, I've been down that path before
Sep 23 15:37:26 <denkenz> And it won't work
Sep 23 15:37:29 <pessi> and what is the problem here?
Sep 23 15:37:35 <holtmann> Nope.
Sep 23 15:38:36 <pessi> we already have mapping from modem call ids to api ids, and we have to solve glare in any case
Sep 23 15:40:14 <denkenz> I don't see the point in complicating this, and I have tried the 'created' path before
Sep 23 15:40:22 <denkenz> It degenerated into something ugly as hell
Sep 23 15:41:16 <denkenz> If you really want to ensure that the method call returns first, there are better ways of doing that
Sep 23 15:41:41 <pessi> such as?
Sep 23 15:42:16 <denkenz> Such as adding a check for dialed/alerting calls in _notify and replying to the method return there
Sep 23 15:42:56 <denkenz> I never bothered because this actually works fine in the end on all modems I tested
Sep 23 15:43:12 <denkenz> Admittedly that has been a long time ago
Sep 23 15:43:54 <pessi> and how creating call object before dialing complicates things from that?
Sep 23 15:44:35 <denkenz> Because ATD can actually return proper errors on why the call failed
Sep 23 15:44:36 <pessi> dialer gets uniform response regardless of how crappy modem there is 
Sep 23 15:45:02 <denkenz> So adding a created state and then a separate signal for that is stupid
Sep 23 15:45:09 <pessi> for which? 
Sep 23 15:45:49 <pessi> if the call fails after it got to "dialed" state we do not care why it failed, is that so?
Sep 23 15:46:32 <denkenz> ATD can return errors, and we can query those errors with CMEE
Sep 23 15:46:36 <denkenz> or CEER
Sep 23 15:46:43 <denkenz> whatever it is, and report them to the core
Sep 23 15:46:57 <denkenz> Nobody is doing that now, but nothing is stopping us
Sep 23 15:47:24 <denkenz> Then we can generate proper errors when ATD fails
Sep 23 15:47:56 <pessi> yes, but this is irrelevant. we have to report reasons why call fails even if it progressed further
Sep 23 15:48:45 <denkenz> yes, good luck with that on AT modems
Sep 23 15:49:51 <pessi> is there a modem without proprietary call management interface? 
Sep 23 15:50:42 <denkenz> It is not really about that, it is more about just how much info the proprietary commands give
Sep 23 15:50:57 <denkenz> Some give almost no info besides the unsolicited call state
Sep 23 15:51:12 <denkenz> So polling CLCC isn't necessary, but that's about it
Sep 23 15:53:34 <denkenz> And there are race conditions with created too
Sep 23 15:53:56 <denkenz> because GAtChat is a queue, you never know whether a CCWA indication is already pending 
Sep 23 15:54:01 <denkenz> That screws up your id management
Sep 23 15:54:44 <pessi> hm?
Sep 23 15:55:18 <denkenz> E.g. you create a call on a dial, but the modem already sent us a CRING
Sep 23 15:55:26 <pessi> yes?
Sep 23 15:55:33 <denkenz> Your ID is now clashing with the one given by the driver
Sep 23 15:55:40 <denkenz> -> FAIL
Sep 23 15:55:43 <pessi> my id?
Sep 23 15:55:59 <pessi> ofono id is allocated by ofono, modem id by modem
Sep 23 15:56:07 <pessi> they are not the same
Sep 23 15:56:18 <denkenz> They actually are
Sep 23 15:56:24 <pessi> with pure luck
Sep 23 15:56:28 <denkenz> Nope
Sep 23 15:56:40 <denkenz> Study up on 27.007 some more
Sep 23 15:57:22 <denkenz> So unless you want to burn lots of CPU cycles cross-matching IDs between the driver and the core, I wouldn't recommend created state
Sep 23 16:09:33 <pessi> so you trust the atd returning after the call has been allocated id
Sep 23 16:11:59 <denkenz> That is what the spec says
Sep 23 16:12:09 <pessi> V.250?
Sep 23 16:12:25 <denkenz> 27.007
Sep 23 16:13:50 <pessi> it just refers to V.250
Sep 23 16:14:46 <denkenz> You have to dig a bit, V.250 does not have call indexes
Sep 23 16:14:51 <denkenz> It might be 22.030 as well
Sep 23 16:15:16 <pessi> so nothing guarantees that there is call id when atd returns
Sep 23 16:16:45 <denkenz> There is, its in the 3gpp specs somewhere
Sep 23 16:16:50 <pessi> which is?
Sep 23 16:17:28 <denkenz> As I said, you'd need to look for it
Sep 23 16:18:12 <pessi> there is nothing in the spec saying that 1) incomplete call has id 2) when atd returns, call has id
Sep 23 16:18:35 <pessi> 22.030 says "X" is the numbering (starting with 1) of the call given by the sequence of setting up or receiving the calls (active, held
Sep 23 16:18:38 <pessi> or waiting) as seen by the served subscriber. Calls hold their number until they are released. New calls take the lowest
Sep 23 16:18:41 <pessi> available number.
Sep 23 16:19:49 <pessi> there is a hole for calls that are being dialed or being received
Sep 23 16:20:13 <denkenz> Maybe on ISI
Sep 23 16:20:24 <denkenz> Not in AT or 27.007
Sep 23 16:20:31 <pessi> isi clls have id once they are in "created" state
Sep 23 16:21:07 <pessi> at calls only if they are active, held or waiting.
Sep 23 16:21:20 <denkenz> you're wrong
Sep 23 16:21:27 <denkenz> Don't read into 22.030 too much
Sep 23 16:22:03 <denkenz> Go play with some modems and come back after
Sep 23 16:22:05 <pessi> it is only spec that defines the call id
Sep 23 16:25:33 <pessi> and actually we were trying to figure out how to do mmi properly
Sep 23 16:41:51 <holtmann> balrog-k1n: Fixed it by myself since I was doing cleanup.
**** BEGIN LOGGING AT Thu Sep 23 20:48:15 2010
Sep 23 23:11:11 <fifa> HELLO ROOM
Sep 23 23:11:42 <fifa> i have few questions on oFono
Sep 23 23:11:56 <fifa> dose it support HFP ??
Sep 23 23:13:03 <fifa> anyone ??
Sep 23 23:13:16 * bzed hopes not.
Sep 23 23:13:48 <bzed> oh HFP
Sep 23 23:13:51 <bzed> I read PHP
Sep 23 23:14:00 <bzed> gah. time for bed :)
Sep 23 23:14:02 <fifa> ok
Sep 23 23:14:48 <fifa> anyone dose oFone support HFP (hands free profile) ??????
Sep 23 23:19:15 <fifa> anyone !!!
Sep 23 23:21:57 <denkenz> it supports hfp client profile
Sep 23 23:30:50 <fifa> it does
Sep 23 23:31:09 <fifa> so there are no knows issues with audio ??
Sep 24 00:03:02 <denkenz> ofono does not handle audio
Sep 24 00:35:07 <holtmann>   CC     src/stk.o
Sep 24 00:35:07 <holtmann> cc1: warnings being treated as errors
Sep 24 00:35:07 <holtmann> src/stk.c: In function ‘handle_command_refresh’:
Sep 24 00:35:07 <holtmann> src/stk.c:1807: error: implicit declaration of function ‘encode_hex_own_buf’
Sep 24 00:38:19 <holtmann> denkenz: And fixed.
Sep 24 00:39:07 <denkenz> ok thanks
Sep 24 00:39:11 <denkenz> silly -O0 got me
**** BEGIN LOGGING AT Fri Sep 24 02:04:35 2010