880251 - [MMS] [B2G] Remove own number from 'participants' field in thread created by Group MMS.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: RIL, defect)

Description

[isabelrios]

Bug seen on Unagi v1-train
Gecko-65bbcee
Gaia-13c6246

PROCEDURE
At least devices A and B are unagi devices with v1-train.
1. From device A send an MMS to device B and C.
2. From device B answer to A

EXPECTED
Device B creates a thread with the group MMS received which contains the anwser to the other devices.

ACTUAL
Device B creates a thread correctly with the original group MMS and the answer but this answer is also recived by itself.

Comment 1

[Corey Frang [:gnarf]]

Was the answer reply an SMS?  It can't be a group message unless its an MMS.

Comment 2

[isabelrios]

(In reply to Corey Frang [:gnarf] [:gnarf37] from comment #1)
> Was the answer reply an SMS?  It can't be a group message unless its an MMS.

Hi, The reply was also a MMS.

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

Blocking for now, MMS work.

Comment 4

[Fernando Campo (:fcampo)]

So far I can't test it with any of the simcards I have around, as O2 have a weird system for MMS (uses an url for letting you see the images you received), but after checking the code, it seems that something might be going on when setting the participants in https://github.com/mozilla-b2g/gaia/blob/master/apps/sms/js/thread_ui.js#L1309

We should check if our own number is among those recipients, and take it out if so. What I'm not so sure about is if Gaia should take care of that, or should be on Gecko side.
Is this making any sense to the code creators?


P.S. As I can't test any of the situations described, I'm stepping out of the bug, and give space for someone who can deal with it.

Comment 5

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Fernando Campo (:fcampo) from comment #4)
> So far I can't test it with any of the simcards I have around, as O2 have a
> weird system for MMS (uses an url for letting you see the images you
> received)

Many carriers do that unless you explicitly enable MMS functionality. Go to their web page and see if there's a way to do that (usually it requires sending them a message with a string such as "ENABLE MMS" or something along the lines).

Comment 6

[Fernando Campo (:fcampo)]

(In reply to Gabriele Svelto [:gsvelto] from comment #5)
> (In reply to Fernando Campo (:fcampo) from comment #4)
> > So far I can't test it with any of the simcards I have around, as O2 have a
> > weird system for MMS (uses an url for letting you see the images you
> > received)
> 
> Many carriers do that unless you explicitly enable MMS functionality. Go to
> their web page and see if there's a way to do that (usually it requires
> sending them a message with a string such as "ENABLE MMS" or something along
> the lines).

Yeah, I tried that already :) Answer was 'Unfortunately we had problems dealing with your request. Try again or contact Customer Service'. Sad indeed

Comment 7

[Mike Pennisi [:jugglinmike]]

Eric and I have been investigating this. The problem lies in the way new threads are created. The behavior we are working on will remove the current user's number from the recipients list in new threads.

Comment 8

[Mike Pennisi [:jugglinmike]]

Re-assigning to Eric since he's taken the lead on the patch.

Comment 9

[Borja Salguero [:borjasalguero]]

After reviewing the issue here it seems to be a Gecko issue more than a Gaia issue. From Gaia we can not 'remove' our phone number from the list because we have no 'phoneNumberLib' for managing this (this functionality was moved to Gecko months ago).

In this case it's true that when creating a thread after receiving a Group MMS we should avoid adding our own number to the list of 'participants', and this should be done low level.

Moving to Gecko and updating the bug properly.

Vicamo, could you help on this? We are having a lot of issues in Gaia, due to as we are adding our phone number, even if we answer to the Group MMS we receive our sent MMS! Thanks a lot :)

Comment 10

[Borja Salguero [:borjasalguero]]

STR:
- Send a MMS from A to B & C
- Receive in B the MMS
- Check the thread created in B

CURRENTLY
  + sender: A
  + participants: A, B & C 
- 'B' should be removed, because If I answer to the group I will receive my own MMS.

EXPECTED:
- Thread should expose only A & C as participants, because 'B' (my phone number) will be the 'sender' if I answer the Group MMS (so is implicitly a participant).

