Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-04.txt

From: [email-masked]
Date: Mon, 27 Jan 2014 14:25:21 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF.

        Title           : WebRTC Audio Codec and Processing Requirements
        Authors         : Jean-Marc Valin
                          Cary Bran
	Filename        : draft-ietf-rtcweb-audio-04.txt
	Pages           : 6
	Date            : 2014-01-27

Abstract:
   This document outlines the audio codec and processing requirements
   for WebRTC client application and endpoint devices.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-audio-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 29 Jan 2014 09:58:50 +0100

WG,

I reviewed the changes introduced here resolves my previous comments.
However, I have to raise one question to the WG.

In Section 3:

   o  G.711 PCMA and PCMU with one channel, a rate of 8000 Hz and any
      ptime value up to 120 ms - see section 4.5.14 of [RFC3551]

It is likely good that one ensures that ones implementation can receive
any number of samples in the RTP payload format. It is also good that
one can send whatever in that range the peer requests. However, I would
note that it is likely good that an implementation restrains oneself to
request ptime values from the peer that are 5 ms increments and likely
20 ms increments for higher values. I have the impression that the used
values are like, 5, 10, 20, 30, 40, 60, 80, 100, 120 ms.

Anyone having any position on this?

Cheers

Magnus

On 2014-01-27 23:25, [email-masked] wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Jan 2014 09:46:09 -0800

> values are like, 5, 10, 20, 30, 40, 60, 80, 100, 120 ms.

I know this is in 3551, but is anyone realistically going to do
anything as high as 120?  It's PCMU after all and the only reason I'm
aware of for going even as high as 20ms is to keep the packetization
overheads down.

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 29 Jan 2014 15:45:16 -0500

Maybe we can ask that receivers MUST be able to receive anything up to
120, but that senders SHOULD use 5, 10, 20, or 40 to avoid causing the
receiver to operate with sub-optimal timing? That being said, even a
ptime of 2.5 ms could possibly end up being used if someone's
transcoding from Opus (which has 2.5 ms frames) to G.711.

	Jean-Marc

On 01/29/2014 03:58 AM, Magnus Westerlund wrote:
> WG,
> 
> I reviewed the changes introduced here resolves my previous
> comments. However, I have to raise one question to the WG.
> 
> In Section 3:
> 
> It is likely good that one ensures that ones implementation can
> receive any number of samples in the RTP payload format. It is also
> good that one can send whatever in that range the peer requests.
> However, I would note that it is likely good that an implementation
> restrains oneself to request ptime values from the peer that are 5
> ms increments and likely 20 ms increments for higher values. I have
> the impression that the used values are like, 5, 10, 20, 30, 40,
> 60, 80, 100, 120 ms.
> 
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories. This draft is a work item of the
>> Real-Time Communication in WEB-browsers Working Group of the
>> IETF.
>> 
>> Authors         : Jean-Marc Valin Cary Bran Filename        :
>> draft-ietf-rtcweb-audio-04.txt Pages           : 6 Date
>> : 2014-01-27
>> 
>> Abstract: This document outlines the audio codec and processing
>> requirements for WebRTC client application and endpoint devices.
>> 
>> 
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>> 
>> _______________________________________________ I-D-Announce
>> mailing list [email-masked] 
>> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft
>> directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
>> 
> 
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 29 Jan 2014 20:53:22 +0000

Can you clarify what problem we are trying to solve here?

Is there a practical problem with implementing the higher values, or are we just trying to prevent someone using the toolkit suboptimally? For the latter, guidance only is needed, and nothing with the strength of SHOULD or MUST.

Regards

