Closed
Bug 999867
Opened 7 years ago
Closed 7 years ago
[Sora]MMS receiving is not possible
Categories
(Firefox OS Graveyard :: RIL, defect, P1)
Firefox OS Graveyard
RIL
Tracking
(blocking-b2g:1.3+, 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)
3.88 MB,
application/zip
|
Details | |
291 bytes,
application/x-shellscript
|
Details | |
3.47 KB,
patch
|
airpingu
:
review+
bajaj
:
approval-mozilla-b2g28+
|
Details | Diff | Splinter Review |
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:
Updated•7 years ago
|
Attachment #8410714 -
Attachment mime type: application/octet-stream → application/zip
Assignee | ||
Comment 2•7 years ago
|
||
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)
Assignee | ||
Updated•7 years ago
|
Component: Gaia::SMS → RIL
Flags: needinfo?(sync-1)
Summary: [Sora][HOMO][TMO 56842 ]MMS receiving is not possible → [Sora]MMS receiving is not possible
Assignee | ||
Comment 3•7 years ago
|
||
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??
Assignee | ||
Comment 5•7 years ago
|
||
(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.
Assignee | ||
Comment 6•7 years ago
|
||
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 | ||
Updated•7 years ago
|
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)
Assignee | ||
Comment 9•7 years ago
|
||
(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)
Comment 11•7 years ago
|
||
Dear mozilla, this case will make our 克罗地亚 user can't receive MMS, so we need to resolve this pr;
Comment 12•7 years ago
|
||
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)
Assignee | ||
Comment 13•7 years ago
|
||
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)
Assignee | ||
Comment 14•7 years ago
|
||
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)
Comment 16•7 years ago
|
||
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)
Comment 17•7 years ago
|
||
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•7 years ago
|
||
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~
Comment 20•7 years ago
|
||
I have tested with the patch, the issue reproduced with 2G network.MMS can be received and sent just under 3G network.
Assignee | ||
Updated•7 years ago
|
Whiteboard: p=3
Target Milestone: --- → 2.0 S3 (6june)
Comment 21•7 years ago
|
||
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)
Updated•7 years ago
|
blocking-b2g: 1.3? → 1.3+
Whiteboard: p=3 → p=3 [cert]
Comment 23•7 years ago
|
||
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)
Assignee | ||
Comment 24•7 years ago
|
||
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!
Assignee | ||
Comment 26•7 years ago
|
||
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)
Assignee | ||
Updated•7 years ago
|
Whiteboard: p=3 [cert] → [p=3] [cert]
Updated•7 years ago
|
Attachment #8429844 -
Flags: review?(gene.lian) → review+
Assignee | ||
Updated•7 years ago
|
status-b2g-v1.3:
--- → affected
status-b2g-v1.3T:
--- → affected
status-b2g-v1.4:
--- → affected
status-b2g-v2.0:
--- → affected
Assignee | ||
Comment 27•7 years ago
|
||
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?
Assignee | ||
Comment 28•7 years ago
|
||
try server result: 1.3: https://tbpl.mozilla.org/?tree=Try&rev=27fe5d1c6a94 Master: https://tbpl.mozilla.org/?tree=Try&rev=81c95186fdc2
Keywords: checkin-needed
Comment 29•7 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/36213c0d72b5
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/36213c0d72b5
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Attachment #8429844 -
Flags: approval-mozilla-b2g28? → approval-mozilla-b2g28+
Updated•7 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•