Closed Bug 999867 Opened 7 years ago Closed 6 years ago

[Sora]MMS receiving is not possible

Categories

(Firefox OS Graveyard :: RIL, defect, P1)

defect

Tracking

(blocking-b2g:1.3+, b2g-v1.3 fixed, b2g-v1.3T fixed, b2g-v1.4 fixed, b2g-v2.0 fixed)

RESOLVED FIXED
2.0 S3 (6june)
blocking-b2g 1.3+
Tracking Status
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: sync-1, Assigned: bevis)

Details

(Whiteboard: [p=3] [cert])

Attachments

(3 files, 2 obsolete files)

Mozilla build ID:20140404164003
 
 issue reported from TMO HR 
 
 Description: It is not possible to receive MMS message on both samples tested. Sending works OK but MMS messages sent ot Fire C are never delivered/displayed on the device. I have attached logs from the device, we will try to get networks logs during the day.
 
 Customer Impact Statement: customers will think they have a faulty device
 
 Expected Behaviour: MMS sending and receiving must work properly
 		
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
Attached file log
Attachment #8410714 - Attachment mime type: application/octet-stream → application/zip
Unfortunately, we didn't see the MmsService logs are enabled in the logcat.
Would you please help to apply this attached script to capture the adb logcat?
We suppose to see "MmsService" related logs in the captured log.

In addition, please also help to capture the tcpdump at the same time for further analysis.