Keith

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of 
> Jean-Marc Valin
> Sent: 29 January 2014 20:45
> To: Magnus Westerlund; [email-masked]
> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-04.txt
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Maybe we can ask that receivers MUST be able to receive 
> anything up to 120, but that senders SHOULD use 5, 10, 20, or 
> 40 to avoid causing the receiver to operate with sub-optimal 
> timing? That being said, even a ptime of 2.5 ms could 
> possibly end up being used if someone's transcoding from Opus 
> (which has 2.5 ms frames) to G.711.
> 
> 	Jean-Marc
> 
> comments. 
> > restrains oneself to request ptime values from the peer 
> that are 5 ms 
> > increments and likely 20 ms increments for higher values. I 
> have the 
> > impression that the used values are like, 5, 10, 20, 30, 
> 40, 60, 80, 
> > 100, 120 ms.
> > 
> >> A New Internet-Draft is available from the on-line Internet-Drafts 
> >> directories. This draft is a work item of the Real-Time 
> Communication 
> >> in WEB-browsers Working Group of the IETF.
> >> 
> I-D-Announce mailing 
> >> list [email-masked] 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJS6WhcAAoJEJ6/8sItn9q9Rk4H/i/4hHYhMEavFZLJkOcarkj5
> IDLIqdciA03yLzJnuausuf0RSwAOcqqf+pmox164rYX7oRyxy/fRCJ1IzyY4kB7L
> J8+PaCzMV7Y2uw2/zNQuqFs2tc2dnwho67jWH1o0OP8Y+gJu6MYMMpbcSNGasqbr
> MweHIQy3d/CLqPcrz5a64JCJdyswtBa4aCraJwOrevsH44KEoRvzBOXHSLBX3eJw
> RKzcZMksl7Fy8DH0YrrNF05J7dZ0TfeNb/ZKWBwh6zOmhCVbO+uBZ+cz8LlP2InS
> IH4r1g3hDPjo2YIPr7zIzwoSUtXZvOq0D6h3G+f/+ILHUa5NSkzPK7ybmWyTtU4=
> =pLn+
> -----END PGP SIGNATURE-----
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 29 Jan 2014 16:12:31 -0500

Well, we need a MUST somewhere to determine the minimum capabilities
required to guarantee interop. I think that minimum should at least
include the durations supported by Opus (so that there's at least a
simple way to do Opus->G.711 transcoding). Beyond that I don't have a
strong opinion on whether we should require more and what ptime(s) to
recommend.

	Jean-Marc

