DISQUS

Tom Coseven · 2 years ago

Apple's approach is basically MMS, which has been in the market for 5 years now. One selling point, as you note, is being able access messages offline. The server centric approach is even older (about 15 years) as part of unified messaging. Companies have had little success selling this unified messaging in a fixed-line desktop or phone paradigm, but Apple plus mobile may be the formula. Other companies (without Apple's flair) have tried to apply unified messaging to mobile with little success (e.g., Callwave).

dimitris · 2 years ago

So, 30+ years after email and 15ish years after MIME, the masters of innovation also known as telcos master the audio attachment.

I wonder if this is one of the items of intellectual proper-taah that Jobs said would be vigorously defended during the iPhone unveiling.

dimitris · 2 years ago

I forgot to mention that the existing 3GPP/GSM standard on SMS contains all the (optional) protocol support needed for visual voicemail, namely the Enhanced Voice Mail Information record in the User Data section of a SMS packet.

It would be interesting to inspect a voicemail notification SMS on AT&T;'s network, both for an iPhone account and for a non-iPhone account, to see if they've enabled this on all accounts, just iPhone accounts, or if they rolled their own protocol.

gmahe · 2 years ago

Hi Dimitris,

As per the spec, only the pdu information are mentioned. There is no specific information as whether the audio (corresponding to voicemail msg) is transferred as part of the SMS and also no octets specified for the same.
Is there any other section in the spec which talks about this?

thanks

dimitris · 2 years ago

gmahe: There's no way to fit audio inside an SMS: These go over the control channel of GSM networks; texting began life as something of a hack in the early days of GSM, it wasn't completely planned for. Thus the payload is limited to 140 ASCII-ish characters. You can chain up to - theoretically - 65536 PDUs to make one mega-message, but when thousands of these are being sent around it would probably cause severe control channel hoggage, which is bad.

If the Enhanced Voice Mail Information feature is being used, then what's probably happening is that the EVMI SMS is being used as the "push" notification that there is a voicemail state change. That contains the calling line ID of the voicemail sender (VM_MESSAGE_CALLING_LINE_IDENTITY), so you can match that to the contact database and drive the "visual voicemail" display.

EVMI also contains a VM_MESSAGE_ID field, so one can envision a "web service" (using the term loosely) API to the voicemail servers which takes that ID as a parameter. The iPhone can then invoke that API and retrieve the messages.

Of course the above is all a guess. But if one could examine the SMS PDU received by the iPhone when new voicemail is available, it might shed some light. Unfortunately that requires warranty-voiding surgery, as you have to remove the iPhone SIM and put it in a GSM device that gives you access to the PDUs (most of them do).

Hmm... Come to think of it, maybe, just maybe, the iPhone does too. I'd be surprised, but it's not impossible. One of these days I should go to the local Apple store and do some Bluetooth poking ;-)

The point is that this is hardly earth-shattering stuff, technically.

gmahe · 2 years ago

Dimitris,

Thanks for the detailed explanation. Yes, infact the main point which i am still pondering over is, how IPhone retrieves the voicemail message and stores in the phone.
Because i am not sure whether AT&T; would've modified /added any changes in the network side for this feature apart from the octet info mentioned in 3GPP Spec for SMS.
So if we assume that there are no network side changes, then can it be possible for the voicemail server to directly send the voicemail messages as MMS to the phone?

thanks

dimitris · 2 years ago

gmahe:

MMS also uses the same notify-with-pointer-to-real content delivery method. The "push" notification is still just a "special" SMS message. Without knowing anything about the internals of AT&T;'s network(*), the difference between implementing visual voicemail as MMS vs. EVMI doesn't seem that great: Either way, and only if you want voicemail delivery to the device without a voice call, you need a non-voice - probably HTTP - front end to the voicemail store. Doing it with MMS saves you from implementing EVMI in the voicemail/SMSC interface so maybe that's what they did.

(*) except observing as a user that their - or their international gateway's - SMSCs have issues with some non-english characters in the GSM alphabet and - as of some time ago - severe bugs with multi-PDU SMS

gmahe · 2 years ago

Dimitris,

thanks for the explanation :)
guess, if at all, we get a protocol log of Apple phone, it would be great!

Edward · 2 years ago

As discussed, visual voicemail was not so much new as just brought to the forefront by the release of the iphone. To me the best visual voicemail service out there iphone or not is Youmail

Jonathan Fitt · 1 year ago

Looks like they're just making use of Enhanced Voice Mail Information from 3GPP 23.040 section 9.2.3.24.13

There's quite a lot of flexibility there.

Nick · 1 year ago

Trust the 3GPP and telco guys to reinvent everything from the internet world. Idiots of the first order!

All you need is (a) a mechanism to inform a phone of a new message (b) an application on the phone that talks to a well known server and retrieves the message.

For (a), you can use SMS or any proprietary messaging. For (b), you can use a proprietary app and server. But, heck, you could even use imap so the phone's voice mailbox is syncronised with the server's. Just put a candy wrapper so it doesn't look like you are talking email. And imap would give you much more, such as the ability to forward messages from one mail box to many others.

Its possible to set this up in under a week. All you need is a linux/bsd box with a telephony card and an open source imap server. You can hack another open source email client written in java, python or whatever to be the phone client.

Notice, I said phone, not iphone.