Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED)

[Cameron Byrne <[e-mail]>]

Sent from ipv6-only Android
On Jan 17, 2013 5:32 AM, "Burger Eric" <[e-mail]> wrote:
>
> People, let's be real:

+1.  Seriously,  this is a candidate for the longest  rat hole I have seen
on the ietf ever.

I normally just delete this thread unread since it is so unproductive.

> I get the impression that people think that if their favorite codec does
not become mandatory to implement or at least
implement-under-threat-of-SHOULD, then no one will implement their favorite
codec.
>
> Let us look at the real world. All of those mobile phones with AMR-WB?
They are statistically likely to be calling other mobile phones with
AMR-WB. Unless I missed something, RTCweb still lets the offer include
AMR-WB and the answer select AMR-WB. Your precious AMR-WB codec will still
get used, and you can leverage all of the silicon and pre-paid IPR
licenses. What about all of those Flash implementations with speex? They
are statistically likely to be calling other implementations with speex. I
am again only just guessing that the offer will contain speed and the
answer will contain speex.
>
> What about the poor slob on a mobile with AMR-WB that wants to call that
Flash buddy with speex? Last I looked, the specification has a MTI of opus.
They will connect with opus. If the client is RTCweb compliant, THERE WILL
BE NO AMR-WB/SPEEX/G.722/MUMBLE/FOO TO OPUS/G.711 TRANSCODING.
>
> Now, what about the really poor slob on a non-RTCweb device? Well, they
are, ahem, on a non-RTCweb device. That is way out of scope. But wait, you
will say -- what about the 1.1 billion 3G subscribers with AMR-WB but no
RTCweb? Well, first off, the mobile-based RTCweb device will almost
certainly have AMR-WB. While some folks like to pick on mobile phone
manufacturers, I doubt some product manager is going to say, "Gee, the IETF
specification does not even mention AMR-WB, so I suppose I will not enable
the silicon I already paid for or use the license I already paid for, and I
will spend my engineering budget to take out AMR-WB." Duh - AMR-WB will be
there already, no transcoding, life is good. What about fixed-line or
broadband interoperability with some wireless user, when they only have
G.722? Well, while we are not making the situation any better, THE
SITUATION IS NO WORSE. Transcoding would happen ANYWAY. It happens TODAY.
So get with the program.
>
> Let us fill in the rat-hole and just move on. Two MTI codecs and a
SEPARATE implementation guide listing why you MIGHT want to implement your
favorite codec.
>

Yep.  Seems we decided this months ago but certain people don't want to
hear it.

CB