Vicamo, Gene, Could you help here? Is leo+ and we are having a lot of issues in MMS related with this. Thanks!

Comment 11

[Gene Lian (I already quit Mozilla)]

I'm afraid we have no way to fix this issue because not every SIM card can provide valid phone number to help us strip out the own number from the receivers. It's more like a SIM card dependent issue.

Maybe we still have a chance to avoid saving the received MMS that is actually sent from us, but I could imagine the solution might be very tricky.

Vicamo, do you have any idea?

Comment 12

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

(In reply to Gene Lian [:gene] from comment #11)
> I'm afraid we have no way to fix this issue because not every SIM card can
> provide valid phone number to help us strip out the own number from the
> receivers. It's more like a SIM card dependent issue.

That's MSISDN.  And yes, not every SIM has it etched in.  So I have no solution for this, either.

> Maybe we still have a chance to avoid saving the received MMS that is
> actually sent from us, but I could imagine the solution might be very tricky.

I don't think this can actually work.

  1. A => B, C;  in B's FxOS phone, we have sender A, recipients B, C, participants A, B, C
  2. B => A, B, C;  in B's FxOS phone, we have sender B, recipients A, B, C, participants A, B, C
  3. C => A, B;  in B's FxOS phone, we have sender C, recipients A, B, participants A, B, C

If you have a full list for all possible situations, I mean, maybe A and C don't know their own number either, then you'll find the only way that Gecko may know B's own number is when following conditions are true:

  I. for a conversation with N participants, inclusive of B, N - 1 messages from all other distinct participants have been received,
  II. for these N - 1 messages, {<recipients>} = {<participants>} \ {<sender>},
  III. B has never sent out a group message, which does NOT contain B in the recipients.

Besides, I don't really think silently drop a already received message is an option.  We may skip retrieval of messages with ADVERTISEMENT as its Message-Class, but that's a different case.

Comment 13

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

https://developer.tizen.org/help/index.jsp?topic=%2Forg.tizen.native.apireference%2FclassTizen_1_1Telephony_1_1SimInfo.html
Tizen has the same problem.

Comment 14

[Dietrich Ayala (:dietrich)]

Do we have the logic already implemented to remove when number *is* available?

Comment 15

[Dietrich Ayala (:dietrich)]

Blocking- for now. The user impact is not large enough to block the entire release on, and the solution is unclear.

Let's look at improving in 1.2 if possible.

Comment 16

[Noemí Freire (:noemi)]

Hi,

IMHO the user impact is quite important since grouping functionality and threading are broken. The response coming from a participant (not being the original sender) generates 2 MMSs, one of them, is received in a separate thread by participant itself (the user is sending a MMS to himself), moreover, it can cause a significant economical impact depending on how MMS are charged (i.e., per event).
Because of those reasons we re-nominate it to leo. 
We consider that this issue needs to be solved or it doesn't make sense to offer grouping functionality since the current flow doesn't work.

Comment 17

[Dietrich Ayala (:dietrich)]

Thanks for clarifying Noemi. The economic impact is important in the launch markets, so yes this should block.

Comment 18

[bhavana bajaj [:bajaj]]

[Triage comment] Passing to David for assingment.

Comment 19

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

(In reply to Dietrich Ayala (:dietrich) from comment #14)
> Do we have the logic already implemented to remove when number *is*
> available?

If you mean "when MSISDN is available", yes, "when comment 12 is met", no.

Comment 20

[Noemí Freire (:noemi)]

As decided during Taipei work week, all groupmms moving to koi? as the feature is no longer in leo (please refer to bug 886767 for leo implementation)

Comment 21

[Preeti Raghunath(:Preeti)]

Please reassign appropriately

Comment 22

[Preeti Raghunath(:Preeti)]

Andrew,

Please review

Comment 23

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

It's mostly nothing Gaia can do, unless we revise the definition of a message thread with the fact "MSISDN is not always available" considered.

Comment 24

[Noemí Freire (:noemi)]

All groupmms moving to comms backlog, Bug 891754

Comment 25

[BMO Automation]

Firefox OS is not being worked on