799584 - B2G MMS: MMSes with picture/video attachments not received

Status: RESOLVED DUPLICATE of bug 744684

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

Description

[John Hammink]

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

Comment 1

[John Hammink]

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

[Dietrich Ayala (:dietrich)]

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?

Comment 3

[Vicamo Yang [:vicamo][:vyang]]

MMS is not a v1 feature.

Comment 4

[Ben Francis [:benfrancis]]

+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

[Alex Keybl [:akeybl]]

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

[Vicamo Yang [:vicamo][:vyang]]

(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

[Chris Lee [:clee]]

> 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

[Vicamo Yang [:vicamo][:vyang]]

(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

[Vicamo Yang [:vicamo][:vyang]]

(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

[Mike Connor [:mconnor]]

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.