Glenn Parsons (gparsons@nortelnetworks.com)
Thu, 14 Dec 2000 14:36:49 -0500
For those of you who don't remember, the original proposal for IVM from
<draft-ema-vpim-simpleV3-00.txt> (you can review the expired drafts on
www.vpim.org) was:
8. Voice CodecsVoice messages may be contained at any location within a message.
The parameters described in [VPIM2] MUST be used to identify them
as voice messages or spoken names. MUST play:
G.726 - audio/32kadpcm or audio/wav; codec=64G.711 - audio/basic or audio/wav; codec=7 MS-GSM - audio/msgsm or audio/wav; codec=31SHOULD encode:
G.726 - audio/32kadpcm or audio/wav; codec=64G.711 - audio/basic or audio/wav; codec=7 MS-GSM - audio/msgsm or audio/wav; codec=31An implementation MUST be able to play either of the three codecs
(either natively or via transcoding) and MUST be able to record
and encode messages in at least one of them.At that time, there was a desire to pick one codec for IVM, not three. And
so the current draft <draft-ietf-vpim-ivm-01.txt> reflects that:
These requirements may be summarised as follows: Codec No VPIM v2 Support With VPIM V2 Support Record Playback Record Playback ------ ------ -------- ------ -------- WAV/MS-GSM MUST MUST MUST MUST G.726 MAY MAY MUST MUST Other MAY MAY MAY MAY Editor's Note: Based on ongoing discussions in the VPIM WG, the baseline codec for IVM may be changed to G.711 mu-law indicated via "audio/basic" or "audio/wav; codec=7".
Are we interested in picking two codecs for IVM? For example:
Codec No VPIM v2 Support With VPIM V2 Support
Record Playback Record Playback
------ ------ -------- ------ --------
WAV/MS-GSM MUST MUST MUST MUST
G.711 MUST MUST MUST MUST
G.726 MAY MAY MUST MUST
Other MAY MAY MAY MAY
Glenn.
> ----------
> From: Cruickshank, Brian [TOR:9T04:EXCH]
> Sent: Thursday, December 14, 2000 10:39 am
> To: Caleb Clausen
> Cc: IETF VPIM List
> Subject: RE: [VPIM] RE: 3GPP-T-WG3 codecs
>
> 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 - 21:38:15 IST