Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio

Roman Shpount <roman@telurix.com> Tue, 26 January 2016 21:21 UTC

Return-Path: <roman@telurix.com>
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 9C7A71B3180 for <rtcweb@ietfa.amsl.com>; Tue, 26 Jan 2016 13:21:46 -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 F4o7mia41Pom for <rtcweb@ietfa.amsl.com>; Tue, 26 Jan 2016 13:21:44 -0800 (PST)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::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 6F2271B2C67 for <rtcweb@ietf.org>; Tue, 26 Jan 2016 13:21:44 -0800 (PST)
Received: by mail-ig0-x22b.google.com with SMTP id t15so69254317igr.0 for <rtcweb@ietf.org>; Tue, 26 Jan 2016 13:21:44 -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=/7tL7VC52mlPN+pO80lyp8Wzf15edPLelJv6sFa5b04=; b=OvDULqlizu5ReCCrqxCz/xBv1irWCsa60zhtw3LIgFEE18JCGiSauH1wCgNAV/jtk9 dzwitOinbz2mkVA/YwamsUAVwgxLB/kfTPYrDdLSLs4948/iXoMVPun+2t9isDwwqJ6s F5Bf8VVVME+kQent3JYTmzHIFrCNtEe1SQfs7twnJ7Q2AjcrLWupJAml2qL/B1YYubjA Oc+HxEQha76ZKw31vg/trP91qKYKK4rMyl4arnKYHKe/yAYeC6UEbOlqFeh95dkelaNS dKYVb8vmINcHGTh4edQOs/1n0Hg0Zy2GMmMKHcvnl5lGRYiBI9aqBtoqM5Q2OtrJgBVd uF8Q==
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=/7tL7VC52mlPN+pO80lyp8Wzf15edPLelJv6sFa5b04=; b=cV/EZAPtUmISms1fGgyINyKHPzm15OzTdsJcSe5WCC1Vkn8pbFQeUZp8xjRlWyk78a 1mwgbJY5blXNIGHh1877u7FUtQunC+dMt9MTuQloocUzb0r04qWPOhcOBYKeJdFCz2yb bFAYupw+9poLBLrHbbSo3nNNKtpUhstpK6nO1H5PRnKERUh8m4OMSWdk5qrxNXzb7Fpr xlLVRUVTYmXqURf/FodQHXBGTc6NZQ4CHQBg2rvBC2nkQYq3SAsv3x2s+UFUmd8us9SI Ol+a3We9cbQYMQr0cOpb2hj7tpixw+K2gD98f5pQ34g/NrUjryI4Q3E+TB62zXbXKO3z Oi6Q==
X-Gm-Message-State: AG10YOTFESamTwIkeKocTSy+lBstv5h86Z+723k7TbyuqxzkxSARyC2fRS3ghYJRJuXmBg==
X-Received: by 10.50.155.43 with SMTP id vt11mr25725303igb.6.1453843303636; Tue, 26 Jan 2016 13:21:43 -0800 (PST)
Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com. [209.85.213.170]) by smtp.gmail.com with ESMTPSA id qd10sm2051061igc.1.2016.01.26.13.21.41 for <rtcweb@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 13:21:42 -0800 (PST)
Received: by mail-ig0-f170.google.com with SMTP id z14so66937251igp.0 for <rtcweb@ietf.org>; Tue, 26 Jan 2016 13:21:41 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.102.69 with SMTP id fm5mr25784652igb.24.1453843301499; Tue, 26 Jan 2016 13:21:41 -0800 (PST)
Received: by 10.36.105.77 with HTTP; Tue, 26 Jan 2016 13:21:41 -0800 (PST)
In-Reply-To: <56A7D683.2010807@mozilla.com>
References: <CA+9kkMDAL1mKqt7cTRmU4YqX2S5QN4RKn2cfbPaBeDgx=yiN0Q@mail.gmail.com> <CAD5OKxtvhaqx=H10=fUiGAjvnGAb_g89p2TZT9iNEg2F9k+6FA@mail.gmail.com> <CA+9kkMApyK4YPaWbQATy9zGfCOd3Dyfr8cY2amODgFE4XQCA=A@mail.gmail.com> <CAD5OKxtDGUv3akJTe6ZRYNhQN=SMY_R+GeV_Kg67Y6EYq+aV=A@mail.gmail.com> <CA+9kkMCvAcxnc=QdGvTm3=VNOQ3TtO+d8PfbfVA8sLeEA6rRqg@mail.gmail.com> <CAD5OKxtu-dsahdwL7t7Br34V-guqKmsdTsztOK_8sSsvWYsF=g@mail.gmail.com> <CA+9kkMBxbmGggCUaBPVtsJ7o3ZvBS=xvDKkmvfJxdVbM8NgiEQ@mail.gmail.com> <CAD5OKxvaJTRtfDQLwpvi+etdh8ZQvP5eRROSvRY2Hg-Uasisww@mail.gmail.com> <F9264ABC-E856-44B4-9E7E-8359B5D39A55@cisco.com> <78C957DC-4659-49A9-B4B9-EFAD5641574F@phonefromhere.com> <CAD5OKxu9_W97uc_rN_1c=Q8Dz713wDe5ccA2zFfPM-3a3YwznQ@mail.gmail.com> <56A7D683.2010807@mozilla.com>
Date: Tue, 26 Jan 2016 16:21:41 -0500
X-Gmail-Original-Message-ID: <CAD5OKxt4e2DBm4QrrtHo3cYaeMptSnsoA5xOD_Z9h+nrZTkQYA@mail.gmail.com>
Message-ID: <CAD5OKxt4e2DBm4QrrtHo3cYaeMptSnsoA5xOD_Z9h+nrZTkQYA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Jean-Marc Valin <jmvalin@mozilla.com>
Content-Type: multipart/alternative; boundary="047d7b10ca098b963b052a434572"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/z94PJx7RGyQQDPAVEePAzDaR3YY>
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working group last call for draft-ietf-rtcweb-audio
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2016 21:21:46 -0000

