Created an attachment (id=1011965) mtklog-voicemail.zip Related link: https://bugzilla.mozilla.org/show_bug.cgi?id=1085765 Test step: 1. Send a voicemail SMS to MT; 2. From log, you can find SMS_ACKNOWLEDGE error as following: mtklog-voicemailmobilelogAPLog_2014_1104_203149main_log 11-04 20:33:50.925 166 641 I Gecko : RIL Worker: [0] Solicited response for request type 37, token 133, error 2

Hi Reporter, Gecko follow the spec in TS 23.038 to send the ACK according to the handled result of the receiving SMS. The only case we don't send this ACK is the case when the message class of the received SMS is class-2 due to the follow reason and expect this to be handled by modem: " When a mobile terminated message is Class 2 ((U)SIM-specific), an MS shall ensure that the message has been transferred to the SMS data field in the (U)SIM before sending an acknowledgement to the SC " The entry point to not send a ACK for class 2 SMS is located at: https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/file/7198906837e7/dom/system/gonk/RadioInterfaceLayer.js#l3060 However, after checking the logs, I found something strange in modem side: 1. The DCS of this MWI is 0xd8, which is a |Message Waiting Indication Group: Store Message| MWI w/o Message Class specified. (It's not a class-2 SMS actually!) 2. This MWI with normal message class seems to be saved into SIM by modem directly and notified via UNSOLICITED_RESPONSE_NEW_SMS_ON_SIM to Gecko. However, by my understanding, the flow of a normal class SMS (no matter that it's a MWI or not) shall be notified by UNSOLICITED_RESPONSE_NEW_SMS instead. Hence, we need modem vendor's help to check why this |non-class-2| MWI was stored directly into SIM by modem while gecko expects to send an ACK after a non-class-2 SMS is handled.

Created an attachment (id=1012258) YarisM 对比测试mtklog.rar 添加对比机YarisM的log

Created an attachment (id=1012258) YarisM 对比测试mtklog.rar 添加对比机YarisM的log

Created an attachment (id=1012258) YarisM 对比测试mtklog.rar 添加对比机YarisM的log

Hi Peng Qi, Could you help to check the modem part per comment 5? Thank you!

(In reply to Josh Cheng [:josh] from comment #9) > Hi Peng Qi, > Could you help to check the modem part per comment 5? Thank you! Sorry, pal, I'm not in charge of SMS related issues, and know little about it. -_-||

Before, I have explained the question about "why this |non-class-2| MWI was stored directly into SIM by modem" in a mail involving mozilla contact window "Shawn Ku". Now, I write here again for remembering. This message is a "message waiting indiction group(store)" as Bevis said. so you can refer SPC 27.005, Table 3.4.1-3(as follow). note:"class 2 or message waiting indication group (store)", the conjunction is "or". this case is just the case that is after "or". so modem gives URC "CMTI". "CMTI" just does not need acknowledge. so please mozilla colleagues help check it again. thanks! ps: Table as follows Table 3.4.1-3: SMS-DELIVER result code and acknowledgement summary <mt> no class or class 1 class 0 or message waiting indication group (discard) class 2 or message waiting indication group (store) class 3 1 +CMTI [+CMTI1)] +CMTI +CMTI 2 +CMT & +CNMA3) +CMT [& +CNMA2)] +CMTI +CMT & +CNMA3) 3 +CMTI [+CMTI1)] +CMTI +CMT & +CNMA3) 1) result code is sent when ME does not have other display device than AT interface. 2) acknowledgement command must be sent when +CSMS <service> value equals 1 and ME does not have other display device than AT interface. 3) acknowledgement command must be sent when +CSMS <service> value equals 1.

