Support AT&T Visual Voice Mail

[Pat McGowan]

If an AT&T SIM has been enabled for Visual Voice Mail, when new voicemail messages are received, the user may see strange messages from the number 100100000 which look like they may be control messages of some sort.

The content looks like a url: alpsgaacds01.attwireless.net:S400?f=0v=800...

...followed immediately by an empty message.

[Tony Espy (awe)]

Did you check for any ofonod error messages in syslog?

WIthout the actual content of the messages, it's going to be hard to debug this.

There's a tracing facility in ofono that

Can you please enable RIL tracing and add the output to the bug?

You can do this by manually editing the ofono upstart job and adding:

env OFONO_RIL_TRACE=y
export OFONO_RIL_TRACE

...and then rebooting.

This will log the RIL messages your phone sends/receives, and then the next time you see the message, we can grab it from syslog, as it'll look something like this:

 [UNSOL]< UNSOL_RESPONSE_NEW_SMS {07912104442961F4000481450200003121401162950A9E41AA890A32CACB6550737ED681B2EF3A282C2F83C270B8FC1D1EA3D3EE33A81DC6A7DBF53628FFAECB41E2303BEC1E9741EC743B4D77818661361B648BC540F437685E2E83D26650FE5D0785E565D0DB0DA2A3CB2079FA8CA683E4617A19046787DD2E50F65D9783CC75361BD47EBBE968761E642E9741F7349B0D9AD3D36C36485C068DD161F9B94C7601}

[Pat McGowan (pat-mcgowan)]

Dec 9 10:27:10 ubuntu-phablet ofonod[1890]: [UNSOL]< UNSOL_RESPONSE_NEW_SMS (07912104442961F4400A81111103010000F53121705122200A8C0B05040B8423F000037502010106266170706C69636174696F6E2F766E642E7761702E6D6D732D6D65737361676500AF848DEDB4848C8298453231323037323032323032373030303036303030303530303030008D9089038031009602EA008A808E02039C8805810305460083687474703A2F2F3139382E3232382E3233382E38303A383030342F31323037)
Dec 9 10:27:10 ubuntu-phablet ofonod[1890]: [UNSOL]< UNSOL_RESPONSE_NEW_SMS (07912104442961F4440A81111103010000F53121705122300A220B05040B8423F0000375020232303232303237303030303630303030353030303000)
Dec 9 10:27:38 ubuntu-phablet ofonod[1890]: [UNSOL]< UNSOL_RESPONSE_NEW_SMS (07913121139408F5400A80011000000000003121900172630A7F060504157B0000767BDBD57E8BD3ECB22B4CA7BBDC65BAAE4683C17EE61ECC64EFE1603053BB77C3C56EB71A6E469399E03DD3B49734CD7B35DA6C664AF762B4D92B979B99E8BD1B2E76BBD570339A4C17D40D9BD3A3F45985C270B5188E66D3B5E7B09A6ECC4E97DD74DD2C56BBC540)
Dec 9 10:27:39 ubuntu-phablet ofonod[1890]: [UNSOL]< UNSOL_RESPONSE_NEW_SMS (07913121139408F5440A80011000000000C83121900172930A06040102000200)

[Tony Espy (awe)]

A quick decode of the above SMS messages shows:

Message #1 - binary encoded SMS
Message #2 - PDU MMS flags set
Message #3 - standard SMS
Message #4 - PDU MMS flags set

So, my guess is this is either a group SMS that utilizes MMS, or it's an MMS message that's been broken apart into several chunks.

Further detective work is required. I'm actually going to be doing some work on MMS in the near future, so I will self-assign, and continue my investigation.

[Pat McGowan (pat-mcgowan)]

Turns out this is a notification of a voice mail change, either new one available or when I remove them.

[Tony Espy (awe)]

OK. The message-waiting interface pending merge review. We're hoping to land it before the Qt5.2 train leaves the station.

If you want to test, the debs are available here:

https://code.launchpad.net/~phablet-team/ofono/ofono-mwi-and-bugs/+merge/204587

[Tony Espy (awe)]

OK, so I think I've manged to craft a test package which reproduces your scenario. I basically hard-wired the code to send the same packets you captured as incoming SMS messages.

I now see the message indicator go blue, and see a popup with the message. Same title as you "1001000000" and the contents of the message is an URI ( eg. vvm.mobile.att.net:5400?f=0... ).

My guess is that the core SMS code in ofono isn't consuming this message as it should be. That'll take a bit more debugging of the code that parses incoming text messages.

[Bill Filler (bfiller)]

I'm seeing the same thing. I have a sim card with voicemail setup. Whenever anyone leaves me a voicemail (with At+t) or I call voice mail and listen or delete a message I get a sms like the attached file

[Tony Espy (awe)]

Thanks for the picture Bill!

So my original guess was that these were binary voicemail indications that weren't being consumed properly by the core ofono code. Per my comment #7, I'd been able to reproduce the bug by hard-coding delayed timer which fired internal notifications with the data Pat had added in comment #2.

Well, when I tried this again today built on top of our latest branch we're trying to merge, I didn't see the incoming messages, nor did the message indicator turn blue. Weird... When I enabled debug for the core ofono sms code ( -d src/sms.c ), I noticed the following output:

ofonod[3497]: src/sms.c:sms_dispatch()
ofonod[3497]: src/sms.c:sms_dispatch() dst 2948 src 9200
ofonod[3497]: src/sms.c:sms_dispatch() dst 2948 src 9200

