**** BEGIN LOGGING AT Fri Jan 14 02:59:58 2011 **** BEGIN LOGGING AT Fri Jan 14 11:39:04 2011 Jan 14 13:38:22 balrog-k1n: I was thinking to do that next, but sure, go ahead? Jan 14 13:46:15 holtmann: ping Jan 14 13:46:39 Jeevaka: pong Jan 14 13:47:32 as per the ifx AT command spec, AT+CTMS? should result in +XCTMS: but the actual result is CTM/TTY mode: Jan 14 13:50:00 do we need to request infineon forcorrect spec or do we need to modify the code depending on the actual result Jan 14 13:50:07 Looks like it. Jan 14 13:50:15 At least this needs to be clarified. Jan 14 13:50:33 However the spec makes sense. Using CTM/TTY mode: does not. At least from where I am standing. Jan 14 13:50:47 Mail Fred about this and CC me on it. Jan 14 13:53:06 AT+XCTMS=? is result in +XCTMS where as spec says CTM/TTY mode: (list of supported s) Jan 14 13:53:13 :) Jan 14 13:57:20 Can you send Fred, Denis and myself an email about it with all example of +XCTMS. This looks like a funny command ;) Jan 14 13:58:51 ok, i'll do that Jan 14 14:01:04 Jeevaka: Thanks. Jan 14 14:03:43 hmm, if I have held+waiting calls, how am I supposed to answer the waiting call? Jan 14 14:04:24 HoldAndAnswer (+CHLD=2) seems to make the held call active, and waiting on hold Jan 14 14:04:49 ;) Jan 14 14:04:57 with ifx? Jan 14 14:05:24 pessi: only at modem I have atm Jan 14 14:07:45 I mean from API perspective it really would make sense if I could Answer() the call Jan 14 14:08:44 (both for incoming and waiting, but alas that's not the AT way it seems) Jan 14 14:17:44 denkenz: any objection to adding the Answer method? (and Hold while we are at it) Jan 14 14:19:20 pessi: and option is to (ab)use PrivateChat, but that requires patching anyways (currently checks for hold, I'm taking a look at patching this now) Jan 14 14:47:42 pessi: the current API is just fine, you have to use HoldAndAnswer Jan 14 14:48:21 denkenz: but see above, it answers the wrong call Jan 14 14:48:27 denkenz: how to answer the waiting call? Jan 14 14:49:45 "Entering 2 followed by SEND - Places all active calls (if any exist) on hold and accepts the other (held or waiting) call." Jan 14 14:49:55 File a bug against the vendor ;) Jan 14 14:51:07 3gpp? Jan 14 14:51:14 22.030 yes Jan 14 14:51:56 denkenz: sms atom is using for Service Center Address 20 digits as MAX length number. Which is the proper max length for it? I have not found yet into docs. (I need to know for the long number task) Jan 14 14:51:57 they accept CRs, not bugs. the problem is if you have hold call and waiting call Jan 14 14:52:22 denkenz: but that doesn really tell what happens when you have one held call and one waiting Jan 14 14:52:57 zrafa: have a peek in 24.011? Jan 14 14:53:34 denkenz: it tells it accepts the other "held or waiting" call, but which, can I rely this is a strictly ordered list, e.g. if there is a held call, that will always become active Jan 14 14:55:19 pessi: ah.. let me read Jan 14 14:56:18 denkenz: and even if the strict ordering would hold, that's still sucks as I don't want to enable the held call (even for a brief moment), just to be able to answer the waiting call Jan 14 14:56:39 denkenz: if some modems cannot do this, that's their problem, but the API should allow some sane way to answer the waiting call Jan 14 14:58:35 kvehmanen: Yes it does, waiting calls always take precedence Jan 14 15:00:06 denkenz: aa, so this is an ifx bug then Jan 14 15:00:19 looks like it Jan 14 15:01:01 denkenz: do you have some AT modem that works properly..? the 3gpp at spec looks dangerously openly-worded Jan 14 15:01:23 mbm does all this stuff properly and so does calypso Jan 14 15:09:12 denkenz: ok thanks, that's convincing enough for me Jan 14 15:24:22 pessi: thanks, that is more clear.. Jan 14 16:33:05 Denis: So far, I can't see in ofono any SIM phonebook import (even not a caching of the file EFADN) Jan 14 16:33:05 I'm just wondering if we are skipping this feature voluntary or this is on the TODO list? Jan 14 16:33:05 I remember that there is a GCF test case requiring to update the SIM phonebook in case of Refresh proactive command with EFADN given as a modified file. Jan 14 16:33:05 So, actually, this GCF test case may fail in our case. Jan 14 16:35:00 denkenz: This is a diff of a work in progress for the long number task: http://pastebin.com/MD6hQw23 . What do you think of that idea?. It would need to re work the phone_number_to_string() and string_to_phone_number() for different lengths as well.. Jan 14 16:40:18 pnunes: Have you look at the doc/phonebook-api.txt? Jan 14 16:41:28 Ok, I understand that it's ongoing. Fine. Do we intend to support also 3G extended fields ? Jan 14 16:42:43 pnunes: I'm lost, we've always supported extended fields Jan 14 16:42:59 zrafa: I actually don't want sca and sim phone number structs in types.h Jan 14 16:43:51 denkenz: okey, but moving them to the proper places would be okey? Jan 14 16:45:37 zrafa: I think you can keep using ofono_phone_number, just do the length checking properly Jan 14 16:46:42 denis: yes, indeed, you're right I can see we handle group, adnumber, adtype, secondtext, email, sip_uri, tel_uri. Perfect. Jan 14 16:48:23 denkenz: okey, like you can see at that pastebin I added so far two valid_phone_number checks more for spliting the current one, so sms.c would use valid_sca_phone_number_format() for example. Jan 14 16:48:52 I think that is fine Jan 14 16:49:49 Denis: What about Call control or MO SMS control? I can see that we can build the related envelop commands and parse the SIM answers but currently this service is not solicited ? right? Jan 14 16:51:13 We do not support call control by sim right now since all modems do this inside their firmware Jan 14 16:52:19 Even for a call setup initiated by a proactive command? Jan 14 16:52:56 call setup initiated by a proactive command is not subject to call control Jan 14 17:04:04 My understanding is that for USIM, the call control (of course if this service is available in the USIM service table) shall be invoked for all call set-up attempts (even those resulting from a SET UP CALL proactive SIM command). That's why we may find a call control TLV object in the Terminal Response for the SETUP Call Jan 14 17:07:48 I guess we should be notified from the answer made by the SIM to the envelope cmd sent directly by the modem. Jan 14 17:11:50 In this case, the call control requested action or the call control result could be included in the Terminal Response. Jan 14 17:16:06 We're never told of the proactive command if the call control fails Jan 14 17:16:34 Most modems handle setup call, send sms, send ss and send ussd inside the firmware Jan 14 17:16:50 call control is the reason why Jan 14 17:17:12 Then again, call control is the most bizarre feature known to man, who ever thought of it should be hanged Jan 14 17:17:30 especially the call -> ussd or -> sms rewriting Jan 14 17:19:08 But to answer your original question, you're correct that setup call is subject to call control Jan 14 17:19:14 indeed, except the call number modification (for a proper emergency code for example), I can't understand the goal in practice. Jan 14 17:19:24 I was actually confusing it with FDN, setup call is not subject to FDN Jan 14 17:20:13 even emergency calls are stupid, since the numbers mean nothing Jan 14 17:20:16 no, even if FDN is enabled, all the call initiated from a proactive comamnd shall pass Jan 14 17:20:40 that is what I meant, setup call dialed number is not checked against FDN Jan 14 17:21:10 yes, that's why it's bizarre... Jan 14 17:23:07 The problem is that this is fortunately not used in practice (so far as I know) but strictly tested by GCF... Jan 14 17:24:17 Well since oFono doesn't even allow SIMs with FDN enabled, not really our problem Jan 14 17:28:20 If we consider that the call setup AND the call control is handled by the modem, then I don't see any issue at least when the call is not modified into another SS or USSD request. Our UI will reflect the call control result (either because the call is released or because the number modification is reported through AT+CLCC for exemple) Jan 14 17:29:40 At this stage I understand that for this feature we are dependent of the modem capability. Jan 14 17:30:15 Actually I don't believe having working support for call control is possible Jan 14 17:30:30 it is handled too widely differently by all the vendors Jan 14 17:30:42 And even android just punts on it Jan 14 17:32:18 however, I welcome any ideas anyone might have ;) Jan 14 17:36:58 Ok, I will think about that. The goal is to find a "generic" solution compatible with all modem capabilities. My personal experience is that when the call setup is not handled by the modem, the call control is neither handled by the modem. It means that if we implemented the call setup, we may think to implement also the call control service. Just my opinion... Jan 14 17:37:56 Oh I'd love to do the entire call control in oFono Jan 14 17:38:03 That would actually be sane Jan 14 17:38:29 however, most vendors try to hide this somehow Jan 14 17:38:33 just check the IFX docs Jan 14 17:38:47 as an example Jan 14 17:41:46 Feel free to add a task to the TODO and start hacking on this btw Jan 14 17:42:08 Supporting call control envelopes is actually pretty simple Jan 14 17:43:17 Sure, I will. For now, my weekend starts...Thanks. **** ENDING LOGGING AT Sat Jan 15 03:00:01 2011