On Tue, Jan 26, 2016 at 3:26 PM, Jean-Marc Valin <jmvalin@mozilla.com>
wrote:

> The text below is what you propose for the rtcweb-audio draft? I
> personally have no opinion on these events (see comment inline for
> clarification though) so I'm happy to include that text if everyone
> else is OK with it.
>

Yes, this is the text I am proposing for rtcweb-audio draft.

> 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. Event SHOULD start on a
> > regular audio packet border and event and gap duration SHOULD be
> > rounded up to the next regular audio packet border.
> >
> > During the time events are generated no audio SHOULD be sent for
> > the same audio stream. When gaps between events are generated,
> > silence and not the background audio SHOULD be sent using regular
> > audio encoding.
>
> I think this would require a bit of clarification. What does "no
> audio" mean here? Silence or no codec packets at all (in that case
> what about PLC)? Also, keep in mind that any silence may not be
> perfectly aligned with theoretical frame boundaries, due to look-ahead.
>
>
First of all I was trying to copy all the normative tone duration
information from W3C document to rtcweb-audio draft.

Second, as far as "no audio" is concerned, what I mean here is that RFC4733
telephone-events are alternative audio encoding similar to CN (see
https://tools.ietf.org/html/rfc4733#section-2.5.2.2). For RTP timestamp
interval covered by telephone-event no non-event audio packets, such as
Opus or G.711, should be present since they are redundant and cause interop
problems. PLC does not apply here since remote gateways is supposed to
generate audio based on the information in telephone-events packets. This
is essentially the same requirement that end point should not send packets
with two different audio encodings (i.e. send Opus and G.711 RTP packets)
at the same time. This can work but can also cause interop problems.

Packet boundaries of audio encoded using codecs such as G.711 or Opus
should create a continuous stream as far as RTP timestamps are concerned
with RFC 4733 telephone event packets unless discontinuous RTP is used. It
should be possible to align decoded audio and telephone-events based on RTP
timestamps.

I also wanted to provide clarification for
https://tools.ietf.org/html/rfc4733#section-2.5.1.2. This section says:

   A source has wide latitude as to how often it sends event updates.  A
   natural interval is the spacing between non-event audio packets.
   (Recall that a single RTP packet can contain multiple audio frames
   for frame-based codecs and that the packet interval can vary during a
   session.)  Alternatively, a source MAY decide to use a different
   spacing for event updates, with a value of 50 ms RECOMMENDED.


I am proposing that WebRTC should recommend that sending telephone-event
packet at natural interval between non-event audio packets is
strongly preferred.

Also, blocking input audio for a short period of time after
telephone-events are transmitted prevents a duplicate DTMF digit audio from
being present in the encoded audio stream which some times happen due to
microphone picking up audio feedback tones played by some DTMF keypad
implementations. This also improves DTMF tone recognition by a receiving
IVR system after audio stream passes through PSTN gateway since having
background audio as a separator between DTMF digits can negatively affect
some tone detection algorithms.

Please let me know if you need more information.

Regards,
_____________
Roman Shpount