On 01/29/2014 03:53 PM, DRAGE, Keith (Keith) wrote:
> Is there a practical problem with implementing the higher values,
> or are we just trying to prevent someone using the toolkit
> suboptimally? For the latter, guidance only is needed, and nothing
> with the strength of SHOULD or MUST.
> 
> Regards
> 
> Keith
> 
>> -----Original Message----- From: rtcweb 
>> [mailto:[email-masked]] On Behalf Of Jean-Marc Valin
>> Sent: 29 January 2014 20:45 To: Magnus Westerlund;
>> [email-masked] Subject: Re: [rtcweb] I-D Action:
>> draft-ietf-rtcweb-audio-04.txt
>> 
> Maybe we can ask that receivers MUST be able to receive anything
> up to 120, but that senders SHOULD use 5, 10, 20, or 40 to avoid
> causing the receiver to operate with sub-optimal timing? That being
> said, even a ptime of 2.5 ms could possibly end up being used if
> someone's transcoding from Opus (which has 2.5 ms frames) to
> G.711.
> 
> Jean-Marc
> 
>>>> o  G.711 PCMA and PCMU with one channel, a rate of 8000 Hz
>>>> and any ptime value up to 120 ms - see section 4.5.14 of
>>>> [RFC3551]
>>>> 
>>>> It is likely good that one ensures that ones implementation
>>>> can receive any number of samples in the RTP payload format.
>>>> It is also good that one can send whatever in that range the
>>>> peer requests. However, I would note that it is likely good
>>>> that an implementation restrains oneself to request ptime
>>>> values from the peer
> that are 5 ms
>>>>> Internet-Drafts directories. This draft is a work item of
>>>>> the Real-Time
> Communication
>>>>> Title           : WebRTC Audio Codec and Processing 
>>>>> Requirements Authors         : Jean-Marc Valin Cary Bran 
>>>>> Filename        : draft-ietf-rtcweb-audio-04.txt Pages : 6
>>>>> Date : 2014-01-27
>>>>> 
>>>>> Abstract: This document outlines the audio codec and 
>>>>> processing requirements for WebRTC client application and 
>>>>> endpoint devices.
>>>>> 
>>>>> 
>>>>> Please note that it may take a couple of minutes from the 
>>>>> time of submission until the htmlized version and diff are 
>>>>> available at tools.ietf.org.
>>>>> 
>>>>> Internet-Draft directories:
>>>>> http://www.ietf.org/shadow.html or
>> _______________________________________________ rtcweb mailing 
>> list [email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 29 Jan 2014 17:23:25 -0700

> Anyone having any position on this?

No objections. 

In practice primes other than 20, 30, 40 , and 60 have high failure rates - I would expect tons of failures for 5 ms.

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 29 Jan 2014 20:52:00 -0500

On 01/29/2014 07:23 PM, Cullen Jennings wrote:
>> receive any number of samples in the RTP payload format. It is
>> also good that one can send whatever in that range the peer
>> requests. However, I would note that it is likely good that an
>> implementation restrains oneself to request ptime values from the
>> peer that are 5 ms increments and likely 20 ms increments for
>> higher values. I have the impression that the used values are
>> like, 5, 10, 20, 30, 40, 60, 80, 100, 120 ms.
>> 
> In practice primes other than 20, 30, 40 , and 60 have high
> failure rates - I would expect tons of failures for 5 ms.

Just to make sure, are you suggesting:
"MUST support at least 20, 30, 40, and 60"
or
"MUST support any ptime, but SHOULD only use 20, 30, 40, or 60"?

	Jean-Marc

>>> Filename        : draft-ietf-rtcweb-audio-04.txt Pages
>>> : 6 Date : 2014-01-27
>>> 
>>> Please note that it may take a couple of minutes from the time
>>> of submission until the htmlized version and diff are available
>>> at tools.ietf.org.
>>> 
>>> Internet-Draft directories: http://www.ietf.org/shadow.html or 
>> Färögatan 6                 | Mobile +46 73 0949079 SE-164 80 
>> Stockholm, Sweden | mailto: [email-masked] 
>> rtcweb mailing list [email-masked] 
> _______________________________________________ rtcweb mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 30 Jan 2014 10:22:44 -0700

> "MUST support any ptime, but SHOULD only use 20, 30, 40, or 60"?

Really I don’t care too much about what it says about what range is allowed as long as the default is something that has high odds of working and that the range that is allowed at least includes 20, 30, 40, and 60. 20 and 30 because that is widely used. 40 because that has some gains for some people and they think they like it. And 60 because there are some soft phones written in Java that can only do 60.  I think everything suggested has meant theses goals so I’ve got no objects to any of the things proposed.  I find the idea of 2.5 ms G.711 packets mildly amusing. Not sure the case were they would get used but someone will probably come up with a use case and if browsers want to support them, fine by me. 

I suspect what is missing here is that the default ptime in an offer for g.711 should be 20 and I think you are suggesting a maxptime of 120 ms. I don’t think you need to put any restrictions on what ptimes are allowed other than that. Need something similar for opus and for other codecs not listed here. 

The draft seems like it should be clear about ptime and maxptime - a Ref to 4566 is probably needed. 

Few nits …

In the draft there is something wrong with Opus-RTP reference.

I’m not sure I would say "Encryption and
   authentication issues are beyond the scope of this document." I think it might be better to say they are covered in security document.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 31 Jan 2014 14:24:27 -0700

Jean-Marc and I were talking about this on IM and here’s my proposal for all this stuff. 

We keep the part about what happens with RTP in draft-ietf-rtcweb-audio but move the parts about SDP off to JSEP. I think that means all we need here is basically MUST implement G.711 & Opus along with their RTP payload formats. 

The ranges of size of packets, frames  and other things seem to be adequately covered by the specs for the codecs and WebRTC is not chaining theses codecs so seems good enough. The JSEP draft that is pointing at all the parts of SDP that need to be supported can deal with the ptime and maxptime in SDP. 

Cullen

On Jan 29, 2014, at 6:52 PM, Jean-Marc Valin <[email-masked]> wrote:

> iQEcBAEBAgAGBQJS6bBAAAoJEJ6/8sItn9q9msUH/iEm+jtj5wIYWA8M2oT1ekhb
> sYJLtyRU/Lngwdabog5nxBZEj7IWmBJ8r9NeRrQo2GSUvrfhlDMBu8EGaNH9vRkT
> CNvt50gQpKiDmxcvR9bwKd43rn3IFj34HNcl+yAjxS2yCvp6ADz9hg1kz4FTnAkp
> 2emn4G78qwPpW9ODUbI1PLkU1kD/3A9Ccqif817dPF+j5DoHUMLaIrn5H7LKL+NF
> zxSbTq2YSlnKXdsQ98XKi8V7hjimELMj71aNHJ0v0+JPPJCc5QMRY7erWimKDdvO
> 2zyF31uusiiozVaG1AsRpzAZlSgCtvMfz+w4V1cDI8WoVU4wILpuiO8wf9JK4ss=
> =5g7m

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 31 Jan 2014 13:39:35 -0800

> The ranges of size of packets, frames  and other things seem to be adequately covered by the specs for the codecs and WebRTC is not chaining theses codecs so seems good enough. The JSEP draft that…

Sounds good to me.