VoiceMail notification pretends there are 255 messages. It is not true there are only 2

Bug #1353379 reported by Jean-Baptiste Lallement
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
indicator-messages (Ubuntu)
Invalid
Undecided
Unassigned
ofono (Ubuntu)
Confirmed
High
Tony Espy

Bug Description

Mako build #175

The VoiceMail notification indicates there are 255 voice messages (cf screenshot) on voice mail while there were only 2 new messages.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: indicator-messages 13.10.1+14.10.20140725-0ubuntu1
Uname: Linux 3.4.0-5-mako armv7l
ApportVersion: 2.14.5-0ubuntu3
Architecture: armhf
Date: Wed Aug 6 11:57:43 2014
InstallationDate: Installed on 2014-08-06 (0 days ago)
InstallationMedia: Ubuntu Utopic Unicorn (development branch) - armhf (20140806-020204)
SourcePackage: indicator-messages
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :
tags: added: qa-touch
tags: added: qa-daily-testing rtm14
Revision history for this message
Bill Filler (bfiller) wrote :

I'm seeing this with krillin build 40 on rtm
Indicator always showing 255 voicemail messages
I have a dual sim setup

Changed in indicator-messages (Ubuntu):
status: New → Invalid
Changed in telephony-service:
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Tiago Salem Herrmann (tiagosh)
Revision history for this message
Tiago Salem Herrmann (tiagosh) wrote :

Bill debugged this issue and this is what we found:
http://pastebin.ubuntu.com/8353187/

Looks more like an ofono bug to me. I will reassign.

affects: telephony-service → ofono
Tony Espy (awe)
affects: ofono → ofono (Ubuntu)
Changed in ofono (Ubuntu):
status: Confirmed → Triaged
assignee: Tiago Salem Herrmann (tiagosh) → Jussi Kangas (jkangas)
Revision history for this message
Jussi Kangas (jkangas) wrote :

Tested with Anritsu in simulated GSM and UMTS networks, but nothing comes through. Since ubuntu-touch ofono does not support UNSOL_RESPONSE_NEW_SMS_ON_SIM I don't see how the voice mail interface could work. Need to discuss with others before proceeding

Revision history for this message
Jussi Kangas (jkangas) wrote :

So what I think is happening here is that voice call notification messages are stored to SIM ( as they should in my opinion, see ETSI TS TS 123 038) and not really read ever. Count is read at startup from the SIM and it just keeps rising.

I can reproduce this in the lab now but I need some extra digging to verify the details.

Bill Filler (bfiller)
tags: added: touch-2014-09-25
Revision history for this message
Jussi Kangas (jkangas) wrote :

How to reproduce case:
- Put your SIM card to Iphone Iphone 4.
- Send voice mail message to the phone with SIM.
- Move card to ubuntu-touch phone.
- MessageCount in voicemail interface is 255.

If I check number of voice mail messages waiting in elementary file EF_MWIS in SIM by Aspects Spy I see value 11111111b when after receiving the messages by Mako or old Nokia phone I see 00000001b. I think this is some sort of bug with certain Qualcomm modems ( Originator reported that his reference phone was about year and half old Sony Xperia with unspecified model number ).
Ofono is not doing the writing, modem is doing that, so we cannot change that.

As Alfonso correctly pointed out in our telco, Ofono not notifying the client in run-time if voice mail message is stored directly to SIM is a separate issue and fixing that would not fix reported problem.

Revision history for this message
Tony Espy (awe) wrote :

Just tested RTM #39 on mako with AT&T SIM. As screenshot shows, the indicator shows two waiting messages.

Revision history for this message
Tony Espy (awe) wrote :

Also tested RTM #44 with krillin, and I get a different result yet again. This time the indicator just states "VoiceMail Messages" with no count. This is using a single T-Mobile pre-paid SIM in slot #1.

Revision history for this message
Tony Espy (awe) wrote :

As I'd mentioned before, there are numerous methods of indicating voice-mail waiting message counts. It appears that some of these methods work, and some don't.

It seems we have more investigation needed.

Revision history for this message
Jussi Kangas (jkangas) wrote :

I recommend to check the behaviour in reference phone with those SIM cards. I would not be surprised if T-Mobile for example just does not update the count. Also it would be interesting to know what was your exact test sequence. Did you see the lp1353379-krillin.png run time or after restarting ofono? If you did it see it run-time, did the message count change after restarting the ofono?

Revision history for this message
Tony Espy (awe) wrote :

@Jussi

My test is simple. Start with a SIM with 0 voicemail messages waiting. Do the following steps twice:

1. Call the Ubuntu phone
2. Decline the call
3. Leave a message

I double-checked T-Mobile on mako, and the behavior is the same, so I believe you're correct about T-Mobile not updating message counts. That said, AT&T works fine for me on mako. I unfortunately can't test AT&T because my account appears to have been screwed up, so I will have to try and resolve tomorrow.

It seems like ofono *is* getting notified of the new message, it's just the count itself which isn't being handled correctly. I wonder if we could pin this down via using OFONO_RIL_TRACE on both devices and compare the data?

Have you been able to reproduce with a real network? If not, then perhaps we may need to create an instrumented version of ofono to try and catch this bug.

Revision history for this message
Jussi Kangas (jkangas) wrote :

As said, commercial networks do not support this feature around here. Voice mail message notification comes as regular sms message here. But you can trust that simulation works correctly. It has been used with several enough phones. Message going straight to the sim is a valid case.

And as said, it looks like that 255 is coming from using the card in different phone that updates the SIM differently. If that is wanted to be fixed I think easiest and quickest solution is stop reading file from the SIM. If we wish, we could enhance that solution by reading the value from messages. Third option is not to read the value before new voice mail message.

However, in my opinion this is a trivial case. After user checks the voice mails from network network should send new message that should update the count correctly. Problem with card that has been moved from one phone to another should therefore be shortlived.

Tony Espy (awe)
Changed in ofono (Ubuntu):
assignee: Jussi Kangas (jkangas) → nobody
Tony Espy (awe)
Changed in ofono (Ubuntu):
assignee: nobody → Tony Espy (awe)
Tony Espy (awe)
Changed in ofono (Ubuntu):
status: Triaged → Confirmed
Revision history for this message
Tony Espy (awe) wrote :

Just reproduced on krillin running RTM image #120 with an AT&T SIM ( slot 1 ) and a T-Mobile SIM ( slot 2 ).

Steps to reproduce:

1. Verify T-Mobile VM mailbox is empty.
2. Call T-Mobile number, decline call and leave a messge.
3. Verify that VM notification is received. Krillin indicates "Voicemail messages waiting" with no message count
4. Call number again, decline and leave a second message
5. No new VM notication. Existing notification still says "Voicemail messages waiting"
6. reboot the phone
7. VM notification now reads "255 Voicemail messages waiting"

Output from list-modems shows:

 [ org.ofono.MessageWaiting ]
        VoicemailWaiting = 1
        VoicemailMailboxNumber = +18056377243
        VoicemailMessageCount = 255

Revision history for this message
Tony Espy (awe) wrote :

Leave a 3rd message, indicator is reset to "Voicemail messages waiting" ( no count ).

Reboot again and VM still reads the same ( no count ). Verified that VoicemailMessageCount is still 0.

Revision history for this message
Tiago Salem Herrmann (tiagosh) wrote :

I managed to reproduce this bug on mako with a t-mobile sim card in a dual boot device, and I noticed that android also lists 255 messages, so I believe this bug is in a lower level.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.