937038 - [Messaging][MMS] Service unavailable when try to send a MMS to valid phone number and other phone number no correct

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: RIL, defect)

Description

[Loli (:lolimartinezcr)]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131025151332

Steps to reproduce:

1. Open a new message dialogue
2. In the to field enter 3 numbers: 2 to valid numbers and 1 to an invalid number (so that the message fails to send to this number)
3. make the message an MMS
4. select send



Actual results:

I can see a screen with this messages:

Service currently unavailable
Message will automatically be sent once service is available


Expected results:

MMS should be sended to 2 valid numbers

Comment 1

[Loli (:lolimartinezcr)]

master 11/11 build:
Gecko-1b73d56
Gaia-b0eb75f

Comment 2

[Bevis Tseng[:bevis][:btseng](Exited)]

Hi,

I would like to reproduce this locally to identify the problem.

In the meantime, may I know the valid and invalid numbers or formats you tried?
Is it also possible to get the log with the following debug flags set to true:
1. DEBUG_ALL in ril_consts.js
2. DEBUG in MmsService.js

Thanks & regards,
Bevis Tseng

Comment 3

[Loli (:lolimartinezcr)]

Numbers:

Valid: 679611975 and 620989920
Not valid: 678

Comment 4

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

The expectation here overthrows that in bug 891756.  ni for further info.

Comment 5

[Bevis Tseng[:bevis][:btseng](Exited)]

Update local test result with the same revision:
1. 678 is not treated as invalid number. (ALL 3 phone numbers are treated as legal recipients.)
2. The MMS is sent normally to the network.

Hi Loli,

Would you mind providing more information or log for further clarification?

Bevis

Comment 6

[Julien Wajsberg [:julienw]]

I don't think the expectations here are different to what is in bug 891756.

bug 917954 moves slowly but will change all error messages. The current error messages in the app are quite wrong, so that might be what causes the confusion here.

Vicamo, when only one of the recipients is wrong, can we know which one it is in Gaia? I think this is planned in the API.

Comment 7

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