Thanks,
Bevis
Flags: needinfo?(sync-1)
Component: Gaia::SMS → RIL
Flags: needinfo?(sync-1)
Summary: [Sora][HOMO][TMO 56842 ]MMS receiving is not possible → [Sora]MMS receiving is not possible
NI was cancelled due to summary changed.
NI again for the information in comment 2.
Flags: needinfo?(sync-1)
the sms patch is as follow:

	Line 1569: 04-22 07:58:11.305 D/use-Rlog/RLOG-RIL_QC_B2G(  291): [SUB0] [UNSL]< UNSOL_RESPONSE_NEW_SMS { SMSC=385980501, mti=0, udhi=64, sender=1598, receiver=, pid=0, epid=0, dcs=4, header={ length : 11, destinationPort : 2948, originatorPort : 9200, segmentRef : 194, segmentMaxSeq : 2, segmentSeq : 1, langIndex : 0, langShiftIndex : 0,  }, body=, binaryData=C206706170706C69636174696F6E2F766E642E7761702E6D6D732D6D657373616765004D6573736167652D49640076313131313371766762616477303000870D80726F6F740073797374656D00A94D4D532D52656C61792D44656C6976657279496E69746961746F720080A7AF848D018BC3938C82986D687163697871343371, messageRef=0, status=0, encoding=4, isMwi=0 Year=222, mon=3, day=22, hour=7, minute=58, second=5}
	Line 1583: 04-22 07:58:13.895 D/use-Rlog/RLOG-RIL_QC_B2G(  291): [SUB0] [UNSL]< UNSOL_RESPONSE_NEW_SMS { SMSC=385980501, mti=0, udhi=64, sender=1598, receiver=, pid=0, epid=0, dcs=4, header={ length : 11, destinationPort : 2948, originatorPort : 9200, segmentRef : 194, segmentMaxSeq : 2, segmentSeq : 2, langIndex : 0, langShiftIndex : 0,  }, body=, binaryData=7667626164773030406D6D732E742D6D6F62696C652E6872008D90890680542D48540096546573746E6120706F72756B61008A808E021C958805810301517F83687474703A2F2F31302E34382E36362E37352F736572766C6574732F6D6D733F6D6573736167652D69643D6D687163697871343371766762616477303000, messageRef=0, status=0, encoding=4, isMwi=0 Year=222, mon=3, day=22, hour=7, minute=58, second=6}
	Line 1665: 04-22 07:59:44.575 D/use-Rlog/RLOG-RIL_QC_B2G(  291): [SUB0] [UNSL]< UNSOL_RESPONSE_NEW_SMS { SMSC=385980501, mti=0, udhi=0, sender=T-HT, receiver=, pid=0, epid=0, dcs=0, header={ length : 0, destinationPort : -1, originatorPort : -1, segmentRef : 0, segmentMaxSeq : 0, segmentSeq : 0, langIndex : 0, langShiftIndex : 0,  }, body=Testna poruka / Test message., binaryData=, messageRef=0, status=0, encoding=0, isMwi=0 Year=222, mon=3, day=22, hour=7, minute=59, second=39}
	Line 1755: 04-22 08:00:01.335 D/use-Rlog/RLOG-RIL_QC_B2G(  291): [SUB0] [UNSL]< UNSOL_RESPONSE_NEW_SMS { SMSC=385980501, mti=0, udhi=64, sender=1598, receiver=, pid=0, epid=0, dcs=4, header={ length : 11, destinationPort : 2948, originatorPort : 9200, segmentRef : 123, segmentMaxSeq : 2, segmentSeq : 1, langIndex : 0, langShiftIndex : 0,  }, body=, binaryData=7B06706170706C69636174696F6E2F766E642E7761702E6D6D732D6D657373616765004D6573736167652D496400763131313133717667646E6675303100870D80726F6F740073797374656D00A94D4D532D52656C61792D44656C6976657279496E69746961746F720080A7AF848D018BC3938C82986D687163697871343371, messageRef=0, status=0, encoding=4, isMwi=0 Year=222, mon=3, day=22, hour=7, minute=59, second=55}
	Line 1769: 04-22 08:00:03.925 D/use-Rlog/RLOG-RIL_QC_B2G(  291): [SUB0] [UNSL]< UNSOL_RESPONSE_NEW_SMS { SMSC=385980501, mti=0, udhi=64, sender=1598, receiver=, pid=0, epid=0, dcs=4, header={ length : 11, destinationPort : 2948, originatorPort : 9200, segmentRef : 123, segmentMaxSeq : 2, segmentSeq : 2, langIndex : 0, langShiftIndex : 0,  }, body=, binaryData=7667646E66753031406D6D732E742D6D6F62696C652E6872008D90890680542D48540096546573746E6120706F72756B61008A808E021C958805810301517F83687474703A2F2F31302E34382E36362E37352F736572766C6574732F6D6D733F6D6573736167652D69643D6D6871636978713433717667646E6675303100, messageRef=0, status=0, encoding=4, isMwi=0 Year=222, mon=3, day=22, hour=7, minute=59, second=56}
	Line 6983: 04-22 08:04:22.055 D/use-Rlog/RLOG-RIL_QC_B2G(  291): [SUB0] [UNSL]< UNSOL_RESPONSE_NEW_SMS { SMSC=385980501, mti=0, udhi=64, sender=1598, receiver=, pid=0, epid=0, dcs=4, header={ length : 11, destinationPort : 2948, originatorPort : 9200, segmentRef : 214, segmentMaxSeq : 2, segmentSeq : 1, langIndex : 0, langShiftIndex : 0,  }, body=, binaryData=D606706170706C69636174696F6E2F766E642E7761702E6D6D732D6D657373616765004D6573736167652D4964007631313131337176676A627634303000870D80726F6F740073797374656D00A94D4D532D52656C61792D44656C6976657279496E69746961746F720080A7AF848D018BC3938C82986D687163697871343371, messageRef=0, status=0, encoding=4, isMwi=0 Year=222, mon=3, day=22, hour=8, minute=4, second=20}
	Line 7051: 04-22 08:04:22.435 D/use-Rlog/RLOG-RIL_QC_B2G(  291): [SUB0] [UNSL]< UNSOL_RESPONSE_NEW_SMS { SMSC=385980501, mti=0, udhi=64, sender=1598, receiver=, pid=0, epid=0, dcs=4, header={ length : 11, destinationPort : 2948, originatorPort : 9200, segmentRef : 214, segmentMaxSeq : 2, segmentSeq : 2, langIndex : 0, langShiftIndex : 0,  }, body=, binaryData=76676A6276343030406D6D732E742D6D6F62696C652E6872008D90890680542D48540096546573746E6120706F72756B61008A808E021C958805810301517F83687474703A2F2F31302E34382E36362E37352F736572766C6574732F6D6D733F6D6573736167652D69643D6D68716369787134337176676A627634303000, messageRef=0, status=0, encoding=4, isMwi=0 Year=222, mon=3, day=22, hour=8, minute=4, second=21}

