**** BEGIN LOGGING AT Wed Oct 20 02:59:56 2010
Oct 20 11:42:51 <holtmann> ofonod[1450]: Net: < \r\n+CTZV: +08,"10/10/20,13:39:09"\r\n
Oct 20 11:42:51 <holtmann> ofonod[1450]: Net: < \r\n+XNITZINFO: "GMT+1","10/10/20,13:39:09"\r\n\r\n+CTZDST: 1\r\n
Oct 20 11:42:51 <holtmann> ofonod[1450]: Received a network time notification on modem: 0x962fc50
Oct 20 11:42:51 <holtmann> ofonod[1450]: Time: -001--1--1 -1:-1:-1-00:00 (DST=0)
Oct 20 11:43:06 <holtmann> akiniemi: You don't handle -1 properly in the netime example plugin ;)
Oct 20 14:25:35 <pessi> denkenz: why voicecall atom does not want to use release_specific ? it is, like, last resort instead of preferred way?
Oct 20 14:26:03 <denkenz> pessi: release_specific does not work on held calls according to 27.007
Oct 20 14:26:14 <denkenz> So we try to avoid using it unless we have no other way
Oct 20 14:26:19 <pessi> ok.
Oct 20 14:27:36 <pessi> what about working_release_specific method? ;-)
Oct 20 14:28:17 <denkenz> do you have a case that is broken?
Oct 20 14:28:34 <denkenz> Basically 27.007 does not mandate CHLD=1x to work on held calls
Oct 20 14:28:39 <denkenz> Most vendors provide some extension
Oct 20 14:28:40 <pessi> ah, hangup active does hang up also the dialing/alerting calls?
Oct 20 14:28:52 <denkenz> But those extensions work very differently between manufacturers
Oct 20 14:29:00 <denkenz> pessi: Yep
Oct 20 14:34:48 <pessi> hmhm. what about release_by_id which would be preferred to other hangup methods?
Oct 20 14:35:53 <denkenz> I actually want to avoid this if possible
Oct 20 14:36:07 <denkenz> certainly we can add a 'this method releases any call' method
Oct 20 14:36:14 <denkenz> But the logic inside the core is complicated already
Oct 20 14:39:31 <pessi> it is
Oct 20 14:41:02 <pessi> why manager_hangup_all insists on both release_specific and hangup_active?
Oct 20 14:42:05 <denkenz> So there's a case when we have waiting + active + held calls
Oct 20 14:42:16 <denkenz> if we don't have hangup_all
Oct 20 14:42:23 <denkenz> We need to hangup_active first, then use release specific
Oct 20 14:42:35 <denkenz> we can't use release_held since the waiting call will become active
Oct 20 14:42:55 <denkenz> So we do the check early on
Oct 20 14:44:44 <denkenz> This might need to be documented a bit better
Oct 20 14:45:28 <denkenz> But most real hardware supports either hangup_all or release specific releasing held calls
Oct 20 14:45:32 <denkenz> one exception might be HFP
Oct 20 15:10:12 <pessi> denkenz: and what is difference between hangup_active and release_all_active? release_all_active also answers to waiting call?
Oct 20 15:10:34 <denkenz> yep
Oct 20 15:11:01 <denkenz> hangup_active came about because of STE modems
Oct 20 15:11:23 <denkenz> their ATH hangs up dialing/alerting/active/incoming calls only
Oct 20 15:11:45 <denkenz> 22.030 specifies ath should hang up all calls except waiting calls
Oct 20 15:11:57 <denkenz> some modems provide both (like ti & ifx)
Oct 20 15:18:39 <pessi> hangup_active() should hang 1) active 2) alerting 3) dialing calls, but not incoming/waiting?
Oct 20 15:19:02 <denkenz> active, alerting, dialing, incoming
Oct 20 15:19:13 <denkenz> waiting can only be hung up using udub
Oct 20 15:19:45 <pessi> ok, so everything but held and waiting
Oct 20 15:19:50 <denkenz> yep
Oct 20 16:01:30 <denkenz> pessi:
Oct 20 16:01:31 <denkenz> +	/* Release incoming or waiting calls */
Oct 20 16:01:31 <denkenz>  	void (*set_udub)(struct ofono_voicecall *vc,
Oct 20 16:01:31 <denkenz>  			ofono_voicecall_cb_t cb, void *data);
Oct 20 16:01:37 <denkenz> udub only works on waiting calls
Oct 20 16:01:52 <denkenz> AT modems only allow chup / ath on incoming calls
Oct 20 16:32:45 <pessi> udub does not work with incoming? ;-o
Oct 20 16:33:02 <pessi> I'll fix my fix
Oct 20 16:34:00 <denkenz> pessi: I'm pretty sure AT modems always send UDUB on incoming calls when you use ATH
Oct 20 16:34:28 <denkenz> pessi: oFono doesn't actually make a distinction, we only allow Hangup and that sends ath or udub depending on call state
Oct 20 16:48:14 <pessi> I love subblocks within subblocks.
Oct 20 17:03:06 <pessi> denkenz: what about renaming set_udub as release_waiting? ;-)
Oct 20 17:05:39 <pessi> akiniemi: you should sit in the same room as Jari and get immersed in SMS knowledge ;)
Oct 20 17:12:09 <pessi> ...and I should say make after rebasing
Oct 20 17:13:10 <pessi> denkenz: have you found out how +CSCA saves the SCA address?
Oct 20 17:13:54 <denkenz> pessi: I confirmed my Huawei stored the numbers on the SIM somehow
Oct 20 17:14:03 <denkenz> pessi: However, I have not found the field it uses
Oct 20 17:14:09 <pessi> but not in the EF_smsp ?
Oct 20 17:14:45 <denkenz> from other documentation I gathered that EFsmsp is generally used, but can be configured by +CRES or something
Oct 20 17:15:08 <denkenz> pessi: didn't look to be EFsmsp, but then again the Huawei firmware might not implement file reading correctly
Oct 20 19:11:35 <denkenz> balrog-k1n: Have you ever encountered Set up Event list being sent from any of your sims?
Oct 20 19:33:22 <pessi> oohahh, sms sent successfully from empathy
Oct 20 19:34:39 <kvalo> pessi: cool!
Oct 20 19:35:41 <pessi> denkenz: sorry, the sms fix patch did not fix
Oct 20 19:35:58 <denkenz> pessi: Then send the next one
Oct 20 19:36:11 <pessi> sure ;-/
Oct 20 19:36:34 <pessi> n900 and n95 seem to have slightly different sms api 
Oct 20 19:36:43 <pessi> we need quirks ;)
Oct 20 19:36:50 <denkenz> hah
Oct 20 19:37:14 <holtmann> Na na na na ...
Oct 20 19:37:41 <holtmann> At least not only we poor AT command monkeys have to deal with that ;)
Oct 20 19:39:07 <crevetor> Guys, is it planned to have nitz be a implemented as propertychanged somewhere at some point ?
Oct 20 19:39:48 <denkenz> no, you need to implement a nettime plugin
Oct 20 19:39:51 <denkenz> see examples/nettime.c
Oct 20 19:40:03 <crevetor> denkenz: ok
Oct 20 19:52:28 <pessi> denkenz: the vc driver api docs are fine
Oct 20 19:53:12 <pessi> denkenz: is there a special reason not to use hangup_active in multiparty_hangup?
Oct 20 19:53:44 <pessi> or is it just creating yet-another code path without good reason?
Oct 20 19:54:02 <denkenz> multiparty_hangup does use hangup_active
Oct 20 19:54:08 <denkenz> afaik?
Oct 20 19:55:17 <pessi> yes, if multiparty has exactly one call
Oct 20 19:55:25 <denkenz> ah I see what you mean
Oct 20 19:55:56 <denkenz> multiparty_hangup can be refined to use release_active / release_all_held / hangup_active
Oct 20 19:56:13 <denkenz> Was just more lazy since the release all queue was already implemented
Oct 20 19:57:53 <denkenz> But yeah, it is probably a good idea, just watch out for those waiting calls ;)
Oct 20 20:05:18 <denkenz> pessi: I already applied the original fix SMS patch
Oct 20 20:05:25 <denkenz> pessi: Have you rebased and which one do I apply now?
Oct 20 20:23:26 <crevetor> denkenz: is there a reason why nettime isn't implmented as a dbs
Oct 20 20:23:43 <crevetor> dbus signal
Oct 20 20:25:07 <denkenz> consensus was against using dbus for it
Oct 20 20:25:23 <denkenz> dbus signals are racy and a plugin is more flexible
Oct 20 20:25:42 <denkenz> There's nothing preventing you from sending a dbus signal from the plugin if you like
Oct 20 20:32:42 <crevetor> denkenz: That's what I'm thinking but then again if you didn't do it for a good reason I might as well not do it...
Oct 20 20:33:02 <denkenz> The basic idea was to either integrate with ntpd
Oct 20 20:33:03 <crevetor> But I don't see how it's gonna fit in our project without using dbus...
Oct 20 20:33:10 <denkenz> Or set the the time directly
Oct 20 20:33:14 <holtmann> The idea was that the plugin send a method call to a time daemon controlling time.
Oct 20 20:33:26 <denkenz> Setting the time directly is easier done through a plugin in oFono itself
Oct 20 20:33:27 <holtmann> And that daemon then makes a decision to either trust that time or not.
Oct 20 20:33:50 <denkenz> ntpd integration is really out of scope for oFono and nobody had time to look into it
Oct 20 20:33:55 <crevetor> denkenz: Well it all depends on your platform..
Oct 20 20:34:19 <denkenz> Of course, but the plugin gives you all the flexibility with no downsides
Oct 20 20:34:30 <crevetor> how is this going to work in meego ? Is it going to directly update the system time ?
Oct 20 20:34:31 <holtmann> denkenz: ntpd is a pain in the butt. See ConnMan for just telling ntpd about its new servers. They overdesigned that API.
Oct 20 20:34:52 <holtmann> crevetor: No idea. Not our problem actually.
Oct 20 20:35:09 <holtmann> As I said before, some time ago the idea was that there is general time daemon.
Oct 20 20:35:14 <crevetor> The thing is that android expects NITZ notifications for network originated time... So we don't have much choice
Oct 20 20:35:16 <holtmann> Not sure if that ever happened or not.
Oct 20 20:35:51 <holtmann> Just ignore NITZ. Only a few networks send these anyway. Out of 4 German operators, only one sends it.
Oct 20 20:36:25 <denkenz> NITZ is entirely stupid btw
Oct 20 20:36:40 <holtmann> And then 90% of the modems doesn't even tell you about it.
Oct 20 20:36:43 <denkenz> We're better off packaging an LAC/CI mapping to timezone
Oct 20 20:36:46 <denkenz> Way more reliable
Oct 20 20:36:50 <holtmann> ISI and IFX might be the only ones which actually do.
Oct 20 20:37:18 <holtmann> You can't trust NITZ for operators that span multiple timezones. They will fuck this up.
Oct 20 20:37:28 <holtmann> Rogers in Canada just did recently again.
Oct 20 20:37:38 <holtmann> The switch all of West coast to east cost time ;)
Oct 20 20:37:50 <holtmann> Or was it Fido, don't remember. One of them did.
Oct 20 20:37:58 <crevetor> holtmann: well my network send it and people will expect it to work if their network has it...
Oct 20 20:38:11 <holtmann> If you hardware supports it.
Oct 20 20:38:26 <denkenz> he's probably using n900 to android hack
Oct 20 20:38:26 <holtmann> As I said, I have seen it on ISI modem and IFX for the first time.
Oct 20 20:38:31 <denkenz> so his hardware does ;)
Oct 20 20:38:31 <crevetor> holtmann: that's my provider :)
Oct 20 20:38:50 <denkenz> Anyway, bottom line, nettime plugin is what you want
Oct 20 20:38:53 <holtmann> Let me repeat this. Not all modems give you this information. Even if the network sends it.
Oct 20 20:38:53 <crevetor> holtmann: fido is a MVNO of Rogers so the network is the same
Oct 20 20:39:07 <denkenz> How you integrate it is a homework assignment
Oct 20 20:39:08 <holtmann> Network is the same, but they might not send the network time.
Oct 20 20:39:31 <crevetor> m yhardware does, it's N900 and I see ofono saying it received NITZ so..
Oct 20 20:39:38 <holtmann> O2 in Germany used the T-Mobile network for some time. On O2 you got CBS and NITZ on T-Mobile you didn't.
Oct 20 20:39:59 <crevetor> holtmann: our implementation is n900 specific anyways so we now it supports it..
Oct 20 20:40:05 <holtmann> So nettime plugin and let it talk to your time daemon in Android.
Oct 20 20:40:23 <holtmann> Whatever piece that is and however it works.
Oct 20 20:40:57 <crevetor> holtmann: I'll figure out the right way to do it :)
Oct 20 20:49:26 <crevetor> You guys don't work with the meego team ?
Oct 20 20:50:16 <denkenz> we do
Oct 20 20:50:21 <kristenc> I have an mbm modem which I can see with list-modems.  However, when I go to online-modem, I get an error telling me that the operation is not available.  Is there something else I need to do?
Oct 20 20:50:43 <denkenz> enable-modem first
Oct 20 20:51:31 <holtmann> crevetor: We do work with the meego team, but we enable features for everybody. Hence the plugin concept.
Oct 20 20:51:35 <balrog-k1n> denkenz: no i haven't seen Set Up Event, basically across the three cards only six commands are used if i remember correctly
Oct 20 20:51:50 <kristenc> enable-modem fails.
Oct 20 20:52:33 <denkenz> balrog-k1n: Ok, I just noticed set up event is actually needed for 'user action' and 'idle screen available'
Oct 20 20:52:44 <denkenz> balrog-k1n: Which of course make no sense, but hey this is GSM ;)
Oct 20 20:53:08 <denkenz> kristenc: what is this mbm modem, and sounds like you need to pastebin the debug trace + at trace
Oct 20 20:53:15 <holtmann> Maybe this is specific to the French SIM cards.
Oct 20 20:53:29 <denkenz> holtmann: More likely specific to the SIM simulator
Oct 20 20:53:31 <balrog-k1n> denkenz: to me it makes sense that the card needs to enabled events, so we don't send it stuff it's not interested in
Oct 20 20:53:41 <kristenc> denkenz: it's a Dell that I've never used before that I'm trying to use with an AT&T sim card.
Oct 20 20:53:48 <holtmann> denkenz: They don't have that one yet. So this must be a real SIM card.
Oct 20 20:54:15 <denkenz> Then it is probably launch browser and not our problem
Oct 20 20:54:18 <kristenc> ofonod[5795]: plugins/udev.c:add_mbm() desc: Dell Wireless 5540 HSPA Mini-Card GPS Port
Oct 20 20:54:28 <denkenz> My 5540 works just fine
Oct 20 20:55:03 <kristenc> yes, it looks like it should work, that's why I'm assuming this is operator error.  But I don't know what I"m supposed to do.
Oct 20 20:55:39 <denkenz> well, try minicom manually first
Oct 20 20:55:47 <denkenz> are the tty ports showing up?
Oct 20 20:56:36 <kristenc> ok - I found my problem.
Oct 20 21:03:00 <crevetor> holtmann: ok
Oct 20 21:13:55 <crevetor> Thanks for your help guys
**** ENDING LOGGING AT Thu Oct 21 02:59:57 2010