Blair Whitney (Blair.Whitney@connsys.com)
Wed, 13 Dec 2000 14:59:18 -0800
I feel the need to reply to this issue of MS-GSM vs. G.711. It seems
pertinent to reply to the below issues, due a comment summarizing the VPIM
pre-meeting:
"After some discussion, noting that the reasons for picking MS-GSM were not
as compelling as they used to be, the room felt that mu-law G.711 should be
the baseline codec for IVM."
I think the decision that the reasons for picking MS-GSM are still
compelling today as they were two years ago.
For one, CPE equipment manufacturers do not necessarily want to have to
design in 72Gig hard drives to their products, so storage space for local
caching of messages on CPE is an issue. Also, the difference between MS-GSM
and G.711 voice file sizes is 5 times (not 4 times). This means 5 times as
much data in the mailbox of a unified messaging user on the server, 5 times
as much data being transmitted on the wire, whether it is between server and
client or server and server. When you design a product to support a large
scale customer base, these issues still seem to be pertinent to today's
solutions. Many users are still going to be using 56K dial up modems. Others
using DSL or cable modem may be transmitting other data on the connection at
the same time.
A possible compromise solution for IVM would be to make detection and
ability to play MS-GSM and G.711 a MUST, and leave the generation of coded
voice by an IVM device optional to be G.711 or MS-GSM.
MS-GSM is a fairly low MIPs algorithm, and the source is available freely on
the web. Implementation complexity does not seem to be much of an issue.
I think an email, about 2 years ago, which I have cut and pasted from the
VPIM archives, by Jonathan Taylor of MediaGate, are still valid:
<!--StartFragment-->
From: Jonathan Taylor
Sent: Thursday, January 7, 1999 6:08 pm
To: David Boreham; vpim-l@ema.org
Subject: Re: Fwd: Re: VPIM v3 Required Codecs
> Prediction:
> A defacto standard codec will appear regardless of what
> is written in the spec.
On the UMS service provider/IP telephony voicemail side, two defacto
standard codecs have appeared.
iPost (us), Jfax, Netspeak, Vocaltec, eCorp, Serome, and others are
using GSM audio for voicemail over email.
However none of these systems are using "VPIM" today. It's all a simple
mime GSM audio attachment to email.
Telinet, MCI, Faxweb, and several others are using RealAudio; either as
a MIME attachment or as an embedded URL pointing back to the voice
message.
On the CPE side I haven't (personally) seen any defacto standards.
Anyone?
> Anyone with battle experience in using a unified
> messaging system care to say whether they think
> that low bit rate encoding is really necessary
> for modem connected clients ?
Yes, in our experience it is. Spending 3-6 seconds to download every
one second of audio (using either g.726 or g.711/pcm/etc) was flat out
rejected by the market when we tried it. In many cases it meant you
spent 1-2 minutes downloding a typical voicemail message on a 14.4
connection.
Since then we've tried RealAudio, TrueSpeech, Voxware Rt29, and GSM; and
for a variety of ease of use & technical reasons GSM won out for our
customers.
On ease of use, GSM is already in Windows 95/98/NT, the Netscape
streaming technology, the Microsoft streaming technology, the Java Media
Framework, and GSM decode can be done in realtime in a 100% pure java
applet. On technical: it requires less MIPS than any other streamable
codec, has good audio quality, and the source to implement it is
availble for free. (Actually Netscape uses the free source
implementation in some of their products).
> If it is needed, then perhaps the solution is
> to define an extension to IMAP which allows
> message body part streaming to clients, with
> client-specified transcoding applied.
This is an enhancement, and certainly an option, but unfortunately not
the solution. ;-(
IMAP4 is not common in service provider environments *yet* (as much as I
wish it was) and from what our ISP customers tell us, it is going to be
some time before it is common. POP3 is the in-place solution.
However, we are working on set of extensions to IMAP4 to accomplish
this. There is a mailing list setup, email Jutta Degener
(jutta@mediagate.com) to get the relevant information if you'd like to
join.
In summary, I think that at least one mandatory, low bit-rate codec, is
required for the Vpim desktop efforts. I think that all VPIM desktop
message creators should send messages with this codec until they learn
that the recipient can do otherwise; and I do not propose that we solve
the "learn otherwise" problem today.
Some days I think that there should be one mandatory higher bit-rate
codec in addition to the low bit rate one, either G.726 and
G.711--mostly on days when I am working hard to respect legacy voicemail
system issues. ;-)
However, given how easy it is in terms of MIPS and coding man hours to
support GSM, most days I wonder if we shouldn't look into using GSM for
everything. It was amazingly easy to add GSM to our product compared to
the other codecs we tried, and I'd like to have VPIM desktop pass on
that ease of integration to others.
However, I do think there should be at *most* 2 mandatory codecs, which
all senders and receivers must be able to support. Anything more than
that is likely to burden implementors and prevent rapid acceptance of
this standard.
And with the wide variety of proprietary voicemail in email formats in
place, with more coming almost weekly, I think that rapid acceptance is
an excruciatingly important goal.
-----Original Message-----
From: Brian Cruickshank [mailto:cruicb@nortelnetworks.com]
Sent: Wednesday, December 13, 2000 9:44 AM
To: Charles Eliot; Anthony Baxter
Cc: IETF VPIM List
Subject: RE: [VPIM] RE: 3GPP-T-WG3 codecs
To me, there are the following pros/cons to G.711 and MS-GSM:
Advantages to MS-GSM:
- Less Storage Space
- Faster to download to client
- Faster to send between servers
Advantages to G.711:
- Better Voice Quality
- "Universal" Client Support
- Fewer MIPs / lower complexity / easy to implement
Storage Space:
With 72Gig drives available and storage capacity following Moore's Law, I
think it is fair to say that the 'Less Storage Space' argument will become
less and less of a factor over time. I understand that there are size
limits on mailboxes which come into play but if this is of paramount concern
then perhaps the Unified Messaging vendor would want to transcode into a
lower bitrate format than MS-GSM (e.g G.729A, G.723.1, etc.). If the VPIM
codec was G.711 then this would be more easily accommodated than if it was
MS-GSM, and with better voice quality.
Download to Client:
Because G.711 is such a light-weight codec in terms of the CPU required to
convert 16b linear to / from G.711, vendors can easily transcode VPIM
messages into whatever codec they prefer for downloading messages to
low-bandwidth clients. If the preferred client codec is MS-GSM, then the
'Fewer MIPS' advantage for G.711 is nullified but if the preferred client
codec is NOT MS-GSM (e.g. it could be G.723.1 for a Voice over IP
connection) then the 'Fewer MIPs' and 'Voice Quality' advantages for G.711
become even more important.
Faster to Send Between Servers:
To me, the strongest argument for MS-GSM is that it takes ~ 1/4 of the
bandwidth to send an MS-GSM encoded voice message between 2 universal
messaging servers than it takes to send a G.711 encoded message. This
translates into a lower operational cost to the service provider. With the
'cost per managed bit' dropping in half every 9 months, however, this may
not be a significant factor for very long.
I think that the main advantages of G.711 - ease of implementation,
universal client support and better voice quality - will make it simpler for
vendors to adopt and will keep the intelligibility of voice messages high.
Brian Cruickshank
Nortel Networks
-----Original Message-----
From: Charles Eliot [mailto:charle@Exchange.Microsoft.com]
Sent: Tuesday, December 12, 2000 8:12 PM
To: Anthony Baxter
Cc: IETF VPIM List
Subject: RE: [VPIM] RE: 3GPP-T-WG3 codecs
The ability to take voicemail offline, ie to download onto your laptop
and read/reply without an active connection, has been one of the most
compelling scenarios for unified messaging adoption by corporate road
warriers. I'll try to dig up reference studies.
-----Original Message-----
From: Anthony Baxter [mailto:anthony@interlink.com.au]
Sent: Wednesday, December 13, 2000 3:21 AM
To: Charles Eliot
Cc: IETF VPIM List
Subject: Re: [VPIM] RE: 3GPP-T-WG3 codecs
>>> "Charles Eliot" wrote
> Turns out - after much sighing and gnashing of teeth - that there is
no
> patent issue. MS-GSM implements the GSM codec, and the proposed RFC
> describes how to format a GSM bitstream in such a way that the MS-GSM
> codec can read it.
>
> The balance between file size and desktop ubiquity is always going to
be
> tricky. I'm leaning these days towards G.711, but as Eric Burger
pointed
> out there is still a lot of slow-link dialup going on out there.
As I mentioned in my last mail, though - surely this is more of an
issue for real time voice, like a phone call, rather than
store-and-forward
as for voicemail?
If you are working with low bandwidth clients, I see no reason why
you couldn't offer a voicemail listen page (say, in a webmail type
situation) that sends the data in a more compressed format - has
there been any studies done on how many of those low-bandwidth users
will actually be pulling their email down to their local PCs, versus
leaving it on a webmail service (hotmail, or whatever)?
Anthony
This archive was generated by hypermail 2.0b3 on Thu Dec 14 2000 - 01:04:55 IST