maybe we can use the data to simulator the mms??
(In reply to buri.blff from comment #4)
> the sms patch is as follow:
> maybe we can use the data to simulator the mms??

Oh! Thanks for reminding this.
I just found something abnormal while decoding these WAP PUSH PDUs.
I'll figure out if there is anything wrong in the WSP PDU parser.
The problem that blocks WspPduHelper to process is that there are several well-known and 
complicated headers such as "authorization" was not implemented [1] which blocks further
process of important header "x-wap-application-id" to be used to identify a MMS notification.

After comparing the implementation in AOSP, it seems that only the following top fields
 in WSP PDU will be decoded:
1. Transaction Id (1st octet)
2. PDU Type (2nd octet)
3. Header Len.
4. Content-Type
The fields in WSP Header are skipped except "x-wap-application-id". [2]
Then, dispatch the remained data to the one who is interested in it.

Need to dig more to see how to skip the un-supported WSP headers to make sure that MMS PDU can
still be processed in advance.

[1] http://hg.mozilla.org/mozilla-central/annotate/b40296602083/dom/mobilemessage/src/gonk/WspPduHelper.jsm#l2514
[2] http://androidxref.com/4.4_r1/xref/frameworks/opt/telephony/src/java/com/android/internal/telephony/WapPushOverSms.java#177
Assignee: nobody → btseng
Dear mozilla,
  our simlulat log is as follow:

I/Gecko   (  315): -*- SMSHELPER_QC_B2G: sendMessageToWapPushService
I/Gecko   (  315): -*- SMSHELPER_QC_B2G: sendMessageToWapPushService binary data ok
I/Gecko   (  315): -@- WspPduHelper: Parser expects ending in 115, but in 63
I/Gecko   (  315): -*- WapPushManager: options: {"bearer":3,"sourceAddress":"106581542701","sourcePort":9200,"destinationAddress":"","destinationPort":2948,"serviceId":0,"transactionId":214,"type":6,"headers":{"content-type":{"media":"application/vnd.wap.mms-message","params":null},"message-id":"v11113qvgjbv400"}}
I/Gecko   (  315): -*- WapPushManager: Push message doesn't contains X-Wap-Application-Id.
I/Gonk    (  315): Setting nice for pid 2538 to 1
I/Gonk    (  315): Changed nice for pid 2538 from 18 to 1.
I/Gecko   (  315): [Parent 315] WARNING: waitpid failed pid:2538 errno:10: file /local/v3.5428/gecko/ipc/chromium/src/base/process_util_posix.cc, line 254
D/SMS_QC_B2G(  315): Received solicited response for SMS_ACKNOWLEDGE, error 0
E/GeckoConsole( 2538): [JavaScript Error: "syntax error" {file: "app://wappush.gaiamobile.org/index.html" line: 1 column: 1 source: "[object Uint8Array]"}]


dose we support  :: application/vnd.wap.mms-message
Dear mozilla,
   We has add our simulate result, it is same to commit6.
   Hope your support to process the mms without "x-wap-application-id".
Flags: needinfo?(sync-1) → needinfo?(vchen)
blocking-b2g: --- → 1.3?
(In reply to buri.blff from comment #8)
> Dear mozilla,
>    We has add our simulate result, it is same to commit6.
>    Hope your support to process the mms without "x-wap-application-id".

Hi,

Since it is time-wasted to support the entire format of WSP PDU,
the action I'd like to take is to see if we are able to skip the unsupported headers to prevent
the parsing of WSP PDU broken and filter out the remained data as MMS PDU for further process.
However, I have to take some time to dig more comprehensively from WSP spec to 
figure out the possibility of this short-term solution.

Sorry for inconvenience.
Thanks for your help Bevis!

Hi Jack/GuoQiang -

As Bevis mentioned, it might take a while for him to find a proper solution for this bug sine he need to get familiar with WSP PDU first. So if you do need a solution for this bug in short time, I am wondering, if you have some engineers that are WSP PDU experts, maybe they can help to come out a patch as well, we are more than happy to review and discuss.

Thanks

Vance
Flags: needinfo?(vchen)
Flags: needinfo?(liuyongming)
Flags: needinfo?(Chenguoqiang)
Dear mozilla,
   this case will make our 克罗地亚 user can't receive MMS,  so we need to resolve this pr;
Hi Vance,

We are trying to find a quick solution from android project, but as you know, we do need mozilla help on MMS app code logic analysis, please keep investigating on your side.

Thanks.
Flags: needinfo?(liuyongming)
Flags: needinfo?(Chenguoqiang)
Since the |contentType| in |WSP PDU of Push and ConfirmedPush| is mandatory,
We can use |contentType| to identify the type of data in WSP PDU if |x-application-id| can not be parsed from WSPPduHelper due to the reason that breaks the parsing of unsupported WSP headers.
Attachment #8427556 - Flags: review?(vyang)
Hi,

I've uploaded a patch which correctly identifies the SMS PDUs as MMS Notification in comment 4.
Can you cherry pick this patch to see if the issue is fixed?

Thanks!
Flags: needinfo?(buri.blff)
Bevis, thanks for your help to come out a solution in such a short notice

Hi Jack -

Patch is available now, please give it a try and let us know the result, if still fails, please help to get the logs.

Thanks for your help

Vance
Flags: needinfo?(liuyongming)
Flags: needinfo?(Chenguoqiang)
Our modify:
let appid = options.headers["x-wap-application-id"];
    if (!appid) {
      // Assume message without applicatioin ID is WAP Push
      debug("Push message doesn't contains X-Wap-Application-Id.");
    }

    // MMS
    if (appid == "x-wap-application:mms.ua") {
      let mmsService = Cc["@mozilla.org/mms/rilmmsservice;1"]
                       .getService(Ci.nsIMmsService);
      mmsService.QueryInterface(Ci.nsIWapPushApplication)
                .receiveWapPush(data.array, data.array.length, data.offset, options);
      return;
    }
Flags: needinfo?(buri.blff)
sorry,


    var appid = null;
    if(options.headers){
        appid = options.headers["x-wap-application-id"];
    }
    if (!appid) {
      // Assume message without applicatioin ID is WAP Push
      debug("Push message doesn't contains X-Wap-Application-Id.");
      if(options.headers && (options.headers["content-type"].media == "application/vnd.wap.mms-message")){
          appid = "x-wap-application:mms.ua";
          options.headers["x-wap-application-id"] = "x-wap-application:mms.ua";
      }
    }
Hi Vance,

We have release daily build with our own modification to customer and will got feedback tomorrow hopefully.

Please kindly give us some advice on modification posted in comment#17.
Do you think we should release another build with your patch?

Thanks.
Flags: needinfo?(liuyongming)
Flags: needinfo?(Chenguoqiang)
(In reply to Jack Liu from comment #18)
> Hi Vance,
> 
> We have release daily build with our own modification to customer and will
> got feedback tomorrow hopefully.
> 
> Please kindly give us some advice on modification posted in comment#17.
> Do you think we should release another build with your patch?
> 
> Thanks.

Well TCL's patch is basically the same as Moz's, so I don't think you need to release another build with Moz's patch. Let's just keep our finger crossed for a pass test result~
I have tested with the patch, the issue reproduced with 2G network.MMS can be received and sent just under 3G network.
Whiteboard: p=3
Target Milestone: --- → 2.0 S3 (6june)
Vance - I'm assuming this is a cert blocker, right? Also, what SIMs is TCL able to reproduce this on? We've never seen this behavior in our testing.
Flags: needinfo?(vchen)
Yes this is a cert blocker, it can be reproduced with DT SIM card in Croatia. Our patch should work fine, TCL is testing the patch now, I will check later and ask Bevis to review/land if the patch can solve the problem
Flags: needinfo?(vchen)
blocking-b2g: 1.3? → 1.3+
Whiteboard: p=3 → p=3 [cert]
Comment on attachment 8427556 [details] [diff] [review]
Patch v1: Identify MMS PDU from either app-id or contentType. r=vyang

It is a 1.3 blocker and Vicamo is taking PTO. Could you please review this patch? Thanks.
Attachment #8427556 - Flags: review?(vyang) → review?(gene.lian)
Hi Gene,

Sorry to request your help to review this patch in a hurry because this is a 1.3 blocker and Vicamo is taking PTO.

Update patch v2 to dispatch all PUSH PDUs according to the mandatory field of "contentType":
1. the |x-wap-application-id| can be used to dispatch PDU to the registered client according to 7.3. Application Addressing in WAP-235-PushOTA-20010425-a.
http://technical.openmobilealliance.org/tech/affiliates/wap/wap-235-pushota-20010425-a.pdf
2. However, the support of WSPPduHelper is not complete to retrieve |x-wap-application-id| correctly from all kinds of Push PDUs.
3. To have to quick fix to identify MMS PDU without exception, we check the mandatory field of "contentType" in PUSH PDU instead of |x-wap-application-id|.
4. Leave the support to route the push request use x-wap-application-id as a future work when WspPduHelper is more solid to support parsing |x-wap-application-id|.

Regards,
Bevis Tseng
Attachment #8427556 - Attachment is obsolete: true
Attachment #8427556 - Flags: review?(gene.lian)
Attachment #8429841 - Flags: review?(gene.lian)
Update the partner test result: MMS can be received now with the patch

Thanks!
Hi Gene,

Sorry to request your help to review this patch in a hurry because this is a 1.3 blocker and Vicamo is taking PTO.

Update patch v2 to dispatch all PUSH PDUs according to the mandatory field of "contentType":
1. the |x-wap-application-id| can be used to dispatch PDU to the registered client according to 7.3. Application Addressing in WAP-235-PushOTA-20010425-a.
http://technical.openmobilealliance.org/tech/affiliates/wap/wap-235-pushota-20010425-a.pdf
2. However, the support of WSPPduHelper is not complete to retrieve |x-wap-application-id| correctly from all kinds of Push PDUs.
3. To have to quick fix to identify MMS PDU without exception, we check the mandatory field of "contentType" in PUSH PDU instead of |x-wap-application-id|.
4. Leave the support to route the push request using |x-wap-application-id| as a future work when WspPduHelper is more solid to support parsing |x-wap-application-id|.

Regards,
Bevis Tseng
Attachment #8429841 - Attachment is obsolete: true
Attachment #8429841 - Flags: review?(gene.lian)
Attachment #8429844 - Flags: review?(gene.lian)
Whiteboard: p=3 [cert] → [p=3] [cert]
Attachment #8429844 - Flags: review?(gene.lian) → review+
Comment on attachment 8429844 [details] [diff] [review]
Patch v2: Dispach WAP Push according to contentType which is the mandatory field in Push PDU. r=gene, a=1.3+

NOTE: This flag is now for security issues only. Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): NA
User impact if declined: Not able to receive MMS in Croatia. Not able to get certificate from Operator.
Testing completed: Y
Risk to taking this patch (and alternatives if risky): N
String or UUID changes made by this patch:N/A
Attachment #8429844 - Attachment description: Patch v2: Dispach WAP Push according to contentType which is the mandatory field in Push PDU. → Patch v2: Dispach WAP Push according to contentType which is the mandatory field in Push PDU. r=gene, a=1.3+
Attachment #8429844 - Flags: approval-mozilla-b2g28?
Attachment #8429844 - Flags: approval-mozilla-b2g28? → approval-mozilla-b2g28+
You need to log in before you can comment on or make changes to this bug.