**** BEGIN LOGGING AT Wed Mar 16 02:59:57 2011
Mar 16 04:21:10 <Rishi_> Hi anyone here ?
Mar 16 16:45:43 <Jeevaka> denkenz: ping
Mar 16 16:47:16 <denkenz> Jeevaka: pong
Mar 16 16:47:44 <Jeevaka> there is an issue with send sms failure case
Mar 16 16:49:45 <Jeevaka> conformance test cases 27.22.8 seq 1.4 is failing due to SMS retry feature
Mar 16 16:50:01 <Jeevaka> Spec reference 31.124
Mar 16 16:51:00 <denkenz> STK should not be enabling retries
Mar 16 16:52:50 <Jeevaka> no, issue is different
Mar 16 16:53:09 <denkenz> oh?
Mar 16 16:55:19 <Jeevaka> As per the spec, SMS should not be sent.
Mar 16 16:55:53 <Jeevaka> As expected, it is not sent. but we are doing a retry after 5seconds
Mar 16 16:57:09 <Jeevaka> due to this, test case is failing as it is not expecting an another Envelope SMS 
Mar 16 16:57:31 <denkenz> as I said, we're not enabling retries
Mar 16 16:57:49 <denkenz> So it could be a bug in the SMS code
Mar 16 16:58:25 <denkenz> However, looking at the code that seems fine
Mar 16 16:58:35 <denkenz> Is network registration being twiddled in the process?
Mar 16 16:59:43 <Jeevaka> nope
Mar 16 17:00:26 <Jeevaka> in tx_finished function, we are having "Sending failed, retry in ***"
Mar 16 17:02:50 <Jeevaka> we are updating the flag with OFONO_SMS_SUBMIT_FLAG_RETRY in sms_send_message
Mar 16 17:05:03 <denkenz> then that's wrong
Mar 16 17:05:23 <denkenz> However, where do you see that?
Mar 16 17:06:20 <denkenz> Since sms_send_message is the D-Bus API, not called from STK
Mar 16 17:06:20 <Jeevaka> file: sms.c, function: tx_finished, sms_send_message
Mar 16 17:08:10 <denkenz> I really don't see how
Mar 16 17:08:13 <Jeevaka> if SMS send fails, then we are resending it in 5seconds
Mar 16 17:09:44 <denkenz>                 if (!(entry->flags & OFONO_SMS_SUBMIT_FLAG_RETRY))
Mar 16 17:09:45 <denkenz>                         goto next_q;
Mar 16 17:09:48 <denkenz> We shouldn't be
Mar 16 17:11:08 <Jeevaka> flags value is set in the sms_send_message. right?
Mar 16 17:12:01 <denkenz> no, stk calls __ofono_sms_txq_submit
Mar 16 17:12:04 <denkenz> it passes no flags
Mar 16 17:12:52 <Jeevaka> use case we are discussing here is sms sent by the user not by SAT
Mar 16 17:13:04 <Jeevaka> sms initiated by user
Mar 16 17:13:18 <denkenz> ah
Mar 16 17:13:54 <Jeevaka> 31.124 specification, test case test 27.22.8 seq 1.4
Mar 16 17:14:14 <denkenz> not much we can do really
Mar 16 17:14:52 <Jeevaka> yes, I know. but I was thinking if the error code is common between all AT modems, then we can disable the retry right?
Mar 16 17:15:14 <denkenz> what does the modem return?
Mar 16 17:15:22 <denkenz> If its one of the permanent errors, then sure
Mar 16 17:15:33 <Jeevaka> ifx returns, CMS error 540
Mar 16 17:15:57 <Jeevaka> manufacturer specific :(
Mar 16 17:16:11 <denkenz> yeah, so no luck there ;)
Mar 16 17:17:02 <denkenz> You can create your own certification specific plugin which won't enable retries
Mar 16 17:17:46 <denkenz> Or we can argue about whether retries are a good idea
Mar 16 17:18:45 <Jeevaka> 2nd options seems to be interesting ;)
Mar 16 17:18:57 <denkenz> lol
Mar 16 17:19:50 <denkenz> What does the test expect the modem to report?
Mar 16 17:20:18 <denkenz> If 27.005 has proper errors for this, then we can abort retrying
Mar 16 17:20:40 <denkenz> And then have IFX fix their firmware
Mar 16 17:22:25 <Jeevaka> issue is test spec doesnt specify any standard error. as usual spec leaves it open
Mar 16 17:23:04 <Jeevaka> I was thinking of using 313 - SIM failure for this case
Mar 16 17:23:26 <denkenz> We have to check the error codes regardless
Mar 16 17:23:39 <denkenz> especially 301 and 330
Mar 16 17:23:50 <Jeevaka> or even 302
Mar 16 17:24:03 <denkenz> yep, so those we need to take care of anyway
Mar 16 17:24:23 <denkenz> since I've already had cases where my SMSC was not configured properly and I kept re-sending
Mar 16 17:24:41 <denkenz> Then there are weird networks which report an error but send the SMS anyway
Mar 16 17:25:30 <Jeevaka> we can raise a bug on the network side for that ;)
Mar 16 17:25:45 <denkenz> yep ;)
Mar 16 17:26:27 <denkenz> I don't know what to tell you, maybe we should whitelist errors to retry on rather than blacklist
Mar 16 17:26:58 <Jeevaka> ok
Mar 16 17:27:04 <denkenz> so e.g. retry on 332 for now and see how far we get
Mar 16 17:28:22 <Jeevaka> ok
**** ENDING LOGGING AT Thu Mar 17 02:59:57 2011