(In reply to Julien Wajsberg [:julienw] from comment #6)
> I don't think the expectations here are different to what is in bug 891756.

Please see bug 891756 comment 4 from Gene.  Basically when we find a wrong number in the receivers array, we still save the message but the further transmission process will be aborted.  However, per description from this bug, that (MMS) message still has to be transmitted.  That's why I said the results of the two bugs are different.

> Vicamo, when only one of the recipients is wrong, can we know which one it
> is in Gaia? I think this is planned in the API.

That's not planned.  Not even in W3C Messaging proposal.  But, yes, it's still possible.  We can subclass DOMError and have a InvalidAddressError event that specifies the failed address.

Comment 8

[Julien Wajsberg [:julienw]]

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #7)
> (In reply to Julien Wajsberg [:julienw] from comment #6)
> > I don't think the expectations here are different to what is in bug 891756.
> 
> Please see bug 891756 comment 4 from Gene.  Basically when we find a wrong
> number in the receivers array, we still save the message but the further
> transmission process will be aborted. 

Thanks for pointing this specific comment, looks like I don't know how to read ;)

> However, per description from this
> bug, that (MMS) message still has to be transmitted.  That's why I said the
> results of the two bugs are different.

I understand what you mean now.

> 
> > Vicamo, when only one of the recipients is wrong, can we know which one it
> > is in Gaia? I think this is planned in the API.
> 
> That's not planned.  Not even in W3C Messaging proposal.  But, yes, it's
> still possible.  We can subclass DOMError and have a InvalidAddressError
> event that specifies the failed address.

I kind of thought InvalidAddressError was an error sent by the modem, but reading bug 891756 again I now recall this is a check made by Gecko. I think we'd really need this, but this is for another bug.

In this bug, I think we get an UnknownError: a number has been rejected by the network.

I don't think we can do much here: the message with all its recipients has been rejected by the network, and I don't think we can do better. Vicamo, does the network say which number is rejected, for MMS?

Comment 9

[Bevis Tseng[:bevis][:btseng](Exited)]

Attachment: Log: MMS_SEND_PDU was sent successfully with both valid and invalid numbers.

Testing in local network and the log analysis with Delivery Report set to ON:
1. The MMS-SEND-REQ with valid number: (0953045255) and invalid number (678) are sent successsfully to MMSC.
2. 2 Delivery reports were arrived and told us that 678 is rejected and 0953045255 is success.

--
11-14 10:56:07.363 I/Gecko   (  700): -@- MmsService: send: aParams: {}
11-14 10:56:07.363 I/Gecko   (  700): -@- MmsService: createSavableFromParams: aParams: {}
11-14 10:56:07.373 I/Gecko   (  700): -@- MmsService: createSavableFromParams: normalize phone number from 0953045255 to 0953045255
11-14 10:56:07.373 I/Gecko   (  700): -@- MmsService: createSavableFromParams: normalize phone number from 678 to 678

11-14 10:56:07.373 I/Gecko   (  700): -@- MmsService: createSavableFromParams: aMessage: {"headers":{"to":[{"address":"0953045255","type":"PLMN"},{"address":"678","type":"PLMN"}]},"parts":[{"headers":{"content-type":{"media":"application/smil","params":{"name":"smil.xml","charset":{"charset":"utf-8"}}},"content-location":"smil.xml","content-id":"<smil>"},"content":"<smil><head><layout><root-layout width=\"320px\" height=\"480px\"/><region id=\"Image\" left=\"0px\" top=\"0px\" width=\"320px\" height=\"320px\" fit=\"meet\"/><region id=\"Text\" left=\"0px\" top=\"320px\" width=\"320px\" height=\"160px\" fit=\"meet\"/></layout></head><body><par dur=\"5000ms\"><img src=\"untitled_1.png\" region=\"Image\"/></par></body></smil>"},{"headers":{"content-type":{"media":"image/png","params":{"name":"untitled_1.png"}},"content-location":"untitled_1.png","content-id":"<untitled_1.png>"},"content":{}}],"type":"mms","timestamp":1384397767383,"receivers":["0953045255","678"],"sender":"[phone]","iccId":"8
11-14 10:56:09.485 I/Gecko   (  700): -@- MmsService: sendRequest: register proxy filter to http://mms.emome.net:8002
11-14 10:56:11.296 I/Gecko   (  700): -@- MmsService: xhr success, response headers: Content-Encoding: gzip
11-14 10:56:11.307 I/Gecko   (  700): -@- MmsService: The sending status of sendTransaction.run(): 128
11-14 10:56:11.417 I/Gecko   (  700): -@- MmsService: Sending MMS succeeded.
11-14 10:56:11.417 I/Gecko   (  700): -@- MmsService: Broadcasting the MMS system message: sms-sent

11-14 10:56:14.440 I/Gecko   (  700): -@- MmsService: receiveWapPush: msg = {"headers":{"x-mms-message-type":134,"x-mms-mms-version":16,"message-id":"yzuEUsYSGwIwUwAAkPu-jAsiAAAAAAAA","to":{"address":"678","type":"PLMN"},"date":"2013-11-14T02:56:12.000Z","x-mms-status":130},"type":134}
11-14 10:56:14.450 I/Gecko   (  700): -@- MmsService: Start updating the delivery status for envelopeId: yzuEUsYSGwIwUwAAkPu-jAsiAAAAAAAA address: 678 mmsStatus: 130
11-14 10:56:14.450 I/Gecko   (  700): -@- MmsService: Updating the delivery status to: rejected

11-14 10:56:22.107 I/Gecko   (  700): -@- MmsService: receiveWapPush: msg = {"headers":{"x-mms-message-type":134,"x-mms-mms-version":16,"message-id":"yzuEUsYSGwIwUwAAkPu-jAsiAAAAAAAA","to":{"address":"[phone]","type":"PLMN"},"date":"2013-11-14T02:56:19.000Z","x-mms-status":129},"type":134}
11-14 10:56:22.117 I/Gecko   (  700): -@- MmsService: Start updating the delivery status for envelopeId: yzuEUsYSGwIwUwAAkPu-jAsiAAAAAAAA address: [phone] mmsStatus: 129
11-14 10:56:22.117 I/Gecko   (  700): -@- MmsService: Updating the delivery status to: success

Comment 10

[Bevis Tseng[:bevis][:btseng](Exited)]

Attachment: Screenshot: Invalid Number will be filtered out in the composer and will not be added into recipient list when sending.

The screenshot shows that if an invalid address is input, the composer will filter it out when sending.

Comment 11

[Bevis Tseng[:bevis][:btseng](Exited)]

Hi Vicamo, Julien,

I have done some test locally and upload my finding in comment#9, comment#10.
Basically, 
1. The invalid number 678 claimed by the reporter was not identified as an invalid number in the device side and the message is sent successfully to the MMSC.
2. I was aware that the number is invalid because the corresponding delivery report status of 678 is 'rejected'.
3. The invalid number we recognized in device side will be filtered out by the composer before sending. (Please see the screenshot attached in comment#10).

So, the behavior is different from what reporter has observed:
'I can see a screen with this messages:
  Service currently unavailable
  Message will automatically be sent once service is available'.

It seems that we still need more information from reporter to know what error was sent that caused this UI display this messages. 

Hope this information is helpful to identify the problem.

Comment 12

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

(In reply to Julien Wajsberg [:julienw] from comment #8)
> In this bug, I think we get an UnknownError: a number has been rejected by
> the network.

Maybe.  Bevis' investigation tells us that reported number won't cause an issue in his tests, but there could still be other examples like a long long long phone number.

And I'd say in this topic (multiple-recipient) MMS acts in a different way with (multiple-recipient) SMS.  For SMS, a wrong-numbered recipient has no effect to others, but for MMS, it blocks the delivery as the bug description says.  If we have now an updated user story suggesting that we should remove the check in MMS, that sounds good to me because we can eliminate such difference between MMS and SMS.

> I don't think we can do much here: the message with all its recipients has
> been rejected by the network, and I don't think we can do better. Vicamo,
> does the network say which number is rejected, for MMS?

Unfortunately, no.  In M-Send.conf PDU we have two fields indicating the send status -- X-Mms-Response-Status and X-Mms-Response-Text.  The latter is optional and by OMA-TS-MMS_ENC-V1_3-20110913-A "the description may be based on the status code names contained in [RFC1893]."  So it's basically X-Mms-Response-Status in plain text.

Comment 13

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

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #12)
> In M-Send.conf PDU we have two fields indicating the
> send status -- X-Mms-Response-Status and X-Mms-Response-Text.

BTW, X-Mms-Response-Status could be

  Error-sending-address-unresolved
  Error-transient-sending-address-unresolved
  Error-permanent-sending-address-unresolved

But no additional information could help us determine which recipient address goes wrong.

Comment 14

[Julien Wajsberg [:julienw]]

Ok so I don't think there is much we can do, right?

That said, I'd like to know what competing platforms are doing in this case. Reporter, could you help?

Comment 15

[Loli (:lolimartinezcr)]

Attachment: Bug_937038.txt

Attach log file.

I have created MMS with 3 participants ( 679611975 valid, 620989920 valid and 6789 invalid)

Comment 16

[Bevis Tseng[:bevis][:btseng](Exited)]

Hi Loli,

After checking the attached log, we didn't find any MMS related logs similar to what I pasted in comment#9 (with tag of MmsService) were printed for further analysis.

Would you please kindly help to 
1. check if you had set the DEBUG flag to true mentioned in comment#2 in the rom build you tested and capture the log again with correct log tags?
2. compare what the reference phone behaves to the same recipients in the same network?

This information is really helpful for us to identify the problem because we are not able to reproduce this symptom in our live network.

Thanks & regards,
Bevis Tseng

Comment 17

[Loli (:lolimartinezcr)]

Attachment: Bug_937038_v2.txt

Comment 18

[Loli (:lolimartinezcr)]

Log attached with flags set to true:
1. DEBUG_ALL in ril_consts.js
2. DEBUG in MmsService.js

Comment 19

[Bevis Tseng[:bevis][:btseng](Exited)]

Hi Loli,

After checking the log, we found that the error was reported from MMSC instead of from the device with |X-Mms-Response-Status| equal to 195.
According to 7.3.48 X-Mms-Response-Status Field in OMA MMS Encapsulation Protocol 1.3,
"195" is mapped to "Error-transient-network-problem" -> "The MMS Proxy-Relay was not able
to handle the corresponding M-Send.req due to unspecified error on the transport layer or capacity overload."

There is no way for device to tell if the sent address is valid or not.

Hence, it looks more likely to be a network issue instead.

Would you please help to check the behavior in other reference phone as well?

Thanks & regards,
Bevis Tseng

--
I/Gecko   (  109): -@- MmsService: createSavableFromParams: aMessage: {"headers":{"to":[{"address":"679611975","type":"PLMN"},{"address":"620989920","type":"PLMN"},{"address":"678","type":"PLMN"}]},"parts":[{"headers":{"content-type":{"media":"application/smil","params":{"name":"smil.xml","charset":{"charset":"utf-8"}}},"content-location":"smil.xml","content-id":"<smil>"},"content":"<smil><head><layout><root-layout width=\"320px\" height=\"480px\"/><region id=\"Image\" left=\"0px\" top=\"0px\" width=\"320px\" height=\"320px\" fit=\"meet\"/><region id=\"Text\" left=\"0px\" top=\"320px\" width=\"320px\" height=\"160px\" fit=\"meet\"/></layout></head><body><par dur=\"5000ms\"><img src=\"IMG_0001.jpg\" region=\"Image\"/></par></body></smil>"},{"headers":{"content-type":{"media":"image/jpeg","params":{"name":"IMG_0001.jpg"}},"content-location":"IMG_0001.jpg","content-id":"<IMG_0001.jpg>"},"content":{}}],"type":"mms","timestamp":1385974019734,"receivers":["679611975","620989920","678"],"se
I/Gecko   (  109): -@- MmsService: sendRequest: register proxy filter to http://mms.movistar.com
I/Gecko   (  109): -@- MmsService: xhr success, response headers: Server: Apache-Coyote/1.1
I/Gecko   (  109): Connection: close
I/Gecko   (  109): Content-Type: application/vnd.wap.mms-message
I/Gecko   (  109): Content-Length: 180
I/Gecko   (  109): Date: Mon, 02 Dec 2013 08:47:09 GMT
I/Gecko   (  109): -@- MmsService: The sending status of sendTransaction.run(): 195
I/Gecko   (  109): -@- MmsService: The returned status of sending transaction: aErrorCode: 4 aEnvelopeId: 53B791EA-5B2E-71E3-923C-78E7D15A2A38
I/Gecko   (  109): -@- MmsService: Marking the delivery state/staus is done. Notify sent or failed.
I/Gecko   (  109): -@- MmsService: Sending MMS failed.

Comment 20

[Loli (:lolimartinezcr)]

I have check the behavior in other  "unagi" and this error happens.

I  haven't tested this behavior in other type of device "buri" because i haven't "build".

Comment 21

[Bevis Tseng[:bevis][:btseng](Exited)]

Compare to the comments in comment#11, comment#12, comment#13, and comment#19, 
this is more likely to be an network specific issue.
Currently, there is not much we can do in the device side to handle this error.

Mark as WONTFIX first. We can REOPEN it if this is identified as client-side issue.

Comment 22

[Loli (:lolimartinezcr)]

Scenario Tested with "Android" and when device can't send MMS after I receive a SMS that says:

The MMS unable to send because the target 678 is not valid. Neither has been charged