**** BEGIN LOGGING AT Thu Sep 02 02:59:58 2010
Sep 02 09:38:58 <zapp42> kvalo: Hi, may I bug you again (regarding ofonos huawei plugin)?
Sep 02 09:40:19 <kvalo> zapp42: sure. I have to leave soonish, but I can check your messages from awaylog after I come back
Sep 02 09:41:06 <zapp42> kvalo: I see a 255 for sim state in the sysinfo result when I plug in my device while ofono is already running...
Sep 02 09:41:38 <zapp42> How is a change in state (once the sim is initialized) supposed to be detected?
Sep 02 09:42:00 <kvalo> I see the same with my huawei e1552. I sent some patches few weeks ago, did you see them?
Sep 02 09:43:21 <zapp42> hmm. I saw some "fix sim state" stuff, but none from you. Will check again... ofono or connman list?
Sep 02 09:43:36 <kvalo> ofono
Sep 02 09:43:42 <kvalo> I can find them for you
Sep 02 09:44:07 <zapp42> don't worry, I will find them. Thank you.
Sep 02 09:44:40 <kvalo> they need more work, but I was able to get my huawei working reliable after those two patches
Sep 02 09:44:53 <kvalo> I don't know if it helps you, though.
Sep 02 09:45:56 <zapp42> "huawei: properly notify sim state to ofono"
Sep 02 09:46:02 <zapp42> This one?
Sep 02 09:46:51 <kvalo> these two:
Sep 02 09:46:56 <kvalo>     huawei: poll sim state
Sep 02 09:47:00 <kvalo>     huawei: postpone post_sim until SIM is ready
Sep 02 09:47:19 <kvalo> zapp42: what's your email address? I can send them via email
Sep 02 09:48:41 <zapp42> kvalo: Thanks. Did you get my address? I am not too familiar with irc..
Sep 02 09:49:25 <kvalo> zapp42: got it. sent the two patches now
Sep 02 09:49:52 <zapp42> Already there. Thanks a lot.
Sep 02 09:50:20 <kvalo> I need to work on the patches more, denis found problems with them.
Sep 02 09:50:59 <kvalo> I will leave soon, but I should back in an hour
Sep 02 11:48:39 <pessi> denkenz: I have no idea how to do it with an AT modem. On isimodem, we get an SS indication. As it is a US-specific addition to the requirements. I'll have to find out if we can even do testing here
Sep 02 13:29:39 <denkenz> pessi: These are still independent
Sep 02 13:30:17 <denkenz> pessi: We also have the problem of when to trigger Offline state in emergency-only mode after the emergency call is over
Sep 02 14:23:13 <pessi> denkenz: I'm trying to solve that with the EmergencyCallOnGoing property and perhaps with a corresponding wait?
Sep 02 14:23:48 <pessi> but we now quite a lot of moving parts
Sep 02 14:24:29 <denkenz> Yes, but EmergencyCallOnGoing when you have no calls makes no sense
Sep 02 14:24:53 <pessi> modem controls online/offline, voicecallmanager makes the call, and then some supplementary service blob talks to GPS
Sep 02 14:25:26 <denkenz> Yes, so perhaps the Modem object should have an EmergencyMode and set_emergency_mode
Sep 02 14:25:35 <denkenz> and several atoms can influence that
Sep 02 14:25:38 <pessi> "EmergencyMode"
Sep 02 14:25:41 <denkenz> Just throwing an idea around
Sep 02 14:25:52 <pessi> thanks ;)
Sep 02 14:26:49 <pessi> something like emergency_mode_ref() and _unref() (or _inc()/_dec())
Sep 02 14:27:25 <denkenz> yeah
Sep 02 15:18:32 <pessi> denkenz: I sent todo mods, please have a look on them
Sep 02 15:27:23 <denkenz> pessi: In general I'd like to keep words like 'figure out' from the TODO items
Sep 02 15:27:40 <denkenz> pessi: Especially in the first sentence ;)
Sep 02 15:29:01 <denkenz> It is fine to be wrong, but the task should contain enough hints and direction for someone else to read the description and have a direction to go in
Sep 02 15:30:10 <denkenz> for the emergency property, label it experimental
Sep 02 15:30:15 <pessi> denkenz: it is genuince marcel, I copied it ;)
Sep 02 15:30:18 <denkenz> But otherwise I'm fine with path 2
Sep 02 15:30:28 <denkenz> s/path/patch
Sep 02 15:31:05 <pessi> denkenz: I'm trying to recruit our emergency call guru to do this ;)
Sep 02 15:31:43 <denkenz> pessi: Just reword it to say 'Proposed solution is to...'
Sep 02 15:31:50 <denkenz> We can always modify it if needed
Sep 02 15:33:23 <denkenz> pessi: Good idea, we have no emergency call Gurus or a network we can initiate them on
Sep 02 15:33:37 <denkenz> pessi: Doubt my local fire department would appreciate me calling around for testing ;)
Sep 02 15:35:51 <pessi> naah. nothing spices the day more than a tired lady answering your call with "Hätäkeskus - nödcentralen. Kuinka voin auttaa? Hur kan jag hjälp?"
Sep 02 15:38:05 <denkenz> I'll take your word for it ;)
Sep 02 15:41:12 <holtmann> pessi: What did I do now?
Sep 02 15:42:12 <pessi> holtmann: probably nothing, but it always convenient to blame you
Sep 02 15:44:21 <pessi> it was denis' text I copied. no wonder he was not happy with it ;)
Sep 02 15:48:26 <denkenz> I don't see any words like 'Figured out' in the TODO
Sep 02 15:48:38 <denkenz> If there are, then its my bad and it needs to be fixed
Sep 02 15:49:44 <denkenz> Some of the TODO items were done rather quickly and need to be fixed up
Sep 02 15:58:47 <pessi> you have to clean emergency number list, i believe
Sep 02 16:00:53 <pessi> the Dial method, should it return both path and property dict, or should we ensure that CallAdded is always emitted before Dial returns?
Sep 02 16:14:59 <denkenz> pessi: voicecall atom always emits signals after returning from the method call
Sep 02 16:15:29 <denkenz> pessi: What will you get from the CallAdded signal that you don't already know from invoking Dial?
Sep 02 16:15:39 <pessi> why all the jazz with need_to_emit, then?
Sep 02 16:17:00 <denkenz> pessi: Some phones are actually weird, they signal unsolicited that call is dialing / alerting
Sep 02 16:17:06 <denkenz> But ATD returns only after
Sep 02 16:17:28 <denkenz> +call is connected
Sep 02 16:18:18 <pessi> uh
Sep 02 16:18:41 <denkenz> Sane firmware, ATD returns immediately and you get call progress indications after
Sep 02 16:19:48 <denkenz> So we try to be as nice as possible in guaranteeing the signal order
Sep 02 16:19:54 <denkenz> But sometimes we simply can't
Sep 02 16:21:08 <pessi> if dialer has to deal with CallAdded before Dial returns, I'd vote for emitting it always before Dial returning 
Sep 02 16:24:02 <denkenz> perhaps, we actually need to hear some feedback from UI guys here
Sep 02 16:24:17 <denkenz> There are other areas where this might need to be tweaked
Sep 02 19:17:15 <akiniemi> denkenz: so what's the use case justifying SMS bearer API?
Sep 02 19:18:09 <denkenz> akiniemi: Dunno, some big customer or other asked for it ;)
Sep 02 19:18:18 <denkenz> akiniemi: I'd personally want that one in main.conf
Sep 02 19:22:39 <denkenz> I'm just raising a question here, it might very well be useful to have Alphabet as something the user sees
Sep 02 19:22:47 <akiniemi> denkenz: wow, that's exactly the same use case we have for Alphabet ;)
Sep 02 19:23:47 <akiniemi> denkenz: S60 phones have both in the UI. Android seems to only have delivery reports and SMSC.
Sep 02 19:24:13 <akiniemi> And iPhone, I think, only has SMSC.
Sep 02 19:24:20 <denkenz> Certainly the 16 bit vs 8 bit stuff belongs in main.conf
Sep 02 19:24:49 <akiniemi> denkenz: no, that should just be 8bit when sending, recv naturally should support both.
Sep 02 19:24:51 <denkenz> Alphabet I can see, Bearer ... I'd really want to see in main.conf
Sep 02 19:25:25 <denkenz> Not sure, considering 23.040 explicitly recommends 16 bit headers
Sep 02 19:26:07 <akiniemi> But why?
Sep 02 19:26:16 <denkenz> collisions?
Sep 02 19:28:47 <akiniemi> You only get collisions if you wrap the ref while a multipart is in flight. Not likely.
Sep 02 19:29:20 <akiniemi> Anyway, all phones out there seem to use 8bit.
Sep 02 19:29:41 <akiniemi> And not to menton 16bit wastes a byte. ;)
Sep 02 19:30:27 <denkenz> Sure, but oFono can be used for M2M usecases
Sep 02 19:30:38 <denkenz> So dismissing something just because it doesn't fit a phone is also not a good idea
Sep 02 19:31:54 <akiniemi> denkenz: surely M2M needs the ability to send binary SMSs, no?
Sep 02 19:32:42 <denkenz> possibly, and I never argued against ability to send binary SMS messages
Sep 02 19:32:52 <denkenz> Just the ability to send them raw over D-Bus
Sep 02 19:33:12 <akiniemi> You mean a raw TPDU or just ay?
Sep 02 19:34:35 <akiniemi> Because I was thinking of adding SendBinary(string to, array{byte}, uint dest, uint src)
Sep 02 19:34:59 <akiniemi> where src == 0 means ephemeral
Sep 02 19:35:12 <denkenz> I'm really against this at this point
Sep 02 19:35:19 <denkenz> I only see the need to send VCards and VCals
Sep 02 19:35:24 <denkenz> This can have dedicated API
Sep 02 19:36:14 <akiniemi> That's then going to be a patch we need to carry in packaging...
Sep 02 19:36:45 <denkenz> Shrug, feel free to convince me
Sep 02 19:36:55 <denkenz> So far I'm seeing talk but no use cases
Sep 02 19:38:03 <holtmann> I think the bearer should be main.conf as well.
Sep 02 19:38:03 <akiniemi> http://developer.android.com/reference/android/telephony/SmsManager.html
Sep 02 19:38:06 <holtmann> But then we have to finally start creating support for main.conf in the first place ;)
Sep 02 19:38:40 <akiniemi> You'll find similar APIs in Symbian, Java MIDP, etc.
Sep 02 19:39:16 <akiniemi> And guys, minimal only works if you combine it with *complete* ;)
Sep 02 19:39:44 <denkenz> Showing crappy Java APIs is not helping your case here
Sep 02 19:39:56 <denkenz> We have never set out to build an Android replacement
Sep 02 19:40:18 <akiniemi> Who's "we"?
Sep 02 19:40:52 <denkenz> Tempting, but nah
Sep 02 19:42:52 <denkenz> Let me put it this way, oFono has never been intended as a general purpose - you can do anything telephony stack
Sep 02 19:43:03 <denkenz> We focus on the use cases that make sense, and we make those easy
Sep 02 19:43:52 <denkenz> This allows us to keep complexity down and reliability of our code up
Sep 02 19:46:14 <denkenz> The rest will take care of itself over time, even the 'completeness' part
Sep 02 19:46:30 <akiniemi> How is SendVCard(string to, ay) less complex?
Sep 02 19:47:14 <akiniemi> Or are you suggesting SendVCard(string to, string card), cause that's not going to work.
Sep 02 19:48:37 <akiniemi> oFono needs to stay out of the vCard charset business, because it ain't pretty and UTF-8. :)
Sep 02 19:49:06 <denkenz> shrug, you again have blinders on and only thinking about your Smart Messaging stuff
Sep 02 19:49:11 <denkenz> you can send VCards over EMS
Sep 02 19:49:24 <denkenz> And trust me, that isn't simple as SendBinary(data, port, src)
Sep 02 19:50:02 <akiniemi> denkenz: huh? What smart messaging stuff? Please explain.
Sep 02 19:50:25 <denkenz> Smart Messaging is the Nokia spec that uses the dest / src port addressing
Sep 02 19:50:33 <denkenz> There other ways to skin a cat
Sep 02 19:50:50 <denkenz> Besides, why should our UI writers have to go read some spec and figure out what source / port to use?
Sep 02 19:51:04 <denkenz> That is utterly stupid and one of the things we're explicitly trying to avoid
Sep 02 19:54:08 <akiniemi> denkenz: I'm not following you. I know of two ways: ports in IEs, plus 8bit UD
Sep 02 19:54:23 <akiniemi> and GSM 7bit and //SCKL23F4 crap at the beginning.
Sep 02 19:54:34 <akiniemi> What are you talking about?
Sep 02 19:55:53 <denkenz> There's also a way as an extended EMS object
Sep 02 19:57:06 <denkenz> Same goes for Images
Sep 02 19:57:15 <denkenz> And the formats are wildly different
Sep 02 19:58:44 <akiniemi> Ok, I'm not talking about sending images in SMS. That is utterly stupid and not something we support.
Sep 02 19:59:40 <denkenz> So back to my original question, what _do_ you want to support?
Sep 02 19:59:45 <denkenz> So far I'm only hearing vCard
Sep 02 20:04:39 <akiniemi> Sending binary data to an application port
Sep 02 20:07:06 <denkenz> and I want a Pony
Sep 02 20:08:48 <akiniemi> So this EMS crap, do you actually know of phones that use it to send vCards?
Sep 02 20:09:50 <denkenz> vCards? no, Images? definitely
Sep 02 20:10:47 <akiniemi> Because all of the phones I know use port addressing to send vCards and MMS to send images
Sep 02 20:11:05 <akiniemi> And use 8bit ref numbers
Sep 02 20:12:02 <denkenz> Shrug, and I had plenty of Ericsson phones that used EMS to send images
Sep 02 20:12:38 <akiniemi> yeah, back in the early nineties ;)
Sep 02 20:13:22 <denkenz> So? Who'd use SMS to send a vCard? That's also utterly stupid
Sep 02 20:13:55 <denkenz> Lets be realistic, sending binary SMSes is not really a use case these days anyway
Sep 02 20:14:11 <denkenz> Unless you wanna do WAP mass marketing or something
Sep 02 20:17:01 <denkenz> Same goes for about a bazillion other features in GSM, like advice of charge, bdn, fdn, all the stupid operator naming crap, and let us not mention sim toolkit
Sep 02 20:20:17 <akiniemi> Sure, but if having to support all that nonsense bothers you, then you're in the wrong business my friend ;)
Sep 02 20:20:50 <denkenz> That doesn't really bother me
Sep 02 20:21:43 <denkenz> what bothers me is kicking the can down the road and expecting some poor UI guy who has no freaking idea to clean up after me
Sep 02 20:22:02 <denkenz> Lets face it, every other telephony stack out there is described by this statement
Sep 02 20:25:43 <akiniemi> So? There is an equal number of developers having to send AT commands to a TTY because there isn't an API available to send SMS.
Sep 02 20:27:42 <denkenz> So make something better
Sep 02 20:27:57 <denkenz> Not take the easy road of at least its not the shittiest thing out there
Sep 02 20:29:13 <akiniemi> I'm trying.
Sep 02 20:31:12 <denkenz> I know, so help me understand why you think SendBinary is needed.  So far I'm only seeing a need for SendBusinessCard and SendAppointment
Sep 02 20:31:26 <akiniemi> Google for developers looking to send binary SMSs
Sep 02 20:32:22 <denkenz> I have before plenty of times, but these guys are building back-office type apps
Sep 02 20:33:02 <denkenz> Something likely done with Kannel or other software that talks directly to the SMSC
Sep 02 20:33:31 <akiniemi> 22:27 < denkenz> Sure, but oFono can be used for M2M usecases
Sep 02 20:33:43 <denkenz> M2M is different though
Sep 02 20:34:02 <denkenz> You're sending sensor info maybe once an hour point to point
Sep 02 20:34:08 <denkenz> Not 20000 marketing messages an hour
Sep 02 20:35:28 <denkenz> And these days M2M is migrating away from SMS to GPRS
Sep 02 20:35:57 <akiniemi> Forget it, GPRS has NATs
Sep 02 20:36:20 <denkenz> Not if you cut a deal with the provider
Sep 02 20:36:31 <denkenz> And still largely cheaper than SMS
Sep 02 20:38:02 <denkenz> And I'm actually totally fine if someone comes in and proposes an extension API to oFono for doing Mass marketing WAP emails
Sep 02 20:39:15 <denkenz> But if that day never comes and we maintained SendBinary for only that reason, then we were being silly ;)
Sep 03 00:17:21 <balrog-k2n> denkenz: i'm trying to implement Send DTMF and also sending dtmf at the end of Set-up Call.  one of the allowed tones is pause, do you think it makes more sense to implement the "pause" (3 seconds of idle) in core or in the driver?
Sep 03 00:18:52 <balrog-k2n> also the pause can be interpreted as a "DTMF Control Digit Separator", am i assuming correctly that this symbol always appears between the number in Set-up Call and the DTMFs to send?
Sep 03 00:19:22 <balrog-k2n> the spec says just that the address field can contain the DTMFs at the end of the number but doesn't say if there's any kind of separator
Sep 03 01:00:06 <zhenhua> denkenz: i have no idea to implement ReqestKey/RequestDigit yet.
Sep 03 01:00:49 <zhenhua> denkenz: For ReqestInput/RequestInputs, I can prompt up a QLineEdit. but for single digit/chars, how to let user input that?
Sep 03 01:06:31 <balrog-k2n> for RequestDigit i pop up the dialer in my client
Sep 03 01:06:43 <balrog-k2n> dialpad*
Sep 03 01:06:57 <balrog-k2n> and let the user press just one digit
Sep 03 01:21:12 <denkenz> balrog-k2n: The rules are very arcane
Sep 03 01:21:41 <denkenz> balrog-k2n: The first C character in the ADN is interpreted as a pause
Sep 03 01:22:05 <denkenz> Don't remember how the others are interpreted
Sep 03 01:22:16 <denkenz> In theory, all modems actually support dial strings
Sep 03 01:22:25 <denkenz> so sending an ATD should be enough
Sep 03 01:24:51 <denkenz> balrog-k2n: For PlayTone, I think using strings is better
Sep 03 01:24:52 <balrog-k2n> denkenz: i think rather the first C is the separator and the remaining ones are pauses?
Sep 03 01:25:21 <denkenz> balrog-k2n: Hm, you're probably right, its been a while
Sep 03 01:26:01 <balrog-k2n> denkenz: so do you think we should just send the string like +12345p1p2 through driver->dial()?
Sep 03 01:26:18 <denkenz> I think that would be fine
Sep 03 01:26:25 <balrog-k2n> one problem is dial() accepts a ofono_phone_number which is limited to 21 chars iirc
Sep 03 01:26:38 <denkenz> Yeah, we can extend that
Sep 03 01:27:02 <balrog-k2n> also i'd need to teach valid_phone_number_format() about it
Sep 03 01:27:11 <denkenz> yep
Sep 03 01:27:37 <balrog-k2n> do you think also AT+VTS= supports pauses?  that's not in 27.007
Sep 03 01:27:52 <denkenz> VTS doesn't
Sep 03 01:28:31 <balrog-k2n> if we implement the pauses in src/voicecall.c then set-up call could also use that
Sep 03 01:28:52 <denkenz> Yep
Sep 03 01:29:01 <denkenz> We already have a task in the TODO about dial strings
Sep 03 01:29:31 <balrog-k2n> ah right
Sep 03 01:29:46 <denkenz> So far our thought has been to:
Sep 03 01:30:04 <denkenz> check for the first pause character, treat that as LineIdentification
Sep 03 01:30:14 <denkenz> add a new attribute for 'DialString' in voicecall
Sep 03 01:30:27 <denkenz> stuff the rest of it in there minus the first separator
Sep 03 01:30:37 <denkenz> And send the whole shabang to the driver
Sep 03 01:30:47 <denkenz> no timers in oFono itself
Sep 03 01:30:53 <denkenz> But lets see if it can work that way
Sep 03 01:31:43 <balrog-k2n> but we need the timers for Send DTMF anyway
Sep 03 01:32:30 <balrog-k2n> LineIdentification would be the number up to the first "p", right?
Sep 03 01:32:35 <denkenz> yep
Sep 03 01:32:43 <balrog-k2n> ok
Sep 03 01:33:07 <balrog-k2n> denkenz: back to PlayTone, there are some 30-40 predefined sounds, are you ok listing them all in doc/stk-api.txt?
Sep 03 01:35:08 <balrog-k2n> one of the tests in 31.124 is Send DTMF "1 pause 2"
Sep 03 01:35:27 <denkenz> yuck ;)
Sep 03 01:35:38 <denkenz> The biggest issue is we don't have timing indications from the AT modem
Sep 03 01:35:55 <denkenz> VTS doesn't really tell us when the tone has been played
Sep 03 01:36:09 <denkenz> So doing pauses is an exercise in futility
Sep 03 01:36:10 <balrog-k2n> ah AT+VTS returns immediately
Sep 03 01:36:14 <balrog-k2n> yeah
Sep 03 01:36:32 <balrog-k2n> we'd have to force the duration to something like 1s at the initialisation
Sep 03 01:36:42 <balrog-k2n> and then assume it is 1s for each tone
Sep 03 01:36:50 <denkenz> VTS has fixed duration
Sep 03 01:36:59 <denkenz> so you can assume somewhat
Sep 03 01:37:26 <balrog-k2n> yeah, there's +VTH or something like that to set that duration
Sep 03 01:37:58 <balrog-k2n> oops, it's +VTD
Sep 03 01:38:15 <denkenz> Btw, for PlayTone I'm leaning towards strings
Sep 03 01:38:25 <denkenz> Post a string version and we see how it looks
Sep 03 01:38:46 <denkenz> It is a one way conversion, so not too bad
Sep 03 01:38:53 <balrog-k2n> denkenz: i'm ok with that, but do we want to list the possible values in the doc?
Sep 03 01:39:18 <denkenz> List the important ones
Sep 03 01:39:27 <denkenz> the melody1..n is sort of silly
Sep 03 01:41:08 <tmzt_> midi chip
Sep 03 01:41:09 <balrog-k2n> ah +VTD already says in GSM the value can't be changed because it's predefined
Sep 03 01:41:37 <denkenz> Yeah, about the best you can do is wait until VTS returns, start the 3 second timer then
Sep 03 01:41:43 <denkenz> But there's still no guarantee
Sep 03 01:42:49 <balrog-k2n> yeah, there seems to be no good way to do that
Sep 03 01:43:36 <balrog-k2n> even if there was no pauses, because Send DTMF has to respond to the SIM only once the tones end
Sep 03 01:45:08 <denkenz> yep, so that one might be a lost cause
Sep 03 01:48:48 <denkenz> So I'd say just send dial strings directly to ATD, let the driver do its magic
Sep 03 01:48:58 <denkenz> for Send DTMF just give up if there are pauses
Sep 03 01:49:03 <denkenz> Until we have some better idea
Sep 03 02:37:13 <balrog-k2n> denkenz: we'll need a timer even when there are no pauses though
Sep 03 02:38:15 <balrog-k2n> i'd just use timers and assume 3s per tone
**** ENDING LOGGING AT Fri Sep 03 02:59:57 2010