Closed Bug 962142 Opened 11 years ago Closed 11 years ago

[B2G][Messages] Sending MMS takes extremely long time, up to 20 min

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(blocking-b2g:1.3+, firefox28 affected)

Status:
RESOLVED WORKSFORME
Milestone:
1.3 C3/1.4 S3(31jan)
Project Flags:
blocking-b2g 1.3+
Tracking Flags:
Tracking Status
firefox28 --- affected

People

(Reporter: nkot, Unassigned)

References

Details

(Keywords: perf, regression, Whiteboard: [c=progress p= s= u=1.3])

Attachments

(1 file)

logcat_mms_debug_enabled
584.23 KB, text/plain
Details
Description: It takes extremely long to send MMS, sometimes up to 20 min. It's not failing though, no error notification, keeps spinning and then eventually gets delivered. Repro Steps: 1) Updated Buri to BuildID: 20140121040201 2) Open Messages app 3) Create new MMS (use camera or gallery attachment) 4) Hit "Send" button Actual: The message is spinning for about 10 min, then eventually sends out Expected: The MMS sends out reasonably fast, with no delays Environmental Variables: Device: Buri v1.4 Master build, Mozilla RIL BuildID: 20140121040201 Gaia: e218d17ae7d01a81d48f833cd6fafb4e11b26cd8 Gecko: cdc0ab2c0cba Version: 29.0a1 Firmware Version: v1.2-device.cfg Notes: - using AT&T SIMs - reproduces also on v1.3 - can receive MMS, also with some delays, up to 2-3 min Repro frequency: 100% See attached logcat with debug_mms enabled
status-firefox28: --- → affected
The reproduction rate is intermittent, but we have managed to reproduce this a few times. Something really broke in the RIL layer here.
blocking-b2g: --- → 1.3?
Component: Gaia::SMS → RIL
Keywords: perf, regression
Severity: normal → critical
Keywords: smoketest
Severity: critical → normal
blocking-b2g: 1.3? → ---
Component: RIL → Gaia::SMS
Severity: normal → critical
blocking-b2g: --- → 1.3?
Component: Gaia::SMS → RIL
Hi, It seems not a regression issue but more likely to be something wrong in the network side after further analysis from the attached log. From the log. 1. There is a MMS to be retrived prior to the MMS to be sent and the MMS is sent after retrieving the MMS from network. (See line#2, line#3, line#1335) 2. However, the first try of sending MMS is failed with a strange HTTP response status (0) instead of 200 (OK). (See line#1337, #2589) 3. This cause the MMS to setup a 5 minute-timer to next retry. (See line#2590) 4. The MMS was sent successfully after next retry. (See line#3603, 4764) -- 01-21 09:27:38.969: I/Gecko(134): -@- MmsService: retrievedMessage = {"headers":{"x-mms-message-type":132,"x-mms-transaction-id":"E90121172435700027000130000","x-mms-mms-version":16,"to":{"address":"+16509336965","type":"PLMN"},"from":{"address":"+12069205887","type":"PLMN"},"message-id":"012117243570002700013","date":"2014-01-21T17:24:35.000Z","x-mms-delivery-report":false,"content-type":{"media":"application/vnd.wap.multipart.related","params":{"type":"application/smil","start":"0.smil"}}},"type":132,"parts":[{"index":0,"headers":{"content-type":{"media":"application/smil","params":null},"content-length":300,"content-id":"0.smil"},"content":"<smil>\n<head>\n<layout>\n <root-layout/>\n<region id=\"Text\" top=\"70%\" left=\"0%\" height=\"30%\" width=\"100%\" fit=\"scroll\"/>\n<region id=\"Image\" top=\"0%\" left=\"0%\" height=\"70%\" width=\"100%\" fit=\"meet\"/>\n</layout>\n</head>\n<body>\n<par dur=\"10s\">\n<img src=\"IMG_7422.jpg\" region=\"Image\"/>\n</par>\n</body>\n</smil>\n"} 01-21 09:27:39.259: I/Gecko(134): -@- MmsService: Broadcasting the MMS system message: sms-received 01-21 09:29:06.189: I/Gecko(134): -@- MmsService: acquire: buffer the MMS request and setup the MMS data call. 01-21 09:29:14.659: I/Gecko(134): -@- MmsService: Got the MMS network connected! Resend the buffered MMS requests: number: 1 01-21 09:29:14.659: I/Gecko(134): -@- MmsService: sendRequest: register proxy filter to http://mmsc.mobile.att.net 01-21 09:30:44.779: I/Gecko(134): -@- MmsService: xhr done, but status = 0, statusText = 01-21 09:30:44.789: I/Gecko(134): -@- MmsService: Fail to send. Will retry after: 300000 01-21 09:35:35.749: I/Gecko(134): -@- MmsService: send: aParams: {} 01-21 09:35:49.079: I/Gecko(134): -@- MmsService: sendRequest: register proxy filter to http://mmsc.mobile.att.net 01-21 09:35:54.979: I/Gecko(134): -@- MmsService: xhr success, response headers: Content-Type: application/vnd.wap.mms-message 01-21 09:35:55.089: I/Gecko(134): -@- MmsService: Sending MMS succeeded. 01-21 09:35:55.089: I/Gecko(134): -@- MmsService: Broadcasting the MMS system message: sms-sent
Keywords: regression
What network was this bug reproduced on? Internal wifi? A specific data plan?
blocking-b2g: 1.3? → ---
Flags: needinfo?(nkot)
Keywords: smoketest
I had WiFi (WPA2) and Cell(H) enabled when the issue reproduced. And apparently it's our WiFi messing up here. When I disabled WiFi and sent MMS using Cell only it went immediately, when I enabled WiFi back then I hit the issue again. Using same WiFi and AT&T SIM on my personal phone and can send MMS without any issues.
Flags: needinfo?(nkot)
Can you check if this reproduces on 1.1? That will isolate whether this is wifi network problem vs. a problem in FxOS.
Flags: needinfo?(nkot)
(In reply to Jason Smith [:jsmith] from comment #5) > Can you check if this reproduces on 1.1? That will isolate whether this is > wifi network problem vs. a problem in FxOS. No, it does not reproduce on v1.1. Have tested two devices at the same time, one flashed to v1.1, the other to v1.4. On V1.1 - MMS was sent immediately, on 1.4 - spinning forever. Device: Buri v1.1 Mozilla RIL BuildID: 20140122041202 Gaia: 6ff3a607f873320d00cb036fa76117f6fadd010f Gecko: e7a8e7b9b7d2 Version: 18.0
Flags: needinfo?(nkot)
Okay - that disproves the analysis in comment 2 then. Let's get a regression window here.
Keywords: regression, regressionwindow-wanted, smoketest
blocking-b2g: --- → 1.3?
QA Contact: mvaughan
This issue appears to have started reproducing on the 01/18/14 1.3 build. - Works - Device: Buri v1.3 MOZ RIL BuildID: 20140117004005 Gaia: a81ccdc53e45a6adeaae423e104e91bcc1e12b0e Gecko: 2c033140eff4 Version: 28.0a2 Firmware Version: V1.2-device.cfg - Broken - Device: Buri v1.3 MOZ RIL BuildID: 20140118004001 Gaia: 50d6487d4d15efda942c934570e6fdfb91f6fe2e Gecko: 9561abd10c52 Version: 28.0a2 Firmware Version: V1.2-device.cfg
Keywords: regressionwindow-wanted
The gecko push log doesn't really help here - I'm not seeing anything that looks obvious for causing this. The gaia commit log doesn't really help either. What I do know however is that this isn't a RIL bug, as there are no RIL commits within the regression range.
The only light hunch I've got for causing this is: https://github.com/mozilla-b2g/gaia/commit/50d6487d4d15efda942c934570e6fdfb91f6fe2e But I'm not entirely sure. Kaze - What do you think? I'm out of ideas on what could cause a regression like this.
Component: RIL → General
Flags: needinfo?(kaze)
blocking-b2g: 1.3? → 1.3+
Priority: -- → P1
Whiteboard: [c=progress p= s= u=1.3]
José Antonio might know better.
Flags: needinfo?(josea.olivera)
(In reply to Julien Wajsberg [:julienw] from comment #14) > José Antonio might know better. If this is caused by a change in the APNs for MMS I would need to know the MCC and MNC codes in the SIM to check whether the APN for MMS has really changed. Natalya, could you provide the MCC and MNC codes in the SIM please? Thanks!
Flags: needinfo?(josea.olivera) → needinfo?(nkot)
Flags: needinfo?(kaze)
Hi José, we are using AT&T SIMs here, the MCC code - 310, MNC - 410.
Flags: needinfo?(nkot)
Thanks Natalya, the APNs for MMS have changed. HEAD https://github.com/mozilla-b2g/gaia/blob/master/shared/resources/apn.json#L1107-L1110 Before bug 947946 https://github.com/mozilla-b2g/gaia/blob/53e8c3e2f5facbc5b72056c9a8deb0b969e27d8f/shared/resources/apn.json#L911-L913 Before bug 947946 there was only one APN, now there are a couple of them. This change comes somehow from AOSP since we use its APN database so It should work in any case. I suggest to try to send the message with each APN. I guess ATT could provide some info to check which is the valid one.
Component: General → Gaia
I've tested with different Data/Messages Settings and it looks like this bug occurs only with default Settings. Default Settings is "ATT Phone" (Settings--> Cell&Data--> check on Data Settings and Message Settings). When change the settings to "ATT WAP" and restart device the bug won't reproduce.
Blocks: 947946
The issue no longer reproduces on today's Master and 1.3 builds, the MMS goes through successfully with no delays with different Data/Settings configurations and with both Cell&WiFi as well as Cell only. I think we can resolve as works for me for now, will reopen the bug if reoccurs. v1.3 BuildID: 20140128004000 Gaia: 3c5119507a985c59cfc264ed23821679b138486d Gecko: 4936f09590a0 Version: 28.0a2 Master BuildID: 20140128040224 Gaia: 6586d2b8b43c6997be5cf5895bbdf3dd20490725 Gecko: 4da3e21a0e5f Version: 29.0a1
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Target Milestone: --- → 1.3 C3/1.4 S3(31jan)
The issue is still happening sometimes so I have to reopen this bug. Please note, usually it is the first sending MMS that gets delayed, so if I don't wait and just send another MMS they both will be sent right away. I also hit bug 949780 while trying to repro my issue, possible these two are related. Removing smoketest keyword, the issue now has less than 50% repro rate.
Status: RESOLVED → REOPENED
Keywords: smoketest
Resolution: WORKSFORME → ---
Please file a new bug for the issue you've hit.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: