**** BEGIN LOGGING AT Fri Mar 04 02:59:59 2011 Mar 04 05:52:38 holtmann: how we can get NITZ value with example nettime plugin on IFX modem? Mar 04 05:53:01 I setup this env but did not get any network time. Mar 04 05:56:12 perhaps network did not provide this feature, just want to confirm, does need other additional action to do? Mar 04 10:54:15 zgli: No. And yes, most likely your network does not send time updates. Mar 04 13:23:37 holtmann: i'm implementing the dial string property in voicecall... one doubt: what's a second stage dial string? Mar 04 13:24:13 it was a task added by pekka pessi a while back :-\ Mar 04 15:27:02 demarchi: second stage dial string is something that is not a number, but dtmf tones to be sent after Mar 04 15:27:22 e.g. +15551234p8888 Mar 04 15:27:48 everything before the p would be the dialing number for say voicemail Mar 04 15:27:54 8888 might be your pin Mar 04 17:07:25 denkenz: Are all modems capable of handling multiple active contexts at the same time ? Mar 04 17:18:18 sameo: not the datacards Mar 04 17:18:29 only mbm can that I know of Mar 04 17:19:00 denkenz: Is this capability somehow exported through the oFono API ? Mar 04 17:19:23 denkenz: Does the modem even let you know about it ? Mar 04 17:19:51 oFono knows on a basic level that a modem is capable of multiple contexts Mar 04 17:20:05 On the API level your 2nd context activation will simply fail Mar 04 17:21:14 e.g. you will get a NotImplemented error Mar 04 17:22:05 I see. We're currently not allowing multiple connections per interfaces in ConnMan, and I was wondering if it was possible to allow this on a per device basis. But I guess it would be easier to do so per technology instead. Mar 04 17:23:31 you will get a different interface for each context Mar 04 17:24:26 oh, that's easier then. Mar 04 17:25:23 denkenz: I'm actually implementing the basis for the BIP commands (class e). Do you think we should consider the possibility to handle simultaneously multiple channels? Mar 04 17:25:55 denkenz: In practice, it requires to handle a list of channel. Currently, it's not what I did. So Before going further, I would like to clarify. Mar 04 17:26:43 I'd do the simple thing first, then extend it to support multiple channels Mar 04 17:27:06 In the long run we probably want the full functionality in the long term Mar 04 17:35:13 Ok, then I continue like that but extending to support multiple channels would require modifications in the structures...We could avoid that actually. But personally I would prefer also to start simply as multiple channel is not something even tested... Mar 04 17:41:59 modification later isn't a problem Mar 04 17:42:09 Our rule of thumb is always to do the simple things first Mar 04 17:47:35 denkenz: OK. Another question: there is a rule which indicates " if an alpha id is provided in the command but the alpha id is a null data object then it means that we should not inform the user about the current activity". I'm willing to comply to this rule but I'm wondering if we have already decided to skip this rule for other proactive commands ? Mar 04 17:49:18 That was a topic of some churn a few months back Mar 04 17:49:40 I think we decided to treat omitted, null and empty alpha ids the same Mar 04 17:49:47 But check the current implementation Mar 04 17:52:42 Yes, it's what I can see .So, I will also consider to always inform the user. Which is better from a user point of view. As a user, I would dislike that my device tries to setup a data connection silently... Mar 04 17:55:11 Jeevaka and balrog-k1n: Can comment further Mar 04 17:55:27 Right now it might be that we simply give an empty string in these cases Mar 04 17:55:40 so there's not a whole lot of value in displaying that anyway Mar 04 17:57:22 And in theory we should try to comply with that stk rule, which sounds like we get wrong Mar 04 17:58:30 denkenz: yes, I noticed that. I assumed that this empty text could be in this case "override" by the STK agent. Mar 04 17:59:53 Perhaps, but I'd rather avoid that Mar 04 17:59:57 But it requires for the STK agent to distinguish which is the current activity. When displying the action info, I'm afrais we can't distinguish if it is Send SS / Snd SMS/ Send USSD... Mar 04 18:00:23 The biggest issue is that the spec is braindead Mar 04 18:00:47 It allows ommitted text/alpha id, len=0 text/alpha id and len=1 text/alpha id Mar 04 18:00:59 And leaves much room for interpretation Mar 04 18:02:28 So do you think we should reconsider to comply to this rule ? Mar 04 18:03:01 Yes, we should comply with as much as possible Mar 04 18:03:51 So be it. Thanks. Mar 04 18:08:43 Jeevaka, balrog-k1n: Can you re-examine our alpha identifier handling. Sounds like we still get it wrong Mar 04 18:30:30 sameo: Actually ConnMan should ever only deal with one context. Only exception might be the old non-dualstack of IP and IPv6 combination. Mar 04 18:31:14 However there we have to see on how the networks deal with IPv6 anyway. Maybe sending IPv4 packet over IPv6 network will be just fine. Or the operators finally got to the IPv4v6 dual context. Mar 04 18:42:58 holtmann: what about the mms context ? Who's going to activate it ? Mar 04 19:03:18 sameo: MMS is done only via oFono and oFono creates a host route to the MMS proxy. Mar 04 19:03:37 holtmann: ok, I wasn't sure about that. Mar 04 19:05:41 It is documented in doc/connman-api.txt in ofono.git. Mar 04 19:05:55 ConnMan should only ever care about contexts with the Type=Internet. **** ENDING LOGGING AT Sat Mar 05 02:59:56 2011