Closed Bug 890167 Opened 11 years ago Closed 10 years ago

[MMS] After receiving a MMS, ACK message is not sent to MMSC if MMSC url setting is wrong

Categories

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

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

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
1.1 QE4 (15jul)

People

(Reporter: leo.bugzilla.gaia, Assigned: bevis)

References

Details

(Whiteboard: [TD-56817], [u=commsapps-user c=messaging p=0], [comms-triaged]) 

1. Title: After receiving a MMS, ACK message is not sent to MMSC if MMSC url setting is wrong
2. Precondition: Able to send and receive an MMS messages
3. Tester's Action:  User modifies the MMSC url setting in DUT messaging menu. 
           (1) User sets in MMSC url  ""http://"". A MMS is sent to DUT.  
           (2) User sets in MMSC url ""h"". A MMS is sent to DUT
4. Detailed Symptom (ENG.) : (1) MMS is received and displayed to user, but no ACK is sent to MMSC. ""MMSE m-notifyresp-ind"" message is not sent. 
(2) MMS is not even displayed to user
5. Expected: Altough the MMSC url format is wrong, MMS should be received and displayed to user and an ACK sent back to MMSC
6. Reproducibility: Y
1) Frequency Rate : 100%
7. Gaia Master/v1-train: Reproduced on v1-train
8. Gaia Revision: f2d6ed54a236e6e3b94f0abad9f0dacb8a1cc7b3
9. Personal email id: sasikala.paruchuri8@gmail.com
(In reply to Leo from comment #0)
> 5. Expected: Altough the MMSC url format is wrong, MMS should be received
> and displayed to user and an ACK sent back to MMSC

How?
blocking-b2g: --- → leo+
Priority: -- → P1
Whiteboard: [TD-56817]
Target Milestone: --- → 1.1 QE4 (15jul)
Re-open if you have a valid scenario for this bug.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
(In reply to Vicamo Yang [:vicamo][:vyang] from comment #1)
> (In reply to Leo from comment #0)
> > 5. Expected: Altough the MMSC url format is wrong, MMS should be received
> > and displayed to user and an ACK sent back to MMSC
> 
> How?
I guess you can use the notification URL for sending back the ACK. When user downloads the MMS, retrieve confirmation ACK will be sent to notification URL instead of MMSC URL.

Other possible way to avoid this issue is to make MMSC value not editable by user.

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #3)
> Re-open if you have a valid scenario for this bug.
This is a blocker for certification. The ack should be received at the MMSC properly(even if the user delete/modify this field) so the carrier can charge their customers properly.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(In reply to Beatriz Rodríguez [:brg] from comment #4)
> (In reply to Vicamo Yang [:vicamo][:vyang] from comment #1)
> > (In reply to Leo from comment #0)
> > > 5. Expected: Altough the MMSC url format is wrong, MMS should be received
> > > and displayed to user and an ACK sent back to MMSC
> > 
> > How?
> I guess you can use the notification URL for sending back the ACK.

"Guess" doesn't sound ok for me, and requests to an URI specified by Content-Location may be recognized as a new retrieval transaction.  The MMS-CTR[1] has only:

  8.2.2. Notification

  To send a notification response, the MMS Client SHALL invoke an HTTP POST
  operation with an M-NotifyResp.ind PDU embedded as the content body. This
  POST is submitted using a URI that addresses the MMS Proxy-Relay that supports
  the specific MMS Client. The MMS Client SHOULD ignore the associated HTTP POST
  response from the MMS Proxy-Relay.

  8.2.3. Retrieving an MM

  The M-Acknowledge.ind PDU is transported in the same way as the
  M-NotifyResp.ind PDU, i.e., by an HTTP POST over a TCP connection between the
  terminal and the MMS Proxy-Relay. The MMS Client SHOULD ignore the associated
  HTTP POST response from the MMS Proxy-Relay.

MMS-CTR clearly says "using a URI that addresses the MMS Proxy-Relay that supports the specific MMS Client", not Content-Location.

> When user
> downloads the MMS, retrieve confirmation ACK will be sent to notification
> URL instead of MMSC URL.

Not a spec-defined behaviour.

> Other possible way to avoid this issue is to make MMSC value not editable by
> user.

> (In reply to Vicamo Yang [:vicamo][:vyang] from comment #3)
> > Re-open if you have a valid scenario for this bug.
> This is a blocker for certification. The ack should be received at the MMSC
> properly(even if the user delete/modify this field) so the carrier can
> charge their customers properly.

Document number, origin, please!  Don't just say it's a "blocker for certification".  Where is the complete test description for this item?  If you're considering a read-only MMSC field, then obviously you'll have to skip this item because you can't edit MMSC and you can't perform defined test procedures for this item.  If this item is skip-able, it can't be a blocker.

[1]: OMA-TS-MMS_CTR-V1_3-20110913-A
Flags: needinfo?(brg)
Whiteboard: [TD-56817] → [TD-56817], [u=commsapps-user c=messaging p=0]
We are investigating how critical this issue could be during certification.
In the past, it was a blocker, we are now checking if the rule is different, however, we think that it is likely that we need to modify the behaviour in any way to support it.
Flags: needinfo?(brg)
Please see bug 827789, this happened in Deutsche Telekom. In some cell phone operators, they might send MMs with x-mms-content-location uri which is totally different with the MMSC in their APN setting. It means using the notification URL for sending back the ACK should not be worked for DT.
Whiteboard: [TD-56817], [u=commsapps-user c=messaging p=0] → [TD-56817], [u=commsapps-user c=messaging p=0], TaipeiMMS
Flags: in-moztrap-
Vicamo, have you got this?
Flags: needinfo?(vyang)
We don't know how to "validate" or "correction" an MMSC url.  For those don't make valid URI objects, we can; but for those pointing to an foreign but valid IP/FQDN addresses, we can't.  So basically we need an address set by Gaia, and we just pass it to MMS proxy relay without modification at sending ACK back.

As discussed this afternoon, we may have two MMSC addresses, one for |M-Send.req|, another for |M-Acknowledge.ind|.  Both are RO to Gecko but RW to Gaia, and most of the time they're equal to each other.  You may design the policy you need then.
Flags: needinfo?(vyang)
Are you saying this needs to be done by Gaia here then? 
To always ACK using the MMSC server address we have in our apn json file we used for APN profiling?
Flags: needinfo?(vyang)
Flags: needinfo?(schung)
I said we "may".  Per yesterday's discuss, Leo promise to have some investigation on their usual solution on Android devices.

(In reply to Wayne Chang [:wchang] from comment #10)
> Are you saying this needs to be done by Gaia here then? 
> To always ACK using the MMSC server address we have in our apn json file we
> used for APN profiling?

Gecko "may" open another MMSC address that is dedicated for sending ACK to MMSC.  Gaia "may" want to set both at switching APNs listed on apn json, but set only "ril.mms.mmsc" when an user enters some customized settings.
Flags: needinfo?(leo.bugzilla.gaia)
Flags: needinfo?(vyang)
Flags: needinfo?(schung)
(In reply to Beatriz Rodríguez [:brg] from comment #6)
> We are investigating how critical this issue could be during certification.
> In the past, it was a blocker, we are now checking if the rule is different,
> however, we think that it is likely that we need to modify the behaviour in
> any way to support it.

Will you please confirm whether this is a blocker or not?
Flags: needinfo?(leo.bugzilla.gaia) → needinfo?(brg)
(In reply to Leo from comment #12)
> (In reply to Beatriz Rodríguez [:brg] from comment #6)
> > We are investigating how critical this issue could be during certification.
> > In the past, it was a blocker, we are now checking if the rule is different,
> > however, we think that it is likely that we need to modify the behaviour in
> > any way to support it.
> 
> Will you please confirm whether this is a blocker or not?
Operator billing is not affected anymore(improvements in MMSC), we can consider that this is not a blocker but a nice to have/improve for v1.2.
Nominating to Koi.
blocking-b2g: leo+ → koi?
Flags: needinfo?(brg)
Removing from workweek list. No longer a blocker for leo.
Whiteboard: [TD-56817], [u=commsapps-user c=messaging p=0], TaipeiMMS → [TD-56817], [u=commsapps-user c=messaging p=0],
Whiteboard: [TD-56817], [u=commsapps-user c=messaging p=0], → [TD-56817], [u=commsapps-user c=messaging p=0], [comms-triaged]
ni? noemi for v1.2
Flags: needinfo?(noef)
We think that we will not need this in v1.2
Flags: needinfo?(noef)
add to backlog 891754
Blocks: comms_backlog
blocking-b2g: koi? → ---
Component: Gaia::SMS → RIL
Assignee: nobody → btseng
Bevis, Could you please double check if we have a good solution for this problem.
IMHO, it is not possible to send ACK back if there is no valid MMSC configured.
I don't see any good solution about this as well. :(
Even there are some suggestions in comment 4 and comment 9, 
there is still no guarantee that the configured MMSC address is valid.

Hence, again, how can we send any ACK back if there is no valid MMSC?

The only thing we can do is that if there is |NO| MMSC address configured,
The message will not be auto-retrieved.
However, this doesn't help too much if MMSC is available but not valid.
In addition, this is not the expected behavior mentioned in the User Story and 
it will also be a bad UX to the user. :(
How can we receive a MMS without MMSC?
(In reply to Julien Wajsberg [:julienw] from comment #22)
> How can we receive a MMS without MMSC?

The location of the MMS message to be downloaded will be specified in 
the Content-Location of the Notification mentioned in comment 5. :)
Ok, then what should we do here? For example should the Settings app show an error in the Message Settings? Or should we show an in-app notification in the Messages app? Or should we just close this bug WONTFIX?
update to WONTFIX according to comment 23.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 10 years ago
Resolution: --- → WONTFIX
This issue is a block TA issue for us. Would you please to give us some advices for how to fix it? Thanks.
Flags: needinfo?(btseng)
(In reply to chencong from comment #26)
> This issue is a block TA issue for us. Would you please to give us some
> advices for how to fix it? Thanks.

Hi Chencong,

The possible solution is have a 'correct' mmsc/mms proxy fields of current connected operator in
a predefined preference or settings.
If both mmsc/mmsproxy are not available, then the predefined one will be used.
Flags: needinfo?(btseng)
You need to log in before you can comment on or make changes to this bug.