(In reply to woodduck from comment #11) > Before, I have explained the question about "why this |non-class-2| MWI was > stored directly into SIM by modem" in a mail involving mozilla contact > window "Shawn Ku". > > Now, I write here again for remembering. > > This message is a "message waiting indiction group(store)" as Bevis said. > > so you can refer SPC 27.005, Table 3.4.1-3(as follow). > > note:"class 2 or message waiting indication group (store)", the conjunction > is "or". this case is just the case that is after "or". so modem gives URC > "CMTI". "CMTI" just does not need acknowledge. > > so please mozilla colleagues help check it again. thanks! > > ps: Table as follows > > Table 3.4.1-3: SMS-DELIVER result code and acknowledgement summary > <mt> no class or class 1 class 0 or message waiting indication group > (discard) class 2 or message waiting indication group (store) class 3 > 1 +CMTI [+CMTI1)] +CMTI +CMTI > 2 +CMT & +CNMA3) +CMT [& +CNMA2)] +CMTI +CMT & +CNMA3) > 3 +CMTI [+CMTI1)] +CMTI +CMT & +CNMA3) > 1) result code is sent when ME does not have other display device than AT > interface. > 2) acknowledgement command must be sent when +CSMS <service> value equals 1 > and ME does not have other display device than AT interface. > 3) acknowledgement command must be sent when +CSMS <service> value equals 1. Hi, Thanks for pointing out |Table 3.4.1-3 SMS-DELIVER result code and acknowledgement summary| in 3GPP TS 27.005. After further study in 27.005 and 23.038, I'd like NI chip vendor(wudduc@gmail.com) to double confirm: 1. Why the MWIG(store) SMS has to be stored in SIM: (MWIG: Message Waiting Indication Group) - According to |Table 3.4.1-2: <mt> parameter| in 27.005, unlike class-2 SMS(SIM-Specific), the preferred storage of MWIG(store) is relied on <mem3> in +CPMS. - However, if CMTI has to be applied to comply 27.005 with available RIL commands, there is only one RIL command can be used RIL_UNSOL_RESPONSE_NEW_SMS_ON_SIM, which restrict the <mem> parameter of +CMTI to be "SM":(U)SIM. - Is this the reason why MWIG(store) SMS was stored to SIM? 2. Is there any impact of this SMS_ACKNOWLEDGE error? Will the SMS ACK request (+CNMA) be sent to the network? If not, I'd like suggest to lower the severity of this issue, because this error is just a warning between gecko and modem for the unnecessary request of SMS_ACK. Set NI to chip vendor(wudduc@gmail.com) for the 2 questions mentioned above. set NI to reporter(sync-1@bugzilla.tld) to triage this as non-blocker if it's just a warning instead of a critical error.

I echo comment 12 to see if any test case failure or fatal error on this case. or We can ignore this error without doing correction.

Hi Wenquan, Please check #12. Thanks.

(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #12) > (In reply to woodduck from comment #11) > > Before, I have explained the question about "why this |non-class-2| MWI was > > stored directly into SIM by modem" in a mail involving mozilla contact > > window "Shawn Ku". > > > > Now, I write here again for remembering. > > > > This message is a "message waiting indiction group(store)" as Bevis said. > > > > so you can refer SPC 27.005, Table 3.4.1-3(as follow). > > > > note:"class 2 or message waiting indication group (store)", the conjunction > > is "or". this case is just the case that is after "or". so modem gives URC > > "CMTI". "CMTI" just does not need acknowledge. > > > > so please mozilla colleagues help check it again. thanks! > > > > ps: Table as follows > > > > Table 3.4.1-3: SMS-DELIVER result code and acknowledgement summary > > <mt> no class or class 1 class 0 or message waiting indication group > > (discard) class 2 or message waiting indication group (store) class 3 > > 1 +CMTI [+CMTI1)] +CMTI +CMTI > > 2 +CMT & +CNMA3) +CMT [& +CNMA2)] +CMTI +CMT & +CNMA3) > > 3 +CMTI [+CMTI1)] +CMTI +CMT & +CNMA3) > > 1) result code is sent when ME does not have other display device than AT > > interface. > > 2) acknowledgement command must be sent when +CSMS <service> value equals 1 > > and ME does not have other display device than AT interface. > > 3) acknowledgement command must be sent when +CSMS <service> value equals 1. > > Hi, > > Thanks for pointing out |Table 3.4.1-3 SMS-DELIVER result code and > acknowledgement summary| in 3GPP TS 27.005. After further study in 27.005 > and 23.038, > > I'd like NI chip vendor(wudduc@gmail.com) to double confirm: > 1. Why the MWIG(store) SMS has to be stored in SIM: (MWIG: Message Waiting > Indication Group) > - According to |Table 3.4.1-2: <mt> parameter| in 27.005, unlike class-2 > SMS(SIM-Specific), the > preferred storage of MWIG(store) is relied on <mem3> in +CPMS. > - However, if CMTI has to be applied to comply 27.005 with available RIL > commands, there is only > one RIL command can be used RIL_UNSOL_RESPONSE_NEW_SMS_ON_SIM, which > restrict the <mem> parameter of > +CMTI to be "SM":(U)SIM. > - Is this the reason why MWIG(store) SMS was stored to SIM? > 2. Is there any impact of this SMS_ACKNOWLEDGE error? > Will the SMS ACK request (+CNMA) be sent to the network? > If not, I'd like suggest to lower the severity of this issue, because > this error is just a > warning between gecko and modem for the unnecessary request of SMS_ACK. > > Set NI to chip vendor(wudduc@gmail.com) for the 2 questions mentioned above. > set NI to reporter(sync-1@bugzilla.tld) to triage this as non-blocker if > it's just a warning instead of a critical error. 1. Why the MWIG(store) SMS has to be stored in SIM: (MWIG: Message Waiting Indication Group) - According to |Table 3.4.1-2: <mt> parameter| in 27.005, unlike class-2 SMS(SIM-Specific), the preferred storage of MWIG(store) is relied on <mem3> in +CPMS. [Answer] we can see the log, the +CPMS return "SM" "SM" "SM", the <mem3> is just "SM" - However, if CMTI has to be applied to comply 27.005 with available RIL commands, there is only one RIL command can be used RIL_UNSOL_RESPONSE_NEW_SMS_ON_SIM, which restrict the <mem> parameter of +CMTI to be "SM":(U)SIM. [Answer]yes - Is this the reason why MWIG(store) SMS was stored to SIM? [Answer]because the APP always store them in ME and modem only use SIM now. 2. Is there any impact of this SMS_ACKNOWLEDGE error? [Answer]it is just a error prompt, Modem has ack to network correctly. if this is not a test item of some requirement, I think this should be not any impact. Will the SMS ACK request (+CNMA) be sent to the network? [Answer]yes, ack will be sent to the network. For CMT, app do the ack, and for CMTI, modem do it. If not, I'd like suggest to lower the severity of this issue, because this error is just a warning between gecko and modem for the unnecessary request of SMS_ACK. [Answer]this question need [sync-1@bugzilla.tld] to confirm

(In reply to woodduck from comment #15) Hi! sync-1@bugzilla.tld Please show your confirmation. Thanks -- Keven

Close the bug for until until partner have further concern.

Pls close it.