Closed
Bug 799584
Opened 12 years ago
Closed 11 years ago
B2G MMS: MMSes with picture/video attachments not received
Categories
(Firefox OS Graveyard :: Gaia::SMS, defect)
Tracking
(blocking-basecamp:-)
RESOLVED
DUPLICATE
of bug 744684
blocking-basecamp | - |
People
(Reporter: jhammink, Unassigned)
References
Details
## Environment : Otoro phone, build 2012-10-05 us Taken from default.xml in b2g-distro: * "platform_build" revision= "0d6d050bc37d3167cc82a1885fd7660456bb0f4e" * "gaia" revision= "5f7dbe06490e6b52a356e033f52fb31c0fa0e2d0" * "releases-mozilla-central" revision= "ddc8eeb3f9b9ee04d9f74b4f60522eb4530a4a6f" * "gonk-misc" revision= "bac8185ab931c9bc868e9bcb9b636620b8032e5e" ## Repro : 1. From another phone, send an MMS, with picture or video attached, to an Otoro running B2G 2. Verify that MMS is received on Otoro, picture/video can be viewed, etc. 3. As a control measure, send a regular SMS (no attachments) also from another phone, to Otoro, to ensure that SMS in fact works. ## Expected : MMS is received on Otoro, picture/video can be viewed along with MMS text; SMS also can be received, viewed. ## Actual : MMS is never received. SMS is received.
Reporter | ||
Updated•12 years ago
|
Summary: MMSes (with picture/video attachments not rec'd) → MMSes with picture/video attachments not rec'd
Reporter | ||
Comment 1•12 years ago
|
||
I can reproduce this on today's daily: 10/9/2012 Taken from default.xml in b2g-distro: * "platform_build" revision= "0d6d050bc37d3167cc82a1885fd7660456bb0f4e" * "gaia" revision= "5f7dbe06490e6b52a356e033f52fb31c0fa0e2d0" * "releases-mozilla-central" revision= "1f41d3603a035d64c3b1d7c16dba5fd1ce322957" * "gonk-misc" revision= "bac8185ab931c9bc868e9bcb9b636620b8032e5e"
Comment 2•12 years ago
|
||
Drivers: Should we at least show that a message was sent, and/or at least show the text content in the message? John, what's up with the blocking bug - mistake?
blocking-basecamp: --- → ?
Comment 4•12 years ago
|
||
+clee Chris, can you confirm what is the expectation if we receive an MMS for v1? Is it OK to simply do nothing, or should we try to extract the text part of the message or something else?
Comment 5•12 years ago
|
||
One other option - is there anything we can do notify the carrier that we aren't able to receive an MMS so that the sender gets an error message? That would prevent us from needing to come up with new UX for this.
Comment 6•12 years ago
|
||
(In reply to Alex Keybl [:akeybl] from comment #5) > One other option - is there anything we can do notify the carrier that we > aren't able to receive an MMS so that the sender gets an error message? That > would prevent us from needing to come up with new UX for this. Actually, that might be impossible. Carriers can have they own web based MMS receiving/reading services. They want everyone sends MMS no matter the receiver(s) is capable of receiving/reading MMS or not. If it happens that your device just can't receive a MMS message, they send a SMS notification to you, with "Please go to http://somewhere/to/read/mms".
Comment 7•12 years ago
|
||
> Chris, can you confirm what is the expectation if we receive an MMS for v1? We should reach out to the Operator and work with them to manage the error messaging here. There should be existing behavior for devices that do not support MMS today. I will follow-up. > > Is it OK to simply do nothing, or should we try to extract the text part of > the message or something else? I think we should fail, but inform the sender of the failure. Josh, additional thoughts here?
Comment 8•12 years ago
|
||
(In reply to Chris Lee [:clee] from comment #7) > > Chris, can you confirm what is the expectation if we receive an MMS for v1? > > We should reach out to the Operator and work with them to manage the error > messaging here. There should be existing behavior for devices that do not > support MMS today. I will follow-up. Here are the typical steps of MMS message retrieval transaction[1]: 1. the sender sends the encoded M-Send.Ind PDU to MMSC through http; 2. MMSC notifies receiver via a binary WAP Push message embedded in a binary encoded SMS message. The SMSC field is, of course, set to SMSC, not MMSC. 3. the receiver sends a http request to MMSC with the decoded content location. Nothing more, nothing less. 4. MMSC replies with a M-Retreive.conf PDU via HTTP POST; 5. the receiver sends a M-NotifyResp.ind PDU back to MMSC as a response via HTTP POST. This time, with an extra mandatory field X-MMS-Status[2]. So, how does a device, which doesn't support MMS, tell MMSC that it's capability? Actually, no way! You don't send a SMS back to SMSC after step 2. SMSC won't parse that SMS message and relay it the MMSC. Never! We can already fetch that MMS message, the missing parts are DOM API and GUI. You can go to %ProfD%/mms and find those fetched messages. We can reply a "Unrecognized" status back in step 5 for now, but note that we have already successfully fetched the message, and according to the specification, we should reply "Retrieved" as we do now. > > > > Is it OK to simply do nothing, or should we try to extract the text part of > > the message or something else? > > I think we should fail, but inform the sender of the failure. Please see my comment #6. Inform the sender is actually quite meaningless. Carriers can host their own web based services. So, how do you define a "successful" send? For carriers, you've already made the send transaction, and the message has been stored online. They won't provide you any chance to make a refound request no matter the receivers of that message are capable of receiving it or not. [1]: "Multimedia Messaging Service Client Transactions" http://www.openmobilealliance.org/technical/release_program/docs/CopyrightClick.aspx?pck=MMS&file=V1_3-20110913-A/OMA-TS-MMS_CTR-V1_3-20110913-A.pdf [2]: "Multimedia Messaging Service Encapsulation Protocol" http://www.openmobilealliance.org/technical/release_program/docs/CopyrightClick.aspx?pck=MMS&file=V1_3-20110913-A/OMA-TS-MMS_ENC-V1_3-20110913-A.pdf
Comment 9•12 years ago
|
||
(In reply to Vicamo Yang [:vicamo][:vyang] from comment #8) > (In reply to Chris Lee [:clee] from comment #7) > > I think we should fail, but inform the sender of the failure. > > Please see my comment #6. Inform the sender is actually quite meaningless. > Carriers can host their own web based services. So, how do you define a > "successful" send? For carriers, you've already made the send transaction, > and the message has been stored online. They won't provide you any chance to > make a refound request no matter the receivers of that message are capable > of receiving it or not. The X-Mms-Status field carried in M-NotifyResp.ind PDU means the same with SMS-DELIVERY-REPORT PDU for SMS. It indicates the status of message delivery. So, like SMS, the delivery status is *NOT* always available. The delivery status can be turned off at receiver's will. Besides, it's an optional feature in both SMS and MMS. Not every carrier supports it. We had this problem for SMS in Brazil (bug 786782).
Comment 10•12 years ago
|
||
At this point, we're not going to block on a silent failure. this is not ideal, but we're not going to hold the release on handling an unsupported message type.
blocking-basecamp: ? → -
Updated•12 years ago
|
No longer blocks: b2g-mms
Depends on: b2g-mms-dom-api
Updated•12 years ago
|
Component: Gaia → Gaia::SMS
Updated•12 years ago
|
Summary: B2G MMS: MMSes with picture/video attachments not rec'd → B2G MMS: MMSes with picture/video attachments not received
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•