Closed
Bug 1060702
Opened 11 years ago
Closed 11 years ago
[SMS] MMS messages received on roaming sim continuiously download message
Categories
(Firefox OS Graveyard :: RIL, defect)
Tracking
(b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.1 affected)
RESOLVED
INVALID
People
(Reporter: jdegeus, Unassigned)
References
()
Details
(Whiteboard: [2.1-flame-test-run-1])
Attachments
(6 files)
Description:
When users are using a international roaming sim card to receive a MMS, the users will receive the MMS however the message will continiously sit on downloading message. If the user receives a message with a subject/title, users will see the title/subject displayed, however the message just continously download.
Setup:
Have 2 devices, 1 device with a US based sim and 1 device with a international sim such as a Taiwan based sim
Device 1: Taiwan based sim
Device 2: US Based sim
Repro Steps:
1) Update a Flame to 20140828040204
2) Device 1: With International Sim enter Settings
a) Select Messaging Settings> Set Auto Retrieve to "On with roaming"
b) Select Back> Cellular & Data> Sim 1> Data Roaming enabled
a) To send out of the USA to the Taiwan based sim enter +8669(XXX)-XXXXX
3) Device 2: Select Messages> New Message> Attach a image or add a subject
4) Device 1: Observe MMS is received but continiously sits on downloading MMS
Actual:
MMS messages received on roaming sim continiously download message
Expected:
MMS messages download successfully
Environmental Variables:
Device: Flame Master (319mb)
Build ID: 20140828040204
Gaia: 3a838afca295c9db32e1a3ec76d49fb7fe7fd2d2
Gecko: 3be45b58fc47
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Repro frequency: 3/3
Link to failed test case: https://moztrap.mozilla.org/manage/case/8258/
See attached: Logcat and youtube attached
Reporter | ||
Comment 1•11 years ago
|
||
This issue DOES OCCUR on Open C 2.0, Open C 1.4, Flame 2.1 (512mb), Flame 2.0 (319mb), Flame 1.4 (319mb)
Actual: MMS continously sits on downloading message
Flame 2.1
Environmental Variables:
Device: Flame Master (512mb)
Build ID: 20140829040202
Gaia: 007f3c50cf69f044628a23c2376c6d88aa45f617
Gecko: d697d649c765
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Flame 2.0
Environmental Variables:
Device: Flame 2.0 (319mb)
BuildID: 20140829000203
Gaia: 5bf3b8cdea15e62ce7bf77a15085a18e24e33c44
Gecko: 5bcf98ed9885
Version: 32.0 (2.0)
Firmware: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flame 1.4
Environmental Variables:
Device: Flame 1.4 (319mb)
Build ID: 20140829063010
Gaia: d6a1e9366dfcf9dd3d84661338996cb36b9a7e00
Gecko: 6de69ed3c146
Version: 30.0 (1.4)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
Open C 2.0
Environmental Variables:
Device: Open_C 2.0
BuildID: 20140829000203
Gaia: 5bf3b8cdea15e62ce7bf77a15085a18e24e33c44
Gecko: 5bcf98ed9885
Version: 32.0 (2.0)
Firmware: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Open C 1.4
Environmental Variables:
Device: Open_C 1.4
BuildID: 20140829063010
Gaia: d6a1e9366dfcf9dd3d84661338996cb36b9a7e00
Gecko: 6de69ed3c146
Version: 30.0 (1.4)
Firmware: P821A10v1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
----------------------------------------------------------------
Open 2.1 devices never received MMS messages therefore i am unsure if this issue occurs on Open C 2.1
Open C 2.1
Environmental Variables:
Device: Open_C Master
Build ID: 20140829040202
Gaia: 007f3c50cf69f044628a23c2376c6d88aa45f617
Gecko: d697d649c765
Version: 34.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Flags: needinfo?(ktucker)
Reporter | ||
Updated•11 years ago
|
QA Whiteboard: [QAnalyst-Triage?]
Comment 2•11 years ago
|
||
Set NI
1 to clarify if its a regression to bug 1057973. Where MMS is not able to download if APN is shared for both internet and MMS.
2. It seems that the debug flag was not enabled during capturing the log. Can we have logcat & tcpdump again with the steps in the following link:
https://github.com/bevis-tseng/Debug_Tools
Thanks!
Component: Gaia::SMS → RIL
Reporter | ||
Comment 3•11 years ago
|
||
Reporter | ||
Comment 4•11 years ago
|
||
Reporter | ||
Comment 5•11 years ago
|
||
Attached new logcat & tcpdump.
Forgot to attach a youtube video of the issue: http://youtu.be/xGOufhUjMKE
status-b2g-v2.0:
--- → affected
Comment 6•11 years ago
|
||
Thanks for capturing the log.
After checking the error cause of setting up data call we got an error "ServiceOptionNotSubscribedError".
It seems that the test SIM didn't subscribe a data call plan.
Can we double confirm this?
If yes, it will be nice to have this check as part of the pre-condition in this test case. :)
Thanks!
Comment 7•11 years ago
|
||
I'm pretty sure the roaming SIM had an active data calling plan when this issue was written up but I will let the reporter double check this. Please check this Jordan.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage-]
Flags: needinfo?(ktucker) → needinfo?(jdegeus)
Comment 8•11 years ago
|
||
We can also checking this with other reference phone with the same test SIM if needed. :)
Comment 9•11 years ago
|
||
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #8)
> We can also checking this with other reference phone with the same test SIM
> if needed. :)
In addition, the MMS of this test SIM goes with different APN named "emome" than default data "internet".
So the condition might be different if you have default data plan but not the MMS data plan.
Reporter | ||
Comment 10•11 years ago
|
||
I have been able to browse the web on 3G while WiFi was disabled however I still am unable to send/receive MMS's on multiple devices.
Here are the following settings for both Data and MMS:
Data:
APN: internet
Identifier: [blank]
Password: [blank]
HTTP proxy host: [blank]
HTTP proxy port: [blank]
MMS proxy: [blank]
MMS port: [blank]
MMSC: [blank]
Authentication: [Not defined]
APN Type: default
Protocol: Not defined
Roaming protocol: Not defined
MMS Settings:
APN: emome
Identifier: [blank]
Password: [blank]
HTTP proxy host: [blank]
HTTP proxy port: [blank]
MMS proxy: 10.1.1.1
MMS port: 8080
MMSC: http://mms.emome.net:8002
Authentication: Not defined
APN Type: mms
Protocol: Not defined
Roaming protocol: Not defined
Reporter | ||
Comment 11•11 years ago
|
||
Reporter | ||
Comment 12•11 years ago
|
||
Attached are new logcats, threadtime logcats and a new TCP dump
Flags: needinfo?(jdegeus) → needinfo?(ktucker)
Reporter | ||
Updated•11 years ago
|
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
Reporter | ||
Comment 13•11 years ago
|
||
I repro'd this issue using 2 different Flame 2.1 (319mb) as well as a Open C 2.1
Flame 2.1
Environmental Variables:
Device: Flame 2.1
BuildID: 20140910000202 (319mb)
Gaia: 79dc972d637ff5ef7667b231e93118b4ed83ba9c
Gecko: 0890010015a2
Version: 34.0a2 (2.1)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Open C 2.1
Environmental Variables:
Device: Open_C 2.1
BuildID: 20140910000202
Gaia: 79dc972d637ff5ef7667b231e93118b4ed83ba9c
Gecko: 0890010015a2
Version: 34.0a2 (2.1)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Comment 14•11 years ago
|
||
Can you look into this Linear? Do have a MMS plan on our Emome's SIM with the phone number +886978725132?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(nli)
Updated•11 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Comment 15•11 years ago
|
||
Hello,
Just confirm with carrier provider, as long as the data plan is active, it should be able to send/receive MMS without specific setting.
Since we have active data plan already, no MMS plan needed actually.
Thanks.
Flags: needinfo?(nli)
Comment 16•11 years ago
|
||
From the latest attached logs in comment 11 & 12, I still saw the same error "ServiceOptionNotSubscribedError" while setting up "emome" data connection.
Can we test MMS with the same test SIM on other Android/iPhone devices to see if the same symptom happened?
Keywords: qawanted
Updated•11 years ago
|
Flags: needinfo?(jdegeus)
Reporter | ||
Comment 17•11 years ago
|
||
Retesting this issue on a Android device, i was unable to send MMS messages. I was able to send SMS messages without issues.
Is this potentially an issue with our Roaming Sim?
Flags: needinfo?(jdegeus)
Comment 18•11 years ago
|
||
Hello,
Contact with carrier and they reply that if the SIM card can send SMS and also be able to connect to Internet, then it should be able to send MMS messages without any configuration.
Comment 19•11 years ago
|
||
(In reply to Linear Li [:nli][moco-tw] from comment #18)
> Hello,
>
> Contact with carrier and they reply that if the SIM card can send SMS and
> also be able to connect to Internet, then it should be able to send MMS
> messages without any configuration.
Hi Linear,
By my understanding, for CHT SIM, internet & mms are using different APN settings,
where internet applies "internet" APN and MMS applies "emome" APN.
Sorry, no offense.
I was wondering if carrier provides correct information for this subscriber,
because, from the radio response from the modem in comment 16, we were told that this SIM was not subscribed for emome APN connection and we met the same problem on other reference device as well. :(
Comment 20•11 years ago
|
||
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #19)
> (In reply to Linear Li [:nli][moco-tw] from comment #18)
> > Hello,
> >
> > Contact with carrier and they reply that if the SIM card can send SMS and
> > also be able to connect to Internet, then it should be able to send MMS
> > messages without any configuration.
>
> Hi Linear,
>
> By my understanding, for CHT SIM, internet & mms are using different APN
> settings,
> where internet applies "internet" APN and MMS applies "emome" APN.
>
> Sorry, no offense.
> I was wondering if carrier provides correct information for this subscriber,
> because, from the radio response from the modem in comment 16, we were told
> that this SIM was not subscribed for emome APN connection and we met the
> same problem on other reference device as well. :(
Hi All,
Just double confirmed with Linear & the Customer Service of CHT, the emome
service was not able to be subscribed for this test SIM because it applied
a mutually exclusive internet data plan.
We'll try to choose a different plan to enable emome and allow MMS service
to be used on this test SIM. :)
Comment 21•11 years ago
|
||
Thanks Bevis for helping to figure out the root cause!
I've applied an new voice plan that could make emome service enable, but sadly the new plan wouldn't be active till 1th Oct CST according to CHT policy.
Please give it a try till then.
Sorry that you have to wait one more week. :(
Thank you for all your patience.
Comment 22•11 years ago
|
||
Hello,
Sorry for late. It should work now.
Could you please give it a try and let me know how it goes?
Thank you. :)
Flags: needinfo?(jdegeus)
Updated•11 years ago
|
QA Contact: aalldredge
Comment 23•11 years ago
|
||
I was unable to reproduce this issue on 2.0 Flame, 2.1 Flame, or 2.2 Flame.
Environmental Variables:
Device: Flame 2.2 Master
BuildID: 20141022133013
Gaia: 27a1d1baaa8e375b70e043efee67d5f2206c330b
Gecko: 7e2fb51abd4b
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
Device: Flame 2.1
BuildID: 20141022081833
Gaia: 734d3547fb6c65e8bc4dd1a52b26f70bdfee7474
Gecko: 9646e94a041c
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Device: Flame 2.0
BuildID: 20141022081832
Gaia: ec722129a962704fda0dd5f39e7efd01261ae946
Gecko: 52280df0e39f
Version: 32.0 (2.0)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Result:
The MMS messages were downloaded automatically, and completed downloading.
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(jdegeus) → needinfo?(jmitchell)
Keywords: qawanted
Comment 24•11 years ago
|
||
All branches were shallow flashed in previous comment.
Comment 25•11 years ago
|
||
So now it's working :)
Hey Bevis, just want to understand if this error state is something we could detect and report to the user?
Flags: needinfo?(btseng)
Comment 26•11 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #25)
> So now it's working :)
>
> Hey Bevis, just want to understand if this error state is something we could
> detect and report to the user?
Sorry to say no for now by current design. :-(
We have file a bug 904514 to enhance the network management.
In which more information about the connection status and the reason why we are not able to established the connection will report to the caller and then, in that case, we could provide more precise information to the user about this.
Flags: needinfo?(btseng)
Comment 27•11 years ago
|
||
Filed Bug 1087898 about this.
Closing this bug then.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Updated•11 years ago
|
Flags: needinfo?(jmitchell)
Updated•11 years ago
|
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
You need to log in
before you can comment on or make changes to this bug.
Description
•