Re: [rtcweb] Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard

[Cullen Jennings <[e-mail]>]

> On Feb 26, 2016, at 2:38 PM, Roman Shpount <[e-mail]> wrote:
> 
> I think Cullen put the 6000 ms max limit in the specification. RFC 2833 tones have a limit of maximum duration of 8191 ms before the duration counter overflows when 8 KHz clock is used.

At the time we wanted a number that was less than 8 seconds (due to the limit above) and more than 4 seconds because some call centers use a "long pound" detection with times up to 4 seconds. So I made up a random number that was between 4 and 8 seconds that I hoped most people could live with. There was nothing special about 6 other than >4 and <8. 

For maximal interoperability, I still think we want to be between 4 and 8 seconds for the max.

Given that pretty much the only place these values are limits not really implemented is in the range of parameters values for the WebRTC insertDTMF function, I think the WebRTC spec is a fine place to specify them but don't think it will make any real world difference to interoperability if we move them from spec to another. I'm not of fan of putting two places as that makes it harder to update them and keep them in sync - the issue on sync is that the two standards organization approve revisions to specs on different time lines. 

As FYI ... the w3c spec for the function is at 

http://w3c.github.io/webrtc-pc/#widl-RTCDTMFSender-insertDTMF-void-DOMString-tones-unsigned-long-duration-unsigned-long-interToneGap