999867 - [Sora]MMS receiving is not possible

Status: RESOLVED FIXED

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

Description

[sync-1]

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:

Comment 1

[sync-1]

Attachment: log

Comment 2

[Bevis Tseng[:bevis][:btseng](Exited)]

Attachment: enable_ril_mms_debug.sh

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

Comment 3

[Bevis Tseng[:bevis][:btseng](Exited)]

NI was cancelled due to summary changed.
NI again for the information in comment 2.

Comment 4

[buri.blff]

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??

Comment 5

[Bevis Tseng[:bevis][:btseng](Exited)]

(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.

Comment 6

[Bevis Tseng[:bevis][:btseng](Exited)]

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

Comment 7

[buri.blff]

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

Comment 8

[buri.blff]

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".

Comment 9

[Bevis Tseng[:bevis][:btseng](Exited)]

(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.

Comment 10

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

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

Comment 11

[buri.blff]

Dear mozilla,
   this case will make our 克罗地亚 user can't receive MMS,  so we need to resolve this pr;

Comment 12

[Jack Liu]

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.

Comment 13

[Bevis Tseng[:bevis][:btseng](Exited)]

Attachment: Patch v1: Identify MMS PDU from either app-id or contentType. r=vyang

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.

Comment 14

[Bevis Tseng[:bevis][:btseng](Exited)]

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!

Comment 15

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

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

Comment 16

[buri.blff]

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;
    }

Comment 17

[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";
      }
    }

Comment 18

[Jack Liu]

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.

Comment 19

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(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~

Comment 20

[liangxin]

I have tested with the patch, the issue reproduced with 2G network.MMS can be received and sent just under 3G network.

Comment 21

[Jason Smith [:jsmith]]

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.

Comment 22

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

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

Comment 23

[Ken Chang[:kenkai]]

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.

Comment 24

[Bevis Tseng[:bevis][:btseng](Exited)]

Attachment: Patch v2: Dispach WAP Push according to contentType which is the mandatory field in Push PDU.

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

Comment 25

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Update the partner test result: MMS can be received now with the patch

Thanks!

Comment 26

[Bevis Tseng[:bevis][:btseng](Exited)]

Attachment: Patch v2: Dispach WAP Push according to contentType which is the mandatory field in Push PDU. r=gene, a=1.3+

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

Comment 27

[Bevis Tseng[:bevis][:btseng](Exited)]

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

Comment 28

[Bevis Tseng[:bevis][:btseng](Exited)]

try server result:
1.3: https://tbpl.mozilla.org/?tree=Try&rev=27fe5d1c6a94
Master: https://tbpl.mozilla.org/?tree=Try&rev=81c95186fdc2

Comment 29

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/36213c0d72b5

Comment 30

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/36213c0d72b5

Comment 31

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/c3ad25a4a1f4

Comment 32

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/327d20c442b1