From nobody Mon Feb 1 08:46:33 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2A11B325D for ; Mon, 1 Feb 2016 08:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz9e1zvKJngB for ; Mon, 1 Feb 2016 08:46:30 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9691B325C for ; Mon, 1 Feb 2016 08:46:30 -0800 (PST) Received: by mail-qg0-x22e.google.com with SMTP id 6so122459616qgy.1 for ; Mon, 01 Feb 2016 08:46:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nimYo6TBKxwJDItzGiDmlWhWPRrp2s6iXAAaQEQNn08=; b=BfO2qsFYwAqJTcoV7Zab94pJPjO1prrYrn16FJ9hckpVkDj8M6qR6XwQ3gC5jicn9X dz3erpbhGwz16jlZLZWZERNCNA0io1pW65hJdMFHqHb+Mx7G5HI7bmUxfT7ORN8ur/m1 XrNZGkIZSYJ4MzHzjTZFTat9sKJ7cq1DtQZbQUOmbBbX36GTGvomZ5MYoanxNC9hi/2g 7P6Cb6dOCxsfTFnIcGSZxCqpPbENoTri4eKa4wpCnq/xrX45erwiaCtC3w7LMhveBWBW F2BH/v0c+TkGTzjOsYl+uYFzXqWCFGQS4QIDEWfJeGMR4Gl9ls6eGFo56U72VFIviRrF CugQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nimYo6TBKxwJDItzGiDmlWhWPRrp2s6iXAAaQEQNn08=; b=O4dDitECV+UaIj8C5Fz8+FB9NdUmTLHv5k74yfWMfTbaqpZmZFIjZDJWEcpfLwMJFX 8Q046tBGXZpTIreqGKXmNh1ru82JpuFc+4aq7AIiEafu6OOl3VAi0GoLmDTztaH1szRl ehkd+64rk0QcOVC+ypK6ai71DF0RTZVEYHzeEY3zzyxcIZT5klLSiaHrU2S5XP6vNW0i Br459TilTO1rwpxBjR8GPtudBxGEiBK/FbAAesGQhECRuG8yOHsW3WKpytAd49f7QVTU r2np1U6MmAOywjiByXJnHI9KJOB91haFQJgA7DiXGptY19mgBs1xwY9ajAJKEQEbb7iU /B/A== X-Gm-Message-State: AG10YOQiXEKNUYI6vXL1WqT0cOEGpGLHHNTChtCpAA4ghUY+CV++dVe0U2Y8jdqT9Bgu2T7SYjre4IFdtCd2sQ== X-Received: by 10.140.94.68 with SMTP id f62mr30076173qge.0.1454345189275; Mon, 01 Feb 2016 08:46:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Mon, 1 Feb 2016 08:46:09 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Mon, 1 Feb 2016 08:46:09 -0800 Message-ID: To: Suhas Nandakumar Content-Type: multipart/alternative; boundary=001a11394c9e633e61052ab820cf Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Doodle for Virtual Interim timing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 16:46:32 -0000 --001a11394c9e633e61052ab820cf Content-Type: text/plain; charset=UTF-8 It was, but I will re-issue with time zone information as soon as Doodle stops giving me a 503. Ted On Sun, Jan 31, 2016 at 5:02 PM, Suhas Nandakumar wrote: > That was my assumption looking at the offered slots :) > > > On Sunday, January 31, 2016, Martin Thomson > wrote: > >> On 30 January 2016 at 06:10, Ted Hardie wrote: >> > http://doodle.com/poll/tn2uavay8bhq4iwe >> >> >> I assume that in the absence of time zone information, this is Pacific >> Time. No? >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > --001a11394c9e633e61052ab820cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It was, but I will re-issue with time zone informat= ion as soon as Doodle stops giving me a 503.

Ted

On Sun, = Jan 31, 2016 at 5:02 PM, Suhas Nandakumar <suhasietf@gmail.com> wrote:
That was my assumption looki= ng at the offered slots :)


On Sunday, January= 31, 2016, Martin Thomson <martin.thomson@gmail.com> wrote:
On 30 January 2016 at 06= :10, Ted Hardie <ted.ietf@gmail.com> wrote:
> = http://doodle.com/poll/tn2uavay8bhq4iwe


I assume that in the absence of time zone information, this is Pacific Time= . No?

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--001a11394c9e633e61052ab820cf-- From nobody Mon Feb 1 08:56:41 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5699F1B3277 for ; Mon, 1 Feb 2016 08:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzjZOTY7qWAL for ; Mon, 1 Feb 2016 08:56:39 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8D51B3276 for ; Mon, 1 Feb 2016 08:56:38 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id o6so53278375qkc.2 for ; Mon, 01 Feb 2016 08:56:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=f+GjLcsd8dbB/D/73AQKnTPc2/nLuoGLuPXMrYt5pPc=; b=wDOnbhzqsgwmAQHM4iY1JvHqA6ae0SKSvFzIz1lpEMuraHp+oneO/p06xkGNq6TODW I5B02kRM63ILX41K0cCk1TcmuQYk0v3l88Ncfk6YtPDy1kt0CQFU3LWtPFRO/ekkUGZr zSKiDzZQZddb/xzLMQMx565PJ44+Ir53G5PCSp/lxyqFLk7ymKRa7nnAZQlF5jEFtJEW d14Of18m09zZL4B7B6GX+XVsmfu9QtcnY80PNah2y8M7l28K1BlmSwkANkCC9O1I49ep jexpEUWhTvZNTuvHNfa4m1Uzn4pHyOytmm++VtNCq7WiTjGEjKp27AT04R8UILRSjgIy 6jpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=f+GjLcsd8dbB/D/73AQKnTPc2/nLuoGLuPXMrYt5pPc=; b=U3PO/P3aijyCQOZvCUsHHjjiE1NqDEynMH55KBznd97SkFnlPHxaw4R16wj+Y7nREG zokUmfjy/6YPnH46ydViBKTRksEcV2UNZ6J5DmvjCiGQ3bllFaxHY3ItFWN3lrnOgtNl OPjXO7GGdB0wmyi8Qs9GGxhx4yx0gHZ9XLEsdrGK0iZDP+ff8QWQ+LnUuf8RbSbhSYSC nIXxJkfgutBd7Fz72M2kke04SPuhvS9yCqXVqzRcBdvfMBT+u7o8KLRB6UOeBadycbU2 MGmJzbpEPaDvisinaFLFLA8BxyOU2h+O9PKkIRPXHOjDNSOiGxuMLDvcpL7ca5/gwLQu dmog== X-Gm-Message-State: AG10YOQj087NKwPU4B4wPzxv/gyk/DmG2mqZPRnuR6cnBOXNiylGx6U3nPxumLb3DIR4bkYnjfODEog6EDrXGA== X-Received: by 10.55.212.152 with SMTP id s24mr29852364qks.36.1454345797882; Mon, 01 Feb 2016 08:56:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Mon, 1 Feb 2016 08:56:18 -0800 (PST) From: Ted Hardie Date: Mon, 1 Feb 2016 08:56:18 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a11498d88a9e35c052ab8446b Archived-At: Subject: [rtcweb] Updated doodle poll link X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 16:56:40 -0000 --001a11498d88a9e35c052ab8446b Content-Type: text/plain; charset=UTF-8 Here is the updated link with timezone selection enabled: http://doodle.com/poll/7vq4u4yyf3sdmgn4 regards, Ted --001a11498d88a9e35c052ab8446b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here is the updated link with timezone selection en= abled:

http://do= odle.com/poll/7vq4u4yyf3sdmgn4

regards,

Ted
--001a11498d88a9e35c052ab8446b-- From nobody Tue Feb 2 11:38:09 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DE71B2FF6 for ; Tue, 2 Feb 2016 11:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFb7yVu31aX8 for ; Tue, 2 Feb 2016 11:38:06 -0800 (PST) Received: from smtp65.ord1c.emailsrvr.com (smtp65.ord1c.emailsrvr.com [108.166.43.65]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D148F1B2FF5 for ; Tue, 2 Feb 2016 11:38:05 -0800 (PST) Received: from smtp9.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp9.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 232FB3803F3; Tue, 2 Feb 2016 14:38:05 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp9.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 6DD47380416; Tue, 2 Feb 2016 14:38:04 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.24.78.56] ([UNAVAILABLE]. [128.107.241.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Tue, 02 Feb 2016 14:38:05 -0500 From: Cullen Jennings Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Feb 2016 10:20:43 -0800 Message-Id: <7A1D1E34-713A-4E21-B10A-39AD08EACCAB@iii.ca> To: "" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [rtcweb] Summary of DTMF Issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 19:38:08 -0000 I had a phone call with Roman to try and get to make sure I understood = the DTMF issues he is concerned with. It was very productive and I am = going to try and summarize my understanding of the issues here (and = Roman feel free to correct me if I got any of this wrong).=20 Three basic issues 1) Support for A-D (been much discussed). This may be the least = important=20 2) Which specification certain things are specified in 3) timing of the DTMF event packets (this is probably the most = important) Let me outline each of these=E2=80=A6=20 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 Issue 1 - DTMF A-D Roman believes that the DTMF A-D tones, while not used all the time, are = used for signalling between some call centre IVR applications (from one = IVR to another) and that they are supported by the major US carriers = representing half or more of the market. (Rowan can you put in any more = here about where it works - was this on IP connection of ISDN = connections ?) Other people seem to think they are not supported on the majority of = ISDN trunks thus are very risking to use from end user (like browser) as = they encouraged applications that failed.=20 I have not heard anyone say this is the end of the world one way or the = other. It is worth nothing that they were required in RFC 2833 but = became optional in 4733.=20 -------------- Issue 2 - Which spec should some of the things be in Right now the normative text on tone duration and gaps between tones is = in the W3C spec. Roman thinks what the text says is correct but it is in = the wrong specification and should instead be normatively defined in an = IETF spec (and the W3C spec can point at that or have a non normative = summary of it) Right now the IETF specs normatively define the range theses options can = cover, and the W3C spec defines an API to set them along with default = values for browsers if they are not set. All within the IETF defined = ranges. So the IETF says the range applications need to be in and the = W3C say for the browser application what the default is for the browser = application.=20 I think the best approach here might just be to get the WebRTC and = RTCWeb chairs to have a quick phone call and see if they can come up = with a proposal they think everyone can live with and float it to both = lists. (note I=E2=80=99m just saying this my individual contributor hat = on - I have not talked to any other chairs about it and have no idea = what they will say ) ----------------- The 3rd issues the biggest issue and has to do with when events are sent = and if audio is suppressed while the events are being sent.=20 First let me get the easy part of this =E2=80=A6 If you receive = unsuppored audio events , they should just be ignored (other than = updaing stats) and not cause any problem like audio artifacts , stopped = connection etc. I think everyone agrees with this but but we need to = check that this is clear enough in the various specifications. (I sort = of hope this got covered in 4733 but if not we might need a clarifying = statement in one of the rtcweb specs). Before I get into the harder part of this issue about what senders = should do, let me explain a bit about what most receivers do.=20 When rendering a received DTMF even into an auto stream, the DTM = overwrites the audio for the duration of the DTMF tone. Every PSTN GW or = IP phone that I have seen the code of for this does this simply by = decoding the audio stream into the jitter buffer, computing where in the = audio stream the DTMF tone would go then synthesizing a DTMF tone it = writing it over the audio samples in the jitter buffer. The varies specs = require this.=20 What senders do is a bit broader. Lots of GWs and ATA will use a DSP to = detect the tones in the audio stream, suppress them out of the audio = stream, then send the 4733 event of the detected tone. The reason to = suppress them is that if the far end is also running a DSP to listen for = in band tones as well as receiving out of band tones, you can get double = detection near the start of the tone. The normal VAD processing will = typically cause the no audio packets to be sent for the time of the = surpassed audio while the 4733 events are being sent.=20 On the other hand lots of IP phones that are configured for 4733 do not = generate any inland audio tones. When they user hits they button, they = just generate 4733 events along with the timing information for them. = This often totally uncoupled from the microphone audio path that just = keeps sending audio from the microphone at the same time. One of the = advantages of this is that since they 4733 tones are out of band, they = don=E2=80=99t destroy the inland audio. So if you are on a conference = call and using DTMF tones to do something like start or stop a = recording, the person can keep talking while pressing the DTMF tones = that the conference bridge will get the 4733 events and people listening = to the call will continue to hear the person speaking with no gaps in = the audio around the time that the keys were pressed to start or stop = recording.=20 Note that given receivers work as described above, both of these sender = strategies work out fine.=20 Roman would like to reduce the variance of what senders are allowed to = do. This proposal applies just as much to SIP or any other applications = of 4733 and is not specific to WebRTC.=20 I=E2=80=99m going to outline 3 options. Option 0 is not what Roman wants = to do but I include it just as a sort of baseline of roughly what we = have today. Roman prefers option 2.=20 Option 0 The sender can send the 4733 DTMF events at the time it feels most = appropriate and if their is in band DTMF tones, it SHOULD suppress the = in-band DTMF tones. (note a browser would never have in-band tones it = needed to supress)=20 Option 1 The sending endpoint MUST send silence in audio during the times that = DTMF tones are being sent.=20 Option 2 The sending endpoint MUST not send any audio packet for he times that = DTMF tones are being sent. The sender would do this by sliding the start = of the DTMF tones forward (or backwards) until it aligned with the = boundary of audio packet. The gaps between DTMF tones would be expanded = to make the the DTM tones end on the boundary of an audio packet. The = appropriate audio packets would then be suppressed. I suspect that for = things like an ATA, it would be even more complicated in that one would = need to make sure that if a DTMF tone start was slid forward, the = appropriate in band audio signal in the first packet got surpassed in = some way.=20 I have not looked at the code path for FF and Chrome but I suspect they = handle sending tones much like the IP phones in that the path of the = DTMF is pretty much independent from the path for the audio. Given they = are detection inland audio tones and replacing them it seems reasonable = that the current implication behave more like an IP phone than a PSTN GW = or ATA.=20 From nobody Tue Feb 2 13:27:42 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB211B3176 for ; Tue, 2 Feb 2016 13:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-_vLivjA7DE for ; Tue, 2 Feb 2016 13:27:38 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C3411B2D34 for ; Tue, 2 Feb 2016 13:27:38 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u12LRbne083047 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 2 Feb 2016 15:27:37 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: rtcweb@ietf.org References: <7A1D1E34-713A-4E21-B10A-39AD08EACCAB@iii.ca> From: Adam Roach Message-ID: <56B11F49.30209@nostrum.com> Date: Tue, 2 Feb 2016 15:27:37 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <7A1D1E34-713A-4E21-B10A-39AD08EACCAB@iii.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Summary of DTMF Issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 21:27:40 -0000 On 2/2/16 12:20, Cullen Jennings wrote: > Issue 1 - DTMF A-D > For the record, I am of the opinion -- although only weakly -- that we should go ahead and require support for these specific four tones in WebRTC browsers. > -------------- > > Issue 2 - Which spec should some of the things be in This one is a little tricky. While I understand questions around SDO ownership of decisions, I think the dominating factor here should be the document constituencies. The IETF documents are of use to people implementing browsers, WebRTC devices, and WebRTC-compatible devices. The W3C documents are aimed at people creating browsers as well as people writing webapps. I would not expect webapp developers to ever check the IETF documents, nor would I expect WebRTC devices to check W3C's API documents. Following this principle to its conclusion: those things that are applicable to webapps need to be in the W3C documents; those things that are applicable to WebRTC devices need to be in the IETF documents, and those things that apply to both need to be repeated in both sets of documents and rigorously consistent with each other. > Right now the normative text on tone duration and gaps between tones is in the W3C spec. Roman thinks what the text says is correct but it is in the wrong specification and should instead be normatively defined in an IETF spec (and the W3C spec can point at that or have a non normative summary of it) I think this is fine, but note that the API has clamping and default behavior based around these timing values. We don't want to change the API behavior, only the document that is authoritative for the timing values. > ----------------- > > The 3rd issues the biggest issue and has to do with when events are sent and if audio is suppressed while the events are being sent. > > ... > > Roman would like to reduce the variance of what senders are allowed to do. This proposal applies just as much to SIP or any other applications of 4733 and is not specific to WebRTC. Doesn't that really point to this being an issue for a different WG? > I’m going to outline 3 options. Option 0 is not what Roman wants to do but I include it just as a sort of baseline of roughly what we have today. Roman prefers option 2. > > Option 0 > > The sender can send the 4733 DTMF events at the time it feels most appropriate and if their is in band DTMF tones, it SHOULD suppress the in-band DTMF tones. (note a browser would never have in-band tones it needed to supress) > > Option 1 > > The sending endpoint MUST send silence in audio during the times that DTMF tones are being sent. > > Option 2 > > The sending endpoint MUST not send any audio packet for he times that DTMF tones are being sent. The sender would do this by sliding the start of the DTMF tones forward (or backwards) until it aligned with the boundary of audio packet. The gaps between DTMF tones would be expanded to make the the DTM tones end on the boundary of an audio packet. The appropriate audio packets would then be suppressed. I suspect that for things like an ATA, it would be even more complicated in that one would need to make sure that if a DTMF tone start was slid forward, the appropriate in band audio signal in the first packet got surpassed in some way. Option 2 seems almost unimplementably complex. It also has the property of being what no one does today; so even if it were as easy to implement as the others, it would maximize the amount of work necessary to bring implementations into compliance. Option 1 seems to defeat the use case -- which I find useful -- that allows conference participants to send DTMF to a focus without having their voice audio unnecessarily suppressed. Option 0 is, as you say (and my experience is consistent with this) the status quo. Your description doesn't outline any concrete issues with this mode of operation, so it's not clear why any IETF WG would seek to change things. I mean, "here's how things work right now, there's nothing broken about it, should we continue to do it?" doesn't seem like a compelling rallying cry. Can you expand -- or get Roman to expand -- on the rationale for wanting to change the current behavior? > I have not looked at the code path for FF If you find a DTMF-sending code path for Firefox, please let me know. /a From nobody Tue Feb 2 20:16:36 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF7E1A0250 for ; Tue, 2 Feb 2016 20:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhirZID-MUy7 for ; Tue, 2 Feb 2016 20:16:33 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1A61A0222 for ; Tue, 2 Feb 2016 20:16:33 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id f81so42203001iof.0 for ; Tue, 02 Feb 2016 20:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UCNDiDZF1mFQhI1zmhkriP6/IKUHIs/3Xp9Ei9p5ZT4=; b=XBPp8BYpPgrhJk76pIsxxk23raNXWnUyg9YPRakUCuXOL9I2PUJ3zOtlB+YM2FjM9n vJOlU+jk4fzsr+F0f6VN/ANJTRnUiOBpc8LxwktyrZsMvqjAfeEoK4CP1wQi60R70EMj NYs/O2nGhTb7thdAAqvDXswDSML7t85UFTZ2XNcEpuG2cQmPs8xpqX7LTqd+siBuZqUa Uh256CL8bk3N8BTLhxATC/7u1TVLQGvZGrTI8vCheYY2kkh8Sro36xGDs8wsLO1fMToV KtBCkhiGgmOKKht/g+Z+jpXVvcHXECV91SA00uGZ4PehS5GWfHsMLGcKUZiKEtUv3Ef3 X0Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UCNDiDZF1mFQhI1zmhkriP6/IKUHIs/3Xp9Ei9p5ZT4=; b=JA8xk2eTqzUP/qunpyODthTa7q29fL15M1sV1UNWQ2RUq5weHlbF82MCbTKgDEjlPt YyJvYJt6hio21zpzgnErK2lRJTtA1TRli5aRhNLmT19GyaPECNoeistkSJajZhWPyxUl mhuuDCB0uQ4BZ3pZoBJIzJROjy94/4H/MdxDh9NNhH5MC0/Al0PNDCoxfjduC/YnDALw iRtU7d9I94ApVdaJBdUB8nAHAWq+LkHaHnekXeIFipn/zbljCspM7/SnWsPo/NFkI2pj 8KWKXp8j4rGihLAAD808gBceBS/jHJ1JkGARFfCYgvQuJ4NaT6JYt98jySDLvEySQhWR cIXA== X-Gm-Message-State: AG10YOTEF9+CghO5HbWOuPErk+Yh58iaQdlZdzNSVRI5aqzCuiiOiWN1eMTFb2eD8a7KqtAJ63MW+YwZ9YXemQ== MIME-Version: 1.0 X-Received: by 10.107.33.14 with SMTP id h14mr1330780ioh.108.1454472993108; Tue, 02 Feb 2016 20:16:33 -0800 (PST) Received: by 10.36.149.130 with HTTP; Tue, 2 Feb 2016 20:16:33 -0800 (PST) In-Reply-To: <56B11F49.30209@nostrum.com> References: <7A1D1E34-713A-4E21-B10A-39AD08EACCAB@iii.ca> <56B11F49.30209@nostrum.com> Date: Wed, 3 Feb 2016 15:16:33 +1100 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Summary of DTMF Issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 04:16:35 -0000 On 3 February 2016 at 08:27, Adam Roach wrote: >> Issue 1 - DTMF A-D >> > > For the record, I am of the opinion -- although only weakly -- that we > should go ahead and require support for these specific four tones in WebRTC > browsers. This costs us little to specify and implement. If it is useful, then it will have been worth it. And if it's a latent footgun, then we can put it in the pile with all the others. >> Issue 2 Like Adam, I don't mind if the normative text is moved as long as it remains correct. >> Issue 3 Option 0 please. From nobody Thu Feb 4 02:47:20 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CE01A7021 for ; Thu, 4 Feb 2016 02:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jb_yCXH3HleV for ; Thu, 4 Feb 2016 02:47:17 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49CFD1A7015 for ; Thu, 4 Feb 2016 02:47:16 -0800 (PST) Received: (qmail 54518 invoked from network); 4 Feb 2016 10:47:14 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 3829 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 4 Feb 2016 10:47:14 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 87E2B18A021A; Thu, 4 Feb 2016 10:47:14 +0000 (GMT) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 7791718A0846; Thu, 4 Feb 2016 10:47:14 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 6839E18A021A; Thu, 4 Feb 2016 10:47:14 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Panton In-Reply-To: <7A1D1E34-713A-4E21-B10A-39AD08EACCAB@iii.ca> Date: Thu, 4 Feb 2016 10:47:13 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <38923C2E-659E-4E72-BCE9-624BF30946B1@phonefromhere.com> References: <7A1D1E34-713A-4E21-B10A-39AD08EACCAB@iii.ca> To: "" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [rtcweb] Summary of DTMF Issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 10:47:19 -0000 >=20 > Option 2 >=20 > The sending endpoint MUST not send any audio packet for he times that = DTMF tones are being sent. The sender would do this by sliding the start = of the DTMF tones forward (or backwards) until it aligned with the = boundary of audio packet. The gaps between DTMF tones would be expanded = to make the the DTM tones end on the boundary of an audio packet. The = appropriate audio packets would then be suppressed. I suspect that for = things like an ATA, it would be even more complicated in that one would = need to make sure that if a DTMF tone start was slid forward, the = appropriate in band audio signal in the first packet got surpassed in = some way.=20 >=20 I=E2=80=99m not keen on this. (Assuming I understand it correctly) -=20 My worry is that recipients that don=E2=80=99t care about DTMF now have = a discontinuous audio stream - their jitterbuffers and clock de-skews = may try to _fix_ unless they understand DTMF. Which leads to the situation I=E2=80=99ve = been trying to avoid - i.e. that every webrtc babymonitor has to = understand DTMF, just so=20 it can ignore DTMF correctly. Please tell me I am wrong. Tim. From nobody Thu Feb 4 04:29:19 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF381B2E04 for ; Thu, 4 Feb 2016 04:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.047 X-Spam-Level: * X-Spam-Status: No, score=1.047 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toevYLdtttwo for ; Thu, 4 Feb 2016 04:29:17 -0800 (PST) Received: from smtp81.iad3a.emailsrvr.com (smtp81.iad3a.emailsrvr.com [173.203.187.81]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7501B2E03 for ; Thu, 4 Feb 2016 04:29:17 -0800 (PST) Received: from smtp3.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp3.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A2285300473; Thu, 4 Feb 2016 07:29:16 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp3.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 34FA330049C; Thu, 4 Feb 2016 07:29:16 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from rtp-vpn6-1416.cisco.com ([UNAVAILABLE]. [173.38.117.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Thu, 04 Feb 2016 07:29:16 -0500 From: Cullen Jennings Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Feb 2016 11:16:29 -0400 Message-Id: To: "" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Harald Alvestrand Subject: [rtcweb] Clarification in draft-ietf-rtcweb-transports-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 12:29:18 -0000 I think we need to make the ALPN a bit more explicit. We agreed to = include the ALPN header so that a proxy knows it might receive video = packet rates tunnelled across it. However the text on this is not 100% = clear. Right now it says If it does so, it MUST support the "ALPN" header as specified in [RFC7639], But some people have posted out including this header is optional in = 7639 so there might be some ubiquity here about what is meant. I think = we should change the word =E2=80=9Csupport=E2=80=9D to =E2=80=9Cinclude=E2= =80=9D to make it clear this needs to be sent to the proxy so that it = would read If it does so, it MUST include the "ALPN" header as specified in [RFC7639], I believe that correctly reflects what we intended on this. There is no = requirement for the proxy to understand or do anything with this header. = Old proxies will just ignore it and cary on as if it was not there.=20 Cullen (with my individual contributor hat on) From nobody Thu Feb 4 07:49:41 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AD51B31E2 for ; Thu, 4 Feb 2016 07:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EBg-ngo3ACS for ; Thu, 4 Feb 2016 07:49:37 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BECC1B31E1 for ; Thu, 4 Feb 2016 07:49:37 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id u30so44655146qge.1 for ; Thu, 04 Feb 2016 07:49:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=UTY9pLdjFurIQ12cX9YguWLPP7SbqJ0n/RkN6nOe+NU=; b=dQJRYr8/EcRbEHvRUhtrmtL3kmJir5Sf0VupaWel1YePsfFuCcFpAsejYcb+qozrKL Ds06I9azIN2yY3qgkpHaUyCb+jgjDz9uwLEPvgNw/7XWq+VLkqT9y0EKfv7tmg3Y7Z3N uVsGRBijPnazSQiseK/to3HqoDKlnBujSLC4ze6Dby40PH8eRTM2UGm6pGXNf63MJ/79 PoXMURpZw0vU7QrvsJmLcHuUBLkRdTlTi+916EE8+UGIUMrNZmtfQDigjHvPnAq4KE75 uB9QkoYfCDsVpHLJ3i4oeZClED0A8xVHjFdFgkRBkrr9gNIUoe1PfHe2ujAUme7/p9sy dW1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=UTY9pLdjFurIQ12cX9YguWLPP7SbqJ0n/RkN6nOe+NU=; b=m5Y37YY+w93dYE/K4J4wpttzr3MfBKALzZ7grDcjemB//pYxz2CW54CChqNy1orFmz MhHj7cAw4KlKpmlhFTwdIimdZkSeU8Snx2Bs3183bYPfzIFy9qqWujgkJVTHyNBOLfYw bKgn7117EMaUD8lPh0/hGzNhfgR0ai5WuIhLj6dvSAJUZyNS1iuBYRw7J4MGZuCfx8zi c2Wxg4esMM05wSndBxbY48x3m/RO3YICx+po6WDJI4OX+hGtsgVBg+yxeoCF83x2UhMf kz0gazXuk7jA8ewtw0P3c1cgLsGJbzpzRLlNCW5GRGNJvVgf0Z2cHOgQSLUEu/v8dn55 O6LA== X-Gm-Message-State: AG10YORqMTk++d8hUTQxLmAgPU7noSEIbVScucg7PhqeyzASgSAFSk9UT23I2LXbLmp33HVT X-Received: by 10.141.4.139 with SMTP id g133mr10378499qhd.34.1454600976652; Thu, 04 Feb 2016 07:49:36 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable121.240-21-96.mc.videotron.ca. [96.21.240.121]) by smtp.gmail.com with ESMTPSA id e187sm5425097qka.1.2016.02.04.07.49.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 07:49:35 -0800 (PST) To: Cullen Jennings , "" References: <7A1D1E34-713A-4E21-B10A-39AD08EACCAB@iii.ca> From: Jean-Marc Valin X-Enigmail-Draft-Status: N1110 Message-ID: <56B3730E.5070404@mozilla.com> Date: Thu, 4 Feb 2016 10:49:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <7A1D1E34-713A-4E21-B10A-39AD08EACCAB@iii.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Summary of DTMF Issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 15:49:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Issue 1 - DTMF A-D I have a weak preference for including A-D since it seems simple enough. > Issue 2 - Which spec should some of the things be in No strong opinion here beyond "please let me know what I need to add to the draft". > The 3rd issues the biggest issue and has to do with when events > are sent and if audio is suppressed while the events are being > sent. I strongly prefer Option 0 here. I don't think options 1 and 2 can be implemented reliably enough to be useful and Option 0 has the advantage of clean audio in the case where the sender only sends DTMF as events (e.g. for videoconferencing bridges as you mentioned). One thing to consider about options 1 and 2 is that using a codec like Opus (though it's also possible with G.711), the frame size can go as low as 2.5 ms, making it nearly impossible to detect tones before they are long enough for the receiver to also detect them from the in-band audio. So I'm fine with "SHOULD suppress the in-band DTMF tones" (when possible), but making it a MUST would just not work. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWs3MLAAoJEJ6/8sItn9q9DDgH/2YJz0g6jTAzjTEpbgknqu7u BgE4j7+IZyelgpI4+I3SaoYqIemmBEUrO2gRomyl7PXkYASwL7P9p5N6AkIfsBgo kvCwPF05tSf+feQOUfnt6ycfVabDUwbZmznC7KtS5FomBu0DSnutRFrlkr9NN3+Z W6nJpSAYA0XH3r2n5x4cj5ImKce1ZKVOKbkTJXJsuNcBUtzhh8c/ViQktup45+ty lwX8E8279wskF+3rD34gV1ojf8vquBkovuvG+fHiquADWxnnbsgEN/nKkHxNwYho Lzt3GalmbP2Hb90wDzQ/lcJATpvMqKLf3AOmOZOTz9LH+QbqIX+fPEDvDheubT0= =yW7L -----END PGP SIGNATURE----- From nobody Thu Feb 4 07:59:20 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723D01B3207 for ; Thu, 4 Feb 2016 07:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAYtRSwOVZHr for ; Thu, 4 Feb 2016 07:59:18 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 103371B3088 for ; Thu, 4 Feb 2016 07:59:18 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id r207so44654961ykd.2 for ; Thu, 04 Feb 2016 07:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H1pjDIw0UQXDTqiuRCMJIU6MBPNt8+M/m7mpSic6tI4=; b=VbdHYoGWVZYrJ+Mh/nbb/vkUpWYLZXmqbiuOM/0cGyYMTsbfPY3fGWdw+TEQlA2AtI JiiiXgWMBLXO1vRFkfi8YwyJZdwHaWm8G/CNxoaI16BGezzX6r6yzkpzUdvrCP+ClmeE kAP4sipQn+LRTTikzPjxOZOsK+05wwURCSYIz5mUs76aAmWy6fmqHRqwX+EildnulPPl Zd+1Bal3SF8jNAbrXM/BL7DSd4IuxBbT3Es9CoRpj07IHP+dBqO0xGZa21ORaRekwfF1 huWsXdDmRBIuPELrfRHU+LvOaf+0xneaW2Q5CF1Ukyy4LAD+m4XDT9u0AX/S+Zf/Ken1 L3Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=H1pjDIw0UQXDTqiuRCMJIU6MBPNt8+M/m7mpSic6tI4=; b=hkGxwtNiLY3/ofuJNF6O3ORO0A5EkqMW0vu0D6sCVKLcmpjuILhelJXyzNB8EzQuSp 10M1JVENvdeWFPGj4e3I7Ei8RoHSyyDuonApWwNkjiO7VQvmxsQ4DM4IZV46h7EitS52 s47DSmSpsGdvW2M+eHDlYl4lqHwLcGecI9E0lN7LI0eV0BWisc+HKU6SVaLUop76cGj7 xXaFHpNcxm5rQ+eghwe+NrcrgmUKPEtsRS2keAHwn6mYTeAuoHGfkS1Lp+KY1yzjjKg0 R0YB0oI1WhesqC2PrRc8PiOj3agpqGjrLzodrnmAlrFdfKp+4U1ly7jX6+3/JeUC+SJd PJlA== X-Gm-Message-State: AG10YOSVk1YCb+kZ1eBlvomb/HQtUQrRg1sWg6w/6a1h1CNucmC4pzcmjzXq0Cj7E7ni9hQXa7Z/br6mkUA8mw== X-Received: by 10.37.24.195 with SMTP id 186mr4061733yby.162.1454601557385; Thu, 04 Feb 2016 07:59:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 4 Feb 2016 07:58:38 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 4 Feb 2016 07:58:38 -0800 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a114159b61e5910052af3d151 Archived-At: Cc: Harald Alvestrand , "" Subject: Re: [rtcweb] Clarification in draft-ietf-rtcweb-transports-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 15:59:19 -0000 --001a114159b61e5910052af3d151 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 3, 2016 at 7:16 AM, Cullen Jennings wrote: > I think we need to make the ALPN a bit more explicit. We agreed to includ= e > the ALPN header so that a proxy knows it might receive video packet rates > tunnelled across it. However the text on this is not 100% clear. Right no= w > it says > > If it does so, it MUST support the "ALPN" header as > specified in [RFC7639], > > But some people have posted out including this header is optional in 7639 > so there might be some ubiquity here about what is meant. I think we shou= ld > change the word =E2=80=9Csupport=E2=80=9D to =E2=80=9Cinclude=E2=80=9D to= make it clear this needs to be > sent to the proxy so that it would read > > If it does so, it MUST include the "ALPN" header as > specified in [RFC7639], > > I believe that correctly reflects what we intended on this. There is no > requirement for the proxy to understand or do anything with this header. > Old proxies will just ignore it and cary on as if it was not there. > I wouldn't have a problem with this if it were restricted to browsers. However, we don't want to careful about retroactively branding endpoints which aren'= t browsers but can talk to WebRTC clients as noncompliant. Maybe this is like codecs where they are "WebRTC Compatible"? -Ekr Cullen > > (with my individual contributor hat on) > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a114159b61e5910052af3d151 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 3, 2016 at 7:16 AM, Cullen Jennings <<= a href=3D"mailto:fluffy@iii.ca" target=3D"_blank">fluffy@iii.ca> wrote:
I think we need to make the AL= PN a bit more explicit. We agreed to include the ALPN header so that a prox= y knows it might receive video packet rates tunnelled across it. However th= e text on this is not 100% clear. Right now it says

=C2=A0 =C2=A0If it does so, it MUST support the "ALPN" header as<= br> =C2=A0 =C2=A0specified in [RFC7639],

But some people have posted out including this header is optional in 7639 s= o there might be some ubiquity here about what is meant. I think we should = change the word =E2=80=9Csupport=E2=80=9D to =E2=80=9Cinclude=E2=80=9D to m= ake it clear this needs to be sent to the proxy so that it would read

=C2=A0 =C2=A0 If it does so, it MUST include the "ALPN" header as=
=C2=A0 =C2=A0specified in [RFC7639],

I believe that correctly reflects what we intended on this. There is no req= uirement for the proxy to understand or do anything with this header. Old p= roxies will just ignore it and cary on as if it was not there.

I wouldn't have a problem with this if it were = restricted to browsers. However,
we don't want to careful abo= ut retroactively branding endpoints which aren't
browsers but= can talk to WebRTC clients as noncompliant. Maybe this
is like c= odecs where they are "WebRTC Compatible"?

-Ekr

Cullen

(with my individual contributor hat on)


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a114159b61e5910052af3d151-- From nobody Thu Feb 4 10:38:04 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FD71ACD1D for ; Thu, 4 Feb 2016 10:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFk0V7psXxXC for ; Thu, 4 Feb 2016 10:38:02 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60DA31ACD11 for ; Thu, 4 Feb 2016 10:37:57 -0800 (PST) Received: by mail-qg0-x232.google.com with SMTP id o11so48870410qge.2 for ; Thu, 04 Feb 2016 10:37:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=DOGhoRavURTCsGvhv4bG3WlGIynCIOeZE2j7J2RE9Cw=; b=f8julhIoIChGeRp1ONXvof//Z+HLjB+aVXnndNpXmvXYPUq8gNB40yv0uKcp9AdFEz 2RVlwHXM6uKuw9TSQ9Gh/vtwjOT6pwGkpXcTrhwFQK919bU1j7BiulCqF9ZXZlhIg8gn Ybmt5lFKqyMOH19ha7ZjqDUWvuBSzI7tMWhoqF5ClQ12vJ8FK8bv8OS7uW5lMWVg1OHt yvOEJwz65JPzRZ/0ZtZHMmcNxQ8oMVWFthd2RdSpQRA/2qKkgKlpnsF+LuYMHgiC/o4y myhxJjH75qQKHhNZf5PfKWzgZysg5OLWb4XbiV2/m8InNOYDWhXkGi1+sAT6dDGFwRBy nyGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=DOGhoRavURTCsGvhv4bG3WlGIynCIOeZE2j7J2RE9Cw=; b=Iju1tPXvZW/ZsLRQgkCQVhzVIVIN9qKOFG8LYrPI/dPTSZuwqueTIWOuaBeXZamOSm GNtIxJ3ezZ6j5hZ9JqVoD5CFFH1OWZAmlFhD+eatHQOx6+KsBqxbKtI4QqaGW5cbsk/o B3/nZ8U7Fnoxaj7xNbc6mr/+Ggmdv1qHrEnIJPzCc0LSNCxu8Ogm22mjFAAWONYFZPOa FUF7tfiLqwHkVTrxZu0G0mGLBJgE1ivgX2hE0aW1FiA/VBcHrfXAHdKQWOoLgjeFSyHJ IEBL8R1LGf7UrN7aMnX1RLOoG6lZjM2GyC2YZBlWM+HV8NSRw+ek+AkX7w+KEFTybWm/ FSgg== X-Gm-Message-State: AG10YOS6bYFlIxtYkxGo0DuCruk4pmCAChtYU+4YZ3vv99PHnaXNsuOaLjjauDVjCJayoj2VSA/PjKCIR5D6GA== X-Received: by 10.141.28.149 with SMTP id f143mr11599950qhe.66.1454611076609; Thu, 04 Feb 2016 10:37:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Thu, 4 Feb 2016 10:37:37 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Thu, 4 Feb 2016 10:37:37 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a11422e8e81fa39052af60815 Archived-At: Subject: Re: [rtcweb] Updated doodle poll link X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 18:38:03 -0000 --001a11422e8e81fa39052af60815 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 1, 2016 at 8:56 AM, Ted Hardie wrote: > Here is the updated link with timezone selection enabled: > > http://doodle.com/poll/7vq4u4yyf3sdmgn4 > > regards, > > Ted > =E2=80=8BThere are currently ten or so replies to the poll, and we'd like t= o have more before making a decision. Please fill the poll in by Friday, February 12th, 2016. thanks! Ted=E2=80=8B --001a11422e8e81fa39052af60815 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 1, 2016 at 8:56 AM,= Ted Hardie <ted.ietf@gmail.com> wrote:
Here is the updated link with tim= ezone selection enabled:

http://doodle.com/poll/7vq4u4yyf3sdmgn4
<= br>
regards,=

Ted=

=E2=80=8BThere = are currently ten or so replies to the poll, and we'd like to have more= before making a decision.=C2=A0 Please fill the poll in by Friday, Februar= y 12th, 2016.

thanks!

Ted=E2=80=8B
=C2=A0

--001a11422e8e81fa39052af60815-- From nobody Thu Feb 4 16:01:16 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988B91ABC75 for ; Thu, 4 Feb 2016 16:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ojauki4xnZYl for ; Thu, 4 Feb 2016 16:01:12 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0921A9300 for ; Thu, 4 Feb 2016 16:01:11 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id 5so3165548igt.0 for ; Thu, 04 Feb 2016 16:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pWSqKrvI0dr1mazZoXBOpl+VlQAMbjPvf2NzjkoCwqQ=; b=y0fe1a0CHuRI2dmCrOsqiUGVn1H0sNweESATsTkm83Xh7zMj36D3tM3o0U3c19evwT tCLsrsUWRcw2bXTJMvYj3gcTc856JIkmFaxO0qdBv2hUzn9DwsjIUs+y452HZVV7jThH olc5HGD3frZpHS0H9F1A9H8TtdbHN2Epom8ONn4CSQwVLBtG+ZgJicfPPc4FVgIQj1Fg 6tYJMb/RfaQi7L3CF63uKkknYKeDkX36duy3wFPV0PDSgYb0rE3edj5lQ/N/YYdzGDx/ ea5swc/igBFgYvQFSmljZ1MTMm9GM9qhJOwFwa17/9D+vB9Ik/2TEFK5kCTTgQiXRJGD V9dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pWSqKrvI0dr1mazZoXBOpl+VlQAMbjPvf2NzjkoCwqQ=; b=E/A07T3kBKBOAuZrbSQ82HQJCkZ7xhzTwI8+XC5P+TBc/21O4GvKm0hpWdAB/EWM3v /QiTPlTDaQdYAecyZo78StrvucqwrbswqH3T3sJaj8MQDPDOcgntYjQZFdPDyB6qtUZp kFuUcezEw7Q6oTFeCnMcsGo/LXPoBNY9UCONBMtXSU5+uJQpA4oQnzCY7VxuqcT0fsju kp5BvXtYyGR8+9hSpnDuItZ3cGjK5PCsxMi+97pv8yY30KbDFRMCKU29mGiITNLoBEbv 5Fnac2V85+nMdl5Kui7kLHqW4vVLWbXAIZZ/WYdeCpgBVBCBhWGYs8bqsiNysDnnTLwi YTdQ== X-Gm-Message-State: AG10YOTh4EXtVUgPDU1RKbBpQk/I3dBnC+t2jqTcXZgKjKceJ8MXNKrxHvcgBCL6l2pvYQ== X-Received: by 10.50.67.111 with SMTP id m15mr5059226igt.65.1454630471259; Thu, 04 Feb 2016 16:01:11 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com. [209.85.213.169]) by smtp.gmail.com with ESMTPSA id m32sm5770280ioi.41.2016.02.04.16.01.09 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 16:01:09 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id xg9so3057051igb.1 for ; Thu, 04 Feb 2016 16:01:09 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.43.136 with SMTP id w8mr12334940igl.96.1454630469028; Thu, 04 Feb 2016 16:01:09 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 4 Feb 2016 16:01:08 -0800 (PST) In-Reply-To: <7A1D1E34-713A-4E21-B10A-39AD08EACCAB@iii.ca> References: <7A1D1E34-713A-4E21-B10A-39AD08EACCAB@iii.ca> Date: Thu, 4 Feb 2016 19:01:08 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=089e011602a862d76c052afa8c79 Archived-At: Cc: "" Subject: Re: [rtcweb] Summary of DTMF Issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 00:01:15 -0000 --089e011602a862d76c052afa8c79 Content-Type: text/plain; charset=UTF-8 Cullen, Thank you very much for your great summary. Here is a bit more details/information from me. *1) Support for A-D (been much discussed). This may be the least important* I am in favor of supporting this even though this is not as important to me as it might seem. I have done a comprehensive test of A-D DTMF tone support by US and Canada phone operators. Based on my test DTMF A-D tones are universally supported. Here are more details for those who are interested: During this test I got two geographic numbers from two US CLEC (competitive local exchange carrier), one geographic number from Canadian CLEC, and toll free numbers from AT&T, MCI/Verizon and Level3. All of those numbers were terminated to my IVR equipment via VoIP trunks configured with these carriers. Calls to the first US CLEC number can terminate via LEC PSTN switch but most of the time, since this CLEC also provides local tandem and long distance service are terminated via direct interconnect with long distance carrier. This means that call is often transmitted VoIP from origination to termination typically going though several SBCs due to the magic of least cost routing. Calls to the second US CLEC number and calls to Canadian CLEC always go through LEC PSTN switch and CLEC VoIP gateway. Calls to AT&T toll free numbers are handed over to AT&T legacy long distance network and then go through a VoIP gateway before being handed over to my equipment. Calls to MCI/Verizon and Level3 toll free numbers go through more modern long distance network and can be transmitetd via VoIP or hit PSTN interconnects and VoIP gateways. I have placed test calls using wholesale VoIP trunks through the following long distance carriers (pretty much everybody): 360Networks, 382com, ANI Networks, ANPI, AT&T, Brightlink, Broadvox, CenturyLink, Comcast, Comcast PSTN, Earthlink, GlobalCrossing , Hypercube, Impact Telecom, Intelepeer, Intelepeer PSTN, Inteliquent, ISPTelecom, Level3 IP, Level3 PSTN, O1, Onvoy, Peerless, Puerto Rico Telephone, Teliphone, TNCI, Verizon, Windstream Both inbound and outbound configurations are typical of how VoIP phone service operators or IVR and conferencing providers get their phone numbers or terminate outbound calls. Enterprises typically go through an additional hosted PBX or trunk management system, but this should not change DTMF support. During the test my IVR test system would place a call, wait for welcome prompt to finish playing, send DTMF digits *1234567890ABCD# and wait for the test system to send the same digits back. Based on this test, all DTMF digits, including A-D were successfully transmitted in both directions. Based on the variety of inbound and outbound carriers tested, this should demonstrate that majority of US long distance operators and their interconnects support A-D DTMF digits. ___________________________________________ *2) Which specification certain things are specified in* I specifically referred to https://www.w3.org/TR/webrtc/#rtcdtmfsender The duration parameter indicates the duration in ms to use for each character passed in the tones parameters. The duration cannot be more than 6000 ms or less than 40 ms. The default duration is 100 ms for each tone. The interToneGap parameter indicates the gap between tones. It must be at least 30 ms. The default value is 70 ms. There are multiple ITU, ETSI and other normative documents that define DTMF tone and gap duration. I do not think there are any IETF documents that specify actual tone duration. I think it would be best to repeat this information in rtcweb-audio draft so that implementer will get the same consistent values from either document. This is why I propose to add the following text to rtcweb-audio: Generated events MUST have duration of no more than 6000 ms and no less than 40 ms with the recommended default duration of 100 ms for each tone. The gap between events MUST be no less then 30 ms with the recommended default duration of 70 ms. __________________________________________ *3) Timing of the DTMF event packets (this is probably the most important)* This is, indeed, the most important decision. First of all, webrtc end point should be able to receive any telephone-events. These events should be ignored (other than updating stats) and should not cause any problem like audio artifacts or stopped connections. Webrtc end point should be able to deal with discontinued audio transmission during these events. There is no mechanism to stop PSTN network from generating telephone-events or from controlling if non-event audio packets would or would not be sent during the telephone-event. During my test described earlier half of the providers sent audio during telephone-events and half did not. First decision that we need to make is regarding timing of the telephone-events. We can specify that: a. telephone-events should start and stop on regular non-event audio packet boundaries. b. telephone-events can start and stop at any time and send updates at any reasonable regular interval Option a. has a benefit of better interop with existing equipment, since in packet audio is suppressed on whole packet. It also more friendly to jitter buffers. Implementation option a. transmission logic is actually trivial and maps well on regular audio transmission algorithm. Here is one of the proposed algorithms: When sending an audio packet: 1. If not currently sending telephone-event or inter-tone gap audio, check if new telephone-event needs to be sent. If new tone is in the queue, remove it from the queue, set the already transmitted telephone-event duration to 0, record the telephone-event start timestamp and set the tone start flag. 2. Is sending a telephone-event, increment the transmitted telephone-event duration by ptime. Set duration in the telephone event packet with this duration. If tone start flag is set, set the mark bit on telephone event packet. If transmitted telephone-event duration is equal or greater then desired tone duration set the end of tone flag; schedule two re-transmissions of end telephone-event with small delay between each re-transmission (typically 5-10 ms); set transmitted gap length to 0; set start gap flag to true; and switch to send gap audio mode. Clear tone start flag. Send the telephone-event packet. 3. If sending a gap audio, increment the transmitted gap duration by ptime. If start gap flag is set, set the the mark bit on the packet. Send the audio packet of regular ptime length. Clear the gap start flag. If transmitted gap duration is greater then desired gap duration switch to normal audio transmission mode. Above described algorithm can work with or without audio being transmitted during the telephone-event. If audio is not sent during the telephone-event, codec state will need to be reset when gap audio is starting to be transmitted. If background audio and not silence is send during the telephone-event, mark bit does not need to be set when gap audio is started. Second decision is regarding what needs to be sent during telephone-event. There are 3 options here: a. Background audio b. Silence c. Nothing There are systems that implement all three options. Sending background audio is typically done by cheaper IP and soft phones. This is an easiest to implement but the lowest quality option. Background audio has a downside of reducing the DTMF tone recognizer performance if it gets rendered into in-band audio by the gateway and get's combined with generated DTMF tone. For DTMF recognizer background audio is basically noise. Furthermore, a lot of DTMF keypad implementations play DTMF tone as a feedback to the user. This applies to some WebRTC DTMF keyboards as well, where an audio file with DTMF tone is played to the user when the keypad digit is played. This is causing double DTMF issues already. Furthermore, I am not aware of any conferencing systems that renders audio during the telephone event into the mixer. Most conferencing systems are configured to suppress this audio since it is either DTMF or sound of persons finger punching the conference phone microphone when dialing the digits. Silence is commonly used by a lot of gateways and SBCs. For a lot of SBCs and gateways sending silence or no audio packets is a configuration option. In essence, they treat sending no audio packets as discontinuous transmission, since audio during telephone-event is assumed not being rendered by the terminated gateway. Thus, it is omitted due to being completely redundant. Main argument for sending nothing are things that Olle brought up in https://www.ietf.org/mail-archive/web/rtcweb/current/msg02963.html . The problem is that some gateways do not handle telephone-events for the same timestamps as audio and discard packets in random. Based on my testing this does not occur with any of the carriers that I am using, so this is likely fixed. Systems I build and operate typically do not send packets when sending telephone events and use above described algorithm to align telephone-events and audio packets. This seems to work well with wide selection of carriers and equipment. This is why I prefer this option, but I am not dead set against other options. We routinely test DTMF transmission performance to our conferencing service across multiple carriers in over 60 countries and I am willing to do an interop test to see how well the options we pick will perform. Regards, _____________ Roman Shpount --089e011602a862d76c052afa8c79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cullen,

Thank you very much = for your great summary.
Here is a bit more details/information fr= om me.

1) Support for A-D (been much discussed). Thi= s may be the least important

I am in favor of supporting this even though this = is not as important to me as it might seem.

I have done a comprehensive test of A= -D DTMF tone support by US and Canada phone operators. Based on my test DTM= F A-D tones are universally supported. Here are more details for those who = are interested:

During this test I got two geographic numbers from two US CLEC (c= ompetitive local exchange carrier), one geographic number from Canadian CLE= C, and toll free numbers from AT&T, MCI/Verizon and Level3.

All of those numb= ers were terminated to my IVR equipment via VoIP trunks configured with the= se carriers.

Calls to the first US CLEC number can terminate via LEC PSTN switch = but most of the time, since this CLEC also provides local tandem and long d= istance service are terminated via direct interconnect with long distance c= arrier. This means that call is often transmitted VoIP from origination to = termination typically going though several SBCs due to the magic of least c= ost routing.

Calls to the second US CLEC number and calls to Canadian CLEC always= go through LEC PSTN switch and CLEC VoIP gateway.

Calls to AT&T toll free nu= mbers are handed over to AT&T legacy long distance network and then go = through a VoIP gateway before being handed over to my equipment.

Calls to MCI/Ver= izon and Level3 toll free numbers go through more modern long distance netw= ork and can be transmitetd via VoIP or hit PSTN interconnects and VoIP gate= ways.

= I have placed test calls using wholesale VoIP trunks through the following = long distance carriers (pretty much everybody): 360Networks, 382com, ANI Ne= tworks, ANPI, AT&T, Brightlink, Broadvox, CenturyLink, Comcast, Comcast= PSTN, Earthlink, GlobalCrossing , Hypercube, Impact Telecom, Intelepeer, I= ntelepeer PSTN, Inteliquent, ISPTelecom, Level3 IP, Level3 PSTN, O1, Onvoy,= Peerless, Puerto Rico Telephone, Teliphone, TNCI, Verizon, Windstream

Both inbou= nd and outbound configurations are typical of how VoIP phone service operat= ors or IVR and conferencing providers get their phone numbers or terminate = outbound calls. Enterprises typically go through an additional hosted PBX o= r trunk management system, but this should not change DTMF support.=C2=A0

During = the test my IVR test system would place a call, wait for welcome prompt to = finish playing, send DTMF digits *1234567890ABCD# and wait for the test sys= tem to send the same digits back. Based on this test, all DTMF digits, incl= uding A-D were successfully transmitted in both directions. Based on the va= riety of inbound and outbound carriers tested, this should demonstrate that= majority of US long distance operators and their interconnects support A-D= DTMF digits.
_____________________________= ______________


2) Which specification certain things are specified= in

I specifically referred to https://www.w3.org/TR= /webrtc/#rtcdtmfsender

The duration parameter indicates the duration = in ms to use for each character passed in the tones parameters. The duratio= n cannot be more than 6000 ms or less than 40 ms. The default duration is 1= 00 ms for each tone.

The interToneGap parameter indicates the gap be= tween tones. It must be at least 30 ms. The default value is 70 ms.

=
There are multiple ITU, ETSI and other normative document= s that define DTMF tone and gap duration. I do not think there are any IETF= documents that specify actual tone duration. I think it would be best to r= epeat this information in rtcweb-audio draft so that implementer will get t= he same consistent values from either document. This is why I propose to ad= d the following text to rtcweb-audio:

Generated events MUST = have duration of no more than 6000 ms and no less=C2=A0than 40 ms with the = recommended default duration of 100 ms for each tone. The gap between event= s MUST be no less then 30 ms with the recommended=C2=A0default duration of = 70 ms.

____= ______________________________________

3) Timing of the DTMF event packets (th= is is probably the most important)

= This is, indeed, the most important decision.

Firs= t of all, webrtc end point should be able to receive any telephone-events. = These events should be=C2=A0ignored (other than=C2=A0updating=C2=A0stats) and should not caus= e any problem like audio artifacts or stopped connections. Webrtc end point= should be able to deal with discontinued audio transmission during these e= vents. There is no mechanism to stop PSTN network from generating telephone= -events or from=C2=A0controlling=C2=A0if non-event audio packets would or w= ould not be sent during the telephone-event. During my test described earli= er half of the providers sent audio during telephone-events and half did no= t.

First decision that we need to make is regarding timi= ng of the telephone-events. We can specify that:

a. teleph= one-events should start and stop on regular non-event audio packet boundari= es.=C2=A0
b. telephone-events can start and stop at any time and send= updates at any reasonable regular interval

<= div>Option a. has = a benefit of better interop with existing=C2=A0equipment, since in packet a= udio is suppressed on whole packet. It also more friendly to jitter buffers= .

Implementation option a. transmission logic is actually = trivial and maps well on regular audio transmission algorithm. Here is one = of the proposed algorithms:

When sending an audio packet:=

1. If not currently sending telephone-event or inter-tone= gap audio, check if new telephone-event needs to be sent. If new tone is i= n the queue, remove it from the queue, set the already transmitted telephon= e-event duration to 0, record the telephone-event start timestamp and set t= he tone start flag.

2. Is sending a telephone-event, incre= ment the=C2=A0transmitted telephone-event duration by ptime. Set duration in the telephone event packet = with this duration. If tone start flag is set, set the mark bit on telephon= e event packet. If=C2=A0transmitted telephone-event duration is equal or greater then=C2=A0desired tone = duration set the end of tone flag;=C2=A0schedule=C2=A0two re-transmissions= =C2=A0of end telephone-event with small delay between each re-transmission = (typically 5-10 ms); set=C2=A0transmitted=C2=A0gap length to 0; set start g= ap flag to true; and switch to send gap audio mode. Clear tone start flag. Send the te= lephone-event packet.

3. If sending a gap audio,=C2=A0<= span style=3D"font-size:12.8px">increment the=C2=A0transmitted gap duration by ptime. = If start gap flag is set, set the the mark bit on the packet. Send the audi= o packet of regular ptime length. Clear the gap start flag. If transmitted = gap duration is greater then desired gap duration switch to normal audio tr= ansmission mode.

Above described algorithm can work with or without audio being transm= itted during the telephone-event. If audio is not sent during the telephone= -event, codec state will need to be reset when gap audio is starting to be = transmitted. If background audio and not silence is send during the telepho= ne-event, mark bit does not need to be set when gap audio is started.

Second decision = is regarding what needs to be sent during telephone-event. There are 3 opti= ons here:

a= . Background audio
b. Silence
c. Nothing

There are systems that implement all three options.

=
Sending backg= round audio is typically done by cheaper IP and soft phones. This is an eas= iest to implement but the lowest quality option. Background audio has a dow= nside of reducing the DTMF tone recognizer performance if it gets rendered = into in-band audio by the gateway and get's combined with generated DTM= F tone. For DTMF recognizer background audio is basically noise. Furthermor= e, a lot of DTMF keypad implementations play DTMF tone as a feedback to the= user. This applies to some WebRTC DTMF keyboards as well, where an audio f= ile with DTMF tone is played to the user when the keypad digit is played. T= his is causing double DTMF issues already.=C2=A0Furthermore, I am not aware= of any conferencing=C2=A0systems that renders audio during the telephone e= vent into the mixer. Most conferencing systems are configured to suppress t= his audio since it is either DTMF or sound of persons finger punching the c= onference phone microphone when dialing the digits.

Silenc= e is commonly used by a lot of gateways and SBCs.
<= font color=3D"#000000">
<= /div>
For a lo= t of SBCs and gateways sending silence or no audio packets is a configurati= on option. In essence, they treat sending no audio packets as=C2=A0disconti= nuous transmission, since audio during telephone-event is assumed not being= rendered by the terminated gateway. Thus, it is=C2=A0omitted=C2=A0due to b= eing completely redundant.
=
Main argument for sending not= hing are things that=C2=A0Olle=C2=A0brought up in=C2=A0https://www.ietf.org/mail-a= rchive/web/rtcweb/current/msg02963.html .=C2=A0The problem is that some gateways do not h= andle telephone-events for the same timestamps as audio and discard packets= in random. Based on my testing this does not occur with any of the carrier= s that I am using, so this is likely fixed.=C2=A0

Systems I build= and operate typically do not send packets when sending telephone events an= d use above described algorithm to align telephone-events and audio packets= . This seems to work well with wide selection of carriers and equipment. Th= is is why I prefer this option, but I am not dead set against other options= .=C2=A0We r= outinely test DTMF transmission performance to our conferencing service acr= oss multiple carriers in over 60 countries=C2=A0and I am willing to do an interop test to see= how well the options we pick will perform.=C2=A0

Regards,
__________= ___
Roman Shpount

--089e011602a862d76c052afa8c79-- From nobody Thu Feb 4 22:28:13 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F261B366B for ; Thu, 4 Feb 2016 22:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25Y1hinIJVSH for ; Thu, 4 Feb 2016 22:28:11 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0A11B366A for ; Thu, 4 Feb 2016 22:28:10 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id f81so118664071iof.0 for ; Thu, 04 Feb 2016 22:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qKDE5yMn3EDGBj5W+O9ZVb47qEAIO+WJ4KpUBRSrIIw=; b=retByaXL0peGQDyJ+NDHeSXpAza0zMqGcEfx/fFPRKea9Bb6VT6vAknF+YByod1akx y6tlybT+6nuAoAqjKLTdNwoibNwymYcTfkzI/FIDedXROQC4X4cE0MYZGKAPJdMttGQq +JdnmYUYKaqjdQDrpCZtN6oelQF3aJF1/X9LrXxL5z+lU/Fc3zrMg+SjzH3NXbHsfvja 94TxnNX6ZmGcxYlyCdh+XBqD0MlZlsskWi7CCk0jBCjUlwkLgtxlEfQegmJguYxruscd TK8vbQd8MHV1f5n0X38z4TPo6PKWCKzKkLCdPp4YiUc+xyF4qMGJGbQoNPJBkYFfYSXo WJ5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qKDE5yMn3EDGBj5W+O9ZVb47qEAIO+WJ4KpUBRSrIIw=; b=C2conBpbjzV2dSPUANMC2sDFTKuuwK0sKm9DxjIG0+rMrcNHpMfvwuufBkbsiyB64S 7N6cBqCnUNzoAbwzh2xEr78pTLYRd9cdA3P1f1iAp9z5YTOY/8RFV/h1vl2hc+n5PhtP E/QMTfmfQibu4UxrfC4Rw7LoFgGTUQbcYTSSIqzHL56ONi/GoifkLPjDmOHg1nX7hJGj IFJ3pIffaMhun2CIfPGxP4aqe0Fy8Q4ZFL6a1ELQxBVC5siQhpK4bAJza92qoS2lDEjD PlL5VcYsZY8g9rB6aY7l0yy79yYsLhJdU1yIWvmDlR9+iV10SahscSjDNdVPz1Gz6nHh nHGg== X-Gm-Message-State: AG10YOSMgLbfnPTFDure4E54zVc3sRK0Wvy75pq3t37yyDKgtfYgBnTXUEzSRVupibciHL3wM66xkayVeMYzNQ== MIME-Version: 1.0 X-Received: by 10.107.16.153 with SMTP id 25mr13809462ioq.100.1454653690224; Thu, 04 Feb 2016 22:28:10 -0800 (PST) Received: by 10.36.53.79 with HTTP; Thu, 4 Feb 2016 22:28:10 -0800 (PST) Received: by 10.36.53.79 with HTTP; Thu, 4 Feb 2016 22:28:10 -0800 (PST) In-Reply-To: References: Date: Fri, 5 Feb 2016 17:28:10 +1100 Message-ID: From: Martin Thomson To: EKR Content-Type: multipart/alternative; boundary=001a113edb167a587b052afff467 Archived-At: Cc: Harald Alvestrand , "" Subject: Re: [rtcweb] Clarification in draft-ietf-rtcweb-transports-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 06:28:12 -0000 --001a113edb167a587b052afff467 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think that Cullen's request is reasonable. I really don't understand the obsession with labeling. Branding something as less than 100% "compliant" if they don't use the header field seems OK to me. There are plenty of other places where implementations will be non-compliant. Also, I think that everyone involved understands that the target is still moving. On Feb 5, 2016 2:59 AM, "Eric Rescorla" wrote: > > > On Wed, Feb 3, 2016 at 7:16 AM, Cullen Jennings wrote: > >> I think we need to make the ALPN a bit more explicit. We agreed to >> include the ALPN header so that a proxy knows it might receive video pac= ket >> rates tunnelled across it. However the text on this is not 100% clear. >> Right now it says >> >> If it does so, it MUST support the "ALPN" header as >> specified in [RFC7639], >> >> But some people have posted out including this header is optional in 763= 9 >> so there might be some ubiquity here about what is meant. I think we sho= uld >> change the word =E2=80=9Csupport=E2=80=9D to =E2=80=9Cinclude=E2=80=9D t= o make it clear this needs to be >> sent to the proxy so that it would read >> >> If it does so, it MUST include the "ALPN" header as >> specified in [RFC7639], >> >> I believe that correctly reflects what we intended on this. There is no >> requirement for the proxy to understand or do anything with this header. >> Old proxies will just ignore it and cary on as if it was not there. >> > > I wouldn't have a problem with this if it were restricted to browsers. > However, > we don't want to careful about retroactively branding endpoints which > aren't > browsers but can talk to WebRTC clients as noncompliant. Maybe this > is like codecs where they are "WebRTC Compatible"? > > -Ekr > > Cullen >> >> (with my individual contributor hat on) >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a113edb167a587b052afff467 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think that Cullen's request is reasonable.

I really don't understand the obsession with labeling.= =C2=A0 Branding something as less than 100% "compliant" if they d= on't use the header field seems OK to me.=C2=A0 There are plenty of oth= er places where implementations will be non-compliant. Also, I think that e= veryone involved understands that the target is still moving.

On Feb 5, 2016 2:59 AM, "Eric Rescorla"= ; <ekr@rtfm.com> wrote:


On Wed, Feb 3, 2016 at = 7:16 AM, Cullen Jennings <fluffy@iii.ca> wrote:
I think we need to make the ALPN a bit more explicit. We = agreed to include the ALPN header so that a proxy knows it might receive vi= deo packet rates tunnelled across it. However the text on this is not 100% = clear. Right now it says

=C2=A0 =C2=A0If it does so, it MUST support the "ALPN" header as<= br> =C2=A0 =C2=A0specified in [RFC7639],

But some people have posted out including this header is optional in 7639 s= o there might be some ubiquity here about what is meant. I think we should = change the word =E2=80=9Csupport=E2=80=9D to =E2=80=9Cinclude=E2=80=9D to m= ake it clear this needs to be sent to the proxy so that it would read

=C2=A0 =C2=A0 If it does so, it MUST include the "ALPN" header as=
=C2=A0 =C2=A0specified in [RFC7639],

I believe that correctly reflects what we intended on this. There is no req= uirement for the proxy to understand or do anything with this header. Old p= roxies will just ignore it and cary on as if it was not there.

I wouldn't have a problem with this if it were = restricted to browsers. However,
we don't want to careful abo= ut retroactively branding endpoints which aren't
browsers but= can talk to WebRTC clients as noncompliant. Maybe this
is like c= odecs where they are "WebRTC Compatible"?

-Ekr

Cullen

(with my individual contributor hat on)


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a113edb167a587b052afff467-- From nobody Fri Feb 5 03:37:01 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85BF1A6F3C for ; Fri, 5 Feb 2016 03:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvgVXkZVqBZ6 for ; Fri, 5 Feb 2016 03:36:59 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EDA31A6F3B for ; Fri, 5 Feb 2016 03:36:59 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id d63so125550547ioj.2 for ; Fri, 05 Feb 2016 03:36:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=thtplGaWiIjpbaSsnlfV0j5P/DSmIp/fdGq5NjT5C14=; b=lPsB02pG51UztXC67QDqCzY/Rr/+xgvkdjj7HlDXf4xDad0wYQa0OHG8HjkgNI1DKP D5WU9uTvH99AyARn7/9BNXaYQvwv4CtQNLtZQfDz+vOvpDsSNwjLjoq4VVoVndlCfbos 0JI4Pc4kREKPs9TtzRX09PI/IjW87qfE3bq5v8Tjw1Ywf1KZVim1gquPxJtYZPZw1keg pxm6t/sxRcU9Wjg+QIcpfSFsmx3xeRjf2oDd5CgDUQefO6uuWg+pNofvSr7FI/rRrfhR vogoAiSQUJaRDdbnTVmUszXlgCPUFQyVqSg9pT5alGl9/OoppbAgc9t+3hKOn1LZBkPK RJuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=thtplGaWiIjpbaSsnlfV0j5P/DSmIp/fdGq5NjT5C14=; b=S5jlgWVgd7NKAxYlb0xice+ofegHs9kwOV6iQUDp3mD5IyLI/K/GGMwBBeV6etCeSP hZTXxYyl3AWKA5bNv8KG/xUTfT6ikLTl2tPZP7MTRi+f0xVAmwougMPxQn7GbuhKQrV+ 880CwwosiUwrc/NJzGCiU1sCmvAi9pu7p8QUGzKjAwRNQLGSJsLBOufQG6c7Z7dLInjA F/i84fqUPk63OU6BVW8UKk33WjhaU69gZJ3YtwBrzEp8eq3Q5j6CNYA9WmQzdBlQff14 BTvMx2cRmUqYfA6VyE7h7fO6cThsg26faef10gMBPDmdBIcTt+UYkU+RA9Ngadz5U63L 5P+A== X-Gm-Message-State: AG10YOQGqK7BThbS3f+79Zo4b06ypc6iMjBnP7P/rI0TacuUY9KZzKonhnpnkYeK8+/sSSp/fnKOB/54zaM/Hw== MIME-Version: 1.0 X-Received: by 10.107.16.153 with SMTP id 25mr14969126ioq.100.1454672219117; Fri, 05 Feb 2016 03:36:59 -0800 (PST) Received: by 10.36.53.79 with HTTP; Fri, 5 Feb 2016 03:36:59 -0800 (PST) In-Reply-To: References: <7A1D1E34-713A-4E21-B10A-39AD08EACCAB@iii.ca> Date: Fri, 5 Feb 2016 22:36:59 +1100 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [rtcweb] Summary of DTMF Issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 11:37:01 -0000 On 5 February 2016 at 11:01, Roman Shpount wrote: > Second decision is regarding what needs to be sent during telephone-event. > There are 3 options here: > > a. Background audio > b. Silence > c. Nothing I would say d. Audio (or is that the same as a. ?) For the same reasons Adam stated: we have cases that b and c break, namely the use of telephone-event as signaling. If some systems have specialized requirements around this, it isn't very hard to suppress audio and get option b. Yes, sending nothing is hard, but if you don't synchronize to audio packet boundaries, you won't get two packets with the same timestamp and won't that improve the chances that you get the tone through? I can see why you might suppress CN packets if those are enabled on the basis that it's largely harmless. But I'm guessing that the affected systems won't like CN. (BTW, I don't really want to see a knob for this.) From nobody Fri Feb 5 03:55:30 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387ED1B32B3 for ; Fri, 5 Feb 2016 03:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH7wi54jzhXS for ; Fri, 5 Feb 2016 03:55:27 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6471B321C for ; Fri, 5 Feb 2016 03:55:26 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-7b-56b48dac9858 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CA.61.05041.CAD84B65; Fri, 5 Feb 2016 12:55:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Fri, 5 Feb 2016 12:55:23 +0100 From: Christer Holmberg To: Ted Hardie , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Updated doodle poll link - scope of the meeting Thread-Index: AdFgC6kRryB0MBI4S2KdzkCvddYbIw== Date: Fri, 5 Feb 2016 11:55:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D7221D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D7221DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7ve6a3i1hBg3bBSzW/mtnt2ica+fA 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZTRcfcte8CWqYlLTF7YGxi0RXYycHBICJhLN E+4zQthiEhfurWfrYuTiEBI4zCgxZ98MKGcxo0TbzlVADgcHm4CFRPc/bZAGEQEPiU1/f7OC 2MICrhJLNnxnhYi7Sdx50MoEYetJXPywHMxmEVCRODzzBQuIzSvgKzHv9lp2EJsRaPH3U2vA apgFxCVuPZnPBHGQgMSSPeeZIWxRiZeP/7FC2EoSPzZcYoGoz5d4sQail1dAUOLkzCcsExiF ZiEZNQtJ2SwkZbOAvmEW0JRYv0sfokRRYkr3Q3YIW0Oidc5cdmTxBYzsqxhFi1OLi3PTjYz0 Uosyk4uL8/P08lJLNjECY+Tglt9WOxgPPnc8xCjAwajEw/vh+uYwIdbEsuLK3EOMEhzMSiK8 t5q3hAnxpiRWVqUW5ccXleakFh9ilOZgURLnXeO8PkxIID2xJDU7NbUgtQgmy8TBKdXA6P5/ bqji8ucqeQsmJuXZPKyY+q2WZ3vF7K5PlW61SslCipwzebyl82/G78r+ELvMS9U2Ulwx41Hx rFM7e94IHJw+/1+kzIOIlf8Druxd9CO67WXKnOeMaoun3phz1cyhzzD1akeT7qt2Yx+1b0tt r+7NEp797WJl0sbylWVPr5kveP5kQnL8NSWW4oxEQy3mouJEAJd4UAGNAgAA Archived-At: Subject: Re: [rtcweb] Updated doodle poll link - scope of the meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 11:55:29 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37D7221DESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZXJlIGhhc27igJl0IGJlZW4gbXVjaCBtYWlsIHRyYWZmaWMgcmVnYXJkaW5nIEpT RVAgZm9yIGEgbG9uZyB0aW1lLiBUaGVyZSBpcyBzb21lIGFjdGl2aXR5IG9uIEdpdGh1YiwgaG93 ZXZlci4NCg0KU28sIGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBtZWV0aW5nIHRvIGdvIHRocm91Z2gg dGhlIG9wZW4gZ2l0aHViIGlzc3Vlcz8gQXJlIGFsbCBvcGVuIGlzc3VlcyBjb2xsZWN0ZWQgaW4g Z2l0aHViIHRvIGJlZ2luIHdpdGg/IEFzIGZhciBhcyBJIGtub3cgKHBsZWFzZSBjb3JyZWN0IG1l IGlmIEnigJltIHdyb25nKSB0aGVyZSBpcyBubyBmb3JtYWwgcHJvY2VkdXJlIHNheWluZyB0aGF0 IGFueW9uZSBoYXZpbmcgYW4gaXNzdWUgd2l0aCBKU0VQIG11c3QgY3JlYXRlIGEgZ2l0aHViIGlz c3VlIGZvciBpdC4NCg0KSSB0aGluayBpdCB3b3VsZCBiZSByZWFsbHkgdXNlZnVsIHRvIGdpdmUg c29tZSBndWlkYW5jZSBvbiBob3cgdG8gcHJlcGFyZSBmb3IgdGhlIG1lZXRpbmcuIFdoYXQgYXJl IHdlIGdvaW5nIHRvIGZvY3VzIG9uPyBXaGljaCBwYXJ0cy9pc3N1ZXMgc2hvdWxkIHRoZSBwYXJ0 aWNpcGFudHMgZ2V0IGZhbWlsaWFyIHdpdGg/IFdoYXQgY2FuIHRoZSBwYXJ0aWNpcGFudHMgZG8g QkVGT1JFIHRoZSBtZWV0aW5nPyBldGMgZXRjDQoNClRoYW5rcyENCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBUZWQgSGFyZGllDQpTZW50OiA0LiBoZWxtaWt1dXRhIDIwMTYgMjA6MzgNClRv OiBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBVcGRhdGVkIGRvb2RsZSBw b2xsIGxpbmsNCg0KT24gTW9uLCBGZWIgMSwgMjAxNiBhdCA4OjU2IEFNLCBUZWQgSGFyZGllIDx0 ZWQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KSGVy ZSBpcyB0aGUgdXBkYXRlZCBsaW5rIHdpdGggdGltZXpvbmUgc2VsZWN0aW9uIGVuYWJsZWQ6DQoN Cmh0dHA6Ly9kb29kbGUuY29tL3BvbGwvN3ZxNHU0eXlmM3NkbWduNA0KcmVnYXJkcywNClRlZA0K DQrigItUaGVyZSBhcmUgY3VycmVudGx5IHRlbiBvciBzbyByZXBsaWVzIHRvIHRoZSBwb2xsLCBh bmQgd2UnZCBsaWtlIHRvIGhhdmUgbW9yZSBiZWZvcmUgbWFraW5nIGEgZGVjaXNpb24uICBQbGVh c2UgZmlsbCB0aGUgcG9sbCBpbiBieSBGcmlkYXksIEZlYnJ1YXJ5IDEydGgsIDIwMTYuDQp0aGFu a3MhDQpUZWTigIsNCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B37D7221DESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkdhcmFtb25kOw0KCXBhbm9zZS0xOjIgMiA0IDQgMyAz IDEgMSA4IDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCAyLjBjbSA3MC44 NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRkkiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGhhc27igJl0IGJlZW4gbXVjaCBtYWls IHRyYWZmaWMgcmVnYXJkaW5nIEpTRVAgZm9yIGEgbG9uZyB0aW1lLiBUaGVyZSBpcyBzb21lIGFj dGl2aXR5IG9uIEdpdGh1YiwgaG93ZXZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+U28sIGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBtZWV0aW5nIHRvIGdvIHRocm91Z2ggdGhl IG9wZW4gZ2l0aHViIGlzc3Vlcz8gQXJlIGFsbCBvcGVuIGlzc3VlcyBjb2xsZWN0ZWQgaW4gZ2l0 aHViIHRvIGJlZ2luIHdpdGg/IEFzIGZhciBhcyBJIGtub3cNCiAocGxlYXNlIGNvcnJlY3QgbWUg aWYgSeKAmW0gd3JvbmcpIHRoZXJlIGlzIG5vIGZvcm1hbCBwcm9jZWR1cmUgc2F5aW5nIHRoYXQg YW55b25lIGhhdmluZyBhbiBpc3N1ZSB3aXRoIEpTRVAgbXVzdCBjcmVhdGUgYSBnaXRodWIgaXNz dWUgZm9yIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIGl0 IHdvdWxkIGJlIHJlYWxseSB1c2VmdWwgdG8gZ2l2ZSBzb21lIGd1aWRhbmNlIG9uIGhvdyB0byBw cmVwYXJlIGZvciB0aGUgbWVldGluZy4gV2hhdCBhcmUgd2UgZ29pbmcgdG8gZm9jdXMgb24/IFdo aWNoIHBhcnRzL2lzc3VlcyBzaG91bGQNCiB0aGUgcGFydGljaXBhbnRzIGdldCBmYW1pbGlhciB3 aXRoPyBXaGF0IGNhbiB0aGUgcGFydGljaXBhbnRzIGRvIEJFRk9SRSB0aGUgbWVldGluZz8gZXRj IGV0YzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MhPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIg W21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGVk IEhhcmRpZTxicj4NCjxiPlNlbnQ6PC9iPiA0LiBoZWxtaWt1dXRhIDIwMTYgMjA6Mzg8YnI+DQo8 Yj5Ubzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dl Yl0gVXBkYXRlZCBkb29kbGUgcG9sbCBsaW5rPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRmViIDEsIDIwMTYgYXQgODo1NiBBTSwgVGVkIEhhcmRp ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnRlZC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dhcmFt b25kJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5IZXJlIGlzIHRoZSB1cGRhdGVkIGxpbmsgd2l0 aCB0aW1lem9uZSBzZWxlY3Rpb24gZW5hYmxlZDo8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwOi8v ZG9vZGxlLmNvbS9wb2xsLzd2cTR1NHl5ZjNzZG1nbjQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v ZG9vZGxlLmNvbS9wb2xsLzd2cTR1NHl5ZjNzZG1nbjQ8L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2FyYW1vbmQmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPnJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0dhcmFtb25kJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+4oCLPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0dhcmFtb25kJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGVyZSBhcmUgY3Vy cmVudGx5IHRlbiBvciBzbyByZXBsaWVzIHRvIHRoZSBwb2xsLCBhbmQgd2UnZCBsaWtlIHRvIGhh dmUgbW9yZSBiZWZvcmUgbWFraW5nIGEgZGVjaXNpb24uJm5ic3A7IFBsZWFzZSBmaWxsIHRoZSBw b2xsIGluIGJ5IEZyaWRheSwgRmVicnVhcnkgMTJ0aCwgMjAxNi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtHYXJhbW9uZCZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+dGhhbmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtHYXJhbW9uZCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGVkPC9zcGFuPuKAizxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtHYXJhbW9uZCZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37D7221DESESSMB209erics_-- From nobody Fri Feb 5 10:09:32 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AC21A1A8B for ; Fri, 5 Feb 2016 10:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ1H89RJzGWO for ; Fri, 5 Feb 2016 10:09:27 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341781A6FA8 for ; Fri, 5 Feb 2016 10:09:27 -0800 (PST) Received: by mail-qg0-x231.google.com with SMTP id b35so73634859qge.0 for ; Fri, 05 Feb 2016 10:09:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NTzEYnPhoo4VY5HBBhcMJkF29b89xlSgl3fOv1cvajg=; b=IVL2GEutmq/JyMpXECb/q52T7UEh/C0udaQobb5abljnPKCgc1W89YLxWykK75jkD7 BjYpf0jksB3nifVc1+wt5LlRaA9NEkruP79+sICWz4kRzKkB5K/tqCHC/lxGwt/2Vw44 gFq0d4gG216vFGzy9cR2wS+cbeag2qBmNZh5VJKKdSj+p1ytF5pXmUpeyvBqaSVyQYse PZzT1vKB25b7eAjpEvAzqVxGuEp04nXktoOZfNfvIYLyRo/XFIGe3O85cucwSh+MSTqo n6Cet42EERySB64DYC2OsDO8NJr6sOvaXP5+yRBiSibcw3aDVy8xn+g5tOjFTcCzc0zE 0aUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NTzEYnPhoo4VY5HBBhcMJkF29b89xlSgl3fOv1cvajg=; b=jmac2CvkYdtncxv5KBj5tCMOWYnBUFxX5eTM0euYrf8v59gc/VRLLUOOC4pNOVbki8 JyjyjKbDVrHvuANegOjfD4djpk+pO+kFDd4w3gBqorIC3Udd4rP/rFLRuA+f06VTwVnc ObYAWVr2ph6xRFAtNQvky47wEu05VpB9k/k3bhSL6BqjxmAN087hzKaydyaUm+6e/TAD EEoB9StsT20teJqzdQ0mnZVBLNis3v5L5H4YSFOvw8/QjzqY2n2jWjepXKPnGBENJmd/ m0hUZG6jEaYY07CexyhvsLVQNv/3ewUdFZlQTHuzeawzExER51baLWfFcOsNItIH+mNl AOaA== X-Gm-Message-State: AG10YOS+RlvjS2gd7KmzREXvXr3D4vGHS6C6YfTSevrC30gJJXwOu+OseLd2rCOYB0ttM/WufXsC5j0cGQRR2A== X-Received: by 10.141.28.149 with SMTP id f143mr19104095qhe.66.1454695766400; Fri, 05 Feb 2016 10:09:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Fri, 5 Feb 2016 10:09:06 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D7221D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D7221D@ESESSMB209.ericsson.se> From: Ted Hardie Date: Fri, 5 Feb 2016 10:09:06 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11422e8e69a38e052b09c005 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Updated doodle poll link - scope of the meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 18:09:30 -0000 --001a11422e8e69a38e052b09c005 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 5, 2016 at 3:55 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > There hasn=E2=80=99t been much mail traffic regarding JSEP for a long tim= e. There > is some activity on Github, however. > > > So, is the purpose of the meeting to go through the open github issues? Are > all open issues collected in github to begin with? As far as I know (plea= se > correct me if I=E2=80=99m wrong) there is no formal procedure saying that= anyone > having an issue with JSEP must create a github issue for it. > > > =E2=80=8BThere were a set of issues whose resolutions were agreed at the la= st meeting, but which did not have actual text in the document that implemented the results of discussion. The editors are planning to have a new draft out the week before this meeting, and the aim of the meeting is to review the draft to be sure the language works for the agreed resolution and doesn't introduce any new issues.=E2=80=8B > I think it would be really useful to give some guidance on how to prepare > for the meeting. > =E2=80=8BWhen the new version is ready, we'll know exactly how many of the = issues got text, and we'll post a list; a standard diff should also show the changes. Reviewing the changes in advance of the meeting is basically all that would be required. The aim here is to avoid taking time at IETF 95 reviewing the changes that implement things we've already settled, so that we can focus the meeting time on issues that don't yet have resolutions. Hope that helps, regards, Ted=E2=80=8B > What are we going to focus on? Which parts/issues should the participants > get familiar with? What can the participants do BEFORE the meeting? etc e= tc > > > > Thanks! > > > > Regards, > > > > Christer > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Ted Hardie > *Sent:* 4. helmikuuta 2016 20:38 > *To:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Updated doodle poll link > > > > On Mon, Feb 1, 2016 at 8:56 AM, Ted Hardie wrote: > > Here is the updated link with timezone selection enabled: > > http://doodle.com/poll/7vq4u4yyf3sdmgn4 > > regards, > > Ted > > > > =E2=80=8BThere are currently ten or so replies to the poll, and we'd like= to have > more before making a decision. Please fill the poll in by Friday, Februa= ry > 12th, 2016. > > thanks! > > Ted=E2=80=8B > > > > > --001a11422e8e69a38e052b09c005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 5, 2016 at 3:55 AM,= Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

There= hasn=E2=80=99t been much mail traffic regarding JSEP for a long time. Ther= e is some activity on Github, however.

=C2=A0

<= /span>

So, i= s the purpose of the meeting to go through the open github issues? Are all = open issues collected in github to begin with? As far as I know (please correct me if I=E2=80=99m wrong) there is no formal procedure sayi= ng that anyone having an issue with JSEP must create a github issue for it.=

=C2=A0


=E2=80=8BThere = were a set of issues whose resolutions were agreed at the last meeting, but= which did not have actual text in the document that implemented the result= s of discussion.=C2=A0 The editors are planning to have a new draft out the= week before this meeting, and the aim of the meeting is to review the draf= t to be sure the language works for the agreed resolution and doesn't i= ntroduce any new issues.=E2=80=8B

=C2=A0

I thi= nk it would be really useful to give some guidance on how to prepare for th= e meeting.


=E2=80=8BWhen= the new version is ready, we'll know exactly how many of the issues go= t text, and we'll post a list; a standard diff should also show the cha= nges.=C2=A0 Reviewing the changes in advance of the meeting is basically al= l that would be required.

The aim here is to avoid ta= king time at IETF 95 reviewing the changes that implement things we've = already settled, so that we can focus the meeting time on issues that don&#= 39;t yet have resolutions.

Hope that helps= ,

regards,

Ted=E2=80=8B

=C2=A0

What are we going to focus on? Whic= h parts/issues should the participants get familiar with? What can the participants do BEFORE th= e meeting? etc etc

=C2=A0

Thank= s!

=C2=A0

Regar= ds,

=C2=A0

Chris= ter

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: 4. helmikuuta 2016 20:38
To: rtcweb@ietf= .org
Subject: Re: [rtcweb] Updated doodle poll link<= /p>

=C2=A0

On Mon, Feb 1, 2016 at 8:56 AM, Ted Hardie <ted.ietf@gmail.com&g= t; wrote:

Here is the updated link with t= imezone selection enabled:

http:= //doodle.com/poll/7vq4u4yyf3sdmgn4

regards,

Ted

=C2=A0

=E2=80=8BThere are currently te= n or so replies to the poll, and we'd like to have more before making a= decision.=C2=A0 Please fill the poll in by Friday, February 12th, 2016.=

thanks!

Ted=E2=80=8B

=C2=A0

=C2=A0


--001a11422e8e69a38e052b09c005-- From nobody Fri Feb 5 13:42:39 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A6C1A885E for ; Fri, 5 Feb 2016 13:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InBV4rW_Gu0v for ; Fri, 5 Feb 2016 13:42:35 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEF01B2CF6 for ; Fri, 5 Feb 2016 13:42:35 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id f81so142555857iof.0 for ; Fri, 05 Feb 2016 13:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=de5iODtTEMXMKHOWE8PgqVNbY9NCErehaiet9sMeexI=; b=klalwDTzr4fnxxVIQqB/n0zSrrcpoBS3wfVxXTpJheXZHaGpGP9SlRm9xkxPBAkrbD hsEWbAhBwCb91F6oXHoh1h8/QI9fJfXT2qO58o6xcM0KFFoMhhkmZJvV/Z4DHnkoNqKP UIyhxpvvnYgf0R1R2DT2jzzxjZNmUuCfmgmBk7S58NN/sm/sZy6fhXANyR/t+oG5CKAV e3dXmGH0yA2LgItTkTN0RjLQWk+T2qU1eb1vl1LNEzBXQWINkqlERa5aCIHiRPJbU5yu AyKBqyVQqvONyecvx+iOp+2nCeQmVI/gDuTSDvT+CCY1IR4UN3uxmRklRQuwszK2sy6J 7Dmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=de5iODtTEMXMKHOWE8PgqVNbY9NCErehaiet9sMeexI=; b=gQqj4rsyGnQ545Dv+sulrM5WcNXSWFr+lzoClDj4Bzf6YSEhV0JpQB/TS81kUWTf1A K4nNjb5hEkvxaUV198gtgISA9ElzJjaT6V5853wEbGlH3nfIAthmIUD6NbAaF2qKcgZ9 mZHH27BmmOCy7ocCwPqFmAgRucjMijly7b/GuVdxxpC2qGpzMVQA8s5ZRDRz38BPcPFn 6LsbXNbvyiqrhHGZYUY5nLZn5nz++DT65Nk3qrDG2ctFmzBiJi8YKoL/Zz8EqZ0HB1Pc c9t08ZC3usSVBNi58hOviB+FZ9blnaWO++uBmuyrDKQWgpKw6Oudlhw7FR0/TnuczWat SngQ== X-Gm-Message-State: AG10YOTfMUeysv3Bx5fUvj4weibAREGiz/PVrwjTxTs2jYvrQnfJKvjlzdW8vz58Bcu5Bw== X-Received: by 10.107.16.81 with SMTP id y78mr17739152ioi.13.1454708554929; Fri, 05 Feb 2016 13:42:34 -0800 (PST) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id nq10sm245588igb.2.2016.02.05.13.42.33 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 13:42:33 -0800 (PST) Received: by mail-io0-f171.google.com with SMTP id f81so142555032iof.0 for ; Fri, 05 Feb 2016 13:42:33 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr15796634ioe.38.1454708552831; Fri, 05 Feb 2016 13:42:32 -0800 (PST) Received: by 10.36.105.77 with HTTP; Fri, 5 Feb 2016 13:42:32 -0800 (PST) In-Reply-To: References: <7A1D1E34-713A-4E21-B10A-39AD08EACCAB@iii.ca> Date: Fri, 5 Feb 2016 16:42:32 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1140b4728b1faf052b0cba9e Archived-At: Cc: "" Subject: Re: [rtcweb] Summary of DTMF Issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 21:42:38 -0000 --001a1140b4728b1faf052b0cba9e Content-Type: text/plain; charset=UTF-8 On Fri, Feb 5, 2016 at 6:36 AM, Martin Thomson wrote: > On 5 February 2016 at 11:01, Roman Shpount wrote: > > Second decision is regarding what needs to be sent during > telephone-event. > > There are 3 options here: > > > > a. Background audio > > b. Silence > > c. Nothing > > I would say d. Audio (or is that the same as a. ?) For the same > reasons Adam stated: we have cases that b and c break, namely the use > of telephone-event as signaling. > This is option a. By background audio I mean audio from the microphone. If you read https://tools.ietf.org/html/rfc4733#section-2.5.2 you will see that "it is RECOMMENDED that gateways render only the telephone-event payload once it is received". This means that audio during the telephone-event is normally ignored and can be safely replaced by silence or not sent at all. I do not think there is a lot of value in the background audio during the telephone event. Systems described by Adam before, the ones that convert from telephone-event audio to DTMF in signaling channel, normally actively suppress audio covered by the telephone-event. The reason for this is that if audio ever gets reassembled back into in-band DTMF tones, since signaling is not time synchronized with audio, two DTMF tones can be generated in the resulting audio stream -- one with original DTMF tone and another with DTMF tone generated based on signaling. Finally, I do not think any systems suppress just the DTMF tone from the audio using some sort of DSP filter. When DTMF tones are suppressed, all audio for the duration of the tone is suppressed. When DTMF tone is detected in-band, it must represent the majority of audio energy so filtering out the tone would be doing additional work for no reason. > If some systems have specialized requirements around this, it isn't > very hard to suppress audio and get option b. Yes, sending nothing is > hard, but if you don't synchronize to audio packet boundaries, you > won't get two packets with the same timestamp and won't that improve > the chances that you get the tone through? > Not synchronizing packets on audio boundaries will decrease your chances for the tone getting through. The reason for this are gateways that time packet playback based on sequence numbers and not RTP timestamps. With telephone-event packet this system assumes that DTMF tone starts after the end of the audio packet with immediately previous sequence number and it is played until telephone-event with end bit is received. Essentially such systems ignore RTP timestamps and use sequnce number * ptime instead. > I can see why you might suppress CN packets if those are enabled on > the basis that it's largely harmless. But I'm guessing that the > affected systems won't like CN. > I never seen a system which sends CN packets during telephone-event. I saw systems that send regular audio packets and systems which send nothing. CN immediately before the telephone-event or during the telephone-event would be completely redundant. P.S. There is one more option for the audio during telephone-event -- generate the DTMF tone and encode it using the audio codec. I hope no one is in favor of this. This is extra work that serves no purpose. I think I disliked it so much I forgot to include it in the list of available options. _____________ Roman Shpount --001a1140b4728b1faf052b0cba9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 5, 2016 at 6:36= AM, Martin Thomson <martin.thomson@gmail.com> wrote:=
On 5 February 2016 at 11:01, Roman Sh= pount <roman@telurix.com> wr= ote:
> Second decision is regarding what needs to be sent during telephone-ev= ent.
> There are 3 options here:
>
> a. Background audio
> b. Silence
> c. Nothing

I would say d. Audio (or is that the same as a. ?)=C2=A0 For the sam= e
reasons Adam stated: we have cases that b and c break, namely the use
of telephone-event as signaling.

This i= s option a. By background audio I mean audio from the microphone.

If you read=C2=A0https://tools.ietf.org/html/rfc4733#section-2.5.2 y= ou will see that "it is RECOMMENDED that gateways render only the tele= phone-event payload once it is received". This means that audio during= the telephone-event is normally ignored and can be safely replaced by sile= nce or not sent at all.

I do not think there i= s a lot of value in the background audio during the telephone event. System= s described by Adam before, the ones that convert from telephone-event audi= o to DTMF in signaling channel, normally actively suppress audio covered by= the telephone-event. The reason for this is that if audio ever gets reasse= mbled back into in-band DTMF tones, since signaling is not time synchronize= d with audio, two DTMF tones can be generated in the resulting audio stream= -- one with original DTMF tone and another with DTMF tone generated based = on signaling.

Finally, I do not think any systems = suppress just the DTMF tone from the audio using some sort of DSP filter. W= hen DTMF tones are suppressed, all audio for the duration of the tone is su= ppressed. When DTMF tone is detected in-band, it must represent the majorit= y of audio energy so filtering out the tone would be doing additional work = for no reason.
=C2=A0
If some systems have = specialized requirements around this, it isn't
very hard to suppress audio and get option b.=C2=A0 Yes, sending nothing is=
hard, but if you don't synchronize to audio packet boundaries, you
won't get two packets with the same timestamp and won't that improv= e
the chances that you get the tone through?

<= div>Not synchronizing packets on audio boundaries will decrease your chance= s for the tone getting through. The reason for this are gateways that time = packet playback based on sequence numbers and not RTP timestamps. With tele= phone-event packet this system assumes that DTMF tone starts after the end = of the audio packet with immediately previous sequence number and it is pla= yed until telephone-event with end bit is received. Essentially such system= s ignore RTP timestamps and use sequnce number * ptime instead. =C2=A0
=C2=A0
I can see why you might suppress CN pack= ets if those are enabled on
the basis that it's largely harmless.=C2=A0 But I'm guessing that t= he
affected systems won't like CN.

I never seen a syst= em which sends CN packets during telephone-event. I saw systems that send r= egular audio packets and systems which send nothing. CN immediately before = the telephone-event or during the telephone-event would be completely redun= dant.

= P.S. There is one more option for the audio during telephone-event -- gener= ate the DTMF tone and encode it using the audio codec. I hope no one is in = favor of this. This is extra work that serves no purpose. I think I dislike= d it so much I forgot to include it in the list of available options.
=
____________= _
Roman Shpount

--001a1140b4728b1faf052b0cba9e-- From nobody Sat Feb 6 03:07:47 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A521B2B97 for ; Sat, 6 Feb 2016 03:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTxeKy4irm8x for ; Sat, 6 Feb 2016 03:07:44 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435511ACE49 for ; Sat, 6 Feb 2016 03:07:44 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-9e-56b5d3fe97b6 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E0.B4.05041.EF3D5B65; Sat, 6 Feb 2016 12:07:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.166]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Sat, 6 Feb 2016 12:07:42 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-mux-exclusive-01 Thread-Index: AdFgzX/VWHNvZFvMR025jRlG2u/S1gAAOw8g Date: Sat, 6 Feb 2016 11:07:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D90319@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D8F2E5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37D8F2E5@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/mixed; boundary="_004_7594FB04B1934943A5C02806D1A2204B37D90319ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLIsWRmVeSWpSXmKPExsUyM2K7h+6/y1vDDNqXyFqs/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMUPEwoWG1Vs/z6ZtYHxtk4XIyeHhICJxK/er0wQtpjEhXvr 2boYuTiEBA4zSmz4c4ERwlnMKLH76GbWLkYODjYBC4nuf9ogDSIC6hKXH15gB7GFBZwk9nTv ZIGIO0tsvzmXCcI2klj4sJMVxGYRUJGYfWQPWJxXwFeiafMnRhBbCMi++f4bM4jNKeAn8bN3 IVg9I9BB30+tAatnFhCXuPVkPtShIhIPL55mg7BFJV4+/scKYStJrNh+iRGiPlPi/NZGqF2C EidnPmGZwCgyC8moWUjKZiEpmwX0JbNAvsTkj+YQJToSC3Z/YoOwtSWWLXzNDGOfOfCYCVNc V2LunD1QtqLE3t3X2WcBQ5FZYAWjxL2z71ggEtYS647tZYcpmtL9kH0BI+8qRtHi1OLi3HQj I73Uoszk4uL8PL281JJNjMCIPrjlt9UOxoPPHQ8xCnAwKvHwGnzcEibEmlhWXJl7iFEFaM6j DasvMEqx5OXnpSqJ8M5csTVMiDclsbIqtSg/vqg0J7X4EKM0B4uSOO8a5/VhQgLpiSWp2amp BalFMFkmDk6pBkYXof4Te7UUdDvdFRM/h/8qjlshdGzzHX+pndXa6yWetPesZ/r/7NWU6zM+ fzA3fr78451H7GwpnmZzJmdJsBbvzqryl1k/6eU0g/tzD60Q5rZoNyt4aWE/UXfTpS9Zsh5v 9D5YTNw7WalKzsHyRsME/RsuW95+5DjuU+i9Xr4ne/52S7UYzhlKLMUZiYZazEXFiQDhuy7u 8AIAAA== Archived-At: Subject: [rtcweb] FW: Draft new version: draft-ietf-mmusic-mux-exclusive-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 11:07:46 -0000 --_004_7594FB04B1934943A5C02806D1A2204B37D90319ESESSMB209erics_ Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37D90319ESESSMB209erics_" --_000_7594FB04B1934943A5C02806D1A2204B37D90319ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, This draft is needed for JSEP, in cases where browsers do not support non-m= ux of RTP and RTCP. Please post any possible questions/issues on the MMUSIC list. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 06 February 2016 13:03 To: mmusic Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive-01 Hi, I've submitted a new version (-01) of draft-mux-exclusive. The main difference compared to the previous version is that the draft now = defines a new SDP attribute, 'rtcp-mux-exclusive', to indicate exclusive su= pport of, and negotiate usage of, RTP/RTCP multiplexing. There are currently no open issues in the draft, so I encourage people to t= ake a look, so that we can start moving towards WGLC. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37D90319ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI,=

 

This draft is needed f= or JSEP, in cases where browsers do not support non-mux of RTP and RTCP.

 

Please post any possib= le questions/issues on the MMUSIC list.

 

Regards,

 

Christer

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 06 February 2016 13:03
To: mmusic <mmusic@ietf.org>
Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-mux-exclusive= -01

 

Hi,

 

I’ve submitted a new version (-01) of draft-mu= x-exclusive.

 

The main difference compared to the previous version= is that the draft now defines a new SDP attribute, ‘rtcp-mux-exclusi= ve’, to indicate exclusive support of, and negotiate usage of, RTP/RT= CP multiplexing.

 

There are currently no open issues in the draft, so = I encourage people to take a look, so that we can start moving towards WGLC= .

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37D90319ESESSMB209erics_-- --_004_7594FB04B1934943A5C02806D1A2204B37D90319ESESSMB209erics_ Content-Type: text/plain; name="ATT00002.txt" Content-Description: ATT00002.txt Content-Disposition: attachment; filename="ATT00002.txt"; size=133; creation-date="Sat, 06 Feb 2016 11:02:45 GMT"; modification-date="Sat, 06 Feb 2016 11:02:45 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBt YWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMNCg== --_004_7594FB04B1934943A5C02806D1A2204B37D90319ESESSMB209erics_-- From nobody Sun Feb 7 23:46:52 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C291ACD10 for ; Sun, 7 Feb 2016 23:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lB5zPbUqMcVc for ; Sun, 7 Feb 2016 23:46:48 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 42DBA1ACD09 for ; Sun, 7 Feb 2016 23:46:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id BE42C7C691F for ; Mon, 8 Feb 2016 08:46:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLh5bHL-QMLY for ; Mon, 8 Feb 2016 08:46:44 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:b88d:73af:6842:3a52] (unknown [IPv6:2001:470:de0a:1:b88d:73af:6842:3a52]) by mork.alvestrand.no (Postfix) with ESMTPSA id C023F7C670A for ; Mon, 8 Feb 2016 08:46:43 +0100 (CET) To: rtcweb@ietf.org References: From: Harald Alvestrand Message-ID: <56B847E2.8060109@alvestrand.no> Date: Mon, 8 Feb 2016 08:46:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070908080506090105040501" Archived-At: Subject: Re: [rtcweb] Clarification in draft-ietf-rtcweb-transports-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 07:46:51 -0000 This is a multi-part message in MIME format. --------------070908080506090105040501 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit This seems reasonable. Filed https://github.com/rtcweb-wg/rtcweb-transport/issues/12 so as to not forget. On 02/05/2016 07:28 AM, Martin Thomson wrote: > > I think that Cullen's request is reasonable. > > I really don't understand the obsession with labeling. Branding > something as less than 100% "compliant" if they don't use the header > field seems OK to me. There are plenty of other places where > implementations will be non-compliant. Also, I think that everyone > involved understands that the target is still moving. > > On Feb 5, 2016 2:59 AM, "Eric Rescorla" > wrote: > > > > On Wed, Feb 3, 2016 at 7:16 AM, Cullen Jennings > wrote: > > I think we need to make the ALPN a bit more explicit. We > agreed to include the ALPN header so that a proxy knows it > might receive video packet rates tunnelled across it. However > the text on this is not 100% clear. Right now it says > > If it does so, it MUST support the "ALPN" header as > specified in [RFC7639], > > But some people have posted out including this header is > optional in 7639 so there might be some ubiquity here about > what is meant. I think we should change the word support to > include to make it clear this needs to be sent to the proxy > so that it would read > > If it does so, it MUST include the "ALPN" header as > specified in [RFC7639], > > I believe that correctly reflects what we intended on this. > There is no requirement for the proxy to understand or do > anything with this header. Old proxies will just ignore it and > cary on as if it was not there. > > > I wouldn't have a problem with this if it were restricted to > browsers. However, > we don't want to careful about retroactively branding endpoints > which aren't > browsers but can talk to WebRTC clients as noncompliant. Maybe this > is like codecs where they are "WebRTC Compatible"? > > -Ekr > > Cullen > > (with my individual contributor hat on) > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. --------------070908080506090105040501 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
This seems reasonable.

Filed https://github.com/rtcweb-wg/rtcweb-transport/issues/12 so as to not forget.

On 02/05/2016 07:28 AM, Martin Thomson wrote:

I think that Cullen's request is reasonable.

I really don't understand the obsession with labeling. Branding something as less than 100% "compliant" if they don't use the header field seems OK to me. There are plenty of other places where implementations will be non-compliant. Also, I think that everyone involved understands that the target is still moving.

On Feb 5, 2016 2:59 AM, "Eric Rescorla" <ekr@rtfm.com> wrote:


On Wed, Feb 3, 2016 at 7:16 AM, Cullen Jennings <fluffy@iii.ca> wrote:
I think we need to make the ALPN a bit more explicit. We agreed to include the ALPN header so that a proxy knows it might receive video packet rates tunnelled across it. However the text on this is not 100% clear. Right now it says

If it does so, it MUST support the "ALPN" header as
specified in [RFC7639],

But some people have posted out including this header is optional in 7639 so there might be some ubiquity here about what is meant. I think we should change the word support to include to make it clear this needs to be sent to the proxy so that it would read

If it does so, it MUST include the "ALPN" header as
specified in [RFC7639],

I believe that correctly reflects what we intended on this. There is no requirement for the proxy to understand or do anything with this header. Old proxies will just ignore it and cary on as if it was not there.

I wouldn't have a problem with this if it were restricted to browsers. However,
we don't want to careful about retroactively branding endpoints which aren't
browsers but can talk to WebRTC clients as noncompliant. Maybe this
is like codecs where they are "WebRTC Compatible"?

-Ekr

Cullen

(with my individual contributor hat on)


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



-- 
Surveillance is pervasive. Go Dark.
--------------070908080506090105040501-- From nobody Mon Feb 8 03:07:56 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6B61ACEE4 for ; Mon, 8 Feb 2016 03:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LLXaDGDTjlt for ; Mon, 8 Feb 2016 03:07:52 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC1E1ACEF0 for ; Mon, 8 Feb 2016 03:07:51 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id C822B1EB8423; Mon, 8 Feb 2016 12:07:49 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0279.002; Mon, 8 Feb 2016 12:07:49 +0100 From: "Hutton, Andrew" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Clarification in draft-ietf-rtcweb-transports-11 Thread-Index: AQHRYkTl13SG26SxHUenzLp8aaPApp8h+wNA Date: Mon, 8 Feb 2016 11:07:48 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E99B4D3@MCHP04MSX.global-ad.net> References: <56B847E2.8060109@alvestrand.no> In-Reply-To: <56B847E2.8060109@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1E99B4D3MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] Clarification in draft-ietf-rtcweb-transports-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 11:07:55 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E99B4D3MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cullen's suggestion also seems reasonable to me and reflects what we intend= ed to say anyway. Andy From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestran= d Sent: 08 February 2016 07:47 To: rtcweb@ietf.org Subject: Re: [rtcweb] Clarification in draft-ietf-rtcweb-transports-11 This seems reasonable. Filed https://github.com/rtcweb-wg/rtcweb-transport/issues/12 so as to not = forget. On 02/05/2016 07:28 AM, Martin Thomson wrote: I think that Cullen's request is reasonable. I really don't understand the obsession with labeling. Branding something = as less than 100% "compliant" if they don't use the header field seems OK t= o me. There are plenty of other places where implementations will be non-c= ompliant. Also, I think that everyone involved understands that the target = is still moving. On Feb 5, 2016 2:59 AM, "Eric Rescorla" >= wrote: On Wed, Feb 3, 2016 at 7:16 AM, Cullen Jennings > wrote: I think we need to make the ALPN a bit more explicit. We agreed to include = the ALPN header so that a proxy knows it might receive video packet rates t= unnelled across it. However the text on this is not 100% clear. Right now i= t says If it does so, it MUST support the "ALPN" header as specified in [RFC7639], But some people have posted out including this header is optional in 7639 s= o there might be some ubiquity here about what is meant. I think we should = change the word "support" to "include" to make it clear this needs to be se= nt to the proxy so that it would read If it does so, it MUST include the "ALPN" header as specified in [RFC7639], I believe that correctly reflects what we intended on this. There is no req= uirement for the proxy to understand or do anything with this header. Old p= roxies will just ignore it and cary on as if it was not there. I wouldn't have a problem with this if it were restricted to browsers. Howe= ver, we don't want to careful about retroactively branding endpoints which aren'= t browsers but can talk to WebRTC clients as noncompliant. Maybe this is like codecs where they are "WebRTC Compatible"? -Ekr Cullen (with my individual contributor hat on) _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. --_000_9F33F40F6F2CD847824537F3C4E37DDF1E99B4D3MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Cullen’s suggestion= also seems reasonable to me and reflects what we intended to say anyway.

 <= /p>

Andy

 <= /p>

 <= /p>

 <= /p>

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 08 February 2016 07:47
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Clarification in draft-ietf-rtcweb-transports-= 11

 

This seems reasonable.

Filed h= ttps://github.com/rtcweb-wg/rtcweb-transport/issues/12 so as to not for= get.

On 02/05/2016 07:28 AM, Martin Thomson wrote:

I think that Cullen's request is reasonable.

I really don't understand the obsession with labeling.  Branding so= mething as less than 100% "compliant" if they don't use the heade= r field seems OK to me.  There are plenty of other places where implem= entations will be non-compliant. Also, I think that everyone involved understands that the target is still moving. =

On Feb 5, 2016 2:59 AM, "Eric Rescorla" &l= t;ekr@rtfm.com> wrote:

 

 

On Wed, Feb 3, 2016 at 7:16 AM, Cullen Jennings <= fluffy@iii.ca> wrote:

I think we need to make the ALPN a bit more explicit= . We agreed to include the ALPN header so that a proxy knows it might recei= ve video packet rates tunnelled across it. However the text on this is not = 100% clear. Right now it says

   If it does so, it MUST support the "ALPN" header as<= br>    specified in [RFC7639],

But some people have posted out including this header is optional in 7639 s= o there might be some ubiquity here about what is meant. I think we should = change the word “support” to “include” to make it c= lear this needs to be sent to the proxy so that it would read

    If it does so, it MUST include the "ALPN" header as=
   specified in [RFC7639],

I believe that correctly reflects what we intended on this. There is no req= uirement for the proxy to understand or do anything with this header. Old p= roxies will just ignore it and cary on as if it was not there.

 

I wouldn't have a problem with this if it were restr= icted to browsers. However,

we don't want to careful about retroactively brandin= g endpoints which aren't

browsers but can talk to WebRTC clients as noncompli= ant. Maybe this

is like codecs where they are "WebRTC Compatibl= e"?

 

-Ekr

 

Cullen

(with my individual contributor hat on)


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

 


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org

https://www.i=
etf.org/mailman/listinfo/rtcweb






-- 
Surveillance is pervasive. Go Dark.
--_000_9F33F40F6F2CD847824537F3C4E37DDF1E99B4D3MCHP04MSXglobal_-- From nobody Tue Feb 9 01:02:05 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B401D1A8700 for ; Tue, 9 Feb 2016 01:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dvzJ4gdriSu for ; Tue, 9 Feb 2016 01:02:02 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534D51A86FF for ; Tue, 9 Feb 2016 01:02:02 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id g62so13710210wme.0 for ; Tue, 09 Feb 2016 01:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=q+DnKodxFacnoqVUbLdmp2cLkwdSTSr5sNP/ylBvWpo=; b=RJqGHVdDvXHr6my7qKY2AAOT01fEx14FFGbt1fkwnXNtmFs4ivc+U0A1wbqQS9AOse 1Kwl7a5Gt2KLKhW5FT6g7jvb/Hiy4DnzzAzqDXW7Y+ykZdJ1sEAFHmHfPGM5cC1/X3RV uc/vEC8us/s3EKyydt5WG1loKAkT/LIUMwqUrUyrXFIOiTcvk6GVNDe3d62C7zd8pK7P cJneDJe1MXlc5NcFx2ELN3F1+4DOHvk8YjsdtY0bGbMOA3Kcx9uANass6g3UYhB8di2Y wCXLiKNzG2enW2dKVx5hTsNFKZeJnEs9zPGswjQ5vFAJPTsrKccw2C3v2K4gXDl/pX0H rFwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=q+DnKodxFacnoqVUbLdmp2cLkwdSTSr5sNP/ylBvWpo=; b=TuEONwUyW94A5zRB+apsmBygu4p3e+tEkOLCg2Ny9itfHkS2NJz+DVcoD5c0H4YVhI Drm1RgOenLLp9RfxXuKFCuYz0Bkut8NxZu2+MJ3kzI6BQunOMse9TyzBSK64kwt4oQ2l 7jrIEze6IZ51cF71lu3cys8/8A1+lH/w45KcvD071b/gIFAH0SGpITR8jiMleMDCiK+o JjwuBaelr5wHGr07prj+x8jyo8gv7RpjgAG2LvgObUZLjhhGHooISIaueOLBmKMPL5mO KDrN+l/4j+MBwUzdb8amsKuQ/nklAWDZhlK8AugaeTFPlmhKRQ/Pls/zlMt9HLCHPG9v CLPQ== X-Gm-Message-State: AG10YOTHzvrxJQzBzQqddz7/h2oyPfI2LJK2bsJZbUfe97i4l1XxXyIgLdenY9UfYb4z2F2QKl/rLZdCqdTWrg== MIME-Version: 1.0 X-Received: by 10.194.192.71 with SMTP id he7mr38054803wjc.82.1455008520929; Tue, 09 Feb 2016 01:02:00 -0800 (PST) Received: by 10.28.16.67 with HTTP; Tue, 9 Feb 2016 01:02:00 -0800 (PST) Date: Tue, 9 Feb 2016 10:02:00 +0100 Message-ID: From: Victor Pascual Avila To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [rtcweb] draft-ietf-rtcweb-transports-11 -- Section-3.4 Middle box related functions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 09:02:03 -0000 Hi, end-to-end TCP is supported but not very useful due to HoLB. Typical use is just TCP to a TURN server or gateway, then UDP. Can we assume real-time media over a TCP-based access works fine? Thanks, -Victor From nobody Tue Feb 9 12:36:01 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D4A1AD338; Tue, 9 Feb 2016 12:35:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160209203557.10249.70130.idtracker@ietfa.amsl.com> Date: Tue, 09 Feb 2016 12:35:57 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 20:35:57 -0000 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 of the IETF. Title : WebRTC Audio Codec and Processing Requirements Authors : Jean-Marc Valin Cary Bran Filename : draft-ietf-rtcweb-audio-10.txt Pages : 7 Date : 2016-02-09 Abstract: This document outlines the audio codec and processing requirements for WebRTC endpoints. 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: https://tools.ietf.org/html/draft-ietf-rtcweb-audio-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-10 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 nobody Tue Feb 9 12:44:28 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7C41AD369 for ; Tue, 9 Feb 2016 12:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBbrn3CQrh0U for ; Tue, 9 Feb 2016 12:44:24 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120C21AD338 for ; Tue, 9 Feb 2016 12:44:23 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id x1so74851059qkc.1 for ; Tue, 09 Feb 2016 12:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=57wNRgyXUNTOWfg16PAoPz1W+nsfz68I94zOztGPlEs=; b=huDuLnnrtWB1WTwQNNdZpPTH46lnW1rzcJEYwVRt1fmGxwCT8J5ARBVKEcuxmos63u SrNCbapw3pw4oArefAkrkZzsmRuLyPk1pml5zLDGAIgvF4B9MG5+U5YWMyVjLhPfeKdD L4G3UhJqAaeuAX5/s8y/saso71W3HxtCz8SlRE4SV/fog6bRV5T2Y6i1HkKV30LdAf72 Swh5i7kVI1nRrEn0EZrnMmbgvNHYJSNz6YwhhqTx1L32IBrL7pGINB1M21fPBEYBb/mj 84LsASVZI11R1vcimHlakkxRlR9HkIBVbMqDfLhwfWTmzznm4kd9Jm+4j0WpsvD0G2Qb WIeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=57wNRgyXUNTOWfg16PAoPz1W+nsfz68I94zOztGPlEs=; b=LhoNo+kmbjfwVsVrZC/bHxHNcFWRrSBeAdx7alnB+CZsZjbqbQ0Y5i37Kz2sIjWDGp bs6FfAiZt11gpp7GccNbtIAV0BB6OlstqQshxc7/iSNxVp18+TweLyH78Rz1Rj585HBO Q0BmWucTV4+fe+kiij1/W8kd40M3oFx/uXfUMiNTpLolEq5ro0U7NRcl1of3P8XJ0R8o /dqCoFS9NkTB1+gX/peRv5ctGG32HmDmtTKQB4ExOVGa6qHVYr5uAb2jAyTQPxt3EyRz U6eKr3+WIlunF+kqWUeXJGyBMRZCIU9c/74GTrJSPmY6uuOKXwyZqMeMyPI5HXYQZLKd 0eaw== X-Gm-Message-State: AG10YOQ63+bYY6J/vEPubpPle7PH0LZSWGhSa8WOOIsDu86a03ePOP7uLbfT0TamaAHFgKtl X-Received: by 10.55.79.17 with SMTP id d17mr43761855qkb.56.1455050663146; Tue, 09 Feb 2016 12:44:23 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable121.240-21-96.mc.videotron.ca. [96.21.240.121]) by smtp.gmail.com with ESMTPSA id z66sm16358947qhc.16.2016.02.09.12.44.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Feb 2016 12:44:21 -0800 (PST) To: internet-drafts@ietf.org, i-d-announce@ietf.org References: <20160209203557.10249.70130.idtracker@ietfa.amsl.com> From: Jean-Marc Valin X-Enigmail-Draft-Status: N1110 Message-ID: <56BA4FA5.8050803@mozilla.com> Date: Tue, 9 Feb 2016 15:44:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160209203557.10249.70130.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 20:44:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I just uploaded version -10, including: - - The CN resolution discussed in December - - Inclusion of A-D events - - Cullen's "option 0" for 4733 events - - Some terminology improvements Cheers, Jean-Marc On 02/09/2016 03:35 PM, internet-drafts@ietf.org wrote: > > 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 of the IETF. > > Title : WebRTC Audio Codec and Processing Requirements > Authors : Jean-Marc Valin Cary Bran Filename : > draft-ietf-rtcweb-audio-10.txt Pages : 7 Date > : 2016-02-09 > > Abstract: This document outlines the audio codec and processing > requirements for WebRTC endpoints. > > > 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: > https://tools.ietf.org/html/draft-ietf-rtcweb-audio-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-10 > > > 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/ > > _______________________________________________ rtcweb mailing > list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWuk+hAAoJEJ6/8sItn9q9y+sH/0YUQQWwrB0xHve7XS/hZ/BI WF/Xr5fpOyKMA9AhA6pb4CVisCDs2ttEcGkoY9AneR+A++nT8fgzZfN/0przzeXQ Odwpe9JsbdvBwP1Iraw5YNzOlknZAUK93rk688lKAGYBhreJvXyRWH0+qciI0fH3 IkhwpnCeukzPZucaR8NCNWSgnlx551TkAxYAEshYtIKVs9c9gZAo/9k/9iBL0NgP sIpLtERf5ERbWbWEp2gIAtHeIW2heXCFpGtfHVr4oxoDk/NMmL6sdNArleNdGzkH 2HFl0tHIG+QsEUZ/iHSlhiXtQpofbzpXX26rFVz7mTMdaXIHXan3Z8oL40580gc= =7HM1 -----END PGP SIGNATURE----- From nobody Wed Feb 10 00:14:55 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8701A00B4; Wed, 10 Feb 2016 00:14:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160210081454.19683.17186.idtracker@ietfa.amsl.com> Date: Wed, 10 Feb 2016 00:14:54 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-codecs-for-interop-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 08:14:54 -0000 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 of the IETF. Title : Additional WebRTC audio codecs for interoperability. Author : Stephane Proust Filename : draft-ietf-rtcweb-audio-codecs-for-interop-05.txt Pages : 11 Date : 2016-02-10 Abstract: To ensure a baseline level of interoperability between WebRTC endpoints, a minimum set of required codecs is specified. However, to maximize the possibility to establish the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser. This document provides some guidelines on the suitable codecs to be considered for WebRTC endpoints to address the most relevant interoperability use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio-codecs-for-interop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-audio-codecs-for-interop-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-codecs-for-interop-05 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 nobody Wed Feb 10 00:18:52 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845141A00CA for ; Wed, 10 Feb 2016 00:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vArAOWDzckfi for ; Wed, 10 Feb 2016 00:18:48 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E041A0074 for ; Wed, 10 Feb 2016 00:18:48 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 28992264472; Wed, 10 Feb 2016 09:18:46 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.43]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 02B7A4C048; Wed, 10 Feb 2016 09:18:46 +0100 (CET) Received: from OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%19]) with mapi id 14.03.0279.002; Wed, 10 Feb 2016 09:18:45 +0100 From: To: Alissa Cooper , "rtcweb@ietf.org" Thread-Topic: [rtcweb] AD evaluation: draft-ietf-rtcweb-audio-codecs-for-interop-04 Thread-Index: AQHRWV4ow8tk1DXDjU6y/mSimYWU8p8lA/HA Date: Wed, 10 Feb 2016 08:18:44 +0000 Message-ID: <8781_1455092326_56BAF266_8781_1402_1_2842AD9A45C83B44B57635FD4831E60A0CD3EB14@OPEXCLILM44.corporate.adroot.infra.ftgroup> References: <36299A4C-DEF7-4A4A-9CC2-0D9AC1BFCE47@cooperw.in> In-Reply-To: <36299A4C-DEF7-4A4A-9CC2-0D9AC1BFCE47@cooperw.in> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.2.8.153315 Archived-At: Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-audio-codecs-for-interop-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 08:18:50 -0000 VGhhbmtzIEFsaXNzYSBmb3IgeW91IHJldmlldw0KSSd2ZSBqdXN0IHN1Ym1pdHRlZCBhIDA1IHZl cnNpb24gY2FwdHVyaW5nIGFsbCB5b3VyIGNvbW1lbnRzIChubyBvdGhlciBjaGFuZ2VzIGV4Y2Vw dCB0aGUgb25lIHlvdSBzdWdnZXN0KQ0KDQpLaW5kIHJlZ2FyZHMNCg0KU3TDqXBoYW5lIA0KDQot LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1i b3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEFsaXNzYSBDb29wZXINCkVudm95w6nCoDog amV1ZGkgMjggamFudmllciAyMDE2IDAwOjU1DQrDgMKgOiBydGN3ZWJAaWV0Zi5vcmcNCk9iamV0 wqA6IFtydGN3ZWJdIEFEIGV2YWx1YXRpb246IGRyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLWNvZGVj cy1mb3ItaW50ZXJvcC0wNA0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBpbiBwcmVw YXJhdGlvbiBmb3IgSUVURiBMQy4gSSBoYXZlIGEgZmV3IHN1YnN0YW50aXZlIGNvbW1lbnRzIHRo YXQgbmVlZCB0byBiZSByZXNvbHZlZCBmb3IgSUVURiBMQy4gSeKAmXZlIGFsc28gaW5jbHVkZWQg c29tZSBuaXRzIGJlbG93IHRoYXQgc2hvdWxkIGJlIHJlc29sdmVkIHRvZ2V0aGVyIHdpdGggTEMg Y29tbWVudHMuDQoNClN1YnN0YW50aXZlIGNvbW1lbnRzOg0KDQooMSkgVHlwaWNhbGx5IHdoZW4g YSBsb25nIGF1dGhvciBsaXN0IGdldHMgc2hpZnRlZCB0byB0aGUgQWNrbm93bGVkZ21lbnRzIHNl Y3Rpb24gdGhlIHJlbWFpbmluZyBuYW1lIGF0IHRoZSB0b3AgZ2V0IG1hcmtlZCBhcyBhbiBlZGl0 b3IuIFRoYXQgc2VlbXMgYXBwcm9wcmlhdGUgaW4gdGhpcyBjYXNlLg0KDQooMikgVGhlIGRvY3Vt ZW50IHVzZXMgdGhlIHRlcm0g4oCcV2ViUlRDIGNsaWVudOKAnSBpbiBhIGZldyBwbGFjZXMuIEkg d291bGQgc3VnZ2VzdCByZWZlcmVuY2luZyB0aGUgdGVybWlub2xvZ3kgZGVmaW5lZCBpbiBkcmFm dC1pZXRmLXJ0Y3dlYi1vdmVydmlldyByZWdhcmRpbmcgZW5kcG9pbnRzL2RldmljZXMvYnJvd3Nl cnMgYW5kIGNvbnNpc3RlbnRseSB1c2luZyB0aGUgdGVybWlub2xvZ3kgZGVmaW5lZCB0aGVyZSAo b3IsIGlmIG5vdCwgZXhwbGFpbiB3aHkgbm90KS4NCg0KKDMpIFRoZSBjbGFpbXMgdGhyb3VnaG91 dCBTZWN0aW9uIDQgYWJvdXQgdGhlIG51bWJlciBvZiB0ZXJtaW5hbHMgYWZmZWN0ZWQgc291bmQg bGlrZSBtYXJrZXRpbmcuIFdhbnRlZCB0byBjaGVjayBpZiB0aGUgV0cgaXMgY29uZmlkZW50IHRo YXQgdGhlc2UgY2xhaW1zIG5lZWQgdG8gYmUgaW4gdGhlIGRvY3VtZW50Lg0KDQooNCkgU2VjdGlv biA0LjQgc2VlbXMgc3VwZXJmbHVvdXMgYW5kIHNob3VsZCBiZSBkZWxldGVkLg0KDQoNCk5pdHM6 DQoNCj0gU2VjdGlvbiAxID0NCg0Kcy90byBpbmNsdWRlIGluIHRoZSBvZmZlciBvdGhlciBzdWl0 YWJsZSBhdWRpbyBjb2RlY3MvdG8gaW5jbHVkZSBpbiB0aGUgb2ZmZXIgb3RoZXIgc3VpdGFibGUg YXVkaW8gY29kZWNzIGJleW9uZCB0aG9zZSB0aGF0IGFyZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50 Lw0KDQo9IFNlY3Rpb24gNSA9DQoNCnMvdG8gYWxzbyByZXBvcnQgbW9yZSBzcGVjaWZpY2FsbHkv dG8gYWxzbyByZWZlciBtb3JlIHNwZWNpZmljYWxseS8NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp LgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh dzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Wed Feb 10 10:35:06 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D829F1B2E7F for ; Wed, 10 Feb 2016 10:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhYrMfa7qcnJ for ; Wed, 10 Feb 2016 10:35:02 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2C01ACE31 for ; Wed, 10 Feb 2016 10:35:02 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1AIZ1XW044032 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Feb 2016 12:35:02 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local From: Adam Roach To: draft-shieh-rtcweb-ip-handling@tools.ietf.org, "rtcweb@ietf.org" Message-ID: <56BB82D5.3000408@nostrum.com> Date: Wed, 10 Feb 2016 12:35:01 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] Comments on draft-shieh-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 18:35:05 -0000 I've reviewed the RTCWEB IP handling document, and believe that the guidance it provides is correct. I have significant feedback on rationale, precision, and implications. I've also included a number of editorial suggestions. In document order: > with both the VPN as well as the ISP public address over that > the VPN runs over. "...address that the VPN runs over." (or "...address over which the VPN runs"). > o By default, WebRTC should follow the route for HTTP traffic, when > this is easy to determine (i.e. not considering proxies). I don't think this is quite the right formulation. By default, WebRTC media should follow normal IP routing rules. In many cases, this will be the same as HTTP traffic, but that won't always be the case. The solution you describe -- binding to 0.0.0.0 or :: -- makes use of the kernel routing table, which may make a different decision than it did for the corresponding web site. > o By default, support for host-host connections should be > maintained. For people who have not been involved in the conversation so far, this is a pretty confusing description of what you're trying to say. I suggest something more like: "By default, WebRTC should enable direct connections between hosts in the same private network space [RFC1918] [RFC3927] [RFC4193] [RFC4862] [RFC5735]." > connect()ing those sockets to a public > destination (e.g. "8.8.8.8"), You're going to want to replace 'e.g. "8.8.8.8"' before publication is requested. Use of literal IP addresses in RFCs has become very strongly discouraged. I would suggest something like "e.g., the STUN or TURN server's address". I would also suggest the document indicate that this technique does not require sending any traffic to the chosen address, and that it is simply a common trick for applications to retrieve information from the kernel about its routing table. > o WebRTC incorporates an explicit permission grant for access to > local audio and video, which are typically much more sensitive > than the aforementioned IP address information. If the user has > consented to media access, this should also allow WebRTC to gather > all possible candidates and determine the absolute best route for > media traffic. [This is the most important comment I have on the document] I don't think the rationale here follows. To be clear, I agree with the overall direction, but I think putting this in front of the security guys is asking for the draft to be shredded into ribbons. The notion that "camera access" is strictly more sensitive than "IP address" doesn't hold up to scrutiny. I propose replacing this bullet with something more along the lines of: "When used with audio and video devices, WebRTC requires explicit user permission to access those devices. We propose that this permission grant be expanded to include consent to access all IP addresses associated with the user agent. This permission grant will allow WebRTC to gather all possible candidates and determine the the most optimal route for media traffic. Combining these permission grants -- rather than having the user grant permission individually -- is a considered balance that takes into account privacy, user notification fatigue, media performance, and informed consent. A key factor in this consideration is the implication of using cameras and microphones: when using physical devices with WebRTC, the user is typically engaging in a conversational session. Conversations are significantly more sensitive to network latency than most other real-time operations, and therefore benefit much more from the use of the most optimal network path available." > Mode 1 Enumerate all addresses: WebRTC will bind to all interfaces > individually and use them all to ping STUN servers or peers. I think "ping" isn't really what you want. Perhaps "...use them all to attempt communication with STUN servers, TURN servers, and WebRTC peers." > access, as indicated in design idea #3 above. If you're going to refer to the bullets by number, please make them a numbered list instead of unnumbered bullets. If you're using xml2rfc, use . > Mode 2 Default route + the single associated local address: By > binding solely to the "any" address, media packets will flow > through the same route as normal HTTP traffic. "...media packets will follow the kernel routing table rules, which typically will be the same as the associated HTTP traffic." > Mode 3 Default route only: This is the the same as Mode 2, except > that the associated private address is not provided, which > may cause traffic to hairpin through NAT or fall back to the > application TURN server, with resulting quality implications. "...hairpin through the NAT, call back to the application TURN server, or fail altogether..." > Mode 4 Force TCP and proxy: This is disables any use of UDP and > forces use of TCP to connect to the TURN server or peer. If > a proxy server is configured, the TCP traffic will be sent > through the proxy, with resulting quality implications. Can we strike "TCP" from this option? Yes, most of the time -- at least for now -- this will be TCP. But the important behavior here is that traffic go through a specific, configured proxy server. Basically, I want it to be clear that using a provisioned TURN server in the same way as one uses a provisioned HTTP proxy has the same privacy properties, and should be considered to be the same mode of operation. Propose: "Force proxy: This forces all WebRTC media traffic through a proxy. If only an HTTP proxy server or TCP-only SOCKS server is configured, the use of UDP will be disabled, and media will be sent as TCP traffic through the proxy. The use of TCP for media degrades its performance significantly." > For example, Chrome users can install the WebRTC > Network Limiter extension for this configuration. I'm not sure this makes sense to go into an RFC. It's almost certainly going to be irrelevant and sound very quaint in 5 to 10 years. > The recommendations mentioned in this document may cause breakage to > certain WebRTC applications. "...may cause certain WebRTC applications to malfunction or operate in a degraded fashion." > o Applications should deploy a TURN server with support for both UDP > and TCP connections to the server. This ensures that connectivity > can still be established, even when Mode 3 or Mode 4 are in use. "This ensures that connectivity can typically be established, even when Mode 3 or Mode 4 are in use." Hairpinning -- even through a TURN server -- isn't always going to work. It will most of the time, but not always. Hence, "typically". Thanks! /a From nobody Sun Feb 14 15:23:58 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D55A1A8778 for ; Sun, 14 Feb 2016 15:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LtWwk2l-rf5 for ; Sun, 14 Feb 2016 15:23:56 -0800 (PST) Received: from smtp65.ord1c.emailsrvr.com (smtp65.ord1c.emailsrvr.com [108.166.43.65]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A1E1A8777 for ; Sun, 14 Feb 2016 15:23:55 -0800 (PST) Received: from smtp1.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 13FA9380186; Sun, 14 Feb 2016 18:23:55 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9E04C38015E; Sun, 14 Feb 2016 18:23:54 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Sun, 14 Feb 2016 18:23:55 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Cullen Jennings In-Reply-To: Date: Sun, 14 Feb 2016 16:23:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <56A17900-798D-49C6-910D-F825BEBE4AC0@iii.ca> References: To: =?utf-8?Q?Victor_Pascual_=C3=81vila?= X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-11 -- Section-3.4 Middle box related functions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 23:23:57 -0000 > On Feb 9, 2016, at 2:02 AM, Victor Pascual Avila = wrote: >=20 > Can we assume real-time media over a TCP-based access works fine? No - in many real world circumstances it will be really messed up and = only work intermittently. But the main idea of ICE is try a range of = things and choose the best thing that works.=20 From nobody Tue Feb 16 05:21:24 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD381A21AE for ; Tue, 16 Feb 2016 05:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5epTCXLNihBj for ; Tue, 16 Feb 2016 05:21:21 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415D91A0098 for ; Tue, 16 Feb 2016 05:21:21 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-2c-56c3224fb80d Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A1.E7.28465.F4223C65; Tue, 16 Feb 2016 14:21:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Tue, 16 Feb 2016 14:21:18 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: Draft new version: BUNDLE-26 Thread-Index: AdFovJJgmDuP5RdQSNWsl2CxzJ/xJQAAFKBA Date: Tue, 16 Feb 2016 13:21:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37DF9C14@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37DF9BDA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37DF9BDA@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37DF9C14ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbHdSddf6XCYwfmNchZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9/SZ2wFlxQqZm/7zdzAOF22i5GTQ0LAROJP6zQ2CFtM4sK9 9UA2F4eQwGFGien7VjNBOIsZJb41LwNyODjYBCwkuv9pgzSICKhLXH54gR3EFhbQlJg5bS8r RFxLYuXvs+wQtpHEi9stLCA2i4CqxNHef+wgY3gFfCXe7bEBCQsBmT2N+5lAbE4BP4nfHfPB bEage76fWgNmMwuIS9x6AhGXEBCQWLLnPDOELSrx8vE/VghbUeLjq32MEPX5Equ2ngKr5xUQ lDg58wnLBEaRWUhGzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFqcWlyc m25krJdalJlcXJyfp5eXWrKJERhBB7f81t3BuPq14yFGAQ5GJR7egohDYUKsiWXFlbmHGCU4 mJVEeP+9AgrxpiRWVqUW5ccXleakFh9ilOZgURLnXeO8PkxIID2xJDU7NbUgtQgmy8TBKdXA 6J/S8/uN857emSUOkhfd6gJN+C7/X+oaF6rpqWi90jl4WswDeQ8Db2fhw9lcLvz7axQXL8yS kVvKnnHk/If9uWuPK4gd/eUTpPhjxY1L0xfem1Vy4+92wRlCsRof8l78drCq2GC9Z4oyW3zn /xa+B/aRb+8uFNDWq3Fv71oT578qSLj62vQVSizFGYmGWsxFxYkAecS9CpwCAAA= Archived-At: Subject: [rtcweb] FW: Draft new version: BUNDLE-26 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 13:21:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37DF9C14ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 16. helmikuuta 2016 15:20 To: mmusic@ietf.org Subject: [MMUSIC] Draft new version: BUNDLE-26 Hi, I've submitted a new version (-26) of BUNDLE. I have added text related to = exclusive RTP/RTPC mux to section 10.3 (and subsections). Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37DF9C14ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI,=

 

Christer

 

mmusi= c [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 16. helmikuuta 2016 15:20
To: mmusic@ietf.org
Subject: [MMUSIC] Draft new version: BUNDLE-26

 

Hi,

 

I’ve submitted a new vers= ion (-26) of BUNDLE. I have added text related to exclusive RTP/RTPC mux to= section 10.3 (and subsections).

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37DF9C14ESESSMB209erics_-- From nobody Tue Feb 16 05:22:58 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC4E1B3464 for ; Tue, 16 Feb 2016 05:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHot0QiTC8xw for ; Tue, 16 Feb 2016 05:22:55 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967291A6F0E for ; Tue, 16 Feb 2016 05:22:54 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-0b-56c322acde0e Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E1.9C.15637.CA223C65; Tue, 16 Feb 2016 14:22:52 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Tue, 16 Feb 2016 14:22:52 +0100 From: Christer Holmberg To: Ted Hardie , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Updated doodle poll link Thread-Index: AQHRXRGIzkrN1LKQ50WP60gnmAq8UZ8cK1aAgBKUsCA= Date: Tue, 16 Feb 2016 13:22:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37DF9C4D@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37DF9C4DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7je4apcNhBq+Oqlms/dfObtE4186B yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyri+cRlbQZtDxcU5+5gbGBfYdTFyckgImEhM /rGSFcIWk7hwbz0biC0kcJhR4vt+sS5GLiB7MaPEsS/fWboYOTjYBCwkuv9pg9SICHhIbPr7 G6xXWEBPYv3URkaIuL7Eq9mTWSFsK4m29h52EJtFQFVi46cfTCBjeAV8Jf6cCYEYP51RYs6y w8wgNZwCgRI3t75lArEZge75fmoNmM0sIC5x68l8Jog7BSSW7DnPDGGLSrx8/A/qfkWJj6/2 MULU50u8vngfrIZXQFDi5MwnLBMYRWYhGTULSdksJGWzgM5jFtCUWL9LH6JEUWJK90N2CFtD onXOXHZk8QWM7KsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAiPq4JbfqjsYL79xPMQowMGo xMNbEHEoTIg1say4MvcQowQHs5II779XQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8a5zXhwkJ pCeWpGanphakFsFkmTg4pRoYFbUXGbse84rdv8LH/N0TqWNq4s8M0sL/9zK/yg9ZZLLiPtM3 l46Fl8uObCwS7p70J0N7/QP/tNSWZG6uJj4eludf0vXvXGXkurnmy6nK1c087eLPPjFPEp8b o7Xz2zH20hD/xclSNZrXnhU4zNrwUeXudJeXtYvzplw3m3PyIEuvJ/sEy1IDJZbijERDLeai 4kQAIU1w+KQCAAA= Archived-At: Subject: Re: [rtcweb] Updated doodle poll link X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 13:22:56 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37DF9C4DESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGlkIHRoZSBjaGFpcnMgcGljayBhIGRhdGUvdGltZSBmb3IgdGhlIG1lZXRpbmc/DQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgVGVkIEhhcmRpZQ0KU2VudDogNC4gaGVsbWlrdXV0YSAyMDE2 IDIwOjM4DQpUbzogcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gVXBkYXRl ZCBkb29kbGUgcG9sbCBsaW5rDQoNCk9uIE1vbiwgRmViIDEsIDIwMTYgYXQgODo1NiBBTSwgVGVk IEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPG1haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb20+PiB3 cm90ZToNCkhlcmUgaXMgdGhlIHVwZGF0ZWQgbGluayB3aXRoIHRpbWV6b25lIHNlbGVjdGlvbiBl bmFibGVkOg0KDQpodHRwOi8vZG9vZGxlLmNvbS9wb2xsLzd2cTR1NHl5ZjNzZG1nbjQNCnJlZ2Fy ZHMsDQpUZWQNCg0K4oCLVGhlcmUgYXJlIGN1cnJlbnRseSB0ZW4gb3Igc28gcmVwbGllcyB0byB0 aGUgcG9sbCwgYW5kIHdlJ2QgbGlrZSB0byBoYXZlIG1vcmUgYmVmb3JlIG1ha2luZyBhIGRlY2lz aW9uLiAgUGxlYXNlIGZpbGwgdGhlIHBvbGwgaW4gYnkgRnJpZGF5LCBGZWJydWFyeSAxMnRoLCAy MDE2Lg0KdGhhbmtzIQ0KVGVk4oCLDQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37DF9C4DESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkdhcmFtb25kOw0KCXBhbm9zZS0xOjIgMiA0IDQgMyAz IDEgMSA4IDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCAyLjBjbSA3MC44 NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRkkiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGlkIHRoZSBjaGFp cnMgcGljayBhIGRhdGUvdGltZSBmb3IgdGhlIG1lZXRpbmc/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGVkIEhhcmRpZTxicj4N CjxiPlNlbnQ6PC9iPiA0LiBoZWxtaWt1dXRhIDIwMTYgMjA6Mzg8YnI+DQo8Yj5Ubzo8L2I+IHJ0 Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gVXBkYXRlZCBk b29kbGUgcG9sbCBsaW5rPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIE1vbiwgRmViIDEsIDIwMTYgYXQgODo1NiBBTSwgVGVkIEhhcmRpZSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRlZC5pZXRmQGdt YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dhcmFtb25kJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5IZXJlIGlzIHRoZSB1cGRhdGVkIGxpbmsgd2l0aCB0aW1lem9uZSBz ZWxlY3Rpb24gZW5hYmxlZDo8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwOi8vZG9vZGxlLmNvbS9w b2xsLzd2cTR1NHl5ZjNzZG1nbjQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZG9vZGxlLmNvbS9w b2xsLzd2cTR1NHl5ZjNzZG1nbjQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2FyYW1vbmQmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPnJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dhcmFtb25k JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+4oCLPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dh cmFtb25kJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGVyZSBhcmUgY3VycmVudGx5IHRlbiBv ciBzbyByZXBsaWVzIHRvIHRoZSBwb2xsLCBhbmQgd2UnZCBsaWtlIHRvIGhhdmUgbW9yZSBiZWZv cmUgbWFraW5nIGEgZGVjaXNpb24uJm5ic3A7IFBsZWFzZSBmaWxsIHRoZSBwb2xsIGluIGJ5IEZy aWRheSwgRmVicnVhcnkgMTJ0aCwgMjAxNi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtHYXJhbW9uZCZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+dGhhbmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtHYXJhbW9u ZCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGVkPC9zcGFuPuKAizxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtHYXJhbW9uZCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37DF9C4DESESSMB209erics_-- From nobody Tue Feb 16 10:02:28 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09DF1B3078 for ; Tue, 16 Feb 2016 10:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDDP-XuQ5iWd for ; Tue, 16 Feb 2016 10:02:21 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED88B1B2D10 for ; Tue, 16 Feb 2016 10:02:20 -0800 (PST) Received: by mail-qg0-x233.google.com with SMTP id b67so139367296qgb.1 for ; Tue, 16 Feb 2016 10:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rpxMPciKemL2Sg7VbXa4fncM5XrXnfItI5Uk1TIO4tQ=; b=LJc0JmMC2CzPY0oi0X5Dornnpvz4XwgoCSEHayetlK1P8T3udwFWb55VErz/MVOh2W pPtRKlnTxFvhcxgNC05ehVBfS3cDUJ+3zvZ4H1tpLL3JGyNFUHVtVA4/+KGkV0LZvEh/ I1lEeic2M5EhvHhwDkb1gcnoJd1bygkwypb8v1NZf8fYw/huBep6DA2OPdXFRaxFsPCN ZAjYuwMk7f0pu06B2FnlMAKC9fXZ4mHxu6q7DMQ16EYsO6an5/kz+CEmBGOa2LmcfD8h UhLKglY+dCqIM+A4cG+Qpup2MEfwbyblGegKl9mJ0THHqXKrDnsA3x7j8rbMxYUMMXQD 3nnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rpxMPciKemL2Sg7VbXa4fncM5XrXnfItI5Uk1TIO4tQ=; b=Qsx5Zho0lvpqPpV16q4nFQWsIRmGC+e93BHZBNKzmqQi8Wtp7S6jlXQAykB3SDXDF8 kQrDzLlDXAvTY8K3K+nkLYyhFXZPxfGg9Q3AmR0t86fbNpH7jYvls+wjDC1USYcIqGis CgrbvMfPQfBPND6eYzmZfQgzKH+P+4FAy4Ze35ETlfHh2bCp8A4qZKg3L1xRFtRf1hI3 7JK7eqsvgHno/xnbXjn/WGz67ROL9AOyKi7dn6JM6SaQQDAO+HfxCBJxC1Z/nZTZ//o4 Fymzrdgl1ij9F2/V3onZVLFh5ninpZjPKvp2qMSmuneP6kBIc3l5iB82Q9gA5Tt9TZ5B k8Ag== X-Gm-Message-State: AG10YOSNgxhQqIsky/I99iEEVpt1OJvj2w2EWbsVSgtNK1C9fo3/VKsScssnqyG0qVjAJFyJhzgNinpw3QhBbw== X-Received: by 10.140.94.50 with SMTP id f47mr29612981qge.0.1455645740167; Tue, 16 Feb 2016 10:02:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Tue, 16 Feb 2016 10:02:00 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37DF9C4D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37DF9C4D@ESESSMB209.ericsson.se> From: Ted Hardie Date: Tue, 16 Feb 2016 10:02:00 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113a9896431d70052be6efef Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Updated doodle poll link X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 18:02:23 -0000 --001a113a9896431d70052be6efef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 16, 2016 at 5:22 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Did the chairs pick a date/time for the meeting? > > > > Regards, > > > > Christer > > Hi Christer, We did not yet pick a time, but will likely do so at our meeting on Thursday. If folks wish to review the poll and adjust their times, feel free to do so (if you find that problematic, just enter a new line and send us a note that you've done so). Ted > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Ted Hardie > *Sent:* 4. helmikuuta 2016 20:38 > *To:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Updated doodle poll link > > > > On Mon, Feb 1, 2016 at 8:56 AM, Ted Hardie wrote: > > Here is the updated link with timezone selection enabled: > > http://doodle.com/poll/7vq4u4yyf3sdmgn4 > > regards, > > Ted > > > > =E2=80=8BThere are currently ten or so replies to the poll, and we'd like= to have > more before making a decision. Please fill the poll in by Friday, Februa= ry > 12th, 2016. > > thanks! > > Ted=E2=80=8B > > > > > --001a113a9896431d70052be6efef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 16, 2016 at 5:22 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Did the ch= airs pick a date/time for the meeting?

=C2= =A0

Regards,

=C2= =A0

Christer


Hi Christer,

We did not yet pick a time, but will likely do so at our meeting o= n Thursday.=C2=A0 If folks wish to review the poll and adjust their times, = feel free to do so (if you find that problematic, just enter a new line and= send us a note that you've done so).

Ted

=C2=A0

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: 4. helmikuuta 2016 20:38
To: rtcweb@ietf= .org
Subject: Re: [rtcweb] Updated doodle poll link<= /p>

=C2=A0

On Mon, Feb 1, 2016 at 8:56 AM, Ted Hardie <ted.ietf@gmail.com&g= t; wrote:

Here is the updated link with= timezone selection enabled:

http:= //doodle.com/poll/7vq4u4yyf3sdmgn4

regards,=

Ted

=C2=A0

=E2=80=8BThere are currently= ten or so replies to the poll, and we'd like to have more before makin= g a decision.=C2=A0 Please fill the poll in by Friday, February 12th, 2016.=

thanks!<= /p>

Ted=E2=80=8B

=C2=A0

=C2=A0


--001a113a9896431d70052be6efef-- From nobody Tue Feb 16 14:34:59 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B321A911F for ; Tue, 16 Feb 2016 14:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.383 X-Spam-Level: X-Spam-Status: No, score=-1.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3nmCpQvi4VI for ; Tue, 16 Feb 2016 14:34:55 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8121A9110 for ; Tue, 16 Feb 2016 14:34:54 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id c200so185323923wme.0 for ; Tue, 16 Feb 2016 14:34:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3aVvPx8bAQJjTRG/O5xpt7CofVUJjxD8WWq041x7olI=; b=mgcHTBX0WFkk/twEen42uLd6LFAdCvcl8p5XKVy/zYNf9jUpuYtU1OinT9ggYXESz4 9WCoNqZZl3kKIkodA1LdL1d8OecHyeyy1yjM7gykYx9wrAgcxjHBiFr/efZ+nL+pTUv8 SWWzZ/4+odMwZliT6o3hPAFwy+2VLpsvLcCOleHMQgU0wXWHkmaqub6D4eTMoQl/u6pR OtSLXyNQ/P5m+GgV6pqdgOxphLIFZCYDvDm18RDebPHupywtiNcIgt+FrdfbtFSzACE5 lrHaAgGnQJ/D/YWfXr1VGlBckGQtvwSdt7CUIDXrLhVByoS7E5L9RkHWi0gsCM3/dOMI Wigw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3aVvPx8bAQJjTRG/O5xpt7CofVUJjxD8WWq041x7olI=; b=JXuF6Qoxdt/qfVczJ8JVHmnoFjjhwOzOB9FAZP4gi1mqU2CSPa5hRUtcMzolZilwi8 7MRCtaWM2WXQr6Idu+1YqlXPGfMYtpqoYxCfRaA7f1DjqPfPDxpKqJvCZ5zJrtenT/NJ MHqVxkUvZtDuAA+4sZPybDoNk5mAyg6op1NZzdpPmPUKU2JbKIVxWXDsHtFY3pA58Jw5 MFNCIITrNqya7W2XFdEmbAxZySONigCQTJP3Jzjnfh73iE3nQ8M8hGnTw1wALwOxQMv6 V4t8Srkfixvsqw/kpGxBxGCm3KiJ04mgsSuxjXCwxypOo1cc9AgYT07inxN/yfJGDzSW o6rA== X-Gm-Message-State: AG10YOSPCOXjo73La6/W9g5Aaa8TIvFd1d2OtpeNpw+5ErvAoKwIlUiMWMHyi7U7zNgcnup6UzjE57Di9Aafrxkh X-Received: by 10.28.177.85 with SMTP id a82mr20914535wmf.57.1455662093190; Tue, 16 Feb 2016 14:34:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.195.130 with HTTP; Tue, 16 Feb 2016 14:34:33 -0800 (PST) In-Reply-To: <56BB82D5.3000408@nostrum.com> References: <56BB82D5.3000408@nostrum.com> From: Justin Uberti Date: Tue, 16 Feb 2016 14:34:33 -0800 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a114543d8faa1e2052beabddf Archived-At: Cc: draft-shieh-rtcweb-ip-handling@tools.ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-shieh-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 22:34:58 -0000 --001a114543d8faa1e2052beabddf Content-Type: text/plain; charset=UTF-8 Thanks for the detailed review. Most of these are noncontroversial - the one that probably needs more discussion is the question around a provisioned TURN server. On Wed, Feb 10, 2016 at 10:35 AM, Adam Roach wrote: > I've reviewed the RTCWEB IP handling document, and believe that the > guidance it provides is correct. I have significant feedback on rationale, > precision, and implications. I've also included a number of editorial > suggestions. > > In document order: > > with both the VPN as well as the ISP public address over that >> the VPN runs over. >> > > "...address that the VPN runs over." (or "...address over which the VPN > runs"). > good catch. > > > o By default, WebRTC should follow the route for HTTP traffic, when >> this is easy to determine (i.e. not considering proxies). >> > > I don't think this is quite the right formulation. By default, WebRTC > media should follow normal IP routing rules. In many cases, this will be > the same as HTTP traffic, but that won't always be the case. The solution > you describe -- binding to 0.0.0.0 or :: -- makes use of the kernel routing > table, which may make a different decision than it did for the > corresponding web site. > I see where you are going, but "normal IP routing rules" seems overly vague. I'll try another wording. > > > o By default, support for host-host connections should be >> maintained. >> > > For people who have not been involved in the conversation so far, this is > a pretty confusing description of what you're trying to say. I suggest > something more like: "By default, WebRTC should enable direct connections > between hosts in the same private network space [RFC1918] [RFC3927] > [RFC4193] [RFC4862] [RFC5735]." > Yes, this section could be clearer. > > connect()ing those sockets to a public >> destination (e.g. "8.8.8.8"), >> > > You're going to want to replace 'e.g. "8.8.8.8"' before publication is > requested. Use of literal IP addresses in RFCs has become very strongly > discouraged. I would suggest something like "e.g., the STUN or TURN > server's address". > The STUN/TURN server may not be the right choice (what if DNS is blocked?). But agree it can be any public, stable IP address. > > I would also suggest the document indicate that this technique does not > require sending any traffic to the chosen address, and that it is simply a > common trick for applications to retrieve information from the kernel about > its routing table. > Good idea. > > o WebRTC incorporates an explicit permission grant for access to >> local audio and video, which are typically much more sensitive >> than the aforementioned IP address information. If the user has >> consented to media access, this should also allow WebRTC to gather >> all possible candidates and determine the absolute best route for >> media traffic. >> > > [This is the most important comment I have on the document] > > I don't think the rationale here follows. To be clear, I agree with the > overall direction, but I think putting this in front of the security guys > is asking for the draft to be shredded into ribbons. The notion that > "camera access" is strictly more sensitive than "IP address" doesn't hold > up to scrutiny. > > I propose replacing this bullet with something more along the lines of: > "When used with audio and video devices, WebRTC requires explicit user > permission to access those devices. We propose that this permission grant > be expanded to include consent to access all IP addresses associated with > the user agent. This permission grant will allow WebRTC to gather all > possible candidates and determine the the most optimal route for media > traffic. Combining these permission grants -- rather than having the user > grant permission individually -- is a considered balance that takes into > account privacy, user notification fatigue, media performance, and informed > consent. A key factor in this consideration is the implication of using > cameras and microphones: when using physical devices with WebRTC, the user > is typically engaging in a conversational session. Conversations are > significantly more sensitive to network latency than most other real-time > operations, and therefore benefit much more from the use of the most > optimal network path available." > Agree this could benefit from a more nuanced explanation, and thanks for the suggested text. > > Mode 1 Enumerate all addresses: WebRTC will bind to all interfaces >> individually and use them all to ping STUN servers or peers. >> > > I think "ping" isn't really what you want. Perhaps "...use them all to > attempt communication with STUN servers, TURN servers, and WebRTC peers." > Will reword. > > access, as indicated in design idea #3 above. >> > > If you're going to refer to the bullets by number, please make them a > numbered list instead of unnumbered bullets. If you're using xml2rfc, use > . > OK. > > > Mode 2 Default route + the single associated local address: By >> binding solely to the "any" address, media packets will flow >> through the same route as normal HTTP traffic. >> > > "...media packets will follow the kernel routing table rules, which > typically will be the same as the associated HTTP traffic." > OK. > > Mode 3 Default route only: This is the the same as Mode 2, except >> that the associated private address is not provided, which >> may cause traffic to hairpin through NAT or fall back to the >> application TURN server, with resulting quality implications. >> > > "...hairpin through the NAT, call back to the application TURN server, or > fail altogether..." > OK. > > Mode 4 Force TCP and proxy: This is disables any use of UDP and >> forces use of TCP to connect to the TURN server or peer. If >> a proxy server is configured, the TCP traffic will be sent >> through the proxy, with resulting quality implications. >> > > Can we strike "TCP" from this option? Yes, most of the time -- at least > for now -- this will be TCP. But the important behavior here is that > traffic go through a specific, configured proxy server. Basically, I want > it to be clear that using a provisioned TURN server in the same way as one > uses a provisioned HTTP proxy has the same privacy properties, and should > be considered to be the same mode of operation. > Propose: "Force proxy: This forces all WebRTC media traffic through a > proxy. If only an HTTP proxy server or TCP-only SOCKS server is configured, > the use of UDP will be disabled, and media will be sent as TCP traffic > through the proxy. The use of TCP for media degrades its performance > significantly." > I'm not sure about this. It really depends on how things should work when a RETURN proxy is provisioned - does mode 3 mean that all traffic on the default interface goes through the proxy, or do we try going through the proxy and going direct simultaneously? If the former, then mode 3 is sufficient. If the latter, then I agree with your approach. But I was thinking the former would be the least surprising behavior. > For example, Chrome users can install the WebRTC >> Network Limiter extension for this configuration. >> > > I'm not sure this makes sense to go into an RFC. It's almost certainly > going to be irrelevant and sound very quaint in 5 to 10 years. > Fair point. > > The recommendations mentioned in this document may cause breakage to >> certain WebRTC applications. >> > > "...may cause certain WebRTC applications to malfunction or operate in a > degraded fashion." > Will reword. > > > o Applications should deploy a TURN server with support for both UDP >> and TCP connections to the server. This ensures that connectivity >> can still be established, even when Mode 3 or Mode 4 are in use. >> > > "This ensures that connectivity can typically be established, even when > Mode 3 or Mode 4 are in use." Hairpinning -- even through a TURN server -- > isn't always going to work. It will most of the time, but not always. > Hence, "typically". > > Agreed, although perhaps it would be better to simply say "assuming the TURN server can be reached". > Thanks! > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a114543d8faa1e2052beabddf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the detailed review. Most of these are noncontr= oversial - the one that probably needs more discussion is the question arou= nd a provisioned TURN server.

On Wed, Feb 10, 2016 at 10:35 AM, Adam Roach <adam@nostrum= .com> wrote:
I've revie= wed the RTCWEB IP handling document, and believe that the guidance it provi= des is correct. I have significant feedback on rationale, precision, and im= plications. I've also included a number of editorial suggestions.

In document order:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with both the VPN as well as the ISP publ= ic address over that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the VPN runs over.

"...address that the VPN runs over." (or "...address over wh= ich the VPN runs").

good catch.=C2= =A0


=C2=A0 =C2=A0 o=C2=A0 By default, WebRTC should follow the route for HTTP t= raffic, when
=C2=A0 =C2=A0 =C2=A0 =C2=A0this is easy to determine (i.e. not considering = proxies).

I don't think this is quite the right formulation. By default, WebRTC m= edia should follow normal IP routing rules. In many cases, this will be the= same as HTTP traffic, but that won't always be the case. The solution = you describe -- binding to 0.0.0.0 or :: -- makes use of the kernel routing= table, which may make a different decision than it did for the correspondi= ng web site.

I see where you are going,= but "normal IP routing rules" seems overly vague. I'll try a= nother wording.=C2=A0


=C2=A0 =C2=A0 o=C2=A0 By default, support for host-host connections should = be
=C2=A0 =C2=A0 =C2=A0 =C2=A0maintained.

For people who have not been involved in the conversation so far, this is a= pretty confusing description of what you're trying to say. I suggest s= omething more like: "By default, WebRTC should enable direct connectio= ns between hosts in the same private network space [RFC1918] [RFC3927] [RFC= 4193] [RFC4862] [RFC5735]."

Yes, t= his section could be clearer.

connect()ing those sockets to a public
=C2=A0 =C2=A0 =C2=A0 =C2=A0destination (e.g. "8.8.8.8"),

You're going to want to replace 'e.g. "8.8.8.8"' befo= re publication is requested. Use of literal IP addresses in RFCs has become= very strongly discouraged. I would suggest something like "e.g., the = STUN or TURN server's address".

The STUN/TURN server may not be the right choice (what if DNS is blocked?= ). But agree it can be any public, stable IP address.=C2=A0

I would also suggest the document indicate that this technique does not req= uire sending any traffic to the chosen address, and that it is simply a com= mon trick for applications to retrieve information from the kernel about it= s routing table.

Good idea.=C2=A0
=

=C2=A0 =C2=A0 o=C2=A0 WebRTC incorporates an explicit permission grant for = access to
=C2=A0 =C2=A0 =C2=A0 =C2=A0local audio and video, which are typically much = more sensitive
=C2=A0 =C2=A0 =C2=A0 =C2=A0than the aforementioned IP address information.= =C2=A0 If the user has
=C2=A0 =C2=A0 =C2=A0 =C2=A0consented to media access, this should also allo= w WebRTC to gather
=C2=A0 =C2=A0 =C2=A0 =C2=A0all possible candidates and determine the absolu= te best route for
=C2=A0 =C2=A0 =C2=A0 =C2=A0media traffic.

[This is the most important comment I have on the document]

I don't think the rationale here follows. To be clear, I agree with the= overall direction, but I think putting this in front of the security guys = is asking for the draft to be shredded into ribbons. The notion that "= camera access" is strictly more sensitive than "IP address" = doesn't hold up to scrutiny.

I propose replacing this bullet with something more along the lines of: &qu= ot;When used with audio and video devices, WebRTC requires explicit user pe= rmission to access those devices. We propose that this permission grant be = expanded to include consent to access all IP addresses associated with the = user agent. This permission grant will allow WebRTC to gather all possible = candidates and determine the the most optimal route for media traffic. Comb= ining these permission grants -- rather than having the user grant permissi= on individually -- is a considered balance that takes into account privacy,= user notification fatigue, media performance, and informed consent. A key = factor in this consideration is the implication of using cameras and microp= hones: when using physical devices with WebRTC, the user is typically engag= ing in a conversational session. Conversations are significantly more sensi= tive to network latency than most other real-time operations, and therefore= benefit much more from the use of the most optimal network path available.= "

Agree this could benefit from a = more nuanced explanation, and thanks for the suggested text.=C2=A0

=C2=A0 =C2=A0 Mode 1=C2=A0 Enumerate all addresses: WebRTC will bind to all= interfaces
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 individually and use them all to = ping STUN servers or peers.

I think "ping" isn't really what you want. Perhaps "...u= se them all to attempt communication with STUN servers, TURN servers, and W= ebRTC peers."

Will reword.=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 access, as indicated in design id= ea #3 above.

If you're going to refer to the bullets by number, please make them a n= umbered list instead of unnumbered bullets. If you're using xml2rfc, us= e <list style=3D"numbers">.

=
OK.=C2=A0


=C2=A0 =C2=A0 Mode 2=C2=A0 Default route + the single associated local addr= ess: By
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 binding solely to the "any&q= uot; address, media packets will flow
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 through the same route as normal = HTTP traffic.

"...media packets will follow the kernel routing table rules, which ty= pically will be the same as the associated HTTP traffic."

OK.=C2=A0

=C2=A0 =C2=A0 Mode 3=C2=A0 Default route only: This is the the same as Mode= 2, except
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that the associated private addre= ss is not provided, which
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 may cause traffic to hairpin thro= ugh NAT or fall back to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 application TURN server, with res= ulting quality implications.

"...hairpin through the NAT, call back to the application TURN server,= or fail altogether..."

OK.=C2=A0<= /div>

=C2=A0 =C2=A0 Mode 4=C2=A0 Force TCP and proxy: This is disables any use of= UDP and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 forces use of TCP to connect to t= he TURN server or peer.=C2=A0 If
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a proxy server is configured, the= TCP traffic will be sent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 through the proxy, with resulting= quality implications.

Can we strike "TCP" from this option? Yes, most of the time -- at= least for now -- this will be TCP. But the important behavior here is that= traffic go through a specific, configured proxy server. Basically, I want = it to be clear that using a provisioned TURN server in the same way as one = uses a provisioned HTTP proxy has the same privacy properties, and should b= e considered to be the same mode of operation.=C2=A0

Propose: "Force proxy: This forces all WebRTC media traffic through a = proxy. If only an HTTP proxy server or TCP-only SOCKS server is configured,= the use of UDP will be disabled, and media will be sent as TCP traffic thr= ough the proxy. The use of TCP for media degrades its performance significa= ntly."

I'm not sure about this= . It really depends on how things should work when a RETURN proxy is provis= ioned - does mode 3 mean that all traffic on the default interface goes thr= ough the proxy, or do we try going through the proxy and going direct simul= taneously?

If the former, then mode 3 is sufficien= t. If the latter, then I agree with your approach.=C2=A0

But I was thinking the former would be the least surprising behavior= .


For example, Chrome users can install the WebRTC
=C2=A0 =C2=A0 Network Limiter extension for this configuration.

I'm not sure this makes sense to go into an RFC. It's almost certai= nly going to be irrelevant and sound very quaint in 5 to 10 years.

Fair point.=C2=A0

=C2=A0 =C2=A0 The recommendations mentioned in this document may cause brea= kage to
=C2=A0 =C2=A0 certain WebRTC applications.

"...may cause certain WebRTC applications to malfunction or operate in= a degraded fashion."

Will reword.= =C2=A0


=C2=A0 =C2=A0 o=C2=A0 Applications should deploy a TURN server with support= for both UDP
=C2=A0 =C2=A0 =C2=A0 =C2=A0and TCP connections to the server.=C2=A0 This en= sures that connectivity
=C2=A0 =C2=A0 =C2=A0 =C2=A0can still be established, even when Mode 3 or Mo= de 4 are in use.

"This ensures that connectivity can typically be established, even whe= n Mode 3 or Mode 4 are in use." Hairpinning -- even through a TURN ser= ver -- isn't always going to work. It will most of the time, but not al= ways. Hence, "typically".

Agreed, although perhaps it would be better to simply say= "assuming the TURN server can be reached".
=C2=A0
Thanks!

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--001a114543d8faa1e2052beabddf-- From nobody Tue Feb 16 15:54:54 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D04E1AD0B9 for ; Tue, 16 Feb 2016 15:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gF_PiLpRFpDq for ; Tue, 16 Feb 2016 15:54:51 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5896B1AD0D6 for ; Tue, 16 Feb 2016 15:54:50 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1GNsUAo009102 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 16 Feb 2016 17:54:30 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Justin Uberti References: <56BB82D5.3000408@nostrum.com> From: Adam Roach Message-ID: <56C3B6B5.1030703@nostrum.com> Date: Tue, 16 Feb 2016 17:54:29 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080307040809010907090105" Archived-At: Cc: draft-shieh-rtcweb-ip-handling@tools.ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-shieh-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 23:54:53 -0000 This is a multi-part message in MIME format. --------------080307040809010907090105 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/16/16 16:34, Justin Uberti wrote: > > Can we strike "TCP" from this option? Yes, most of the time -- at > least for now -- this will be TCP. But the important behavior here > is that traffic go through a specific, configured proxy server. > Basically, I want it to be clear that using a provisioned TURN > server in the same way as one uses a provisioned HTTP proxy has > the same privacy properties, and should be considered to be the > same mode of operation. > > > Propose: "Force proxy: This forces all WebRTC media traffic > through a proxy. If only an HTTP proxy server or TCP-only SOCKS > server is configured, the use of UDP will be disabled, and media > will be sent as TCP traffic through the proxy. The use of TCP for > media degrades its performance significantly." > > > I'm not sure about this. It really depends on how things should work > when a RETURN proxy is provisioned - does mode 3 mean that all traffic > on the default interface goes through the proxy, or do we try going > through the proxy and going direct simultaneously? > > If the former, then mode 3 is sufficient. If the latter, then I agree > with your approach. Well, it's not just TURN servers -- it's anything that operates as a proxy and can deal with UDP traffic. Basically, it's a matter of future-proofing this option. If it makes you feel better, think of this as allowing the use of QUIC proxies in the future, if someone rolled out a QUIC-enabled TURN protocol. Or, if you'd like to look at a protocol that is actually specified (if not widely deployed), consider use with a UDP-enabled SOCKS5 proxy. The point of my comment is that throwing "TCP" into mode 4 seems arbitrary. I'm not saying we have to outline the potential non-TCP cases that may arise; I just want us not to be so shortsighted as to preclude them. /a --------------080307040809010907090105 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/16/16 16:34, Justin Uberti wrote:
Can we strike "TCP" from this option? Yes, most of the time -- at least for now -- this will be TCP. But the important behavior here is that traffic go through a specific, configured proxy server. Basically, I want it to be clear that using a provisioned TURN server in the same way as one uses a provisioned HTTP proxy has the same privacy properties, and should be considered to be the same mode of operation. 

Propose: "Force proxy: This forces all WebRTC media traffic through a proxy. If only an HTTP proxy server or TCP-only SOCKS server is configured, the use of UDP will be disabled, and media will be sent as TCP traffic through the proxy. The use of TCP for media degrades its performance significantly."

I'm not sure about this. It really depends on how things should work when a RETURN proxy is provisioned - does mode 3 mean that all traffic on the default interface goes through the proxy, or do we try going through the proxy and going direct simultaneously?

If the former, then mode 3 is sufficient. If the latter, then I agree with your approach. 

Well, it's not just TURN servers -- it's anything that operates as a proxy and can deal with UDP traffic. Basically, it's a matter of future-proofing this option. If it makes you feel better, think of this as allowing the use of QUIC proxies in the future, if someone rolled out a QUIC-enabled TURN protocol. Or, if you'd like to look at a protocol that is actually specified (if not widely deployed), consider use with a UDP-enabled SOCKS5 proxy.

The point of my comment is that throwing "TCP" into mode 4 seems arbitrary. I'm not saying we have to outline the potential non-TCP cases that may arise; I just want us not to be so shortsighted as to preclude them.

/a
--------------080307040809010907090105-- From nobody Thu Feb 18 06:27:11 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BE01AC3EC for ; Thu, 18 Feb 2016 06:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.294 X-Spam-Level: X-Spam-Status: No, score=0.294 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s7KYe7goY-x for ; Thu, 18 Feb 2016 06:27:09 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519671ACD58 for ; Thu, 18 Feb 2016 06:27:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E50147C773D; Thu, 18 Feb 2016 15:26:58 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGmGwI2CAaUO; Thu, 18 Feb 2016 15:26:57 +0100 (CET) Received: from [IPv6:2620:0:1043:fd00:56f:9811:9b6d:2ca7] (unknown [IPv6:2620:0:1043:fd00:56f:9811:9b6d:2ca7]) by mork.alvestrand.no (Postfix) with ESMTPSA id C73647C7738; Thu, 18 Feb 2016 15:26:56 +0100 (CET) User-Agent: K-9 Mail for Android In-Reply-To: <56A17900-798D-49C6-910D-F825BEBE4AC0@iii.ca> References: <56A17900-798D-49C6-910D-F825BEBE4AC0@iii.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----E1HTXO6UOSYYN9PF5TT37YOM0BFZSG" Content-Transfer-Encoding: 8bit From: Harald Alvestrand Date: Thu, 18 Feb 2016 15:26:53 +0100 To: Cullen Jennings , =?ISO-8859-1?Q?Victor_Pascual_=C1vila?= Message-ID: <00D3AC65-0338-45A0-8A5F-1A70F3D1B7CC@alvestrand.no> Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-transports-11 -- Section-3.4 Middle box related functions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 14:27:11 -0000 ------E1HTXO6UOSYYN9PF5TT37YOM0BFZSG Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 We can assume it works better than no connection. If both are allowed by firewalls, UDP will work better in ~all cases. Den 15. februar 2016 00:23:53 CET, skrev Cullen Jennings : > >> On Feb 9, 2016, at 2:02 AM, Victor Pascual Avila > wrote: >> >> Can we assume real-time media over a TCP-based access works fine? > >No - in many real world circumstances it will be really messed up and >only work intermittently. But the main idea of ICE is try a range of >things and choose the best thing that works. > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------E1HTXO6UOSYYN9PF5TT37YOM0BFZSG Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit We can assume it works better than no connection. If both are allowed by firewalls, UDP will work better in ~all cases.

Den 15. februar 2016 00:23:53 CET, skrev Cullen Jennings <fluffy@iii.ca>:

 On Feb 9, 2016, at 2:02 AM, Victor Pascual Avila <victor.pascual.avila@gmail.com> wrote:
 
 Can we assume real-time media over a TCP-based access works fine?

No - in many real world circumstances it will be really messed up and only work intermittently. But the main idea of ICE is try a range of things and choose the best thing that works. 



rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------E1HTXO6UOSYYN9PF5TT37YOM0BFZSG-- From nobody Thu Feb 18 10:54:22 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843A31B2FD3 for ; Thu, 18 Feb 2016 10:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81sA9WZWWcvp for ; Thu, 18 Feb 2016 10:54:18 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8F11B2C11 for ; Thu, 18 Feb 2016 10:54:16 -0800 (PST) Received: by mail-qg0-x22a.google.com with SMTP id b67so44101847qgb.1 for ; Thu, 18 Feb 2016 10:54:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=BxHp43yp3uAXTrtZvdczQwCf2J6u6U0ZkyaEUz/DClY=; b=fbjDABELhJr5KkC00AYwc47xy1BaP34kMulWlTIHjIlYnhWSq8/wRrbp7oqUk10WOb KJZR6ZSlg7Jj9oK5CbPyDLfiqxS0tZbAMjNoXFZqVwtaj33lSZC7GzwhpsXKxELdPs9D uKytPvrjHR3sTxJ8FcX7tnpHBC4cbYVPeRKcXoT4rJDhsy74iE7kIYWdEfemVGpvvIRE WfEMZ8c0ua3RAlmbzHNUCcyDgV9CpXaIN/Op1CI7SzDXGOYsNAfeuKlUhXR2vRlHfAzO /VKfQJyIfV3Lf0z6GXvfoGVRCNnlRkKVW+y4aUc+AuIDjzHgmQS27kC1zuUCB4SZnltr fb2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=BxHp43yp3uAXTrtZvdczQwCf2J6u6U0ZkyaEUz/DClY=; b=ZRgNJDJ+q4whwWDGJq8q80muD6VDxoGo1/ULFvG9jlOeXnHGG4lURMhyh/rKUPj5am 1+ABqLJfoBXMWpewWmOziu6p3r/ETLdLfMFirPSirZV+HGerGqP55yUYBj9VjHiDvpOK /uL5C6pFQFovNnvnW+L4N94Uj5s/GXM8IncvkaLKXb8pirIV327upr9FmwDP58i4CuAk uBpWFP4tCbWRD8fjoxC7dNVBDFhhem/Mq9YYEk1NuI24s9QqS3Qp+tu/6nBiJCwudyhi 6XkhQBxeX7A8gSKQtoIvVflBiNqq+KKzanAUl3Gn8pPKcbThPUI5Nip/m3wyBN4Qzsrh bpYA== X-Gm-Message-State: AG10YOQDGTu+Nbf186VHBF/aGXnbvC4Wp+ba8bEwtsyrM3Y3ifNzuewp2xfLuxBgyp8fr/u5yqJQD6xGpDYV5w== X-Received: by 10.140.96.84 with SMTP id j78mr10476352qge.93.1455821655980; Thu, 18 Feb 2016 10:54:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Thu, 18 Feb 2016 10:53:56 -0800 (PST) From: Ted Hardie Date: Thu, 18 Feb 2016 10:53:56 -0800 Message-ID: To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=001a113ab544a94722052c0fe4ad Archived-At: Subject: [rtcweb] Doodle results for upcoming virtual interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 18:54:19 -0000 --001a113ab544a94722052c0fe4ad Content-Type: text/plain; charset=UTF-8 We plan to hold the meeting 9:00 a.m. to 11:00 a.m. PST (5:00 p.m. to 7:00 p.m. UTC) on Thursday, March 10, 2016. The main agenda item will be reviewing updates to JSEP anticipated before then, but if you have other agenda items, please send them to the chairs by Monday. A formal IETF announcement will go out next week with the finalized agenda. thanks, Ted, Cullen, Sean --001a113ab544a94722052c0fe4ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We plan to hold the meeting 9:00 a.m. to 11= :00 a.m. PST (5:00 p.m. to 7:00 p.m. UTC) on Thursday, March 10, 2016.=C2= =A0 The main agenda item will be reviewing updates to JSEP anticipated befo= re then, but if you have other agenda items, please send them to the chairs= by Monday.

A formal IETF announcement will go out next week w= ith the finalized agenda.

thanks,

Ted, Cullen, Se= an
--001a113ab544a94722052c0fe4ad-- From nobody Thu Feb 18 10:59:32 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF231B3118 for ; Thu, 18 Feb 2016 10:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8CH3O5IsDuA for ; Thu, 18 Feb 2016 10:59:28 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205DB1B30C8 for ; Thu, 18 Feb 2016 10:59:27 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-12-56c6148d80d0 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E2.A7.20792.D8416C65; Thu, 18 Feb 2016 19:59:26 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Thu, 18 Feb 2016 19:59:25 +0100 From: Christer Holmberg To: Ted Hardie , "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Thread-Topic: [rtcweb] Doodle results for upcoming virtual interim Thread-Index: AQHRan3KXgIRIVWB+UutPpeq8g1h758yJ20w Date: Thu, 18 Feb 2016 18:59:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E07B17@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E07B17ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7nG6fyLEwg1uTWS06JrNZrP3Xzm5x ZVUjs0XjXDsHFo8pvzeyeuycdZfdY8mSn0weBw8yBrBEcdmkpOZklqUW6dslcGX8XvqDqaDP uqJtUQNrA+MOyy5GTg4JAROJ1TdOsEDYYhIX7q1n62Lk4hASOMwo8e7wClYIZzGjRMe3+4xd jBwcbAIWEt3/tEHiIgI9jBKNtxsYQbqFBRwltq97xg5iiwg4Sdzf858ZwjaSuLF4DVgNi4Cq xI3lc8DivAK+Env6d4BtFhIIkHjUMw0szikQKHGs5S7YHEagi76fWsMEYjMLiEvcejKfCeJS AYkle84zQ9iiEi8f/2OFsJUkGpc8YYWoz5fY8eI9G8QuQYmTM5+wTGAUmYVk1CwkZbOQlM0C epNZQFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2IULU4tLs5NNzLSSy3KTC4uzs/Ty0st 2cQIjLyDW35b7WA8+NzxEKMAB6MSD2/B7yNhQqyJZcWVuYcYJTiYlUR4qz4fDRPiTUmsrEot yo8vKs1JLT7EKM3BoiTOu8Z5fZiQQHpiSWp2ampBahFMlomDU6qBUXnKgUnr9j8+snjzz/fv C9tPyU8pffCeaadCt5lXgklLcmHawScfbfZ/Of3O9WK459FTFpf2nrLmU3ozXXPVy1nRjx+m 53hFs3yKPKP5ztR6lnREwYdWww89WSyaLcFH5cumx13SNbjEsKBnYfvpUvb3mRJpS2yCjgQ8 ChdJZdnweNXiBLcVckosxRmJhlrMRcWJAAdkjOa4AgAA Archived-At: Subject: Re: [rtcweb] Doodle results for upcoming virtual interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 18:59:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E07B17ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkNvdWxkIHlvdSBhZGQgYSBuZXcgcGFydGljaXBhbnQsIOKAnFNFTEVDVEVEIFRJTUXi gJ0sIHRvIHRoZSBwb2xsLCBhbmQgY2xpY2sgdGhlIHNlbGVjdGVkIHRpbWUsIHRvIG1ha2Ugc3Vy ZSBldmVyeW9uZSB1c2luZyB0aGVpciBsb2NhbCB0aW1lIHpvbmUgZ2V0IHRoZSBjb3JyZWN0IHRp bWUgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRj d2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUZWQgSGFyZGllDQpTZW50OiAxOCBG ZWJydWFyeSAyMDE2IDIwOjU0DQpUbzogcnRjd2ViQGlldGYub3JnOyBDdWxsZW4gSmVubmluZ3Mg PGZsdWZmeUBjaXNjby5jb20+OyBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb20+DQpTdWJqZWN0 OiBbcnRjd2ViXSBEb29kbGUgcmVzdWx0cyBmb3IgdXBjb21pbmcgdmlydHVhbCBpbnRlcmltDQoN CldlIHBsYW4gdG8gaG9sZCB0aGUgbWVldGluZyA5OjAwIGEubS4gdG8gMTE6MDAgYS5tLiBQU1Qg KDU6MDAgcC5tLiB0byA3OjAwIHAubS4gVVRDKSBvbiBUaHVyc2RheSwgTWFyY2ggMTAsIDIwMTYu ICBUaGUgbWFpbiBhZ2VuZGEgaXRlbSB3aWxsIGJlIHJldmlld2luZyB1cGRhdGVzIHRvIEpTRVAg YW50aWNpcGF0ZWQgYmVmb3JlIHRoZW4sIGJ1dCBpZiB5b3UgaGF2ZSBvdGhlciBhZ2VuZGEgaXRl bXMsIHBsZWFzZSBzZW5kIHRoZW0gdG8gdGhlIGNoYWlycyBieSBNb25kYXkuDQpBIGZvcm1hbCBJ RVRGIGFubm91bmNlbWVudCB3aWxsIGdvIG91dCBuZXh0IHdlZWsgd2l0aCB0aGUgZmluYWxpemVk IGFnZW5kYS4NCnRoYW5rcywNClRlZCwgQ3VsbGVuLCBTZWFuDQo= --_000_7594FB04B1934943A5C02806D1A2204B37E07B17ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q291bGQgeW91IGFkZCBhIG5ldyBwYXJ0 aWNpcGFudCwg4oCcU0VMRUNURUQgVElNReKAnSwgdG8gdGhlIHBvbGwsIGFuZCBjbGljayB0aGUg c2VsZWN0ZWQgdGltZSwgdG8gbWFrZSBzdXJlIGV2ZXJ5b25lIHVzaW5nIHRoZWlyIGxvY2FsDQog dGltZSB6b25lIGdldCB0aGUgY29ycmVjdCB0aW1lIDopPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBydGN3 ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ VGVkIEhhcmRpZTxicj4NCjxiPlNlbnQ6PC9iPiAxOCBGZWJydWFyeSAyMDE2IDIwOjU0PGJyPg0K PGI+VG86PC9iPiBydGN3ZWJAaWV0Zi5vcmc7IEN1bGxlbiBKZW5uaW5ncyAmbHQ7Zmx1ZmZ5QGNp c2NvLmNvbSZndDs7IFNlYW4gVHVybmVyICZsdDtzZWFuQHNuM3JkLmNvbSZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gW3J0Y3dlYl0gRG9vZGxlIHJlc3VsdHMgZm9yIHVwY29taW5nIHZpcnR1YWwg aW50ZXJpbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+V2UgcGxhbiB0byBob2xkIHRo ZSBtZWV0aW5nIDk6MDAgYS5tLiB0byAxMTowMCBhLm0uIFBTVCAoNTowMCBwLm0uIHRvIDc6MDAg cC5tLiBVVEMpIG9uIFRodXJzZGF5LCBNYXJjaCAxMCwgMjAxNi4mbmJzcDsgVGhlIG1haW4gYWdl bmRhIGl0ZW0gd2lsbCBiZSByZXZpZXdpbmcgdXBkYXRlcyB0byBKU0VQIGFudGljaXBhdGVkIGJl Zm9yZSB0aGVuLCBidXQgaWYgeW91IGhhdmUNCiBvdGhlciBhZ2VuZGEgaXRlbXMsIHBsZWFzZSBz ZW5kIHRoZW0gdG8gdGhlIGNoYWlycyBieSBNb25kYXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QSBmb3Jt YWwgSUVURiBhbm5vdW5jZW1lbnQgd2lsbCBnbyBvdXQgbmV4dCB3ZWVrIHdpdGggdGhlIGZpbmFs aXplZCBhZ2VuZGEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+dGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UZWQsIEN1bGxlbiwgU2VhbjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37E07B17ESESSMB209erics_-- From nobody Thu Feb 18 11:01:48 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FE21A8859 for ; Thu, 18 Feb 2016 11:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xLF77k3mTT5 for ; Thu, 18 Feb 2016 11:01:29 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1419E1A0405 for ; Thu, 18 Feb 2016 11:01:28 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-5f-56c61506328b Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 15.81.28465.60516C65; Thu, 18 Feb 2016 20:01:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.68]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Thu, 18 Feb 2016 20:01:26 +0100 From: Christer Holmberg To: Christer Holmberg , Ted Hardie , "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Thread-Topic: [rtcweb] Doodle results for upcoming virtual interim Thread-Index: AQHRan3KXgIRIVWB+UutPpeq8g1h758yJ20wgAABKUA= Date: Thu, 18 Feb 2016 19:01:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E07B6C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E07B17@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E07B17@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E07B6CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7li676LEwg+er2S06JrNZrP3Xzm5x ZVUjs0XjXDsHFo8pvzeyeuycdZfdY8mSn0weBw8yBrBEcdmkpOZklqUW6dslcGX827WAsWCd X0XzTp0Gxhk+XYycHBICJhIvl91nh7DFJC7cW8/WxcjFISRwmFHi8cNpjBDOYiBn2meWLkYO DjYBC4nuf9ogcRGBQ0Dx5jawbmEBR4nt656B2SICThL39/xnhrCtJBb1fweLswioShz4M5cZ ZA6vgK9E7ysliPlTGCXWrHvLBFLDKeAncebnKTYQmxHoou+n1oDFmQXEJW49mc8EcamAxJI9 55khbFGJl4//sULYShKNS56wQtTnS6x8uhqshldAUOLkzCcsExhFZiEZNQtJ2SwkZbOAzmMW 0JRYv0sfokRRYkr3Q3YIW0Oidc5cdmTxBYzsqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjEC 4+7glt+6OxhXv3Y8xCjAwajEw1vw+0iYEGtiWXFlLjAAOZiVRHirPh8NE+JNSaysSi3Kjy8q zUktPsQozcGiJM67xnl9mJBAemJJanZqakFqEUyWiYNTqoGx3zb/TdLp6a3THj+8ZHfV0e3j 803dHVm/Fle6uVltW3/fW1Ynwi/86Q7B7Zwrp97aUtm5PoEzfummB2Ebdi+WUfj44pknA8M+ 21bX/yed1Jl2zJ9w8y+zTl3oiyesl4W1+uzL/LUKBJguyTsu9QlU/3IwmP1EaeZRG7Pq3KhA wS/q6zPkbUqUWIozEg21mIuKEwH/KpNHtwIAAA== Archived-At: Subject: Re: [rtcweb] Doodle results for upcoming virtual interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 19:01:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E07B6CESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yZ2V0IHdoYXQgSSBzYWlkIOKAkyB5b3UgY2FuIHNlZSB0aGUgdGltZSBmcm9tIHRoZSBwb2xs LiBTb3JyeSBmb3IgdGhlIG1lc3MuDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6IDE4IEZl YnJ1YXJ5IDIwMTYgMjA6NTkNClRvOiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+OyBy dGN3ZWJAaWV0Zi5vcmc7IEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGNpc2NvLmNvbT47IFNlYW4g VHVybmVyIDxzZWFuQHNuM3JkLmNvbT4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBEb29kbGUgcmVz dWx0cyBmb3IgdXBjb21pbmcgdmlydHVhbCBpbnRlcmltDQoNCkhpLA0KDQpDb3VsZCB5b3UgYWRk IGEgbmV3IHBhcnRpY2lwYW50LCDigJxTRUxFQ1RFRCBUSU1F4oCdLCB0byB0aGUgcG9sbCwgYW5k IGNsaWNrIHRoZSBzZWxlY3RlZCB0aW1lLCB0byBtYWtlIHN1cmUgZXZlcnlvbmUgdXNpbmcgdGhl aXIgbG9jYWwgdGltZSB6b25lIGdldCB0aGUgY29ycmVjdCB0aW1lIDopDQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgVGVkIEhhcmRpZQ0KU2VudDogMTggRmVicnVhcnkgMjAxNiAyMDo1NA0K VG86IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPjsgQ3VsbGVuIEplbm5p bmdzIDxmbHVmZnlAY2lzY28uY29tPG1haWx0bzpmbHVmZnlAY2lzY28uY29tPj47IFNlYW4gVHVy bmVyIDxzZWFuQHNuM3JkLmNvbTxtYWlsdG86c2VhbkBzbjNyZC5jb20+Pg0KU3ViamVjdDogW3J0 Y3dlYl0gRG9vZGxlIHJlc3VsdHMgZm9yIHVwY29taW5nIHZpcnR1YWwgaW50ZXJpbQ0KDQpXZSBw bGFuIHRvIGhvbGQgdGhlIG1lZXRpbmcgOTowMCBhLm0uIHRvIDExOjAwIGEubS4gUFNUICg1OjAw IHAubS4gdG8gNzowMCBwLm0uIFVUQykgb24gVGh1cnNkYXksIE1hcmNoIDEwLCAyMDE2LiAgVGhl IG1haW4gYWdlbmRhIGl0ZW0gd2lsbCBiZSByZXZpZXdpbmcgdXBkYXRlcyB0byBKU0VQIGFudGlj aXBhdGVkIGJlZm9yZSB0aGVuLCBidXQgaWYgeW91IGhhdmUgb3RoZXIgYWdlbmRhIGl0ZW1zLCBw bGVhc2Ugc2VuZCB0aGVtIHRvIHRoZSBjaGFpcnMgYnkgTW9uZGF5Lg0KQSBmb3JtYWwgSUVURiBh bm5vdW5jZW1lbnQgd2lsbCBnbyBvdXQgbmV4dCB3ZWVrIHdpdGggdGhlIGZpbmFsaXplZCBhZ2Vu ZGEuDQp0aGFua3MsDQpUZWQsIEN1bGxlbiwgU2Vhbg0K --_000_7594FB04B1934943A5C02806D1A2204B37E07B6CESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Gb3JnZXQgd2hhdCBJ IHNhaWQg4oCTIHlvdSBjYW4gc2VlIHRoZSB0aW1lIGZyb20gdGhlIHBvbGwuIFNvcnJ5IGZvciB0 aGUgbWVzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBu YW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+U2VudDo8 L2I+IDE4IEZlYnJ1YXJ5IDIwMTYgMjA6NTk8YnI+DQo8Yj5Ubzo8L2I+IFRlZCBIYXJkaWUgJmx0 O3RlZC5pZXRmQGdtYWlsLmNvbSZndDs7IHJ0Y3dlYkBpZXRmLm9yZzsgQ3VsbGVuIEplbm5pbmdz ICZsdDtmbHVmZnlAY2lzY28uY29tJmd0OzsgU2VhbiBUdXJuZXIgJmx0O3NlYW5Ac24zcmQuY29t Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gRG9vZGxlIHJlc3VsdHMgZm9y IHVwY29taW5nIHZpcnR1YWwgaW50ZXJpbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkNvdWxkIHlvdSBhZGQgYSBuZXcgcGFydGljaXBhbnQsIOKAnFNFTEVDVEVEIFRJTUXigJ0s IHRvIHRoZSBwb2xsLCBhbmQgY2xpY2sgdGhlIHNlbGVjdGVkIHRpbWUsIHRvIG1ha2Ugc3VyZSBl dmVyeW9uZSB1c2luZyB0aGVpciBsb2NhbA0KIHRpbWUgem9uZSBnZXQgdGhlIGNvcnJlY3QgdGlt ZSA6KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gcnRjd2Vi IFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpydGN3ZWIt Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRlZCBIYXJkaWU8YnI+ DQo8Yj5TZW50OjwvYj4gMTggRmVicnVhcnkgMjAxNiAyMDo1NDxicj4NCjxiPlRvOjwvYj4gPGEg aHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjsgQ3VsbGVu IEplbm5pbmdzICZsdDs8YSBocmVmPSJtYWlsdG86Zmx1ZmZ5QGNpc2NvLmNvbSI+Zmx1ZmZ5QGNp c2NvLmNvbTwvYT4mZ3Q7OyBTZWFuIFR1cm5lciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNlYW5Ac24z cmQuY29tIj5zZWFuQHNuM3JkLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtydGN3 ZWJdIERvb2RsZSByZXN1bHRzIGZvciB1cGNvbWluZyB2aXJ0dWFsIGludGVyaW08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPldlIHBsYW4gdG8gaG9sZCB0aGUgbWVldGluZyA5OjAwIGEu bS4gdG8gMTE6MDAgYS5tLiBQU1QgKDU6MDAgcC5tLiB0byA3OjAwIHAubS4gVVRDKSBvbiBUaHVy c2RheSwgTWFyY2ggMTAsIDIwMTYuJm5ic3A7IFRoZSBtYWluIGFnZW5kYSBpdGVtIHdpbGwgYmUg cmV2aWV3aW5nIHVwZGF0ZXMgdG8gSlNFUCBhbnRpY2lwYXRlZCBiZWZvcmUgdGhlbiwgYnV0IGlm IHlvdSBoYXZlDQogb3RoZXIgYWdlbmRhIGl0ZW1zLCBwbGVhc2Ugc2VuZCB0aGVtIHRvIHRoZSBj aGFpcnMgYnkgTW9uZGF5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkEgZm9ybWFsIElFVEYgYW5ub3VuY2Vt ZW50IHdpbGwgZ28gb3V0IG5leHQgd2VlayB3aXRoIHRoZSBmaW5hbGl6ZWQgYWdlbmRhLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPnRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGVkLCBDdWxsZW4sIFNlYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B37E07B6CESESSMB209erics_-- From nobody Thu Feb 18 17:14:17 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7281A871A for ; Thu, 18 Feb 2016 17:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXWXPCDBwanW for ; Thu, 18 Feb 2016 17:14:14 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7401A8740 for ; Thu, 18 Feb 2016 17:14:13 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id x1so25739346qkc.1 for ; Thu, 18 Feb 2016 17:14:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qydAbtZq59/SAfCo9oEIY3+biZvV6bSa41oDW/Q8KH0=; b=V2PghDrbW8xL6EItlETZu033M+HEKHwyYILJSRkbJGc/zAHG1hcEsyxYEPvcAyHTc+ VijJ+Fm3CzNmNEnRXPG785hHzw3/+bqoeGtvd7HiwJOV8JjlcKqmIvrb7/t/VgDJetaI iiAa9FZc+gI3lrBIvP3EGXFGozbqPlRH1YL/skgEgKzi9KNTnGcLq+MnQNTvN3RBKhJt PaZK6c/ptTn/Pg/3/2LngbPYWHgJGuXxvD+fNmV5Os5/ZwXXsVUPItGowzFntzKBNvRl zzAYBDbczRgZF2THWlqZwZ0tpRIb33EqqQEEVCzd/H+KDpbLMJZNwTy0U/lDUqGkP+Lp MyRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qydAbtZq59/SAfCo9oEIY3+biZvV6bSa41oDW/Q8KH0=; b=SZDH9KYKpkrcamYzI9XOTyi+puj9iHeK03ouJH8adnSGhH77mPjSvR0PDqk788UVCI 8iYthgw80bLFMQayY1cbCy/96p4dL1rdrg1a5zZ/WoCG9B4NGahI+YHTN8IO7AcGnaRh lqsJXFKiZv4R3YtdQwxJjNUhcqaSMkZTwrmw6f5rfvWpp/mb23Ve6y0J2ulUbFDIsGUD CqjarNTx467gi/tISbL/c+lyb6PmJkYt8nLUDilAJFVT6ua/x51zJe1uRSoj98aExdgZ MI8JQMvmbNbyb+W4ahGtzi41RIfI/FVvkYXW3oUyhv7R0LxKAWuqkswuZSn/dYZlpNGz bbhg== X-Gm-Message-State: AG10YOTJP4AwSI0y5QNRbG9GTFp/+3bTQP+shUSDkVH+GunxrvsMAL8qmGq4N0jBoVK4sMGwTitDLKE8E+7OMw== X-Received: by 10.55.41.11 with SMTP id p11mr12395488qkh.86.1455844452257; Thu, 18 Feb 2016 17:14:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Thu, 18 Feb 2016 17:13:52 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E07B17@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E07B17@ESESSMB209.ericsson.se> From: Ted Hardie Date: Thu, 18 Feb 2016 17:13:52 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114053b66cd85e052c153358 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Doodle results for upcoming virtual interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 01:14:16 -0000 --001a114053b66cd85e052c153358 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 18, 2016 at 10:59 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > Could you add a new participant, =E2=80=9CSELECTED TIME=E2=80=9D, to the = poll, and click > the selected time, to make sure everyone using their local time zone get > the correct time :) > > > > Regards, > > > > Christer > > Okay, I re-opened the poll, added that choice, re-selected the time, and closed the poll again. From my view, it all looks correct again, but please let me know if I made an error in the incantations. thanks, Ted > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Ted Hardie > *Sent:* 18 February 2016 20:54 > *To:* rtcweb@ietf.org; Cullen Jennings ; Sean Turner < > sean@sn3rd.com> > *Subject:* [rtcweb] Doodle results for upcoming virtual interim > > > > We plan to hold the meeting 9:00 a.m. to 11:00 a.m. PST (5:00 p.m. to 7:0= 0 > p.m. UTC) on Thursday, March 10, 2016. The main agenda item will be > reviewing updates to JSEP anticipated before then, but if you have other > agenda items, please send them to the chairs by Monday. > > A formal IETF announcement will go out next week with the finalized agend= a. > > thanks, > > Ted, Cullen, Sean > --001a114053b66cd85e052c153358 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 18, 2016 at 10:59 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

Could you add a new participant, =E2= =80=9CSELECTED TIME=E2=80=9D, to the poll, and click the selected time, to = make sure everyone using their local time zone get the correct time :)

=C2=A0

Regards,

=C2=A0

Christer


Okay= , I re-opened the poll, added that choice, re-selected the time, and closed= the poll again.=C2=A0 From my view, it all looks correct again, but please= let me know if I made an error in the incantations.

than= ks,

Ted

=C2=A0
<= p class=3D"MsoNormal">=C2=A0

From: = rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: 18 February 2016 20:54
To: rtcweb@ietf= .org; Cullen Jennings <fluffy@cisco.com>; Sean Turner <sean@sn3rd.com>
Subject: [rtcweb] Doodle results for upcoming virtual interim=

=C2=A0

We plan to hold the m= eeting 9:00 a.m. to 11:00 a.m. PST (5:00 p.m. to 7:00 p.m. UTC) on Thursday= , March 10, 2016.=C2=A0 The main agenda item will be reviewing updates to J= SEP anticipated before then, but if you have other agenda items, please send them to the chairs by Monday.

A formal IETF announc= ement will go out next week with the finalized agenda.

thanks,=

Ted, Cullen, Sean


--001a114053b66cd85e052c153358-- From nobody Mon Feb 22 01:00:35 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F051B2C32; Mon, 22 Feb 2016 01:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBNSqcgF6klk; Mon, 22 Feb 2016 01:00:30 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7DE41B2C30; Mon, 22 Feb 2016 01:00:28 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-a9-56cace2b2a83 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0C.1E.28465.B2ECAC65; Mon, 22 Feb 2016 10:00:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 10:00:26 +0100 From: Christer Holmberg To: "mmusic@ietf.org" , "rtcweb@ietf.org" Thread-Topic: Confusion with references to RFC 5245 and draft-5245bis Thread-Index: AdFtT2VzhFsiwYbeT3qr3Botxh76Rg== Date: Mon, 22 Feb 2016 09:00:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E2D311@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E2D311ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2K7ma72uVNhBpu3iFhMXf6YxWLtv3Z2 ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlzFq1gqlghnbF8Y7/bA2Md1W7GDk5JARMJBa/Xc4I YYtJXLi3ng3EFhI4zCjxe7dDFyMXkL2YUaLn0VmWLkYODjYBC4nuf9ogNSICPhJff91jBwkL CzhIzDkBFXaV+H79OwuErSexbMp6sPEsAqoS+6e2soGU8wr4SqxujQUJMwJt/X5qDROIzSwg LnHryXwmiGsEJJbsOc8MYYtKvHz8jxXCVpJYsf0SI0R9vkTbiR6wVbwCghInZz5hmcAoNAvJ qFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGEWLU4uLc9ONjPVSizKTi4vz 8/TyUks2MQLj4uCW37o7GFe/djzEKMDBqMTDa8B5KkyINbGsuDL3EKMEB7OSCO/Wo0Ah3pTE yqrUovz4otKc1OJDjNIcLErivGuc14cJCaQnlqRmp6YWpBbBZJk4OKUaGKUqmBWqhG9Mmn3L wHzfv4aNgiKC8WH6ytOnrEuSObxCKDcr4VREYkjFXr014jnuce5RiipRWxk/PpSOyO818F+T cqVq7mTfU1NMdvse+X3mZPfVDvHsKAUvMxWdII+7Uf6nKhq+/J9ktyT5ppvgwYXOd3ceqhI7 dyQvNKfkyf3tD0Nj3zUfUmIpzkg01GIuKk4EADM1jrOHAgAA Archived-At: Subject: [rtcweb] Confusion with references to RFC 5245 and draft-5245bis X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 09:00:32 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E2D311ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (Sorry for the cross-posting, but this applies to both MMUSIC and RTCWEB) Hi, draft-bundle currently references RFC 5245. draft-bundle also references draft-ice-sip-sdp, which references draft-5245= bis. draft-bundle also references draft-trickle-ice-sip, which references RFC 52= 45 JSEP references RFC 5245. JSEP also references draft-bundle. My intention is to update the reference in draft-bundle to draft-5245bis - = and I REALLY think we should do the same thing in draft-trickle-ice-sip and= draft-jsep. Otherwise we will end up with references (explicit or implicit= ) to both RFC 5245 and draft-5245bis all over, which could end up being REA= LLY confusing. I KNOW the reason people want to reference RFC 5245, is because they don't = want to create a dependency on draft-5245bis. Well, I think we REALLY shall= create such dependency, and then make sure we get draft-5245bis ready (mor= e on that in a separate draft). Regards, Christer So, my intention is to reference draft-5245bis also in BUNDLE. --_000_7594FB04B1934943A5C02806D1A2204B37E2D311ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(Sorry for the cross-posting, but this applies to bo= th MMUSIC and RTCWEB)

 

Hi,

 

draft-bundle currently references RFC 5245.

 

draft-bundle also references draft-ice-sip-sdp, whic= h references draft-5245bis.

 

draft-bundle also references draft-trickle-ice-sip, = which references RFC 5245

 

JSEP references RFC 5245.

 

JSEP also references draft-bundle.

 

My intention is to update the reference in draft-bun= dle to draft-5245bis – and I REALLY think we should do the same thing= in draft-trickle-ice-sip and draft-jsep. Otherwise we will end up with ref= erences (explicit or implicit) to both RFC 5245 and draft-5245bis all over, which could end up being REALLY confusing= .

 

I KNOW the reason people want to reference RFC 5245,= is because they don’t want to create a dependency on draft-5245bis. = Well, I think we REALLY shall create such dependency, and then make sure we= get draft-5245bis ready (more on that in a separate draft).

 

Regards,

 

Christer

 

 

 

 

 

 

So, my intention is to reference draft-5245bis also = in BUNDLE.

 

 

--_000_7594FB04B1934943A5C02806D1A2204B37E2D311ESESSMB209erics_-- From nobody Tue Feb 23 09:24:18 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 496E61B38D5; Tue, 23 Feb 2016 09:24:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160223172417.7350.12702.idtracker@ietfa.amsl.com> Date: Tue, 23 Feb 2016 09:24:17 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] RTCWEB WG Virtual Interim Meeting: March 10, 2016 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 17:24:17 -0000 The Real-Time Communication in WEB-browsers (RTCWEB) working group plans to hold a Virtual Interim meeting on March 10, 2016 from 9:00 a.m. to 11:00 a.m. Pacific Time (1700-1900 UTC). Details for participation will be posted on the RTCWEB mailing list. From nobody Wed Feb 24 13:31:25 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A448E1B40C9; Wed, 24 Feb 2016 13:31:21 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160224213121.376.85278.idtracker@ietfa.amsl.com> Date: Wed, 24 Feb 2016 13:31:21 -0800 Archived-At: Cc: rtcweb-chairs@ietf.org, alcoop@cisco.com, rtcweb@ietf.org, draft-ietf-rtcweb-audio@ietf.org Subject: [rtcweb] Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 21:31:21 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC Audio Codec and Processing Requirements' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-03-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document outlines the audio codec and processing requirements for WebRTC endpoints. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Feb 24 13:32:06 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD3F1B2D0D; Wed, 24 Feb 2016 13:32:03 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160224213203.1684.63921.idtracker@ietfa.amsl.com> Date: Wed, 24 Feb 2016 13:32:03 -0800 Archived-At: Cc: rtcweb@ietf.org, draft-ietf-rtcweb-audio-codecs-for-interop@ietf.org, alcoop@cisco.com, rtcweb-chairs@ietf.org Subject: [rtcweb] Last Call: (Additional WebRTC audio codecs for interoperability.) to Informational RFC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 21:32:03 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'Additional WebRTC audio codecs for interoperability.' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-03-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract To ensure a baseline level of interoperability between WebRTC endpoints, a minimum set of required codecs is specified. However, to maximize the possibility to establish the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser. This document provides some guidelines on the suitable codecs to be considered for WebRTC endpoints to address the most relevant interoperability use cases. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio-codecs-for-interop/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio-codecs-for-interop/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Feb 24 13:42:41 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A59D1B42BC for ; Wed, 24 Feb 2016 13:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-UjJMsY61Nk for ; Wed, 24 Feb 2016 13:42:37 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC5B1B42D8 for ; Wed, 24 Feb 2016 13:42:37 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id z135so68854654iof.0 for ; Wed, 24 Feb 2016 13:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=GrcMvBkWkW9NDxsS6zYIOX2FaoNViIL9frbqAd5R6Ag=; b=ZfYjzhXqExIMO/1Wjy9fhagX/YNRvGGb3fA9m8z5h9MENQ7ptspWS7eM9G5kEUSyMV /KUVXD9fcw0qroeyQgF6ff5AiVQU0PvAUatUUPxtxS4uCfrKzo0NK6NxQTu+rE68X+zF ycM7hRg1ZUJOBW6qWNv48OsrfP2sYTi11oCjN8Y6AtKy5u1azRKGrc8puO1BmG85t2tP oY7KoUWcs0lko2Nag3MpcR7+/5NRceTMIunXfGJ/ha+X+uGae0MA7uOjXIUNwVL5otFj 8u0RFG1IRmVmxAecZ0XEE5ngGiqF9lARJZWKhQeVxbgpX2iYZqU24lbTDe2ZB31oBJ5M JEHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=GrcMvBkWkW9NDxsS6zYIOX2FaoNViIL9frbqAd5R6Ag=; b=cKZUNbNk/979eSRWA0acXgmqqnHeEkFqfe/ul09hoMkjpv4yDHGTQbvJpxe4O11Qz9 yVcLIq7NrjtxnRwnZQiuJC9ESJOESM8bWpqAr+9edj9+0MZztyWVklnkt2aoNGAENVRP jjV0Zz97xtzFA1QNM481qDnNamAvWuu0R7MulA6IzAZmF6C6CTbvq/Gx3yrhSJvHmmOr mOBeC6HuiItRX3DnEnCdmccX2eTUdW8bh5th5Xmv/3dbsJXkQfsAukMgCImKw05XvW1t um7w/qSAkAD8Etr1VinP+mOqxzi+vn1jqBBhtN1jK1mpC9ZBjZ+fBU5E9qQ1K69CZa/B BDOQ== X-Gm-Message-State: AG10YOT4mbXih6eolYt/6/CFQWb7S6cHLes4g1gJRvTr6KZW747HH+6eoc86VkkS0HgyzQ== X-Received: by 10.107.32.20 with SMTP id g20mr41006457iog.149.1456350157180; Wed, 24 Feb 2016 13:42:37 -0800 (PST) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com. [209.85.223.179]) by smtp.gmail.com with ESMTPSA id 8sm2046325ioe.8.2016.02.24.13.42.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 13:42:36 -0800 (PST) Received: by mail-io0-f179.google.com with SMTP id g203so68060880iof.2; Wed, 24 Feb 2016 13:42:36 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr37462946ioe.38.1456350155584; Wed, 24 Feb 2016 13:42:35 -0800 (PST) Received: by 10.36.105.77 with HTTP; Wed, 24 Feb 2016 13:42:35 -0800 (PST) In-Reply-To: <20160224213121.376.85278.idtracker@ietfa.amsl.com> References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> Date: Wed, 24 Feb 2016 16:42:35 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: rtcweb-chairs@ietf.org, alcoop@cisco.com, "rtcweb@ietf.org" , draft-ietf-rtcweb-audio@ietf.org Content-Type: multipart/alternative; boundary=001a1140b472b1483b052c8af152 Archived-At: Subject: Re: [rtcweb] Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 21:42:39 -0000 --001a1140b472b1483b052c8af152 Content-Type: text/plain; charset=UTF-8 Hi All, There is still my comment which is not addressed. I was asking to add DTMF tone duration normative information to this document to align it with to https://www.w3.org/TR/webrtc/#rtcdtmfsender. In particular I proposed to add the following text to section 3: Generated events MUST have duration of no more than 6000 ms and no less than 40 ms with the recommended default duration of 100 ms for each tone. The gap between events MUST be no less then 30 ms with the recommended default duration of 70 ms. Regards, _____________ Roman Shpount On Wed, Feb 24, 2016 at 4:31 PM, The IESG wrote: > > The IESG has received a request from the Real-Time Communication in > WEB-browsers WG (rtcweb) to consider the following document: > - 'WebRTC Audio Codec and Processing Requirements' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2016-03-09. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document outlines the audio codec and processing requirements > for WebRTC endpoints. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1140b472b1483b052c8af152 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

There is still my comment which= is not addressed. I was asking to add DTMF tone duration normative informa= tion to this document to align it with=C2=A0=C2=A0to=C2=A0https://w= ww.w3.org/TR/webrtc/#rtcdtmfsender.

In particu= lar I proposed to add the following text to section 3:

=
Generated events MUS= T have duration of no more than 6000 ms and no less=C2=A0than 40 ms with th= e recommended default duration of 100 ms for each tone. The gap between eve= nts MUST be no less then 30 ms with the recommended=C2=A0default duration o= f 70 ms.

Regards,=
_____________
Roman Shpount

On Wed, Feb 24, 2016 at 4:31 PM, The IESG <iesg-secretary@ietf.org> wrote:
The IESG has received a request from the Real-Time Communication in
WEB-browsers WG (rtcweb) to consider the following document:
- 'WebRTC Audio Codec and Processing Requirements'
=C2=A0 <draft-ietf-rtcweb-audio-10.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailin= g lists by 2016-03-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


=C2=A0 =C2=A0This document outlines the audio codec and processing requirem= ents
=C2=A0 =C2=A0for WebRTC endpoints.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ie= tf-rtcweb-audio/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/dra= ft-ietf-rtcweb-audio/ballot/


No IPR declarations have been submitted directly on this I-D.


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--001a1140b472b1483b052c8af152-- From nobody Thu Feb 25 10:09:01 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3680A1B2FB1 for ; Thu, 25 Feb 2016 10:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8f_zE6J6QG5 for ; Thu, 25 Feb 2016 10:08:57 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4E31A8F34 for ; Thu, 25 Feb 2016 10:08:03 -0800 (PST) Received: by mail-qg0-x236.google.com with SMTP id b67so46261107qgb.1 for ; Thu, 25 Feb 2016 10:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=JGAWVlJyOC06dFjsqz6JbtTfSCh1JZOpjFceRY/LqK4=; b=Wciry0rwuTqZmV/DDD95H9s/9enNrl+Moaag3sossg54+s+qSDuYEJsjhjYYh5YaPv AXdkI/gHsn6r7HwXt95vPRpQHgpuxe00rIG5ZQzAmaFsp0OX4bBM4Nia4wCndtq5qGoG 4JhA5bhcpooGubtiLFrLbzG48qxwZOl44K7xqMf7toYjd5VeBUlELt1TSBIXLSORQaSa S9gHJh9MWw4gOFHC3tcZNuYv7XxWldSc9d6p9VYX1rHJQG4/OAVi5BD88C8Qg5br1Dpn AvhmNhcxJvBBvkgKQYb/6CGlwSbYx3ebcsif8+8CsCieQH24YlvooPWYtADRnvoy8T8Z b96A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=JGAWVlJyOC06dFjsqz6JbtTfSCh1JZOpjFceRY/LqK4=; b=gEtwiLeMajD/MTVpUNBTZM48mRxd8ilqcYRfhtvd4GiuiX7l5FEtXdmU81E5Xzyrim UrzPQvjomnjhHw3dyVGvf3qD8Vpf2KHp05wPotR9BSZ40BFIVM4OHCgGj1/JSZEZJ7cq aGTRUqNJbPF7k41Zhy8HhICPFxgBVcLzk5zKYwHGcf4lIZfjTNCZgQsmaqUTRFzSCriG wbGbfV1As/aD+gyktm1movlLyZ7DFczQzIl9HDZ9K4J6ROXFDdH1F6hofhTrTDya++gT aaFo1mxPIsrc4TrKoqCqDr2q4PphEFnFVqCDMDBKWwo9l7iH4qvXENTOcclnvPDxnMXz C5eA== X-Gm-Message-State: AG10YOTkCC6w9zIQzsJhv16LHsNiEQPA6NdXRoidBoXrvu7Z5we5RJuRU7xXYLUgD6eNK/cWnr5M7wXF5IDlhg== X-Received: by 10.140.175.136 with SMTP id v130mr55892662qhv.74.1456423682679; Thu, 25 Feb 2016 10:08:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Thu, 25 Feb 2016 10:07:43 -0800 (PST) In-Reply-To: <56CE2CF4.70001@jmvalin.ca> References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> From: Ted Hardie Date: Thu, 25 Feb 2016 10:07:43 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a113a5fe43faecc052c9c10af Archived-At: Subject: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 18:08:59 -0000 --001a113a5fe43faecc052c9c10af Content-Type: text/plain; charset=UTF-8 Mailman claims this was auto-discarded and it doesn't show in the archives, so I'm forwarding. I will separately check on why it got chucked. regards, Ted ---------- Forwarded message ---------- From: Jean-Marc Valin Date: Wed, Feb 24, 2016 at 2:21 PM Subject: Re: [rtcweb] Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard To: Roman Shpount , rtcweb-chairs@ietf.org, alcoop@cisco.com, "rtcweb@ietf.org" , draft-ietf-rtcweb-audio@ietf.org On 02/24/2016 04:42 PM, Roman Shpount wrote: > Generated events MUST have duration of no more than 6000 ms and no > less than 40 ms with the recommended default duration of 100 ms for each > tone. The gap between events MUST be no less then 30 ms with the > recommended default duration of 70 ms. OK, I missed that part, but I'm fine with it. Unless anyone objects, I can add it to the draft. Jean-Marc > Regards, > _____________ > Roman Shpount > > On Wed, Feb 24, 2016 at 4:31 PM, The IESG > wrote: > > > The IESG has received a request from the Real-Time Communication in > WEB-browsers WG (rtcweb) to consider the following document: > - 'WebRTC Audio Codec and Processing Requirements' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2016-03-09. > Exceptionally, comments may be > sent to iesg@ietf.org instead. In either > case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document outlines the audio codec and processing requirements > for WebRTC endpoints. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a113a5fe43faecc052c9c10af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mailman claims this was auto-discarded and it do= esn't show in the archives, so I'm forwarding.=C2=A0 I will separat= ely check on why it got chucked.

regards,

Ted
=
---------- Forwarded message ----= ------
From: Jean-Marc Valin <jmvalin@jmvalin.ca&g= t;
Date: Wed, Feb 24, 2016 at 2:21 PM
Subject: Re: [rtcweb] La= st Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Pro= cessing Requirements) to Proposed Standard
To: Roman Shpount <roman@telurix.com>, rtcweb-chairs@ietf.org, alcoop@cisco.com, "rtcweb@ietf.org" <rtcweb@ie= tf.org>, draft-i= etf-rtcweb-audio@ietf.org


On 02/24/2016 04:= 42 PM, Roman Shpount wrote:
> Generated events MUST have duration of no more than 6000 ms and no
> less than 40 ms with the recommended default duration of 100 ms for ea= ch
> tone. The gap between events MUST be no less then 30 ms with the
> recommended default duration of 70 ms.

OK, I missed that part, but I'm fine with it. Unless anyone obje= cts, I
can add it to the draft.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jean-Marc


> Regards,
> _____________
> Roman Shpount
>
> On Wed, Feb 24, 2016 at 4:31 PM, The IESG <iesg-secretary@ietf.org
> <mailto:iesg-secretary@ietf.org>> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0The IESG has received a request from the Real-Time = Communication in
>=C2=A0 =C2=A0 =C2=A0WEB-browsers WG (rtcweb) to consider the following = document:
>=C2=A0 =C2=A0 =C2=A0- 'WebRTC Audio Codec and Processing Requiremen= ts'
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<draft-ietf-rtcweb-audio-10.txt> as Pr= oposed Standard
>
>=C2=A0 =C2=A0 =C2=A0The IESG plans to make a decision in the next few w= eeks, and solicits
>=C2=A0 =C2=A0 =C2=A0final comments on this action. Please send substant= ive comments to the
>=C2=A0 =C2=A0 =C2=A0ietf@ietf.o= rg <mailto:ietf@ietf.org> ma= iling lists by 2016-03-09.
>=C2=A0 =C2=A0 =C2=A0Exceptionally, comments may be
>=C2=A0 =C2=A0 =C2=A0sent to iesg@ietf.= org <mailto:iesg@ietf.org> i= nstead. In either
>=C2=A0 =C2=A0 =C2=A0case, please retain the
>=C2=A0 =C2=A0 =C2=A0beginning of the Subject line to allow automated so= rting.
>
>=C2=A0 =C2=A0 =C2=A0Abstract
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 This document outlines the audio codec and = processing requirements
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 for WebRTC endpoints.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0The file can be obtained via
>=C2=A0 =C2=A0 =C2=A0https://datatracker= .ietf.org/doc/draft-ietf-rtcweb-audio/
>
>=C2=A0 =C2=A0 =C2=A0IESG discussion can be tracked via
>=C2=A0 =C2=A0 =C2=A0https://data= tracker.ietf.org/doc/draft-ietf-rtcweb-audio/ballot/
>
>
>=C2=A0 =C2=A0 =C2=A0No IPR declarations have been submitted directly on= this I-D.
>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0rtcweb mailing list
>=C2=A0 =C2=A0 =C2=A0rtcweb@ie= tf.org <mailto:rtcweb@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/lis= tinfo/rtcweb
>
>

--001a113a5fe43faecc052c9c10af-- From nobody Thu Feb 25 10:45:51 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97C21B30A6 for ; Thu, 25 Feb 2016 10:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhYNXLaBeCfY for ; Thu, 25 Feb 2016 10:45:48 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E101ACE7D for ; Thu, 25 Feb 2016 10:45:48 -0800 (PST) Received: by mail-yk0-x233.google.com with SMTP id r207so26213125ykd.2 for ; Thu, 25 Feb 2016 10:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=sQwFWKXNmpgZFUFzjQhIuh0wMGhD+pYNsmjx4SluBac=; b=TrAUgK+9xWxbbeTptYXmLdeOPBZxwjOLCkC6RUGnOApG9jc96j5CIjX15Al89vTmYz GRDfWW2iGgM0KLnRrJ16owVjJQX+6v1iwrGAcAfUHefqVd7QPqYYawRVxGURUiT7w9Jz UQ7BqmCzelpoMeWtkJipDthMmTxb6d0Yc+UZw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=sQwFWKXNmpgZFUFzjQhIuh0wMGhD+pYNsmjx4SluBac=; b=E4LPyCGRUrgNRlQMoyYbozIgro2onCaeF0hhMKqtt+5Sj93L2wyo5qYfimTal86J9f ufayVuGZ1ysuR93uk/hWhi331+2PwPc5uB7mGY0jAXWDNPhym2kBImOzWci+tpx1lqTW urZ9dTMK/nrKdPiZbF8dmOaAqv3CrXBVIH6cb66pfJiPmx/EMoOGmiSLtE/U1qgl2bD4 EtnhE+QpBVnNTlhBEBY0QNws7FHfe6qta0jGfI0shYUhQWrPnI4SvqxhnM0TmpD/VQuB A+E7RBVnCTpSiiHlZoC0bDbbXydFEZNQTAh3SzW3QJZDGODDQ0JbxmMmW9Ag2ZH7SA6T 1g0A== X-Gm-Message-State: AG10YOQ5P60zcKyk1PnveapMxBwf4RDqFIC6CZ7P4W2sugYr+CTZDk07jPKL0hPsbLcajA== X-Received: by 10.37.64.198 with SMTP id n189mr23913484yba.124.1456425947544; Thu, 25 Feb 2016 10:45:47 -0800 (PST) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id i67sm6920656ywf.34.2016.02.25.10.45.46 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Feb 2016 10:45:46 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sean Turner In-Reply-To: <2073ABB8-AEC7-4475-8159-AA7FE426C5B6@sn3rd.com> Date: Thu, 25 Feb 2016 13:45:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2073ABB8-AEC7-4475-8159-AA7FE426C5B6@sn3rd.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-alpn X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 18:45:50 -0000 All, This draft passed through WGLC and I=E2=80=99ll be passing it to Alissa = later this evening. spt > On Jan 25, 2016, at 11:18, Sean Turner wrote: >=20 > All, >=20 > This is the working group last call for the =E2=80=9CALPN" draft = available at https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/. = Please review the draft and send your comments to this list by Tuesday, = February 9th, 2016. =20 >=20 > Thanks, > C/T/S From nobody Thu Feb 25 11:03:56 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F3E1B31A9 for ; Thu, 25 Feb 2016 11:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODohmVm6_csk for ; Thu, 25 Feb 2016 11:03:53 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7B91B31A0 for ; Thu, 25 Feb 2016 11:03:53 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id h129so50605254ywb.1 for ; Thu, 25 Feb 2016 11:03:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=CYdv5d7hsgAGtpKXIdlhZC/66PN/Ac9K3vUTu8Kg5t8=; b=WHlNUqsdBJ4WCxPbK9PCkfxgI7zxj75E58JOQSlTqJOUOq5z3Bo21fsRCWC58kAJCz xx5pBU1eXDd01H/g9pCLqTzRSytRf1D9PSdacxkswU8j0JeFituh3bbGyj2rcdD3MVs2 ooYYZ0dpjSlphf+9m9vgLJQ6d5qNUXzY/YFLI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=CYdv5d7hsgAGtpKXIdlhZC/66PN/Ac9K3vUTu8Kg5t8=; b=Qk2sYo0AXW2ebwzYQ8VRmdIMX/w7BUuflefqOIgz68xlmtraG+VPfDA5Es8HXOZLMp I7ZK1dCPd/4SClVnVbyNz+EDJM4ZYSO7IEeoQCM0nDRPlqj9/XLEyJjC/bQbVErQUAUq QL1Ai/glLcLlWBC6PbcQzmf6myA8ze4nfwyIwQUyjfP/4ew9uEPQ1oIRKgi5CO8yjQDX 858J1nch0A09wPvwXHeHoLDFJ9AOPPVvl11dv0ZnC+jFNTj/9dID0sv5WVcLZueMrVIN XxD+sfOyrSNAu+GsrJH05ADz+Vq5i/D6s7HB3dzhC2dDEn+Y2ic6CC3Mquu1u/tJJku5 QxGw== X-Gm-Message-State: AG10YORC+q2DeqRSe+YUz2nyzXuyxCH9tO94i5OQCFTuficGI4pYfTL2Ib15f0joXsa2kA== X-Received: by 10.13.230.78 with SMTP id p75mr24569885ywe.234.1456427032612; Thu, 25 Feb 2016 11:03:52 -0800 (PST) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id i67sm6977573ywf.34.2016.02.25.11.03.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Feb 2016 11:03:52 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <890D5A28-D91E-4FDF-BE3F-F635F4DA12D4@sn3rd.com> Date: Thu, 25 Feb 2016 14:03:50 -0500 To: rtcweb@ietf.org, draft-shieh-rtcweb-ip-handling@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [rtcweb] adopted: draft-shieh-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 19:03:54 -0000 All, We=E2=80=99ve verified the consensus of the room at IETF 94 on the list = that there is WG consensus to adopt draft-shieh-rtcweb-ip-handling-00 = [0]. Justin/Guo-wei, When you get a chance please submit as a WG draft. I=E2=80=99ve = pre-approved the name draft-ietf-rtcweb-ip-handling. spt [0] = https://mailarchive.ietf.org/arch/msg/rtcweb/uA26Ho6R872S8B3h71iW1B_aUcI= From nobody Thu Feb 25 11:44:52 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96BA1B334F for ; Thu, 25 Feb 2016 11:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta5mfw3XxLxv for ; Thu, 25 Feb 2016 11:44:45 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0063.outbound.protection.outlook.com [207.46.100.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA891B334E for ; Thu, 25 Feb 2016 11:44:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jBEP//kkia2HpEHOb/OGf49mRtRCyoPG2zyymZbixNQ=; b=USS9zZ/yhZn3dQ86U9+ymU+CcTOrwN1bGkBqyzCLhYlQ/9w20lQRjUdQdnVQfbPhoW9F9cpPtf4qxwTWvZF41wIw6WGXpZIHWnuZ2/fHMjPKJRyKA5VY2pc09wX0BULPEtAysg0zTPDPn6SeaubaxtpgcAUwCfMhDP5IJHnBvRo= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1552.namprd03.prod.outlook.com (10.162.129.158) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 25 Feb 2016 19:44:43 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Thu, 25 Feb 2016 19:44:43 +0000 From: "Asveren, Tolga" To: Ted Hardie , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p89Kcur Date: Thu, 25 Feb 2016 19:44:42 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 40745723-a1db-4b80-c7a4-08d33e1c1ba2 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1552; 5:/+v1bnQwetLgC/Iahjv++haSIBja1rXnglLezfG7kMlz4LChoVka5MDXLaxOe/wafDhozIXxZI6rp8B8c2l7dMAJ86bexGBrqe7MUideJ1ydu++yDWAmhLRl883k5KjH681sIZSdVVczTPFHMjxZAw==; 24:QF/pTdZsNJUsFjJ3WAEG3r/E7fqWXmWprJw3/1nmPu629k+HcVJSIAgLGZdiJRhT3c6I1n7dXHx0ujVICAM7nVQA6U+h8PoMTNQyyriRJwU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1552; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR0301MB1552; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1552; x-forefront-prvs: 08635C03D4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(24454002)(164054003)(479174004)(3900700001)(19625215002)(19617315012)(92566002)(6116002)(15975445007)(99286002)(3280700002)(19580395003)(19580405001)(74316001)(3660700001)(1096002)(77096005)(5001770100001)(40100003)(16236675004)(2501003)(33656002)(2950100001)(10400500002)(122556002)(11100500001)(54356999)(76176999)(19627405001)(2906002)(5001960100002)(107886002)(5004730100002)(106116001)(87936001)(50986999)(3846002)(102836003)(5003600100002)(189998001)(2900100001)(1220700001)(5008740100001)(76576001)(5002640100001)(93886004)(230783001)(66066001)(586003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1552; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB15510A18734956A22BD5FB5AB2A60SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2016 19:44:42.9437 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1552 Archived-At: Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 19:44:51 -0000 --_000_SN1PR0301MB15510A18734956A22BD5FB5AB2A60SN1PR0301MB1551_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roman, What is the rationale of having this "MUST" strength mandate? Thanks, Tolga ________________________________ From: rtcweb on behalf of Ted Hardie Sent: Thursday, February 25, 2016 1:07 PM To: rtcweb@ietf.org Subject: [rtcweb] Fwd: Last Call: (WebRTC = Audio Codec and Processing Requirements) to Proposed Standard Mailman claims this was auto-discarded and it doesn't show in the archives,= so I'm forwarding. I will separately check on why it got chucked. regards, Ted ---------- Forwarded message ---------- From: Jean-Marc Valin > Date: Wed, Feb 24, 2016 at 2:21 PM Subject: Re: [rtcweb] Last Call: (WebRTC A= udio Codec and Processing Requirements) to Proposed Standard To: Roman Shpount >, rtcweb-cha= irs@ietf.org, alcoop@cisco.com, "rtcweb@ietf.org" >, draft-ietf-rtcweb-audio@ietf.org On 02/24/2016 04:42 PM, Roman Shpount wrote: > Generated events MUST have duration of no more than 6000 ms and no > less than 40 ms with the recommended default duration of 100 ms for each > tone. The gap between events MUST be no less then 30 ms with the > recommended default duration of 70 ms. OK, I missed that part, but I'm fine with it. Unless anyone objects, I can add it to the draft. Jean-Marc > Regards, > _____________ > Roman Shpount > > On Wed, Feb 24, 2016 at 4:31 PM, The IESG > >> wrote: > > > The IESG has received a request from the Real-Time Communication in > WEB-browsers WG (rtcweb) to consider the following document: > - 'WebRTC Audio Codec and Processing Requirements' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to th= e > ietf@ietf.org > mailing lists by 2016-03-09. > Exceptionally, comments may be > sent to iesg@ietf.org > instead. In either > case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document outlines the audio codec and processing requirements > for WebRTC endpoints. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > --_000_SN1PR0301MB15510A18734956A22BD5FB5AB2A60SN1PR0301MB1551_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Roman,


What is the rationale of having this "MUST" strength mandate?<= /p>


Thanks,

Tolga



From: rtcweb <rtcweb-bou= nces@ietf.org> on behalf of Ted Hardie <ted.ietf@gmail.com>
Sent: Thursday, February 25, 2016 1:07 PM
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt= > (WebRTC Audio Codec and Processing Requirements) to Proposed Standard<= /font>
 
Mailman claims this was auto-discarded and it doesn't show in the arch= ives, so I'm forwarding.  I will separately check on why it got chucke= d.

regards,

Ted
---------- Forwarded message ----------
From: Jean-Marc Valin &= lt;jmvalin@jmvalin.ca><= br> Date: Wed, Feb 24, 2016 at 2:21 PM
Subject: Re: [rtcweb] Last Call: <draft-ietf-rtcweb-audio-10.txt> (We= bRTC Audio Codec and Processing Requirements) to Proposed Standard
To: Roman Shpount <roman@telurix.co= m>, rtcweb-chairs@ietf.org, alcoop@cisc= o.com, "rtcweb@ietf.org&quo= t; <rtcweb@ietf.org>, draft-ietf-rtcweb-audio= @ietf.org


On 02/24/2016 04:42 PM, Roman Shpount wrote:
> Generated events MUST have duration of no more than 6000 ms and no
> less than 40 ms with the recommended default duration of 100 ms for ea= ch
> tone. The gap between events MUST be no less then 30 ms with the
> recommended default duration of 70 ms.

OK, I missed that part, but I'm fine with it. Unless anyone objects,= I
can add it to the draft.

        Jean-Marc


> Regards,
> _____________
> Roman Shpount
>
> On Wed, Feb 24, 2016 at 4:31 PM, The IESG <iesg-secretary@ietf.org
> <mailto:iesg-secretary@ietf.org>> wrote:
>
>
>     The IESG has received a request from the Real-Time = Communication in
>     WEB-browsers WG (rtcweb) to consider the following = document:
>     - 'WebRTC Audio Codec and Processing Requirements'<= br> >       <draft-ietf-rtcweb-audio-10.txt> as Pr= oposed Standard
>
>     The IESG plans to make a decision in the next few w= eeks, and solicits
>     final comments on this action. Please send substant= ive comments to the
>     ietf@ietf.o= rg <mailto:ietf@ietf.org> ma= iling lists by 2016-03-09.
>     Exceptionally, comments may be
>     sent to iesg@ietf.= org <mailto:iesg@ietf.org> i= nstead. In either
>     case, please retain the
>     beginning of the Subject line to allow automated so= rting.
>
>     Abstract
>
>
>        This document outlines the audio codec and = processing requirements
>        for WebRTC endpoints.
>
>
>
>
>     The file can be obtained via
>     https://datatracker= .ietf.org/doc/draft-ietf-rtcweb-audio/
>
>     IESG discussion can be tracked via
>     https://data= tracker.ietf.org/doc/draft-ietf-rtcweb-audio/ballot/
>
>
>     No IPR declarations have been submitted directly on= this I-D.
>
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ie= tf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/lis= tinfo/rtcweb
>
>

--_000_SN1PR0301MB15510A18734956A22BD5FB5AB2A60SN1PR0301MB1551_-- From nobody Thu Feb 25 12:58:35 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7461B3536 for ; Thu, 25 Feb 2016 12:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xN2ZpsQVC9z4 for ; Thu, 25 Feb 2016 12:58:31 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725551B3535 for ; Thu, 25 Feb 2016 12:58:31 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id g203so101750147iof.2 for ; Thu, 25 Feb 2016 12:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=2w8/m4peEGfE1dftwMAtHHOQKIyzA2U2KoKqnk9NWn8=; b=ImV8pfq9CSITsbFGvdgY2v6O2G1tSp7gOPNRTtzENRdQcx3+IVF4lFnBLWmoRLI0Ll 0lfMfg8klTzAarQZ0ZHcAxL3Uv50OWCN4IGHV48nifL+TEnrca3FAl6/LT7A2wavA518 j/Kf83XvHReWgI3nfrGYHnBup/hv5lHs1Cbs+NfvBfAo8Oz6+KPWne9QSbORq81WZ1MN B/CFNE+Mhavq+yF1cOzyJYRUdCCcrinesKh6H4ppLIfdQ5awZtR7tWi+mhlda+SQAbnO lpAA2zqX1gYsrMqMGxCGK4gt/Mt29J5bzGuR6C8zj/mzzjJlaoAG9ISstkZIrm/IXxUE VmVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2w8/m4peEGfE1dftwMAtHHOQKIyzA2U2KoKqnk9NWn8=; b=SuptuSVODCYppvLl0+CJphmegqJBmgwhI6k5EJOybs1KKY3KZaJk4kWmv0Yc+Lhh1t jOvW9bKveZqSV3eJnXaLkBErBE9iPY7dr0NHZxIWpX61sgLLB3161q83sBO2wlikvVA6 yIl82Dz5iXWelRTKbP/lPYwU/eAp+cMRR69Uf2z51ZLAR/W8ssg9pQwZdYEH9R8aBaIO 07nAnEb4ZWRzJFgpWS2p8IfVuaM8N7knrQJ5zRzJvOhUBAq7UDlE8NM6CAMLEqRDuJii Hl+qlm0si6wnbXl1hPjqI45Q3KbR3vafOxtOx6+zSSPiz3lCnjSMWG4m8w0J66U5+xf8 IdCA== X-Gm-Message-State: AG10YOT2t2NDmgcCp8T0t1D41+U+4y084EnwZY16hbyuk/Ohf1Dk+kBqesZpyJ3IkK7zbw== X-Received: by 10.107.128.21 with SMTP id b21mr5635672iod.143.1456433910800; Thu, 25 Feb 2016 12:58:30 -0800 (PST) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com. [209.85.213.180]) by smtp.gmail.com with ESMTPSA id o65sm3969487ioi.24.2016.02.25.12.58.29 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 12:58:29 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id y8so23702862igp.0 for ; Thu, 25 Feb 2016 12:58:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.159.7 with SMTP id wy7mr752483igb.24.1456433908805; Thu, 25 Feb 2016 12:58:28 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 25 Feb 2016 12:58:28 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> Date: Thu, 25 Feb 2016 15:58:28 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a1136a72ec5faa1052c9e719f Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 20:58:33 -0000 --001a1136a72ec5faa1052c9e719f Content-Type: text/plain; charset=UTF-8 Tolga, In the proposed text I have copied the requirements from https://www.w3.org/TR/webrtc/#rtcdtmfsender to make sure specifications are consistent with each other. Here is the text present in WebRTC TR: The duration parameter indicates the duration in ms to use for each character passed in the tones parameters. The duration cannot be more than 6000 ms or less than 40 ms. The default duration is 100 ms for each tone. The interToneGap parameter indicates the gap between tones. It must be at least 30 ms. The default value is 70 ms. I believe the limits in WebRTC TR are based on ITU-T Q.24, which are, in turn, based on physical limitation imposed by transmitting DTMF tones using 8Khz audio. It is physically impossible to design an inband DTMF detector which can detect DTMF digits of duration less then 40 ms with gaps less then 30 ms and still be capable of handling talk off. This requirement is the MUST level to provide minimal support necessary for PSTN interop. Regards, _____________ Roman Shpount On Thu, Feb 25, 2016 at 2:44 PM, Asveren, Tolga wrote: > Roman, > > > What is the rationale of having this "MUST" strength mandate? > > > Thanks, > > Tolga > > > ------------------------------ > *From:* rtcweb on behalf of Ted Hardie < > ted.ietf@gmail.com> > *Sent:* Thursday, February 25, 2016 1:07 PM > *To:* rtcweb@ietf.org > *Subject:* [rtcweb] Fwd: Last Call: > (WebRTC Audio Codec and Processing Requirements) to Proposed Standard > > Mailman claims this was auto-discarded and it doesn't show in the > archives, so I'm forwarding. I will separately check on why it got chucked. > > regards, > > Ted > ---------- Forwarded message ---------- > From: Jean-Marc Valin > Date: Wed, Feb 24, 2016 at 2:21 PM > Subject: Re: [rtcweb] Last Call: (WebRTC > Audio Codec and Processing Requirements) to Proposed Standard > To: Roman Shpount , rtcweb-chairs@ietf.org, > alcoop@cisco.com, "rtcweb@ietf.org" , > draft-ietf-rtcweb-audio@ietf.org > > > On 02/24/2016 04:42 PM, Roman Shpount wrote: > > Generated events MUST have duration of no more than 6000 ms and no > > less than 40 ms with the recommended default duration of 100 ms for each > > tone. The gap between events MUST be no less then 30 ms with the > > recommended default duration of 70 ms. > > OK, I missed that part, but I'm fine with it. Unless anyone objects, I > can add it to the draft. > > Jean-Marc > > > > Regards, > > _____________ > > Roman Shpount > > > > On Wed, Feb 24, 2016 at 4:31 PM, The IESG > > wrote: > > > > > > The IESG has received a request from the Real-Time Communication in > > WEB-browsers WG (rtcweb) to consider the following document: > > - 'WebRTC Audio Codec and Processing Requirements' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to > the > > ietf@ietf.org mailing lists by 2016-03-09. > > Exceptionally, comments may be > > sent to iesg@ietf.org instead. In either > > case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document outlines the audio codec and processing requirements > > for WebRTC endpoints. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1136a72ec5faa1052c9e719f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tolga,

In the proposed text I have copied th= e requirements from =C2=A0https://www.w3.org/TR/webrtc/#rtcdtmfsender to make sure specifi= cations are consistent with each other. Here is the text present in WebRTC = TR:

The duration parameter indicates the duration in ms to use for = each character passed in the tones parameters. The duration cannot be more = than 6000 ms or less than 40 ms. The default duration is 100 ms for each to= ne.

The interToneGap parameter indicates the gap b= etween tones. It must be at least 30 ms. The default value is 70 ms.
<= /blockquote>

I believe the limits in WebRTC TR are based on ITU-T Q.24, which are, in t= urn, based on physical limitation imposed by transmitting DTMF tones using = 8Khz audio. It is physically impossible to design an inband DTMF detector w= hich can detect DTMF digits of duration less then 40 ms with gaps less then= 30 ms and still be capable of handling talk off. This requirement is the M= UST level to provide minimal support necessary for PSTN interop.

Regards,
_____________
Roman Shpoun= t

On Thu, Feb 25, 2016 at 2:44 PM, Asveren, To= lga <tasveren@sonusnet.com> wrote:

Roman,


What is the rationale of having this "MUST" strength mandate?<= /p>


Thanks,

Tolga



From: rtcweb <rtcweb-bounces@ietf.org> on behalf of = Ted Hardie <ted.= ietf@gmail.com>
Sent: Thursday, February 25, 2016 1:07 PM
To: rtcweb@ietf= .org
Subject: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt= > (WebRTC Audio Codec and Processing Requirements) to Proposed Standard<= /font>
=C2=A0
Mailman claims this was auto-discarded and it doesn't show in the = archives, so I'm forwarding.=C2=A0 I will separately check on why it go= t chucked.

regards,

Ted
---------- Forwarded message ----------
From: Jean-Marc Valin &= lt;jmvalin@jmvalin.= ca>
Date: Wed, Feb 24, 2016 at 2:21 PM
Subject: Re: [rtcweb] Last Call: <draft-ietf-rtcweb-audio-10.txt> (We= bRTC Audio Codec and Processing Requirements) to Proposed Standard
To: Roman Shpount <roman@telurix.com>, rtcweb-chairs@ietf.org, alcoop@cisco.com, "rtcweb@ietf.org" <rtcweb@ietf.org>, draft= -ietf-rtcweb-audio@ietf.org


On 02/24/2016 04:42 PM, Roman Shpount wrote:
> Generated events MUST have duration of no more than 6000 ms and no
> less than 40 ms with the recommended default duration of 100 ms for ea= ch
> tone. The gap between events MUST be no less then 30 ms with the
> recommended default duration of 70 ms.

OK, I missed that part, but I'm fine with it. Unless anyone obje= cts, I
can add it to the draft.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jean-Marc


> Regards,
> _____________
> Roman Shpount
>
> On Wed, Feb 24, 2016 at 4:31 PM, The IESG <iesg-secretary@ietf.org
> <mailto:iesg-secretary@ietf.org>> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0The IESG has received a request from the Real-Time = Communication in
>=C2=A0 =C2=A0 =C2=A0WEB-browsers WG (rtcweb) to consider the following = document:
>=C2=A0 =C2=A0 =C2=A0- 'WebRTC Audio Codec and Processing Requiremen= ts'
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<draft-ietf-rtcweb-audio-10.txt> as Pr= oposed Standard
>
>=C2=A0 =C2=A0 =C2=A0The IESG plans to make a decision in the next few w= eeks, and solicits
>=C2=A0 =C2=A0 =C2=A0final comments on this action. Please send substant= ive comments to the
>=C2=A0 =C2=A0 =C2=A0ietf@ietf.org <mailto:ietf@ietf.org> mailing lists by 2016-03-09.
>=C2=A0 =C2=A0 =C2=A0Exceptionally, comments may be
>=C2=A0 =C2=A0 =C2=A0sent to iesg@ietf.org <mailto:iesg@ietf.org> instead. In either
>=C2=A0 =C2=A0 =C2=A0case, please retain the
>=C2=A0 =C2=A0 =C2=A0beginning of the Subject line to allow automated so= rting.
>
>=C2=A0 =C2=A0 =C2=A0Abstract
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 This document outlines the audio codec and = processing requirements
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 for WebRTC endpoints.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0The file can be obtained via
>=C2=A0 =C2=A0 =C2=A0https://datatracker= .ietf.org/doc/draft-ietf-rtcweb-audio/
>
>=C2=A0 =C2=A0 =C2=A0IESG discussion can be tracked via
>=C2=A0 =C2=A0 =C2=A0https://data= tracker.ietf.org/doc/draft-ietf-rtcweb-audio/ballot/
>
>
>=C2=A0 =C2=A0 =C2=A0No IPR declarations have been submitted directly on= this I-D.
>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0rtcweb mailing list
>=C2=A0 =C2=A0 =C2=A0rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/lis= tinfo/rtcweb
>
>


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--001a1136a72ec5faa1052c9e719f-- From nobody Thu Feb 25 23:38:35 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DCE1ACE15 for ; Thu, 25 Feb 2016 23:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.205 X-Spam-Level: X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTD7Dw8sN-Re for ; Thu, 25 Feb 2016 23:38:29 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98ECF1ACE12 for ; Thu, 25 Feb 2016 23:38:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id A7E507C5253; Fri, 26 Feb 2016 08:38:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74hrDHTe3JxV; Fri, 26 Feb 2016 08:38:23 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:3d51:6ebb:6436:f9a]) by mork.alvestrand.no (Postfix) with ESMTPSA id D24F37C3E2F; Fri, 26 Feb 2016 08:38:23 +0100 (CET) To: Roman Shpount , "Asveren, Tolga" References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> From: Harald Alvestrand Message-ID: <56D000EF.9010004@alvestrand.no> Date: Fri, 26 Feb 2016 08:38:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050305010609050906080709" Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 07:38:32 -0000 This is a multi-part message in MIME format. --------------050305010609050906080709 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Roman, you're the expert here - googling for the text unearthed this message from you in 2013: https://lists.w3.org/Archives/Public/public-webrtc/2013Apr/0030.html Reviewiing that archive might save you the effort of repeating the arguments again; at the moment, I have no idea where the upper limit came from. On 02/25/2016 09:58 PM, Roman Shpount wrote: > Tolga, > > In the proposed text I have copied the requirements from > https://www.w3.org/TR/webrtc/#rtcdtmfsender to make sure > specifications are consistent with each other. Here is the text > present in WebRTC TR: > > The duration parameter indicates the duration in ms to use for > each character passed in the tones parameters. The duration cannot > be more than 6000 ms or less than 40 ms. The default duration is > 100 ms for each tone. > > The interToneGap parameter indicates the gap between tones. It > must be at least 30 ms. The default value is 70 ms. > > > I believe the limits in WebRTC TR are based on ITU-T Q.24, which are, > in turn, based on physical limitation imposed by transmitting DTMF > tones using 8Khz audio. It is physically impossible to design an > inband DTMF detector which can detect DTMF digits of duration less > then 40 ms with gaps less then 30 ms and still be capable of handling > talk off. This requirement is the MUST level to provide minimal > support necessary for PSTN interop. > > Regards, > _____________ > Roman Shpount > > On Thu, Feb 25, 2016 at 2:44 PM, Asveren, Tolga > wrote: > > Roman, > > > What is the rationale of having this "MUST" strength mandate? > > > Thanks, > > Tolga > > > > ------------------------------------------------------------------------ > *From:* rtcweb > on behalf of Ted Hardie > > > *Sent:* Thursday, February 25, 2016 1:07 PM > *To:* rtcweb@ietf.org > *Subject:* [rtcweb] Fwd: Last Call: > (WebRTC Audio Codec and > Processing Requirements) to Proposed Standard > > Mailman claims this was auto-discarded and it doesn't show in the > archives, so I'm forwarding. I will separately check on why it > got chucked. > > regards, > > Ted > ---------- Forwarded message ---------- > From: *Jean-Marc Valin* > > Date: Wed, Feb 24, 2016 at 2:21 PM > Subject: Re: [rtcweb] Last Call: > (WebRTC Audio Codec and Processing Requirements) to Proposed Standard > To: Roman Shpount >, > rtcweb-chairs@ietf.org , > alcoop@cisco.com , "rtcweb@ietf.org > " >, draft-ietf-rtcweb-audio@ietf.org > > > > On 02/24/2016 04:42 PM, Roman Shpount wrote: > > Generated events MUST have duration of no more than 6000 ms and no > > less than 40 ms with the recommended default duration of 100 ms > for each > > tone. The gap between events MUST be no less then 30 ms with the > > recommended default duration of 70 ms. > > OK, I missed that part, but I'm fine with it. Unless anyone objects, I > can add it to the draft. > > Jean-Marc > > > > Regards, > > _____________ > > Roman Shpount > > > > On Wed, Feb 24, 2016 at 4:31 PM, The IESG > > > >> wrote: > > > > > > The IESG has received a request from the Real-Time > Communication in > > WEB-browsers WG (rtcweb) to consider the following document: > > - 'WebRTC Audio Codec and Processing Requirements' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and > solicits > > final comments on this action. Please send substantive > comments to the > > ietf@ietf.org > mailing lists by 2016-03-09. > > Exceptionally, comments may be > > sent to iesg@ietf.org > > instead. In either > > case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document outlines the audio codec and processing > requirements > > for WebRTC endpoints. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------050305010609050906080709 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Roman, you're the expert here - googling for the text unearthed this message from you in 2013:

https://lists.w3.org/Archives/Public/public-webrtc/2013Apr/0030.html

Reviewiing that archive might save you the effort of repeating the arguments again; at the moment, I have no idea where the upper limit came from.


On 02/25/2016 09:58 PM, Roman Shpount wrote:
Tolga,

In the proposed text I have copied the requirements from https://www.w3.org/TR/webrtc/#rtcdtmfsender to make sure specifications are consistent with each other. Here is the text present in WebRTC TR:

The duration parameter indicates the duration in ms to use for each character passed in the tones parameters. The duration cannot be more than 6000 ms or less than 40 ms. The default duration is 100 ms for each tone.

The interToneGap parameter indicates the gap between tones. It must be at least 30 ms. The default value is 70 ms.

I believe the limits in WebRTC TR are based on ITU-T Q.24, which are, in turn, based on physical limitation imposed by transmitting DTMF tones using 8Khz audio. It is physically impossible to design an inband DTMF detector which can detect DTMF digits of duration less then 40 ms with gaps less then 30 ms and still be capable of handling talk off. This requirement is the MUST level to provide minimal support necessary for PSTN interop.

Regards,
_____________
Roman Shpount

On Thu, Feb 25, 2016 at 2:44 PM, Asveren, Tolga <tasveren@sonusnet.com> wrote:

Roman,


What is the rationale of having this "MUST" strength mandate?


Thanks,

Tolga



From: rtcweb <rtcweb-bounces@ietf.org> on behalf of Ted Hardie <ted.ietf@gmail.com>
Sent: Thursday, February 25, 2016 1:07 PM
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard
Mailman claims this was auto-discarded and it doesn't show in the archives, so I'm forwarding. I will separately check on why it got chucked.

regards,

Ted
---------- Forwarded message ----------
From: Jean-Marc Valin <jmvalin@jmvalin.ca>
Date: Wed, Feb 24, 2016 at 2:21 PM
Subject: Re: [rtcweb] Last Call: <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard
To: Roman Shpount <roman@telurix.com>, rtcweb-chairs@ietf.org, alcoop@cisco.com, "rtcweb@ietf.org" <rtcweb@ietf.org>, draft-ietf-rtcweb-audio@ietf.org


On 02/24/2016 04:42 PM, Roman Shpount wrote:
> Generated events MUST have duration of no more than 6000 ms and no
> less than 40 ms with the recommended default duration of 100 ms for each
> tone. The gap between events MUST be no less then 30 ms with the
> recommended default duration of 70 ms.

OK, I missed that part, but I'm fine with it. Unless anyone objects, I
can add it to the draft.

Jean-Marc


> Regards,
> _____________
> Roman Shpount
>
> On Wed, Feb 24, 2016 at 4:31 PM, The IESG <iesg-secretary@ietf.org
> <mailto:iesg-secretary@ietf.org>> wrote:
>
>
> The IESG has received a request from the Real-Time Communication in
> WEB-browsers WG (rtcweb) to consider the following document:
> - 'WebRTC Audio Codec and Processing Requirements'
> <draft-ietf-rtcweb-audio-10.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org <mailto:ietf@ietf.org> mailing lists by 2016-03-09.
> Exceptionally, comments may be
> sent to iesg@ietf.org <mailto:iesg@ietf.org> instead. In either
> case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
> This document outlines the audio codec and processing requirements
> for WebRTC endpoints.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org <mailto:rtcweb@ietf.org>
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------050305010609050906080709-- From nobody Fri Feb 26 00:15:02 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7F11A1BF8 for ; Fri, 26 Feb 2016 00:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5kyEI7qr4ct for ; Fri, 26 Feb 2016 00:14:56 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FB31A1BBB for ; Fri, 26 Feb 2016 00:14:56 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id y89so59965297qge.2 for ; Fri, 26 Feb 2016 00:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=UXUvCOFvC5t1KgIFPQ2XknrUDFiyiI+AxpZu6Chz0Zc=; b=dlEaXgJ9M0Io4GKOw+KVflObwF1XJhRLKK8F2Y7T4Y/mLoIMd8rFWZqbX3Ytu6mv2J Qq1ig/uqcRaJBUm3jYUCG4EKyXnzvdUcSGMJQeD0aRMwWrnGLygekAYfLtrz0spGO6cN GWP+mlqRviA9y0uy4iSszcmieZ1VKOjx4fHrs4IHK28poRUr6ETvBdL+tuo9trMM4pcn zV34bW0DA37uo4EH4qXBYE8PCaKbsk1NY2Q9WjB67t23GyQsH5Ot/LBZ4VMmr2ZOeC8p WAdw2zru1j0tJAE7BNdjH4YE8DEBvPuM9Bj+Sc3R6HNg5RW5O56TGmz6+1i9p/nDyzwA XXAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=UXUvCOFvC5t1KgIFPQ2XknrUDFiyiI+AxpZu6Chz0Zc=; b=Bb30KHLogogw27pr+wqdWf6S1yvNCsiCHxJt/Bn6UVxLN8G0zi35wuO/fKqOBcNzI3 NK4R2RKn2gCEZO1UAMMPNP/suRxsoZpnXMEMGLEFXBcN06v+1aIJWmeKPxnRTEnu4a4f aNAZb7GIqYITpQUILl+qYxCE/mk0P1F3BoyPo7LE48J5iicBZwIOGgD+rlgryN3fO2fN qQe/rsOiyC2ODwZVeY+3PQ3CATgLeAf3g0f1kenseIlcR8ghi2W1gBetNqR9rgPKdWFd p2QH2pr77cHJte11NwXufTUK40Or+te3wOP2lSw6/KBsoE2jAtvzvcatokULVgSIFG9t IzSg== X-Gm-Message-State: AD7BkJJMP7Yn2XYUwMr+ppxhuCSCYs/Aop+r3yHTJ3JjL6u5aCmiNH0kPt9LLoUvd89JJD/y X-Received: by 10.140.237.204 with SMTP id i195mr252892qhc.55.1456474495252; Fri, 26 Feb 2016 00:14:55 -0800 (PST) Received: from panoramix.jmvalin.ca (modemcable121.240-21-96.mc.videotron.ca. [96.21.240.121]) by smtp.gmail.com with ESMTPSA id y206sm4870827qhc.0.2016.02.26.00.14.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 00:14:54 -0800 (PST) To: Roman Shpount , "Asveren, Tolga" References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> From: Jean-Marc Valin Message-ID: <56D0097D.40308@mozilla.com> Date: Fri, 26 Feb 2016 03:14:53 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 08:15:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Roman, Just as a clarification, are we talking about the duration of RFC4733 tone events or the duration of audio tones (or both)? I agree that going below 40 ms is just not possible. As for the upper bound, more than 6000 ms is definitely insane, but I have no precise opinion on the exact threshold that should be used, or why anyone would want such long tones in the first place. Cheers, Jean-Marc On 02/25/2016 03:58 PM, Roman Shpount wrote: > Tolga, > > In the proposed text I have copied the requirements from > https://www.w3.org/TR/webrtc/#rtcdtmfsender to make sure > specifications are consistent with each other. Here is the text > present in WebRTC TR: > > The duration parameter indicates the duration in ms to use for > each character passed in the tones parameters. The duration cannot > be more than 6000 ms or less than 40 ms. The default duration is > 100 ms for each tone. > > The interToneGap parameter indicates the gap between tones. It > must be at least 30 ms. The default value is 70 ms. > > > I believe the limits in WebRTC TR are based on ITU-T Q.24, which > are, in turn, based on physical limitation imposed by transmitting > DTMF tones using 8Khz audio. It is physically impossible to design > an inband DTMF detector which can detect DTMF digits of duration > less then 40 ms with gaps less then 30 ms and still be capable of > handling talk off. This requirement is the MUST level to provide > minimal support necessary for PSTN interop. > > Regards, _____________ Roman Shpount > > On Thu, Feb 25, 2016 at 2:44 PM, Asveren, Tolga > > wrote: > > Roman, > > > What is the rationale of having this "MUST" strength mandate? > > > Thanks, > > Tolga > > > > ---------------------------------------------------------------------- - -- > > *From:* rtcweb > on behalf of Ted Hardie > > *Sent:* Thursday, > February 25, 2016 1:07 PM *To:* rtcweb@ietf.org > *Subject:* [rtcweb] Fwd: Last Call: > (WebRTC Audio Codec and Processing > Requirements) to Proposed Standard > > Mailman claims this was auto-discarded and it doesn't show in the > archives, so I'm forwarding. I will separately check on why it > got chucked. > > regards, > > Ted ---------- Forwarded message ---------- From: *Jean-Marc Valin* > > Date: Wed, Feb 24, > 2016 at 2:21 PM Subject: Re: [rtcweb] Last Call: > (WebRTC Audio Codec and Processing > Requirements) to Proposed Standard To: Roman Shpount > >, > rtcweb-chairs@ietf.org , > alcoop@cisco.com , "rtcweb@ietf.org > " >, draft-ietf-rtcweb-audio@ietf.org > > > > On 02/24/2016 04:42 PM, Roman Shpount wrote: >> Generated events MUST have duration of no more than 6000 ms and >> no less than 40 ms with the recommended default duration of 100 >> ms for each tone. The gap between events MUST be no less then 30 >> ms with the recommended default duration of 70 ms. > > OK, I missed that part, but I'm fine with it. Unless anyone > objects, I can add it to the draft. > > Jean-Marc > > >> Regards, _____________ Roman Shpount >> >> On Wed, Feb 24, 2016 at 4:31 PM, The IESG >> >> > >> wrote: >> >> >> The IESG has received a request from the Real-Time Communication >> in WEB-browsers WG (rtcweb) to consider the following document: - >> 'WebRTC Audio Codec and Processing Requirements' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and >> solicits final comments on this action. Please send substantive >> comments to the ietf@ietf.org >> > mailing lists by 2016-03-09. >> Exceptionally, comments may be sent to iesg@ietf.org >> > > instead. In either >> case, please retain the beginning of the Subject line to allow >> automated sorting. >> >> Abstract >> >> >> This document outlines the audio codec and processing >> requirements for WebRTC endpoints. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> _______________________________________________ rtcweb mailing >> list rtcweb@ietf.org > > >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > _______________________________________________ rtcweb mailing > list rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ rtcweb mailing > list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW0Al6AAoJEJ6/8sItn9q9esMH/19lsbFBvYNUXwu9nzDSm03H iNbdErApJiny7n75Hz1W/+ujItui+NjpKS1enj2/bpsN4qdExQlsRs+ksAN3GyL8 /2Oto1bnB0fRtTtJHUrOCM0469rSt/QrTeKfBf7EnR3e9uzfQid75lFD9WlHsz8A P3ubJK4Wy3JO5MmLDSiqqXVCZsTy+iws5hKTFGLK88uiRZ7lE7apcMS3ig2hCGKF nr2KSS44juvsJ64qGHaIXxNzSe2Treini60dNQ7d77tLoeoUCdN2dbF3w/38LdQE W/0LS4hORcq9xB1ndptJ2StXg8fUmVgNcHd3WE1RrHV8JlO9VFBuAE1AS4asGqk= =7BbB -----END PGP SIGNATURE----- From nobody Fri Feb 26 03:20:25 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C689C1B29C4 for ; Fri, 26 Feb 2016 03:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjVIg2zU2ZGG for ; Fri, 26 Feb 2016 03:20:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0673.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::673]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21681B29BF for ; Fri, 26 Feb 2016 03:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vqWB7aYQlwK3hH/13kmnpGjRu1OBWCHbdedDEhHq9R8=; b=uBAqU1u+JvjAXYNwwUkhK8Sb/irYYxUtnqLVgDlbiXRR2QennTd7Q7T8YD/z1hT70xabx/3G1wR0kTnaEoIRLemZgfLs05yV50ABZ8oIgWLArwkQ09SfYYdsjFEs+lTj6h/Pvv352RU2WYSWbYSbmaSLiZgLoD3fraZvr9PZl5Y= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1550.namprd03.prod.outlook.com (10.162.129.156) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 26 Feb 2016 11:19:55 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Fri, 26 Feb 2016 11:19:55 +0000 From: "Asveren, Tolga" To: Harald Alvestrand , Roman Shpount Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p89KcurgAAU0gCAALLLgIAAOucg Date: Fri, 26 Feb 2016 11:19:55 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> In-Reply-To: <56D000EF.9010004@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alvestrand.no; dkim=none (message not signed) header.d=none; alvestrand.no; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: e85a9048-fd9b-4bb9-34c3-08d33e9ec10a x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1550; 5:HRIMIUaLisWhSMFYSDmGsANMkJSqJ/+ZBDgqBTSwo1N3ddycHtAh9Ilx4Pe2SnX5gf3Zj/LGFUvWspjMGtregusDXKx3Fa//rgbrlAXPco/T9eQOpGl1gRhqbco1ULUlb+t7RgBBmQ3jQf3o+0cTJQ==; 24:6DZqqGBCbgTM9LBzRLIbPic++EulhVucFTsLasymn+gfFlaY7IJPUZxCbJT7L6LmbewRHGf7RxXZBu/5XGeIovhvbW1U9w0a88Z8XQf3BvI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1550; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR0301MB1550; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1550; x-forefront-prvs: 0864A36BBF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(479174004)(164054003)(2473001)(24454002)(22974007)(377454003)(87936001)(102836003)(3846002)(1096002)(11100500001)(50986999)(76176999)(54356999)(106116001)(189998001)(19300405004)(93886004)(76576001)(5001960100002)(66066001)(1220700001)(230783001)(86362001)(5008740100001)(4326007)(16236675004)(19625215002)(5004730100002)(2906002)(2950100001)(586003)(790700001)(74316001)(3660700001)(2900100001)(6116002)(3280700002)(5001770100001)(15975445007)(3900700001)(92566002)(19617315012)(10400500002)(33656002)(5003600100002)(122556002)(19580405001)(77096005)(19580395003)(40100003)(99286002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1550; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB15518B65A2E7D2ACFE2663B4B2A70SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2016 11:19:55.2392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1550 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 11:20:24 -0000 --_000_SN1PR0301MB15518B65A2E7D2ACFE2663B4B2A70SN1PR0301MB1551_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable i- I think w3org should have followed the lead of IETF in this issue rather= than the other way around, i.e. the values recommended by the IETF specifi= cation should have been cited in the w3org document IMHO. ii- The reasonable value range could depend on the negotiated codec and tha= t would be known at the time of interesting the digits; so anything with MU= ST strength is too restrictive IMHO. iii- The presence of transcoding/interworking (between different forms of d= igit transfer) devices (they will be there, whether we like it or not, for = certain scenarios) makes it even less desirable to have MUST strength manda= tes. iv- I think adding some text regarding gap/duration of digit packets could = be fine but I rather would prefer it with "recommend" (even not RECOMMEND) = (and providing some values only as examples). Thanks, Tolga From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Friday, February 26, 2016 2:38 AM To: Roman Shpount ; Asveren, Tolga Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: Last Call: (Web= RTC Audio Codec and Processing Requirements) to Proposed Standard Roman, you're the expert here - googling for the text unearthed this messag= e from you in 2013: https://lists.w3.org/Archives/Public/public-webrtc/2013Apr/0030.html Reviewiing that archive might save you the effort of repeating the argument= s again; at the moment, I have no idea where the upper limit came from. On 02/25/2016 09:58 PM, Roman Shpount wrote: Tolga, In the proposed text I have copied the requirements from https://www.w3.or= g/TR/webrtc/#rtcdtmfsender to make sure specifications are consistent with = each other. Here is the text present in WebRTC TR: The duration parameter indicates the duration in ms to use for each charact= er passed in the tones parameters. The duration cannot be more than 6000 ms= or less than 40 ms. The default duration is 100 ms for each tone. The interToneGap parameter indicates the gap between tones. It must be at l= east 30 ms. The default value is 70 ms. I believe the limits in WebRTC TR are based on ITU-T Q.24, which are, in tu= rn, based on physical limitation imposed by transmitting DTMF tones using 8= Khz audio. It is physically impossible to design an inband DTMF detector wh= ich can detect DTMF digits of duration less then 40 ms with gaps less then = 30 ms and still be capable of handling talk off. This requirement is the MU= ST level to provide minimal support necessary for PSTN interop. Regards, _____________ Roman Shpount On Thu, Feb 25, 2016 at 2:44 PM, Asveren, Tolga > wrote: Roman, What is the rationale of having this "MUST" strength mandate? Thanks, Tolga ________________________________ From: rtcweb > on b= ehalf of Ted Hardie > Sent: Thursday, February 25, 2016 1:07 PM To: rtcweb@ietf.org Subject: [rtcweb] Fwd: Last Call: (WebRTC = Audio Codec and Processing Requirements) to Proposed Standard Mailman claims this was auto-discarded and it doesn't show in the archives,= so I'm forwarding. I will separately check on why it got chucked. regards, Ted ---------- Forwarded message ---------- From: Jean-Marc Valin > Date: Wed, Feb 24, 2016 at 2:21 PM Subject: Re: [rtcweb] Last Call: (WebRTC A= udio Codec and Processing Requirements) to Proposed Standard To: Roman Shpount >, rtcweb-cha= irs@ietf.org, alcoop@cisco.com, "rtcweb@ietf.org" >, draft-ietf-rtcweb-audio@ietf.org On 02/24/2016 04:42 PM, Roman Shpount wrote: > Generated events MUST have duration of no more than 6000 ms and no > less than 40 ms with the recommended default duration of 100 ms for each > tone. The gap between events MUST be no less then 30 ms with the > recommended default duration of 70 ms. OK, I missed that part, but I'm fine with it. Unless anyone objects, I can add it to the draft. Jean-Marc > Regards, > _____________ > Roman Shpount > > On Wed, Feb 24, 2016 at 4:31 PM, The IESG > >> wrote: > > > The IESG has received a request from the Real-Time Communication in > WEB-browsers WG (rtcweb) to consider the following document: > - 'WebRTC Audio Codec and Processing Requirements' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to th= e > ietf@ietf.org > mailing lists by 2016-03-09. > Exceptionally, comments may be > sent to iesg@ietf.org > instead. In either > case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document outlines the audio codec and processing requirements > for WebRTC endpoints. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_SN1PR0301MB15518B65A2E7D2ACFE2663B4B2A70SN1PR0301MB1551_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

i- I think w3org should have followed= the lead of IETF in this issue rather than the other way around, i.e. the = values recommended by the IETF specification should have been cited in the w3org document IMHO.

 

ii- The reasonable value range could = depend on the negotiated codec and that would be known at the time of inter= esting the digits; so anything with MUST strength is too restrictive IMHO.

 

iii- The presence of transcoding/inte= rworking (between different forms of digit transfer) devices (they will be = there, whether we like it or not, for certain scenarios) makes it even less desirable to have MUST strength mandates.

 

iv- I think adding some text regardin= g gap/duration of digit packets could be fine but I rather would prefer it = with “recommend” (even not RECOMMEND) (and providing some values only as examples).

 

Thanks,

Tolga

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Friday, February 26, 2016 2:38 AM
To: Roman Shpount <roman@telurix.com>; Asveren, Tolga <tasv= eren@sonusnet.com>
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10= .txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Stand= ard

 

Tolga,

 

In the proposed text I have copied the requirements = from  https://= www.w3.org/TR/webrtc/#rtcdtmfsender to make sure specifications are con= sistent with each other. Here is the text present in WebRTC TR:

 

The duration parameter indicates the duration in ms = to use for each character passed in the tones parameters. The duration cann= ot be more than 6000 ms or less than 40 ms. The default duration is 100 ms = for each tone.

 

The interToneGap parameter indicates the gap between= tones. It must be at least 30 ms. The default value is 70 ms.

 

I believe the limits in WebRTC TR are based on ITU-T= Q.24, which are, in turn, based on physical limitation imposed by transmit= ting DTMF tones using 8Khz audio. It is physically impossible to design an = inband DTMF detector which can detect DTMF digits of duration less then 40 ms with gaps less then 30 ms and stil= l be capable of handling talk off. This requirement is the MUST level to pr= ovide minimal support necessary for PSTN interop.

 

Regards,

_____________
Roman Shpount

 

On Thu, Feb 25, 2016 at 2:44 PM, Asveren, Tolga <= tasveren@sonusnet.com> wrot= e:

Roman,

 

What is the rationale of having this "MUST" strengt= h mandate?

 

Thanks,

Tolga

 

From: rtc= web <rtcweb= -bounces@ietf.org> on behalf of Ted Hardie <ted.ietf= @gmail.com>
Sent: Thursday, February 25, 2016 1:07 PM
To: rtcweb@ietf= .org
Subject: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.txt= > (WebRTC Audio Codec and Processing Requirements) to Proposed Standard<= /span>

 

Mailman claims this = was auto-discarded and it doesn't show in the archives, so I'm forwarding.&= nbsp; I will separately check on why it got chucked.

regards,<= /span>

Ted

---------- Forwarded message ---------- From: Jean-Marc Valin <jmva= lin@jmvalin.ca>
Date: Wed, Feb 24, 2016 at 2:21 PM
Subject: Re: [rtcweb] Last Call: <draft-ietf-rtcweb-audio-10.txt> (We= bRTC Audio Codec and Processing Requirements) to Proposed Standard
To: Roman Shpount <roman@telurix.co= m>, rtcweb-chairs@ietf.org, alcoop@cisc= o.com, "rtcwe= b@ietf.org" <rtcweb@ietf.org>, draft= -ietf-rtcweb-audio@ietf.org


On 02/24/2016 04:42 PM, Roman Shpount wrote:
> Generated events MUST have duration of no more than 6000 ms and no
> less than 40 ms with the recommended default duration of 100 ms for ea= ch
> tone. The gap between events MUST be no less then 30 ms with the
> recommended default duration of 70 ms.

OK, I missed that part, but I'm fine with it. Unless anyone objects, I
can add it to the draft.

        Jean-Marc


> Regards,
> _____________
> Roman Shpount
>
> On Wed, Feb 24, 2016 at 4:31 PM, The IESG <iesg-secretary@ietf.org
> <mailto:iesg-secretary@i= etf.org>> wrote:
>
>
>     The IESG has received a request from the Real-Time = Communication in
>     WEB-browsers WG (rtcweb) to consider the following = document:
>     - 'WebRTC Audio Codec and Processing Requirements'<= br> >       <draft-ietf-rtcweb-audio-10.txt> as Pr= oposed Standard
>
>     The IESG plans to make a decision in the next few w= eeks, and solicits
>     final comments on this action. Please send substant= ive comments to the
>     ietf@ietf.org = <mailto:ietf@ietf.org= > mailing lists by 2016-03-09.
>     Exceptionally, comments may be
>     sent to iesg@ietf.= org <mailto:iesg@= ietf.org> instead. In either
>     case, please retain the
>     beginning of the Subject line to allow automated so= rting.
>
>     Abstract
>
>
>        This document outlines the audio codec and = processing requirements
>        for WebRTC endpoints.
>
>
>
>
>     The file can be obtained via
>     https://datatracker.ietf.org/doc/draft= -ietf-rtcweb-audio/
>
>     IESG discussion can be tracked via
>     https://datatracker.ietf.org/do= c/draft-ietf-rtcweb-audio/ballot/
>
>
>     No IPR declarations have been submitted directly on= this I-D.
>
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org<= /a> <mailto:rtcweb@= ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb >
>

 


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

 




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org

https://www.i=
etf.org/mailman/listinfo/rtcweb

 

--_000_SN1PR0301MB15518B65A2E7D2ACFE2663B4B2A70SN1PR0301MB1551_-- From nobody Fri Feb 26 05:10:12 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B4F1A90B3 for ; Fri, 26 Feb 2016 05:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2S6n_ld-pexb for ; Fri, 26 Feb 2016 05:10:09 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051741A909C for ; Fri, 26 Feb 2016 05:10:08 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aZI9m-0005Bs-DZ for rtcweb@ietf.org; Fri, 26 Feb 2016 14:10:06 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aZI9l-00021y-VE for rtcweb@ietf.org; Fri, 26 Feb 2016 14:10:06 +0100 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 26 Feb 2016 14:10:05 +0100 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 38701 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BBBF9B960FAE32DD9E7FEE6C4D55CA9A5B8A62AF X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 9280 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [rtcweb] Local prioritization in draft-ietf-rtcweb-transports-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 13:10:11 -0000 Hi, Overall, I like this document a lot - it makes for a very good read! - but I think it would make sense for section 4.1 to explicitly point to = draft-ietf-rmcat-coupled-cc (the next version of which is going to = explain how weights much be set to adhere to the priority levels that = are described in this section; it's easy, we just didn't have this text = in there yet). To be concrete, I suggest the following two changes: *** When an WebRTC implementation has packets to send on multiple streams that are congestion-controlled under the same congestion controller, the WebRTC implementation SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below. *** should be: *** When a WebRTC implementation has packets to send on multiple streams that are congestion-controlled under the same congestion controller or multiple coupled congestion controllers (e.g. using the mechanism = in [draft-ietf-rmcat-coupled-cc]), the WebRTC implementation SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below. *** (note a fixed nit in there: the second word is "a" instead of "an") and, perhaps even more importantly, a small change in section 4.2: *** More advice on the use of DSCP code points with RTP is given in [I-D.ietf-dart-dscp-rtp]. *** should be: *** More advice on the use of DSCP code points with RTP as well as = coupled congestion control is given in [I-D.ietf-dart-dscp-rtp]. *** and in fact I-D.ietf-dart-dscp-rtp should now be RFC 7657- Cheers, Michael From nobody Fri Feb 26 07:33:21 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9161A872E for ; Fri, 26 Feb 2016 07:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYd1pj0zFG7D for ; Fri, 26 Feb 2016 07:33:18 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE131A872D for ; Fri, 26 Feb 2016 07:33:17 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id g127so71677206ywf.2 for ; Fri, 26 Feb 2016 07:33:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=btBc6MLOLrK8+pyLj6EYaljrEY94g/0vuOFQo0cY+Ps=; b=IG/SPZNg8tXboAXSsTvl+PI3wkfaUgYtIkBZeI76ZvNROdnH0e65ZGnqVlaqmzsoZp ++HBMxJApXjPhkL5J/TdTrFmLPoIPRKwA9NNLgj29me5M9/jcmL0L9e760JKG6Sjd+88 n8GhFIl1+W+7DU/G0rBIaQWHY3p7CRZSkBEf4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=btBc6MLOLrK8+pyLj6EYaljrEY94g/0vuOFQo0cY+Ps=; b=dZ1YD++AICo1sCIuGDA/JXxN6LNZjP2eH2mELTN+xYj6d3vbaHUMsmegR+hSqiJ8kC v0+RkVD8Cx+hu1x6pkAZKMV2psFyDoLwT4yf2SrDAogeJ3A7ER5X+WyZpvfdy0IVLOoo CzaM0zyoSarA0R6shQh5xb8C8/naqNR+cZqxHC8QDY/5s2E76xrp1k2DPWYu3JBH4VPu qjsBskNCiOh6aZQUYfXcsBgJbOoKRlbJvnwzMVGfZJLmMpqgSjAY1wxIThxNNaRcoy1E EuY1pcPgLiIHEscVn+hLqmtQ95oLg9jw39MU+hChbmWkXcT1Wy9RE3ViBi4rdNtcCHPB 0XsQ== X-Gm-Message-State: AD7BkJIjceCB1Exisz5rp1pFZUbCmZv2NLXEMM1W5WmdVlobUuzCiU+h+uopajwvaBrmUQ== X-Received: by 10.129.129.198 with SMTP id r189mr1124364ywf.107.1456500797099; Fri, 26 Feb 2016 07:33:17 -0800 (PST) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id h68sm10148639ywd.42.2016.02.26.07.33.16 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Feb 2016 07:33:16 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <46276723-F9BF-4D5F-BDA3-76A00A8C27A1@sn3rd.com> Date: Fri, 26 Feb 2016 10:33:15 -0500 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [rtcweb] time to revise rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 15:33:19 -0000 All, Now that draft-ietf-mmusic-mux-exclusive is in WGLC over in MMUSIC = [0][1], the chairs of this WG think it=E2=80=99s time to revise = draft-ietf-rtcweb-rtp-usage with the text the WG discussed on list, = which was discussed in this thread [2]. Once the rtp-usage authors have = submitted a new draft, we'll be reconfirming the consensus on = draft-ietf-rtcweb-rtp-usage, i.e., we need to yank it back from the RFC = editor, make these changes, and then go through the process of getting = it back in the RFC editor=E2=80=99s queue. Cheers, spt [0] = https://mailarchive.ietf.org/arch/msg/mmusic/KxrTeCaOF_LTDeWJtLKSP06nH9U [1] And kudos to them for moving out so smartly. [2] = https://mailarchive.ietf.org/arch/msg/rtcweb/Yb3NpKuKSKIxRYYqPMNoNvyuIrc= From nobody Fri Feb 26 13:36:44 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC7B1B30E3 for ; Fri, 26 Feb 2016 13:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUcoVGI8nn_P for ; Fri, 26 Feb 2016 13:36:35 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CFA71B30DF for ; Fri, 26 Feb 2016 13:36:35 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id hb3so43069984igb.0 for ; Fri, 26 Feb 2016 13:36:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=55cw3G+I8HhnWkXri1odOWCQfb0DREOOQeksYXZi8Fw=; b=IelgkP/GzlZ/YVR47yFGhNDGi0ucUyIoFxHt6zZTLNr01khkm/kHjzyt1CQsx9MFx/ FYR5J96YNwSE0DKl/nkdGnlM5Z9TXVG2IjC/tPh1THo5hWM+9XMcpKcbmy6x4KNGTX97 mj1NGX+zIM4V554WMB3huzCEu73yx1fQ/N2SCbdtaat7L0gD82UJjVVcaxqejNOMw6J+ 6YLLXMjXIUbaqEttdqVr+kj6tc+FaXPwhganj1w4tvcTXPzY3c8WqkvoqDcspFLuabck mslknuotv3K8cH21IT2Bh1YF+lg6Mo0oHshd6qw4+QC+5DtUe4dwWXzslB53CvJvx6mI 27rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=55cw3G+I8HhnWkXri1odOWCQfb0DREOOQeksYXZi8Fw=; b=bVmtONwbMIOSAR1mqsyKoApLGK9r0dW1SD8TfnhflEvQUZSLyFMGvab3nNXZk6Zq5I CvBWe71/s/JYp8jsCr9xY4ElJ3lCtMpSKsRQLaTnQKBpWavh6sI9qZ2TeVlEl61aYssG 4/XgN1HMEjRekG23tfldaSgavHsrX8k42S1NQIHt9fM2OBIn/a7zh5BPNfNuV8SFlWug XkXH5vzqSQcOPVwPZzc/Op/j7JPMKJ6eGtdmr9g00y5CUAg2F9Xgs5g4bL+Djc5li+Em l8v5pfS87HV53A8xCsT1Z884dBdhHW2CsC1XWtgqwfTj4R2EgIE6sbNc0/XvRn1gHTaE oNDg== X-Gm-Message-State: AD7BkJKeAy32D3BONz22zqJ8psWMEQYJusALvhEgHtDwkr4ztjpsbPKGsWmrB+HSOyMfkg== X-Received: by 10.50.138.76 with SMTP id qo12mr60642igb.87.1456522594658; Fri, 26 Feb 2016 13:36:34 -0800 (PST) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id wz3sm2105035igb.16.2016.02.26.13.36.32 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 13:36:32 -0800 (PST) Received: by mail-io0-f171.google.com with SMTP id 9so130838185iom.1 for ; Fri, 26 Feb 2016 13:36:32 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.132.12 with SMTP id g12mr10471051iod.145.1456522592181; Fri, 26 Feb 2016 13:36:32 -0800 (PST) Received: by 10.36.105.77 with HTTP; Fri, 26 Feb 2016 13:36:32 -0800 (PST) In-Reply-To: <56D000EF.9010004@alvestrand.no> References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> Date: Fri, 26 Feb 2016 16:36:32 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a113ece60b73a7a052cb317f0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:36:37 -0000 --001a113ece60b73a7a052cb317f0 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 26, 2016 at 2:38 AM, Harald Alvestrand wrote: > Roman, you're the expert here - googling for the text unearthed this > message from you in 2013: > > https://lists.w3.org/Archives/Public/public-webrtc/2013Apr/0030.html > > Reviewiing that archive might save you the effort of repeating the > arguments again; at the moment, I have no idea where the upper limit came > from. > > Harald, All I am trying to achieve is getting both WebRTC TR and draft-ietf-rtcweb-audio say the same thing. The current tone duration limitats are present in the W3C document. I do not necessarily agree with these limitations, but I do know where they come from. I do think these limitations should be reviewed by this group since they clearly define the network related aspects of DTMF tone generation. Whatever is decided by this group needs to be then replicated to W3C WebRTC document. The minimum duration for tone and the gap in the W3C document comes from ITU Q.24 specification. The maximum duration of 6 seconds is something Cullen put in when he wrote the document. Maximum duration of RFC 2833 tone or single segment RFC 4733 tone with 8 KHz RTP timestamps is about 8 seconds. If 48 KHz clock used, max single segment tone duration would be about 1.3 sec. I have not seen any implementations of RFC 4733 long duration events ( https://tools.ietf.org/html/rfc4733#section-2.5.1.3) in the wild since DTMF tones are mostly used with 8 KHz clocks and no one really cares about DTMF events longer then 8 sec. Support for multi-segment long duration DTMF events would be necessary if someone will decide to use DTMF with Opus since DTMF digits with duration longer then 1 sec are used by some IVR. My personal preference (as expressed in the quoted message) not to specify min and max duration for DTMF tones or gaps. I think having reasonable default values is enough. If developer cares enough to adjust the duration values, I assume he or she would know what they are doing. If they set something silly, they will have to deal with the consequences. Other people on the list wanted to limit the number of foot guns in the API and decided to put reasonable min and max limits on tone and gap duration. This is not my first preference, but I do not think these limits are unreasonable, so I did not object too much. Regards, _____________ Roman Shpount --001a113ece60b73a7a052cb317f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 26, 2016 at 2:3= 8 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
=
=20 =20 =20
Roman, you're the expert here - googling for the text unearthed this message from you in 2013:

https://lists.w3.org/Archives/Public/public-webrtc/= 2013Apr/0030.html

Reviewiing that archive might save you the effort of repeating the arguments again; at the moment, I have no idea where the upper limit came from.


Harald,

All I am trying = to achieve is getting both WebRTC TR and draft-ietf-rtcweb-audio say the sa= me thing. The current tone duration limitats are present in the W3C documen= t. I do not necessarily agree with these limitations, but I do know where t= hey come from. I do think these limitations should be reviewed by this grou= p since they clearly define the network related aspects of DTMF tone genera= tion. Whatever is decided by this group needs to be then replicated to W3C = WebRTC document.

The minimum duration for tone and the gap in the W3C document co= mes from ITU Q.24 specification.

=
The maximum duration of 6 seconds is something C= ullen put in when he wrote the document. Maximum duration of RFC 2833 tone = or single segment RFC 4733 tone with 8 KHz RTP timestamps is about 8 second= s. If 48 KHz clock used, max single segment tone duration would be about 1.= 3 sec. I have not seen any implementations of RFC 4733 long duration events= (https://t= ools.ietf.org/html/rfc4733#section-2.5.1.3) in the wild since DTMF tone= s are mostly used with 8 KHz clocks and no one really cares about DTMF even= ts longer then 8 sec. Support for multi-segment long duration DTMF events w= ould be necessary if someone will decide to use DTMF with Opus since DTMF d= igits with duration longer then 1 sec are used by some IVR.

My personal preferenc= e (as expressed in the quoted message) not to specify min and max duration = for DTMF tones or gaps. I think having reasonable default values is enough.= If developer cares enough to adjust the duration values, I assume he or sh= e would know what they are doing. If they set something silly, they will ha= ve to deal with the consequences.

Other people on the list wanted to limit the nu= mber of foot guns in the API and decided to put reasonable min and max limi= ts on tone and gap duration. This is not my first preference, but I do not = think these limits are unreasonable, so I did not object too much.

Regards,
_____________
Roman Shpount
=C2=A0
--001a113ece60b73a7a052cb317f0-- From nobody Fri Feb 26 13:38:31 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B23B1B30EB for ; Fri, 26 Feb 2016 13:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjvgCE5OYRVH for ; Fri, 26 Feb 2016 13:38:29 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 125D51B30EA for ; Fri, 26 Feb 2016 13:38:29 -0800 (PST) Received: by mail-ig0-x22c.google.com with SMTP id g6so47806759igt.1 for ; Fri, 26 Feb 2016 13:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=g/DpkP19AkbLyQyExs5LXr9BLdej1AnD+kdv/i3dkn0=; b=zFSmYTHBmvCDnnPTUsvnYdHP0M+ELRWakhtMd4z87hhnT1ejIBVweU9wWShb+tA52/ P/9N7vEreB5cz4otWCrEIr7CRNJeVGvfNI4dQKQywOzPf31IsN98skhFo+R31F+s4swd j6/aXCBrmfikBo/Eo8tPzh6OSigtk/ufqU/joih2BaCMqDHZSSNHaW0fFAjrnnMrILBK BMLX1XWA2ZinHwgaVtg7/1x+nZvMhc+d9gZ1tTigJAHVPyUCSBOD9V8Br0vnaukibgd0 Ef1oS1W/wSpgdEO0XPD9QhFeR8nzaLrgP+mELylKXizRaZpJN6rmcLO9+VBLmyQPahop G4kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=g/DpkP19AkbLyQyExs5LXr9BLdej1AnD+kdv/i3dkn0=; b=HCSdeI0mvZyPUIR6fm34wxq6eXc67hWm2PmPsK1siZ4/aMW0lSSzubNs24/Vj2mECI gdhB2cVpIZ0mKR627606PM+uomqQR/kbsEMl/oXCvdGuDegr/hP27EJenovjZX725DGv BaiUdF4ZZ2f6xnImUS2nz/zM6juKKBkeEJeKQYmaA+G+RR3MjM/i4RoWCygsSOik3pon BSIciQn6WU3ewNxx3YT87AJEV1ySanetPEhFEtBeS5CAqjEoyEcbmkGK9H71pskC8UbU HLIqRdVjBzSARC+RsGVIil5NWGF33ID558osoAwdudTuQJnTPGoP/F/m+xAEt+pugEAk MwFA== X-Gm-Message-State: AD7BkJJWJ1b1GIiV9JCHibpsKu/888RVP8xzrXDCeXWUG+1NCQG/aBJKx3ocid9pD5ylSg== X-Received: by 10.50.64.178 with SMTP id p18mr80195igs.55.1456522708473; Fri, 26 Feb 2016 13:38:28 -0800 (PST) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com. [209.85.223.181]) by smtp.gmail.com with ESMTPSA id h131sm6128875ioe.7.2016.02.26.13.38.26 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 13:38:26 -0800 (PST) Received: by mail-io0-f181.google.com with SMTP id l127so135226158iof.3 for ; Fri, 26 Feb 2016 13:38:26 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.12.226 with SMTP id 95mr10732173iom.70.1456522706365; Fri, 26 Feb 2016 13:38:26 -0800 (PST) Received: by 10.36.105.77 with HTTP; Fri, 26 Feb 2016 13:38:26 -0800 (PST) In-Reply-To: <56D0097D.40308@mozilla.com> References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D0097D.40308@mozilla.com> Date: Fri, 26 Feb 2016 16:38:26 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=001a113f8f8e8536e1052cb31e90 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:38:30 -0000 --001a113f8f8e8536e1052cb31e90 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 26, 2016 at 3:14 AM, Jean-Marc Valin wrote: > Just as a clarification, are we talking about the duration of RFC4733 > tone events or the duration of audio tones (or both)? I agree that > going below 40 ms is just not possible. As for the upper bound, more > than 6000 ms is definitely insane, but I have no precise opinion on > the exact threshold that should be used, or why anyone would want such > long tones in the first place. > 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. _____________ Roman Shpount --001a113f8f8e8536e1052cb31e90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 26, 2016 at 3:14 AM, Jean-Marc Valin <= ;jmvalin@mozilla.c= om> wrote:
Just as a clarification, are we talking about the duration of RFC4= 733
tone events or the duration of audio tones (or both)? I agree that
going below 40 ms is just not possible. As for the upper bound, more
than 6000 ms is definitely insane, but I have no precise opinion on
the exact threshold that should be used, or why anyone would want such
long tones in the first place.

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 overflow= s when 8 KHz clock is used.
______= _______
Roman Shpount
=C2=A0
--001a113f8f8e8536e1052cb31e90-- From nobody Fri Feb 26 13:56:32 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C26A1B3124 for ; Fri, 26 Feb 2016 13:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qk7QCrAlc03 for ; Fri, 26 Feb 2016 13:56:28 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7DBA1B311F for ; Fri, 26 Feb 2016 13:56:27 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id 9so131271457iom.1 for ; Fri, 26 Feb 2016 13:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=6N1PVQvPwNdNq4vVOqxlsaP6Oyse0Rd3cZz44Pxalhg=; b=BUyzaFYSLQBP3QDmtt5JxYRmb9no83NpfbIsIzcYHUgdFCSLrtzq6PwXRWLaZyXJqU sOXnKoYqUKFN3R0apCDFEdD+xK50KB6cWwinoF8+dhMH0O7KHRRLU5IdcMsbp1JsFRJ4 M9td9fpKiPbsCrpj+BGQuiCGtbVo6Xnb8fmwSTM1/MudSxAtzEE4HN3iNMRJIHxkm+oc Lg5nEHIprlpeHLjvQR8IDB1wdCl+IAI7fESsKghMuGAMavKZty6DBMlj0yTbvAY1x79q wdft0Q9ahvUPMxZPURAp1lmW+qKnIXvsihD1PlCBAw3oACEuanDpaj7t6U8feHpgIQ6V Uf7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=6N1PVQvPwNdNq4vVOqxlsaP6Oyse0Rd3cZz44Pxalhg=; b=iJOzeyUC790xYCYgGflgKtw25X+msy/og9eNIKbsUfqqY5B5KQVnvYW8/DeJ9sfwXa hTYWjW4JRkLNgGKOoxusVRrbHcQZ+h2KxmLA8d6SrzfhSnRivBGIero19h9avnMIRfX3 lP1ibiaYFwO9XlP7LwNAF6RAnO3g2D5R1aqnTxw2foana7FhP1kQjQYAImeOljtJIAti xr/Y+I9SstB2WeGVZ0IBGzZ1/YovwjedxFF89WrUkK4YD+mCpfsWAPI4Zk9T3ZU1TKl6 h/NEJXjEPE3ZjTtARdnbTH5VaqHE1Kim/dI7jr6LjHcIxlaHuzBivsKNBhLPmg6E5jPJ +bAg== X-Gm-Message-State: AG10YOT7xpdcC6ilwtpYkfxzsY8/aYJ7MC5pLw0N7Ld+HDYds5bMFPvhH8uPwMN/38ocZg== X-Received: by 10.107.167.80 with SMTP id q77mr11899861ioe.110.1456523787252; Fri, 26 Feb 2016 13:56:27 -0800 (PST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com. [209.85.213.173]) by smtp.gmail.com with ESMTPSA id o201sm6098945ioe.15.2016.02.26.13.56.26 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 13:56:26 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id y8so44654713igp.1 for ; Fri, 26 Feb 2016 13:56:26 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.28.48 with SMTP id y16mr206493igg.2.1456523785746; Fri, 26 Feb 2016 13:56:25 -0800 (PST) Received: by 10.36.105.77 with HTTP; Fri, 26 Feb 2016 13:56:25 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> Date: Fri, 26 Feb 2016 16:56:25 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=089e0158b360db4afe052cb35e3b Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:56:29 -0000 --089e0158b360db4afe052cb35e3b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 26, 2016 at 6:19 AM, Asveren, Tolga wrote: > i- I think w3org should have followed the lead of IETF in this issue > rather than the other way around, i.e. the values recommended by the IETF > specification should have been cited in the w3org document IMHO. > I agree completely. I am not aware of any IETF document that defines DTMF or RFC 4733 tone duration limits, so I proposed to add these limits to draft-ietf-rtcweb-audio. Most importantly I wanted the text from W3C reviewed in IETF since it was clearly a network related. Furthermore, anybody implementing WebRTC compatible RTP audio interface should not need to read the API document to find the network specific limits. ii- The reasonable value range could depend on the negotiated codec and > that would be known at the time of interesting the digits; so anything wi= th > MUST strength is too restrictive IMHO. > We know that RFC 4733 would be used to transmit DTMF tones from WebRTC endpoints. RFC 4733 has no upper or lower limits on tone duration, so technically these can be set to anything or not set at all. Some people argue that we should limit number of foot guns for future API users, so they wanted to have reasonable tone duration limits. iii- The presence of transcoding/interworking (between different forms of > digit transfer) devices (they will be there, whether we like it or not, f= or > certain scenarios) makes it even less desirable to have MUST strength > mandates. > Unfortunately I spend a significant amount of my time dealing with transcoding elements (SBCs) dealing with RFC 4733 tones. Sending tones which are too short or sent at high rates make such transcoding elements generate unexpected or broken DTMF sequences. Reordered or interleaved tones are commonly generated in response to such sequences. Extremely long duration DTMF digits typically break into several digits. There is danger in not having reasonable limits. The decision if API users should be protected from this danger is up to this group. iv- I think adding some text regarding gap/duration of digit packets could > be fine but I rather would prefer it with =E2=80=9Crecommend=E2=80=9D (ev= en not RECOMMEND) > (and providing some values only as examples). > I agree that having reasonable recommended values should be sufficient for most cases. The group has to decide if it wants to protect the developers from themselves and set MUST level limits on tone and gap duration. _____________ Roman Shpount --089e0158b360db4afe052cb35e3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 26, 2016 at 6:19 AM, Asveren, Tolga <= tasveren@sonusne= t.com> wrote:

i- I think w3org should have followed the le= ad of IETF in this issue rather than the other way around, i.e. the values = recommended by the IETF specification should have been cited in the w3org document IMHO.


I agree completely. I am not aware of any IETF doc= ument that defines DTMF or RFC 4733 tone duration=C2=A0limits, so I propose= d to add these limits to draft-ietf-rtcweb-audio. Most importantly I wanted= the text from W3C reviewed in IETF since it was clearly a network related.= Furthermore, anybody implementing WebRTC compatible RTP audio interface sh= ould not need to read the API document to find the network specific limits.=

ii- The reasonable value range could depend = on the negotiated codec and that would be known at the time of interesting = the digits; so anything with MUST strength is too restrictive IMHO.

=C2=A0
We know that RFC 4733 would be used to transmit DTMF tones from WebRTC en= dpoints. RFC 4733 has no upper or lower limits on tone duration, so technic= ally these can be set to anything or not set at all. Some people argue that= we should limit number of foot guns for future API users, so they wanted t= o have reasonable tone duration limits.

iii- The presence of transcoding/interworking (b= etween different forms of digit transfer) devices (they will be there, whet= her we like it or not, for certain scenarios) makes it even less desirable to have MUST strength mandates.

=C2=A0
Unfortunately I spend a si= gnificant amount of my time dealing with transcoding elements (SBCs) dealin= g with RFC 4733 tones. Sending tones which are too short or sent at high ra= tes make such transcoding elements generate unexpected or broken DTMF seque= nces. Reordered or interleaved tones are commonly generated in response to = such sequences. Extremely long duration DTMF digits typically break into se= veral digits. There is danger in not having reasonable limits. The decision= if API users should be protected from this danger is up to this group.

iv- I think addi= ng some text regarding gap/duration of digit packets could be fine but I ra= ther would prefer it with =E2=80=9Crecommend=E2=80=9D (even not RECOMMEND) = (and providing some values only as examples).

=C2= =A0
I agree that having reasonable recommended values should be s= ufficient for most cases. The group has to decide if it wants to protect th= e developers from themselves and set MUST level limits on tone and gap dura= tion.
_____________
Roman Shpou= nt
=C2=A0
--089e0158b360db4afe052cb35e3b-- From nobody Sat Feb 27 02:45:55 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB241A8A51 for ; Sat, 27 Feb 2016 02:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSLGDDe3Gls3 for ; Sat, 27 Feb 2016 02:45:50 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0056.outbound.protection.outlook.com [207.46.100.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BFED1A8A64 for ; Sat, 27 Feb 2016 02:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=amL+9YbCLHRTbWIgnQs3cH6PFoJZy3md1vwRPtnH168=; b=gPvY33CoPXrxAmnyxuhiSpeub5HjCWjSrdXQBcdRQyKZn+1XOBp9mXNCtktsd/LGB8Z6HZk6lucrsHa78gCi50fNSvOh8haHfjpQiEawvR6G96wqzwfcHb3RSPxj8j309PK6GnqpMT90+kzLUMTGbXimNDfhlgKcpELle8WlUaA= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1550.namprd03.prod.outlook.com (10.162.129.156) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 27 Feb 2016 10:45:47 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Sat, 27 Feb 2016 10:45:47 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p89KcurgAAU0gCAALLLgIAAOucggAC01ICAANVAYA== Date: Sat, 27 Feb 2016 10:45:46 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 313302d3-7a8f-444b-da64-08d33f632697 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1550; 5:0bZb8qzrtfGcbL4e9cm48QKyf/3HITfyIyK5omf5zQvtJwiJmNlC4SELioqq4bqzhGZUWiK930qwUpl8g3VgrxFCd0VR9AObY33i89RhQeu/190b1LGp1EB1moOo6ofdptk8upjZOn5VvOcTt80cfA==; 24:7SmGIV1XN9FAn1Xt5DlvxePvvQQEi871Sgr+dpk1zUcACQjWTsIb37S8Vsb+EJef37j8uP5euRJRGgi6InQxWCzzr5KSpo9pQ6TRFBIJ7KI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1550; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR0301MB1550; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1550; x-forefront-prvs: 086597191B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(164054003)(2473001)(24454002)(377454003)(87936001)(3846002)(102836003)(1096002)(11100500001)(110136002)(54356999)(189998001)(50986999)(76176999)(106116001)(19300405004)(93886004)(76576001)(586003)(5001960100002)(66066001)(5002640100001)(1220700001)(86362001)(230783001)(16236675004)(19625215002)(2950100001)(5004730100002)(2906002)(790700001)(74316001)(3660700001)(2900100001)(6116002)(3280700002)(15975445007)(19609705001)(92566002)(10400500002)(99286002)(4326007)(33656002)(122556002)(5008740100001)(5003600100002)(19580405001)(77096005)(19580395003)(40100003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1550; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB15519E82B0384EF6EC348B72B2B80SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2016 10:45:46.8826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1550 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2016 10:45:53 -0000 --_000_SN1PR0301MB15519E82B0384EF6EC348B72B2B80SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgSSBkb27igJl0IG1pcy9vdmVyLWludGVycHJldCBSb21hbuKAmXMgYW5zd2VyLCBpdCBzZWVt cyBsaWtlIGF0IGxlYXN0IHNvbWUgcGVvcGxlIHdobyByZWFsbHkgY2FyZS9oYXZlIHByYWN0aWNh bCBleHBlcmllbmNlIGFib3V0IHRoaXMgaXNzdWUsIGUuZy4gUm9tYW4gYW5kIG15c2VsZiwgYXJl IGluIGZhdm9yIG9mIG5vdCBtYW5kYXRpbmcgYW55IHZhbHVlcyBhbmQgc3VnZ2VzdGluZyB0aGF0 IHczb3JnIHNwZWNpZmljYXRpb24gaXMgdXBkYXRlZCBhY2NvcmRpbmdseS4gSSBwZXJzb25hbGx5 IHdvdWxkIHByZWZlciBub3RoaW5nIG1vcmUgdGhhbiBhIChvciB0d28pIHNlbnRlbmNlIGFzIGEg d2FybmluZyB3aXRob3V0IHVzaW5nIGFueSBrZXl3b3JkcyBpbiBydGN3ZWItYXVkaW8uIERvZXMg dGhpcyBzb3VuZCBhIHJlYXNvbmFibGUgY2hvaWNlIHRvIG90aGVyIGZvbGtzPw0KDQpUaGFua3Ms DQpUb2xnYQ0KDQpGcm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21d DQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDI2LCAyMDE2IDQ6NTYgUE0NClRvOiBBc3ZlcmVuLCBU b2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPg0KQ2M6IEhhcmFsZCBBbHZlc3RyYW5kIDxoYXJh bGRAYWx2ZXN0cmFuZC5ubz47IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJd IEZ3ZDogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1ydGN3ZWItYXVkaW8tMTAudHh0PiAoV2ViUlRD IEF1ZGlvIENvZGVjIGFuZCBQcm9jZXNzaW5nIFJlcXVpcmVtZW50cykgdG8gUHJvcG9zZWQgU3Rh bmRhcmQNCg0KT24gRnJpLCBGZWIgMjYsIDIwMTYgYXQgNjoxOSBBTSwgQXN2ZXJlbiwgVG9sZ2Eg PHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tPj4gd3Jv dGU6DQppLSBJIHRoaW5rIHczb3JnIHNob3VsZCBoYXZlIGZvbGxvd2VkIHRoZSBsZWFkIG9mIElF VEYgaW4gdGhpcyBpc3N1ZSByYXRoZXIgdGhhbiB0aGUgb3RoZXIgd2F5IGFyb3VuZCwgaS5lLiB0 aGUgdmFsdWVzIHJlY29tbWVuZGVkIGJ5IHRoZSBJRVRGIHNwZWNpZmljYXRpb24gc2hvdWxkIGhh dmUgYmVlbiBjaXRlZCBpbiB0aGUgdzNvcmcgZG9jdW1lbnQgSU1ITy4NCg0KSSBhZ3JlZSBjb21w bGV0ZWx5LiBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSUVURiBkb2N1bWVudCB0aGF0IGRlZmluZXMg RFRNRiBvciBSRkMgNDczMyB0b25lIGR1cmF0aW9uIGxpbWl0cywgc28gSSBwcm9wb3NlZCB0byBh ZGQgdGhlc2UgbGltaXRzIHRvIGRyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLiBNb3N0IGltcG9ydGFu dGx5IEkgd2FudGVkIHRoZSB0ZXh0IGZyb20gVzNDIHJldmlld2VkIGluIElFVEYgc2luY2UgaXQg d2FzIGNsZWFybHkgYSBuZXR3b3JrIHJlbGF0ZWQuIEZ1cnRoZXJtb3JlLCBhbnlib2R5IGltcGxl bWVudGluZyBXZWJSVEMgY29tcGF0aWJsZSBSVFAgYXVkaW8gaW50ZXJmYWNlIHNob3VsZCBub3Qg bmVlZCB0byByZWFkIHRoZSBBUEkgZG9jdW1lbnQgdG8gZmluZCB0aGUgbmV0d29yayBzcGVjaWZp YyBsaW1pdHMuDQoNCmlpLSBUaGUgcmVhc29uYWJsZSB2YWx1ZSByYW5nZSBjb3VsZCBkZXBlbmQg b24gdGhlIG5lZ290aWF0ZWQgY29kZWMgYW5kIHRoYXQgd291bGQgYmUga25vd24gYXQgdGhlIHRp bWUgb2YgaW50ZXJlc3RpbmcgdGhlIGRpZ2l0czsgc28gYW55dGhpbmcgd2l0aCBNVVNUIHN0cmVu Z3RoIGlzIHRvbyByZXN0cmljdGl2ZSBJTUhPLg0KDQpXZSBrbm93IHRoYXQgUkZDIDQ3MzMgd291 bGQgYmUgdXNlZCB0byB0cmFuc21pdCBEVE1GIHRvbmVzIGZyb20gV2ViUlRDIGVuZHBvaW50cy4g UkZDIDQ3MzMgaGFzIG5vIHVwcGVyIG9yIGxvd2VyIGxpbWl0cyBvbiB0b25lIGR1cmF0aW9uLCBz byB0ZWNobmljYWxseSB0aGVzZSBjYW4gYmUgc2V0IHRvIGFueXRoaW5nIG9yIG5vdCBzZXQgYXQg YWxsLiBTb21lIHBlb3BsZSBhcmd1ZSB0aGF0IHdlIHNob3VsZCBsaW1pdCBudW1iZXIgb2YgZm9v dCBndW5zIGZvciBmdXR1cmUgQVBJIHVzZXJzLCBzbyB0aGV5IHdhbnRlZCB0byBoYXZlIHJlYXNv bmFibGUgdG9uZSBkdXJhdGlvbiBsaW1pdHMuDQoNCmlpaS0gVGhlIHByZXNlbmNlIG9mIHRyYW5z Y29kaW5nL2ludGVyd29ya2luZyAoYmV0d2VlbiBkaWZmZXJlbnQgZm9ybXMgb2YgZGlnaXQgdHJh bnNmZXIpIGRldmljZXMgKHRoZXkgd2lsbCBiZSB0aGVyZSwgd2hldGhlciB3ZSBsaWtlIGl0IG9y IG5vdCwgZm9yIGNlcnRhaW4gc2NlbmFyaW9zKSBtYWtlcyBpdCBldmVuIGxlc3MgZGVzaXJhYmxl IHRvIGhhdmUgTVVTVCBzdHJlbmd0aCBtYW5kYXRlcy4NCg0KVW5mb3J0dW5hdGVseSBJIHNwZW5k IGEgc2lnbmlmaWNhbnQgYW1vdW50IG9mIG15IHRpbWUgZGVhbGluZyB3aXRoIHRyYW5zY29kaW5n IGVsZW1lbnRzIChTQkNzKSBkZWFsaW5nIHdpdGggUkZDIDQ3MzMgdG9uZXMuIFNlbmRpbmcgdG9u ZXMgd2hpY2ggYXJlIHRvbyBzaG9ydCBvciBzZW50IGF0IGhpZ2ggcmF0ZXMgbWFrZSBzdWNoIHRy YW5zY29kaW5nIGVsZW1lbnRzIGdlbmVyYXRlIHVuZXhwZWN0ZWQgb3IgYnJva2VuIERUTUYgc2Vx dWVuY2VzLiBSZW9yZGVyZWQgb3IgaW50ZXJsZWF2ZWQgdG9uZXMgYXJlIGNvbW1vbmx5IGdlbmVy YXRlZCBpbiByZXNwb25zZSB0byBzdWNoIHNlcXVlbmNlcy4gRXh0cmVtZWx5IGxvbmcgZHVyYXRp b24gRFRNRiBkaWdpdHMgdHlwaWNhbGx5IGJyZWFrIGludG8gc2V2ZXJhbCBkaWdpdHMuIFRoZXJl IGlzIGRhbmdlciBpbiBub3QgaGF2aW5nIHJlYXNvbmFibGUgbGltaXRzLiBUaGUgZGVjaXNpb24g aWYgQVBJIHVzZXJzIHNob3VsZCBiZSBwcm90ZWN0ZWQgZnJvbSB0aGlzIGRhbmdlciBpcyB1cCB0 byB0aGlzIGdyb3VwLg0KDQppdi0gSSB0aGluayBhZGRpbmcgc29tZSB0ZXh0IHJlZ2FyZGluZyBn YXAvZHVyYXRpb24gb2YgZGlnaXQgcGFja2V0cyBjb3VsZCBiZSBmaW5lIGJ1dCBJIHJhdGhlciB3 b3VsZCBwcmVmZXIgaXQgd2l0aCDigJxyZWNvbW1lbmTigJ0gKGV2ZW4gbm90IFJFQ09NTUVORCkg KGFuZCBwcm92aWRpbmcgc29tZSB2YWx1ZXMgb25seSBhcyBleGFtcGxlcykuDQoNCkkgYWdyZWUg dGhhdCBoYXZpbmcgcmVhc29uYWJsZSByZWNvbW1lbmRlZCB2YWx1ZXMgc2hvdWxkIGJlIHN1ZmZp Y2llbnQgZm9yIG1vc3QgY2FzZXMuIFRoZSBncm91cCBoYXMgdG8gZGVjaWRlIGlmIGl0IHdhbnRz IHRvIHByb3RlY3QgdGhlIGRldmVsb3BlcnMgZnJvbSB0aGVtc2VsdmVzIGFuZCBzZXQgTVVTVCBs ZXZlbCBsaW1pdHMgb24gdG9uZSBhbmQgZ2FwIGR1cmF0aW9uLg0KX19fX19fX19fX19fXw0KUm9t YW4gU2hwb3VudA0KDQo= --_000_SN1PR0301MB15519E82B0384EF6EC348B72B2B80SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIEkgZG9u4oCZdCBtaXMvb3Zlci1pbnRl cnByZXQgUm9tYW7igJlzIGFuc3dlciwgaXQgc2VlbXMgbGlrZSBhdCBsZWFzdCBzb21lIHBlb3Bs ZSB3aG8gcmVhbGx5IGNhcmUvaGF2ZSBwcmFjdGljYWwgZXhwZXJpZW5jZSBhYm91dCB0aGlzIGlz c3VlLCBlLmcuIFJvbWFuIGFuZCBteXNlbGYsDQogYXJlIGluIGZhdm9yIG9mIG5vdCBtYW5kYXRp bmcgYW55IHZhbHVlcyBhbmQgc3VnZ2VzdGluZyB0aGF0IHczb3JnIHNwZWNpZmljYXRpb24gaXMg dXBkYXRlZCBhY2NvcmRpbmdseS4gSSBwZXJzb25hbGx5IHdvdWxkIHByZWZlciBub3RoaW5nIG1v cmUgdGhhbiBhIChvciB0d28pIHNlbnRlbmNlIGFzIGEgd2FybmluZyB3aXRob3V0IHVzaW5nIGFu eSBrZXl3b3JkcyBpbiBydGN3ZWItYXVkaW8uIERvZXMgdGhpcyBzb3VuZCBhIHJlYXNvbmFibGUg Y2hvaWNlDQogdG8gb3RoZXIgZm9sa3M/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRvbGdhPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9t YW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IEZyaWRheSwgRmVicnVhcnkgMjYsIDIwMTYgNDo1NiBQTTxicj4NCjxiPlRvOjwvYj4gQXN2ZXJl biwgVG9sZ2EgJmx0O3Rhc3ZlcmVuQHNvbnVzbmV0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEhh cmFsZCBBbHZlc3RyYW5kICZsdDtoYXJhbGRAYWx2ZXN0cmFuZC5ubyZndDs7IHJ0Y3dlYkBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gRndkOiBMYXN0IENhbGw6ICZs dDtkcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpby0xMC50eHQmZ3Q7IChXZWJSVEMgQXVkaW8gQ29kZWMg YW5kIFByb2Nlc3NpbmcgUmVxdWlyZW1lbnRzKSB0byBQcm9wb3NlZCBTdGFuZGFyZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBGcmksIEZlYiAyNiwgMjAxNiBhdCA2OjE5IEFNLCBBc3ZlcmVuLCBUb2xn YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5pLSBJIHRoaW5r IHczb3JnIHNob3VsZCBoYXZlIGZvbGxvd2VkIHRoZSBsZWFkIG9mIElFVEYgaW4gdGhpcyBpc3N1 ZSByYXRoZXIgdGhhbiB0aGUgb3RoZXIgd2F5IGFyb3VuZCwNCiBpLmUuIHRoZSB2YWx1ZXMgcmVj b21tZW5kZWQgYnkgdGhlIElFVEYgc3BlY2lmaWNhdGlvbiBzaG91bGQgaGF2ZSBiZWVuIGNpdGVk IGluIHRoZSB3M29yZyBkb2N1bWVudCBJTUhPLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGFncmVlIGNvbXBsZXRlbHkuIEkgYW0gbm90IGF3YXJlIG9mIGFueSBJRVRGIGRvY3VtZW50IHRo YXQgZGVmaW5lcyBEVE1GIG9yIFJGQyA0NzMzIHRvbmUgZHVyYXRpb24mbmJzcDtsaW1pdHMsIHNv IEkgcHJvcG9zZWQgdG8gYWRkIHRoZXNlIGxpbWl0cyB0byBkcmFmdC1pZXRmLXJ0Y3dlYi1hdWRp by4gTW9zdCBpbXBvcnRhbnRseSBJIHdhbnRlZCB0aGUgdGV4dCBmcm9tIFczQyByZXZpZXdlZCBp biBJRVRGIHNpbmNlDQogaXQgd2FzIGNsZWFybHkgYSBuZXR3b3JrIHJlbGF0ZWQuIEZ1cnRoZXJt b3JlLCBhbnlib2R5IGltcGxlbWVudGluZyBXZWJSVEMgY29tcGF0aWJsZSBSVFAgYXVkaW8gaW50 ZXJmYWNlIHNob3VsZCBub3QgbmVlZCB0byByZWFkIHRoZSBBUEkgZG9jdW1lbnQgdG8gZmluZCB0 aGUgbmV0d29yayBzcGVjaWZpYyBsaW1pdHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5paS0gVGhlIHJlYXNvbmFibGUgdmFsdWUgcmFuZ2UgY291bGQgZGVwZW5k IG9uIHRoZSBuZWdvdGlhdGVkIGNvZGVjIGFuZCB0aGF0IHdvdWxkIGJlIGtub3duIGF0IHRoZQ0K IHRpbWUgb2YgaW50ZXJlc3RpbmcgdGhlIGRpZ2l0czsgc28gYW55dGhpbmcgd2l0aCBNVVNUIHN0 cmVuZ3RoIGlzIHRvbyByZXN0cmljdGl2ZSBJTUhPLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Uga25v dyB0aGF0IFJGQyA0NzMzIHdvdWxkIGJlIHVzZWQgdG8gdHJhbnNtaXQgRFRNRiB0b25lcyBmcm9t IFdlYlJUQyBlbmRwb2ludHMuIFJGQyA0NzMzIGhhcyBubyB1cHBlciBvciBsb3dlciBsaW1pdHMg b24gdG9uZSBkdXJhdGlvbiwgc28gdGVjaG5pY2FsbHkgdGhlc2UgY2FuIGJlIHNldCB0byBhbnl0 aGluZyBvciBub3Qgc2V0IGF0IGFsbC4gU29tZSBwZW9wbGUgYXJndWUgdGhhdCB3ZSBzaG91bGQg bGltaXQNCiBudW1iZXIgb2YgZm9vdCBndW5zIGZvciBmdXR1cmUgQVBJIHVzZXJzLCBzbyB0aGV5 IHdhbnRlZCB0byBoYXZlIHJlYXNvbmFibGUgdG9uZSBkdXJhdGlvbiBsaW1pdHMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5paWktIFRoZSBwcmVzZW5jZSBvZiB0 cmFuc2NvZGluZy9pbnRlcndvcmtpbmcgKGJldHdlZW4gZGlmZmVyZW50IGZvcm1zIG9mIGRpZ2l0 IHRyYW5zZmVyKSBkZXZpY2VzICh0aGV5DQogd2lsbCBiZSB0aGVyZSwgd2hldGhlciB3ZSBsaWtl IGl0IG9yIG5vdCwgZm9yIGNlcnRhaW4gc2NlbmFyaW9zKSBtYWtlcyBpdCBldmVuIGxlc3MgZGVz aXJhYmxlIHRvIGhhdmUgTVVTVCBzdHJlbmd0aCBtYW5kYXRlcy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlVuZm9ydHVuYXRlbHkgSSBzcGVuZCBhIHNpZ25pZmljYW50IGFtb3VudCBvZiBteSB0aW1lIGRl YWxpbmcgd2l0aCB0cmFuc2NvZGluZyBlbGVtZW50cyAoU0JDcykgZGVhbGluZyB3aXRoIFJGQyA0 NzMzIHRvbmVzLiBTZW5kaW5nIHRvbmVzIHdoaWNoIGFyZSB0b28gc2hvcnQgb3Igc2VudCBhdCBo aWdoIHJhdGVzIG1ha2Ugc3VjaCB0cmFuc2NvZGluZyBlbGVtZW50cyBnZW5lcmF0ZSB1bmV4cGVj dGVkIG9yIGJyb2tlbg0KIERUTUYgc2VxdWVuY2VzLiBSZW9yZGVyZWQgb3IgaW50ZXJsZWF2ZWQg dG9uZXMgYXJlIGNvbW1vbmx5IGdlbmVyYXRlZCBpbiByZXNwb25zZSB0byBzdWNoIHNlcXVlbmNl cy4gRXh0cmVtZWx5IGxvbmcgZHVyYXRpb24gRFRNRiBkaWdpdHMgdHlwaWNhbGx5IGJyZWFrIGlu dG8gc2V2ZXJhbCBkaWdpdHMuIFRoZXJlIGlzIGRhbmdlciBpbiBub3QgaGF2aW5nIHJlYXNvbmFi bGUgbGltaXRzLiBUaGUgZGVjaXNpb24gaWYgQVBJIHVzZXJzIHNob3VsZA0KIGJlIHByb3RlY3Rl ZCBmcm9tIHRoaXMgZGFuZ2VyIGlzIHVwIHRvIHRoaXMgZ3JvdXAuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5pdi0gSSB0aGluayBhZGRpbmcgc29tZSB0ZXh0IHJl Z2FyZGluZyBnYXAvZHVyYXRpb24gb2YgZGlnaXQgcGFja2V0cyBjb3VsZCBiZSBmaW5lIGJ1dCBJ IHJhdGhlciB3b3VsZA0KIHByZWZlciBpdCB3aXRoIOKAnHJlY29tbWVuZOKAnSAoZXZlbiBub3Qg UkVDT01NRU5EKSAoYW5kIHByb3ZpZGluZyBzb21lIHZhbHVlcyBvbmx5IGFzIGV4YW1wbGVzKS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgdGhhdCBoYXZpbmcgcmVhc29uYWJsZSByZWNvbW1l bmRlZCB2YWx1ZXMgc2hvdWxkIGJlIHN1ZmZpY2llbnQgZm9yIG1vc3QgY2FzZXMuIFRoZSBncm91 cCBoYXMgdG8gZGVjaWRlIGlmIGl0IHdhbnRzIHRvIHByb3RlY3QgdGhlIGRldmVsb3BlcnMgZnJv bSB0aGVtc2VsdmVzIGFuZCBzZXQgTVVTVCBsZXZlbCBsaW1pdHMgb24gdG9uZSBhbmQgZ2FwIGR1 cmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR0301MB15519E82B0384EF6EC348B72B2B80SN1PR0301MB1551_-- From nobody Sat Feb 27 05:11:37 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35F81AC416 for ; Sat, 27 Feb 2016 05:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-IHKQv7geqp for ; Sat, 27 Feb 2016 05:11:33 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB051A1B69 for ; Sat, 27 Feb 2016 05:11:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 080477C675E; Sat, 27 Feb 2016 14:11:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6Z1jiyByF5a; Sat, 27 Feb 2016 14:11:29 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:9c91:e863:f283:7d70] (unknown [IPv6:2001:470:de0a:1:9c91:e863:f283:7d70]) by mork.alvestrand.no (Postfix) with ESMTPSA id A664D7C6750; Sat, 27 Feb 2016 14:11:29 +0100 (CET) To: "Asveren, Tolga" , Roman Shpount References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> From: Harald Alvestrand Message-ID: <56D1A080.7050901@alvestrand.no> Date: Sat, 27 Feb 2016 14:11:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2016 13:11:36 -0000 Den 27. feb. 2016 11:45, skrev Asveren, Tolga: > If I don’t mis/over-interpret Roman’s answer, it seems like at least > some people who really care/have practical experience about this issue, > e.g. Roman and myself, are in favor of not mandating any values and > suggesting that w3org specification is updated accordingly. I personally > would prefer nothing more than a (or two) sentence as a warning without > using any keywords in rtcweb-audio. Does this sound a reasonable choice > to other folks? At the WEBRTC API, this *will* lead to noninteroperable implementations, since some browsers will enforce different limits from other browsers. It's all coming back now - we decided to go with fixed limits in the spec because it was inconcievable that implementations wouldn't impose *some* limits, and the idea of adding API surface for probing what the limits were was just too gross for such a low-value (relatively speaking) feature. > > > > Thanks, > > Tolga > > > > *From:*Roman Shpount [mailto:roman@telurix.com] > *Sent:* Friday, February 26, 2016 4:56 PM > *To:* Asveren, Tolga > *Cc:* Harald Alvestrand ; rtcweb@ietf.org > *Subject:* Re: [rtcweb] Fwd: Last Call: > (WebRTC Audio Codec and Processing Requirements) to Proposed Standard > > > > On Fri, Feb 26, 2016 at 6:19 AM, Asveren, Tolga > wrote: > > i- I think w3org should have followed the lead of IETF in this issue > rather than the other way around, i.e. the values recommended by the > IETF specification should have been cited in the w3org document IMHO. > > > > I agree completely. I am not aware of any IETF document that defines > DTMF or RFC 4733 tone duration limits, so I proposed to add these limits > to draft-ietf-rtcweb-audio. Most importantly I wanted the text from W3C > reviewed in IETF since it was clearly a network related. Furthermore, > anybody implementing WebRTC compatible RTP audio interface should not > need to read the API document to find the network specific limits. > > > > ii- The reasonable value range could depend on the negotiated codec > and that would be known at the time of interesting the digits; so > anything with MUST strength is too restrictive IMHO. > > > > We know that RFC 4733 would be used to transmit DTMF tones from WebRTC > endpoints. RFC 4733 has no upper or lower limits on tone duration, so > technically these can be set to anything or not set at all. Some people > argue that we should limit number of foot guns for future API users, so > they wanted to have reasonable tone duration limits. > > > > iii- The presence of transcoding/interworking (between different > forms of digit transfer) devices (they will be there, whether we > like it or not, for certain scenarios) makes it even less desirable > to have MUST strength mandates. > > > > Unfortunately I spend a significant amount of my time dealing with > transcoding elements (SBCs) dealing with RFC 4733 tones. Sending tones > which are too short or sent at high rates make such transcoding elements > generate unexpected or broken DTMF sequences. Reordered or interleaved > tones are commonly generated in response to such sequences. Extremely > long duration DTMF digits typically break into several digits. There is > danger in not having reasonable limits. The decision if API users should > be protected from this danger is up to this group. > > > > iv- I think adding some text regarding gap/duration of digit packets > could be fine but I rather would prefer it with “recommend” (even > not RECOMMEND) (and providing some values only as examples). > > > > I agree that having reasonable recommended values should be sufficient > for most cases. The group has to decide if it wants to protect the > developers from themselves and set MUST level limits on tone and gap > duration. > > _____________ > Roman Shpount > > > From nobody Sat Feb 27 08:32:50 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829351A8A96 for ; Sat, 27 Feb 2016 08:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWKUamGX3Rpg for ; Sat, 27 Feb 2016 08:32:44 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0099.outbound.protection.outlook.com [207.46.100.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E56D1A8A8C for ; Sat, 27 Feb 2016 08:32:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qOfp4yhE7+cjNSqhbPoXYEZnpplCyvJtaMJLK6VdqEw=; b=aUvE/FHdO2PXrgncueEra+tMZsvjguuVMmIomqHs9zZh8nzZgrfMAYsXdioJgfP16ssEmd8CKllR+5wslm3TtOyUFCoZhA5Fz7wgUunBgoRMg7tqNy1x3xDOb/7pXeSxRNhtELv0pG2gYnFP6RVbhX/GwHJrgCDVXkcrQ/iL4w4= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 27 Feb 2016 16:32:42 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Sat, 27 Feb 2016 16:32:42 +0000 From: "Asveren, Tolga" To: Harald Alvestrand , Roman Shpount Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p89KcurgAAU0gCAALLLgIAAOucggAC01ICAANVAYIAAKmkAgAA3mfA= Date: Sat, 27 Feb 2016 16:32:42 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> <56D1A080.7050901@alvestrand.no> In-Reply-To: <56D1A080.7050901@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alvestrand.no; dkim=none (message not signed) header.d=none; alvestrand.no; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: c97c9be0-3fed-4118-a57f-08d33f939d6c x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:HsK8h8wVUJE5vm/C+FUvZS0HhphGC7QtCxUhPA94KP/+q55BKxBOAw/bMsohKq4634ed+EXgAfVDE/kMW+ob40rFURgjda0yKMkBS/SdS/qqh6xmR7DLlntaDgUiBHRJCl14FG3VuLJ/ZVoPLeYpug==; 24:qobuus/U93WudImLpz/XkGGvF1SGpSpLw7cRNNZZrpUfaKx1c5yYO3l73aKV0oa1g7z7uI2u3jHnWPdIH1UTLZs7RrcjUcTs0nV7o3BB16g= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 086597191B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(164054003)(2473001)(24454002)(377454003)(77096005)(2900100001)(19580395003)(19580405001)(2950100001)(1220700001)(5001960100002)(189998001)(106116001)(40100003)(76176999)(10400500002)(5001770100001)(11100500001)(50986999)(92566002)(54356999)(33656002)(87936001)(4326007)(3846002)(6116002)(102836003)(586003)(5003600100002)(2906002)(3660700001)(99286002)(5002640100001)(5004730100002)(1096002)(74316001)(122556002)(76576001)(5008740100001)(93886004)(66066001)(3280700002)(86362001)(230783001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2016 16:32:42.1382 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2016 16:32:48 -0000 SSBkb27igJl0IHRoaW5rIGJyb3dzZXJzIHNob3VsZCBiZSBlbmZvcmNpbmcgKmFueSogbGltaXRh dGlvbnMuIEl0IHNob3VsZCBiZSB1cCB0byB0aGUgYXBwbGljYXRpb24gZGV2ZWxvcGVyIHRvIGRl Y2lkZSB3aGF0IHZhbHVlcyB0byB1c2UuIFRoaXMgd291bGQgc29sdmUgdGhlIHByb2JsZW0gYW5k IGlzIHRoZSByaWdodCBhcHByb2FjaCBhbnlob3cgSU1ITy4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBIYXJhbGQgQWx2ZXN0cmFuZCBb bWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vXQ0KPiBTZW50OiBTYXR1cmRheSwgRmVicnVhcnkg MjcsIDIwMTYgODoxMSBBTQ0KPiBUbzogQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0 LmNvbT47IFJvbWFuIFNocG91bnQNCj4gPHJvbWFuQHRlbHVyaXguY29tPg0KPiBDYzogcnRjd2Vi QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBGd2Q6IExhc3QgQ2FsbDogPGRyYWZ0 LWlldGYtcnRjd2ViLWF1ZGlvLTEwLnR4dD4NCj4gKFdlYlJUQyBBdWRpbyBDb2RlYyBhbmQgUHJv Y2Vzc2luZyBSZXF1aXJlbWVudHMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+IA0KPiBEZW4gMjcu IGZlYi4gMjAxNiAxMTo0NSwgc2tyZXYgQXN2ZXJlbiwgVG9sZ2E6DQo+ID4gSWYgSSBkb27igJl0 IG1pcy9vdmVyLWludGVycHJldCBSb21hbuKAmXMgYW5zd2VyLCBpdCBzZWVtcyBsaWtlIGF0IGxl YXN0DQo+ID4gc29tZSBwZW9wbGUgd2hvIHJlYWxseSBjYXJlL2hhdmUgcHJhY3RpY2FsIGV4cGVy aWVuY2UgYWJvdXQgdGhpcw0KPiA+IGlzc3VlLCBlLmcuIFJvbWFuIGFuZCBteXNlbGYsIGFyZSBp biBmYXZvciBvZiBub3QgbWFuZGF0aW5nIGFueSB2YWx1ZXMNCj4gPiBhbmQgc3VnZ2VzdGluZyB0 aGF0IHczb3JnIHNwZWNpZmljYXRpb24gaXMgdXBkYXRlZCBhY2NvcmRpbmdseS4gSQ0KPiA+IHBl cnNvbmFsbHkgd291bGQgcHJlZmVyIG5vdGhpbmcgbW9yZSB0aGFuIGEgKG9yIHR3bykgc2VudGVu Y2UgYXMgYQ0KPiA+IHdhcm5pbmcgd2l0aG91dCB1c2luZyBhbnkga2V5d29yZHMgaW4gcnRjd2Vi LWF1ZGlvLiBEb2VzIHRoaXMgc291bmQgYQ0KPiA+IHJlYXNvbmFibGUgY2hvaWNlIHRvIG90aGVy IGZvbGtzPw0KPiANCj4gQXQgdGhlIFdFQlJUQyBBUEksIHRoaXMgKndpbGwqIGxlYWQgdG8gbm9u aW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMsDQo+IHNpbmNlIHNvbWUgYnJvd3NlcnMgd2ls bCBlbmZvcmNlIGRpZmZlcmVudCBsaW1pdHMgZnJvbSBvdGhlciBicm93c2Vycy4NCj4gDQo+IEl0 J3MgYWxsIGNvbWluZyBiYWNrIG5vdyAtIHdlIGRlY2lkZWQgdG8gZ28gd2l0aCBmaXhlZCBsaW1p dHMgaW4gdGhlIHNwZWMNCj4gYmVjYXVzZSBpdCB3YXMgaW5jb25jaWV2YWJsZSB0aGF0IGltcGxl bWVudGF0aW9ucyB3b3VsZG4ndCBpbXBvc2UNCj4gKnNvbWUqIGxpbWl0cywgYW5kIHRoZSBpZGVh IG9mIGFkZGluZyBBUEkgc3VyZmFjZSBmb3IgcHJvYmluZyB3aGF0IHRoZSBsaW1pdHMNCj4gd2Vy ZSB3YXMganVzdCB0b28gZ3Jvc3MgZm9yIHN1Y2ggYSBsb3ctdmFsdWUgKHJlbGF0aXZlbHkNCj4g c3BlYWtpbmcpIGZlYXR1cmUuDQo+IA0KPiANCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGFua3MsDQo+ ID4NCj4gPiBUb2xnYQ0KPiA+DQo+ID4NCj4gPg0KPiA+ICpGcm9tOipSb21hbiBTaHBvdW50IFtt YWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQo+ID4gKlNlbnQ6KiBGcmlkYXksIEZlYnJ1YXJ5IDI2 LCAyMDE2IDQ6NTYgUE0NCj4gPiAqVG86KiBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNu ZXQuY29tPg0KPiA+ICpDYzoqIEhhcmFsZCBBbHZlc3RyYW5kIDxoYXJhbGRAYWx2ZXN0cmFuZC5u bz47IHJ0Y3dlYkBpZXRmLm9yZw0KPiA+ICpTdWJqZWN0OiogUmU6IFtydGN3ZWJdIEZ3ZDogTGFz dCBDYWxsOg0KPiA+IDxkcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpby0xMC50eHQ+IChXZWJSVEMgQXVk aW8gQ29kZWMgYW5kIFByb2Nlc3NpbmcNCj4gPiBSZXF1aXJlbWVudHMpIHRvIFByb3Bvc2VkIFN0 YW5kYXJkDQo+ID4NCj4gPg0KPiA+DQo+ID4gT24gRnJpLCBGZWIgMjYsIDIwMTYgYXQgNjoxOSBB TSwgQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbQ0KPiA+IDxtYWlsdG86dGFz dmVyZW5Ac29udXNuZXQuY29tPj4gd3JvdGU6DQo+ID4NCj4gPiAgICAgaS0gSSB0aGluayB3M29y ZyBzaG91bGQgaGF2ZSBmb2xsb3dlZCB0aGUgbGVhZCBvZiBJRVRGIGluIHRoaXMgaXNzdWUNCj4g PiAgICAgcmF0aGVyIHRoYW4gdGhlIG90aGVyIHdheSBhcm91bmQsIGkuZS4gdGhlIHZhbHVlcyBy ZWNvbW1lbmRlZCBieSB0aGUNCj4gPiAgICAgSUVURiBzcGVjaWZpY2F0aW9uIHNob3VsZCBoYXZl IGJlZW4gY2l0ZWQgaW4gdGhlIHczb3JnIGRvY3VtZW50IElNSE8uDQo+ID4NCj4gPg0KPiA+DQo+ ID4gSSBhZ3JlZSBjb21wbGV0ZWx5LiBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSUVURiBkb2N1bWVu dCB0aGF0IGRlZmluZXMNCj4gPiBEVE1GIG9yIFJGQyA0NzMzIHRvbmUgZHVyYXRpb24gbGltaXRz LCBzbyBJIHByb3Bvc2VkIHRvIGFkZCB0aGVzZQ0KPiA+IGxpbWl0cyB0byBkcmFmdC1pZXRmLXJ0 Y3dlYi1hdWRpby4gTW9zdCBpbXBvcnRhbnRseSBJIHdhbnRlZCB0aGUgdGV4dA0KPiA+IGZyb20g VzNDIHJldmlld2VkIGluIElFVEYgc2luY2UgaXQgd2FzIGNsZWFybHkgYSBuZXR3b3JrIHJlbGF0 ZWQuDQo+ID4gRnVydGhlcm1vcmUsIGFueWJvZHkgaW1wbGVtZW50aW5nIFdlYlJUQyBjb21wYXRp YmxlIFJUUCBhdWRpbw0KPiA+IGludGVyZmFjZSBzaG91bGQgbm90IG5lZWQgdG8gcmVhZCB0aGUg QVBJIGRvY3VtZW50IHRvIGZpbmQgdGhlIG5ldHdvcmsNCj4gc3BlY2lmaWMgbGltaXRzLg0KPiA+ DQo+ID4NCj4gPg0KPiA+ICAgICBpaS0gVGhlIHJlYXNvbmFibGUgdmFsdWUgcmFuZ2UgY291bGQg ZGVwZW5kIG9uIHRoZSBuZWdvdGlhdGVkIGNvZGVjDQo+ID4gICAgIGFuZCB0aGF0IHdvdWxkIGJl IGtub3duIGF0IHRoZSB0aW1lIG9mIGludGVyZXN0aW5nIHRoZSBkaWdpdHM7IHNvDQo+ID4gICAg IGFueXRoaW5nIHdpdGggTVVTVCBzdHJlbmd0aCBpcyB0b28gcmVzdHJpY3RpdmUgSU1ITy4NCj4g Pg0KPiA+DQo+ID4NCj4gPiBXZSBrbm93IHRoYXQgUkZDIDQ3MzMgd291bGQgYmUgdXNlZCB0byB0 cmFuc21pdCBEVE1GIHRvbmVzIGZyb20NCj4gV2ViUlRDDQo+ID4gZW5kcG9pbnRzLiBSRkMgNDcz MyBoYXMgbm8gdXBwZXIgb3IgbG93ZXIgbGltaXRzIG9uIHRvbmUgZHVyYXRpb24sIHNvDQo+ID4g dGVjaG5pY2FsbHkgdGhlc2UgY2FuIGJlIHNldCB0byBhbnl0aGluZyBvciBub3Qgc2V0IGF0IGFs bC4gU29tZQ0KPiA+IHBlb3BsZSBhcmd1ZSB0aGF0IHdlIHNob3VsZCBsaW1pdCBudW1iZXIgb2Yg Zm9vdCBndW5zIGZvciBmdXR1cmUgQVBJDQo+ID4gdXNlcnMsIHNvIHRoZXkgd2FudGVkIHRvIGhh dmUgcmVhc29uYWJsZSB0b25lIGR1cmF0aW9uIGxpbWl0cy4NCj4gPg0KPiA+DQo+ID4NCj4gPiAg ICAgaWlpLSBUaGUgcHJlc2VuY2Ugb2YgdHJhbnNjb2RpbmcvaW50ZXJ3b3JraW5nIChiZXR3ZWVu IGRpZmZlcmVudA0KPiA+ICAgICBmb3JtcyBvZiBkaWdpdCB0cmFuc2ZlcikgZGV2aWNlcyAodGhl eSB3aWxsIGJlIHRoZXJlLCB3aGV0aGVyIHdlDQo+ID4gICAgIGxpa2UgaXQgb3Igbm90LCBmb3Ig Y2VydGFpbiBzY2VuYXJpb3MpIG1ha2VzIGl0IGV2ZW4gbGVzcyBkZXNpcmFibGUNCj4gPiAgICAg dG8gaGF2ZSBNVVNUIHN0cmVuZ3RoIG1hbmRhdGVzLg0KPiA+DQo+ID4NCj4gPg0KPiA+IFVuZm9y dHVuYXRlbHkgSSBzcGVuZCBhIHNpZ25pZmljYW50IGFtb3VudCBvZiBteSB0aW1lIGRlYWxpbmcg d2l0aA0KPiA+IHRyYW5zY29kaW5nIGVsZW1lbnRzIChTQkNzKSBkZWFsaW5nIHdpdGggUkZDIDQ3 MzMgdG9uZXMuIFNlbmRpbmcgdG9uZXMNCj4gPiB3aGljaCBhcmUgdG9vIHNob3J0IG9yIHNlbnQg YXQgaGlnaCByYXRlcyBtYWtlIHN1Y2ggdHJhbnNjb2RpbmcNCj4gPiBlbGVtZW50cyBnZW5lcmF0 ZSB1bmV4cGVjdGVkIG9yIGJyb2tlbiBEVE1GIHNlcXVlbmNlcy4gUmVvcmRlcmVkIG9yDQo+ID4g aW50ZXJsZWF2ZWQgdG9uZXMgYXJlIGNvbW1vbmx5IGdlbmVyYXRlZCBpbiByZXNwb25zZSB0byBz dWNoDQo+ID4gc2VxdWVuY2VzLiBFeHRyZW1lbHkgbG9uZyBkdXJhdGlvbiBEVE1GIGRpZ2l0cyB0 eXBpY2FsbHkgYnJlYWsgaW50bw0KPiA+IHNldmVyYWwgZGlnaXRzLiBUaGVyZSBpcyBkYW5nZXIg aW4gbm90IGhhdmluZyByZWFzb25hYmxlIGxpbWl0cy4gVGhlDQo+ID4gZGVjaXNpb24gaWYgQVBJ IHVzZXJzIHNob3VsZCBiZSBwcm90ZWN0ZWQgZnJvbSB0aGlzIGRhbmdlciBpcyB1cCB0byB0aGlz DQo+IGdyb3VwLg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgICBpdi0gSSB0aGluayBhZGRpbmcgc29t ZSB0ZXh0IHJlZ2FyZGluZyBnYXAvZHVyYXRpb24gb2YgZGlnaXQgcGFja2V0cw0KPiA+ICAgICBj b3VsZCBiZSBmaW5lIGJ1dCBJIHJhdGhlciB3b3VsZCBwcmVmZXIgaXQgd2l0aCDigJxyZWNvbW1l bmTigJ0gKGV2ZW4NCj4gPiAgICAgbm90IFJFQ09NTUVORCkgKGFuZCBwcm92aWRpbmcgc29tZSB2 YWx1ZXMgb25seSBhcyBleGFtcGxlcykuDQo+ID4NCj4gPg0KPiA+DQo+ID4gSSBhZ3JlZSB0aGF0 IGhhdmluZyByZWFzb25hYmxlIHJlY29tbWVuZGVkIHZhbHVlcyBzaG91bGQgYmUgc3VmZmljaWVu dA0KPiA+IGZvciBtb3N0IGNhc2VzLiBUaGUgZ3JvdXAgaGFzIHRvIGRlY2lkZSBpZiBpdCB3YW50 cyB0byBwcm90ZWN0IHRoZQ0KPiA+IGRldmVsb3BlcnMgZnJvbSB0aGVtc2VsdmVzIGFuZCBzZXQg TVVTVCBsZXZlbCBsaW1pdHMgb24gdG9uZSBhbmQgZ2FwDQo+ID4gZHVyYXRpb24uDQo+ID4NCj4g PiBfX19fX19fX19fX19fDQo+ID4gUm9tYW4gU2hwb3VudA0KPiA+DQo+ID4NCj4gPg0K From nobody Sun Feb 28 08:11:49 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2DF1A1C00 for ; Sun, 28 Feb 2016 08:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tG7MDeNnceM1 for ; Sun, 28 Feb 2016 08:11:46 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8543A1A1BF8 for ; Sun, 28 Feb 2016 08:11:46 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id e63so103820758ywc.3 for ; Sun, 28 Feb 2016 08:11:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=f2taZ29JewIDavvp7FHk1snl8deyY5Bks5+jEnSQrHo=; b=JRK84HZEqM/O0OZJWHRe0lm/PU34AjEB99R2Q7DDyjSMoBWlX6EyUdabYxjgDefsyb pm969Jd2ArDAVndAlKEDppAzke7gzhvVcmagTAlDBCeqFoZaUdu+uXs1nUu4mra/efoY V54uIt7vrJJynuD7EkMEDdMN8GjU/ML058OW3jMRLYSsrVk06h/lenCOyQH2Glq0/P6s MUJX5QmdAtteIst/ngrtJA0V7kAVEr+4IT61t5cGMqi+kCqtyKuQw/YWiHutLsvO0NFA yvczaS99dA/VyqFhmhHxsm07t+p7Q3LReVxBDerJBq9x2X+XOOWVtdPgdBgR5TO9kLyA /kNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=f2taZ29JewIDavvp7FHk1snl8deyY5Bks5+jEnSQrHo=; b=VO+IbB91FZVU2W+k7fhNvkVH9U+BFST8xl/POqadenDOvMS4f+xGLrhXLVu5UEXg10 FCtcAW5qAUfi9jbgl3DwP7TbbwoCBFmcuz3hdqi2303kpeGTVFgseor9+A9VK2buAE+m SGC+Nglk/bluyRnZEbGpEmlK7d3Pxs0wKoBzvE37Avdw5epbfIsTW93Tee4Q5cBaGu+r fLZWjbUjA1ULHd7MI435eLCmsth97WMQ56LFZZgoo70G5uJwDET9ePfK9l/IrA0MY7Qd XZTeiNB4lTs50F80UX/Ys9E5H7gFKF+O91TiE1P+xIzFJATElpT7zbKAd+aHpMtE/A2v VjTw== X-Gm-Message-State: AD7BkJKlwrqI6UN55NWOidogIJsSVNfudobmOUf4vhcPwRLUEP0tzOY5nML962Rv4zS17A24UOxvFt8N4cewxQ== X-Received: by 10.13.215.18 with SMTP id z18mr6021287ywd.278.1456675905792; Sun, 28 Feb 2016 08:11:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.66.207 with HTTP; Sun, 28 Feb 2016 08:11:26 -0800 (PST) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 28 Feb 2016 17:11:26 +0100 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [rtcweb] draft-roach-mmusic-unified-plan status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 16:11:48 -0000 Hi, What is the status of draft-roach-mmusic-unified-plan? There have been no new draft versions since the first one written in 2013. Is draft-roach-mmusic-unified-plan-00 up-to-date? Firefox already implements it (I will check soon whether it conforms to the spec in draft-roach-mmusic-unified-plan-00 or not), and Chrome is supposed to implement it in Q1 2016. So, shouldn't the draft get more love? I just cannot expect that it does not need changes after ~3 years... --=20 I=C3=B1aki Baz Castillo From nobody Sun Feb 28 08:30:25 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB841A6F0A for ; Sun, 28 Feb 2016 08:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiNPj5VufJGw for ; Sun, 28 Feb 2016 08:30:23 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1CD1A6F02 for ; Sun, 28 Feb 2016 08:30:23 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id u200so104398271ywf.0 for ; Sun, 28 Feb 2016 08:30:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=zQkGChb1vNl8Ny4xaSWprVbV4IuWxbO+S4pEwK20kXo=; b=vQhAXtnokRcilqw/JyEtMIRkO7E+NxjDYlqXKu2iQ+tn5FCxD8S3kTVyhNmWaBIFpa CbmxiyJj3KPJk3oM25ajSNbeR9ZZDSSflRwfxtv7oQc3uRu4mfACEqPxWaFesKjtvwZW pOIc6aBH8TIxtpGXx5R299muRGrtOVS6RkwTH/jt1TqggAeKpSxSwHSoD9CI0ushTWVF i8FGg/E3nO4G3/tVwZkBEvoMu22MeWaJJDoC3o7zFe2qYqSbvefetTUl/miteJuzvdSY uDDjj1l7HGoNA3IAMZzlGl5r1Wdi42aRlV2aeUnVsEPYDFDG8Sb84w/YnEZ6GN3WqC0x O4/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=zQkGChb1vNl8Ny4xaSWprVbV4IuWxbO+S4pEwK20kXo=; b=N9yRRB6CDi0S8HNdSsQC2/ZnQTvx/9mDC4bhaHmEPMccPBejRZ6uxYuMI+Q7DlIhgs OOLfe+hyKQQ0H6rqOkalaFTaEwIlEXC2qYLCMmcQ1qg9+w8kTZOBhXwuB29zN/tdQU60 dYG7m7Sg3t3s/J8VW213xkgm5rfpPsX+IE1PVcqmOlhn14CesZ+WRB6V5BcfiYKjkzSw Eo2AwI8V3UifMUdhcJCbgmU94Djfh3sm7YKies1C3xj2ZomNY59jaTcf7QUko/axFRk6 hz6jXKC+hjoTFFOYZ6uS4JzwAhA4L7RAEqKsFC/uWo4Z6pCjD/5RUo/G2OhkDU6cP43K fS0w== X-Gm-Message-State: AD7BkJJsonHz5jd+534uV5glS82hEbk5s+XybPh4B9Skj7YxIxP/m69S0SrjMIH/rxvDav/mO3FGpyxviGlpYw== X-Received: by 10.13.215.18 with SMTP id z18mr6054766ywd.278.1456677022761; Sun, 28 Feb 2016 08:30:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.66.207 with HTTP; Sun, 28 Feb 2016 08:30:03 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 28 Feb 2016 17:30:03 +0100 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] draft-roach-mmusic-unified-plan status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 16:30:24 -0000 2016-02-28 17:11 GMT+01:00 I=C3=B1aki Baz Castillo : > So, shouldn't the draft get more love? I just cannot expect that it > does not need changes after ~3 years... For example, the draft shows: a=3Dssrc:53280 This is, a "a=3Dssrc" SDP line with no attribute or attribute:value, which IMHO is incorrect according to RFC 5576 in which it is stated that: Each "ssrc" media attribute specifies a single source-level attribute for the given . For each source mentioned in SDP, the source-level attribute "cname", defined in Section 6.1, MUST be provided. https://tools.ietf.org/html/rfc5576#section-4.1 -------------------------- 4.1. The "ssrc" Media Attribute a=3Dssrc: a=3Dssrc: : -------------------------- --=20 I=C3=B1aki Baz Castillo From nobody Sun Feb 28 09:22:47 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9902D1A8760 for ; Sun, 28 Feb 2016 09:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoD6CqGdajza for ; Sun, 28 Feb 2016 09:22:45 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D081A875C for ; Sun, 28 Feb 2016 09:22:45 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u1SHMdjG060608 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 28 Feb 2016 11:22:40 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , "rtcweb@ietf.org" References: From: Adam Roach Message-ID: <56D32CDF.1010001@nostrum.com> Date: Sun, 28 Feb 2016 11:22:39 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] draft-roach-mmusic-unified-plan status X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 17:22:46 -0000 Unified plan was never intended to be an implementation spec. It (along with the plan-a and plan-b documents) described an approach for the purpose of having a working group discussion on the topic. It was purely an internal working group document. It served its purpose, and is finished. The actual implementation details associated with the approach it describes appear in the various SDP-related documents produced by RTCWEB and MMUSIC, such as the JSEP and simulcast documents. /a On 2/28/16 10:11, Iñaki Baz Castillo wrote: > Hi, > > What is the status of draft-roach-mmusic-unified-plan? There have been > no new draft versions since the first one written in 2013. Is > draft-roach-mmusic-unified-plan-00 up-to-date? > > Firefox already implements it (I will check soon whether it conforms > to the spec in draft-roach-mmusic-unified-plan-00 or not), and Chrome > is supposed to implement it in Q1 2016. > > So, shouldn't the draft get more love? I just cannot expect that it > does not need changes after ~3 years... > From nobody Mon Feb 29 09:22:41 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2491B381B for ; Mon, 29 Feb 2016 09:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AX6j-6N0qhcJ for ; Mon, 29 Feb 2016 09:22:36 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270FC1B3828 for ; Mon, 29 Feb 2016 09:22:32 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id o6so59092861qkc.2 for ; Mon, 29 Feb 2016 09:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GKaVmjlre9RDGoLgRpRlH42/kHUCcU3TTqy8dAt3NX4=; b=OZjSBhIHQFR/jGtLLsV7ZsNw2qq/2GQfqsz33gE6lrH3aEG0c65luexYdUXMVDJccc ryuI9vzgJpqT0bE26rENIPnPcmR/6K6AIuv83YjwMCC+0qPz4RlOuNAR0SRX9Seg4Qgx edJK9X8guoEAh3vs3q3zkL1zVm5i6JpKsE13YqIhls+O57NjZ8SXesG4fgSdvEEfuEMX Gk8+nxveGbn+1iU6J3VmnUspmEirHzX2knZcryB3szSR/SSJXX4gXtnb4Jm9lSo/FDBg A5V29q3hUozNHwYRon8s0M/WhMcKMziCTwDS8P2n4atF5LE478IjR3bsaG/BN6TYZWkq LjxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GKaVmjlre9RDGoLgRpRlH42/kHUCcU3TTqy8dAt3NX4=; b=GI4mvAUQGa8fexE70LykglhmNGG1K3Hi9Fq7o+Mi60e+I5tloJplEm0zWKjQ2ai6HU xrwcfgP1hTfZl7L6gnhMb9+dTuEei1+5vfDQzUt1V4VCD5idWFnVF+tVmR2KQOiDhnWv gbUrG47R3rXrqYSJybhhudMeglS+aatUFerGm2j30CQPJhfdTFHqg+Lg2SKaMAhC5wMo HuEMA3scSpWSzXVFXqHbHYZt9HyrbcTnlwd92rE8ne2t9TqFSODH6mcsQapAZgugcyCH CF5+KZjlXq3vMXLQ56fsb2mXvCkxFiaLtLNDOGtV/cTeFreoiC0gRkF4HjeVxvBladuM nNPQ== X-Gm-Message-State: AD7BkJI2WRXu6zxyW/d6+jXF6Wux8kwqNAQ5P4a7wPaypWusftpyIu7lzW51gTLJFWx39hrd1wbC1MadfkMPwg== X-Received: by 10.55.71.66 with SMTP id u63mr20878956qka.67.1456766551283; Mon, 29 Feb 2016 09:22:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.6.13 with HTTP; Mon, 29 Feb 2016 09:22:11 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> <56D1A080.7050901@alvestrand.no> From: Ted Hardie Date: Mon, 29 Feb 2016 09:22:11 -0800 Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a114a7974cf5e0a052cebe414 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 17:22:40 -0000 --001a114a7974cf5e0a052cebe414 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Feb 27, 2016 at 8:32 AM, Asveren, Tolga wrote: > I don=E2=80=99t think browsers should be enforcing *any* limitations. It = should be > up to the application developer to decide what values to use. So a tone of 2 hours duration is okay? That seems pretty likely to trigger the "multiple digits" issue that Roman pointed out for SBCs, for one thing. Harald's point is that there are some clearly silly possibilities out there, so some limitation will be there (1 hour, 3 minutes, 6000ms) and that probing for what an implementation has chosen is much more complicated here than makes sense. > This would solve the problem and is the right approach anyhow IMHO. > > Without any hats on, I think this is pretty unlikely work out well. Ted Thanks, > Tolga > > > -----Original Message----- > > From: Harald Alvestrand [mailto:harald@alvestrand.no] > > Sent: Saturday, February 27, 2016 8:11 AM > > To: Asveren, Tolga ; Roman Shpount > > > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] Fwd: Last Call: > > (WebRTC Audio Codec and Processing Requirements) to Proposed Standard > > > > Den 27. feb. 2016 11:45, skrev Asveren, Tolga: > > > If I don=E2=80=99t mis/over-interpret Roman=E2=80=99s answer, it seem= s like at least > > > some people who really care/have practical experience about this > > > issue, e.g. Roman and myself, are in favor of not mandating any value= s > > > and suggesting that w3org specification is updated accordingly. I > > > personally would prefer nothing more than a (or two) sentence as a > > > warning without using any keywords in rtcweb-audio. Does this sound a > > > reasonable choice to other folks? > > > > At the WEBRTC API, this *will* lead to noninteroperable implementations= , > > since some browsers will enforce different limits from other browsers. > > > > It's all coming back now - we decided to go with fixed limits in the sp= ec > > because it was inconcievable that implementations wouldn't impose > > *some* limits, and the idea of adding API surface for probing what the > limits > > were was just too gross for such a low-value (relatively > > speaking) feature. > > > > > > > > > > > > > > > > Thanks, > > > > > > Tolga > > > > > > > > > > > > *From:*Roman Shpount [mailto:roman@telurix.com] > > > *Sent:* Friday, February 26, 2016 4:56 PM > > > *To:* Asveren, Tolga > > > *Cc:* Harald Alvestrand ; rtcweb@ietf.org > > > *Subject:* Re: [rtcweb] Fwd: Last Call: > > > (WebRTC Audio Codec and Processing > > > Requirements) to Proposed Standard > > > > > > > > > > > > On Fri, Feb 26, 2016 at 6:19 AM, Asveren, Tolga > > > wrote: > > > > > > i- I think w3org should have followed the lead of IETF in this > issue > > > rather than the other way around, i.e. the values recommended by > the > > > IETF specification should have been cited in the w3org document > IMHO. > > > > > > > > > > > > I agree completely. I am not aware of any IETF document that defines > > > DTMF or RFC 4733 tone duration limits, so I proposed to add these > > > limits to draft-ietf-rtcweb-audio. Most importantly I wanted the text > > > from W3C reviewed in IETF since it was clearly a network related. > > > Furthermore, anybody implementing WebRTC compatible RTP audio > > > interface should not need to read the API document to find the networ= k > > specific limits. > > > > > > > > > > > > ii- The reasonable value range could depend on the negotiated cod= ec > > > and that would be known at the time of interesting the digits; so > > > anything with MUST strength is too restrictive IMHO. > > > > > > > > > > > > We know that RFC 4733 would be used to transmit DTMF tones from > > WebRTC > > > endpoints. RFC 4733 has no upper or lower limits on tone duration, so > > > technically these can be set to anything or not set at all. Some > > > people argue that we should limit number of foot guns for future API > > > users, so they wanted to have reasonable tone duration limits. > > > > > > > > > > > > iii- The presence of transcoding/interworking (between different > > > forms of digit transfer) devices (they will be there, whether we > > > like it or not, for certain scenarios) makes it even less desirab= le > > > to have MUST strength mandates. > > > > > > > > > > > > Unfortunately I spend a significant amount of my time dealing with > > > transcoding elements (SBCs) dealing with RFC 4733 tones. Sending tone= s > > > which are too short or sent at high rates make such transcoding > > > elements generate unexpected or broken DTMF sequences. Reordered or > > > interleaved tones are commonly generated in response to such > > > sequences. Extremely long duration DTMF digits typically break into > > > several digits. There is danger in not having reasonable limits. The > > > decision if API users should be protected from this danger is up to > this > > group. > > > > > > > > > > > > iv- I think adding some text regarding gap/duration of digit > packets > > > could be fine but I rather would prefer it with =E2=80=9Crecommen= d=E2=80=9D (even > > > not RECOMMEND) (and providing some values only as examples). > > > > > > > > > > > > I agree that having reasonable recommended values should be sufficien= t > > > for most cases. The group has to decide if it wants to protect the > > > developers from themselves and set MUST level limits on tone and gap > > > duration. > > > > > > _____________ > > > Roman Shpount > > > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a114a7974cf5e0a052cebe414 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Feb 27, 2016 at 8:32 AM, Asveren, Tolga <tas= veren@sonusnet.com> wrote:
I don=E2=80=99t think= browsers should be enforcing *any* limitations. It should be up to the app= lication developer to decide what values to use.

So a tone of 2 hours duration is okay?=C2=A0 That seems pretty likel= y to trigger the "multiple digits" issue that Roman pointed out f= or SBCs, for one thing.

Harald's point is that there are some cl= early silly possibilities out there, so some limitation will be there (1 ho= ur, 3 minutes, 6000ms) and that probing for what an implementation has chos= en is much more complicated here than makes sense.=C2=A0
=C2= =A0
This would solve the problem and is= the right approach anyhow IMHO.

=C2=A0Without any hats on, I think this is pretty unl= ikely work out well.

Ted

Thanks,
Tolga

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> Sent: Saturday, Februar= y 27, 2016 8:11 AM
> To: Asveren, Tolga <tasver= en@sonusnet.com>; Roman Shpount
> <roman@telurix.com>
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.t= xt>
> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard<= br> >
> Den 27. feb. 2016 11:45, skrev Asveren, Tolga:
> > If I don=E2=80=99t mis/over-interpret Roman=E2=80=99s answer, it = seems like at least
> > some people who really care/have practical experience about this<= br> > > issue, e.g. Roman and myself, are in favor of not mandating any v= alues
> > and suggesting that w3org specification is updated accordingly. I=
> > personally would prefer nothing more than a (or two) sentence as = a
> > warning without using any keywords in rtcweb-audio. Does this sou= nd a
> > reasonable choice to other folks?
>
> At the WEBRTC API, this *will* lead to noninteroperable implementation= s,
> since some browsers will enforce different limits from other browsers.=
>
> It's all coming back now - we decided to go with fixed limits in t= he spec
> because it was inconcievable that implementations wouldn't impose<= br> > *some* limits, and the idea of adding API surface for probing what the= limits
> were was just too gross for such a low-value (relatively
> speaking) feature.
>
>
> >
> >
> >
> > Thanks,
> >
> > Tolga
> >
> >
> >
> > *From:*Roman Shpount [mailto:roman@telurix.com]
> > *Sent:* Friday, February 26, 2016 4:56 PM
> > *To:* Asveren, Tolga <tasveren@sonusnet.com>
> > *Cc:* Harald Alvestrand <harald@alvestrand.no>; rtcweb@= ietf.org
> > *Subject:* Re: [rtcweb] Fwd: Last Call:
> > <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Pr= ocessing
> > Requirements) to Proposed Standard
> >
> >
> >
> > On Fri, Feb 26, 2016 at 6:19 AM, Asveren, Tolga <tasveren@sonusnet.com
> > <mailto:tasveren@sonu= snet.com>> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0i- I think w3org should have followed the lead= of IETF in this issue
> >=C2=A0 =C2=A0 =C2=A0rather than the other way around, i.e. the val= ues recommended by the
> >=C2=A0 =C2=A0 =C2=A0IETF specification should have been cited in t= he w3org document IMHO.
> >
> >
> >
> > I agree completely. I am not aware of any IETF document that defi= nes
> > DTMF or RFC 4733 tone duration limits, so I proposed to add these=
> > limits to draft-ietf-rtcweb-audio. Most importantly I wanted the = text
> > from W3C reviewed in IETF since it was clearly a network related.=
> > Furthermore, anybody implementing WebRTC compatible RTP audio
> > interface should not need to read the API document to find the ne= twork
> specific limits.
> >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0ii- The reasonable value range could depend on= the negotiated codec
> >=C2=A0 =C2=A0 =C2=A0and that would be known at the time of interes= ting the digits; so
> >=C2=A0 =C2=A0 =C2=A0anything with MUST strength is too restrictive= IMHO.
> >
> >
> >
> > We know that RFC 4733 would be used to transmit DTMF tones from > WebRTC
> > endpoints. RFC 4733 has no upper or lower limits on tone duration= , so
> > technically these can be set to anything or not set at all. Some<= br> > > people argue that we should limit number of foot guns for future = API
> > users, so they wanted to have reasonable tone duration limits. > >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0iii- The presence of transcoding/interworking = (between different
> >=C2=A0 =C2=A0 =C2=A0forms of digit transfer) devices (they will be= there, whether we
> >=C2=A0 =C2=A0 =C2=A0like it or not, for certain scenarios) makes i= t even less desirable
> >=C2=A0 =C2=A0 =C2=A0to have MUST strength mandates.
> >
> >
> >
> > Unfortunately I spend a significant amount of my time dealing wit= h
> > transcoding elements (SBCs) dealing with RFC 4733 tones. Sending = tones
> > which are too short or sent at high rates make such transcoding > > elements generate unexpected or broken DTMF sequences. Reordered = or
> > interleaved tones are commonly generated in response to such
> > sequences. Extremely long duration DTMF digits typically break in= to
> > several digits. There is danger in not having reasonable limits. = The
> > decision if API users should be protected from this danger is up = to this
> group.
> >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0iv- I think adding some text regarding gap/dur= ation of digit packets
> >=C2=A0 =C2=A0 =C2=A0could be fine but I rather would prefer it wit= h =E2=80=9Crecommend=E2=80=9D (even
> >=C2=A0 =C2=A0 =C2=A0not RECOMMEND) (and providing some values only= as examples).
> >
> >
> >
> > I agree that having reasonable recommended values should be suffi= cient
> > for most cases. The group has to decide if it wants to protect th= e
> > developers from themselves and set MUST level limits on tone and = gap
> > duration.
> >
> > _____________
> > Roman Shpount
> >
> >
> >
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a114a7974cf5e0a052cebe414-- From nobody Mon Feb 29 10:29:40 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D162C1B397F for ; Mon, 29 Feb 2016 10:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai_ZHwbdWnd3 for ; Mon, 29 Feb 2016 10:29:29 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0619.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:619]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1753C1B397D for ; Mon, 29 Feb 2016 10:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fwxq6/jf0PArdKvMOBA03999did2mvmOQv8LL9JuZrM=; b=Rrv4ki/xaE+W7DbyW08kfREmhmk10lDtErQPlbYDigsUAr9wkDVt72a1iOm0wkBHx9W6OBY/zX1FjMlio35KYhPXFU8fB0aOMtVxQ3QQRPllYvWuwvXTHCiNKs6pKIqDZZWcSzGiRdHy72i1Xce/ydL0thic8yYw8o7wvbMUjjI= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 29 Feb 2016 18:29:09 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Mon, 29 Feb 2016 18:29:09 +0000 From: "Asveren, Tolga" To: Ted Hardie Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p89KcurgAAU0gCAALLLgIAAOucggAC01ICAANVAYIAAKmkAgAA3mfCAAzMegIAAEaGA Date: Mon, 29 Feb 2016 18:29:09 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> <56D1A080.7050901@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 01c8b1ff-90e4-4701-e841-08d341363737 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:wader4tFxBfkV7yf6/lb0j3StaTi+U4syrLEJm8uhGmF3INLI1H/YgzGZIFoAZQ+ChBxGyE/Vw80iGXlHkxywIJT5GFff5bBfFC/6hBTEoIgGCi0bR9cI8dj09Nq/mf8ziKyAqLdmjNYuwSPSKLd2Q==; 24:/CK9SXaNFryG4efPrYktKTByL5ciuT594AviGMYEAfxFa8GZ3omwnQdc0s+AmjQfyQyCgVhvqaNMVuGUvDdMXih+Kt5xqjoiNZd344I/8hI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 0867F4F1AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(164054003)(2473001)(13464003)(377454003)(87936001)(3846002)(50986999)(19300405004)(76176999)(110136002)(5002640100001)(2906002)(102836003)(11100500001)(93886004)(230783001)(5003600100002)(81156008)(76576001)(1096002)(16236675004)(5004730100002)(19625215002)(122556002)(3660700001)(10400500002)(92566002)(15975445007)(6116002)(790700001)(3280700002)(74316001)(19617315012)(99286002)(19609705001)(2900100001)(33656002)(1220700001)(586003)(2950100001)(189998001)(5008740100001)(54356999)(66066001)(19580405001)(77096005)(19580395003)(86362001)(4326007)(40100003)(5001960100003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551506B16DC14D555E98AD4B2BA0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Feb 2016 18:29:09.7634 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 18:29:39 -0000 --_000_SN1PR0301MB1551506B16DC14D555E98AD4B2BA0SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgb2J2aW91c2x5IGFyZSBzb21lIHZhbHVlcyB3aGljaCBhcmUgdW5yZWFzb25hYmxlIGJ1 dCB1c2luZyBzYW5lIHZhbHVlcyBzaG91bGQgYmUgZHJpdmVuIGJ5IHRoZSBhcHBsaWNhdGlvbi4g QnJvd3NlcnMgc3RpbGwgY2FuIHN1cHBvcnQgc29tZSBkZWZhdWx0IHZhbHVlcyDigJN0byBiZSB1 c2VkIGlmIGFwcGxpY2F0aW9uIGRvZXMgbm90IHN1cHBseSBhbnkgdmFsdWUtLCBiZXR0ZXIgYmFz ZWQgb24gdGhlIG5lZ290aWF0ZWQgY29kZWMsIGZvciBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzLCB3 aG8gYXJlIG5vdCBzYXZ2eSBlbm91Z2ggdG8gcGljayBhIHZhbHVlLiBPVE9ILCB3aGF0IEkgYW0g YXJndWluZyBhZ2FpbnN0IGlzIGJyb3dzZXJzICplbmZvcmNpbmcqIGNlcnRhaW4gbGltaXRzIGFu ZCBydGN3ZWItYXVkaW8gc3BlY2lmaWNhdGlvbiBtYW5kYXRpbmcgbGltaXRzLg0KDQpUaGFua3Ms DQpUb2xnYQ0KDQpGcm9tOiBUZWQgSGFyZGllIFttYWlsdG86dGVkLmlldGZAZ21haWwuY29tXQ0K U2VudDogTW9uZGF5LCBGZWJydWFyeSAyOSwgMjAxNiAxMjoyMiBQTQ0KVG86IEFzdmVyZW4sIFRv bGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb20+DQpDYzogSGFyYWxkIEFsdmVzdHJhbmQgPGhhcmFs ZEBhbHZlc3RyYW5kLm5vPjsgUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb20+OyBydGN3 ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBGd2Q6IExhc3QgQ2FsbDogPGRyYWZ0 LWlldGYtcnRjd2ViLWF1ZGlvLTEwLnR4dD4gKFdlYlJUQyBBdWRpbyBDb2RlYyBhbmQgUHJvY2Vz c2luZyBSZXF1aXJlbWVudHMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoNCk9uIFNhdCwgRmViIDI3 LCAyMDE2IGF0IDg6MzIgQU0sIEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb208 bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+IHdyb3RlOg0KSSBkb27igJl0IHRoaW5rIGJy b3dzZXJzIHNob3VsZCBiZSBlbmZvcmNpbmcgKmFueSogbGltaXRhdGlvbnMuIEl0IHNob3VsZCBi ZSB1cCB0byB0aGUgYXBwbGljYXRpb24gZGV2ZWxvcGVyIHRvIGRlY2lkZSB3aGF0IHZhbHVlcyB0 byB1c2UuDQoNClNvIGEgdG9uZSBvZiAyIGhvdXJzIGR1cmF0aW9uIGlzIG9rYXk/ICBUaGF0IHNl ZW1zIHByZXR0eSBsaWtlbHkgdG8gdHJpZ2dlciB0aGUgIm11bHRpcGxlIGRpZ2l0cyIgaXNzdWUg dGhhdCBSb21hbiBwb2ludGVkIG91dCBmb3IgU0JDcywgZm9yIG9uZSB0aGluZy4NCg0KSGFyYWxk J3MgcG9pbnQgaXMgdGhhdCB0aGVyZSBhcmUgc29tZSBjbGVhcmx5IHNpbGx5IHBvc3NpYmlsaXRp ZXMgb3V0IHRoZXJlLCBzbyBzb21lIGxpbWl0YXRpb24gd2lsbCBiZSB0aGVyZSAoMSBob3VyLCAz IG1pbnV0ZXMsIDYwMDBtcykgYW5kIHRoYXQgcHJvYmluZyBmb3Igd2hhdCBhbiBpbXBsZW1lbnRh dGlvbiBoYXMgY2hvc2VuIGlzIG11Y2ggbW9yZSBjb21wbGljYXRlZCBoZXJlIHRoYW4gbWFrZXMg c2Vuc2UuDQoNClRoaXMgd291bGQgc29sdmUgdGhlIHByb2JsZW0gYW5kIGlzIHRoZSByaWdodCBh cHByb2FjaCBhbnlob3cgSU1ITy4NCiBXaXRob3V0IGFueSBoYXRzIG9uLCBJIHRoaW5rIHRoaXMg aXMgcHJldHR5IHVubGlrZWx5IHdvcmsgb3V0IHdlbGwuDQpUZWQNClRoYW5rcywNClRvbGdhDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSGFyYWxkIEFsdmVzdHJhbmQg W21haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubzxtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8+ XQ0KPiBTZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMjcsIDIwMTYgODoxMSBBTQ0KPiBUbzogQXN2 ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNu ZXQuY29tPj47IFJvbWFuIFNocG91bnQNCj4gPHJvbWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21h bkB0ZWx1cml4LmNvbT4+DQo+IENjOiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZz4NCj4gU3ViamVjdDogUmU6IFtydGN3ZWJdIEZ3ZDogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0 Zi1ydGN3ZWItYXVkaW8tMTAudHh0Pg0KPiAoV2ViUlRDIEF1ZGlvIENvZGVjIGFuZCBQcm9jZXNz aW5nIFJlcXVpcmVtZW50cykgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4NCj4gRGVuIDI3LiBmZWIu IDIwMTYgMTE6NDUsIHNrcmV2IEFzdmVyZW4sIFRvbGdhOg0KPiA+IElmIEkgZG9u4oCZdCBtaXMv b3Zlci1pbnRlcnByZXQgUm9tYW7igJlzIGFuc3dlciwgaXQgc2VlbXMgbGlrZSBhdCBsZWFzdA0K PiA+IHNvbWUgcGVvcGxlIHdobyByZWFsbHkgY2FyZS9oYXZlIHByYWN0aWNhbCBleHBlcmllbmNl IGFib3V0IHRoaXMNCj4gPiBpc3N1ZSwgZS5nLiBSb21hbiBhbmQgbXlzZWxmLCBhcmUgaW4gZmF2 b3Igb2Ygbm90IG1hbmRhdGluZyBhbnkgdmFsdWVzDQo+ID4gYW5kIHN1Z2dlc3RpbmcgdGhhdCB3 M29yZyBzcGVjaWZpY2F0aW9uIGlzIHVwZGF0ZWQgYWNjb3JkaW5nbHkuIEkNCj4gPiBwZXJzb25h bGx5IHdvdWxkIHByZWZlciBub3RoaW5nIG1vcmUgdGhhbiBhIChvciB0d28pIHNlbnRlbmNlIGFz IGENCj4gPiB3YXJuaW5nIHdpdGhvdXQgdXNpbmcgYW55IGtleXdvcmRzIGluIHJ0Y3dlYi1hdWRp by4gRG9lcyB0aGlzIHNvdW5kIGENCj4gPiByZWFzb25hYmxlIGNob2ljZSB0byBvdGhlciBmb2xr cz8NCj4NCj4gQXQgdGhlIFdFQlJUQyBBUEksIHRoaXMgKndpbGwqIGxlYWQgdG8gbm9uaW50ZXJv cGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMsDQo+IHNpbmNlIHNvbWUgYnJvd3NlcnMgd2lsbCBlbmZv cmNlIGRpZmZlcmVudCBsaW1pdHMgZnJvbSBvdGhlciBicm93c2Vycy4NCj4NCj4gSXQncyBhbGwg Y29taW5nIGJhY2sgbm93IC0gd2UgZGVjaWRlZCB0byBnbyB3aXRoIGZpeGVkIGxpbWl0cyBpbiB0 aGUgc3BlYw0KPiBiZWNhdXNlIGl0IHdhcyBpbmNvbmNpZXZhYmxlIHRoYXQgaW1wbGVtZW50YXRp b25zIHdvdWxkbid0IGltcG9zZQ0KPiAqc29tZSogbGltaXRzLCBhbmQgdGhlIGlkZWEgb2YgYWRk aW5nIEFQSSBzdXJmYWNlIGZvciBwcm9iaW5nIHdoYXQgdGhlIGxpbWl0cw0KPiB3ZXJlIHdhcyBq dXN0IHRvbyBncm9zcyBmb3Igc3VjaCBhIGxvdy12YWx1ZSAocmVsYXRpdmVseQ0KPiBzcGVha2lu ZykgZmVhdHVyZS4NCj4NCj4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4NCj4gPiBU b2xnYQ0KPiA+DQo+ID4NCj4gPg0KPiA+ICpGcm9tOipSb21hbiBTaHBvdW50IFttYWlsdG86cm9t YW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPl0NCj4gPiAqU2VudDoqIEZy aWRheSwgRmVicnVhcnkgMjYsIDIwMTYgNDo1NiBQTQ0KPiA+ICpUbzoqIEFzdmVyZW4sIFRvbGdh IDx0YXN2ZXJlbkBzb251c25ldC5jb208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+DQo+ ID4gKkNjOiogSGFyYWxkIEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPG1haWx0bzpo YXJhbGRAYWx2ZXN0cmFuZC5ubz4+OyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZz4NCj4gPiAqU3ViamVjdDoqIFJlOiBbcnRjd2ViXSBGd2Q6IExhc3QgQ2FsbDoNCj4gPiA8 ZHJhZnQtaWV0Zi1ydGN3ZWItYXVkaW8tMTAudHh0PiAoV2ViUlRDIEF1ZGlvIENvZGVjIGFuZCBQ cm9jZXNzaW5nDQo+ID4gUmVxdWlyZW1lbnRzKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+DQo+ ID4NCj4gPg0KPiA+IE9uIEZyaSwgRmViIDI2LCAyMDE2IGF0IDY6MTkgQU0sIEFzdmVyZW4sIFRv bGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4N Cj4gPiA8bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNu ZXQuY29tPj4+IHdyb3RlOg0KPiA+DQo+ID4gICAgIGktIEkgdGhpbmsgdzNvcmcgc2hvdWxkIGhh dmUgZm9sbG93ZWQgdGhlIGxlYWQgb2YgSUVURiBpbiB0aGlzIGlzc3VlDQo+ID4gICAgIHJhdGhl ciB0aGFuIHRoZSBvdGhlciB3YXkgYXJvdW5kLCBpLmUuIHRoZSB2YWx1ZXMgcmVjb21tZW5kZWQg YnkgdGhlDQo+ID4gICAgIElFVEYgc3BlY2lmaWNhdGlvbiBzaG91bGQgaGF2ZSBiZWVuIGNpdGVk IGluIHRoZSB3M29yZyBkb2N1bWVudCBJTUhPLg0KPiA+DQo+ID4NCj4gPg0KPiA+IEkgYWdyZWUg Y29tcGxldGVseS4gSSBhbSBub3QgYXdhcmUgb2YgYW55IElFVEYgZG9jdW1lbnQgdGhhdCBkZWZp bmVzDQo+ID4gRFRNRiBvciBSRkMgNDczMyB0b25lIGR1cmF0aW9uIGxpbWl0cywgc28gSSBwcm9w b3NlZCB0byBhZGQgdGhlc2UNCj4gPiBsaW1pdHMgdG8gZHJhZnQtaWV0Zi1ydGN3ZWItYXVkaW8u IE1vc3QgaW1wb3J0YW50bHkgSSB3YW50ZWQgdGhlIHRleHQNCj4gPiBmcm9tIFczQyByZXZpZXdl ZCBpbiBJRVRGIHNpbmNlIGl0IHdhcyBjbGVhcmx5IGEgbmV0d29yayByZWxhdGVkLg0KPiA+IEZ1 cnRoZXJtb3JlLCBhbnlib2R5IGltcGxlbWVudGluZyBXZWJSVEMgY29tcGF0aWJsZSBSVFAgYXVk aW8NCj4gPiBpbnRlcmZhY2Ugc2hvdWxkIG5vdCBuZWVkIHRvIHJlYWQgdGhlIEFQSSBkb2N1bWVu dCB0byBmaW5kIHRoZSBuZXR3b3JrDQo+IHNwZWNpZmljIGxpbWl0cy4NCj4gPg0KPiA+DQo+ID4N Cj4gPiAgICAgaWktIFRoZSByZWFzb25hYmxlIHZhbHVlIHJhbmdlIGNvdWxkIGRlcGVuZCBvbiB0 aGUgbmVnb3RpYXRlZCBjb2RlYw0KPiA+ICAgICBhbmQgdGhhdCB3b3VsZCBiZSBrbm93biBhdCB0 aGUgdGltZSBvZiBpbnRlcmVzdGluZyB0aGUgZGlnaXRzOyBzbw0KPiA+ICAgICBhbnl0aGluZyB3 aXRoIE1VU1Qgc3RyZW5ndGggaXMgdG9vIHJlc3RyaWN0aXZlIElNSE8uDQo+ID4NCj4gPg0KPiA+ DQo+ID4gV2Uga25vdyB0aGF0IFJGQyA0NzMzIHdvdWxkIGJlIHVzZWQgdG8gdHJhbnNtaXQgRFRN RiB0b25lcyBmcm9tDQo+IFdlYlJUQw0KPiA+IGVuZHBvaW50cy4gUkZDIDQ3MzMgaGFzIG5vIHVw cGVyIG9yIGxvd2VyIGxpbWl0cyBvbiB0b25lIGR1cmF0aW9uLCBzbw0KPiA+IHRlY2huaWNhbGx5 IHRoZXNlIGNhbiBiZSBzZXQgdG8gYW55dGhpbmcgb3Igbm90IHNldCBhdCBhbGwuIFNvbWUNCj4g PiBwZW9wbGUgYXJndWUgdGhhdCB3ZSBzaG91bGQgbGltaXQgbnVtYmVyIG9mIGZvb3QgZ3VucyBm b3IgZnV0dXJlIEFQSQ0KPiA+IHVzZXJzLCBzbyB0aGV5IHdhbnRlZCB0byBoYXZlIHJlYXNvbmFi bGUgdG9uZSBkdXJhdGlvbiBsaW1pdHMuDQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgIGlpaS0gVGhl IHByZXNlbmNlIG9mIHRyYW5zY29kaW5nL2ludGVyd29ya2luZyAoYmV0d2VlbiBkaWZmZXJlbnQN Cj4gPiAgICAgZm9ybXMgb2YgZGlnaXQgdHJhbnNmZXIpIGRldmljZXMgKHRoZXkgd2lsbCBiZSB0 aGVyZSwgd2hldGhlciB3ZQ0KPiA+ICAgICBsaWtlIGl0IG9yIG5vdCwgZm9yIGNlcnRhaW4gc2Nl bmFyaW9zKSBtYWtlcyBpdCBldmVuIGxlc3MgZGVzaXJhYmxlDQo+ID4gICAgIHRvIGhhdmUgTVVT VCBzdHJlbmd0aCBtYW5kYXRlcy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBVbmZvcnR1bmF0ZWx5IEkg c3BlbmQgYSBzaWduaWZpY2FudCBhbW91bnQgb2YgbXkgdGltZSBkZWFsaW5nIHdpdGgNCj4gPiB0 cmFuc2NvZGluZyBlbGVtZW50cyAoU0JDcykgZGVhbGluZyB3aXRoIFJGQyA0NzMzIHRvbmVzLiBT ZW5kaW5nIHRvbmVzDQo+ID4gd2hpY2ggYXJlIHRvbyBzaG9ydCBvciBzZW50IGF0IGhpZ2ggcmF0 ZXMgbWFrZSBzdWNoIHRyYW5zY29kaW5nDQo+ID4gZWxlbWVudHMgZ2VuZXJhdGUgdW5leHBlY3Rl ZCBvciBicm9rZW4gRFRNRiBzZXF1ZW5jZXMuIFJlb3JkZXJlZCBvcg0KPiA+IGludGVybGVhdmVk IHRvbmVzIGFyZSBjb21tb25seSBnZW5lcmF0ZWQgaW4gcmVzcG9uc2UgdG8gc3VjaA0KPiA+IHNl cXVlbmNlcy4gRXh0cmVtZWx5IGxvbmcgZHVyYXRpb24gRFRNRiBkaWdpdHMgdHlwaWNhbGx5IGJy ZWFrIGludG8NCj4gPiBzZXZlcmFsIGRpZ2l0cy4gVGhlcmUgaXMgZGFuZ2VyIGluIG5vdCBoYXZp bmcgcmVhc29uYWJsZSBsaW1pdHMuIFRoZQ0KPiA+IGRlY2lzaW9uIGlmIEFQSSB1c2VycyBzaG91 bGQgYmUgcHJvdGVjdGVkIGZyb20gdGhpcyBkYW5nZXIgaXMgdXAgdG8gdGhpcw0KPiBncm91cC4N Cj4gPg0KPiA+DQo+ID4NCj4gPiAgICAgaXYtIEkgdGhpbmsgYWRkaW5nIHNvbWUgdGV4dCByZWdh cmRpbmcgZ2FwL2R1cmF0aW9uIG9mIGRpZ2l0IHBhY2tldHMNCj4gPiAgICAgY291bGQgYmUgZmlu ZSBidXQgSSByYXRoZXIgd291bGQgcHJlZmVyIGl0IHdpdGgg4oCccmVjb21tZW5k4oCdIChldmVu DQo+ID4gICAgIG5vdCBSRUNPTU1FTkQpIChhbmQgcHJvdmlkaW5nIHNvbWUgdmFsdWVzIG9ubHkg YXMgZXhhbXBsZXMpLg0KPiA+DQo+ID4NCj4gPg0KPiA+IEkgYWdyZWUgdGhhdCBoYXZpbmcgcmVh c29uYWJsZSByZWNvbW1lbmRlZCB2YWx1ZXMgc2hvdWxkIGJlIHN1ZmZpY2llbnQNCj4gPiBmb3Ig bW9zdCBjYXNlcy4gVGhlIGdyb3VwIGhhcyB0byBkZWNpZGUgaWYgaXQgd2FudHMgdG8gcHJvdGVj dCB0aGUNCj4gPiBkZXZlbG9wZXJzIGZyb20gdGhlbXNlbHZlcyBhbmQgc2V0IE1VU1QgbGV2ZWwg bGltaXRzIG9uIHRvbmUgYW5kIGdhcA0KPiA+IGR1cmF0aW9uLg0KPiA+DQo+ID4gX19fX19fX19f X19fXw0KPiA+IFJvbWFuIFNocG91bnQNCj4gPg0KPiA+DQo+ID4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3 ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== --_000_SN1PR0301MB1551506B16DC14D555E98AD4B2BA0SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmltDQoJe21zby1zdHls ZS1uYW1lOmltO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+VGhlcmUgb2J2aW91c2x5IGFyZSBzb21lIHZhbHVlcyB3aGljaCBhcmUgdW5yZWFzb25h YmxlIGJ1dCB1c2luZyBzYW5lIHZhbHVlcyBzaG91bGQgYmUgZHJpdmVuIGJ5IHRoZSBhcHBsaWNh dGlvbi4gQnJvd3NlcnMgc3RpbGwgY2FuIHN1cHBvcnQgc29tZSBkZWZhdWx0IHZhbHVlcw0KIOKA k3RvIGJlIHVzZWQgaWYgYXBwbGljYXRpb24gZG9lcyBub3Qgc3VwcGx5IGFueSB2YWx1ZS0sIGJl dHRlciBiYXNlZCBvbiB0aGUgbmVnb3RpYXRlZCBjb2RlYywgZm9yIGFwcGxpY2F0aW9uIGRldmVs b3BlcnMsIHdobyBhcmUgbm90IHNhdnZ5IGVub3VnaCB0byBwaWNrIGEgdmFsdWUuIE9UT0gsIHdo YXQgSSBhbSBhcmd1aW5nIGFnYWluc3QgaXMgYnJvd3NlcnMgKjxiPmVuZm9yY2luZzwvYj4qIGNl cnRhaW4gbGltaXRzIGFuZCBydGN3ZWItYXVkaW8NCiBzcGVjaWZpY2F0aW9uIG1hbmRhdGluZyBs aW1pdHMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5Ub2xnYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRlZCBIYXJkaWUgW21haWx0bzp0 ZWQuaWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJydWFyeSAy OSwgMjAxNiAxMjoyMiBQTTxicj4NCjxiPlRvOjwvYj4gQXN2ZXJlbiwgVG9sZ2EgJmx0O3Rhc3Zl cmVuQHNvbnVzbmV0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEhhcmFsZCBBbHZlc3RyYW5kICZs dDtoYXJhbGRAYWx2ZXN0cmFuZC5ubyZndDs7IFJvbWFuIFNocG91bnQgJmx0O3JvbWFuQHRlbHVy aXguY29tJmd0OzsgcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRj d2ViXSBGd2Q6IExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLTEwLnR4dCZn dDsgKFdlYlJUQyBBdWRpbyBDb2RlYyBhbmQgUHJvY2Vzc2luZyBSZXF1aXJlbWVudHMpIHRvIFBy b3Bvc2VkIFN0YW5kYXJkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFNhdCwgRmViIDI3LCAyMDE2IGF0IDg6MzIgQU0sIEFzdmVyZW4sIFRv bGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIiB0YXJnZXQ9Il9i bGFuayI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbuKA mXQgdGhpbmsgYnJvd3NlcnMgc2hvdWxkIGJlIGVuZm9yY2luZyAqYW55KiBsaW1pdGF0aW9ucy4g SXQgc2hvdWxkIGJlIHVwIHRvIHRoZSBhcHBsaWNhdGlvbiBkZXZlbG9wZXIgdG8gZGVjaWRlIHdo YXQgdmFsdWVzIHRvIHVzZS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gYSB0b25lIG9mIDIgaG91cnMgZHVyYXRpb24gaXMg b2theT8mbmJzcDsgVGhhdCBzZWVtcyBwcmV0dHkgbGlrZWx5IHRvIHRyaWdnZXIgdGhlICZxdW90 O211bHRpcGxlIGRpZ2l0cyZxdW90OyBpc3N1ZSB0aGF0IFJvbWFuIHBvaW50ZWQgb3V0IGZvciBT QkNzLCBmb3Igb25lIHRoaW5nLjxicj4NCjxicj4NCkhhcmFsZCdzIHBvaW50IGlzIHRoYXQgdGhl cmUgYXJlIHNvbWUgY2xlYXJseSBzaWxseSBwb3NzaWJpbGl0aWVzIG91dCB0aGVyZSwgc28gc29t ZSBsaW1pdGF0aW9uIHdpbGwgYmUgdGhlcmUgKDEgaG91ciwgMyBtaW51dGVzLCA2MDAwbXMpIGFu ZCB0aGF0IHByb2JpbmcgZm9yIHdoYXQgYW4gaW1wbGVtZW50YXRpb24gaGFzIGNob3NlbiBpcyBt dWNoIG1vcmUgY29tcGxpY2F0ZWQgaGVyZSB0aGFuIG1ha2VzIHNlbnNlLiZuYnNwOw0KPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhpcyB3b3VsZCBzb2x2ZSB0aGUgcHJvYmxlbSBh bmQgaXMgdGhlIHJpZ2h0IGFwcHJvYWNoIGFueWhvdyBJTUhPLjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+Jm5ic3A7V2l0aG91dCBhbnkgaGF0cyBvbiwgSSB0aGluayB0aGlzIGlzIHBy ZXR0eSB1bmxpa2VseSB3b3JrIG91dCB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UZWQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rcyw8YnI+DQpUb2xnYTxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZndDsg RnJvbTogSGFyYWxkIEFsdmVzdHJhbmQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86aGFyYWxkQGFs dmVzdHJhbmQubm8iPmhhcmFsZEBhbHZlc3RyYW5kLm5vPC9hPl08L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgU2VudDogU2F0dXJk YXksIEZlYnJ1YXJ5IDI3LCAyMDE2IDg6MTEgQU08YnI+DQomZ3Q7IFRvOiBBc3ZlcmVuLCBUb2xn YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbSI+dGFzdmVyZW5Ac29u dXNuZXQuY29tPC9hPiZndDs7IFJvbWFuIFNocG91bnQ8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86cm9tYW5AdGVsdXJpeC5jb20iPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDs8YnI+DQom Z3Q7IENjOiA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRndkOiBMYXN0IENhbGw6ICZsdDtk cmFmdC1pZXRmLXJ0Y3dlYi1hdWRpby0xMC50eHQmZ3Q7PGJyPg0KJmd0OyAoV2ViUlRDIEF1ZGlv IENvZGVjIGFuZCBQcm9jZXNzaW5nIFJlcXVpcmVtZW50cykgdG8gUHJvcG9zZWQgU3RhbmRhcmQ8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBEZW4gMjcuIGZlYi4gMjAxNiAxMTo0NSwgc2tyZXYgQXN2ZXJl biwgVG9sZ2E6PGJyPg0KJmd0OyAmZ3Q7IElmIEkgZG9u4oCZdCBtaXMvb3Zlci1pbnRlcnByZXQg Um9tYW7igJlzIGFuc3dlciwgaXQgc2VlbXMgbGlrZSBhdCBsZWFzdDxicj4NCiZndDsgJmd0OyBz b21lIHBlb3BsZSB3aG8gcmVhbGx5IGNhcmUvaGF2ZSBwcmFjdGljYWwgZXhwZXJpZW5jZSBhYm91 dCB0aGlzPGJyPg0KJmd0OyAmZ3Q7IGlzc3VlLCBlLmcuIFJvbWFuIGFuZCBteXNlbGYsIGFyZSBp biBmYXZvciBvZiBub3QgbWFuZGF0aW5nIGFueSB2YWx1ZXM8YnI+DQomZ3Q7ICZndDsgYW5kIHN1 Z2dlc3RpbmcgdGhhdCB3M29yZyBzcGVjaWZpY2F0aW9uIGlzIHVwZGF0ZWQgYWNjb3JkaW5nbHku IEk8YnI+DQomZ3Q7ICZndDsgcGVyc29uYWxseSB3b3VsZCBwcmVmZXIgbm90aGluZyBtb3JlIHRo YW4gYSAob3IgdHdvKSBzZW50ZW5jZSBhcyBhPGJyPg0KJmd0OyAmZ3Q7IHdhcm5pbmcgd2l0aG91 dCB1c2luZyBhbnkga2V5d29yZHMgaW4gcnRjd2ViLWF1ZGlvLiBEb2VzIHRoaXMgc291bmQgYTxi cj4NCiZndDsgJmd0OyByZWFzb25hYmxlIGNob2ljZSB0byBvdGhlciBmb2xrcz88YnI+DQomZ3Q7 PGJyPg0KJmd0OyBBdCB0aGUgV0VCUlRDIEFQSSwgdGhpcyAqd2lsbCogbGVhZCB0byBub25pbnRl cm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucyw8YnI+DQomZ3Q7IHNpbmNlIHNvbWUgYnJvd3NlcnMg d2lsbCBlbmZvcmNlIGRpZmZlcmVudCBsaW1pdHMgZnJvbSBvdGhlciBicm93c2Vycy48YnI+DQom Z3Q7PGJyPg0KJmd0OyBJdCdzIGFsbCBjb21pbmcgYmFjayBub3cgLSB3ZSBkZWNpZGVkIHRvIGdv IHdpdGggZml4ZWQgbGltaXRzIGluIHRoZSBzcGVjPGJyPg0KJmd0OyBiZWNhdXNlIGl0IHdhcyBp bmNvbmNpZXZhYmxlIHRoYXQgaW1wbGVtZW50YXRpb25zIHdvdWxkbid0IGltcG9zZTxicj4NCiZn dDsgKnNvbWUqIGxpbWl0cywgYW5kIHRoZSBpZGVhIG9mIGFkZGluZyBBUEkgc3VyZmFjZSBmb3Ig cHJvYmluZyB3aGF0IHRoZSBsaW1pdHM8YnI+DQomZ3Q7IHdlcmUgd2FzIGp1c3QgdG9vIGdyb3Nz IGZvciBzdWNoIGEgbG93LXZhbHVlIChyZWxhdGl2ZWx5PGJyPg0KJmd0OyBzcGVha2luZykgZmVh dHVyZS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGFua3MsPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IFRvbGdhPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICpGcm9tOipSb21hbiBTaHBvdW50IFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIj5yb21hbkB0ZWx1cml4LmNvbTwvYT5dPGJyPg0KJmd0 OyAmZ3Q7ICpTZW50OiogRnJpZGF5LCBGZWJydWFyeSAyNiwgMjAxNiA0OjU2IFBNPGJyPg0KJmd0 OyAmZ3Q7ICpUbzoqIEFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5A c29udXNuZXQuY29tIj50YXN2ZXJlbkBzb251c25ldC5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0 OyAqQ2M6KiBIYXJhbGQgQWx2ZXN0cmFuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhcmFsZEBhbHZl c3RyYW5kLm5vIj5oYXJhbGRAYWx2ZXN0cmFuZC5ubzwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyAqU3Vi amVjdDoqIFJlOiBbcnRjd2ViXSBGd2Q6IExhc3QgQ2FsbDo8YnI+DQomZ3Q7ICZndDsgJmx0O2Ry YWZ0LWlldGYtcnRjd2ViLWF1ZGlvLTEwLnR4dCZndDsgKFdlYlJUQyBBdWRpbyBDb2RlYyBhbmQg UHJvY2Vzc2luZzxicj4NCiZndDsgJmd0OyBSZXF1aXJlbWVudHMpIHRvIFByb3Bvc2VkIFN0YW5k YXJkPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IE9uIEZyaSwgRmViIDI2LCAyMDE2IGF0IDY6MTkgQU0sIEFzdmVyZW4sIFRvbGdhICZs dDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIj50YXN2ZXJlbkBzb251c25l dC5jb208L2E+PGJyPg0KJmd0OyAmZ3Q7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRhc3Zl cmVuQHNvbnVzbmV0LmNvbSI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPiZndDsmZ3Q7IHdyb3Rl Ojxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7aS0gSSB0 aGluayB3M29yZyBzaG91bGQgaGF2ZSBmb2xsb3dlZCB0aGUgbGVhZCBvZiBJRVRGIGluIHRoaXMg aXNzdWU8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3JhdGhlciB0aGFuIHRoZSBv dGhlciB3YXkgYXJvdW5kLCBpLmUuIHRoZSB2YWx1ZXMgcmVjb21tZW5kZWQgYnkgdGhlPGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtJRVRGIHNwZWNpZmljYXRpb24gc2hvdWxkIGhh dmUgYmVlbiBjaXRlZCBpbiB0aGUgdzNvcmcgZG9jdW1lbnQgSU1ITy48YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSSBhZ3JlZSBjb21w bGV0ZWx5LiBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSUVURiBkb2N1bWVudCB0aGF0IGRlZmluZXM8 YnI+DQomZ3Q7ICZndDsgRFRNRiBvciBSRkMgNDczMyB0b25lIGR1cmF0aW9uIGxpbWl0cywgc28g SSBwcm9wb3NlZCB0byBhZGQgdGhlc2U8YnI+DQomZ3Q7ICZndDsgbGltaXRzIHRvIGRyYWZ0LWll dGYtcnRjd2ViLWF1ZGlvLiBNb3N0IGltcG9ydGFudGx5IEkgd2FudGVkIHRoZSB0ZXh0PGJyPg0K Jmd0OyAmZ3Q7IGZyb20gVzNDIHJldmlld2VkIGluIElFVEYgc2luY2UgaXQgd2FzIGNsZWFybHkg YSBuZXR3b3JrIHJlbGF0ZWQuPGJyPg0KJmd0OyAmZ3Q7IEZ1cnRoZXJtb3JlLCBhbnlib2R5IGlt cGxlbWVudGluZyBXZWJSVEMgY29tcGF0aWJsZSBSVFAgYXVkaW88YnI+DQomZ3Q7ICZndDsgaW50 ZXJmYWNlIHNob3VsZCBub3QgbmVlZCB0byByZWFkIHRoZSBBUEkgZG9jdW1lbnQgdG8gZmluZCB0 aGUgbmV0d29yazxicj4NCiZndDsgc3BlY2lmaWMgbGltaXRzLjxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7aWktIFRoZSByZWFzb25hYmxlIHZhbHVlIHJhbmdlIGNvdWxkIGRlcGVuZCBvbiB0aGUgbmVn b3RpYXRlZCBjb2RlYzxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7YW5kIHRoYXQg d291bGQgYmUga25vd24gYXQgdGhlIHRpbWUgb2YgaW50ZXJlc3RpbmcgdGhlIGRpZ2l0czsgc288 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2FueXRoaW5nIHdpdGggTVVTVCBzdHJl bmd0aCBpcyB0b28gcmVzdHJpY3RpdmUgSU1ITy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgV2Uga25vdyB0aGF0IFJGQyA0NzMzIHdv dWxkIGJlIHVzZWQgdG8gdHJhbnNtaXQgRFRNRiB0b25lcyBmcm9tPGJyPg0KJmd0OyBXZWJSVEM8 YnI+DQomZ3Q7ICZndDsgZW5kcG9pbnRzLiBSRkMgNDczMyBoYXMgbm8gdXBwZXIgb3IgbG93ZXIg bGltaXRzIG9uIHRvbmUgZHVyYXRpb24sIHNvPGJyPg0KJmd0OyAmZ3Q7IHRlY2huaWNhbGx5IHRo ZXNlIGNhbiBiZSBzZXQgdG8gYW55dGhpbmcgb3Igbm90IHNldCBhdCBhbGwuIFNvbWU8YnI+DQom Z3Q7ICZndDsgcGVvcGxlIGFyZ3VlIHRoYXQgd2Ugc2hvdWxkIGxpbWl0IG51bWJlciBvZiBmb290 IGd1bnMgZm9yIGZ1dHVyZSBBUEk8YnI+DQomZ3Q7ICZndDsgdXNlcnMsIHNvIHRoZXkgd2FudGVk IHRvIGhhdmUgcmVhc29uYWJsZSB0b25lIGR1cmF0aW9uIGxpbWl0cy48YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO2lpaS0gVGhlIHByZXNlbmNlIG9mIHRyYW5zY29kaW5nL2ludGVyd29ya2luZyAoYmV0 d2VlbiBkaWZmZXJlbnQ8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2Zvcm1zIG9m IGRpZ2l0IHRyYW5zZmVyKSBkZXZpY2VzICh0aGV5IHdpbGwgYmUgdGhlcmUsIHdoZXRoZXIgd2U8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2xpa2UgaXQgb3Igbm90LCBmb3IgY2Vy dGFpbiBzY2VuYXJpb3MpIG1ha2VzIGl0IGV2ZW4gbGVzcyBkZXNpcmFibGU8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwO3RvIGhhdmUgTVVTVCBzdHJlbmd0aCBtYW5kYXRlcy48YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg VW5mb3J0dW5hdGVseSBJIHNwZW5kIGEgc2lnbmlmaWNhbnQgYW1vdW50IG9mIG15IHRpbWUgZGVh bGluZyB3aXRoPGJyPg0KJmd0OyAmZ3Q7IHRyYW5zY29kaW5nIGVsZW1lbnRzIChTQkNzKSBkZWFs aW5nIHdpdGggUkZDIDQ3MzMgdG9uZXMuIFNlbmRpbmcgdG9uZXM8YnI+DQomZ3Q7ICZndDsgd2hp Y2ggYXJlIHRvbyBzaG9ydCBvciBzZW50IGF0IGhpZ2ggcmF0ZXMgbWFrZSBzdWNoIHRyYW5zY29k aW5nPGJyPg0KJmd0OyAmZ3Q7IGVsZW1lbnRzIGdlbmVyYXRlIHVuZXhwZWN0ZWQgb3IgYnJva2Vu IERUTUYgc2VxdWVuY2VzLiBSZW9yZGVyZWQgb3I8YnI+DQomZ3Q7ICZndDsgaW50ZXJsZWF2ZWQg dG9uZXMgYXJlIGNvbW1vbmx5IGdlbmVyYXRlZCBpbiByZXNwb25zZSB0byBzdWNoPGJyPg0KJmd0 OyAmZ3Q7IHNlcXVlbmNlcy4gRXh0cmVtZWx5IGxvbmcgZHVyYXRpb24gRFRNRiBkaWdpdHMgdHlw aWNhbGx5IGJyZWFrIGludG88YnI+DQomZ3Q7ICZndDsgc2V2ZXJhbCBkaWdpdHMuIFRoZXJlIGlz IGRhbmdlciBpbiBub3QgaGF2aW5nIHJlYXNvbmFibGUgbGltaXRzLiBUaGU8YnI+DQomZ3Q7ICZn dDsgZGVjaXNpb24gaWYgQVBJIHVzZXJzIHNob3VsZCBiZSBwcm90ZWN0ZWQgZnJvbSB0aGlzIGRh bmdlciBpcyB1cCB0byB0aGlzPGJyPg0KJmd0OyBncm91cC48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw O2l2LSBJIHRoaW5rIGFkZGluZyBzb21lIHRleHQgcmVnYXJkaW5nIGdhcC9kdXJhdGlvbiBvZiBk aWdpdCBwYWNrZXRzPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtjb3VsZCBiZSBm aW5lIGJ1dCBJIHJhdGhlciB3b3VsZCBwcmVmZXIgaXQgd2l0aCDigJxyZWNvbW1lbmTigJ0gKGV2 ZW48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO25vdCBSRUNPTU1FTkQpIChhbmQg cHJvdmlkaW5nIHNvbWUgdmFsdWVzIG9ubHkgYXMgZXhhbXBsZXMpLjxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJIGFncmVlIHRoYXQg aGF2aW5nIHJlYXNvbmFibGUgcmVjb21tZW5kZWQgdmFsdWVzIHNob3VsZCBiZSBzdWZmaWNpZW50 PGJyPg0KJmd0OyAmZ3Q7IGZvciBtb3N0IGNhc2VzLiBUaGUgZ3JvdXAgaGFzIHRvIGRlY2lkZSBp ZiBpdCB3YW50cyB0byBwcm90ZWN0IHRoZTxicj4NCiZndDsgJmd0OyBkZXZlbG9wZXJzIGZyb20g dGhlbXNlbHZlcyBhbmQgc2V0IE1VU1QgbGV2ZWwgbGltaXRzIG9uIHRvbmUgYW5kIGdhcDxicj4N CiZndDsgJmd0OyBkdXJhdGlvbi48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgX19fX19f X19fX19fXzxicj4NCiZndDsgJmd0OyBSb21hbiBTaHBvdW50PGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR0301MB1551506B16DC14D555E98AD4B2BA0SN1PR0301MB1551_-- From nobody Mon Feb 29 10:35:59 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75011B39A5 for ; Mon, 29 Feb 2016 10:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LLvvCKhhtwL for ; Mon, 29 Feb 2016 10:35:54 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497841B39A0 for ; Mon, 29 Feb 2016 10:35:54 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id x1so59917089qkc.1 for ; Mon, 29 Feb 2016 10:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V0VFpw6IQL/Ujn4jc4Xiu/SrMi5bzLFDE5sTCHJlggw=; b=i2IBVcHbMxHKGq1QZ2/d6koUuBIsEqYBQNulMUp1aXX6/DRj2NjBM/TwqceakDWghg cFkjHvYHEdqoeuBmHxGsvc0ARU5OTe4w+T+GyTcyJs2tE8fqUdsAsk6pn46AYRnRm5Bu RUIYr/O2/D3KA3VS0ui//WubRG+s1YU9Zqd0EhaUCU6bRElVDJ6wPKafuBU826lDCZ6Y 214i7/AGtqpqWRS4Dj3Q5M/fA6te8tQgmBvBS5tzyhVouwUB9lncrV9cAPUclrTT1DMU tjNe9SJ0SK2HdxcPPx2fMIX2Cw1C8FZrjiWBs0GaGDacyYywE6Fj2UwD2+qMBtvBfBP5 d8sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V0VFpw6IQL/Ujn4jc4Xiu/SrMi5bzLFDE5sTCHJlggw=; b=giQHCNMJl8KCl0ELJZvN7T129yK7JFsrqfYgWCWyyBQCfP5R35zpEbTbOCR9Ke+oOs 77FqslPhgI6ZsTvwuW9+9rZlTqX2n29qWo6WmOu5JxUkWTobpFGrTPNsj4xYhCvPwe7k CeHclRLU6uVPawwMJ0JKyczkHrPPa2eHJhWTtvFzPL2fNgz+iwSWfOZbcGadWl5Iml3d hXULL3RZaGnL7HnHUy5xZ5bDotMWGEuIQGPQY+Qy/vifa0s+nPKegEW3PA7xv1t+rlfl ARX9AtAS2AY6XMbDxVq7nxNm+V/8yPbtZQp5ldhO5q0U987IlGDodsJgFdFHqYYDZv5W JZtg== X-Gm-Message-State: AD7BkJITgaWK/QVEVqHImhdABJMEOtlRWC4bCHXvZNsOSc/9R31uNP9g5hwK4i08rljDkOOOGWPJI2lU/jv2mw== X-Received: by 10.55.195.16 with SMTP id a16mr21195835qkj.36.1456770953452; Mon, 29 Feb 2016 10:35:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.6.13 with HTTP; Mon, 29 Feb 2016 10:35:33 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> <56D1A080.7050901@alvestrand.no> From: Ted Hardie Date: Mon, 29 Feb 2016 10:35:33 -0800 Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a11479d863322f7052ceceb70 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 18:35:58 -0000 --001a11479d863322f7052ceceb70 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 29, 2016 at 10:29 AM, Asveren, Tolga wrote: > There obviously are some values which are unreasonable but using sane > values should be driven by the application > Okay, but the point of the max (6000ms) and min (40ms) is exactly that--to make a common statement about what range is sane in this context. Without that, there would have to be API surface for discovering what was considered sane; as Harald pointed out, that's going to get little use for the complication it adds. Do you disagree that these are sane values for a bound to the range? regards, Ted > . Browsers still can support some default values =E2=80=93to be used if > application does not supply any value-, better based on the negotiated > codec, for application developers, who are not savvy enough to pick a > value. OTOH, what I am arguing against is browsers **enforcing** certain > limits and rtcweb-audio specification mandating limits. > > > > Thanks, > > Tolga > > > > *From:* Ted Hardie [mailto:ted.ietf@gmail.com] > *Sent:* Monday, February 29, 2016 12:22 PM > *To:* Asveren, Tolga > *Cc:* Harald Alvestrand ; Roman Shpount < > roman@telurix.com>; rtcweb@ietf.org > > *Subject:* Re: [rtcweb] Fwd: Last Call: > (WebRTC Audio Codec and Processing Requirements) to Proposed Standard > > > > On Sat, Feb 27, 2016 at 8:32 AM, Asveren, Tolga > wrote: > > I don=E2=80=99t think browsers should be enforcing *any* limitations. It = should be > up to the application developer to decide what values to use. > > > > So a tone of 2 hours duration is okay? That seems pretty likely to > trigger the "multiple digits" issue that Roman pointed out for SBCs, for > one thing. > > Harald's point is that there are some clearly silly possibilities out > there, so some limitation will be there (1 hour, 3 minutes, 6000ms) and > that probing for what an implementation has chosen is much more complicat= ed > here than makes sense. > > > > This would solve the problem and is the right approach anyhow IMHO. > > Without any hats on, I think this is pretty unlikely work out well. > > Ted > > Thanks, > Tolga > > > -----Original Message----- > > From: Harald Alvestrand [mailto:harald@alvestrand.no] > > > Sent: Saturday, February 27, 2016 8:11 AM > > To: Asveren, Tolga ; Roman Shpount > > > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] Fwd: Last Call: > > (WebRTC Audio Codec and Processing Requirements) to Proposed Standard > > > > Den 27. feb. 2016 11:45, skrev Asveren, Tolga: > > > If I don=E2=80=99t mis/over-interpret Roman=E2=80=99s answer, it seem= s like at least > > > some people who really care/have practical experience about this > > > issue, e.g. Roman and myself, are in favor of not mandating any value= s > > > and suggesting that w3org specification is updated accordingly. I > > > personally would prefer nothing more than a (or two) sentence as a > > > warning without using any keywords in rtcweb-audio. Does this sound a > > > reasonable choice to other folks? > > > > At the WEBRTC API, this *will* lead to noninteroperable implementations= , > > since some browsers will enforce different limits from other browsers. > > > > It's all coming back now - we decided to go with fixed limits in the sp= ec > > because it was inconcievable that implementations wouldn't impose > > *some* limits, and the idea of adding API surface for probing what the > limits > > were was just too gross for such a low-value (relatively > > speaking) feature. > > > > > > > > > > > > > > > > Thanks, > > > > > > Tolga > > > > > > > > > > > > *From:*Roman Shpount [mailto:roman@telurix.com] > > > *Sent:* Friday, February 26, 2016 4:56 PM > > > *To:* Asveren, Tolga > > > *Cc:* Harald Alvestrand ; rtcweb@ietf.org > > > *Subject:* Re: [rtcweb] Fwd: Last Call: > > > (WebRTC Audio Codec and Processing > > > Requirements) to Proposed Standard > > > > > > > > > > > > On Fri, Feb 26, 2016 at 6:19 AM, Asveren, Tolga > > > wrote: > > > > > > i- I think w3org should have followed the lead of IETF in this > issue > > > rather than the other way around, i.e. the values recommended by > the > > > IETF specification should have been cited in the w3org document > IMHO. > > > > > > > > > > > > I agree completely. I am not aware of any IETF document that defines > > > DTMF or RFC 4733 tone duration limits, so I proposed to add these > > > limits to draft-ietf-rtcweb-audio. Most importantly I wanted the text > > > from W3C reviewed in IETF since it was clearly a network related. > > > Furthermore, anybody implementing WebRTC compatible RTP audio > > > interface should not need to read the API document to find the networ= k > > specific limits. > > > > > > > > > > > > ii- The reasonable value range could depend on the negotiated cod= ec > > > and that would be known at the time of interesting the digits; so > > > anything with MUST strength is too restrictive IMHO. > > > > > > > > > > > > We know that RFC 4733 would be used to transmit DTMF tones from > > WebRTC > > > endpoints. RFC 4733 has no upper or lower limits on tone duration, so > > > technically these can be set to anything or not set at all. Some > > > people argue that we should limit number of foot guns for future API > > > users, so they wanted to have reasonable tone duration limits. > > > > > > > > > > > > iii- The presence of transcoding/interworking (between different > > > forms of digit transfer) devices (they will be there, whether we > > > like it or not, for certain scenarios) makes it even less desirab= le > > > to have MUST strength mandates. > > > > > > > > > > > > Unfortunately I spend a significant amount of my time dealing with > > > transcoding elements (SBCs) dealing with RFC 4733 tones. Sending tone= s > > > which are too short or sent at high rates make such transcoding > > > elements generate unexpected or broken DTMF sequences. Reordered or > > > interleaved tones are commonly generated in response to such > > > sequences. Extremely long duration DTMF digits typically break into > > > several digits. There is danger in not having reasonable limits. The > > > decision if API users should be protected from this danger is up to > this > > group. > > > > > > > > > > > > iv- I think adding some text regarding gap/duration of digit > packets > > > could be fine but I rather would prefer it with =E2=80=9Crecommen= d=E2=80=9D (even > > > not RECOMMEND) (and providing some values only as examples). > > > > > > > > > > > > I agree that having reasonable recommended values should be sufficien= t > > > for most cases. The group has to decide if it wants to protect the > > > developers from themselves and set MUST level limits on tone and gap > > > duration. > > > > > > _____________ > > > Roman Shpount > > > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --001a11479d863322f7052ceceb70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 29, 2016 at 10:29 AM, Asveren, Tolga <tas= veren@sonusnet.com> wrote:

There obviously are some values which= are unreasonable but using sane values should be driven by the application=


Okay, but the point= of the max (6000ms) and min (40ms) is exactly that--to make a common state= ment about what range is sane in this context.=C2=A0 Without that, there wo= uld have to be API surface for discovering what was considered sane; as Har= ald pointed out, that's going to get little use for the complication it= adds.

Do you disagree that these are sane values for a b= ound to the range?

regards,

Ted

=C2=A0

. = Browsers still can support some default values =E2=80=93to be used if application does not supply any value-, better base= d on the negotiated codec, for application developers, who are not savvy en= ough to pick a value. OTOH, what I am arguing against is browsers *enfor= cing* certain limits and rtcweb-audio specification mandating limits.

=C2=A0

Thanks,

Tolga

=C2=A0

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Monday, February 29, 2016 12:22 PM
To: Asveren, Tolga <tasveren@sonusnet.com>
Cc: Harald Alvestrand <harald@alvestrand.no>; Roman Shpount <roman@telurix.com>; rtcweb@ietf.org=


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

=C2=A0

On Sat, Feb 27, 2016 at 8:32 AM, Asveren, Tolga <= tasveren@sonusne= t.com> wrote:

I don=E2=80=99t think browsers should be enforcing *= any* limitations. It should be up to the application developer to decide wh= at values to use.

=C2=A0

So a tone of 2 hours duration is okay?=C2=A0 That se= ems pretty likely to trigger the "multiple digits" issue that Rom= an pointed out for SBCs, for one thing.

Harald's point is that there are some clearly silly possibilities out t= here, so some limitation will be there (1 hour, 3 minutes, 6000ms) and that= probing for what an implementation has chosen is much more complicated her= e than makes sense.=C2=A0

=C2=A0

This would solve the = problem and is the right approach anyhow IMHO.

=C2=A0Without any hat= s on, I think this is pretty unlikely work out well.

Ted

Thanks,
Tolga

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]

> Sent: Saturday, February 27, 2016 8:11 AM
> To: Asveren, Tolga <tasveren@sonusnet.com>; Roman Shpount
> <roman@telur= ix.com>
> Cc: rtcweb@ietf.o= rg
> Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.t= xt>
> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard<= br> >
> Den 27. feb. 2016 11:45, skrev Asveren, Tolga:
> > If I don=E2=80=99t mis/over-interpret Roman=E2=80=99s answer, it = seems like at least
> > some people who really care/have practical experience about this<= br> > > issue, e.g. Roman and myself, are in favor of not mandating any v= alues
> > and suggesting that w3org specification is updated accordingly. I=
> > personally would prefer nothing more than a (or two) sentence as = a
> > warning without using any keywords in rtcweb-audio. Does this sou= nd a
> > reasonable choice to other folks?
>
> At the WEBRTC API, this *will* lead to noninteroperable implementation= s,
> since some browsers will enforce different limits from other browsers.=
>
> It's all coming back now - we decided to go with fixed limits in t= he spec
> because it was inconcievable that implementations wouldn't impose<= br> > *some* limits, and the idea of adding API surface for probing what the= limits
> were was just too gross for such a low-value (relatively
> speaking) feature.
>
>
> >
> >
> >
> > Thanks,
> >
> > Tolga
> >
> >
> >
> > *From:*Roman Shpount [mailto:roman@telurix.com]
> > *Sent:* Friday, February 26, 2016 4:56 PM
> > *To:* Asveren, Tolga <tasveren@sonusnet.com>
> > *Cc:* Harald Alvestrand <harald@alvestrand.no>; rtcweb@ietf.org > > *Subject:* Re: [rtcweb] Fwd: Last Call:
> > <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Pr= ocessing
> > Requirements) to Proposed Standard
> >
> >
> >
> > On Fri, Feb 26, 2016 at 6:19 AM, Asveren, Tolga <tasveren@sonusnet.com
> > <mailto:tasveren@sonusnet.com>> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0i- I think w3org should have followed the lead= of IETF in this issue
> >=C2=A0 =C2=A0 =C2=A0rather than the other way around, i.e. the val= ues recommended by the
> >=C2=A0 =C2=A0 =C2=A0IETF specification should have been cited in t= he w3org document IMHO.
> >
> >
> >
> > I agree completely. I am not aware of any IETF document that defi= nes
> > DTMF or RFC 4733 tone duration limits, so I proposed to add these=
> > limits to draft-ietf-rtcweb-audio. Most importantly I wanted the = text
> > from W3C reviewed in IETF since it was clearly a network related.=
> > Furthermore, anybody implementing WebRTC compatible RTP audio
> > interface should not need to read the API document to find the ne= twork
> specific limits.
> >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0ii- The reasonable value range could depend on= the negotiated codec
> >=C2=A0 =C2=A0 =C2=A0and that would be known at the time of interes= ting the digits; so
> >=C2=A0 =C2=A0 =C2=A0anything with MUST strength is too restrictive= IMHO.
> >
> >
> >
> > We know that RFC 4733 would be used to transmit DTMF tones from > WebRTC
> > endpoints. RFC 4733 has no upper or lower limits on tone duration= , so
> > technically these can be set to anything or not set at all. Some<= br> > > people argue that we should limit number of foot guns for future = API
> > users, so they wanted to have reasonable tone duration limits. > >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0iii- The presence of transcoding/interworking = (between different
> >=C2=A0 =C2=A0 =C2=A0forms of digit transfer) devices (they will be= there, whether we
> >=C2=A0 =C2=A0 =C2=A0like it or not, for certain scenarios) makes i= t even less desirable
> >=C2=A0 =C2=A0 =C2=A0to have MUST strength mandates.
> >
> >
> >
> > Unfortunately I spend a significant amount of my time dealing wit= h
> > transcoding elements (SBCs) dealing with RFC 4733 tones. Sending = tones
> > which are too short or sent at high rates make such transcoding > > elements generate unexpected or broken DTMF sequences. Reordered = or
> > interleaved tones are commonly generated in response to such
> > sequences. Extremely long duration DTMF digits typically break in= to
> > several digits. There is danger in not having reasonable limits. = The
> > decision if API users should be protected from this danger is up = to this
> group.
> >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0iv- I think adding some text regarding gap/dur= ation of digit packets
> >=C2=A0 =C2=A0 =C2=A0could be fine but I rather would prefer it wit= h =E2=80=9Crecommend=E2=80=9D (even
> >=C2=A0 =C2=A0 =C2=A0not RECOMMEND) (and providing some values only= as examples).
> >
> >
> >
> > I agree that having reasonable recommended values should be suffi= cient
> > for most cases. The group has to decide if it wants to protect th= e
> > developers from themselves and set MUST level limits on tone and = gap
> > duration.
> >
> > _____________
> > Roman Shpount
> >
> >
> >
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

=C2=A0


--001a11479d863322f7052ceceb70-- From nobody Mon Feb 29 10:42:22 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E281B3980 for ; Mon, 29 Feb 2016 10:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFTgPUALfZkR for ; Mon, 29 Feb 2016 10:42:16 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0089.outbound.protection.outlook.com [207.46.100.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC401B3937 for ; Mon, 29 Feb 2016 10:42:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=U1oMnQHF5PrEQCmaeRnWiwydycTk6+ZUrIM7jCC1P1c=; b=PXqwoGeXtqTIjnCwBRMPNHTgXblnBJVYSzSw8vHZsOp+HXykfVnuI2zOFyeUAF/YSm7Dx6GnR1Y+QRwizmf1xswbzQK0ZMEAT6sLRaHJ9Lqm/yj8NYEToGqdP8tXr/8ZlqFsqTJ5uE2D4SRWFQYM3xXyRG+ZXPhEuBok6GLTHhE= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 29 Feb 2016 18:42:14 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Mon, 29 Feb 2016 18:42:14 +0000 From: "Asveren, Tolga" To: Ted Hardie Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p89KcurgAAU0gCAALLLgIAAOucggAC01ICAANVAYIAAKmkAgAA3mfCAAzMegIAAEaGAgAAC3oCAAAAVkA== Date: Mon, 29 Feb 2016 18:42:14 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> <56D1A080.7050901@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 7de3f2a9-2427-40a6-892e-08d341380ad1 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:zJgZp0uqXahLbFTSyGo+jpnnb+c9woTRIoo6+b8g7nb5i6v/G4fxKTprJ3w9rxMAj0Ujqvo1v+XO48SuDXcr5/Nflkm+xywnj4XUVW/FTXu1P3xT5JhXZAvnk81oo91YC3EoFCi2PZ8JDawA9v4xXA==; 24:aBMUIMKsNG9yfkR817Z+JghBxwZLrVg/FhosUX9wl6in8EMqIWczMYjrutZhzSyuzAMgMzF3CZVa2jrk4EY3XllotiPq1PtY2/J75UKAg8A= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 0867F4F1AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(164054003)(2473001)(13464003)(377454003)(87936001)(3846002)(50986999)(19300405004)(76176999)(110136002)(5002640100001)(2906002)(102836003)(11100500001)(93886004)(230783001)(5003600100002)(81156008)(76576001)(1096002)(16236675004)(5004730100002)(19625215002)(122556002)(3660700001)(10400500002)(92566002)(15975445007)(6116002)(790700001)(3280700002)(74316001)(19617315012)(99286002)(19609705001)(2900100001)(33656002)(1220700001)(586003)(2950100001)(189998001)(5008740100001)(54356999)(66066001)(19580405001)(77096005)(19580395003)(86362001)(4326007)(40100003)(5001960100003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551C791B62BC7311DB3897CB2BA0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Feb 2016 18:42:14.2975 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 18:42:21 -0000 --_000_SN1PR0301MB1551C791B62BC7311DB3897CB2BA0SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3Qgc3VyZSB3aGV0aGVyIDQwbXMgc2hvdWxkIGJlIGFic29sdXRlIG1pbmltdW0gZm9y IGFsbCBjb2RlY3MuIEV2ZW4gZm9yIDYwMDBtcywgd2hvIGFtIEkgdG8gYXJndWUgdGhhdCBzb21l Ym9keSBjYW7igJl0IGNvbWUgdXAgd2l0aCBhIHVzZSBjYXNlL2FwcGxpY2F0aW9uLCB3aGljaCBy ZXF1aXJlcyBzb21ldGhpbmcgbG9uZ2VyLiBTbywgb3ZlcmFsbCwgZW5mb3JjaW5nIGRvZXMgbm90 IHNlZW0gdG8gYmUgdGhlIHJpZ2h0IHRoaW5nIElNR08gKGRlZmF1bHQgdmFsdWUgaXMgZmluZSBh cyBhbHJlYWR5IGluZGljYXRlZCkgKGFuZCBJIGRvbuKAmXQgZnVsbHkgYWdyZWUgd2l0aCB5b3Vy IHN0YXRlbWVudCB0aGF0IOKAnHRoZSBwb2ludCBvZiBtaW4vbWF4IGlzIHByb21vdGluZyBzYW5l IHZhbHVlc+KAnSBhcyB0aGUgbW9kZWwgeW91IGFyZSBkZXNjcmliaW5nIGlzICDigJxlbmZvcmNp bmfigJ0gYSByYW5nZSByYXRoZXIgdGhhbiBhIGRlZmF1bHQgdmFsdWUgaW4gYnJvd3Nlci9yZWNv bW1lbmRhdGlvbiBpbiB0aGUgc3BlY2lmaWNhdGlvbikuDQoNClRoYW5rcywNClRvbGdhDQoNCkZy b206IFRlZCBIYXJkaWUgW21haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb21dDQpTZW50OiBNb25kYXks IEZlYnJ1YXJ5IDI5LCAyMDE2IDE6MzYgUE0NClRvOiBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5A c29udXNuZXQuY29tPg0KQ2M6IEhhcmFsZCBBbHZlc3RyYW5kIDxoYXJhbGRAYWx2ZXN0cmFuZC5u bz47IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPjsgcnRjd2ViQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3J0Y3dlYl0gRndkOiBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLXJ0Y3dlYi1h dWRpby0xMC50eHQ+IChXZWJSVEMgQXVkaW8gQ29kZWMgYW5kIFByb2Nlc3NpbmcgUmVxdWlyZW1l bnRzKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KDQpPbiBNb24sIEZlYiAyOSwgMjAxNiBhdCAxMDoy OSBBTSwgQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVy ZW5Ac29udXNuZXQuY29tPj4gd3JvdGU6DQpUaGVyZSBvYnZpb3VzbHkgYXJlIHNvbWUgdmFsdWVz IHdoaWNoIGFyZSB1bnJlYXNvbmFibGUgYnV0IHVzaW5nIHNhbmUgdmFsdWVzIHNob3VsZCBiZSBk cml2ZW4gYnkgdGhlIGFwcGxpY2F0aW9uDQoNCk9rYXksIGJ1dCB0aGUgcG9pbnQgb2YgdGhlIG1h eCAoNjAwMG1zKSBhbmQgbWluICg0MG1zKSBpcyBleGFjdGx5IHRoYXQtLXRvIG1ha2UgYSBjb21t b24gc3RhdGVtZW50IGFib3V0IHdoYXQgcmFuZ2UgaXMgc2FuZSBpbiB0aGlzIGNvbnRleHQuICBX aXRob3V0IHRoYXQsIHRoZXJlIHdvdWxkIGhhdmUgdG8gYmUgQVBJIHN1cmZhY2UgZm9yIGRpc2Nv dmVyaW5nIHdoYXQgd2FzIGNvbnNpZGVyZWQgc2FuZTsgYXMgSGFyYWxkIHBvaW50ZWQgb3V0LCB0 aGF0J3MgZ29pbmcgdG8gZ2V0IGxpdHRsZSB1c2UgZm9yIHRoZSBjb21wbGljYXRpb24gaXQgYWRk cy4NCkRvIHlvdSBkaXNhZ3JlZSB0aGF0IHRoZXNlIGFyZSBzYW5lIHZhbHVlcyBmb3IgYSBib3Vu ZCB0byB0aGUgcmFuZ2U/DQpyZWdhcmRzLA0KVGVkDQoNCg0KLiBCcm93c2VycyBzdGlsbCBjYW4g c3VwcG9ydCBzb21lIGRlZmF1bHQgdmFsdWVzIOKAk3RvIGJlIHVzZWQgaWYgYXBwbGljYXRpb24g ZG9lcyBub3Qgc3VwcGx5IGFueSB2YWx1ZS0sIGJldHRlciBiYXNlZCBvbiB0aGUgbmVnb3RpYXRl ZCBjb2RlYywgZm9yIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMsIHdobyBhcmUgbm90IHNhdnZ5IGVu b3VnaCB0byBwaWNrIGEgdmFsdWUuIE9UT0gsIHdoYXQgSSBhbSBhcmd1aW5nIGFnYWluc3QgaXMg YnJvd3NlcnMgKmVuZm9yY2luZyogY2VydGFpbiBsaW1pdHMgYW5kIHJ0Y3dlYi1hdWRpbyBzcGVj aWZpY2F0aW9uIG1hbmRhdGluZyBsaW1pdHMuDQoNClRoYW5rcywNClRvbGdhDQoNCkZyb206IFRl ZCBIYXJkaWUgW21haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnRlZC5pZXRmQGdtYWls LmNvbT5dDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI5LCAyMDE2IDEyOjIyIFBNDQpUbzogQXN2 ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNu ZXQuY29tPj4NCkNjOiBIYXJhbGQgQWx2ZXN0cmFuZCA8aGFyYWxkQGFsdmVzdHJhbmQubm88bWFp bHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vPj47IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXgu Y29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+OyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0 Y3dlYkBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEZ3ZDogTGFzdCBDYWxsOiA8 ZHJhZnQtaWV0Zi1ydGN3ZWItYXVkaW8tMTAudHh0PiAoV2ViUlRDIEF1ZGlvIENvZGVjIGFuZCBQ cm9jZXNzaW5nIFJlcXVpcmVtZW50cykgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCg0KT24gU2F0LCBG ZWIgMjcsIDIwMTYgYXQgODozMiBBTSwgQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0 LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tPj4gd3JvdGU6DQpJIGRvbuKAmXQgdGhp bmsgYnJvd3NlcnMgc2hvdWxkIGJlIGVuZm9yY2luZyAqYW55KiBsaW1pdGF0aW9ucy4gSXQgc2hv dWxkIGJlIHVwIHRvIHRoZSBhcHBsaWNhdGlvbiBkZXZlbG9wZXIgdG8gZGVjaWRlIHdoYXQgdmFs dWVzIHRvIHVzZS4NCg0KU28gYSB0b25lIG9mIDIgaG91cnMgZHVyYXRpb24gaXMgb2theT8gIFRo YXQgc2VlbXMgcHJldHR5IGxpa2VseSB0byB0cmlnZ2VyIHRoZSAibXVsdGlwbGUgZGlnaXRzIiBp c3N1ZSB0aGF0IFJvbWFuIHBvaW50ZWQgb3V0IGZvciBTQkNzLCBmb3Igb25lIHRoaW5nLg0KDQpI YXJhbGQncyBwb2ludCBpcyB0aGF0IHRoZXJlIGFyZSBzb21lIGNsZWFybHkgc2lsbHkgcG9zc2li aWxpdGllcyBvdXQgdGhlcmUsIHNvIHNvbWUgbGltaXRhdGlvbiB3aWxsIGJlIHRoZXJlICgxIGhv dXIsIDMgbWludXRlcywgNjAwMG1zKSBhbmQgdGhhdCBwcm9iaW5nIGZvciB3aGF0IGFuIGltcGxl bWVudGF0aW9uIGhhcyBjaG9zZW4gaXMgbXVjaCBtb3JlIGNvbXBsaWNhdGVkIGhlcmUgdGhhbiBt YWtlcyBzZW5zZS4NCg0KVGhpcyB3b3VsZCBzb2x2ZSB0aGUgcHJvYmxlbSBhbmQgaXMgdGhlIHJp Z2h0IGFwcHJvYWNoIGFueWhvdyBJTUhPLg0KIFdpdGhvdXQgYW55IGhhdHMgb24sIEkgdGhpbmsg dGhpcyBpcyBwcmV0dHkgdW5saWtlbHkgd29yayBvdXQgd2VsbC4NClRlZA0KVGhhbmtzLA0KVG9s Z2ENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBIYXJhbGQgQWx2ZXN0 cmFuZCBbbWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vPG1haWx0bzpoYXJhbGRAYWx2ZXN0cmFu ZC5ubz5dDQo+IFNlbnQ6IFNhdHVyZGF5LCBGZWJydWFyeSAyNywgMjAxNiA4OjExIEFNDQo+IFRv OiBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPG1haWx0bzp0YXN2ZXJlbkBz b251c25ldC5jb20+PjsgUm9tYW4gU2hwb3VudA0KPiA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRv OnJvbWFuQHRlbHVyaXguY29tPj4NCj4gQ2M6IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2Vi QGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRndkOiBMYXN0IENhbGw6IDxkcmFm dC1pZXRmLXJ0Y3dlYi1hdWRpby0xMC50eHQ+DQo+IChXZWJSVEMgQXVkaW8gQ29kZWMgYW5kIFBy b2Nlc3NpbmcgUmVxdWlyZW1lbnRzKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPg0KPiBEZW4gMjcu IGZlYi4gMjAxNiAxMTo0NSwgc2tyZXYgQXN2ZXJlbiwgVG9sZ2E6DQo+ID4gSWYgSSBkb27igJl0 IG1pcy9vdmVyLWludGVycHJldCBSb21hbuKAmXMgYW5zd2VyLCBpdCBzZWVtcyBsaWtlIGF0IGxl YXN0DQo+ID4gc29tZSBwZW9wbGUgd2hvIHJlYWxseSBjYXJlL2hhdmUgcHJhY3RpY2FsIGV4cGVy aWVuY2UgYWJvdXQgdGhpcw0KPiA+IGlzc3VlLCBlLmcuIFJvbWFuIGFuZCBteXNlbGYsIGFyZSBp biBmYXZvciBvZiBub3QgbWFuZGF0aW5nIGFueSB2YWx1ZXMNCj4gPiBhbmQgc3VnZ2VzdGluZyB0 aGF0IHczb3JnIHNwZWNpZmljYXRpb24gaXMgdXBkYXRlZCBhY2NvcmRpbmdseS4gSQ0KPiA+IHBl cnNvbmFsbHkgd291bGQgcHJlZmVyIG5vdGhpbmcgbW9yZSB0aGFuIGEgKG9yIHR3bykgc2VudGVu Y2UgYXMgYQ0KPiA+IHdhcm5pbmcgd2l0aG91dCB1c2luZyBhbnkga2V5d29yZHMgaW4gcnRjd2Vi LWF1ZGlvLiBEb2VzIHRoaXMgc291bmQgYQ0KPiA+IHJlYXNvbmFibGUgY2hvaWNlIHRvIG90aGVy IGZvbGtzPw0KPg0KPiBBdCB0aGUgV0VCUlRDIEFQSSwgdGhpcyAqd2lsbCogbGVhZCB0byBub25p bnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucywNCj4gc2luY2Ugc29tZSBicm93c2VycyB3aWxs IGVuZm9yY2UgZGlmZmVyZW50IGxpbWl0cyBmcm9tIG90aGVyIGJyb3dzZXJzLg0KPg0KPiBJdCdz IGFsbCBjb21pbmcgYmFjayBub3cgLSB3ZSBkZWNpZGVkIHRvIGdvIHdpdGggZml4ZWQgbGltaXRz IGluIHRoZSBzcGVjDQo+IGJlY2F1c2UgaXQgd2FzIGluY29uY2lldmFibGUgdGhhdCBpbXBsZW1l bnRhdGlvbnMgd291bGRuJ3QgaW1wb3NlDQo+ICpzb21lKiBsaW1pdHMsIGFuZCB0aGUgaWRlYSBv ZiBhZGRpbmcgQVBJIHN1cmZhY2UgZm9yIHByb2Jpbmcgd2hhdCB0aGUgbGltaXRzDQo+IHdlcmUg d2FzIGp1c3QgdG9vIGdyb3NzIGZvciBzdWNoIGEgbG93LXZhbHVlIChyZWxhdGl2ZWx5DQo+IHNw ZWFraW5nKSBmZWF0dXJlLg0KPg0KPg0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPg0K PiA+IFRvbGdhDQo+ID4NCj4gPg0KPiA+DQo+ID4gKkZyb206KlJvbWFuIFNocG91bnQgW21haWx0 bzpyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+XQ0KPiA+ICpTZW50 OiogRnJpZGF5LCBGZWJydWFyeSAyNiwgMjAxNiA0OjU2IFBNDQo+ID4gKlRvOiogQXN2ZXJlbiwg VG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29t Pj4NCj4gPiAqQ2M6KiBIYXJhbGQgQWx2ZXN0cmFuZCA8aGFyYWxkQGFsdmVzdHJhbmQubm88bWFp bHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vPj47IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2Vi QGlldGYub3JnPg0KPiA+ICpTdWJqZWN0OiogUmU6IFtydGN3ZWJdIEZ3ZDogTGFzdCBDYWxsOg0K PiA+IDxkcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpby0xMC50eHQ+IChXZWJSVEMgQXVkaW8gQ29kZWMg YW5kIFByb2Nlc3NpbmcNCj4gPiBSZXF1aXJlbWVudHMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+ ID4NCj4gPg0KPiA+DQo+ID4gT24gRnJpLCBGZWIgMjYsIDIwMTYgYXQgNjoxOSBBTSwgQXN2ZXJl biwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQu Y29tPg0KPiA+IDxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tPG1haWx0bzp0YXN2ZXJlbkBz b251c25ldC5jb20+Pj4gd3JvdGU6DQo+ID4NCj4gPiAgICAgaS0gSSB0aGluayB3M29yZyBzaG91 bGQgaGF2ZSBmb2xsb3dlZCB0aGUgbGVhZCBvZiBJRVRGIGluIHRoaXMgaXNzdWUNCj4gPiAgICAg cmF0aGVyIHRoYW4gdGhlIG90aGVyIHdheSBhcm91bmQsIGkuZS4gdGhlIHZhbHVlcyByZWNvbW1l bmRlZCBieSB0aGUNCj4gPiAgICAgSUVURiBzcGVjaWZpY2F0aW9uIHNob3VsZCBoYXZlIGJlZW4g Y2l0ZWQgaW4gdGhlIHczb3JnIGRvY3VtZW50IElNSE8uDQo+ID4NCj4gPg0KPiA+DQo+ID4gSSBh Z3JlZSBjb21wbGV0ZWx5LiBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSUVURiBkb2N1bWVudCB0aGF0 IGRlZmluZXMNCj4gPiBEVE1GIG9yIFJGQyA0NzMzIHRvbmUgZHVyYXRpb24gbGltaXRzLCBzbyBJ IHByb3Bvc2VkIHRvIGFkZCB0aGVzZQ0KPiA+IGxpbWl0cyB0byBkcmFmdC1pZXRmLXJ0Y3dlYi1h dWRpby4gTW9zdCBpbXBvcnRhbnRseSBJIHdhbnRlZCB0aGUgdGV4dA0KPiA+IGZyb20gVzNDIHJl dmlld2VkIGluIElFVEYgc2luY2UgaXQgd2FzIGNsZWFybHkgYSBuZXR3b3JrIHJlbGF0ZWQuDQo+ ID4gRnVydGhlcm1vcmUsIGFueWJvZHkgaW1wbGVtZW50aW5nIFdlYlJUQyBjb21wYXRpYmxlIFJU UCBhdWRpbw0KPiA+IGludGVyZmFjZSBzaG91bGQgbm90IG5lZWQgdG8gcmVhZCB0aGUgQVBJIGRv Y3VtZW50IHRvIGZpbmQgdGhlIG5ldHdvcmsNCj4gc3BlY2lmaWMgbGltaXRzLg0KPiA+DQo+ID4N Cj4gPg0KPiA+ICAgICBpaS0gVGhlIHJlYXNvbmFibGUgdmFsdWUgcmFuZ2UgY291bGQgZGVwZW5k IG9uIHRoZSBuZWdvdGlhdGVkIGNvZGVjDQo+ID4gICAgIGFuZCB0aGF0IHdvdWxkIGJlIGtub3du IGF0IHRoZSB0aW1lIG9mIGludGVyZXN0aW5nIHRoZSBkaWdpdHM7IHNvDQo+ID4gICAgIGFueXRo aW5nIHdpdGggTVVTVCBzdHJlbmd0aCBpcyB0b28gcmVzdHJpY3RpdmUgSU1ITy4NCj4gPg0KPiA+ DQo+ID4NCj4gPiBXZSBrbm93IHRoYXQgUkZDIDQ3MzMgd291bGQgYmUgdXNlZCB0byB0cmFuc21p dCBEVE1GIHRvbmVzIGZyb20NCj4gV2ViUlRDDQo+ID4gZW5kcG9pbnRzLiBSRkMgNDczMyBoYXMg bm8gdXBwZXIgb3IgbG93ZXIgbGltaXRzIG9uIHRvbmUgZHVyYXRpb24sIHNvDQo+ID4gdGVjaG5p Y2FsbHkgdGhlc2UgY2FuIGJlIHNldCB0byBhbnl0aGluZyBvciBub3Qgc2V0IGF0IGFsbC4gU29t ZQ0KPiA+IHBlb3BsZSBhcmd1ZSB0aGF0IHdlIHNob3VsZCBsaW1pdCBudW1iZXIgb2YgZm9vdCBn dW5zIGZvciBmdXR1cmUgQVBJDQo+ID4gdXNlcnMsIHNvIHRoZXkgd2FudGVkIHRvIGhhdmUgcmVh c29uYWJsZSB0b25lIGR1cmF0aW9uIGxpbWl0cy4NCj4gPg0KPiA+DQo+ID4NCj4gPiAgICAgaWlp LSBUaGUgcHJlc2VuY2Ugb2YgdHJhbnNjb2RpbmcvaW50ZXJ3b3JraW5nIChiZXR3ZWVuIGRpZmZl cmVudA0KPiA+ICAgICBmb3JtcyBvZiBkaWdpdCB0cmFuc2ZlcikgZGV2aWNlcyAodGhleSB3aWxs IGJlIHRoZXJlLCB3aGV0aGVyIHdlDQo+ID4gICAgIGxpa2UgaXQgb3Igbm90LCBmb3IgY2VydGFp biBzY2VuYXJpb3MpIG1ha2VzIGl0IGV2ZW4gbGVzcyBkZXNpcmFibGUNCj4gPiAgICAgdG8gaGF2 ZSBNVVNUIHN0cmVuZ3RoIG1hbmRhdGVzLg0KPiA+DQo+ID4NCj4gPg0KPiA+IFVuZm9ydHVuYXRl bHkgSSBzcGVuZCBhIHNpZ25pZmljYW50IGFtb3VudCBvZiBteSB0aW1lIGRlYWxpbmcgd2l0aA0K PiA+IHRyYW5zY29kaW5nIGVsZW1lbnRzIChTQkNzKSBkZWFsaW5nIHdpdGggUkZDIDQ3MzMgdG9u ZXMuIFNlbmRpbmcgdG9uZXMNCj4gPiB3aGljaCBhcmUgdG9vIHNob3J0IG9yIHNlbnQgYXQgaGln aCByYXRlcyBtYWtlIHN1Y2ggdHJhbnNjb2RpbmcNCj4gPiBlbGVtZW50cyBnZW5lcmF0ZSB1bmV4 cGVjdGVkIG9yIGJyb2tlbiBEVE1GIHNlcXVlbmNlcy4gUmVvcmRlcmVkIG9yDQo+ID4gaW50ZXJs ZWF2ZWQgdG9uZXMgYXJlIGNvbW1vbmx5IGdlbmVyYXRlZCBpbiByZXNwb25zZSB0byBzdWNoDQo+ ID4gc2VxdWVuY2VzLiBFeHRyZW1lbHkgbG9uZyBkdXJhdGlvbiBEVE1GIGRpZ2l0cyB0eXBpY2Fs bHkgYnJlYWsgaW50bw0KPiA+IHNldmVyYWwgZGlnaXRzLiBUaGVyZSBpcyBkYW5nZXIgaW4gbm90 IGhhdmluZyByZWFzb25hYmxlIGxpbWl0cy4gVGhlDQo+ID4gZGVjaXNpb24gaWYgQVBJIHVzZXJz IHNob3VsZCBiZSBwcm90ZWN0ZWQgZnJvbSB0aGlzIGRhbmdlciBpcyB1cCB0byB0aGlzDQo+IGdy b3VwLg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgICBpdi0gSSB0aGluayBhZGRpbmcgc29tZSB0ZXh0 IHJlZ2FyZGluZyBnYXAvZHVyYXRpb24gb2YgZGlnaXQgcGFja2V0cw0KPiA+ICAgICBjb3VsZCBi ZSBmaW5lIGJ1dCBJIHJhdGhlciB3b3VsZCBwcmVmZXIgaXQgd2l0aCDigJxyZWNvbW1lbmTigJ0g KGV2ZW4NCj4gPiAgICAgbm90IFJFQ09NTUVORCkgKGFuZCBwcm92aWRpbmcgc29tZSB2YWx1ZXMg b25seSBhcyBleGFtcGxlcykuDQo+ID4NCj4gPg0KPiA+DQo+ID4gSSBhZ3JlZSB0aGF0IGhhdmlu ZyByZWFzb25hYmxlIHJlY29tbWVuZGVkIHZhbHVlcyBzaG91bGQgYmUgc3VmZmljaWVudA0KPiA+ IGZvciBtb3N0IGNhc2VzLiBUaGUgZ3JvdXAgaGFzIHRvIGRlY2lkZSBpZiBpdCB3YW50cyB0byBw cm90ZWN0IHRoZQ0KPiA+IGRldmVsb3BlcnMgZnJvbSB0aGVtc2VsdmVzIGFuZCBzZXQgTVVTVCBs ZXZlbCBsaW1pdHMgb24gdG9uZSBhbmQgZ2FwDQo+ID4gZHVyYXRpb24uDQo+ID4NCj4gPiBfX19f X19fX19fX19fDQo+ID4gUm9tYW4gU2hwb3VudA0KPiA+DQo+ID4NCj4gPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QN CnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0KDQo= --_000_SN1PR0301MB1551C791B62BC7311DB3897CB2BA0SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhbSBub3Qgc3Vy ZSB3aGV0aGVyIDQwbXMgc2hvdWxkIGJlIGFic29sdXRlIG1pbmltdW0gZm9yIGFsbCBjb2RlY3Mu IEV2ZW4gZm9yIDYwMDBtcywgd2hvIGFtIEkgdG8gYXJndWUgdGhhdCBzb21lYm9keSBjYW7igJl0 IGNvbWUgdXAgd2l0aCBhIHVzZSBjYXNlL2FwcGxpY2F0aW9uLA0KIHdoaWNoIHJlcXVpcmVzIHNv bWV0aGluZyBsb25nZXIuIFNvLCBvdmVyYWxsLCBlbmZvcmNpbmcgZG9lcyBub3Qgc2VlbSB0byBi ZSB0aGUgcmlnaHQgdGhpbmcgSU1HTyAoZGVmYXVsdCB2YWx1ZSBpcyBmaW5lIGFzIGFscmVhZHkg aW5kaWNhdGVkKSAoYW5kIEkgZG9u4oCZdCBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50 IHRoYXQg4oCcdGhlIHBvaW50IG9mIG1pbi9tYXggaXMgcHJvbW90aW5nIHNhbmUgdmFsdWVz4oCd IGFzIHRoZSBtb2RlbCB5b3UNCiBhcmUgZGVzY3JpYmluZyBpcyAmbmJzcDvigJxlbmZvcmNpbmfi gJ0gYSByYW5nZSByYXRoZXIgdGhhbiBhIGRlZmF1bHQgdmFsdWUgaW4gYnJvd3Nlci9yZWNvbW1l bmRhdGlvbiBpbiB0aGUgc3BlY2lmaWNhdGlvbikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRvbGdhPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gVGVkIEhhcmRpZSBbbWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDI5LCAyMDE2IDE6MzYgUE08YnI+DQo8Yj5Ubzo8L2I+IEFz dmVyZW4sIFRvbGdhICZsdDt0YXN2ZXJlbkBzb251c25ldC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBIYXJhbGQgQWx2ZXN0cmFuZCAmbHQ7aGFyYWxkQGFsdmVzdHJhbmQubm8mZ3Q7OyBSb21hbiBT aHBvdW50ICZsdDtyb21hbkB0ZWx1cml4LmNvbSZndDs7IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gRndkOiBMYXN0IENhbGw6ICZsdDtkcmFmdC1pZXRm LXJ0Y3dlYi1hdWRpby0xMC50eHQmZ3Q7IChXZWJSVEMgQXVkaW8gQ29kZWMgYW5kIFByb2Nlc3Np bmcgUmVxdWlyZW1lbnRzKSB0byBQcm9wb3NlZCBTdGFuZGFyZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEZlYiAyOSwgMjAxNiBh dCAxMDoyOSBBTSwgQXN2ZXJlbiwgVG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0bzp0YXN2ZXJlbkBz b251c25ldC5jb20iIHRhcmdldD0iX2JsYW5rIj50YXN2ZXJlbkBzb251c25ldC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+VGhlcmUgb2J2aW91c2x5IGFyZSBzb21lIHZhbHVlcyB3aGljaCBhcmUgdW5yZWFzb25h YmxlIGJ1dCB1c2luZyBzYW5lIHZhbHVlcyBzaG91bGQgYmUgZHJpdmVuIGJ5IHRoZQ0KIGFwcGxp Y2F0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+T2theSwgYnV0IHRoZSBwb2ludCBvZiB0aGUgbWF4ICg2MDAwbXMpIGFuZCBtaW4gKDQw bXMpIGlzIGV4YWN0bHkgdGhhdC0tdG8gbWFrZSBhIGNvbW1vbiBzdGF0ZW1lbnQgYWJvdXQgd2hh dCByYW5nZSBpcyBzYW5lIGluIHRoaXMgY29udGV4dC4mbmJzcDsgV2l0aG91dCB0aGF0LCB0aGVy ZSB3b3VsZCBoYXZlIHRvIGJlIEFQSSBzdXJmYWNlIGZvciBkaXNjb3ZlcmluZw0KIHdoYXQgd2Fz IGNvbnNpZGVyZWQgc2FuZTsgYXMgSGFyYWxkIHBvaW50ZWQgb3V0LCB0aGF0J3MgZ29pbmcgdG8g Z2V0IGxpdHRsZSB1c2UgZm9yIHRoZSBjb21wbGljYXRpb24gaXQgYWRkcy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+RG8geW91IGRpc2FncmVlIHRoYXQgdGhlc2UgYXJlIHNhbmUgdmFsdWVzIGZv ciBhIGJvdW5kIHRvIHRoZSByYW5nZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+cmVnYXJkcyw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRlZDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi4g QnJvd3NlcnMgc3RpbGwgY2FuIHN1cHBvcnQgc29tZSBkZWZhdWx0IHZhbHVlcyDigJN0byBiZSB1 c2VkIGlmIGFwcGxpY2F0aW9uIGRvZXMgbm90IHN1cHBseSBhbnkgdmFsdWUtLA0KIGJldHRlciBi YXNlZCBvbiB0aGUgbmVnb3RpYXRlZCBjb2RlYywgZm9yIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMs IHdobyBhcmUgbm90IHNhdnZ5IGVub3VnaCB0byBwaWNrIGEgdmFsdWUuIE9UT0gsIHdoYXQgSSBh bSBhcmd1aW5nIGFnYWluc3QgaXMgYnJvd3NlcnMgKjxiPmVuZm9yY2luZzwvYj4qIGNlcnRhaW4g bGltaXRzIGFuZCBydGN3ZWItYXVkaW8gc3BlY2lmaWNhdGlvbiBtYW5kYXRpbmcgbGltaXRzLg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRvbGdhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRlZCBIYXJkaWUgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86dGVkLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGVk LmlldGZAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5 IDI5LCAyMDE2IDEyOjIyIFBNPGJyPg0KPGI+VG86PC9iPiBBc3ZlcmVuLCBUb2xnYSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRhc3Zl cmVuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBIYXJhbGQgQWx2ZXN0cmFu ZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vIiB0YXJnZXQ9Il9ibGFu ayI+aGFyYWxkQGFsdmVzdHJhbmQubm88L2E+Jmd0OzsgUm9tYW4gU2hwb3VudCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFuayI+cm9tYW5AdGVsdXJp eC5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFty dGN3ZWJdIEZ3ZDogTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtaWV0Zi1ydGN3ZWItYXVkaW8tMTAudHh0 Jmd0OyAoV2ViUlRDIEF1ZGlvIENvZGVjIGFuZCBQcm9jZXNzaW5nIFJlcXVpcmVtZW50cykgdG8g UHJvcG9zZWQgU3RhbmRhcmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU2F0LCBGZWIgMjcs IDIwMTYgYXQgODozMiBBTSwgQXN2ZXJlbiwgVG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0bzp0YXN2 ZXJlbkBzb251c25ldC5jb20iIHRhcmdldD0iX2JsYW5rIj50YXN2ZXJlbkBzb251c25ldC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkkgZG9u4oCZdCB0aGluayBicm93c2VycyBzaG91bGQgYmUgZW5mb3JjaW5nICphbnkqIGxp bWl0YXRpb25zLiBJdCBzaG91bGQgYmUgdXAgdG8gdGhlIGFwcGxpY2F0aW9uIGRldmVsb3BlciB0 byBkZWNpZGUgd2hhdCB2YWx1ZXMgdG8gdXNlLg0KPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U28gYSB0b25lIG9mIDIgaG91 cnMgZHVyYXRpb24gaXMgb2theT8mbmJzcDsgVGhhdCBzZWVtcyBwcmV0dHkgbGlrZWx5IHRvIHRy aWdnZXIgdGhlICZxdW90O211bHRpcGxlIGRpZ2l0cyZxdW90OyBpc3N1ZSB0aGF0IFJvbWFuIHBv aW50ZWQgb3V0IGZvciBTQkNzLCBmb3Igb25lIHRoaW5nLjxicj4NCjxicj4NCkhhcmFsZCdzIHBv aW50IGlzIHRoYXQgdGhlcmUgYXJlIHNvbWUgY2xlYXJseSBzaWxseSBwb3NzaWJpbGl0aWVzIG91 dCB0aGVyZSwgc28gc29tZSBsaW1pdGF0aW9uIHdpbGwgYmUgdGhlcmUgKDEgaG91ciwgMyBtaW51 dGVzLCA2MDAwbXMpIGFuZCB0aGF0IHByb2JpbmcgZm9yIHdoYXQgYW4gaW1wbGVtZW50YXRpb24g aGFzIGNob3NlbiBpcyBtdWNoIG1vcmUgY29tcGxpY2F0ZWQgaGVyZSB0aGFuIG1ha2VzIHNlbnNl LiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhpcyB3b3Vs ZCBzb2x2ZSB0aGUgcHJvYmxlbSBhbmQgaXMgdGhlIHJpZ2h0IGFwcHJvYWNoIGFueWhvdyBJTUhP LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ Jm5ic3A7V2l0aG91dCBhbnkgaGF0cyBvbiwgSSB0aGluayB0aGlzIGlzIHByZXR0eSB1bmxpa2Vs eSB3b3JrIG91dCB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0Ij5UZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5r cyw8YnI+DQpUb2xnYTxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQomZ3Q7IEZyb206IEhhcmFsZCBBbHZlc3RyYW5kIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv OmhhcmFsZEBhbHZlc3RyYW5kLm5vIiB0YXJnZXQ9Il9ibGFuayI+aGFyYWxkQGFsdmVzdHJhbmQu bm88L2E+XTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZndDsgU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDI3LCAyMDE2IDg6MTEgQU08YnI+DQom Z3Q7IFRvOiBBc3ZlcmVuLCBUb2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVz bmV0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7OyBS b21hbiBTaHBvdW50PGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXgu Y29tIiB0YXJnZXQ9Il9ibGFuayI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0Ozxicj4NCiZndDsg Q2M6IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3 ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRndkOiBMYXN0 IENhbGw6ICZsdDtkcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpby0xMC50eHQmZ3Q7PGJyPg0KJmd0OyAo V2ViUlRDIEF1ZGlvIENvZGVjIGFuZCBQcm9jZXNzaW5nIFJlcXVpcmVtZW50cykgdG8gUHJvcG9z ZWQgU3RhbmRhcmQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBEZW4gMjcuIGZlYi4gMjAxNiAxMTo0NSwg c2tyZXYgQXN2ZXJlbiwgVG9sZ2E6PGJyPg0KJmd0OyAmZ3Q7IElmIEkgZG9u4oCZdCBtaXMvb3Zl ci1pbnRlcnByZXQgUm9tYW7igJlzIGFuc3dlciwgaXQgc2VlbXMgbGlrZSBhdCBsZWFzdDxicj4N CiZndDsgJmd0OyBzb21lIHBlb3BsZSB3aG8gcmVhbGx5IGNhcmUvaGF2ZSBwcmFjdGljYWwgZXhw ZXJpZW5jZSBhYm91dCB0aGlzPGJyPg0KJmd0OyAmZ3Q7IGlzc3VlLCBlLmcuIFJvbWFuIGFuZCBt eXNlbGYsIGFyZSBpbiBmYXZvciBvZiBub3QgbWFuZGF0aW5nIGFueSB2YWx1ZXM8YnI+DQomZ3Q7 ICZndDsgYW5kIHN1Z2dlc3RpbmcgdGhhdCB3M29yZyBzcGVjaWZpY2F0aW9uIGlzIHVwZGF0ZWQg YWNjb3JkaW5nbHkuIEk8YnI+DQomZ3Q7ICZndDsgcGVyc29uYWxseSB3b3VsZCBwcmVmZXIgbm90 aGluZyBtb3JlIHRoYW4gYSAob3IgdHdvKSBzZW50ZW5jZSBhcyBhPGJyPg0KJmd0OyAmZ3Q7IHdh cm5pbmcgd2l0aG91dCB1c2luZyBhbnkga2V5d29yZHMgaW4gcnRjd2ViLWF1ZGlvLiBEb2VzIHRo aXMgc291bmQgYTxicj4NCiZndDsgJmd0OyByZWFzb25hYmxlIGNob2ljZSB0byBvdGhlciBmb2xr cz88YnI+DQomZ3Q7PGJyPg0KJmd0OyBBdCB0aGUgV0VCUlRDIEFQSSwgdGhpcyAqd2lsbCogbGVh ZCB0byBub25pbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucyw8YnI+DQomZ3Q7IHNpbmNlIHNv bWUgYnJvd3NlcnMgd2lsbCBlbmZvcmNlIGRpZmZlcmVudCBsaW1pdHMgZnJvbSBvdGhlciBicm93 c2Vycy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJdCdzIGFsbCBjb21pbmcgYmFjayBub3cgLSB3ZSBk ZWNpZGVkIHRvIGdvIHdpdGggZml4ZWQgbGltaXRzIGluIHRoZSBzcGVjPGJyPg0KJmd0OyBiZWNh dXNlIGl0IHdhcyBpbmNvbmNpZXZhYmxlIHRoYXQgaW1wbGVtZW50YXRpb25zIHdvdWxkbid0IGlt cG9zZTxicj4NCiZndDsgKnNvbWUqIGxpbWl0cywgYW5kIHRoZSBpZGVhIG9mIGFkZGluZyBBUEkg c3VyZmFjZSBmb3IgcHJvYmluZyB3aGF0IHRoZSBsaW1pdHM8YnI+DQomZ3Q7IHdlcmUgd2FzIGp1 c3QgdG9vIGdyb3NzIGZvciBzdWNoIGEgbG93LXZhbHVlIChyZWxhdGl2ZWx5PGJyPg0KJmd0OyBz cGVha2luZykgZmVhdHVyZS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGFua3MsPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRvbGdhPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICpGcm9tOipSb21hbiBTaHBvdW50IFttYWls dG86PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFuayI+cm9t YW5AdGVsdXJpeC5jb208L2E+XTxicj4NCiZndDsgJmd0OyAqU2VudDoqIEZyaWRheSwgRmVicnVh cnkgMjYsIDIwMTYgNDo1NiBQTTxicj4NCiZndDsgJmd0OyAqVG86KiBBc3ZlcmVuLCBUb2xnYSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICpDYzoqIEhhcmFs ZCBBbHZlc3RyYW5kICZsdDs8YSBocmVmPSJtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8iIHRh cmdldD0iX2JsYW5rIj5oYXJhbGRAYWx2ZXN0cmFuZC5ubzwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48 YnI+DQomZ3Q7ICZndDsgKlN1YmplY3Q6KiBSZTogW3J0Y3dlYl0gRndkOiBMYXN0IENhbGw6PGJy Pg0KJmd0OyAmZ3Q7ICZsdDtkcmFmdC1pZXRmLXJ0Y3dlYi1hdWRpby0xMC50eHQmZ3Q7IChXZWJS VEMgQXVkaW8gQ29kZWMgYW5kIFByb2Nlc3Npbmc8YnI+DQomZ3Q7ICZndDsgUmVxdWlyZW1lbnRz KSB0byBQcm9wb3NlZCBTdGFuZGFyZDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPbiBGcmksIEZlYiAyNiwgMjAxNiBhdCA2OjE5IEFN LCBBc3ZlcmVuLCBUb2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvYT48YnI+DQomZ3Q7ICZn dDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7aS0gSSB0aGluayB3 M29yZyBzaG91bGQgaGF2ZSBmb2xsb3dlZCB0aGUgbGVhZCBvZiBJRVRGIGluIHRoaXMgaXNzdWU8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3JhdGhlciB0aGFuIHRoZSBvdGhlciB3 YXkgYXJvdW5kLCBpLmUuIHRoZSB2YWx1ZXMgcmVjb21tZW5kZWQgYnkgdGhlPGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtJRVRGIHNwZWNpZmljYXRpb24gc2hvdWxkIGhhdmUgYmVl biBjaXRlZCBpbiB0aGUgdzNvcmcgZG9jdW1lbnQgSU1ITy48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSSBhZ3JlZSBjb21wbGV0ZWx5 LiBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSUVURiBkb2N1bWVudCB0aGF0IGRlZmluZXM8YnI+DQom Z3Q7ICZndDsgRFRNRiBvciBSRkMgNDczMyB0b25lIGR1cmF0aW9uIGxpbWl0cywgc28gSSBwcm9w b3NlZCB0byBhZGQgdGhlc2U8YnI+DQomZ3Q7ICZndDsgbGltaXRzIHRvIGRyYWZ0LWlldGYtcnRj d2ViLWF1ZGlvLiBNb3N0IGltcG9ydGFudGx5IEkgd2FudGVkIHRoZSB0ZXh0PGJyPg0KJmd0OyAm Z3Q7IGZyb20gVzNDIHJldmlld2VkIGluIElFVEYgc2luY2UgaXQgd2FzIGNsZWFybHkgYSBuZXR3 b3JrIHJlbGF0ZWQuPGJyPg0KJmd0OyAmZ3Q7IEZ1cnRoZXJtb3JlLCBhbnlib2R5IGltcGxlbWVu dGluZyBXZWJSVEMgY29tcGF0aWJsZSBSVFAgYXVkaW88YnI+DQomZ3Q7ICZndDsgaW50ZXJmYWNl IHNob3VsZCBub3QgbmVlZCB0byByZWFkIHRoZSBBUEkgZG9jdW1lbnQgdG8gZmluZCB0aGUgbmV0 d29yazxicj4NCiZndDsgc3BlY2lmaWMgbGltaXRzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7aWkt IFRoZSByZWFzb25hYmxlIHZhbHVlIHJhbmdlIGNvdWxkIGRlcGVuZCBvbiB0aGUgbmVnb3RpYXRl ZCBjb2RlYzxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7YW5kIHRoYXQgd291bGQg YmUga25vd24gYXQgdGhlIHRpbWUgb2YgaW50ZXJlc3RpbmcgdGhlIGRpZ2l0czsgc288YnI+DQom Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2FueXRoaW5nIHdpdGggTVVTVCBzdHJlbmd0aCBp cyB0b28gcmVzdHJpY3RpdmUgSU1ITy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgV2Uga25vdyB0aGF0IFJGQyA0NzMzIHdvdWxkIGJl IHVzZWQgdG8gdHJhbnNtaXQgRFRNRiB0b25lcyBmcm9tPGJyPg0KJmd0OyBXZWJSVEM8YnI+DQom Z3Q7ICZndDsgZW5kcG9pbnRzLiBSRkMgNDczMyBoYXMgbm8gdXBwZXIgb3IgbG93ZXIgbGltaXRz IG9uIHRvbmUgZHVyYXRpb24sIHNvPGJyPg0KJmd0OyAmZ3Q7IHRlY2huaWNhbGx5IHRoZXNlIGNh biBiZSBzZXQgdG8gYW55dGhpbmcgb3Igbm90IHNldCBhdCBhbGwuIFNvbWU8YnI+DQomZ3Q7ICZn dDsgcGVvcGxlIGFyZ3VlIHRoYXQgd2Ugc2hvdWxkIGxpbWl0IG51bWJlciBvZiBmb290IGd1bnMg Zm9yIGZ1dHVyZSBBUEk8YnI+DQomZ3Q7ICZndDsgdXNlcnMsIHNvIHRoZXkgd2FudGVkIHRvIGhh dmUgcmVhc29uYWJsZSB0b25lIGR1cmF0aW9uIGxpbWl0cy48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw O2lpaS0gVGhlIHByZXNlbmNlIG9mIHRyYW5zY29kaW5nL2ludGVyd29ya2luZyAoYmV0d2VlbiBk aWZmZXJlbnQ8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2Zvcm1zIG9mIGRpZ2l0 IHRyYW5zZmVyKSBkZXZpY2VzICh0aGV5IHdpbGwgYmUgdGhlcmUsIHdoZXRoZXIgd2U8YnI+DQom Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2xpa2UgaXQgb3Igbm90LCBmb3IgY2VydGFpbiBz Y2VuYXJpb3MpIG1ha2VzIGl0IGV2ZW4gbGVzcyBkZXNpcmFibGU8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJm5ic3A7ICZuYnNwO3RvIGhhdmUgTVVTVCBzdHJlbmd0aCBtYW5kYXRlcy48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVW5mb3J0 dW5hdGVseSBJIHNwZW5kIGEgc2lnbmlmaWNhbnQgYW1vdW50IG9mIG15IHRpbWUgZGVhbGluZyB3 aXRoPGJyPg0KJmd0OyAmZ3Q7IHRyYW5zY29kaW5nIGVsZW1lbnRzIChTQkNzKSBkZWFsaW5nIHdp dGggUkZDIDQ3MzMgdG9uZXMuIFNlbmRpbmcgdG9uZXM8YnI+DQomZ3Q7ICZndDsgd2hpY2ggYXJl IHRvbyBzaG9ydCBvciBzZW50IGF0IGhpZ2ggcmF0ZXMgbWFrZSBzdWNoIHRyYW5zY29kaW5nPGJy Pg0KJmd0OyAmZ3Q7IGVsZW1lbnRzIGdlbmVyYXRlIHVuZXhwZWN0ZWQgb3IgYnJva2VuIERUTUYg c2VxdWVuY2VzLiBSZW9yZGVyZWQgb3I8YnI+DQomZ3Q7ICZndDsgaW50ZXJsZWF2ZWQgdG9uZXMg YXJlIGNvbW1vbmx5IGdlbmVyYXRlZCBpbiByZXNwb25zZSB0byBzdWNoPGJyPg0KJmd0OyAmZ3Q7 IHNlcXVlbmNlcy4gRXh0cmVtZWx5IGxvbmcgZHVyYXRpb24gRFRNRiBkaWdpdHMgdHlwaWNhbGx5 IGJyZWFrIGludG88YnI+DQomZ3Q7ICZndDsgc2V2ZXJhbCBkaWdpdHMuIFRoZXJlIGlzIGRhbmdl ciBpbiBub3QgaGF2aW5nIHJlYXNvbmFibGUgbGltaXRzLiBUaGU8YnI+DQomZ3Q7ICZndDsgZGVj aXNpb24gaWYgQVBJIHVzZXJzIHNob3VsZCBiZSBwcm90ZWN0ZWQgZnJvbSB0aGlzIGRhbmdlciBp cyB1cCB0byB0aGlzPGJyPg0KJmd0OyBncm91cC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2l2LSBJ IHRoaW5rIGFkZGluZyBzb21lIHRleHQgcmVnYXJkaW5nIGdhcC9kdXJhdGlvbiBvZiBkaWdpdCBw YWNrZXRzPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtjb3VsZCBiZSBmaW5lIGJ1 dCBJIHJhdGhlciB3b3VsZCBwcmVmZXIgaXQgd2l0aCDigJxyZWNvbW1lbmTigJ0gKGV2ZW48YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO25vdCBSRUNPTU1FTkQpIChhbmQgcHJvdmlk aW5nIHNvbWUgdmFsdWVzIG9ubHkgYXMgZXhhbXBsZXMpLjxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJIGFncmVlIHRoYXQgaGF2aW5n IHJlYXNvbmFibGUgcmVjb21tZW5kZWQgdmFsdWVzIHNob3VsZCBiZSBzdWZmaWNpZW50PGJyPg0K Jmd0OyAmZ3Q7IGZvciBtb3N0IGNhc2VzLiBUaGUgZ3JvdXAgaGFzIHRvIGRlY2lkZSBpZiBpdCB3 YW50cyB0byBwcm90ZWN0IHRoZTxicj4NCiZndDsgJmd0OyBkZXZlbG9wZXJzIGZyb20gdGhlbXNl bHZlcyBhbmQgc2V0IE1VU1QgbGV2ZWwgbGltaXRzIG9uIHRvbmUgYW5kIGdhcDxicj4NCiZndDsg Jmd0OyBkdXJhdGlvbi48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19f Xzxicj4NCiZndDsgJmd0OyBSb21hbiBTaHBvdW50PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl YiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR0301MB1551C791B62BC7311DB3897CB2BA0SN1PR0301MB1551_-- From nobody Mon Feb 29 11:07:35 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4561B3A25 for ; Mon, 29 Feb 2016 11:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG-6nFL1SaUe for ; Mon, 29 Feb 2016 11:07:29 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A94D1B3A22 for ; Mon, 29 Feb 2016 11:07:29 -0800 (PST) Received: by mail-qg0-x231.google.com with SMTP id y89so123413623qge.2 for ; Mon, 29 Feb 2016 11:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HPDqudLvPHFS2aNUefGs5Sqz9l1AjlMpxzdxYhYfP7k=; b=uDzJuZ0R8CmFdD92K157UQsVrpk9YT4OlqbHuzAzxg2xjWC6HYf2B8RDKQvq6WI6yd Ms3WG6Wxu1uhDxKbnezfhpEqALvRO0CRxSerKTjIi5Es6zxL37s/uarjrQ8eDhuaNmW8 cHh/ZR0cNaT8FRUWVsbNk/QJuVJ9hOWPnn/VHMwTS5xjm0uUYkris3KhJ9A6ty6tNc/O YH2XQ6qrSyIkR3W51PAhMSNBlrswrh0JbW0xgveWG07Q75TONQj6o3tTZrzOlNodS59o 4nvDKU+hhLWfXWSfpBJFyZURYZO+q1rafZoqHqcKUXxqstkWBWfashWZYQndSABhTOvP xpgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HPDqudLvPHFS2aNUefGs5Sqz9l1AjlMpxzdxYhYfP7k=; b=e2/pW1MMrP20F7P7F+/1DCgOx5Ef18o7xENS7tVXdgKVz2GW1yKNaH51kIPV5zIbtL UrmbHyNdnYnEUgu0hzRI/S3DqB/LaOXf4PZ9VLdYD1J1RH7jjpkD+ngYOKWqShYzYXk/ hOosHc6s6EjSYxa6u/YrOpQh6nAKj1IZ4FLOyUtBSdj7uBtu6+G47904vQMDLgZAsXPS Ze0egjTi3KeJlDz+26zM4GpjLbZlztKvFLGNPms+VPZq9qGHTad/8VKfwqgVYEnGt4nS ZbixwfLf7BLEZdf/nGPj+I9Nh7LkLmb3m8GQC0g9jxrAC0/Fa6gBD/Qmw5MhG7LmAl56 NJxQ== X-Gm-Message-State: AD7BkJLvpqyRUDehYbu3GOVvRblF7pYiME27/l/rXuk3EV8vYtk8FNKQ1iiXWe5hkdOszRJTpS1xslB4FNLPTA== X-Received: by 10.140.100.244 with SMTP id s107mr20837391qge.19.1456772848472; Mon, 29 Feb 2016 11:07:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.6.13 with HTTP; Mon, 29 Feb 2016 11:07:08 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> <56D1A080.7050901@alvestrand.no> From: Ted Hardie Date: Mon, 29 Feb 2016 11:07:08 -0800 Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a1134f50426e619052ced5c1a Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 19:07:33 -0000 --001a1134f50426e619052ced5c1a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 29, 2016 at 10:42 AM, Asveren, Tolga wrote: > I am not sure whether 40ms should be absolute minimum for all codecs. Eve= n > for 6000ms, who am I to argue that somebody can=E2=80=99t come up with a = use > case/application, which requires something longer. So, overall, enforcing > does not seem to be the right thing IMGO (default value is fine as alread= y > indicated) (and I don=E2=80=99t fully agree with your statement that =E2= =80=9Cthe point of > min/max is promoting sane values=E2=80=9D as the model you are describing= is > =E2=80=9Cenforcing=E2=80=9D a range rather than a default value in brows= er/recommendation > in the specification). > > > So, to put this in RFC 2119 terms, you believe these values should be at SHOULD strength rather than MUST? If that were the case but there were no API surface to determine whether an implementation supported other values, what, exactly would happen. Ted > Thanks, > > Tolga > > > > *From:* Ted Hardie [mailto:ted.ietf@gmail.com] > *Sent:* Monday, February 29, 2016 1:36 PM > > *To:* Asveren, Tolga > *Cc:* Harald Alvestrand ; Roman Shpount < > roman@telurix.com>; rtcweb@ietf.org > *Subject:* Re: [rtcweb] Fwd: Last Call: > (WebRTC Audio Codec and Processing Requirements) to Proposed Standard > > > > On Mon, Feb 29, 2016 at 10:29 AM, Asveren, Tolga > wrote: > > There obviously are some values which are unreasonable but using sane > values should be driven by the application > > > > Okay, but the point of the max (6000ms) and min (40ms) is exactly that--t= o > make a common statement about what range is sane in this context. Withou= t > that, there would have to be API surface for discovering what was > considered sane; as Harald pointed out, that's going to get little use fo= r > the complication it adds. > > Do you disagree that these are sane values for a bound to the range? > > regards, > > Ted > > > > > . Browsers still can support some default values =E2=80=93to be used if > application does not supply any value-, better based on the negotiated > codec, for application developers, who are not savvy enough to pick a > value. OTOH, what I am arguing against is browsers **enforcing** certain > limits and rtcweb-audio specification mandating limits. > > > > Thanks, > > Tolga > > > > *From:* Ted Hardie [mailto:ted.ietf@gmail.com] > *Sent:* Monday, February 29, 2016 12:22 PM > *To:* Asveren, Tolga > *Cc:* Harald Alvestrand ; Roman Shpount < > roman@telurix.com>; rtcweb@ietf.org > > > *Subject:* Re: [rtcweb] Fwd: Last Call: > (WebRTC Audio Codec and Processing Requirements) to Proposed Standard > > > > On Sat, Feb 27, 2016 at 8:32 AM, Asveren, Tolga > wrote: > > I don=E2=80=99t think browsers should be enforcing *any* limitations. It = should be > up to the application developer to decide what values to use. > > > > So a tone of 2 hours duration is okay? That seems pretty likely to > trigger the "multiple digits" issue that Roman pointed out for SBCs, for > one thing. > > Harald's point is that there are some clearly silly possibilities out > there, so some limitation will be there (1 hour, 3 minutes, 6000ms) and > that probing for what an implementation has chosen is much more complicat= ed > here than makes sense. > > > > This would solve the problem and is the right approach anyhow IMHO. > > Without any hats on, I think this is pretty unlikely work out well. > > Ted > > Thanks, > Tolga > > > -----Original Message----- > > From: Harald Alvestrand [mailto:harald@alvestrand.no] > > > Sent: Saturday, February 27, 2016 8:11 AM > > To: Asveren, Tolga ; Roman Shpount > > > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] Fwd: Last Call: > > (WebRTC Audio Codec and Processing Requirements) to Proposed Standard > > > > Den 27. feb. 2016 11:45, skrev Asveren, Tolga: > > > If I don=E2=80=99t mis/over-interpret Roman=E2=80=99s answer, it seem= s like at least > > > some people who really care/have practical experience about this > > > issue, e.g. Roman and myself, are in favor of not mandating any value= s > > > and suggesting that w3org specification is updated accordingly. I > > > personally would prefer nothing more than a (or two) sentence as a > > > warning without using any keywords in rtcweb-audio. Does this sound a > > > reasonable choice to other folks? > > > > At the WEBRTC API, this *will* lead to noninteroperable implementations= , > > since some browsers will enforce different limits from other browsers. > > > > It's all coming back now - we decided to go with fixed limits in the sp= ec > > because it was inconcievable that implementations wouldn't impose > > *some* limits, and the idea of adding API surface for probing what the > limits > > were was just too gross for such a low-value (relatively > > speaking) feature. > > > > > > > > > > > > > > > > Thanks, > > > > > > Tolga > > > > > > > > > > > > *From:*Roman Shpount [mailto:roman@telurix.com] > > > *Sent:* Friday, February 26, 2016 4:56 PM > > > *To:* Asveren, Tolga > > > *Cc:* Harald Alvestrand ; rtcweb@ietf.org > > > *Subject:* Re: [rtcweb] Fwd: Last Call: > > > (WebRTC Audio Codec and Processing > > > Requirements) to Proposed Standard > > > > > > > > > > > > On Fri, Feb 26, 2016 at 6:19 AM, Asveren, Tolga > > > wrote: > > > > > > i- I think w3org should have followed the lead of IETF in this > issue > > > rather than the other way around, i.e. the values recommended by > the > > > IETF specification should have been cited in the w3org document > IMHO. > > > > > > > > > > > > I agree completely. I am not aware of any IETF document that defines > > > DTMF or RFC 4733 tone duration limits, so I proposed to add these > > > limits to draft-ietf-rtcweb-audio. Most importantly I wanted the text > > > from W3C reviewed in IETF since it was clearly a network related. > > > Furthermore, anybody implementing WebRTC compatible RTP audio > > > interface should not need to read the API document to find the networ= k > > specific limits. > > > > > > > > > > > > ii- The reasonable value range could depend on the negotiated cod= ec > > > and that would be known at the time of interesting the digits; so > > > anything with MUST strength is too restrictive IMHO. > > > > > > > > > > > > We know that RFC 4733 would be used to transmit DTMF tones from > > WebRTC > > > endpoints. RFC 4733 has no upper or lower limits on tone duration, so > > > technically these can be set to anything or not set at all. Some > > > people argue that we should limit number of foot guns for future API > > > users, so they wanted to have reasonable tone duration limits. > > > > > > > > > > > > iii- The presence of transcoding/interworking (between different > > > forms of digit transfer) devices (they will be there, whether we > > > like it or not, for certain scenarios) makes it even less desirab= le > > > to have MUST strength mandates. > > > > > > > > > > > > Unfortunately I spend a significant amount of my time dealing with > > > transcoding elements (SBCs) dealing with RFC 4733 tones. Sending tone= s > > > which are too short or sent at high rates make such transcoding > > > elements generate unexpected or broken DTMF sequences. Reordered or > > > interleaved tones are commonly generated in response to such > > > sequences. Extremely long duration DTMF digits typically break into > > > several digits. There is danger in not having reasonable limits. The > > > decision if API users should be protected from this danger is up to > this > > group. > > > > > > > > > > > > iv- I think adding some text regarding gap/duration of digit > packets > > > could be fine but I rather would prefer it with =E2=80=9Crecommen= d=E2=80=9D (even > > > not RECOMMEND) (and providing some values only as examples). > > > > > > > > > > > > I agree that having reasonable recommended values should be sufficien= t > > > for most cases. The group has to decide if it wants to protect the > > > developers from themselves and set MUST level limits on tone and gap > > > duration. > > > > > > _____________ > > > Roman Shpount > > > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > --001a1134f50426e619052ced5c1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 29, 2016 at 10:42 AM, Asveren, Tolga <tas= veren@sonusnet.com> wrote:

I am not sure whether 40ms should be = absolute minimum for all codecs. Even for 6000ms, who am I to argue that so= mebody can=E2=80=99t come up with a use case/application, which requires something longer. So, overall, enforcing does not seem to b= e the right thing IMGO (default value is fine as already indicated) (and I = don=E2=80=99t fully agree with your statement that =E2=80=9Cthe point of mi= n/max is promoting sane values=E2=80=9D as the model you are describing is =C2=A0=E2=80=9Cenforcing=E2=80=9D a range rather than a = default value in browser/recommendation in the specification).

=C2=A0

<= /blockquote>
So, to put this in RFC 2119 terms, you believe these value= s should be at SHOULD strength rather than MUST?=C2=A0 If that were the cas= e but there were no API surface to determine whether an implementation supp= orted other values, what, exactly would happen.

Ted

=C2=A0

=

Thanks,

Tolga

=C2=A0

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Monday, February 29, 2016 1:36 PM


To: Asveren, Tolga <tasveren@sonusnet.com>
Cc: Harald Alvestrand <harald@alvestrand.no>; Roman Shpount <roman@telurix.com>; rtcweb@ietf.org
Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10= .txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Stand= ard

=C2=A0

On Mon, Feb 29, 2016 at 10:29 AM, Asveren, Tolga <= ;tasveren@sonusn= et.com> wrote:

There obviously are some values which= are unreasonable but using sane values should be driven by the application

=C2=A0

Okay, but the point o= f the max (6000ms) and min (40ms) is exactly that--to make a common stateme= nt about what range is sane in this context.=C2=A0 Without that, there woul= d have to be API surface for discovering what was considered sane; as Harald pointed out, that's going to get l= ittle use for the complication it adds.

Do you disagree that = these are sane values for a bound to the range?

regards,

Ted


=C2=A0

. Browsers still can support some def= ault values =E2=80=93to be used if application does not supply any value-, better based on the negotiated codec, for application developers, who are = not savvy enough to pick a value. OTOH, what I am arguing against is browse= rs *enforcing* certain limits and rtcweb-audio specification mandati= ng limits.

=C2=A0

Thanks,

Tolga

=C2=A0

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Monday, February 29, 2016 12:22 PM
To: Asveren, Tolga <tasveren@sonusnet.com>
Cc: Harald Alvestrand <harald@alvestrand.no>; Roman Shpount <roman@telurix.com>; rtcweb@ietf.org


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

=C2=A0

On Sat, Feb 27, 2016 at 8:32 AM, Asveren, Tolga <= tasveren@sonusne= t.com> wrote:

I don=E2=80=99t think browsers should be enforcing *= any* limitations. It should be up to the application developer to decide wh= at values to use.

=C2=A0

So a tone of 2 hours duration is okay?=C2=A0 That se= ems pretty likely to trigger the "multiple digits" issue that Rom= an pointed out for SBCs, for one thing.

Harald's point is that there are some clearly silly possibilities out t= here, so some limitation will be there (1 hour, 3 minutes, 6000ms) and that= probing for what an implementation has chosen is much more complicated her= e than makes sense.=C2=A0

=C2=A0

This would solve the = problem and is the right approach anyhow IMHO.

=C2=A0Without any hat= s on, I think this is pretty unlikely work out well.

Ted

Thanks,
Tolga

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]

> Sent: Saturday, February 27, 2016 8:11 AM
> To: Asveren, Tolga <tasveren@sonusnet.com>; Roman Shpount
> <roman@telur= ix.com>
> Cc: rtcweb@ietf.o= rg
> Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10.t= xt>
> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard<= br> >
> Den 27. feb. 2016 11:45, skrev Asveren, Tolga:
> > If I don=E2=80=99t mis/over-interpret Roman=E2=80=99s answer, it = seems like at least
> > some people who really care/have practical experience about this<= br> > > issue, e.g. Roman and myself, are in favor of not mandating any v= alues
> > and suggesting that w3org specification is updated accordingly. I=
> > personally would prefer nothing more than a (or two) sentence as = a
> > warning without using any keywords in rtcweb-audio. Does this sou= nd a
> > reasonable choice to other folks?
>
> At the WEBRTC API, this *will* lead to noninteroperable implementation= s,
> since some browsers will enforce different limits from other browsers.=
>
> It's all coming back now - we decided to go with fixed limits in t= he spec
> because it was inconcievable that implementations wouldn't impose<= br> > *some* limits, and the idea of adding API surface for probing what the= limits
> were was just too gross for such a low-value (relatively
> speaking) feature.
>
>
> >
> >
> >
> > Thanks,
> >
> > Tolga
> >
> >
> >
> > *From:*Roman Shpount [mailto:roman@telurix.com]
> > *Sent:* Friday, February 26, 2016 4:56 PM
> > *To:* Asveren, Tolga <tasveren@sonusnet.com>
> > *Cc:* Harald Alvestrand <harald@alvestrand.no>; rtcweb@ietf.org > > *Subject:* Re: [rtcweb] Fwd: Last Call:
> > <draft-ietf-rtcweb-audio-10.txt> (WebRTC Audio Codec and Pr= ocessing
> > Requirements) to Proposed Standard
> >
> >
> >
> > On Fri, Feb 26, 2016 at 6:19 AM, Asveren, Tolga <tasveren@sonusnet.com
> > <mailto:tasveren@sonusnet.com>> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0i- I think w3org should have followed the lead= of IETF in this issue
> >=C2=A0 =C2=A0 =C2=A0rather than the other way around, i.e. the val= ues recommended by the
> >=C2=A0 =C2=A0 =C2=A0IETF specification should have been cited in t= he w3org document IMHO.
> >
> >
> >
> > I agree completely. I am not aware of any IETF document that defi= nes
> > DTMF or RFC 4733 tone duration limits, so I proposed to add these=
> > limits to draft-ietf-rtcweb-audio. Most importantly I wanted the = text
> > from W3C reviewed in IETF since it was clearly a network related.=
> > Furthermore, anybody implementing WebRTC compatible RTP audio
> > interface should not need to read the API document to find the ne= twork
> specific limits.
> >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0ii- The reasonable value range could depend on= the negotiated codec
> >=C2=A0 =C2=A0 =C2=A0and that would be known at the time of interes= ting the digits; so
> >=C2=A0 =C2=A0 =C2=A0anything with MUST strength is too restrictive= IMHO.
> >
> >
> >
> > We know that RFC 4733 would be used to transmit DTMF tones from > WebRTC
> > endpoints. RFC 4733 has no upper or lower limits on tone duration= , so
> > technically these can be set to anything or not set at all. Some<= br> > > people argue that we should limit number of foot guns for future = API
> > users, so they wanted to have reasonable tone duration limits. > >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0iii- The presence of transcoding/interworking = (between different
> >=C2=A0 =C2=A0 =C2=A0forms of digit transfer) devices (they will be= there, whether we
> >=C2=A0 =C2=A0 =C2=A0like it or not, for certain scenarios) makes i= t even less desirable
> >=C2=A0 =C2=A0 =C2=A0to have MUST strength mandates.
> >
> >
> >
> > Unfortunately I spend a significant amount of my time dealing wit= h
> > transcoding elements (SBCs) dealing with RFC 4733 tones. Sending = tones
> > which are too short or sent at high rates make such transcoding > > elements generate unexpected or broken DTMF sequences. Reordered = or
> > interleaved tones are commonly generated in response to such
> > sequences. Extremely long duration DTMF digits typically break in= to
> > several digits. There is danger in not having reasonable limits. = The
> > decision if API users should be protected from this danger is up = to this
> group.
> >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0iv- I think adding some text regarding gap/dur= ation of digit packets
> >=C2=A0 =C2=A0 =C2=A0could be fine but I rather would prefer it wit= h =E2=80=9Crecommend=E2=80=9D (even
> >=C2=A0 =C2=A0 =C2=A0not RECOMMEND) (and providing some values only= as examples).
> >
> >
> >
> > I agree that having reasonable recommended values should be suffi= cient
> > for most cases. The group has to decide if it wants to protect th= e
> > developers from themselves and set MUST level limits on tone and = gap
> > duration.
> >
> > _____________
> > Roman Shpount
> >
> >
> >
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

=C2=A0

=C2=A0


--001a1134f50426e619052ced5c1a-- From nobody Mon Feb 29 11:08:32 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD281B3A2F for ; Mon, 29 Feb 2016 11:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjVWq41LH1I0 for ; Mon, 29 Feb 2016 11:08:29 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B3E1B3A34 for ; Mon, 29 Feb 2016 11:08:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0D38E7C7831; Mon, 29 Feb 2016 20:08:27 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwYFvdDH14q5; Mon, 29 Feb 2016 20:08:26 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:4811:707a:323e:7958] (unknown [IPv6:2001:470:de0a:1:4811:707a:323e:7958]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2BF407C780C; Mon, 29 Feb 2016 20:08:26 +0100 (CET) To: "Asveren, Tolga" , Ted Hardie References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D000EF.9010004@alvestrand.no> <56D1A080.7050901@alvestrand.no> From: Harald Alvestrand Message-ID: <56D49729.5090602@alvestrand.no> Date: Mon, 29 Feb 2016 20:08:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 19:08:31 -0000 Den 29. feb. 2016 19:42, skrev Asveren, Tolga: > I am not sure whether 40ms should be absolute minimum for all codecs. > Even for 6000ms, who am I to argue that somebody can’t come up with a > use case/application, which requires something longer. So, overall, > enforcing does not seem to be the right thing IMGO (default value is > fine as already indicated) (and I don’t fully agree with your statement > that “the point of min/max is promoting sane values” as the model you > are describing is “enforcing” a range rather than a default value in > browser/recommendation in the specification). The point of browswers enforcing min/max is to encourage (forcefully) application writers to write applications that run in all browsers. The point of mandating support up to min/max is to encourage browsers to implement something that works with all conformant applications. There's logic to this. From nobody Mon Feb 29 11:31:00 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C431B3A71 for ; Mon, 29 Feb 2016 11:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okVBzL6Ewfrr for ; Mon, 29 Feb 2016 11:30:57 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 365511B34DB for ; Mon, 29 Feb 2016 11:30:57 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id 9so194191678iom.1 for ; Mon, 29 Feb 2016 11:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=nlX5JqHS/DkAq21NPFnpTah8NKDq73ibU4CQ6mRYEgI=; b=UsKbAhGj7eAtcxzpbZnFdIDYQGL8EfDIjgx2oPTccrISJYd5dyr5HhP9VpRergTPVR a/YNy+JAyG9fWA3jSOdqgoaYsqeG1yUH01cQ8VTGKyQv3ehrbgdYpphTTWsTezRQsbo1 Bi0GSoYlkb0wisIu6HTocy7IdHrZeoQMdd3WZV1l0PYjws7zhYOoeuHBCE2UmfS9JlSK k7WxlGeB50VFMQ5ahMlNbo58OfhFG6IUE0IlLB16I0gKNkXWmVPuNY7jkpfo5yAESyLM /EFFQa2mvlDWjnFutQ3jh4PdQL4H5lj7jx73preyxFh6ih/ezFN0g450VuA1kLi1cgXD j8KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nlX5JqHS/DkAq21NPFnpTah8NKDq73ibU4CQ6mRYEgI=; b=FhS7sdcHU2d7S86sMXT6/2pxJQvc1wZz5X+rZ0IoGZrbhIocyNcc28Mnfw1sCtJcJc 84jFNG4Wv3KCE+K3QAEC6szC54YvcqclSgGvsQPvtz+sy1NhMzrRNsTFZk90lLI8LMwh IZVjuGO9QKQ0c+r/b2kPM/nuUaUi9TjggZegGMRv1oi+znGzPlZ3h6FSkhkBiqmz6BeE 8rjeVZn8uS2sKO8KleclBlWcg30WinyZBampYvKdRirY+q4+UGla2K1GLBgqYzkZ5BsL LUsPEp3MAwmT+ox4KfyYPmZ7Hj1cXN+jAEfYLkeFYBbTDwrdA+okKb6A494aDdESfD7u uKzQ== X-Gm-Message-State: AG10YOQdBUUQ/Otb10e99hyodNtt9hbJIIOmtzBuJrM7fbN2MpdRLIWg5/lvkh4FTiCdIw== X-Received: by 10.107.15.196 with SMTP id 65mr23499120iop.48.1456774256509; Mon, 29 Feb 2016 11:30:56 -0800 (PST) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com. [209.85.213.181]) by smtp.gmail.com with ESMTPSA id c193sm11412943ioe.18.2016.02.29.11.30.54 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Feb 2016 11:30:54 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id g6so3267040igt.1 for ; Mon, 29 Feb 2016 11:30:54 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.30.104 with SMTP id r8mr11596155igh.2.1456774253958; Mon, 29 Feb 2016 11:30:53 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 29 Feb 2016 11:30:53 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> <56D1A080.7050901@alvestrand.no> Date: Mon, 29 Feb 2016 14:30:53 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=047d7bdca2ececf1f2052cedafe4 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 19:30:59 -0000 --047d7bdca2ececf1f2052cedafe4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 29, 2016 at 1:42 PM, Asveren, Tolga wrote: > I am not sure whether 40ms should be absolute minimum for all codecs. Eve= n > for 6000ms, who am I to argue that somebody can=E2=80=99t come up with a = use > case/application, which requires something longer. So, overall, enforcing > does not seem to be the right thing IMGO (default value is fine as alread= y > indicated) (and I don=E2=80=99t fully agree with your statement that =E2= =80=9Cthe point of > min/max is promoting sane values=E2=80=9D as the model you are describing= is > =E2=80=9Cenforcing=E2=80=9D a range rather than a default value in brows= er/recommendation > in the specification). > > > Hi All, Just to be absolutely clear, there are no interconnected PSTN systems which accept DTMF tones shorter then 40 ms with less then 30 ms gaps. RFC 4733 does not impose the minimum DTMF tone duration limit, so VoIP only systems will take shorter tones. We routinely test SBCs and provider gateways on how they handle extremely short DTMF tones. Quite a few of them break, since tones and gaps need to be extended to generate valid PCMU/PCMA audio. RFC 2833 had a maximum DTMF tone duration of 8191 ms after which the tone duration counter overflowed (unsigned short int used to measure duration in RTP units with 8 KHz clock). I am not aware of anyone who run into this limit for any practical application. So, as far as I can see we have two options for min duration: a. Set the min tone duration limit to 40 ms and min gap limit to 30 ms. These are minimum values accepted by national phone networks according to ITU b. Set the min tone duration and min gap to 0. These are the minimum values possible with RFC 4733 I would prefer option b here, but this is mostly for testing. I would understand if no one else would want this and go with PSTN based limits (option a). And we have two options for max duration: a. Set max tone duration to 8000 ms (I would increase it from 6000ms to at least have some reason for it). b. Make max tone duration unlimited. I would go with option a. No one needs tones longer then 8 s even for testing. I assume no one is against the default values of 100 ms tone and 70 ms gap. I believe these values to be safe and reasonable. >From interop experience I would also enforce starting and ending the tone on the non tone packet boundary, but this can be an implementation specific= . This was all discussed to death in the webrtc group. Unfortunately it was the wrong group to discuss this topic. Regards, _____________ Roman Shpount --047d7bdca2ececf1f2052cedafe4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 29, 2016 at 1:42 PM, Asveren, Tolga <= tasveren@sonusne= t.com> wrote:

I am not sure whether 40ms should be absolut= e minimum for all codecs. Even for 6000ms, who am I to argue that somebody = can=E2=80=99t come up with a use case/application, which requires something longer. So, overall, enforcing does not seem to b= e the right thing IMGO (default value is fine as already indicated) (and I = don=E2=80=99t fully agree with your statement that =E2=80=9Cthe point of mi= n/max is promoting sane values=E2=80=9D as the model you are describing is =C2=A0=E2=80=9Cenforcing=E2=80=9D a range rather than a = default value in browser/recommendation in the specification).=C2=A0



Hi All,

Just to be absolutely clear, there are no= interconnected PSTN systems which accept DTMF tones shorter then 40 ms wit= h less then 30 ms gaps. RFC 4733 does not impose the minimum DTMF tone dura= tion limit, so VoIP only systems will take shorter tones. We routinely test= SBCs and provider gateways on how they handle extremely short DTMF tones. = Quite a few of them break, since tones and gaps need to be extended to gene= rate valid PCMU/PCMA audio.

RFC 2833 had a maximum= DTMF tone duration of 8191 ms after which the tone duration counter overfl= owed (unsigned short int used to measure duration in RTP units with 8 KHz c= lock). I am not aware of anyone who run into this limit for any practical a= pplication.

So, as far as I can see we have two op= tions for min duration:

a. Set the min tone durati= on limit to 40 ms and min gap limit to 30 ms. These are minimum values acce= pted by national phone networks according to ITU
b. Set the min t= one duration and min gap to 0. These are the minimum values possible with R= FC 4733

I would prefer option b here, but this is = mostly for testing. I would understand if no one else would want this and g= o with PSTN based limits (option a).

And we have t= wo options for max duration:

a. Set max tone durat= ion to 8000 ms (I would increase it from 6000ms to at least have some reaso= n for it).
b. Make max tone duration unlimited.

I would go with option a. No one needs tones longer then 8 s even f= or testing.

I assume no one is against the default= values of 100 ms tone and 70 ms gap. I believe these values to be safe and= reasonable.
From interop experience I would also enforce startin= g and ending the tone on the non tone packet boundary, but this can be an i= mplementation specific.

This was all discussed to = death in the webrtc group. Unfortunately it was the wrong group to discuss = this topic.=C2=A0

Regards,
_____________
Roman Shpount
=C2=A0
--047d7bdca2ececf1f2052cedafe4-- From nobody Mon Feb 29 12:11:22 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764481B3B49 for ; Mon, 29 Feb 2016 12:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojDevH-Sx61l for ; Mon, 29 Feb 2016 12:11:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0605.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:605]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E9A1B3B3D for ; Mon, 29 Feb 2016 12:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kz8sBRFDGRph8f5+fJ0ChmAOOm1GaZwlo38k+F6eYIQ=; b=FI2caKCUhb3ZvXnXSL5kq8rQxr6rfNOA6WmwdlONAYZBFn1P3WKiqSWLEJnnayuTIUtDDeU1ymRtbvC6lNB3M2KFOTqiC5clEohWiqId1h7HTWl5L2zD7d88UkNJjVDESuKrhN+rrAn69V+SnW0hVRdzvNjJxjxB1f3WeO1eXD0= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 29 Feb 2016 20:10:50 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Mon, 29 Feb 2016 20:10:50 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p89KcurgAAU0gCAALLLgIAAOucggAC01ICAANVAYIAAKmkAgAA3mfCAAzMegIAAEaGAgAAC3oCAAAAVkIAAD2GAgAAJS/o= Date: Mon, 29 Feb 2016 20:10:49 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> <56D1A080.7050901@alvestrand.no> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: bb6e023c-762d-4599-813d-08d341446b3a x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:kAIIp3R2Ie4V2wP3ZG64fQlCyFhu+pyY7K9NH/6eiNtikwYMLpv9Pbu/G5/45DGNyURpmsENRY274qf/TBXttdv/9vETw8k+8QzSkNhmNogVl3JzqE4hBX+LicJNqlG2oUSoOX6pxguOrTgzGhtHrA==; 24:33mzqwPzg6sU1eAW+NcitnlIdH3Y1xXwP4knw0LlC3cOqUG5S7pjOFfZZCjSyrrHhw8hK9dOLfWKNILn9Tofa/rFjE8ZvqQsMdDBGtBvcxw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 0867F4F1AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(53754006)(164054003)(2473001)(377454003)(87936001)(3846002)(50986999)(76176999)(110136002)(5002640100001)(2906002)(102836003)(11100500001)(230783001)(93886004)(5003600100002)(81156008)(19627405001)(76576001)(1096002)(5004730100002)(16236675004)(19625215002)(122556002)(3660700001)(10400500002)(92566002)(3280700002)(74316001)(3900700001)(99286002)(6116002)(2900100001)(33656002)(586003)(4326007)(1220700001)(2950100001)(5008740100001)(189998001)(54356999)(66066001)(19580405001)(19580395003)(77096005)(86362001)(5001960100003)(40100003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB155111CC2AAC4D3B0962B3E6B2BA0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Feb 2016 20:10:49.8043 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 20:11:21 -0000 --_000_SN1PR0301MB155111CC2AAC4D3B0962B3E6B2BA0SN1PR0301MB1551_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i- I don't know why we are trying to restrict the solution to PSTN/ITU reco= mmendations. t certainly is possible that interworking is to be done to som= e other form of VoIP network. ii- I think the core requirement is that we don't want application develope= rs to use "wrong" values. There are two possibilities here: - App developer knows what he is doing In this scenario, he can supply the values to be used. - App developer does not know much about DTMF digits In this scenario, browser default values can be used. An application writte= n by such a person still would run on all browsers as long as browsers supp= orts *some* default value -not necessarily the same-. IMHO, recommending some guidelines for app.developers and default values to= be used by browsers (without any keywords) would provide a satisfactory so= lution for both scenarios. Thanks, Tolga ________________________________ From: Roman Shpount Sent: Monday, February 29, 2016 2:30 PM To: Asveren, Tolga Cc: Ted Hardie; Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: Last Call: (Web= RTC Audio Codec and Processing Requirements) to Proposed Standard On Mon, Feb 29, 2016 at 1:42 PM, Asveren, Tolga > wrote: I am not sure whether 40ms should be absolute minimum for all codecs. Even = for 6000ms, who am I to argue that somebody can't come up with a use case/a= pplication, which requires something longer. So, overall, enforcing does no= t seem to be the right thing IMGO (default value is fine as already indicat= ed) (and I don't fully agree with your statement that "the point of min/max= is promoting sane values" as the model you are describing is "enforcing" = a range rather than a default value in browser/recommendation in the specif= ication). Hi All, Just to be absolutely clear, there are no interconnected PSTN systems which= accept DTMF tones shorter then 40 ms with less then 30 ms gaps. RFC 4733 d= oes not impose the minimum DTMF tone duration limit, so VoIP only systems w= ill take shorter tones. We routinely test SBCs and provider gateways on how= they handle extremely short DTMF tones. Quite a few of them break, since t= ones and gaps need to be extended to generate valid PCMU/PCMA audio. RFC 2833 had a maximum DTMF tone duration of 8191 ms after which the tone d= uration counter overflowed (unsigned short int used to measure duration in = RTP units with 8 KHz clock). I am not aware of anyone who run into this lim= it for any practical application. So, as far as I can see we have two options for min duration: a. Set the min tone duration limit to 40 ms and min gap limit to 30 ms. The= se are minimum values accepted by national phone networks according to ITU b. Set the min tone duration and min gap to 0. These are the minimum values= possible with RFC 4733 I would prefer option b here, but this is mostly for testing. I would under= stand if no one else would want this and go with PSTN based limits (option = a). And we have two options for max duration: a. Set max tone duration to 8000 ms (I would increase it from 6000ms to at = least have some reason for it). b. Make max tone duration unlimited. I would go with option a. No one needs tones longer then 8 s even for testi= ng. I assume no one is against the default values of 100 ms tone and 70 ms gap.= I believe these values to be safe and reasonable. >From interop experience I would also enforce starting and ending the tone o= n the non tone packet boundary, but this can be an implementation specific. This was all discussed to death in the webrtc group. Unfortunately it was t= he wrong group to discuss this topic. Regards, _____________ Roman Shpount --_000_SN1PR0301MB155111CC2AAC4D3B0962B3E6B2BA0SN1PR0301MB1551_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

i- I don't know why we are trying to restrict the solution to PSTN/ITU r= ecommendations. t certainly is possible that interworking is to be done to = some other form of VoIP network.


ii- I think the core requirement is that we don't want applica= tion developers to use "wrong" values. There are two possibilitie= s here:

- App developer knows what he is doing

In this scenario, he can supply the values to be used.<= /p>

- App developer does not know much about DTMF digits

In this scenario, browser default values can be used. An appl= ication written by such a person still would run on all browsers as lo= ng as browsers supports *some* default value -not necessarily the same-.


IMHO, recommending some guidelines for app.developers an= d default values to be used by browsers (without any keywords) would p= rovide a satisfactory solution for both scenarios.



Thanks,

Tolga



From: Roman Shpount <rom= an@telurix.com>
Sent: Monday, February 29, 2016 2:30 PM
To: Asveren, Tolga
Cc: Ted Hardie; Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10= .txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Stand= ard
 
On Mon, Feb 29, 2016 at 1:42 PM, Asveren, To= lga <tasveren@son= usnet.com> wrote:

I am not sure whether 40ms should be absol= ute minimum for all codecs. Even for 6000ms, who am I to argue that somebod= y can’t come up with a use case/application, which requires something longer. So, overall, enforcing does not seem to b= e the right thing IMGO (default value is fine as already indicated) (and I = don’t fully agree with your statement that “the point of min/ma= x is promoting sane values” as the model you are describing is  “enforcing” a range rather than a defa= ult value in browser/recommendation in the specification).=  



Hi All,

Just to be absolutely clear, there are no interconnected PSTN systems = which accept DTMF tones shorter then 40 ms with less then 30 ms gaps. RFC 4= 733 does not impose the minimum DTMF tone duration limit, so VoIP only syst= ems will take shorter tones. We routinely test SBCs and provider gateways on how they handle extremely sho= rt DTMF tones. Quite a few of them break, since tones and gaps need to be e= xtended to generate valid PCMU/PCMA audio.

RFC 2833 had a maximum DTMF tone duration of 8191 ms after which the t= one duration counter overflowed (unsigned short int used to measure duratio= n in RTP units with 8 KHz clock). I am not aware of anyone who run into thi= s limit for any practical application.

So, as far as I can see we have two options for min duration:

a. Set the min tone duration limit to 40 ms and min gap limit to 30 ms= . These are minimum values accepted by national phone networks according to= ITU
b. Set the min tone duration and min gap to 0. These are the minimum v= alues possible with RFC 4733

I would prefer option b here, but this is mostly for testing. I would = understand if no one else would want this and go with PSTN based limits (op= tion a).

And we have two options for max duration:

a. Set max tone duration to 8000 ms (I would increase it from 6000ms t= o at least have some reason for it).
b. Make max tone duration unlimited.

I would go with option a. No one needs tones longer then 8 s even for = testing.

I assume no one is against the default values of 100 ms tone and 70 ms= gap. I believe these values to be safe and reasonable.
From interop experience I would also enforce starting and ending the t= one on the non tone packet boundary, but this can be an implementation spec= ific.

This was all discussed to death in the webrtc group. Unfortunately it = was the wrong group to discuss this topic. 

Regards,
_____________
Roman Shpount
 
--_000_SN1PR0301MB155111CC2AAC4D3B0962B3E6B2BA0SN1PR0301MB1551_-- From nobody Mon Feb 29 12:53:34 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C88F1B3BDF for ; Mon, 29 Feb 2016 12:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3mteNKGKgBK for ; Mon, 29 Feb 2016 12:53:20 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB3E1B3BD2 for ; Mon, 29 Feb 2016 12:53:19 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id s68so61416424qkh.3 for ; Mon, 29 Feb 2016 12:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zt9/ahKt92QAPdRSp6ZYYUwDHCnLwFZOrZUxDTfr57g=; b=sPof+P6C42i/sYrdev6coABNXtDqnmaCcWRQ244hu9NMGNdV60G1F7oNeuX60Ae+Us HxdZltCn1WHTmd7+rAEMdaVwvvmTpvf+T+yn1+Puuxjjwxj6T4MG+7e0ktPzUQ/70N3s +WvuZHCYA1fsX01Sny0mCFqo9tannhBYn1HH8csTn1E5rC97cCTLg7JxAuNRjTc6N/aE ikKV9cMMv8fTnnhDMfpGs8oJ4KR1NPml0aQe0oDUUbPJciBc/OHLEflrJGjKPhfFlrJR 8MaerTDjgv1oO3FZ/mjbAM7ftUx7rBfulu6K5+t8AoyWOM7oHlOOqmLyWrcnL6S39siX UJfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zt9/ahKt92QAPdRSp6ZYYUwDHCnLwFZOrZUxDTfr57g=; b=JHqAT3bLOgv1bSztrJDpAhdxkB2/tAGO1ee28R7Ta9TeCS9RtBYdiB0bNnWBkcI6zC teFRIWrrXFYt27rxsuRKDbne0fIis5L/0nqs/PJ2ue0G6LnXazdBSBdlNRbOwlbgN4YF O7+nAd9EB6V73F27tYi8fHPyP/Zepdf1h7bJjcVkIrMsS3tPQg/HozNyIQYOXSiI+1dx /vBNguZo6a6zPdORn87M3EUybSDtBgr6qLaAH+H0DwwyeOQ25ch2zi755h1ExRN/1R87 4IgCYMqMY9JpujCHRm9u7ckUGxzZRSnPPQ1r1BiLYLz75nUdZFNk5NAVCLH00X3BsDCw x95Q== X-Gm-Message-State: AD7BkJKBxrNAwvrA24uao051hY/MV3h1Vb8AMq3D2c7A69T6c30xyYteuzs5gl4X8Of2MuoIXZmWhdxFJCtVCQ== X-Received: by 10.55.74.141 with SMTP id x135mr21899638qka.20.1456779198880; Mon, 29 Feb 2016 12:53:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.6.13 with HTTP; Mon, 29 Feb 2016 12:52:59 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> <56D1A080.7050901@alvestrand.no> From: Ted Hardie Date: Mon, 29 Feb 2016 12:52:59 -0800 Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a114a7c6eaa6386052ceed657 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 20:53:25 -0000 --001a114a7c6eaa6386052ceed657 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howdy, On Mon, Feb 29, 2016 at 12:10 PM, Asveren, Tolga wrote: > - App developer knows what he is doing > You still have not answered the question of how the application discerns what the bounds are for a browser, if they are not specified. Also, assuming either 40/6000 (or even 40/8000, to follow Roman's recent suggestion) are used in conformance with PSTN requirements, what is the likelihood that the developer who knows what she's doing is going to select something outside that range? regards, Ted > Thanks, > > Tolga > > > ------------------------------ > *From:* Roman Shpount > *Sent:* Monday, February 29, 2016 2:30 PM > *To:* Asveren, Tolga > *Cc:* Ted Hardie; Harald Alvestrand; rtcweb@ietf.org > *Subject:* Re: [rtcweb] Fwd: Last Call: > (WebRTC Audio Codec and Processing Requirements) to Proposed Standard > > On Mon, Feb 29, 2016 at 1:42 PM, Asveren, Tolga > wrote: > >> I am not sure whether 40ms should be absolute minimum for all codecs. >> Even for 6000ms, who am I to argue that somebody can=E2=80=99t come up w= ith a use >> case/application, which requires something longer. So, overall, enforcin= g >> does not seem to be the right thing IMGO (default value is fine as alrea= dy >> indicated) (and I don=E2=80=99t fully agree with your statement that =E2= =80=9Cthe point of >> min/max is promoting sane values=E2=80=9D as the model you are describin= g is >> =E2=80=9Cenforcing=E2=80=9D a range rather than a default value in brow= ser/recommendation >> in the specification). >> >> >> > Hi All, > > Just to be absolutely clear, there are no interconnected PSTN systems > which accept DTMF tones shorter then 40 ms with less then 30 ms gaps. RFC > 4733 does not impose the minimum DTMF tone duration limit, so VoIP only > systems will take shorter tones. We routinely test SBCs and provider > gateways on how they handle extremely short DTMF tones. Quite a few of th= em > break, since tones and gaps need to be extended to generate valid PCMU/PC= MA > audio. > > RFC 2833 had a maximum DTMF tone duration of 8191 ms after which the tone > duration counter overflowed (unsigned short int used to measure duration = in > RTP units with 8 KHz clock). I am not aware of anyone who run into this > limit for any practical application. > > So, as far as I can see we have two options for min duration: > > a. Set the min tone duration limit to 40 ms and min gap limit to 30 ms. > These are minimum values accepted by national phone networks according to > ITU > b. Set the min tone duration and min gap to 0. These are the minimum > values possible with RFC 4733 > > I would prefer option b here, but this is mostly for testing. I would > understand if no one else would want this and go with PSTN based limits > (option a). > > And we have two options for max duration: > > a. Set max tone duration to 8000 ms (I would increase it from 6000ms to a= t > least have some reason for it). > b. Make max tone duration unlimited. > > I would go with option a. No one needs tones longer then 8 s even for > testing. > > I assume no one is against the default values of 100 ms tone and 70 ms > gap. I believe these values to be safe and reasonable. > From interop experience I would also enforce starting and ending the tone > on the non tone packet boundary, but this can be an implementation specif= ic. > > This was all discussed to death in the webrtc group. Unfortunately it was > the wrong group to discuss this topic. > > Regards, > _____________ > Roman Shpount > > --001a114a7c6eaa6386052ceed657 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,
On Mon, Feb 29, 2016 at 12:10 PM, Asveren, Tolga= <tasveren@sonusnet.com> wrote:
- App developer knows what he i= s doing

You still have n= ot answered the question of how the application discerns what the bounds ar= e for a browser, if they are not specified.

Also, assumin= g either 40/6000 (or even 40/8000, to follow Roman's recent suggestion)= are used in conformance with PSTN requirements, what is the likelihood tha= t the developer who knows what she's doing is going to select something= outside that range?

regards,

Ted
=C2=A0

Thanks,

Tolga



From: Roman Shpount <roman@telurix.com>
Sent: Monday, February 29, 2016 2:30 PM
To: Asveren, Tolga
Cc: Ted Hardie; Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10= .txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Stand= ard
=C2=A0
On Mon, Feb 29, 2016 at 1:42 PM, Asveren, Tolga <tasveren@son= usnet.com> wrote:

I am not sure whether 40ms should be absolut= e minimum for all codecs. Even for 6000ms, who am I to argue that somebody = can=E2=80=99t come up with a use case/application, which requires something longer. So, overall, enforcing does not seem to b= e the right thing IMGO (default value is fine as already indicated) (and I = don=E2=80=99t fully agree with your statement that =E2=80=9Cthe point of mi= n/max is promoting sane values=E2=80=9D as the model you are describing is =C2=A0=E2=80=9Cenforcing=E2=80=9D a range rather than a = default value in browser/recommendation in the specification).=C2=A0



Hi All,

Just to be absolutely clear, there are no interconnected PSTN systems = which accept DTMF tones shorter then 40 ms with less then 30 ms gaps. RFC 4= 733 does not impose the minimum DTMF tone duration limit, so VoIP only syst= ems will take shorter tones. We routinely test SBCs and provider gateways on how they handle extremely sho= rt DTMF tones. Quite a few of them break, since tones and gaps need to be e= xtended to generate valid PCMU/PCMA audio.

RFC 2833 had a maximum DTMF tone duration of 8191 ms after which the t= one duration counter overflowed (unsigned short int used to measure duratio= n in RTP units with 8 KHz clock). I am not aware of anyone who run into thi= s limit for any practical application.

So, as far as I can see we have two options for min duration:

a. Set the min tone duration limit to 40 ms and min gap limit to 30 ms= . These are minimum values accepted by national phone networks according to= ITU
b. Set the min tone duration and min gap to 0. These are the minimum v= alues possible with RFC 4733

I would prefer option b here, but this is mostly for testing. I would = understand if no one else would want this and go with PSTN based limits (op= tion a).

And we have two options for max duration:

a. Set max tone duration to 8000 ms (I would increase it from 6000ms t= o at least have some reason for it).
b. Make max tone duration unlimited.

I would go with option a. No one needs tones longer then 8 s even for = testing.

I assume no one is against the default values of 100 ms tone and 70 ms= gap. I believe these values to be safe and reasonable.
From interop experience I would also enforce starting and ending the t= one on the non tone packet boundary, but this can be an implementation spec= ific.

This was all discussed to death in the webrtc group. Unfortunately it = was the wrong group to discuss this topic.=C2=A0

Regards,
_____________
Roman Shpount
=C2=A0

--001a114a7c6eaa6386052ceed657-- From nobody Mon Feb 29 16:15:56 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B571A1BD9 for ; Mon, 29 Feb 2016 16:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgHRrNMW74tC for ; Mon, 29 Feb 2016 16:15:53 -0800 (PST) Received: from smtp73.iad3a.emailsrvr.com (smtp73.iad3a.emailsrvr.com [173.203.187.73]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642D61A1BE6 for ; Mon, 29 Feb 2016 16:15:53 -0800 (PST) Received: from smtp10.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5E5382803DC; Mon, 29 Feb 2016 19:15:52 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp10.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id AFADC2802D7; Mon, 29 Feb 2016 19:15:51 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Mon, 29 Feb 2016 19:15:52 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Cullen Jennings In-Reply-To: Date: Mon, 29 Feb 2016 17:15:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2897548F-0632-42C0-A55E-EB3F0F734A44@iii.ca> References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D0097D.40308@mozilla.com> To: Roman Shpount X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 00:15:55 -0000 > On Feb 26, 2016, at 2:38 PM, Roman Shpount wrote: >=20 > 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.=20 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.=20 As FYI ... the w3c spec for the function is at=20 = http://w3c.github.io/webrtc-pc/#widl-RTCDTMFSender-insertDTMF-void-DOMStri= ng-tones-unsigned-long-duration-unsigned-long-interToneGap