Brian Cruickshank (cruicb@nortelnetworks.com)
Thu, 14 Dec 2000 09:39:55 -0600
Caleb, I totally agree with your suggestion of supporting both mu-law and
MS-GSM as baseline codecs.
Brian Cruickshank
Nortel Networks
-----Original Message-----
From: Caleb Clausen [mailto:clausen@connsys.com]
Sent: Wednesday, December 13, 2000 9:39 PM
To: Cruickshank, Brian [TOR:9T04:EXCH]
Cc: IETF VPIM List
Subject: RE: [VPIM] RE: 3GPP-T-WG3 codecs
brian,
it looks to me like the ivm product that you're talking about is very
different from the product i actually work on. that's not bad; we
need a variety of implementations to address different needs. but
the standard needs to be broad enough to cover everybody.
it isn't clear to me where you think that the transcoding you
mention below takes place. in the ivm gateway? in the mail server?
your transcoding proposal is mostly irrelevant to the product my
company produces right now. we have to interoperate with
standard, unmodified email clients and servers; our customers are
free to choose whatever clients and servers they want, as long as
they implement internet standard email protocols and formats.
given this environment, transcoding could only be done by our
device (the ivm gateway), since we have control over neither the
email client nor the email server. and there's no way for us to
transcode on the ivm gateway and make the transcoded data
available to a desktop email client. (unless the voice mails we
generate are already in ms-gsm form. (which _is_ what we do.))
to quote from draft-ietf-vpim-ivm-goals-00.txt:
> IVM MUST support interoperability amongst the
> systems listed below:
> - Desktop Email client applications
> - IVM-capable Voice Mail systems
> - IVM-capable unified messaging systems
> - Traditional email servers
efforts are underway to provide a standard way to transcode in
imap. given that this imap extension is not even fully defined yet,
much less implemented by imap client and server vendors or
widely deployed, imap transcoding will not become relevant to us
for 4-5 years, if ever.
in any case, this would not address the issue of a large emails
being unsupported by traditional email servers, since the email
would have to be stored in mu-law form on the mail server itself.
regarding your point about the 72-gig hard drives: this is fine for big-
iron type implementations. but some of us don't want the extra
expense and unreliability that a hard drive implies.
the issue of a default codec is less important to me than the issue
of mandatory support for (playing) some low-bit-rate codec. with
that in mind, let me propose the following compromise:
ivm implementations MUST support playing of both mu-law and ms-
gsm formatted messages. ivm implementations MUST default to
recording in either mu-law or ms-gsm. ivm implementations MAY
play other codecs, and MAY record in one of those other codecs,
provided they know that the recipient can handle that other codec.
From: "Brian Cruickshank" <cruicb@nortelnetworks.com>
> 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.
"The battle
for mental territory
is glory.
End of story."
--KRS-ONE
This archive was generated by hypermail 2.0b3 on Thu Dec 14 2000 - 17:46:22 IST