So next I checked the push-notification plugin to see if that's where these messages were being routed, and lo and behold, the ports 2948 and 9200 are the WAP_PUSH ports, so that's where these messages are now being routed. WAP PUSH is also used by MMS, which registers to see all of these messages too. I have to run this past Sergio, but I imagine if nuntium attempted to decode these messages as MMS messages, it would fail.

The final clue was Bill's photo. If you look at the URL, the hostname is vmm.mobile.att.net. I'm pretty sure "vmm" stands for "visual voice mail".

That said, as I don't have a picture of Pat's message, I may need to be a little more digging to confirm that his messages were also visual voice mail. They may have just been MMS messages. Pat, if so, hope nobody sent you anything we all shouldn't see!

[Tony Espy (awe)]

Here's some more data, the original traced messages indicated by Pat in comment #2 are:

1 & 2: a binary encoded WAP PUSH
3: a text message with a 16-bit application address set via a UDH ( user data header ); this message is not 8-bit binary encoded, thus it's handled by ofono as a regular text message ( this is probably a bug )
4: a text message with the message-waiting bit(s) set in the DCS field; this is properly handled by ofono and causes the message-waiting interface to properly indicate that a new voicemail is available.

I will discuss message #3 with upstream and see if I can get an opinion on why messages with application addresses aren't always treated as datagrams.

[Tony Espy (awe)]

Here's the content of the WAP PUSH messages after concatenation:

0106266170706C69636174696F6E2F766E642E7761702E6D6D732D6D65737361676500AF848DEDB4848C8298453231323037323032323032373030303036303030303530303030008D9089038031009602EA008A808E02039C8805810305460083687474703A2F2F3139382E3232382E3233382E38303A383030342F3132303732303232303237303030303630303030353030303000

[Sergio Schvezov (sergiusens)]

This seems to be an mms

2014/04/28 16:01:55 Push data
00000000 01 06 26 61 70 70 6c 69 63 61 74 69 6f 6e 2f 76 |..&application/v|
00000010 6e 64 2e 77 61 70 2e 6d 6d 73 2d 6d 65 73 73 61 |nd.wap.mms-messa|
00000020 67 65 00 af 84 8d ed b4 84 8c 82 98 45 32 31 32 |ge..........E212|
00000030 30 37 32 30 32 32 30 32 37 30 30 30 30 36 30 30 |0720220270000600|
00000040 30 30 35 30 30 30 30 00 8d 90 89 03 80 31 00 96 |0050000......1..|
00000050 02 ea 00 8a 80 8e 02 03 9c 88 05 81 03 05 46 00 |..............F.|
00000060 83 68 74 74 70 3a 2f 2f 31 39 38 2e 32 32 38 2e |.http://198.228.|
00000070 32 33 38 2e 38 30 3a 38 30 30 34 2f 31 32 30 37 |238.80:8004/1207|
00000080 32 30 32 32 30 32 37 30 30 30 30 36 30 30 30 30 |2022027000060000|
00000090 35 30 30 30 30 00 |50000.|
Setting HeaderLength to 38
Setting ContentType to application/vnd.wap.mms-message
Setting ApplicationId to 4
2014/04/28 16:01:55 &{38 0 4 0 0 application/vnd.wap.mms-message [140 130 152 69 50 49 50 48 55 50 48 50 50 48 50 55 48 48 48 48 54 48 48 48 48 53 48 48 48 48 0 141 144 137 3 128 49 0 150 2 234 0 138 128 142 2 3 156 136 5 129 3 5 70 0 131 104 116 116 112 58 47 47 49 57 56 46 50 50 56 46 50 51 56 46 56 48 58 56 48 48 52 47 49 50 48 55 50 48 50 50 48 50 55 48 48 48 48 54 48 48 48 48 53 48 48 48 48 0]}
Setting TransactionId to E21207202202700006000050000
Setting Version to 0x10 == 16
Setting From to 1
Next string encoded with: utf-8
Setting Subject to
Setting Class to 0x80 == 128
Setting Size to 768
Expiry token: 81
Message Expiry 197958, 0
Setting ContentLocation to http://198.228.238.80:8004/1207202202700006000050000

[Tony Espy (awe)]

@Pat

Can you re-test with the latest stable image and add your results to the bug?

[Pat McGowan (pat-mcgowan)]

Tested on 109
A voice mail on AT&T still results in seeing the control messages

[Bill Filler (bfiller)]

same. All you have to do is call the voicemal (long press the 1 key on the dialer) and when you hang up from the call you get the control message as an sms

[Tony Espy (awe)]

OK, based on comment #7 which details a URL prefixed with "vvm" and Bill's screenshot in comment #9 which show an URL onscreen which also includes an URL with "vvm", my conclusion is that these two SIMs have been enabled for AT&T's Visual Voice Mail which isn't supported by Touch yet.

I enabled Basic VoiceMail on my phone with an AT&T SIM ( GoPhone ), and I don't receive any weird control messages, and VM notification works as expected.

@Pat & @Bill

Can you both please call customer service and confirm whether or not your SIM has been provisioning for VVM? If so, you should probably have the operator disable it and re-provision Basic Voice Mail.

[Bill Filler (bfiller)]

I'm sure it is configured for VVM. This bug should be to track and fix VVM in touch I suppose. Not sure what's involved in supporting it, but as a first phase we should not display sms messages that are VVM related.

[Tony Espy (awe)]

I updated the Importance to Wishlist and changed the summary to "Support AT&T Visual VoiceMail".

That said, based on comment #13, I believe there is a bug in ofono that prevents un-encoded text messages that contain an application ID from being handled properly.