> [Hmmmm. "MIGHT".  Perhaps a new 2119 term, meaning "You might consider
this, and if you don't do it, may may get cooties."]
>
> On Jan 17, 2013, at 7:54 AM, Andrew Allen <[e-mail]> wrote:
>
> >
> > As I recall during the MTI discussion it was claimed that OPUS was
intended for interoperability between RTCweb endoints and G.711 for
interoperability with legacy. That's why we selected 2 MTI Codecs.
> >
> > Transcoding between G.711 and something else like G.722 will not have
anything like the transcoding cost as between OPUS and G.722 - basically
the complexity of a media gateway.  Of course you will not get the full
fidelity of either OPUS or G.722 but basic audio communications will work
fine which is all I think we can guarantee with legacy.
> >
> > If platforms already have other codecs (such as AMR on mobile devices)
that are usable by the browser then it makes perfect sense that they be
included in the offer but I don't think IETF should start recommending
other codecs to implement other than the 2 MTI. This should be left as
product decisions based on commercial needs and not recommendations made by
IETF the driver for which I suspect has more to do with the interests of
some legacy products/deployments than those of RTCweb.
> >
> > Since almost every computing platform has a browser (including most
mobile phones) within a few years every computing platform will have RTCweb
and OPUS so the need for high fidelity legacy codec interoperability will I
think become a mute point.
> >
> > I think the inteoperability concerns should be more focussed on the
video issue where we seem to have a real problem.
> >
> > Andrew
> >
> > ----- Original Message -----
> > From: Roy, Radhika R CIV USARMY (US) [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2013 06:13 AM Central Standard Time
> > To: Roman Shpount <[e-mail]>; Martin Thomson <
[e-mail]>
> > Cc: [e-mail] <[e-mail]>
> > Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus
Regarding Selecting Recommended Audio Codecs) (UNCLASSIFIED)
> >
> > Classification: UNCLASSIFIED
> > Caveats: NONE
> >
> > Hi, all:
> >
> > A good assessment - thanks to Roman.
> >
> > So, the transcoding cost is enormous from both performance and HW/SW
> > implementation point of view.
> >
> > In the end it may so appear that we are not hearing each other.
> >
> > BR/Radhika
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
Behalf Of
> > Roman Shpount
> > Sent: Thursday, January 17, 2013 5:32 AM
> > To: Martin Thomson
> > Cc: [e-mail]
> > Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus
> > Regarding Selecting Recommended Audio Codecs)
> >
> >
> > On Wed, Jan 16, 2013 at 7:03 PM, Martin Thomson <
[e-mail]>
> > wrote:
> >
> >
> >       If we don't say "webrtc implementations SHOULD implement
> >       G.722/AMR/AMR-WB", what is the failure mode for your application?
> >       Keeping in mind that - because this isn't 2119 MUST - you have to
> >       expect that some non-negligible proportion of clients will not
> > support
> >       this no matter how much extra ink we using in printing large
> > letters,
> >       how much pain does this really cause you?
> >
> >       I expect that the transcoding costs are what this come down to.
> > Does
> >       anyone care to quantify this?
> >
> >
> > If common codecs are not implemented in the browser this would mean
> > transcoding will need to be performed on some sort of server-side media
> > gateway. There are three distinct issues we need to take into account
when
> > dealing with transcoding. I would list them in what, at least from my
point
> > of view, is the order of importance:
> >
> > 1. If you need to do trancoding, you will need to implement a jitter
buffer
> > on the transcoding media gateway. ICE processing and SRTP en/decoding
can be
> > performed on out of order packets as they are received. You cannot
transcode
> > out of order audio. This means audio packets would need to be delayed
by the
> > jitter buffer size. In cases of good internet connection this means 40
ms
> > jitter buffer delay. In cases of consumer internet in US (somebody
sitting
> > on a DSL connection at home behind a WiFi router) you are typically
looking
> > at 60-80 ms jitter buffer delay. If you are dealing with international
> > internet connections jitter of 150 ms to 200 ms is not unheard of. This
> > means an additional delay due to jitter buffering of 40 ms (best case)
to
> > 200 ms. This is in addition to any other delays that are already
present on
> > the audio path. Adding an extra 100 ms of delay can make audio
conversions
> > very awkward or unusable. On the other hand, if the gateway were
performing
> > just ICE and SRTP, it would introduce 1-2 ms of delay at most (In this
case
> > I am talking about a software based implementation running on generic
server
> > hardware. A dedicated DSP solution would probably be even faster).
> >
> > 2. Audio artifacts due to transcoding. Apart from usual audio
degradation
> > due to transcoding (OPUS transcoded to AMR would sound worse then OPUS
or
> > AMR), we would also deal with double packet loss concealment. Media
gateway
> > will conceal lost packets when transcoding. Client will conceal lost
packet
> > received from the gateway. This would actually sound worse then PLC
> > performed in one place.
> >
> > 3. Scalability of the transcoding gateway. Gateway which just deals
with ICE
> > processing and SRTP en/decoding can handle from 2000 to 10000 concurrent
> > call when running on a generic server CPU (different scalability is due
to
> > differences in CPU performance and presence of AES specific
instructions).
> > Gateway that would do G.722 to OPUS transcoding would most likely handle
> > from 500 to 1000 concurrent calls. We are looking at 10x difference in
> > performance. If we need to transcode AMR to OPUS the difference would be
> > even higher. This translates in 10x difference in hardware, data center,
> > power, and operations costs.
> >
> > _____________
> > Roman Shpount
> >
> > Classification: UNCLASSIFIED
> > Caveats: NONE
> >
> >
> >
> > ---------------------------------------------------------------------
> > This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from
your system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb