Eric Burger (eburger@snowshore.com)
Thu, 14 Dec 2000 07:37:13 -0500
No matter how much we try, IVM and VPIMv2 are operationally so different
that there is no real benefit from having the same codec. VPIMv2 has a lot
of operating assumptions and guarantees that just cannot exist in the IVM
world, such as Privacy, real Read Receipt, and Security assumptions.
I know of at least one major VM vendor for whom G.726 was one of the main
obstacles to VPIMv2. Using GSM actually would have been easier!
> -----Original Message-----
> From: owner-vpim@lists.neystadt.org
> [mailto:owner-vpim@lists.neystadt.org]On Behalf Of Martin Dragomirecky
> Sent: Wednesday, December 13, 2000 1:13 PM
> To: Brian Cruickshank
> Cc: Charles Eliot; Anthony Baxter; IETF VPIM List
> Subject: Re: [VPIM] RE: 3GPP-T-WG3 codecs
>
>
> would g.726 32k be another option, one virtue being compat w/ vpim 2?
>
> > Brian Cruickshank wrote:
> >
> > 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 - 14:38:05 IST