From nobody Thu Jul 7 14:33:51 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93A412D532 for ; Thu, 7 Jul 2016 14:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=QstQeq+6; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=JbWI1hOh 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 DRM7WShqkN_b for ; Thu, 7 Jul 2016 14:33:48 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFDB12D0CD for ; Thu, 7 Jul 2016 14:33:48 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9A1CE20149 for ; Thu, 7 Jul 2016 17:33:47 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 07 Jul 2016 17:33:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=sGd /6WXB0PsjqGQhtt8QYE2oBPU=; b=QstQeq+64S23WeLyiGl3Fhr4gLdEGVLBUAr Byw3LrfSv+9M883A/Dp2JtKD9zK+o7LGsEvcJycZDCUMr9a1WyJPTT1ju63ldgxu Ayq5y5nQ/LIKToAMqKQJOdC3fKUYb/hutj6Dj2RCSnI8LE4h5SC2JpsJW4WyiPmT ANUTP6Qs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=sGd/6WXB0PsjqGQhtt8QYE2oBPU=; b=JbWI1 hOhBAIaWFHYusfY6GFQlX9L24Xb3wI0XWYgDpfH8kBpf5gW/udWT6Q18W7lN+/Uv HK7ikl8U8Ru8mo8j2kLzIuG78P9hCVzKp9Qc374eS1AzhQnJ2gbYR8coYISj5Vhp 2DIdYwKbWuasqMn91TRt6B7xRgjNwVJdmnbb9Q= X-Sasl-enc: DaFhf78BDDgg8++rFgU82agoLKNzt9DaaA4dd+8rHAg1 1467927227 Received: from dhcp-171-68-21-119.cisco.com (dhcp-171-68-21-119.cisco.com [171.68.21.119]) by mail.messagingengine.com (Postfix) with ESMTPA id EB50EF29E1 for ; Thu, 7 Jul 2016 17:33:46 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 7 Jul 2016 14:33:46 -0700 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [rtcweb] AD evaluation: draft-ietf-rtcweb-transports-14 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jul 2016 21:33:49 -0000 I have reviewed this document in preparation for IETF last call. It is = in good shape and I have requested the last call. While the last call is ongoing, I would like to double-check that this = document (particularly Section 4) raises no new security considerations = that should be documented in Section 6. I'm wondering if there are = scenarios where a malicious application could try to game the priority = scheme to some ill effect? draft-ietf-tsvwg-rtcweb-qos talks a bit about = this, so I'm wondering if anything needs to be said here. And I found a couple of nits to be resolved together with any LC = comments: - Sec 3.2 - Please update the citation to point to = draft-ietf-mmusic-ice-dualstack-fairness-02. - Sec 3.4 - "Third, using TCP only between the endpoint and its relay may result in less issues with TCP in regards to real-time constraints, e.g. due to head of line blocking." =20 This is awkwardly phrased. I would suggest something like "Third, using = TCP between the client's TURN server and its peer may result in more = performance problems (due to head-of-line blocking) than using UDP." Alissa= From nobody Thu Jul 7 14:53:17 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 9B87212D5CD; Thu, 7 Jul 2016 14:53:12 -0700 (PDT) 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.25.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160707215312.18636.43343.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 14:53:12 -0700 Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: [rtcweb] Last Call: (Transports for WebRTC) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 07 Jul 2016 21:53:13 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'Transports for WebRTC' 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-07-21. 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 describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jul 7 15:05:15 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFD312D606 for ; Thu, 7 Jul 2016 15:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=q0Fmhs1v; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=t44AbD6R 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 whLpiwhaAoaP for ; Thu, 7 Jul 2016 15:05:11 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856EA12D59A for ; Thu, 7 Jul 2016 15:05:11 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id EBDC4203C7 for ; Thu, 7 Jul 2016 18:05:10 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 07 Jul 2016 18:05:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=X2LVE9PfEja4Ex6qZZj3wKwHzww=; b=q0Fmhs 1vYmmUFo/pEp349XP4ZK/UScFL0l2w22YyBTQRDU44NkpnXQ5ILrTOFwxVzc6XI5 gVKdbvo9PEiMnNkepLmVNQ2afJh4Wr6dCc0hO5d5O0jx/Q82GIHMtUG+iYo8jSjk ZxfaJzd1YlpDgsa+31OifQ9zgkv22elvrj6NE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=X2LVE9PfEja4Ex6 qZZj3wKwHzww=; b=t44AbD6RO+E3DAGoZkHyr4eOkRo+9BECz22pPIRt71UXhdd QNDVJHTouK0hC7CQGqglf2ydrR0cGRfjTRa85EKiN55hRNTzC6KmdSkH8D8IUPu3 x8qyFk3kvNFYKdwxpoDtL5RnBtar2YVlJ0tVUuGdY0XYBneCtjgfaLVuNJmE= X-Sasl-enc: nt/SKwx/+mGDahUgJhnE60cz8pucP1/x7q5eNunnE80v 1467929109 Received: from dhcp-171-68-21-119.cisco.com (dhcp-171-68-21-119.cisco.com [171.68.21.119]) by mail.messagingengine.com (Postfix) with ESMTPA id 18175F2A01 for ; Thu, 7 Jul 2016 18:05:09 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Thu, 7 Jul 2016 15:05:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <135AC732-714F-4AD2-83F3-B23ED173C992@cooperw.in> References: To: rtcweb@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-transports-14 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jul 2016 22:05:13 -0000 And one bit I left out =E2=80=94 if text is to be added to reference = draft-ietf-rtcweb-return, that should be done together with addressing = nits and LC comments. > On Jul 7, 2016, at 2:33 PM, Alissa Cooper wrote: >=20 > I have reviewed this document in preparation for IETF last call. It is = in good shape and I have requested the last call. >=20 > While the last call is ongoing, I would like to double-check that this = document (particularly Section 4) raises no new security considerations = that should be documented in Section 6. I'm wondering if there are = scenarios where a malicious application could try to game the priority = scheme to some ill effect? draft-ietf-tsvwg-rtcweb-qos talks a bit about = this, so I'm wondering if anything needs to be said here. >=20 > And I found a couple of nits to be resolved together with any LC = comments: >=20 > - Sec 3.2 - Please update the citation to point to = draft-ietf-mmusic-ice-dualstack-fairness-02. >=20 > - Sec 3.4 - >=20 > "Third, using TCP only between the endpoint and its relay may result > in less issues with TCP in regards to real-time constraints, e.g. = due > to head of line blocking." >=20 > This is awkwardly phrased. I would suggest something like "Third, = using TCP between the client's TURN server and its peer may result in = more performance problems (due to head-of-line blocking) than using = UDP." >=20 > Alissa > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jul 7 19:10:23 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 2B1F2126FDC; Thu, 7 Jul 2016 19:10:22 -0700 (PDT) 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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708021022.18894.29260.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 19:10:22 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-sdp-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 02:10:22 -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 : SDP for the WebRTC Authors : Suhas Nandakumar Cullen Jennings Filename : draft-ietf-rtcweb-sdp-02.txt Pages : 107 Date : 2016-07-07 Abstract: The Web Real-Time Communication [WebRTC] working group is charged to provide protocol support for direct interactive rich communication using audio, video and data between two peers' web browsers. With in the WebRTC framework, Session Description protocol (SDP) [RFC4566] is used for negotiating session capabilities between the peers. Such a negotiation happens based on the SDP Offer/Answer exchange mechanism described in [RFC3264]. This document provides an informational reference in describing the role of SDP and the Offer/Answer exchange mechanism for the most common WebRTC use-cases. This SDP examples provided in this document is still a work in progress, but it aims to align closest to the evolving standards work. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-sdp-02 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 Thu Jul 7 19:26:22 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69694127078 for ; Thu, 7 Jul 2016 19:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WTrSTT2xm2VI for ; Thu, 7 Jul 2016 19:26:18 -0700 (PDT) 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 8B0E7126FDC for ; Thu, 7 Jul 2016 19:26:18 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id b72so30329416ywa.3 for ; Thu, 07 Jul 2016 19:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=zJhwNNsFQH3vlxfaUkIIxzBNEbgtyDQUC4d+VrGl2M4=; b=HmkwZEI+rW1/65u67Z8lp22U+l69shrRq9J5WrXB/PM6hapMMXgKlBrC9nLWu9kFhW 9S+dmcaV6FbSuLJqlaJy3yT4MFUsSFh8HDwTAfQ9untZ1yToSovMgLyVComhFyWDvTj6 bfjPMJprJS9mi/BMk/4Un/T0YjOxiqny1G2Hg4wtWM1U520AVBtJW4tmlGgur55mLcdc boHwaF7QcFDEyBPaxIloVHSsEVVpmPmX49mxnCEj5K7WaH8ahrt5c23iJg6sOjX7puP5 BWJj4pq3Z7m4o9kog5qy0sWyDH2m0Z+CVoa1jDOdVUjOpCCJJEcQlJv4tkWUqBRo0u5W 4EMg== 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; bh=zJhwNNsFQH3vlxfaUkIIxzBNEbgtyDQUC4d+VrGl2M4=; b=WMGgLB3l77GR4V0OOs2zSmcJIm3uTMcQIrJtkKRp9aAdLjC6R48bZ5DkREQAGMr16u gGZFU64GPXyrMUfwcbjdnhSVzuQLg8WwJ6ttjXv9ESKPJ1Yxlb0VLhQ2Fd8mXrXYWmEU rCqcErLULEVJoH2AhwPBUE4c5XMm2+gnk/OyN4CTGw3BxjsJEzduPfFf/m7up9Csamj7 0EsywEkM3iLfYkcxTrOQHvBEVCgtyKMR5fQnBqIJVLGOviNYDh0aZloHeLEqYMoAUFwN xbqfKLhlsQqcAKDBnGyyGTMclVgQsB08oKqDXbPHg1mPtuohcVsBiAhrSN2kXol8ESrQ FT/Q== X-Gm-Message-State: ALyK8tIgbDQXZUJFGlZYJ4pI4Or5crax/hYmXcVfPmLCncPvH47lmwHv+Y0Y4Ijj1txEVdHtNzuE5xP8BwU4Ng== X-Received: by 10.129.156.78 with SMTP id t75mr2938084ywg.295.1467944777780; Thu, 07 Jul 2016 19:26:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.33.195 with HTTP; Thu, 7 Jul 2016 19:26:17 -0700 (PDT) From: Suhas Nandakumar Date: Fri, 8 Jul 2016 07:56:17 +0530 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0b7ce8079b26053716872d Archived-At: Subject: [rtcweb] draft-ietf-rtcweb-sdp-02 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 02:26:20 -0000 --94eb2c0b7ce8079b26053716872d Content-Type: text/plain; charset=UTF-8 Hello All We have submitted the -02 version of RTCWEB SDP examples draft which went through quite a bit of content re-shuffling and updates to match (attempt) the latest versions of BUNDLE, JSEP and related drafts. Many thanks to Paul for starting the review of the draft that triggered few formatting changes, changes related to consistency of attribute values and their ordering, to enhance the readability throughout the draft. Please refer to the following HTML version while reviewing/reading the draft: https://tools.ietf.org/id/draft-ietf-rtcweb-sdp-02.html [[ It might take a short while for the data-tracker to render the above HTML version though ]] Here is the high-level summary of changes 1. As far as possible, the examples reflect latest BUNDLE and JSEP requirements. 2. SCTP examples are updated 3. Visual markers, separators are added in the SDP table 4. SSRC values, IP Address , Port numbers, CNAMEs are consistent to a great extent now 5. Attributes ordering is consistent across all the examples now 6. RID, Simulcast examples are matched against their latest draft versions. Please give it a read and let us know your comments/feedback. Cheers Suhas/Cullen --94eb2c0b7ce8079b26053716872d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 =C2=A0We have submitte= d the -02 version of RTCWEB SDP examples draft which went through quite a b= it of content re-shuffling and updates to match (attempt) the latest versio= ns of BUNDLE, JSEP and related drafts.=C2=A0

Many = thanks to Paul for starting the review of the draft that triggered few form= atting changes, changes related to consistency of attribute values and thei= r ordering, to enhance the readability throughout the draft.

=
Please refer to the following HTML version while reviewing/readi= ng the draft:=C2=A0


[[ It might take a short wh= ile for the data-tracker to render the above HTML version though ]]

Here is the high-level summary of changes
1. As= far as possible, the examples reflect latest BUNDLE and JSEP requirements.=
2. SCTP examples are updated=C2=A0
3. Visual markers, = separators are added in the SDP table
4. SSRC values, IP Address = , Port numbers, CNAMEs are consistent to a great extent now
5. At= tributes ordering is consistent across all the examples now
6. RI= D, Simulcast examples are matched against their latest draft versions.

Please give it a read and let us know your comments/fe= edback.

Cheers
Suhas/Cullen
--94eb2c0b7ce8079b26053716872d-- From nobody Thu Jul 7 19:48:05 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 8EEF6126FDC; Thu, 7 Jul 2016 19:48:00 -0700 (PDT) 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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708024800.18890.47642.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 19:48:00 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-15.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jul 2016 02:48:00 -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 : Javascript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-15.txt Pages : 88 Date : 2016-07-07 Abstract: This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-15 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 Sat Jul 9 14:27:48 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4055B12D149 for ; Sat, 9 Jul 2016 14:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 e8jVGZrrcjlT for ; Sat, 9 Jul 2016 14:27:45 -0700 (PDT) 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 2CF1212B01E for ; Sat, 9 Jul 2016 14:27:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 131397C8A85; Sat, 9 Jul 2016 23:27:43 +0200 (CEST) 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 qtGHmY5Qetnd; Sat, 9 Jul 2016 23:27:42 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:8c38:e853:481d:3a13] (unknown [IPv6:2001:470:de0a:1:8c38:e853:481d:3a13]) by mork.alvestrand.no (Postfix) with ESMTPSA id E89557C8A84; Sat, 9 Jul 2016 23:27:41 +0200 (CEST) To: Alissa Cooper , rtcweb@ietf.org References: From: Harald Alvestrand Message-ID: <57816C4D.5030609@alvestrand.no> Date: Sat, 9 Jul 2016 23:27:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-transports-14 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jul 2016 21:27:47 -0000 Thank you - I have filed this review as https://github.com/rtcweb-wg/rtcweb-transport/issues/21 and will address it after the Last Call ends. Den 07. juli 2016 23:33, skrev Alissa Cooper: > I have reviewed this document in preparation for IETF last call. It is in good shape and I have requested the last call. > > While the last call is ongoing, I would like to double-check that this document (particularly Section 4) raises no new security considerations that should be documented in Section 6. I'm wondering if there are scenarios where a malicious application could try to game the priority scheme to some ill effect? draft-ietf-tsvwg-rtcweb-qos talks a bit about this, so I'm wondering if anything needs to be said here. > > And I found a couple of nits to be resolved together with any LC comments: > > - Sec 3.2 - Please update the citation to point to draft-ietf-mmusic-ice-dualstack-fairness-02. > > - Sec 3.4 - > > "Third, using TCP only between the endpoint and its relay may result > in less issues with TCP in regards to real-time constraints, e.g. due > to head of line blocking." > > This is awkwardly phrased. I would suggest something like "Third, using TCP between the client's TURN server and its peer may result in more performance problems (due to head-of-line blocking) than using UDP." > > Alissa > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Mon Jul 11 05:22:45 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD4F12D16F for ; Mon, 11 Jul 2016 05:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.954 X-Spam-Level: X-Spam-Status: No, score=-101.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=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 8yqAY94msSY6 for ; Mon, 11 Jul 2016 05:22:30 -0700 (PDT) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451E512D176 for ; Mon, 11 Jul 2016 05:22:20 -0700 (PDT) Received: from smtp19.relay.dfw1a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp19.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id A7E23380269; Mon, 11 Jul 2016 08:22:19 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 62784380204; Mon, 11 Jul 2016 08:22:19 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.82.176.50] ([UNAVAILABLE]. [173.38.117.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Mon, 11 Jul 2016 08:22:19 -0400 From: Cullen Jennings Content-Type: multipart/alternative; boundary="Apple-Mail=_4DF3B869-1E94-4A20-8850-E85B182EF845" Message-Id: <16EBD211-7FAD-43F1-A855-639EC17A17FE@cisco.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Mon, 11 Jul 2016 08:22:18 -0400 References: To: RTCWeb IETF , mmusic WG In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] Tunnelling DTLS in SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 12:22:31 -0000 --Apple-Mail=_4DF3B869-1E94-4A20-8850-E85B182EF845 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Quick questions for folks =E2=80=A6 is an idea that we should explore a = bit deeper before making decisions about it? or should we not proceed? = or should we proceed? Just looking for feedback on where this should go = next=20 Thanks, Cullen > On Apr 18, 2016, at 7:59 AM, Roman Shpount > wrote: >=20 > On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla > wrote: > I wanted to call your attention to a draft I just published with a = possibly stupid > idea. >=20 > https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 = >=20 > A nontrivial fraction of call setup time in WebRTC is the DTLS = handshake. > This document describes how to piggyback the first few handshake = messages > in the SDP offer/answer exchange, thus reducing latency. >=20 > Comments welcome. >=20 >=20 > One other issue I thought off was that with DTLS SDP either offerer or = answerer can start a new DTLS association. When answerer starts a new = session it will have exactly the same problems as forking, since this = will create multiple DTLS sessions with the same client random. This can = be solved with some sort of fallback mechanism to either regular DTLS = setup or to sending a ClientHello in the answer. >=20 > Regards, > _____________ > Roman Shpount > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_4DF3B869-1E94-4A20-8850-E85B182EF845 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Quick questions for = folks =E2=80=A6  is an idea that we should explore a bit deeper = before making decisions about it? or should we not proceed? or should we = proceed? Just looking for feedback on where this should go = next 

Thanks, = Cullen


On Apr 18, 2016, at 7:59 AM, Roman Shpount <roman@telurix.com> = wrote:

On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla = <ekr@rtfm.com> wrote:
I wanted to call your attention to a draft I just published = with a possibly stupid
idea.

https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A = nontrivial fraction of call setup time in WebRTC is the DTLS = handshake.
This document describes how to piggyback = the first few handshake messages
in the SDP = offer/answer exchange, thus reducing latency.

Comments welcome.


One other issue I thought off was that = with DTLS SDP either offerer or answerer can start a new DTLS = association. When answerer starts a new session it will have exactly the = same problems as forking, since this will create multiple DTLS sessions = with the same client random. This can be solved with some sort of = fallback mechanism to either regular DTLS setup or to sending a = ClientHello in the answer.

Regards,
_____________
Roman = Shpount
 
_______________________________________________
rtcweb = mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_4DF3B869-1E94-4A20-8850-E85B182EF845-- From nobody Mon Jul 11 06:56:19 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9BD12D19B; Mon, 11 Jul 2016 06:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.589 X-Spam-Level: X-Spam-Status: No, score=-5.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com 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 a4yuxG69NlA0; Mon, 11 Jul 2016 06:56:13 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 25E7A12B00E; Mon, 11 Jul 2016 06:56:13 -0700 (PDT) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u6BDu7fM016116 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Jul 2016 09:56:09 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u6BDu7fM016116 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1468245369; bh=codt3XZDh/bWzSHPBNtCZZFW0FM=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=p9r5ln3E6b9vpgZ8vPMNhTV+1Y0U1t1iiDfYk9nnfleAd+AEJ+277uwLZE1Mvw0nO vsolV3VRXkYpGki3ctFq7bdmgAxVw91wP//jQXE2xw6WVM9sv4bUsO1Xo7uYepP6yd HqDcA43i3zZ/N9n1eZdB6wTBwRH98PyF7luBtWRw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u6BDu7fM016116 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd56.lss.emc.com (RSA Interceptor); Mon, 11 Jul 2016 09:55:49 -0400 Received: from MXHUB315.corp.emc.com (MXHUB315.corp.emc.com [10.146.3.93]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u6BDtsCQ009230 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 11 Jul 2016 09:55:55 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB315.corp.emc.com ([10.146.3.93]) with mapi id 14.03.0266.001; Mon, 11 Jul 2016 09:55:54 -0400 From: "Black, David" To: Michael Welzl , Brian E Carpenter Thread-Topic: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? Thread-Index: AQHRzhJbsZyuYvv6mE+PQ2kNBpP9KZ/5U/cAgAAHhwCAGfiowA== Date: Mon, 11 Jul 2016 13:55:53 +0000 Message-ID: References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> In-Reply-To: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.240.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 13:56:15 -0000 WytydGN3ZWJdDQoNCj4gPj4gV2UgYmVsaWV2ZSB0aGF0IGRyYWZ0LWlldGYtdHN2d2ctcnRjd2Vi LXFvcyBzaG91bGQgc2F5OiBpZiBzZXR0aW5nIHRoZSBEU0NQDQo+IHZhbHVlcyBhcyBwcm9wb3Nl ZCBoZXJlIGNvbnNpc3RlbnRseSBwcm9kdWNlcyBwYWNrZXQgZHJvcHMsIHNlbmRlcnMgc2hvdWxk IGZhbGwNCj4gYmFjayB0byBEU0NQIDAuIFdlYlJUQyBzaG91bGRuJ3QgImZhaWwiIGJlY2F1c2Ug b2YgdGhlIERTQ1AuDQo+ID4NCj4gPiBUaGlzIGlzIGFuIGludGVyZXN0aW5nIGFuZCB3b3JyeWlu ZyByZXN1bHQgaW5kZWVkLCBidXQgaXQncyBpbiBubyB3YXkgc3BlY2lmaWMNCj4gPiB0byBXZWJS VEMuIEkgdGhpbmsgYSBnZW5lcmljIFJGQyAoIkhhcHB5IEV5ZWJhbGxzIHdpdGggRGlmZmVyZW50 aWF0ZWQNCj4gU2VydmljZXMiPykNCj4gPiB3b3VsZCBiZSB0aGUgd2F5IHRvIGdvLg0KPiANCj4g V2VsbCwgaWYgeW91IHVzZSB0aGUgRFNDUCB3aXRoaW4geW91ciBvd24gYWRtaW5pc3RyYXRpdmUg ZG9tYWluIGZvciBEaWZmU2VydiwgeW91DQo+IHNob3VsZCBiZSBzYWZl4oCmLiBzbyBJIGd1ZXNz IHRoaXMgcHJvYmxlbSBtb3N0bHkgbWF0dGVycyBmb3IgdXNhZ2UgYWNyb3NzDQo+IGRvbWFpbnMs IG9yIGV2ZW4gZW5kLXRvLWVuZC4NCj4gPT4gSXQgc2VlbXMgdG8gbWUgdGhhdCBpdOKAmXMgYnJv YWRlciB0aGFuIFdlYlJUQyBpbiBleGFjdGx5IHRoZSBzYW1lIHdheSBhcw0KPiBSRkM3NjU3IGlz IGJyb2FkZXIgdGhhbiBXZWJSVEMuDQoNCldlIGhhdmUgYW4gaW1tZWRpYXRlIGlzc3VlIGFib3V0 IHdoYXQgdG8gYWRkIHRvIHRoZSBydGN3ZWItcW9zIGRyYWZ0LCB3aGljaA0KaXMgSUVTRyBhcHBy b3ZlZCwgYW5kIHdpbGwgZ28gdG8gdGhlIFJGQyBFZGl0b3Igb25jZSB0aGlzIGNvbmNlcm4gaXMg cmVzb2x2ZWQuDQpXaGlsZSBJIGdyZWF0bHkgYXBwcmVjaWF0ZSBNaWNoYWVsJ3Mgc3VnZ2VzdGlv biBvZiB0ZXh0LCBJIHdvbmRlciB3aGV0aGVyIHRoaXMNCmlzIHBhcnQgb2YgYSBsYXJnZXIgcHJv YmxlbSAuLi4NCg0KQ3VsbGVuIHJlY2VudGx5IHNlbnQgYSBtZXNzYWdlIHRvIFRTVldHIGFib3V0 IGluaXRpYWwgdXNlIG9mIGJhbmR3aWR0aCBieSBJQ0UgZm9yIFNUVU46DQoNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdHN2d2cvY3VycmVudC9tc2cxNDQ5Ny5odG1sDQoN ClRoYXQgIG1lc3NhZ2UgYmVnaW5zIHdpdGg6DQoNCj4gV2hlbiBXZWJSVEMgY29ubmVjdGlvbnMg c3RhcnQsIHRoZXkgc2VuZCBhIGJ1bmNoIG9mIFNUVU4gcGFja2V0cyBhcyBwYXJ0IG9mIElDRS4N Cj4gVHlwaWNhbGx5IG1vc3Qgb2YgdGhlc2UgU1RVTiBwYWNrZXRzIGRvIG5vdCBhY3R1YWxseSBy ZWFjaCBhIHZhbGlkIGRlc3RpbmF0aW9uIHNvIHRoZXkNCj4gaGF2ZSAxMDAlIHBhY2tldCBsb3Nz IGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIHNlbmRlci4gVGhpcyBpcyBkaXNjdXNzZWQg bW9yZQ0KPiBpbiBkcmFmdC1qZW5uaW5ncy1pY2UtcnRjd2ViLXRpbWluZy0wMQ0KDQpUaGlzIGZl ZWxzIGxpa2UgcGFydCBvZiB0aGUgc2FtZSBwcm9ibGVtIC0gYmxhY2staG9saW5nIGNhdXNlZCBi eSBEU0NQIHNlbGVjdGlvbiBmZWVscw0KbGlrZSBpdCBjb3VsZCBiZSBkZWFsdCB3aXRoIGFzIHBh cnQgb2YgU1RVTiBwcm9iaW5nLCBhbHRob3VnaCBzb21lIGNhdXRpb24gaXMgaW4gb3JkZXINCiAo ZS5nLiwgaWYgRUYgaXMgdXNlZCB0byBzZXQgdXAgYXVkaW8pLg0KDQpXaGF0J3MgdGhlICJyaWdo dCB3YXkiIHRvIGRlYWwgd2l0aCB0aGlzIHBvc3NpYmlsaXR5IHRoYXQgbm9uLWRlZmF1bHQgRFND UCB1c2FnZSBieQ0KV2ViIFJUQyBtYXkgY2F1c2UgYmxhY2staG9saW5nLCBhbmQgd2hpY2ggZHJh ZnQgc2hvdWxkIHNwZWNpZnkgdGhlIGJsYWNrLWhvbGUtDQphdm9pZGFuY2UgYmVoYXZpb3I/DQoN ClRoYW5rcywgLS1EYXZpZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hh ZWwgV2VsemwNCj4gU2VudDogRnJpZGF5LCBKdW5lIDI0LCAyMDE2IDQ6NTIgUE0NCj4gVG86IEJy aWFuIEUgQ2FycGVudGVyDQo+IENjOiB0c3Z3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Rz dndnXSBGYWxsLWJhY2sgdG8gRFNDUCAwIGluIGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcyA/ DQo+IA0KPiBIaSwNCj4gDQo+IA0KPiA+IE9uIDI0LiBqdW4uIDIwMTYsIGF0IDIyLjI1LCBCcmlh biBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPg0KPiB3cm90ZToNCj4g Pg0KPiA+PiBXZSBiZWxpZXZlIHRoYXQgZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zIHNob3Vs ZCBzYXk6IGlmIHNldHRpbmcgdGhlIERTQ1ANCj4gdmFsdWVzIGFzIHByb3Bvc2VkIGhlcmUgY29u c2lzdGVudGx5IHByb2R1Y2VzIHBhY2tldCBkcm9wcywgc2VuZGVycyBzaG91bGQgZmFsbA0KPiBi YWNrIHRvIERTQ1AgMC4gV2ViUlRDIHNob3VsZG4ndCAiZmFpbCIgYmVjYXVzZSBvZiB0aGUgRFND UC4NCj4gPg0KPiA+IFRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgYW5kIHdvcnJ5aW5nIHJlc3VsdCBp bmRlZWQsIGJ1dCBpdCdzIGluIG5vIHdheSBzcGVjaWZpYw0KPiA+IHRvIFdlYlJUQy4gSSB0aGlu ayBhIGdlbmVyaWMgUkZDICgiSGFwcHkgRXllYmFsbHMgd2l0aCBEaWZmZXJlbnRpYXRlZA0KPiBT ZXJ2aWNlcyI/KQ0KPiA+IHdvdWxkIGJlIHRoZSB3YXkgdG8gZ28uDQo+IA0KPiBXZWxsLCBpZiB5 b3UgdXNlIHRoZSBEU0NQIHdpdGhpbiB5b3VyIG93biBhZG1pbmlzdHJhdGl2ZSBkb21haW4gZm9y IERpZmZTZXJ2LCB5b3UNCj4gc2hvdWxkIGJlIHNhZmXigKYuIHNvIEkgZ3Vlc3MgdGhpcyBwcm9i bGVtIG1vc3RseSBtYXR0ZXJzIGZvciB1c2FnZSBhY3Jvc3MNCj4gZG9tYWlucywgb3IgZXZlbiBl bmQtdG8tZW5kLg0KPiA9PiBJdCBzZWVtcyB0byBtZSB0aGF0IGl04oCZcyBicm9hZGVyIHRoYW4g V2ViUlRDIGluIGV4YWN0bHkgdGhlIHNhbWUgd2F5IGFzDQo+IFJGQzc2NTcgaXMgYnJvYWRlciB0 aGFuIFdlYlJUQy4NCj4gDQo+IEFzIGEgc2lkZSBub3RlLCBJIHRoaW5rIHRoZSB0ZXJtIOKAnEhh cHB5IEV5ZWJhbGxz4oCdIGlzIG1pc2xlYWRpbmcgaGVyZS4gVGhpcyB0ZXJtLCB0bw0KPiBtZSwg aW5kaWNhdGVzIHBhcmFsbGVsIHVzYWdlIG9mIG11bHRpcGxlIHBhY2tldCB0eXBlcyB0byBzZWUg d2hpY2ggb25lKHMpDQo+IHN1Y2NlZWQocykgYW5kIHRoZW4gdHJ5IHRvIG1ha2UgdGhlIGJlc3Qg Y2hvaWNlLg0KPiBUaGlzIGlzbuKAmXQgd2hhdCB5b3Ugd291bGQgZG8gaGVyZSAtIHdl4oCZcmUg dGFsa2luZyBhYm91dCBhIHJhcmUgZmFpbHVyZSBzaXR1YXRpb24uIEl04oCZcw0KPiByZWFsbHkg b25seSBzb21ldGhpbmcgSeKAmWQgc3VnZ2VzdCBhcyBhIGZhbGwtYmFjaywgdXBvbiBzZWVpbmcg Y29tbXVuaWNhdGlvbg0KPiBmYWlsaW5nIGVudGlyZWx5LCBvdmVyIGEgbG9uZ2VyIHBlcmlvZCAo cGVyaGFwcyBpbiBsaW5lIHdpdGggYSBjaXJjdWl0LWJyZWFrZXIpLg0KPiANCj4gDQo+ID4gQnV0 IChhcyB3aXRoIGEgbG90IG9mIHJlY2VudCBkaXNjdXNzaW9uIGFib3V0IElQdjYNCj4gPiBleHRl bnNpb24gaGVhZGVycyBjYXVzaW5nIHBhY2tldCBkcm9wcykgd2UgcmVhbGx5IG5lZWQgdG8gdW5k ZXJzdGFuZCB3aHkNCj4gdGhpcw0KPiA+IGhhcHBlbnMuIElzIGl0IHRyYWZmaWMgcG9saWNpbmcg dGhhdCBmYWlscyB0byByZWNsYXNzaWZ5IGFuZCByZS1tYXJrIHBhY2tldHMsDQo+ID4gbWlzZ3Vp ZGVkIGZpcmV3YWxscywgb3Igd2hhdD8NCj4gDQo+IEkgaGF2ZSBubyBjbHVl4oCmIGJ1dCBhcyBt eSBwcmV2aW91cyBlbWFpbCBzYWlkLCB3ZSBoYXZlIGluZGljYXRpb25zIHRoYXQgdGhpcw0KPiBi ZWhhdmlvciBvY2N1cnJlZCBjbG9zZSB0byB0aGUgc2VuZGVycyAobW9zdCBvZiB0aGVtIGJlaW5n IGluIHBlb3BsZeKAmXMgaG9tZXMpLA0KPiBoZW5jZSBpdOKAmXMgbW9yZSBsaWtlbHkgdGhhdCB0 aGlzIHdhcyBkb25lIGJ5IGEgbWlkZGxlYm94IG9yIGFuIGVkZ2Ugcm91dGVyIHRoYW4NCj4gYnkg YSBjb3JlIHJvdXRlci4NCj4gVGhhdOKAmXMgYXMgbXVjaCBhcyB3ZSBrbm93Li4uDQo+IA0KPiBD aGVlcnMsDQo+IE1pY2hhZWwNCj4gDQo+IA0KPiA+DQo+ID4gUmVnYXJkcw0KPiA+ICAgQnJpYW4N Cj4gPg0KPiA+IE9uIDI1LzA2LzIwMTYgMDA6MTcsIE1pY2hhZWwgV2Vsemwgd3JvdGU6DQo+ID4+ IERlYXIgYWxsLA0KPiA+Pg0KPiA+PiBXZSByZWNlbnRseSBkaWQgRFNDUCByZWxhdGVkIG1lYXN1 cmVtZW50cyB0aGF0IGxlYWQgdXMgdG8gcHJvcG9zZSBhIGNoYW5nZQ0KPiB0byBkcmFmdC1pZXRm LXRzdndnLXJ0Y3dlYi1xb3MuDQo+ID4+IFRoZXNlIG1lYXN1cmVtZW50cyBhcmUgcmVwb3J0ZWQg aW4gdGhpcyBwYXBlcjoNCj4gPj4gaHR0cDovL2hlaW0uaWZpLnVpby5uby9+bWljaGF3ZS9yZXNl YXJjaC9wdWJsaWNhdGlvbnMvYW5ydzE2LQ0KPiBtZWFzdXJlbWVudC5wZGYNCj4gPj4gLi4uIHdo aWNoIHdpbGwgYmUgcHJlc2VudGVkIGF0IHRoZSBBTlJXIHdvcmtzaG9wLCB0aGUgU2F0dXJkYXkg YmVmb3JlIHRoZQ0KPiBJRVRGIG1lZXRpbmcuDQo+ID4+DQo+ID4+IFRoZSBwYXBlciByZXBvcnRz IG9uIHRlc3RzIGJldHdlZW4gcGVvcGxlJ3MgaG9tZXMgYW5kIDMgc2VydmVycyB0aGF0IHdlDQo+ IHJhbiAtIG9uZSBpbiBPcmVnb24gKGFtYXpvbiBjbG91ZCkgYW5kIHR3byBpbiBOb3J3YXkuIFRo aXMgZ2F2ZSB1cyAxODUgZGlzdGluY3QNCj4gcGF0aHMgKElQIGFkZHJlc3MgcGFpcnMpLiBUaGUg dGVzdCB3YXMgYSBUQ1AgaGFuZHNoYWtlLCBkb25lIHdpdGggcmF3IHNvY2tldHMsDQo+IGFuZCB3 ZSBwbGF5ZWQgYXJvdW5kIHdpdGggdmFsdWVzIGluIHRoZSBJUCBoZWFkZXIuIE1lYW53aGlsZSwg UnVuYSAobWFpbg0KPiBhdXRob3IpIGRpZCBzb21lIG1vcmUgdGVzdHMgZnJvbSB2YXJpb3VzIHB1 YmxpYyBwbGFjZXMgZHVyaW5nIGEgdHJpcCBmcm9tIE5vcndheQ0KPiB0byBJbmRpYSwgZXNzZW50 aWFsbHkgY29uZmlybWluZyB0aGUgZmluZGluZyB3ZSBkaXNjdXNzIGhlcmU7IHdlJ2xsIGFzayBm b3IgYSBzbG90IHRvDQo+IHJlcG9ydCBhYm91dCBib3RoIHRoZSBkYXRhIGluIHRoZSBBTlJXIHBh cGVyIGFuZCB0aGUgbmV3ZXIgZGF0YSBpbiB0aGUgTUFQUkcNCj4gc2Vzc2lvbi4NCj4gPj4NCj4g Pj4gVGhlIG51bWJlciBvZiBkYXRhIHBvaW50cyBpc24ndCBleGFjdGx5IGh1Z2UgaW4gYm90aCBj YXNlcywgYnV0IHN0aWxsIHJlbGV2YW50LA0KPiB3ZSBiZWxpZXZlOiBpdCBpcyBhYm91dCBhIHBl cnNpc3RlbnQgZmFpbHVyZSB0aGF0IHdlIHNhdyBvbiBkaWZmZXJlbnQgcGF0aHMsIGFuZCBzbw0K PiB3ZSB0aGluayBpdCdzIHByb2JhYmx5IHJlYXNvbmFibGUgdG8gdGFrZSBpdCBpbnRvIGFjY291 bnQgKGdpdmVuIHRoYXQgYSBmaXggc2hvdWxkbid0DQo+IGJlIHZlcnkgY29tcGxpY2F0ZWQgZWl0 aGVyKS4NCj4gPj4NCj4gPj4gV2UgdXNlZCwgYXMgaW5wdXQsIERTQ1AgdmFsdWVzIGZyb20gdGhl IHRhYmxlIGluIGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcy4NCj4gPj4gSGVyZSBhcmUgc29t ZSBzZW50ZW5jZXMgY29weSArIHBhc3RlZCBmcm9tIG91ciBwYXBlcjoNCj4gPj4NCj4gPj4gKioq DQo+ID4+ICJUbyBtaW5pbWl6ZSB0aGUgY2hhbmNlIHRoYXQgY29uZ2VzdGlvbi1iYXNlZCBkcm9w cyBtYWtlIHVzIGJlbGlldmUgaW4gYQ0KPiBmYWlsdXJlDQo+ID4+IHRvIGNvbW11bmljYXRlIHVz aW5nIGNlcnRhaW4gdmFsdWVzIGluIHRoZSBJUCBoZWFkZXIsIHdlIHJlLXRyaWVkIGZhaWxlZA0K PiBwYWNrZXQNCj4gPj4gZXhjaGFuZ2VzIHVwIHRvIHRocmVlIHRpbWVzLCBhbmQgd2Ugc2VudCBh biBJQ01QIHBhY2tldCBqdXN0IGFoZWFkIG9mIGV2ZXJ5DQo+ID4+IG1lYXN1cmVtZW50IHBhY2tl dC4gV2Ugb25seSBhc3N1bWVkIGEgY29tbXVuaWNhdGlvbiBmYWlsdXJlIHdoZW4gdGhlDQo+IHRl c3QNCj4gPj4gZmFpbGVkIHRocmVlIHRpbWVzIGFuZCB0aGUgSUNNUCBwYWNrZXQgc3VjY2VlZGVk LiINCj4gPj4NCj4gPj4gIkNvbnNpZGVyaW5nIHRhYmxlIDEgaW4gWzZdLCB3ZSBhc3N1bWVkIHRo ZSBmbG93IHR5cGUg4oCcSW50ZXJhY3RpdmUgVmlkZW8gd2l0aA0KPiBvcg0KPiA+PiB3aXRob3V0 IEF1ZGlv4oCdIHdpdGggYXBwbGljYXRpb24gcHJpb3JpdGllcyDigJxWZXJ5IGxvd+KAnSAoRFND UCB2YWx1ZSBDUzEgKDgpKSwNCj4g4oCcTG934oCdDQo+ID4+IChERiAoMCkpIG9yIOKAnE1lZGl1 beKAnSAoQUY0MiAoMzYpKSwgYW5kIGZsb3cgdHlwZSDigJxBdWRpb+KAnSB3aXRoIGFwcGxpY2F0 aW9uDQo+IHByaW9yaXRpeQ0KPiA+PiDigJxIaWdo4oCdIChFRiBQSEIgKDQ2KSkuIg0KPiA+Pg0K PiA+PiAiV2UgZGlkIHNlZSBjb25zaXN0ZW50IHBhY2tldCBkcm9wcyB0b286IG9uIDIzIHBhdGhz IGZvciBEU0NQIHZhbHVlIDgsIDIxDQo+IHBhdGhzDQo+ID4+IGZvciAzNiwgMTkgZm9yIDQ2LiIN Cj4gPj4gKioqDQo+ID4+DQo+ID4+IFdlIGFsc28gc2F3IERTQ1AgdmFsdWUgY2hhbmdlcywgYnV0 IG5vdGhpbmcgdmVyeSBhbGFybWluZyB0aGVyZSAtIGluIG9uZQ0KPiBjYXNlLCBBRjQyIHdhcyBj aGFuZ2VkIHRvIEFGNDEsIHdoaWNoIGlzIGV2ZW4gbmljZSAgOikgICAgIGhvd2V2ZXIsIHRoaXMg Y29uc2lzdGVudA0KPiBkcm9wIGJlaGF2aW9yIHRoYXQgYXBwZWFycyBvbmx5IHdoZW4gdXNpbmcg YSBEU0NQIHZhbHVlICE9IDAgaXNuJ3QgZ29vZCBhdCBhbGwuDQo+IE5vdyB0aGVzZSB0aGluZ3Mg Y291bGQgaW4gcHJpbmNpcGxlIGhhdmUgaGFwcGVuZWQgY2xvc2UgdG8gb3VyIDMgc2VydmVycywN Cj4gbWVhbmluZyB0aGVyZSB3ZXJlIG9ubHkgZmV3IGRldmljZXMgdGhhdCBkaWQgaXQsIGJ1dCBp biBmYWN0IHRoaXMgbWVhc3VyZW1lbnQNCj4gd2FzIGEgcGFydCBvZiBhIGxhcmdlciBtZWFzdXJl bWVudCBjYW1wYWlnbiBpbiB3aGljaCB3ZSBhbHNvIGNoZWNrZWQgd2hlcmUNCj4gc3VjaCBwYWNr ZXQgZHJvcHMgdHlwaWNhbGx5IGhhcHBlbmVkLiBUaGUgcmVzdWx0IHdhczogbW9zdCBzdWNoIGRy b3BzIHNlZW0gdG8NCj4gYmUgY2xvc2UgdG8gdGhlIGNsaWVudCwgd2hpY2ggbWF5IGluZGljYXRl IHRoYXQgdGhlcmUgd2VyZSBpbiBmYWN0IG11bHRpcGxlIHN1Y2gNCj4gYm94ZXMuDQo+ID4+DQo+ ID4+IFdlIGJlbGlldmUgdGhhdCBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3Mgc2hvdWxkIHNh eTogaWYgc2V0dGluZyB0aGUgRFNDUA0KPiB2YWx1ZXMgYXMgcHJvcG9zZWQgaGVyZSBjb25zaXN0 ZW50bHkgcHJvZHVjZXMgcGFja2V0IGRyb3BzLCBzZW5kZXJzIHNob3VsZCBmYWxsDQo+IGJhY2sg dG8gRFNDUCAwLiBXZWJSVEMgc2hvdWxkbid0ICJmYWlsIiBiZWNhdXNlIG9mIHRoZSBEU0NQLg0K PiA+Pg0KPiA+PiBDaGVlcnMsDQo+ID4+IE1pY2hhZWwNCj4gPj4NCj4gPj4NCj4gPg0KDQo= From nobody Mon Jul 11 07:37:08 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DAD12D187; Mon, 11 Jul 2016 07:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 7UX-6R076Lrp; Mon, 11 Jul 2016 07:37:04 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444B712B043; Mon, 11 Jul 2016 07:37:03 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail41.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 11 Jul 2016 16:36:53 +0200 X-IronPort-AV: E=Sophos;i="5.28,346,1464645600"; d="scan'208";a="489203544" Received: from he101655.emea1.cds.t-internal.com ([10.134.226.17]) by qde0ps.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2016 16:34:59 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101655.emea1.cds.t-internal.com (10.134.226.17) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 11 Jul 2016 16:34:28 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1178.000; Mon, 11 Jul 2016 16:34:28 +0200 From: To: , , Thread-Topic: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? Thread-Index: AQHRzhJbsZyuYvv6mE+PQ2kNBpP9KZ/5U/cAgAAHhwCAGfiowIAAC+UA Date: Mon, 11 Jul 2016 14:34:28 +0000 Message-ID: References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.169.95] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: fluffy@cisco.com, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 14:37:07 -0000 SGkgRGF2aWQsDQoNCmFyZSB5b3UgYXNraW5nLCB3aGV0aGVyIHRoZSB0cmVhdG1lbnQgb2YgdW5l eHBlY3RlZCBEU0NQcyANCi0gc2hvdWxkIGJlIGRvY3VtZW50ZWQgd2l0aGluIGRyYWZ0LWlldGYt dHN2d2ctcnRjd2ViLXFvcyBvcg0KLSBzaG91bGQgYmUgZG9jdW1lbnRlZCB3aXRoaW4gZHJhZnQt amVubmluZ3MtaWNlLXJ0Y3dlYi10aW1pbmctMDEgb3INCi0gc2hvdWxkIGJlIGRvY3VtZW50ZWQg d2l0aGluIGEgdG8gYmUgd3JpdHRlbiBkcmFmdC11bmV4cGVjdGVkLWRzY3AtdHJlYXRtZW50Pw0K DQpXZSd2ZSBkaXNjdXNzZWQgYmxlYWNoaW5nIHZzIHRyYW5zcG9ydCBvZiB1bmV4cGVjdGVkIERT Q1BzIHdoaWxlIHdvcmtpbmcgb24gZGlmZnNlcnYtaW50ZXJjb24gYXMgYSBwb3NzaWJsZSBtZWFz dXJlIChidXQgbmV2ZXIgZGlzY3Vzc2VkIGRyb3BwaW5nKS4gSSBmYXZvciBhIHNlcGFyYXRlIGFu ZCBnZW5lcmljIFJGQyBkZWFsaW5nIHdpdGggdGhlIGlzc3VlLCBpZiB0aGF0IGlzIHdoYXQgeW91 IGFzayBmb3IuIEkgdGhpbmsgdGhlIGlzc3VlIG9mIHVuZXhwZWN0ZWQgRFNDUCB0cmVhdG1lbnQg aXMgbm90IHJ0Y3dlYi9TVFVOLy4uLiBzcGVjaWZpYy4gVGhlIHNhbWUgaG9sZHMgZm9yIHRoZSBh dm9pZGFuY2Ugb2YgYmxhY2tob2xpbmcgZHVlIHRvIERTQ1AgbWFya3MuIEhpbnRzIHRvIGF2b2lk IGl0IHNob3VsZCBiZSBwYXJ0IG9mIHRoYXQgZHJhZnQuIA0KDQpEaWRuJ3QgcmVhZCB0aGUgREFS VCB3b3JrIGJlZm9yZSByZXBseWluZywgYnV0IEkgYXNzdW1lIHRoZSBzaXR1YXRpb24gaXNuJ3Qg Y292ZXJlZCBpbiBzdWZmaWNpZW50IGRldGFpbCB0aGVyZS4NCg0KUmVnYXJkcywNCg0KUnVlZGln ZXINCiANCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiB0c3Z3ZyBb bWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9uIEJsYWNrLCBEYXZp ZA0KR2VzZW5kZXQ6IE1vbnRhZywgMTEuIEp1bGkgMjAxNiAxNTo1Ng0KQW46IE1pY2hhZWwgV2Vs emw7IEJyaWFuIEUgQ2FycGVudGVyDQpDYzogQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpOyBydGN3 ZWJAaWV0Zi5vcmc7IHRzdndnQGlldGYub3JnDQpCZXRyZWZmOiBSZTogW3RzdndnXSBGYWxsLWJh Y2sgdG8gRFNDUCAwIGluIGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcyA/DQoNClsrcnRjd2Vi XQ0KDQo+ID4+IFdlIGJlbGlldmUgdGhhdCBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3Mgc2hv dWxkIHNheTogaWYgc2V0dGluZyANCj4gPj4gdGhlIERTQ1ANCj4gdmFsdWVzIGFzIHByb3Bvc2Vk IGhlcmUgY29uc2lzdGVudGx5IHByb2R1Y2VzIHBhY2tldCBkcm9wcywgc2VuZGVycyANCj4gc2hv dWxkIGZhbGwgYmFjayB0byBEU0NQIDAuIFdlYlJUQyBzaG91bGRuJ3QgImZhaWwiIGJlY2F1c2Ug b2YgdGhlIERTQ1AuDQo+ID4NCj4gPiBUaGlzIGlzIGFuIGludGVyZXN0aW5nIGFuZCB3b3JyeWlu ZyByZXN1bHQgaW5kZWVkLCBidXQgaXQncyBpbiBubyANCj4gPiB3YXkgc3BlY2lmaWMgdG8gV2Vi UlRDLiBJIHRoaW5rIGEgZ2VuZXJpYyBSRkMgKCJIYXBweSBFeWViYWxscyB3aXRoIA0KPiA+IERp ZmZlcmVudGlhdGVkDQo+IFNlcnZpY2VzIj8pDQo+ID4gd291bGQgYmUgdGhlIHdheSB0byBnby4N Cj4gDQo+IFdlbGwsIGlmIHlvdSB1c2UgdGhlIERTQ1Agd2l0aGluIHlvdXIgb3duIGFkbWluaXN0 cmF0aXZlIGRvbWFpbiBmb3IgDQo+IERpZmZTZXJ2LCB5b3Ugc2hvdWxkIGJlIHNhZmXigKYuIHNv IEkgZ3Vlc3MgdGhpcyBwcm9ibGVtIG1vc3RseSBtYXR0ZXJzIA0KPiBmb3IgdXNhZ2UgYWNyb3Nz IGRvbWFpbnMsIG9yIGV2ZW4gZW5kLXRvLWVuZC4NCj4gPT4gSXQgc2VlbXMgdG8gbWUgdGhhdCBp dOKAmXMgYnJvYWRlciB0aGFuIFdlYlJUQyBpbiBleGFjdGx5IHRoZSBzYW1lIA0KPiB3YXkgYXMN Cj4gUkZDNzY1NyBpcyBicm9hZGVyIHRoYW4gV2ViUlRDLg0KDQpXZSBoYXZlIGFuIGltbWVkaWF0 ZSBpc3N1ZSBhYm91dCB3aGF0IHRvIGFkZCB0byB0aGUgcnRjd2ViLXFvcyBkcmFmdCwgd2hpY2gg aXMgSUVTRyBhcHByb3ZlZCwgYW5kIHdpbGwgZ28gdG8gdGhlIFJGQyBFZGl0b3Igb25jZSB0aGlz IGNvbmNlcm4gaXMgcmVzb2x2ZWQuDQpXaGlsZSBJIGdyZWF0bHkgYXBwcmVjaWF0ZSBNaWNoYWVs J3Mgc3VnZ2VzdGlvbiBvZiB0ZXh0LCBJIHdvbmRlciB3aGV0aGVyIHRoaXMgaXMgcGFydCBvZiBh IGxhcmdlciBwcm9ibGVtIC4uLg0KDQpDdWxsZW4gcmVjZW50bHkgc2VudCBhIG1lc3NhZ2UgdG8g VFNWV0cgYWJvdXQgaW5pdGlhbCB1c2Ugb2YgYmFuZHdpZHRoIGJ5IElDRSBmb3IgU1RVTjoNCg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90c3Z3Zy9jdXJyZW50L21zZzE0 NDk3Lmh0bWwNCg0KVGhhdCAgbWVzc2FnZSBiZWdpbnMgd2l0aDoNCg0KPiBXaGVuIFdlYlJUQyBj b25uZWN0aW9ucyBzdGFydCwgdGhleSBzZW5kIGEgYnVuY2ggb2YgU1RVTiBwYWNrZXRzIGFzIHBh cnQgb2YgSUNFLg0KPiBUeXBpY2FsbHkgbW9zdCBvZiB0aGVzZSBTVFVOIHBhY2tldHMgZG8gbm90 IGFjdHVhbGx5IHJlYWNoIGEgdmFsaWQgDQo+IGRlc3RpbmF0aW9uIHNvIHRoZXkgaGF2ZSAxMDAl IHBhY2tldCBsb3NzIGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgDQo+IHRoZSBzZW5kZXIuIFRo aXMgaXMgZGlzY3Vzc2VkIG1vcmUgaW4gDQo+IGRyYWZ0LWplbm5pbmdzLWljZS1ydGN3ZWItdGlt aW5nLTAxDQoNClRoaXMgZmVlbHMgbGlrZSBwYXJ0IG9mIHRoZSBzYW1lIHByb2JsZW0gLSBibGFj ay1ob2xpbmcgY2F1c2VkIGJ5IERTQ1Agc2VsZWN0aW9uIGZlZWxzIGxpa2UgaXQgY291bGQgYmUg ZGVhbHQgd2l0aCBhcyBwYXJ0IG9mIFNUVU4gcHJvYmluZywgYWx0aG91Z2ggc29tZSBjYXV0aW9u IGlzIGluIG9yZGVyICAoZS5nLiwgaWYgRUYgaXMgdXNlZCB0byBzZXQgdXAgYXVkaW8pLg0KDQpX aGF0J3MgdGhlICJyaWdodCB3YXkiIHRvIGRlYWwgd2l0aCB0aGlzIHBvc3NpYmlsaXR5IHRoYXQg bm9uLWRlZmF1bHQgRFNDUCB1c2FnZSBieSBXZWIgUlRDIG1heSBjYXVzZSBibGFjay1ob2xpbmcs IGFuZCB3aGljaCBkcmFmdCBzaG91bGQgc3BlY2lmeSB0aGUgYmxhY2staG9sZS0gYXZvaWRhbmNl IGJlaGF2aW9yPw0KDQpUaGFua3MsIC0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBNaWNoYWVsIFdlbHpsDQo+IFNlbnQ6IEZyaWRheSwgSnVuZSAyNCwgMjAxNiA0OjUy IFBNDQo+IFRvOiBCcmlhbiBFIENhcnBlbnRlcg0KPiBDYzogdHN2d2dAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFt0c3Z3Z10gRmFsbC1iYWNrIHRvIERTQ1AgMCBpbiBkcmFmdC1pZXRmLXRzdndn LXJ0Y3dlYi1xb3MgPw0KPiANCj4gSGksDQo+IA0KPiANCj4gPiBPbiAyNC4ganVuLiAyMDE2LCBh dCAyMi4yNSwgQnJpYW4gRSBDYXJwZW50ZXIgDQo+ID4gPGJyaWFuLmUuY2FycGVudGVyQGdtYWls LmNvbT4NCj4gd3JvdGU6DQo+ID4NCj4gPj4gV2UgYmVsaWV2ZSB0aGF0IGRyYWZ0LWlldGYtdHN2 d2ctcnRjd2ViLXFvcyBzaG91bGQgc2F5OiBpZiBzZXR0aW5nIA0KPiA+PiB0aGUgRFNDUA0KPiB2 YWx1ZXMgYXMgcHJvcG9zZWQgaGVyZSBjb25zaXN0ZW50bHkgcHJvZHVjZXMgcGFja2V0IGRyb3Bz LCBzZW5kZXJzIA0KPiBzaG91bGQgZmFsbCBiYWNrIHRvIERTQ1AgMC4gV2ViUlRDIHNob3VsZG4n dCAiZmFpbCIgYmVjYXVzZSBvZiB0aGUgRFNDUC4NCj4gPg0KPiA+IFRoaXMgaXMgYW4gaW50ZXJl c3RpbmcgYW5kIHdvcnJ5aW5nIHJlc3VsdCBpbmRlZWQsIGJ1dCBpdCdzIGluIG5vIA0KPiA+IHdh eSBzcGVjaWZpYyB0byBXZWJSVEMuIEkgdGhpbmsgYSBnZW5lcmljIFJGQyAoIkhhcHB5IEV5ZWJh bGxzIHdpdGggDQo+ID4gRGlmZmVyZW50aWF0ZWQNCj4gU2VydmljZXMiPykNCj4gPiB3b3VsZCBi ZSB0aGUgd2F5IHRvIGdvLg0KPiANCj4gV2VsbCwgaWYgeW91IHVzZSB0aGUgRFNDUCB3aXRoaW4g eW91ciBvd24gYWRtaW5pc3RyYXRpdmUgZG9tYWluIGZvciANCj4gRGlmZlNlcnYsIHlvdSBzaG91 bGQgYmUgc2FmZeKApi4gc28gSSBndWVzcyB0aGlzIHByb2JsZW0gbW9zdGx5IG1hdHRlcnMgDQo+ IGZvciB1c2FnZSBhY3Jvc3MgZG9tYWlucywgb3IgZXZlbiBlbmQtdG8tZW5kLg0KPiA9PiBJdCBz ZWVtcyB0byBtZSB0aGF0IGl04oCZcyBicm9hZGVyIHRoYW4gV2ViUlRDIGluIGV4YWN0bHkgdGhl IHNhbWUgDQo+IHdheSBhcw0KPiBSRkM3NjU3IGlzIGJyb2FkZXIgdGhhbiBXZWJSVEMuDQo+IA0K PiBBcyBhIHNpZGUgbm90ZSwgSSB0aGluayB0aGUgdGVybSDigJxIYXBweSBFeWViYWxsc+KAnSBp cyBtaXNsZWFkaW5nIGhlcmUuIA0KPiBUaGlzIHRlcm0sIHRvIG1lLCBpbmRpY2F0ZXMgcGFyYWxs ZWwgdXNhZ2Ugb2YgbXVsdGlwbGUgcGFja2V0IHR5cGVzIHRvIA0KPiBzZWUgd2hpY2ggb25lKHMp DQo+IHN1Y2NlZWQocykgYW5kIHRoZW4gdHJ5IHRvIG1ha2UgdGhlIGJlc3QgY2hvaWNlLg0KPiBU aGlzIGlzbuKAmXQgd2hhdCB5b3Ugd291bGQgZG8gaGVyZSAtIHdl4oCZcmUgdGFsa2luZyBhYm91 dCBhIHJhcmUgZmFpbHVyZSANCj4gc2l0dWF0aW9uLiBJdOKAmXMgcmVhbGx5IG9ubHkgc29tZXRo aW5nIEnigJlkIHN1Z2dlc3QgYXMgYSBmYWxsLWJhY2ssIHVwb24gDQo+IHNlZWluZyBjb21tdW5p Y2F0aW9uIGZhaWxpbmcgZW50aXJlbHksIG92ZXIgYSBsb25nZXIgcGVyaW9kIChwZXJoYXBzIGlu IGxpbmUgd2l0aCBhIGNpcmN1aXQtYnJlYWtlcikuDQo+IA0KPiANCj4gPiBCdXQgKGFzIHdpdGgg YSBsb3Qgb2YgcmVjZW50IGRpc2N1c3Npb24gYWJvdXQgSVB2NiBleHRlbnNpb24gaGVhZGVycyAN Cj4gPiBjYXVzaW5nIHBhY2tldCBkcm9wcykgd2UgcmVhbGx5IG5lZWQgdG8gdW5kZXJzdGFuZCB3 aHkNCj4gdGhpcw0KPiA+IGhhcHBlbnMuIElzIGl0IHRyYWZmaWMgcG9saWNpbmcgdGhhdCBmYWls cyB0byByZWNsYXNzaWZ5IGFuZCByZS1tYXJrIA0KPiA+IHBhY2tldHMsIG1pc2d1aWRlZCBmaXJl d2FsbHMsIG9yIHdoYXQ/DQo+IA0KPiBJIGhhdmUgbm8gY2x1ZeKApiBidXQgYXMgbXkgcHJldmlv dXMgZW1haWwgc2FpZCwgd2UgaGF2ZSBpbmRpY2F0aW9ucyANCj4gdGhhdCB0aGlzIGJlaGF2aW9y IG9jY3VycmVkIGNsb3NlIHRvIHRoZSBzZW5kZXJzIChtb3N0IG9mIHRoZW0gYmVpbmcgDQo+IGlu IHBlb3BsZeKAmXMgaG9tZXMpLCBoZW5jZSBpdOKAmXMgbW9yZSBsaWtlbHkgdGhhdCB0aGlzIHdh cyBkb25lIGJ5IGEgDQo+IG1pZGRsZWJveCBvciBhbiBlZGdlIHJvdXRlciB0aGFuIGJ5IGEgY29y ZSByb3V0ZXIuDQo+IFRoYXTigJlzIGFzIG11Y2ggYXMgd2Uga25vdy4uLg0KPiANCj4gQ2hlZXJz LA0KPiBNaWNoYWVsDQo+IA0KPiANCj4gPg0KPiA+IFJlZ2FyZHMNCj4gPiAgIEJyaWFuDQo+ID4N Cj4gPiBPbiAyNS8wNi8yMDE2IDAwOjE3LCBNaWNoYWVsIFdlbHpsIHdyb3RlOg0KPiA+PiBEZWFy IGFsbCwNCj4gPj4NCj4gPj4gV2UgcmVjZW50bHkgZGlkIERTQ1AgcmVsYXRlZCBtZWFzdXJlbWVu dHMgdGhhdCBsZWFkIHVzIHRvIHByb3Bvc2UgYSANCj4gPj4gY2hhbmdlDQo+IHRvIGRyYWZ0LWll dGYtdHN2d2ctcnRjd2ViLXFvcy4NCj4gPj4gVGhlc2UgbWVhc3VyZW1lbnRzIGFyZSByZXBvcnRl ZCBpbiB0aGlzIHBhcGVyOg0KPiA+PiBodHRwOi8vaGVpbS5pZmkudWlvLm5vL35taWNoYXdlL3Jl c2VhcmNoL3B1YmxpY2F0aW9ucy9hbnJ3MTYtDQo+IG1lYXN1cmVtZW50LnBkZg0KPiA+PiAuLi4g d2hpY2ggd2lsbCBiZSBwcmVzZW50ZWQgYXQgdGhlIEFOUlcgd29ya3Nob3AsIHRoZSBTYXR1cmRh eSANCj4gPj4gYmVmb3JlIHRoZQ0KPiBJRVRGIG1lZXRpbmcuDQo+ID4+DQo+ID4+IFRoZSBwYXBl ciByZXBvcnRzIG9uIHRlc3RzIGJldHdlZW4gcGVvcGxlJ3MgaG9tZXMgYW5kIDMgc2VydmVycyAN Cj4gPj4gdGhhdCB3ZQ0KPiByYW4gLSBvbmUgaW4gT3JlZ29uIChhbWF6b24gY2xvdWQpIGFuZCB0 d28gaW4gTm9yd2F5LiBUaGlzIGdhdmUgdXMgMTg1IA0KPiBkaXN0aW5jdCBwYXRocyAoSVAgYWRk cmVzcyBwYWlycykuIFRoZSB0ZXN0IHdhcyBhIFRDUCBoYW5kc2hha2UsIGRvbmUgDQo+IHdpdGgg cmF3IHNvY2tldHMsIGFuZCB3ZSBwbGF5ZWQgYXJvdW5kIHdpdGggdmFsdWVzIGluIHRoZSBJUCBo ZWFkZXIuIA0KPiBNZWFud2hpbGUsIFJ1bmEgKG1haW4NCj4gYXV0aG9yKSBkaWQgc29tZSBtb3Jl IHRlc3RzIGZyb20gdmFyaW91cyBwdWJsaWMgcGxhY2VzIGR1cmluZyBhIHRyaXAgDQo+IGZyb20g Tm9yd2F5IHRvIEluZGlhLCBlc3NlbnRpYWxseSBjb25maXJtaW5nIHRoZSBmaW5kaW5nIHdlIGRp c2N1c3MgDQo+IGhlcmU7IHdlJ2xsIGFzayBmb3IgYSBzbG90IHRvIHJlcG9ydCBhYm91dCBib3Ro IHRoZSBkYXRhIGluIHRoZSBBTlJXIA0KPiBwYXBlciBhbmQgdGhlIG5ld2VyIGRhdGEgaW4gdGhl IE1BUFJHIHNlc3Npb24uDQo+ID4+DQo+ID4+IFRoZSBudW1iZXIgb2YgZGF0YSBwb2ludHMgaXNu J3QgZXhhY3RseSBodWdlIGluIGJvdGggY2FzZXMsIGJ1dCANCj4gPj4gc3RpbGwgcmVsZXZhbnQs DQo+IHdlIGJlbGlldmU6IGl0IGlzIGFib3V0IGEgcGVyc2lzdGVudCBmYWlsdXJlIHRoYXQgd2Ug c2F3IG9uIGRpZmZlcmVudCANCj4gcGF0aHMsIGFuZCBzbyB3ZSB0aGluayBpdCdzIHByb2JhYmx5 IHJlYXNvbmFibGUgdG8gdGFrZSBpdCBpbnRvIA0KPiBhY2NvdW50IChnaXZlbiB0aGF0IGEgZml4 IHNob3VsZG4ndCBiZSB2ZXJ5IGNvbXBsaWNhdGVkIGVpdGhlcikuDQo+ID4+DQo+ID4+IFdlIHVz ZWQsIGFzIGlucHV0LCBEU0NQIHZhbHVlcyBmcm9tIHRoZSB0YWJsZSBpbiBkcmFmdC1pZXRmLXRz dndnLXJ0Y3dlYi1xb3MuDQo+ID4+IEhlcmUgYXJlIHNvbWUgc2VudGVuY2VzIGNvcHkgKyBwYXN0 ZWQgZnJvbSBvdXIgcGFwZXI6DQo+ID4+DQo+ID4+ICoqKg0KPiA+PiAiVG8gbWluaW1pemUgdGhl IGNoYW5jZSB0aGF0IGNvbmdlc3Rpb24tYmFzZWQgZHJvcHMgbWFrZSB1cyBiZWxpZXZlIA0KPiA+ PiBpbiBhDQo+IGZhaWx1cmUNCj4gPj4gdG8gY29tbXVuaWNhdGUgdXNpbmcgY2VydGFpbiB2YWx1 ZXMgaW4gdGhlIElQIGhlYWRlciwgd2UgcmUtdHJpZWQgDQo+ID4+IGZhaWxlZA0KPiBwYWNrZXQN Cj4gPj4gZXhjaGFuZ2VzIHVwIHRvIHRocmVlIHRpbWVzLCBhbmQgd2Ugc2VudCBhbiBJQ01QIHBh Y2tldCBqdXN0IGFoZWFkIA0KPiA+PiBvZiBldmVyeSBtZWFzdXJlbWVudCBwYWNrZXQuIFdlIG9u bHkgYXNzdW1lZCBhIGNvbW11bmljYXRpb24gDQo+ID4+IGZhaWx1cmUgd2hlbiB0aGUNCj4gdGVz dA0KPiA+PiBmYWlsZWQgdGhyZWUgdGltZXMgYW5kIHRoZSBJQ01QIHBhY2tldCBzdWNjZWVkZWQu Ig0KPiA+Pg0KPiA+PiAiQ29uc2lkZXJpbmcgdGFibGUgMSBpbiBbNl0sIHdlIGFzc3VtZWQgdGhl IGZsb3cgdHlwZSDigJxJbnRlcmFjdGl2ZSANCj4gPj4gVmlkZW8gd2l0aA0KPiBvcg0KPiA+PiB3 aXRob3V0IEF1ZGlv4oCdIHdpdGggYXBwbGljYXRpb24gcHJpb3JpdGllcyDigJxWZXJ5IGxvd+KA nSAoRFNDUCB2YWx1ZSANCj4gPj4gQ1MxICg4KSksDQo+IOKAnExvd+KAnQ0KPiA+PiAoREYgKDAp KSBvciDigJxNZWRpdW3igJ0gKEFGNDIgKDM2KSksIGFuZCBmbG93IHR5cGUg4oCcQXVkaW/igJ0g d2l0aCANCj4gPj4gYXBwbGljYXRpb24NCj4gcHJpb3JpdGl5DQo+ID4+IOKAnEhpZ2jigJ0gKEVG IFBIQiAoNDYpKS4iDQo+ID4+DQo+ID4+ICJXZSBkaWQgc2VlIGNvbnNpc3RlbnQgcGFja2V0IGRy b3BzIHRvbzogb24gMjMgcGF0aHMgZm9yIERTQ1AgdmFsdWUgDQo+ID4+IDgsIDIxDQo+IHBhdGhz DQo+ID4+IGZvciAzNiwgMTkgZm9yIDQ2LiINCj4gPj4gKioqDQo+ID4+DQo+ID4+IFdlIGFsc28g c2F3IERTQ1AgdmFsdWUgY2hhbmdlcywgYnV0IG5vdGhpbmcgdmVyeSBhbGFybWluZyB0aGVyZSAt IA0KPiA+PiBpbiBvbmUNCj4gY2FzZSwgQUY0MiB3YXMgY2hhbmdlZCB0byBBRjQxLCB3aGljaCBp cyBldmVuIG5pY2UgIDopICAgICBob3dldmVyLCB0aGlzIGNvbnNpc3RlbnQNCj4gZHJvcCBiZWhh dmlvciB0aGF0IGFwcGVhcnMgb25seSB3aGVuIHVzaW5nIGEgRFNDUCB2YWx1ZSAhPSAwIGlzbid0 IGdvb2QgYXQgYWxsLg0KPiBOb3cgdGhlc2UgdGhpbmdzIGNvdWxkIGluIHByaW5jaXBsZSBoYXZl IGhhcHBlbmVkIGNsb3NlIHRvIG91ciAzIA0KPiBzZXJ2ZXJzLCBtZWFuaW5nIHRoZXJlIHdlcmUg b25seSBmZXcgZGV2aWNlcyB0aGF0IGRpZCBpdCwgYnV0IGluIGZhY3QgDQo+IHRoaXMgbWVhc3Vy ZW1lbnQgd2FzIGEgcGFydCBvZiBhIGxhcmdlciBtZWFzdXJlbWVudCBjYW1wYWlnbiBpbiB3aGlj aCANCj4gd2UgYWxzbyBjaGVja2VkIHdoZXJlIHN1Y2ggcGFja2V0IGRyb3BzIHR5cGljYWxseSBo YXBwZW5lZC4gVGhlIHJlc3VsdCANCj4gd2FzOiBtb3N0IHN1Y2ggZHJvcHMgc2VlbSB0byBiZSBj bG9zZSB0byB0aGUgY2xpZW50LCB3aGljaCBtYXkgDQo+IGluZGljYXRlIHRoYXQgdGhlcmUgd2Vy ZSBpbiBmYWN0IG11bHRpcGxlIHN1Y2ggYm94ZXMuDQo+ID4+DQo+ID4+IFdlIGJlbGlldmUgdGhh dCBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3Mgc2hvdWxkIHNheTogaWYgc2V0dGluZyANCj4g Pj4gdGhlIERTQ1ANCj4gdmFsdWVzIGFzIHByb3Bvc2VkIGhlcmUgY29uc2lzdGVudGx5IHByb2R1 Y2VzIHBhY2tldCBkcm9wcywgc2VuZGVycyANCj4gc2hvdWxkIGZhbGwgYmFjayB0byBEU0NQIDAu IFdlYlJUQyBzaG91bGRuJ3QgImZhaWwiIGJlY2F1c2Ugb2YgdGhlIERTQ1AuDQo+ID4+DQo+ID4+ IENoZWVycywNCj4gPj4gTWljaGFlbA0KPiA+Pg0KPiA+Pg0KPiA+DQoNCg== From nobody Mon Jul 11 09:19:21 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AD712B03C for ; Mon, 11 Jul 2016 09:19:15 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 Yfmf5sQJhjbt for ; Mon, 11 Jul 2016 09:19:13 -0700 (PDT) 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 A816412D599 for ; Mon, 11 Jul 2016 09:19:12 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id q83so41305643iod.1 for ; Mon, 11 Jul 2016 09:19:12 -0700 (PDT) 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:from:date:message-id:subject:to :cc; bh=yQugzfB58RESYgJ4U7fopIYcLQnLTyELgXsfFX4oKKI=; b=isuesdAJGJgJJegqn+n6vFQvb6cueUn14U1yTqOpHQT0Naqa/oFhkUvEsJTneWRB9y 0N3XS4nRDazv0pbJi8f3RkvW6zMzoYyyKogidVOxZZsP5XUxrA1KtluHKoSRPwq5j4e/ /AjkXKYY2Uj9RvjPWGdcRaD71kyySzPldlV1EYc7MizYXwQXnHfB/LjZW7if+LOr5RrX sq0zFAO8XMJLTE04CkdcRixTVCXsWHEkAxNxnOPo6KW1UytRcWmJzmxHJi9grrrmvpN9 Ze9dX846vxKbc0GA55A6T+RVMKgcjsc2ELZCF+wP6s8rmFjI3s9JB7uiXBSto4Hwz0/i YzzQ== 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=yQugzfB58RESYgJ4U7fopIYcLQnLTyELgXsfFX4oKKI=; b=LIUysmKPHOftaW15MUF8T9EdxMmcgqVGqy4BWvlqxeiw6RfRZFh0JHVgLGFBvfGrIE 3sNy5Op1+/GAo85MgR2WGMrOk2sMhwNLFzfsVtLhXibjEnPK+ZfAGD00JP/wsV0xle6m G+inFGSK1dJZ7xNULOCj3RSxtWwgNqWWs72krjfwv8pWAZawcxecczRPJPMyeRbKwF0d p3neUHYQcux8w4mI3gsoc1vfQKODeK4RZA3yuOJMSDIx6fIQPP0LtEx8wlIU7K+Niven 7pQPuMesL40BlEP5mruN2GBSc4TR5WejbLo40w+njn6Ph1iYQafmnve2dMYEVX/7eZ0r vckw== X-Gm-Message-State: ALyK8tIIod6wbuoTTRPRBEBran2IKrxHj3CXy3gbgGTAIjtzI4kioPbmupRp2lSmAj/WDw== X-Received: by 10.107.164.202 with SMTP id d71mr20978058ioj.80.1468253951879; Mon, 11 Jul 2016 09:19:11 -0700 (PDT) Received: from mail-it0-f51.google.com (mail-it0-f51.google.com. [209.85.214.51]) by smtp.gmail.com with ESMTPSA id 92sm4195254iok.22.2016.07.11.09.19.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jul 2016 09:19:11 -0700 (PDT) Received: by mail-it0-f51.google.com with SMTP id f6so9944297ith.0; Mon, 11 Jul 2016 09:19:11 -0700 (PDT) X-Received: by 10.36.23.210 with SMTP id 201mr7275369ith.18.1468253950824; Mon, 11 Jul 2016 09:19:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.62.139 with HTTP; Mon, 11 Jul 2016 09:19:10 -0700 (PDT) In-Reply-To: <16EBD211-7FAD-43F1-A855-639EC17A17FE@cisco.com> References: <16EBD211-7FAD-43F1-A855-639EC17A17FE@cisco.com> From: Roman Shpount Date: Mon, 11 Jul 2016 12:19:10 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a114370be2dff9405375e8335 Archived-At: Cc: RTCWeb IETF , mmusic WG Subject: Re: [rtcweb] [MMUSIC] Tunnelling DTLS in SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 16:19:15 -0000 --001a114370be2dff9405375e8335 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would definitely like to proceed with this. There are certain issues related to forking and new associations being setup by the answering party, but I think they are resolvable. On the other hand, the benefits of reduced call setup up time definitely make this worthwhile. _____________ Roman Shpount On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings wrote: > > Quick questions for folks =E2=80=A6 is an idea that we should explore a = bit > deeper before making decisions about it? or should we not proceed? or > should we proceed? Just looking for feedback on where this should go next > > Thanks, Cullen > > > On Apr 18, 2016, at 7:59 AM, Roman Shpount wrote: > > On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla wrote: > >> I wanted to call your attention to a draft I just published with a >> possibly stupid >> idea. >> >> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 >> >> A nontrivial fraction of call setup time in WebRTC is the DTLS handshake= . >> This document describes how to piggyback the first few handshake message= s >> in the SDP offer/answer exchange, thus reducing latency. >> >> Comments welcome. >> >> > One other issue I thought off was that with DTLS SDP either offerer or > answerer can start a new DTLS association. When answerer starts a new > session it will have exactly the same problems as forking, since this wil= l > create multiple DTLS sessions with the same client random. This can be > solved with some sort of fallback mechanism to either regular DTLS setup = or > to sending a ClientHello in the answer. > > Regards, > _____________ > Roman Shpount > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a114370be2dff9405375e8335 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would definitely like to proceed with this. There are ce= rtain issues related to forking and new associations being setup by the ans= wering party, but I think they are resolvable. On the other hand, the benef= its of reduced call setup up time definitely make this worthwhile.

_____________
Roman Shpount
<= /div>
On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jenn= ings <fluffy@cisco.com> wrote:

Quick questions for = folks =E2=80=A6 =C2=A0is an idea that we should explore a bit deeper before= making decisions about it? or should we not proceed? or should we proceed?= Just looking for feedback on where this should go next=C2=A0

Thanks, Cullen


=
On Apr 18, 2016, at 7:59 AM, Roman Shpount <= roman@telurix.com> wrote:

I wanted to call your att= ention to a draft I just published with a possibly stupid
ide= a.


A nontrivial fract= ion of call setup time in WebRTC is the DTLS handshake.
This docu= ment describes how to piggyback the first few handshake messages
= in the SDP offer/answer exchange, thus reducing latency.

Comments welcome.


One other issue I thought off was that with DTLS SDP either offere= r or answerer can start a new DTLS association. When answerer starts a new = session it will have exactly the same problems as forking, since this will = create multiple DTLS sessions with the same client random. This can be solv= ed with some sort of fallback mechanism to either regular DTLS setup or to = sending a ClientHello in the answer.

Regards,
_____________
Roman Shpount
=C2=A0
_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb


________________________________________= _______
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


--001a114370be2dff9405375e8335-- From nobody Mon Jul 11 09:33:40 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5885A12D5AE for ; Mon, 11 Jul 2016 09:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=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 dBsQjW0h8d0m for ; Mon, 11 Jul 2016 09:33:31 -0700 (PDT) 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 DB88112D5C7 for ; Mon, 11 Jul 2016 09:33:30 -0700 (PDT) Received: (qmail 98660 invoked from network); 11 Jul 2016 16:33:28 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 8895 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 11 Jul 2016 16:33:28 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id E16A518A0347; Mon, 11 Jul 2016 17:33:24 +0100 (BST) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id CF8EA18A0627; Mon, 11 Jul 2016 17:33:24 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id AD37F18A0347; Mon, 11 Jul 2016 17:33:24 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4D84090A-9399-4B02-8FA3-F1FE227809B0" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: T H Panton In-Reply-To: Date: Mon, 11 Jul 2016 17:33:23 +0100 Message-Id: <7DF2166A-3AF4-4591-AB25-8C5415875E8D@phonefromhere.com> References: <16EBD211-7FAD-43F1-A855-639EC17A17FE@cisco.com> To: Roman Shpount X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Cullen Jennings , RTCWeb IETF , mmusic WG Subject: Re: [rtcweb] [MMUSIC] Tunnelling DTLS in SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 16:33:34 -0000 --Apple-Mail=_4D84090A-9399-4B02-8FA3-F1FE227809B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Jul 2016, at 17:19, Roman Shpount wrote: >=20 > I would definitely like to proceed with this. There are certain issues = related to forking and new associations being setup by the answering = party, but I think they are resolvable. On the other hand, the benefits = of reduced call setup up time definitely make this worthwhile. As I said (remotely) at the last meeting, =20 I am distinctly _unkeen_ on the aesthetics of this - it ties us to ever = uglier and larger SDP, it breaks software layer separation in the = stacks,=20 it will no doubt presume a single DTLS implementation, it will be _fun_ = to test, and I anticipate it will open some ugly attack vectors to the javascript kiddies.=20 Last I heard EKR was going to experiment with it and come back with a = view on how (in)accurate my doom-saying was.=20 I haven't heard the reply... - If folks want a corridor conversation about this next week in Berlin, = I'll be there. T. >=20 > _____________ > Roman Shpount >=20 > On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings > wrote: >=20 > Quick questions for folks =E2=80=A6 is an idea that we should explore = a bit deeper before making decisions about it? or should we not proceed? = or should we proceed? Just looking for feedback on where this should go = next=20 >=20 > Thanks, Cullen >=20 >=20 >> On Apr 18, 2016, at 7:59 AM, Roman Shpount > wrote: >>=20 >> On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla > wrote: >> I wanted to call your attention to a draft I just published with a = possibly stupid >> idea. >>=20 >> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 = >>=20 >> A nontrivial fraction of call setup time in WebRTC is the DTLS = handshake. >> This document describes how to piggyback the first few handshake = messages >> in the SDP offer/answer exchange, thus reducing latency. >>=20 >> Comments welcome. >>=20 >>=20 >> One other issue I thought off was that with DTLS SDP either offerer = or answerer can start a new DTLS association. When answerer starts a new = session it will have exactly the same problems as forking, since this = will create multiple DTLS sessions with the same client random. This can = be solved with some sort of fallback mechanism to either regular DTLS = setup or to sending a ClientHello in the answer. >>=20 >> Regards, >> _____________ >> Roman Shpount >> =20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb = >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic = >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --Apple-Mail=_4D84090A-9399-4B02-8FA3-F1FE227809B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 11 Jul 2016, at 17:19, Roman Shpount <roman@telurix.com> = wrote:

I would = definitely like to proceed with this. There are certain issues related = to forking and new associations being setup by the answering party, but = I think they are resolvable. On the other hand, the benefits of reduced = call setup up time definitely make this = worthwhile.

As I = said (remotely) at the last meeting,  
I am distinctly = _unkeen_ on the aesthetics of this - it ties us to ever uglier and = larger SDP, it breaks software layer separation in the = stacks, 
it will no doubt presume a single DTLS = implementation, it will be _fun_ to test, and I anticipate it will open = some ugly attack vectors
to the javascript = kiddies. 

Last I heard EKR was going = to experiment with it and come back with a view on how (in)accurate my = doom-saying was. 
I haven't heard the = reply...

- If folks want a corridor = conversation about this next week in Berlin, I'll be = there.

T.


_____________
Roman = Shpount

On Mon, Jul = 11, 2016 at 8:22 AM, Cullen Jennings <fluffy@cisco.com> wrote:

Quick questions for folks =E2=80=A6  is an idea = that we should explore a bit deeper before making decisions about it? or = should we not proceed? or should we proceed? Just looking for feedback = on where this should go next 

Thanks, Cullen


On Apr 18, 2016, at 7:59 AM, Roman Shpount <roman@telurix.com> wrote:

On Mon, Apr 4, 2016 at 9:10 AM, Eric = Rescorla <ekr@rtfm.com> wrote:
I wanted to call your attention to a draft I just published = with a possibly stupid
idea.

https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A = nontrivial fraction of call setup time in WebRTC is the DTLS = handshake.
This document describes how to piggyback = the first few handshake messages
in the SDP = offer/answer exchange, thus reducing latency.

Comments welcome.


One other issue I thought off was that = with DTLS SDP either offerer or answerer can start a new DTLS = association. When answerer starts a new session it will have exactly the = same problems as forking, since this will create multiple DTLS sessions = with the same client random. This can be solved with some sort of = fallback mechanism to either regular DTLS setup or to sending a = ClientHello in the answer.

Regards,
_____________
Roman Shpount
 
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


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


_______________________________________________
rtcweb mailing = list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
= --Apple-Mail=_4D84090A-9399-4B02-8FA3-F1FE227809B0-- From nobody Mon Jul 11 09:59:03 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFF212D182; Mon, 11 Jul 2016 09:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 igR6fTyPXOu4; Mon, 11 Jul 2016 09:58:57 -0700 (PDT) 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 AEE09128E18; Mon, 11 Jul 2016 09:58:56 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-2e-5783d04ee109 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5A.4B.12516.E40D3875; Mon, 11 Jul 2016 18:58:55 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0294.000; Mon, 11 Jul 2016 18:58:54 +0200 From: Christer Holmberg To: T H Panton , Roman Shpount Thread-Topic: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP Thread-Index: AQHR25H7RNZN26dRbUODj/n1LGaMCaATc9/F Date: Mon, 11 Jul 2016 16:58:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4768FEBB@ESESSMB208.ericsson.se> References: <16EBD211-7FAD-43F1-A855-639EC17A17FE@cisco.com> , <7DF2166A-3AF4-4591-AB25-8C5415875E8D@phonefromhere.com> In-Reply-To: <7DF2166A-3AF4-4591-AB25-8C5415875E8D@phonefromhere.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4768FEBBESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7pa7/heZwg0c32S06JrNZTF3+mMVi xoWpzBZr/7WzW1zcfovRgdVjyu+NrB5Llvxk8lgyqZHN49aUggCWKC6blNSczLLUIn27BK6M UzMvsxXsKqmY8/MEewPj3tQuRk4OCQETidvLTrFC2GISF+6tZ+ti5OIQEjjCKHHr3R8mCGcx o8STVfPYuxg5ONgELCS6/2mDNIgIeEos/j+DHcRmFkiT+H2vgxGkRFjAXGLZM6gSC4nZbx8w Q9hGEgvOnmcEsVkEVCWOXlvAAmLzCvhKnGn4wwyx6hSTxPWbT8FWcQq4SnzYEwNSwwh02/dT a5ggVolLNH1ZCXWzgMSSPeeZIWxRiZeP/7FC1ORLzD74jwlivqDEyZlPWCYwisxC0j4LSdks JGUQcQOJL+9vQ9naEssWvmaGsPUlut+fZkIWX8DIvopRtDi1uDg33chYL7UoM7m4OD9PLy+1 ZBMjMAYPbvmtu4Nx9WvHQ4wCHIxKPLwJR5vChVgTy4orcw8xSnAwK4nwzjnbHC7Em5JYWZVa lB9fVJqTWnyIUZqDRUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qBsbW9pe0Gn2lFdlbD8nnh 32oUZ9nJ3A69vfbJVOs59j+VZb/o3vzIPM1CKeJQeuGPrOsrDs6vXudzY8e1dZfNd174JfeC d52mj46nZ/O7JR2xYjuXJiyQe1hu5GVaKHm/7J40++yfa2M/J9ruL5gVWcPeUqkgLBt1JICb VfKKxSulW6eO/3XxVmIpzkg01GIuKk4EABS9Z+y9AgAA Archived-At: Cc: Cullen Jennings , RTCWeb IETF , mmusic WG Subject: Re: [rtcweb] [MMUSIC] Tunnelling DTLS in SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 16:58:59 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4768FEBBESESSMB208erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, All I'll say at this point is that you cannot assume that forking entities = will remove the attribute. You either need to have a fallback procedure in = case of forking, or say that the mechanism MUST NOT be used in environments= where forking can occur (which makes the mechanism more or less useless in= virtually all SIP environments). Regards, Christer Sent from my Windows Phone ________________________________ From: T H Panton Sent: =FD11/=FD07/=FD2016 19:33 To: Roman Shpount Cc: Cullen Jennings; RTCWeb IETF; mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP On 11 Jul 2016, at 17:19, Roman Shpount > wrote: I would definitely like to proceed with this. There are certain issues rela= ted to forking and new associations being setup by the answering party, but= I think they are resolvable. On the other hand, the benefits of reduced ca= ll setup up time definitely make this worthwhile. As I said (remotely) at the last meeting, I am distinctly _unkeen_ on the aesthetics of this - it ties us to ever ugl= ier and larger SDP, it breaks software layer separation in the stacks, it will no doubt presume a single DTLS implementation, it will be _fun_ to = test, and I anticipate it will open some ugly attack vectors to the javascript kiddies. Last I heard EKR was going to experiment with it and come back with a view = on how (in)accurate my doom-saying was. I haven't heard the reply... - If folks want a corridor conversation about this next week in Berlin, I'l= l be there. T. _____________ Roman Shpount On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings > wrote: Quick questions for folks =85 is an idea that we should explore a bit deep= er before making decisions about it? or should we not proceed? or should we= proceed? Just looking for feedback on where this should go next Thanks, Cullen On Apr 18, 2016, at 7:59 AM, Roman Shpount > wrote: On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla > wrote: I wanted to call your attention to a draft I just published with a possibly= stupid idea. https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 A nontrivial fraction of call setup time in WebRTC is the DTLS handshake. This document describes how to piggyback the first few handshake messages in the SDP offer/answer exchange, thus reducing latency. Comments welcome. One other issue I thought off was that with DTLS SDP either offerer or answ= erer can start a new DTLS association. When answerer starts a new session i= t will have exactly the same problems as forking, since this will create mu= ltiple DTLS sessions with the same client random. This can be solved with s= ome sort of fallback mechanism to either regular DTLS setup or to sending a= ClientHello in the answer. Regards, _____________ Roman Shpount _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B4768FEBBESESSMB208erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

All I'll say at this point is that you cannot assume that forking entities = will remove the attribute. You either need to have a fallback procedure in = case of forking, or say that the mechanism MUST NOT be used in environments= where forking can occur (which makes the mechanism more or less useless in virtually all SIP environments= ).

Regards,

Christer


Sent from my Windows Phone
From: T H Panton
Sent: =FD11= /=FD07/=FD2016 19:33
To: Roman Shpount
Cc: Cullen Jennings; RTCWeb IETF; mmusic WG
Subject: Re: [= MMUSIC] [rtcweb]   Tunnelling DTLS in SDP


On 11 Jul 2016, at 17:19, Roman Shpount <roman@telurix.com> wrote:

I would definitely like to proceed with this. There are certain issues rela= ted to forking and new associations being setup by the answering party, but= I think they are resolvable. On the other hand, the benefits of reduced ca= ll setup up time definitely make this worthwhile.

As I said (remotely) at the last meeting,  
I am distinctly _unkeen_ on the aesthetics of this - it ties us to eve= r uglier and larger SDP, it breaks software layer separation in the stacks,=  
it will no doubt presume a single DTLS implementation, it will be _fun= _ to test, and I anticipate it will open some ugly attack vectors
to the javascript kiddies. 

Last I heard EKR was going to experiment with it and come back with a view = on how (in)accurate my doom-saying was. 
I haven't heard the reply...

- If folks want a corridor conversation about this next week in Berlin= , I'll be there.

T.


_____________
Roman Shpount

On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings=  <= fluffy@cisco.com> = wrote:

Quick questions for folks =85  is an idea that we should explore a bit= deeper before making decisions about it? or should we not proceed? or shou= ld we proceed? Just looking for feedback on where this should go next 

Thanks, Cullen


On Apr 18, 2016, at 7:59 AM, Roman Shpount <roman@telurix.com= > wrote:

On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla <ekr@rtfm.com>= ; wrote:
I wanted to call your attention to a draft I just published= with a possibly stupid
idea.

https://tools.ietf.org/html/draft-r= escorla-dtls-in-sdp-00

A nontrivial fraction of call setup time in WebRTC is the D= TLS handshake.
This document describes how to piggyback the first few hand= shake messages
in the SDP offer/answer exchange, thus reducing latency.

Comments welcome.


One other issue I thought off was that with DTLS SDP either= offerer or answerer can start a new DTLS association. When answerer starts= a new session it will have exactly the same problems as forking, since thi= s will create multiple DTLS sessions with the same client random. This can be solved with some sort of fallback= mechanism to either regular DTLS setup or to sending a ClientHello in the = answer.

Regards,
_____________
Roman Shpount
 
_______________________________________________
rtcweb mailing list
rtcweb@ietf= .org
https://www.ietf.org/mailman/listinfo/rtcweb


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic<= /a>


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

--_000_7594FB04B1934943A5C02806D1A2204B4768FEBBESESSMB208erics_-- From nobody Mon Jul 11 10:12:01 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0CE12D5C9 for ; Mon, 11 Jul 2016 10:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com 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 tknbN2PkM282 for ; Mon, 11 Jul 2016 10:11:54 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 489E012D0C7 for ; Mon, 11 Jul 2016 10:11:54 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id l125so98014732ywb.2 for ; Mon, 11 Jul 2016 10:11:54 -0700 (PDT) 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 :cc:content-transfer-encoding; bh=UTt4HIgF58JUBfdQhHwLW6oXqkePBpfRlPz51tUvJPY=; b=Ei6XrCegv38uiw5OcTBH9f91ymYE7g6QXgoAlr7541T+2yMlH8/T6as/nJzZyMWpZJ v0z6ifcp1z9JCFCvgsOaMyaJAyyv6b6vvcWJqoVfWF+zL8a+wLLb8CzpU9LI7GJdezA/ H7JcMjtyXIfQPtmxtNz6FvEmY0U+IEVYNsl7fmedO9N2p4mDxWjqQHX/2Eun7PFriGJY zFAZNvlJDDXskTpN/+oCQdd4lAsXZqvnt7jMBNYZtAKduQ5UoaK5sz6rij3ORuIbZnC5 HcN6YYMqTFVmGuibHHiz/9+0c9c0hrbIe1Q+aw/yEN0s44s1jJ/GaX8Vz67cY4/XYq2N NvMg== 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-transfer-encoding; bh=UTt4HIgF58JUBfdQhHwLW6oXqkePBpfRlPz51tUvJPY=; b=PQFi6uXUzpxnjSBZJRMiw4pVV+4y1M7YhK2hozJaZDa1VQXfDne6Ui7ObmvaQ+HXT0 Yk2RbViyZV9y+ye3ghWOkiQqPp38F5upvDzhli/YPBqyZcDtV/+VY/K5RwDcw3o9nbVj WlRkICbt/qEYD1+ARbfS+Ln0o9kgr3r06bG9tkABQayVB0bNH0Yu/U/3yamJRrxIRfNv K9eWiFpSbmLxzp7Z6liiMOWD/ADXi71dl1LGB6j8S16RZ6LyJkns62LGFoB08W6duvBm UwbIhv/pfyUzgxvmfTwRzi3KBr6PsWWqqvxMeXZ6FOsNve8C+T+8xeKgjbXNSXq4i01X oH2g== X-Gm-Message-State: ALyK8tJbnOmBxiEhGdoYiKOunJG3DK96asOvf6eNieiIgEXzo7pXPz7zDE3YVDIFaxlQZCsRffqN+L3Kup53Kw== X-Received: by 10.37.223.206 with SMTP id w197mr13737594ybg.172.1468257113587; Mon, 11 Jul 2016 10:11:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.33.213 with HTTP; Mon, 11 Jul 2016 10:11:34 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4768FEBB@ESESSMB208.ericsson.se> References: <16EBD211-7FAD-43F1-A855-639EC17A17FE@cisco.com> <7DF2166A-3AF4-4591-AB25-8C5415875E8D@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B4768FEBB@ESESSMB208.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 11 Jul 2016 19:11:34 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Cullen Jennings , RTCWeb IETF , mmusic WG Subject: Re: [rtcweb] [MMUSIC] Tunnelling DTLS in SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 17:11:57 -0000 2016-07-11 18:58 GMT+02:00 Christer Holmberg : > All I'll say at this point is that you cannot assume that forking entitie= s > will remove the attribute. You either need to have a fallback procedure i= n > case of forking, or say that the mechanism MUST NOT be used in environmen= ts > where forking can occur (which makes the mechanism more or less useless i= n > virtually all SIP environments). SIP devices can just ignore this spec like if it was Outbound or GRUU. --=20 I=C3=B1aki Baz Castillo From nobody Mon Jul 11 11:22:45 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E797512D63A; Mon, 11 Jul 2016 11:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.589 X-Spam-Level: X-Spam-Status: No, score=-5.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com 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 VnYLsBNgn-cR; Mon, 11 Jul 2016 11:22:38 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 8A74A12D633; Mon, 11 Jul 2016 11:22:38 -0700 (PDT) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u6BIMZAu006073 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Jul 2016 14:22:36 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u6BIMZAu006073 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1468261356; bh=evR68eDoSOZgRBj7XkvEs8OOjrE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=uPKziJx7IXluywg6NX7x6Dm19uCe+Z9BLwUJr1MdRr9eqRwiZSXfS3fMiX35ujiI9 apHfLpvmOmiioxHKYyWfsbspFpk3kU/rwMBdEc2jNvVIAH9wCX3iCxv4ccmi3d7V9G r5985v5fC+UaNFzBDMwwuPcQk39lR/bNUYsEUgq4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u6BIMZAu006073 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd56.lss.emc.com (RSA Interceptor); Mon, 11 Jul 2016 14:22:19 -0400 Received: from MXHUB309.corp.emc.com (MXHUB309.corp.emc.com [10.146.3.35]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u6BIMPMI006613 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 11 Jul 2016 14:22:25 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB309.corp.emc.com ([10.146.3.35]) with mapi id 14.03.0266.001; Mon, 11 Jul 2016 14:22:24 -0400 From: "Black, David" To: "Ruediger.Geib@telekom.de" , "michawe@ifi.uio.no" , "brian.e.carpenter@gmail.com" Thread-Topic: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? Thread-Index: AQHRzhJbsZyuYvv6mE+PQ2kNBpP9KZ/5U/cAgAAHhwCAGfiowIAAC+UAgABFHwA= Date: Mon, 11 Jul 2016 18:22:23 +0000 Message-ID: References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.97.8.65] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "fluffy@cisco.com" , "Black, David" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 18:22:41 -0000 PiBhcmUgeW91IGFza2luZywgd2hldGhlciB0aGUgdHJlYXRtZW50IG9mIHVuZXhwZWN0ZWQgRFND UHMNCg0KTm8sIEknbSBhc2tpbmcgd2hpY2ggZHJhZnQgc2hvdWxkIGRvY3VtZW50IHdoYXQgYSBX ZWJSVEMgYXBwbGljYXRpb24gb3IgYSBicm93c2VyDQpob3N0aW5nIGEgV2ViUlRDIGFwcGxpY2F0 aW9uIHNob3VsZCBkbyBpbiBvcmRlciB0byBiZSByb2J1c3QgdG8gYmxhY2staG9sZQ0KKHVucmVh Y2hhYmlsaXR5KSBiZWhhdmlvciBjYXVzZWQgYnkgdXNlIG9mIGEgRFNDUCBvdGhlciB0aGFuIDAw MDAwMC4NCg0KPiBEaWRuJ3QgcmVhZCB0aGUgREFSVCB3b3JrIGJlZm9yZSByZXBseWluZywgYnV0 IEkgYXNzdW1lIHRoZSBzaXR1YXRpb24gaXNuJ3QNCj4gY292ZXJlZCBpbiBzdWZmaWNpZW50IGRl dGFpbCB0aGVyZS4NCg0KTm9wZSwgaXQgaXNuJ3QgLi4uDQoNClRoYW5rcywgLS1EYXZpZA0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJ1ZWRpZ2VyLkdlaWJAdGVsZWtv bS5kZSBbbWFpbHRvOlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZV0NCj4gU2VudDogTW9uZGF5LCBK dWx5IDExLCAyMDE2IDEwOjM0IEFNDQo+IFRvOiBCbGFjaywgRGF2aWQ7IG1pY2hhd2VAaWZpLnVp by5ubzsgYnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tDQo+IENjOiBmbHVmZnlAY2lzY28uY29t OyBydGN3ZWJAaWV0Zi5vcmc7IHRzdndnQGlldGYub3JnDQo+IFN1YmplY3Q6IEFXOiBbdHN2d2dd IEZhbGwtYmFjayB0byBEU0NQIDAgaW4gZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zID8NCj4g DQo+IEhpIERhdmlkLA0KPiANCj4gYXJlIHlvdSBhc2tpbmcsIHdoZXRoZXIgdGhlIHRyZWF0bWVu dCBvZiB1bmV4cGVjdGVkIERTQ1BzDQo+IC0gc2hvdWxkIGJlIGRvY3VtZW50ZWQgd2l0aGluIGRy YWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcyBvcg0KPiAtIHNob3VsZCBiZSBkb2N1bWVudGVkIHdp dGhpbiBkcmFmdC1qZW5uaW5ncy1pY2UtcnRjd2ViLXRpbWluZy0wMSBvcg0KPiAtIHNob3VsZCBi ZSBkb2N1bWVudGVkIHdpdGhpbiBhIHRvIGJlIHdyaXR0ZW4gZHJhZnQtdW5leHBlY3RlZC1kc2Nw LQ0KPiB0cmVhdG1lbnQ/DQo+IA0KPiBXZSd2ZSBkaXNjdXNzZWQgYmxlYWNoaW5nIHZzIHRyYW5z cG9ydCBvZiB1bmV4cGVjdGVkIERTQ1BzIHdoaWxlIHdvcmtpbmcgb24NCj4gZGlmZnNlcnYtaW50 ZXJjb24gYXMgYSBwb3NzaWJsZSBtZWFzdXJlIChidXQgbmV2ZXIgZGlzY3Vzc2VkIGRyb3BwaW5n KS4gSSBmYXZvciBhDQo+IHNlcGFyYXRlIGFuZCBnZW5lcmljIFJGQyBkZWFsaW5nIHdpdGggdGhl IGlzc3VlLCBpZiB0aGF0IGlzIHdoYXQgeW91IGFzayBmb3IuIEkgdGhpbmsNCj4gdGhlIGlzc3Vl IG9mIHVuZXhwZWN0ZWQgRFNDUCB0cmVhdG1lbnQgaXMgbm90IHJ0Y3dlYi9TVFVOLy4uLiBzcGVj aWZpYy4gVGhlDQo+IHNhbWUgaG9sZHMgZm9yIHRoZSBhdm9pZGFuY2Ugb2YgYmxhY2tob2xpbmcg ZHVlIHRvIERTQ1AgbWFya3MuIEhpbnRzIHRvIGF2b2lkIGl0DQo+IHNob3VsZCBiZSBwYXJ0IG9m IHRoYXQgZHJhZnQuDQo+IA0KPiBEaWRuJ3QgcmVhZCB0aGUgREFSVCB3b3JrIGJlZm9yZSByZXBs eWluZywgYnV0IEkgYXNzdW1lIHRoZSBzaXR1YXRpb24gaXNuJ3QNCj4gY292ZXJlZCBpbiBzdWZm aWNpZW50IGRldGFpbCB0aGVyZS4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBSdWVkaWdlcg0KPiAN Cj4gDQo+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gVm9uOiB0c3Z3ZyBb bWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9uIEJsYWNrLCBEYXZp ZA0KPiBHZXNlbmRldDogTW9udGFnLCAxMS4gSnVsaSAyMDE2IDE1OjU2DQo+IEFuOiBNaWNoYWVs IFdlbHpsOyBCcmlhbiBFIENhcnBlbnRlcg0KPiBDYzogQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkp OyBydGN3ZWJAaWV0Zi5vcmc7IHRzdndnQGlldGYub3JnDQo+IEJldHJlZmY6IFJlOiBbdHN2d2dd IEZhbGwtYmFjayB0byBEU0NQIDAgaW4gZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zID8NCj4g DQo+IFsrcnRjd2ViXQ0KPiANCj4gPiA+PiBXZSBiZWxpZXZlIHRoYXQgZHJhZnQtaWV0Zi10c3Z3 Zy1ydGN3ZWItcW9zIHNob3VsZCBzYXk6IGlmIHNldHRpbmcNCj4gPiA+PiB0aGUgRFNDUA0KPiA+ IHZhbHVlcyBhcyBwcm9wb3NlZCBoZXJlIGNvbnNpc3RlbnRseSBwcm9kdWNlcyBwYWNrZXQgZHJv cHMsIHNlbmRlcnMNCj4gPiBzaG91bGQgZmFsbCBiYWNrIHRvIERTQ1AgMC4gV2ViUlRDIHNob3Vs ZG4ndCAiZmFpbCIgYmVjYXVzZSBvZiB0aGUgRFNDUC4NCj4gPiA+DQo+ID4gPiBUaGlzIGlzIGFu IGludGVyZXN0aW5nIGFuZCB3b3JyeWluZyByZXN1bHQgaW5kZWVkLCBidXQgaXQncyBpbiBubw0K PiA+ID4gd2F5IHNwZWNpZmljIHRvIFdlYlJUQy4gSSB0aGluayBhIGdlbmVyaWMgUkZDICgiSGFw cHkgRXllYmFsbHMgd2l0aA0KPiA+ID4gRGlmZmVyZW50aWF0ZWQNCj4gPiBTZXJ2aWNlcyI/KQ0K PiA+ID4gd291bGQgYmUgdGhlIHdheSB0byBnby4NCj4gPg0KPiA+IFdlbGwsIGlmIHlvdSB1c2Ug dGhlIERTQ1Agd2l0aGluIHlvdXIgb3duIGFkbWluaXN0cmF0aXZlIGRvbWFpbiBmb3INCj4gPiBE aWZmU2VydiwgeW91IHNob3VsZCBiZSBzYWZl4oCmLiBzbyBJIGd1ZXNzIHRoaXMgcHJvYmxlbSBt b3N0bHkgbWF0dGVycw0KPiA+IGZvciB1c2FnZSBhY3Jvc3MgZG9tYWlucywgb3IgZXZlbiBlbmQt dG8tZW5kLg0KPiA+ID0+IEl0IHNlZW1zIHRvIG1lIHRoYXQgaXTigJlzIGJyb2FkZXIgdGhhbiBX ZWJSVEMgaW4gZXhhY3RseSB0aGUgc2FtZQ0KPiA+IHdheSBhcw0KPiA+IFJGQzc2NTcgaXMgYnJv YWRlciB0aGFuIFdlYlJUQy4NCj4gDQo+IFdlIGhhdmUgYW4gaW1tZWRpYXRlIGlzc3VlIGFib3V0 IHdoYXQgdG8gYWRkIHRvIHRoZSBydGN3ZWItcW9zIGRyYWZ0LCB3aGljaCBpcw0KPiBJRVNHIGFw cHJvdmVkLCBhbmQgd2lsbCBnbyB0byB0aGUgUkZDIEVkaXRvciBvbmNlIHRoaXMgY29uY2VybiBp cyByZXNvbHZlZC4NCj4gV2hpbGUgSSBncmVhdGx5IGFwcHJlY2lhdGUgTWljaGFlbCdzIHN1Z2dl c3Rpb24gb2YgdGV4dCwgSSB3b25kZXIgd2hldGhlciB0aGlzIGlzDQo+IHBhcnQgb2YgYSBsYXJn ZXIgcHJvYmxlbSAuLi4NCj4gDQo+IEN1bGxlbiByZWNlbnRseSBzZW50IGEgbWVzc2FnZSB0byBU U1ZXRyBhYm91dCBpbml0aWFsIHVzZSBvZiBiYW5kd2lkdGggYnkgSUNFDQo+IGZvciBTVFVOOg0K PiANCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90c3Z3Zy9jdXJyZW50 L21zZzE0NDk3Lmh0bWwNCj4gDQo+IFRoYXQgIG1lc3NhZ2UgYmVnaW5zIHdpdGg6DQo+IA0KPiA+ IFdoZW4gV2ViUlRDIGNvbm5lY3Rpb25zIHN0YXJ0LCB0aGV5IHNlbmQgYSBidW5jaCBvZiBTVFVO IHBhY2tldHMgYXMgcGFydCBvZg0KPiBJQ0UuDQo+ID4gVHlwaWNhbGx5IG1vc3Qgb2YgdGhlc2Ug U1RVTiBwYWNrZXRzIGRvIG5vdCBhY3R1YWxseSByZWFjaCBhIHZhbGlkDQo+ID4gZGVzdGluYXRp b24gc28gdGhleSBoYXZlIDEwMCUgcGFja2V0IGxvc3MgZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBv Zg0KPiA+IHRoZSBzZW5kZXIuIFRoaXMgaXMgZGlzY3Vzc2VkIG1vcmUgaW4NCj4gPiBkcmFmdC1q ZW5uaW5ncy1pY2UtcnRjd2ViLXRpbWluZy0wMQ0KPiANCj4gVGhpcyBmZWVscyBsaWtlIHBhcnQg b2YgdGhlIHNhbWUgcHJvYmxlbSAtIGJsYWNrLWhvbGluZyBjYXVzZWQgYnkgRFNDUCBzZWxlY3Rp b24NCj4gZmVlbHMgbGlrZSBpdCBjb3VsZCBiZSBkZWFsdCB3aXRoIGFzIHBhcnQgb2YgU1RVTiBw cm9iaW5nLCBhbHRob3VnaCBzb21lIGNhdXRpb24gaXMNCj4gaW4gb3JkZXIgIChlLmcuLCBpZiBF RiBpcyB1c2VkIHRvIHNldCB1cCBhdWRpbykuDQo+IA0KPiBXaGF0J3MgdGhlICJyaWdodCB3YXki IHRvIGRlYWwgd2l0aCB0aGlzIHBvc3NpYmlsaXR5IHRoYXQgbm9uLWRlZmF1bHQgRFNDUCB1c2Fn ZSBieQ0KPiBXZWIgUlRDIG1heSBjYXVzZSBibGFjay1ob2xpbmcsIGFuZCB3aGljaCBkcmFmdCBz aG91bGQgc3BlY2lmeSB0aGUgYmxhY2staG9sZS0NCj4gYXZvaWRhbmNlIGJlaGF2aW9yPw0KPiAN Cj4gVGhhbmtzLCAtLURhdmlkDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gRnJvbTogdHN2d2cgW21haWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTWljaGFlbCBXZWx6bA0KPiA+IFNlbnQ6IEZyaWRheSwgSnVuZSAyNCwgMjAxNiA0OjUyIFBN DQo+ID4gVG86IEJyaWFuIEUgQ2FycGVudGVyDQo+ID4gQ2M6IHRzdndnQGlldGYub3JnDQo+ID4g U3ViamVjdDogUmU6IFt0c3Z3Z10gRmFsbC1iYWNrIHRvIERTQ1AgMCBpbiBkcmFmdC1pZXRmLXRz dndnLXJ0Y3dlYi1xb3MgPw0KPiA+DQo+ID4gSGksDQo+ID4NCj4gPg0KPiA+ID4gT24gMjQuIGp1 bi4gMjAxNiwgYXQgMjIuMjUsIEJyaWFuIEUgQ2FycGVudGVyDQo+ID4gPiA8YnJpYW4uZS5jYXJw ZW50ZXJAZ21haWwuY29tPg0KPiA+IHdyb3RlOg0KPiA+ID4NCj4gPiA+PiBXZSBiZWxpZXZlIHRo YXQgZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zIHNob3VsZCBzYXk6IGlmIHNldHRpbmcNCj4g PiA+PiB0aGUgRFNDUA0KPiA+IHZhbHVlcyBhcyBwcm9wb3NlZCBoZXJlIGNvbnNpc3RlbnRseSBw cm9kdWNlcyBwYWNrZXQgZHJvcHMsIHNlbmRlcnMNCj4gPiBzaG91bGQgZmFsbCBiYWNrIHRvIERT Q1AgMC4gV2ViUlRDIHNob3VsZG4ndCAiZmFpbCIgYmVjYXVzZSBvZiB0aGUgRFNDUC4NCj4gPiA+ DQo+ID4gPiBUaGlzIGlzIGFuIGludGVyZXN0aW5nIGFuZCB3b3JyeWluZyByZXN1bHQgaW5kZWVk LCBidXQgaXQncyBpbiBubw0KPiA+ID4gd2F5IHNwZWNpZmljIHRvIFdlYlJUQy4gSSB0aGluayBh IGdlbmVyaWMgUkZDICgiSGFwcHkgRXllYmFsbHMgd2l0aA0KPiA+ID4gRGlmZmVyZW50aWF0ZWQN Cj4gPiBTZXJ2aWNlcyI/KQ0KPiA+ID4gd291bGQgYmUgdGhlIHdheSB0byBnby4NCj4gPg0KPiA+ IFdlbGwsIGlmIHlvdSB1c2UgdGhlIERTQ1Agd2l0aGluIHlvdXIgb3duIGFkbWluaXN0cmF0aXZl IGRvbWFpbiBmb3INCj4gPiBEaWZmU2VydiwgeW91IHNob3VsZCBiZSBzYWZl4oCmLiBzbyBJIGd1 ZXNzIHRoaXMgcHJvYmxlbSBtb3N0bHkgbWF0dGVycw0KPiA+IGZvciB1c2FnZSBhY3Jvc3MgZG9t YWlucywgb3IgZXZlbiBlbmQtdG8tZW5kLg0KPiA+ID0+IEl0IHNlZW1zIHRvIG1lIHRoYXQgaXTi gJlzIGJyb2FkZXIgdGhhbiBXZWJSVEMgaW4gZXhhY3RseSB0aGUgc2FtZQ0KPiA+IHdheSBhcw0K PiA+IFJGQzc2NTcgaXMgYnJvYWRlciB0aGFuIFdlYlJUQy4NCj4gPg0KPiA+IEFzIGEgc2lkZSBu b3RlLCBJIHRoaW5rIHRoZSB0ZXJtIOKAnEhhcHB5IEV5ZWJhbGxz4oCdIGlzIG1pc2xlYWRpbmcg aGVyZS4NCj4gPiBUaGlzIHRlcm0sIHRvIG1lLCBpbmRpY2F0ZXMgcGFyYWxsZWwgdXNhZ2Ugb2Yg bXVsdGlwbGUgcGFja2V0IHR5cGVzIHRvDQo+ID4gc2VlIHdoaWNoIG9uZShzKQ0KPiA+IHN1Y2Nl ZWQocykgYW5kIHRoZW4gdHJ5IHRvIG1ha2UgdGhlIGJlc3QgY2hvaWNlLg0KPiA+IFRoaXMgaXNu 4oCZdCB3aGF0IHlvdSB3b3VsZCBkbyBoZXJlIC0gd2XigJlyZSB0YWxraW5nIGFib3V0IGEgcmFy ZSBmYWlsdXJlDQo+ID4gc2l0dWF0aW9uLiBJdOKAmXMgcmVhbGx5IG9ubHkgc29tZXRoaW5nIEni gJlkIHN1Z2dlc3QgYXMgYSBmYWxsLWJhY2ssIHVwb24NCj4gPiBzZWVpbmcgY29tbXVuaWNhdGlv biBmYWlsaW5nIGVudGlyZWx5LCBvdmVyIGEgbG9uZ2VyIHBlcmlvZCAocGVyaGFwcyBpbiBsaW5l IHdpdGgNCj4gYSBjaXJjdWl0LWJyZWFrZXIpLg0KPiA+DQo+ID4NCj4gPiA+IEJ1dCAoYXMgd2l0 aCBhIGxvdCBvZiByZWNlbnQgZGlzY3Vzc2lvbiBhYm91dCBJUHY2IGV4dGVuc2lvbiBoZWFkZXJz DQo+ID4gPiBjYXVzaW5nIHBhY2tldCBkcm9wcykgd2UgcmVhbGx5IG5lZWQgdG8gdW5kZXJzdGFu ZCB3aHkNCj4gPiB0aGlzDQo+ID4gPiBoYXBwZW5zLiBJcyBpdCB0cmFmZmljIHBvbGljaW5nIHRo YXQgZmFpbHMgdG8gcmVjbGFzc2lmeSBhbmQgcmUtbWFyaw0KPiA+ID4gcGFja2V0cywgbWlzZ3Vp ZGVkIGZpcmV3YWxscywgb3Igd2hhdD8NCj4gPg0KPiA+IEkgaGF2ZSBubyBjbHVl4oCmIGJ1dCBh cyBteSBwcmV2aW91cyBlbWFpbCBzYWlkLCB3ZSBoYXZlIGluZGljYXRpb25zDQo+ID4gdGhhdCB0 aGlzIGJlaGF2aW9yIG9jY3VycmVkIGNsb3NlIHRvIHRoZSBzZW5kZXJzIChtb3N0IG9mIHRoZW0g YmVpbmcNCj4gPiBpbiBwZW9wbGXigJlzIGhvbWVzKSwgaGVuY2UgaXTigJlzIG1vcmUgbGlrZWx5 IHRoYXQgdGhpcyB3YXMgZG9uZSBieSBhDQo+ID4gbWlkZGxlYm94IG9yIGFuIGVkZ2Ugcm91dGVy IHRoYW4gYnkgYSBjb3JlIHJvdXRlci4NCj4gPiBUaGF04oCZcyBhcyBtdWNoIGFzIHdlIGtub3cu Li4NCj4gPg0KPiA+IENoZWVycywNCj4gPiBNaWNoYWVsDQo+ID4NCj4gPg0KPiA+ID4NCj4gPiA+ IFJlZ2FyZHMNCj4gPiA+ICAgQnJpYW4NCj4gPiA+DQo+ID4gPiBPbiAyNS8wNi8yMDE2IDAwOjE3 LCBNaWNoYWVsIFdlbHpsIHdyb3RlOg0KPiA+ID4+IERlYXIgYWxsLA0KPiA+ID4+DQo+ID4gPj4g V2UgcmVjZW50bHkgZGlkIERTQ1AgcmVsYXRlZCBtZWFzdXJlbWVudHMgdGhhdCBsZWFkIHVzIHRv IHByb3Bvc2UgYQ0KPiA+ID4+IGNoYW5nZQ0KPiA+IHRvIGRyYWZ0LWlldGYtdHN2d2ctcnRjd2Vi LXFvcy4NCj4gPiA+PiBUaGVzZSBtZWFzdXJlbWVudHMgYXJlIHJlcG9ydGVkIGluIHRoaXMgcGFw ZXI6DQo+ID4gPj4gaHR0cDovL2hlaW0uaWZpLnVpby5uby9+bWljaGF3ZS9yZXNlYXJjaC9wdWJs aWNhdGlvbnMvYW5ydzE2LQ0KPiA+IG1lYXN1cmVtZW50LnBkZg0KPiA+ID4+IC4uLiB3aGljaCB3 aWxsIGJlIHByZXNlbnRlZCBhdCB0aGUgQU5SVyB3b3Jrc2hvcCwgdGhlIFNhdHVyZGF5DQo+ID4g Pj4gYmVmb3JlIHRoZQ0KPiA+IElFVEYgbWVldGluZy4NCj4gPiA+Pg0KPiA+ID4+IFRoZSBwYXBl ciByZXBvcnRzIG9uIHRlc3RzIGJldHdlZW4gcGVvcGxlJ3MgaG9tZXMgYW5kIDMgc2VydmVycw0K PiA+ID4+IHRoYXQgd2UNCj4gPiByYW4gLSBvbmUgaW4gT3JlZ29uIChhbWF6b24gY2xvdWQpIGFu ZCB0d28gaW4gTm9yd2F5LiBUaGlzIGdhdmUgdXMgMTg1DQo+ID4gZGlzdGluY3QgcGF0aHMgKElQ IGFkZHJlc3MgcGFpcnMpLiBUaGUgdGVzdCB3YXMgYSBUQ1AgaGFuZHNoYWtlLCBkb25lDQo+ID4g d2l0aCByYXcgc29ja2V0cywgYW5kIHdlIHBsYXllZCBhcm91bmQgd2l0aCB2YWx1ZXMgaW4gdGhl IElQIGhlYWRlci4NCj4gPiBNZWFud2hpbGUsIFJ1bmEgKG1haW4NCj4gPiBhdXRob3IpIGRpZCBz b21lIG1vcmUgdGVzdHMgZnJvbSB2YXJpb3VzIHB1YmxpYyBwbGFjZXMgZHVyaW5nIGEgdHJpcA0K PiA+IGZyb20gTm9yd2F5IHRvIEluZGlhLCBlc3NlbnRpYWxseSBjb25maXJtaW5nIHRoZSBmaW5k aW5nIHdlIGRpc2N1c3MNCj4gPiBoZXJlOyB3ZSdsbCBhc2sgZm9yIGEgc2xvdCB0byByZXBvcnQg YWJvdXQgYm90aCB0aGUgZGF0YSBpbiB0aGUgQU5SVw0KPiA+IHBhcGVyIGFuZCB0aGUgbmV3ZXIg ZGF0YSBpbiB0aGUgTUFQUkcgc2Vzc2lvbi4NCj4gPiA+Pg0KPiA+ID4+IFRoZSBudW1iZXIgb2Yg ZGF0YSBwb2ludHMgaXNuJ3QgZXhhY3RseSBodWdlIGluIGJvdGggY2FzZXMsIGJ1dA0KPiA+ID4+ IHN0aWxsIHJlbGV2YW50LA0KPiA+IHdlIGJlbGlldmU6IGl0IGlzIGFib3V0IGEgcGVyc2lzdGVu dCBmYWlsdXJlIHRoYXQgd2Ugc2F3IG9uIGRpZmZlcmVudA0KPiA+IHBhdGhzLCBhbmQgc28gd2Ug dGhpbmsgaXQncyBwcm9iYWJseSByZWFzb25hYmxlIHRvIHRha2UgaXQgaW50bw0KPiA+IGFjY291 bnQgKGdpdmVuIHRoYXQgYSBmaXggc2hvdWxkbid0IGJlIHZlcnkgY29tcGxpY2F0ZWQgZWl0aGVy KS4NCj4gPiA+Pg0KPiA+ID4+IFdlIHVzZWQsIGFzIGlucHV0LCBEU0NQIHZhbHVlcyBmcm9tIHRo ZSB0YWJsZSBpbiBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi0NCj4gcW9zLg0KPiA+ID4+IEhlcmUg YXJlIHNvbWUgc2VudGVuY2VzIGNvcHkgKyBwYXN0ZWQgZnJvbSBvdXIgcGFwZXI6DQo+ID4gPj4N Cj4gPiA+PiAqKioNCj4gPiA+PiAiVG8gbWluaW1pemUgdGhlIGNoYW5jZSB0aGF0IGNvbmdlc3Rp b24tYmFzZWQgZHJvcHMgbWFrZSB1cyBiZWxpZXZlDQo+ID4gPj4gaW4gYQ0KPiA+IGZhaWx1cmUN Cj4gPiA+PiB0byBjb21tdW5pY2F0ZSB1c2luZyBjZXJ0YWluIHZhbHVlcyBpbiB0aGUgSVAgaGVh ZGVyLCB3ZSByZS10cmllZA0KPiA+ID4+IGZhaWxlZA0KPiA+IHBhY2tldA0KPiA+ID4+IGV4Y2hh bmdlcyB1cCB0byB0aHJlZSB0aW1lcywgYW5kIHdlIHNlbnQgYW4gSUNNUCBwYWNrZXQganVzdCBh aGVhZA0KPiA+ID4+IG9mIGV2ZXJ5IG1lYXN1cmVtZW50IHBhY2tldC4gV2Ugb25seSBhc3N1bWVk IGEgY29tbXVuaWNhdGlvbg0KPiA+ID4+IGZhaWx1cmUgd2hlbiB0aGUNCj4gPiB0ZXN0DQo+ID4g Pj4gZmFpbGVkIHRocmVlIHRpbWVzIGFuZCB0aGUgSUNNUCBwYWNrZXQgc3VjY2VlZGVkLiINCj4g PiA+Pg0KPiA+ID4+ICJDb25zaWRlcmluZyB0YWJsZSAxIGluIFs2XSwgd2UgYXNzdW1lZCB0aGUg ZmxvdyB0eXBlIOKAnEludGVyYWN0aXZlDQo+ID4gPj4gVmlkZW8gd2l0aA0KPiA+IG9yDQo+ID4g Pj4gd2l0aG91dCBBdWRpb+KAnSB3aXRoIGFwcGxpY2F0aW9uIHByaW9yaXRpZXMg4oCcVmVyeSBs b3figJ0gKERTQ1AgdmFsdWUNCj4gPiA+PiBDUzEgKDgpKSwNCj4gPiDigJxMb3figJ0NCj4gPiA+ PiAoREYgKDApKSBvciDigJxNZWRpdW3igJ0gKEFGNDIgKDM2KSksIGFuZCBmbG93IHR5cGUg4oCc QXVkaW/igJ0gd2l0aA0KPiA+ID4+IGFwcGxpY2F0aW9uDQo+ID4gcHJpb3JpdGl5DQo+ID4gPj4g 4oCcSGlnaOKAnSAoRUYgUEhCICg0NikpLiINCj4gPiA+Pg0KPiA+ID4+ICJXZSBkaWQgc2VlIGNv bnNpc3RlbnQgcGFja2V0IGRyb3BzIHRvbzogb24gMjMgcGF0aHMgZm9yIERTQ1AgdmFsdWUNCj4g PiA+PiA4LCAyMQ0KPiA+IHBhdGhzDQo+ID4gPj4gZm9yIDM2LCAxOSBmb3IgNDYuIg0KPiA+ID4+ ICoqKg0KPiA+ID4+DQo+ID4gPj4gV2UgYWxzbyBzYXcgRFNDUCB2YWx1ZSBjaGFuZ2VzLCBidXQg bm90aGluZyB2ZXJ5IGFsYXJtaW5nIHRoZXJlIC0NCj4gPiA+PiBpbiBvbmUNCj4gPiBjYXNlLCBB RjQyIHdhcyBjaGFuZ2VkIHRvIEFGNDEsIHdoaWNoIGlzIGV2ZW4gbmljZSAgOikgICAgIGhvd2V2 ZXIsIHRoaXMNCj4gY29uc2lzdGVudA0KPiA+IGRyb3AgYmVoYXZpb3IgdGhhdCBhcHBlYXJzIG9u bHkgd2hlbiB1c2luZyBhIERTQ1AgdmFsdWUgIT0gMCBpc24ndCBnb29kIGF0IGFsbC4NCj4gPiBO b3cgdGhlc2UgdGhpbmdzIGNvdWxkIGluIHByaW5jaXBsZSBoYXZlIGhhcHBlbmVkIGNsb3NlIHRv IG91ciAzDQo+ID4gc2VydmVycywgbWVhbmluZyB0aGVyZSB3ZXJlIG9ubHkgZmV3IGRldmljZXMg dGhhdCBkaWQgaXQsIGJ1dCBpbiBmYWN0DQo+ID4gdGhpcyBtZWFzdXJlbWVudCB3YXMgYSBwYXJ0 IG9mIGEgbGFyZ2VyIG1lYXN1cmVtZW50IGNhbXBhaWduIGluIHdoaWNoDQo+ID4gd2UgYWxzbyBj aGVja2VkIHdoZXJlIHN1Y2ggcGFja2V0IGRyb3BzIHR5cGljYWxseSBoYXBwZW5lZC4gVGhlIHJl c3VsdA0KPiA+IHdhczogbW9zdCBzdWNoIGRyb3BzIHNlZW0gdG8gYmUgY2xvc2UgdG8gdGhlIGNs aWVudCwgd2hpY2ggbWF5DQo+ID4gaW5kaWNhdGUgdGhhdCB0aGVyZSB3ZXJlIGluIGZhY3QgbXVs dGlwbGUgc3VjaCBib3hlcy4NCj4gPiA+Pg0KPiA+ID4+IFdlIGJlbGlldmUgdGhhdCBkcmFmdC1p ZXRmLXRzdndnLXJ0Y3dlYi1xb3Mgc2hvdWxkIHNheTogaWYgc2V0dGluZw0KPiA+ID4+IHRoZSBE U0NQDQo+ID4gdmFsdWVzIGFzIHByb3Bvc2VkIGhlcmUgY29uc2lzdGVudGx5IHByb2R1Y2VzIHBh Y2tldCBkcm9wcywgc2VuZGVycw0KPiA+IHNob3VsZCBmYWxsIGJhY2sgdG8gRFNDUCAwLiBXZWJS VEMgc2hvdWxkbid0ICJmYWlsIiBiZWNhdXNlIG9mIHRoZSBEU0NQLg0KPiA+ID4+DQo+ID4gPj4g Q2hlZXJzLA0KPiA+ID4+IE1pY2hhZWwNCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPg0KDQo= From nobody Mon Jul 11 15:41:27 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B836D12B02A for ; Mon, 11 Jul 2016 15:41:23 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 6crO4gWP-74o for ; Mon, 11 Jul 2016 15:41:21 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 02FFD12D08D for ; Mon, 11 Jul 2016 15:41:21 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id w127so6409855ywf.3 for ; Mon, 11 Jul 2016 15:41:20 -0700 (PDT) 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; bh=pa8KOKHuQkqdPMXJ3OimSiXtzmqcfibWJlbxGsUBGvc=; b=pcSN9/RJGLAbmvtdWWB6KBFKF9lbRsnlS9eSc4u2BrrLyLZoAk3aYU4vy3r9DdNJZb yIgndB1/675HnDFN03TW1UYUEzSpYbfSyMlIkmydZC/uXe0GBOfrmnSeYNtoIEG0BGbg r8NGXPbgAyp4UWE9d6u1DAbsJUPlwKlEcASZn0M/jLHKO4f/M084cwgC72bN73HLwlqt Ih5QF7LjiWsUGe+QXC0csYqM6LUnlD4ttfMA7ZfzL6F+13obEeNBFYNspVvFOyHcgSs2 6weaF+T1VxLfX4RUAbK+kflns8xfqw62qkFdYxV5XM1mod7uQmbzmkToGTvWdk5V54rM trEw== 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=pa8KOKHuQkqdPMXJ3OimSiXtzmqcfibWJlbxGsUBGvc=; b=a68eqaNBV/bXAXBuI+DEv4DrreeRiPwFn448KjZpuMvqD+IQOAGRTM4HrAPsu9FuYW u5clT4v3NpIDg+ixHhLY7RmbeKjV5RNVrOE1gbOANkA0wSY/EOsMDDtas4IvRI1/dDcf Ki6w8Hj7N08yc1Pi5vPS70EJXobAGFlBDrMsxSgV/M1iMs3YKR/pPW2p/epvxEqEk0qS n2oCjJqpeB6h6ED09cvXNxEomIcl2vuD9bTA38rHVzy6gDIRYbbTG+bTMKLhleIaiWri YphLYp/egzoI5xPAa4nMWwJKPj1dGiw2YC82nD4fD/dURYwRqvxTcepbIt5Rq6rfEnPp jYUQ== X-Gm-Message-State: ALyK8tLZzCSWr3Wg1IK4Nf6VzIiCYt7RXcJaQh1GP1Vm6wes45LlzECAZWiB43vZs4ixgX/FH12rkZDRNWIppg== X-Received: by 10.37.209.5 with SMTP id i5mr13716680ybg.146.1468276880162; Mon, 11 Jul 2016 15:41:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Mon, 11 Jul 2016 15:40:40 -0700 (PDT) In-Reply-To: <7DF2166A-3AF4-4591-AB25-8C5415875E8D@phonefromhere.com> References: <16EBD211-7FAD-43F1-A855-639EC17A17FE@cisco.com> <7DF2166A-3AF4-4591-AB25-8C5415875E8D@phonefromhere.com> From: Eric Rescorla Date: Mon, 11 Jul 2016 15:40:40 -0700 Message-ID: To: T H Panton Content-Type: multipart/alternative; boundary=94eb2c06fc0adff3f1053763d960 Archived-At: Cc: Cullen Jennings , RTCWeb IETF , mmusic WG Subject: Re: [rtcweb] [MMUSIC] Tunnelling DTLS in SDP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 22:41:24 -0000 --94eb2c06fc0adff3f1053763d960 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2016 at 9:33 AM, T H Panton wrote: > > On 11 Jul 2016, at 17:19, Roman Shpount wrote: > > I would definitely like to proceed with this. There are certain issues > related to forking and new associations being setup by the answering part= y, > but I think they are resolvable. On the other hand, the benefits of reduc= ed > call setup up time definitely make this worthwhile. > > > As I said (remotely) at the last meeting, > I am distinctly _unkeen_ on the aesthetics of this - it ties us to ever > uglier and larger SDP, it breaks software layer separation in the stacks, > it will no doubt presume a single DTLS implementation, it will be _fun_ t= o > test, and I anticipate it will open some ugly attack vectors > to the javascript kiddies. > > Last I heard EKR was going to experiment with it and come back with a vie= w > on how (in)accurate my doom-saying was. > I haven't heard the reply... > We're working on an implementation now but it took a while to divert the staff. -Ekr > > - If folks want a corridor conversation about this next week in Berlin, > I'll be there. > > T. > > > _____________ > Roman Shpount > > On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings wrote= : > >> >> Quick questions for folks =E2=80=A6 is an idea that we should explore a= bit >> deeper before making decisions about it? or should we not proceed? or >> should we proceed? Just looking for feedback on where this should go nex= t >> >> Thanks, Cullen >> >> >> On Apr 18, 2016, at 7:59 AM, Roman Shpount wrote: >> >> On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla wrote: >> >>> I wanted to call your attention to a draft I just published with a >>> possibly stupid >>> idea. >>> >>> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 >>> >>> A nontrivial fraction of call setup time in WebRTC is the DTLS handshak= e. >>> This document describes how to piggyback the first few handshake messag= es >>> in the SDP offer/answer exchange, thus reducing latency. >>> >>> Comments welcome. >>> >>> >> One other issue I thought off was that with DTLS SDP either offerer or >> answerer can start a new DTLS association. When answerer starts a new >> session it will have exactly the same problems as forking, since this wi= ll >> create multiple DTLS sessions with the same client random. This can be >> solved with some sort of fallback mechanism to either regular DTLS setup= or >> to sending a ClientHello in the answer. >> >> Regards, >> _____________ >> Roman Shpount >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --94eb2c06fc0adff3f1053763d960 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 11, 2016 at 9:33 AM, T H Panton <tim@phonefromhere.com= > wrote:

= On 11 Jul 2016, at 17:19, Roman Shpount <roman@telurix.com> wrote:

I would definitel= y like to proceed with this. There are certain issues related to forking an= d new associations being setup by the answering party, but I think they are= resolvable. On the other hand, the benefits of reduced call setup up time = definitely make this worthwhile.

As I said (remotely) at the last meeting, =C2=A0
I am di= stinctly _unkeen_ on the aesthetics of this - it ties us to ever uglier and= larger SDP, it breaks software layer separation in the stacks,=C2=A0
=
it will no doubt presume a single DTLS implementation, it will be _fun= _ to test, and I anticipate it will open some ugly attack vectors
to the javascript kiddies.=C2=A0

Last I heard EKR was going to experiment with it and come back with a view= on how (in)accurate my doom-saying was.=C2=A0
I haven't hear= d the reply...

We're workin= g on an implementation now but it took a while to divert the staff.

-Ekr
=C2=A0

- If folks want a = corridor conversation about this next week in Berlin, I'll be there.

T.


_____________
Roman Shpount

On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings=C2=A0<fluff= y@cisco.com>=C2=A0wrote:

Quick questions for folks = =E2=80=A6 =C2=A0is an idea that we should explore a bit deeper before makin= g decisions about it? or should we not proceed? or should we proceed? Just = looking for feedback on where this should go next=C2=A0

= Thanks, Cullen


<= div>
On Apr 18, 2016, at 7:59 AM, Roman Shpount <roman@telurix.com> wrote:
<= br>
<= div>
On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla=C2=A0<ekr@r= tfm.com>=C2=A0wrote:
I wanted to call yo= ur attention to a draft I just published with a possibly stupid
idea.


A nontrivial= fraction of call setup time in WebRTC is the DTLS handshake.
Thi= s document describes how to piggyback the first few handshake messages
in the SDP offer/answer exchange, thus reducing latency.
Comments welcome.

=
One other issue I thought off was that with DTLS SDP either = offerer or answerer can start a new DTLS association. When answerer starts = a new session it will have exactly the same problems as forking, since this= will create multiple DTLS sessions with the same client random. This can b= e solved with some sort of fallback mechanism to either regular DTLS setup = or to sending a ClientHello in the answer.

Regards= ,
_____________
Roman Shpount
=C2=A0
______________________________________= _________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/= rtcweb


___= ____________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


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


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


--94eb2c06fc0adff3f1053763d960-- From nobody Mon Jul 11 16:28:11 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506A412D0E1 for ; Mon, 11 Jul 2016 16:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Db_niTGZpTOe for ; Mon, 11 Jul 2016 16:28:09 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003: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 3D34912B02A for ; Mon, 11 Jul 2016 16:28:09 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id r2so170438414oih.2 for ; Mon, 11 Jul 2016 16:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=FfJNrBKdSFbYr5Edp+MA9TdtMwidmbJJ9OouX5Vr2PY=; b=OF0v9EQULWaj9CQzV/+IHXr6q15Tda9WJhTgNnAFWboaFIIWhGbrQ8qq8iNXo1mi2J SF4nSU+WRBKnFEqXN/DXyH2UHwAaLQRYyK32MFPvXCPTCSAxdW2EVLlauIlz7K3SsDj0 Dj+EQRdDQwQVVUMu6ZceLzufGxJMm9Cj26pwFbE7lZWLrfrIoq7WPvNvvVpxfi9L2LFU 2VQPEhP4Js3pk62JelL2IAQakY5/Ul/4E6NnhhaYrDOz46LLvhPuseXloR61OtOxBGYx 4oSTZni3TEVmAXiBSjQkuV1uHQ7ReGe1v8/2We99DdOblGgjWw872s21croOSKxNcCDv 9FrQ== 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; bh=FfJNrBKdSFbYr5Edp+MA9TdtMwidmbJJ9OouX5Vr2PY=; b=dvy9WimlHBZG1TrEAbOoka6yqeamivCRAr4gYb6gx+gIme43daIS662ZjKe8oFFAGn +P1St81cnFNut/UhI7Y2aLvrFjh9aSfKCM3244np9L5ahmOSXY+ohIF/oGQIOmm5zBEa Spu/2ZXfbfgBNPKQikuH+czWN5golIJVu8onuu/pxrgv01GhF1kp9Qv7j1vIBXuOhV/B 4Rr5wl4s/3T/gg4aB006WsKnSgcifgFr4K2LTPXPMIb+k7gQ+oUbv5dn3z4HO2mcTQj1 eA4zjNaJIH4J8wpYv744+v2OJMroQ00ZmmTtfR+loxvcbTTXpddr3OeR15HejVXjdNLj Eyhw== X-Gm-Message-State: ALyK8tLrwWtT1vRzQ3Adt0cKsXBb8NWpAo1XKgt8XfqeyiukqLY5uzYhFtMwJyXVIB7QcrgaDVEyYqK5uRGkPQ== X-Received: by 10.202.68.6 with SMTP id r6mr11618896oia.53.1468279688516; Mon, 11 Jul 2016 16:28:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Mon, 11 Jul 2016 16:27:37 -0700 (PDT) From: Ted Hardie Date: Mon, 11 Jul 2016 16:27:37 -0700 Message-ID: To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner , Alissa Cooper Content-Type: multipart/alternative; boundary=001a113d6f4643db1d05376481be Archived-At: Subject: [rtcweb] Agenda change: Friday meeting returned to pool X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jul 2016 23:28:10 -0000 --001a113d6f4643db1d05376481be Content-Type: text/plain; charset=UTF-8 Howdy, Fewer of the drafts were updated and fewer reviews received than the chairs expected. Given the very tight timing for this IETF and the overlaps in ART, we have agreed with the ADs to return the Friday slot to the pool for rescheduling. Our current agenda proposal is this: Agenda Administrivia (5 mins) JSEP (90 mins) draft-ietf-rtcweb-sdp (15 mins) Matters from other WGs (10 mins) Comments, edits, and suggestions welcome, Ted, Cullen, Sean --001a113d6f4643db1d05376481be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

Fewer of the drafts were upd= ated and fewer reviews received than the chairs expected.=C2=A0 Given the v= ery tight timing for this IETF and the overlaps in ART, we have agreed with= the ADs to return the Friday slot to the pool for rescheduling.

Our current agenda proposal is this:

Agenda=20
Administrivia (5 mins)
JSEP  (90 mins)
draft-ietf-rtcweb-sdp  (15 mins)
Matters from other WGs (10 mins)

Comments, edits, and sug=
gestions welcome,

Ted, Cullen, Sean
--001a113d6f4643db1d05376481be-- From nobody Tue Jul 12 00:44:57 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F8812D6B8; Tue, 12 Jul 2016 00:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 WeqnFc04yU2p; Tue, 12 Jul 2016 00:44:52 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6865D12D739; Tue, 12 Jul 2016 00:44:07 -0700 (PDT) Received: from [192.168.2.19] (host-2-102-75-137.as13285.net [2.102.75.137]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 3D68E1B001E4; Tue, 12 Jul 2016 08:44:02 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Tue, 12 Jul 2016 08:44:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <648D8616-0AB5-4420-A829-1481B30237F4@erg.abdn.ac.uk> References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> To: "Black, David" Archived-At: Cc: "fluffy@cisco.com" , "Ruediger.Geib@telekom.de" , "tsvwg@ietf.org" , "rtcweb@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 07:44:55 -0000 The DART work warns of the pitfalls.=20 My suggestion is that for protocols using ICE that STUN packets could be use= d for this path check - if this is desired. I am not sure we need to hold th= e current draft for this sort of addition. Gorry On 11 Jul 2016, at 19:22, Black, David wrote: >> are you asking, whether the treatment of unexpected DSCPs >=20 > No, I'm asking which draft should document what a WebRTC application or a b= rowser > hosting a WebRTC application should do in order to be robust to black-hole= > (unreachability) behavior caused by use of a DSCP other than 000000. >=20 >> Didn't read the DART work before replying, but I assume the situation isn= 't >> covered in sufficient detail there. >=20 > Nope, it isn't ... >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] >> Sent: Monday, July 11, 2016 10:34 AM >> To: Black, David; michawe@ifi.uio.no; brian.e.carpenter@gmail.com >> Cc: fluffy@cisco.com; rtcweb@ietf.org; tsvwg@ietf.org >> Subject: AW: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ?= >>=20 >> Hi David, >>=20 >> are you asking, whether the treatment of unexpected DSCPs >> - should be documented within draft-ietf-tsvwg-rtcweb-qos or >> - should be documented within draft-jennings-ice-rtcweb-timing-01 or >> - should be documented within a to be written draft-unexpected-dscp- >> treatment? >>=20 >> We've discussed bleaching vs transport of unexpected DSCPs while working o= n >> diffserv-intercon as a possible measure (but never discussed dropping). I= favor a >> separate and generic RFC dealing with the issue, if that is what you ask f= or. I think >> the issue of unexpected DSCP treatment is not rtcweb/STUN/... specific. T= he >> same holds for the avoidance of blackholing due to DSCP marks. Hints to a= void it >> should be part of that draft. >>=20 >> Didn't read the DART work before replying, but I assume the situation isn= 't >> covered in sufficient detail there. >>=20 >> Regards, >>=20 >> Ruediger >>=20 >>=20 >> -----Urspr=C3=BCngliche Nachricht----- >> Von: tsvwg [mailto:tsvwg-bounces@ietf.org] Im Auftrag von Black, David >> Gesendet: Montag, 11. Juli 2016 15:56 >> An: Michael Welzl; Brian E Carpenter >> Cc: Cullen Jennings (fluffy); rtcweb@ietf.org; tsvwg@ietf.org >> Betreff: Re: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ?= >>=20 >> [+rtcweb] >>=20 >>>>> We believe that draft-ietf-tsvwg-rtcweb-qos should say: if setting >>>>> the DSCP >>> values as proposed here consistently produces packet drops, senders >>> should fall back to DSCP 0. WebRTC shouldn't "fail" because of the DSCP.= >>>>=20 >>>> This is an interesting and worrying result indeed, but it's in no >>>> way specific to WebRTC. I think a generic RFC ("Happy Eyeballs with >>>> Differentiated >>> Services"?) >>>> would be the way to go. >>>=20 >>> Well, if you use the DSCP within your own administrative domain for >>> DiffServ, you should be safe=E2=80=A6. so I guess this problem mostly ma= tters >>> for usage across domains, or even end-to-end. >>> =3D> It seems to me that it=E2=80=99s broader than WebRTC in exactly the= same >>> way as >>> RFC7657 is broader than WebRTC. >>=20 >> We have an immediate issue about what to add to the rtcweb-qos draft, whi= ch is >> IESG approved, and will go to the RFC Editor once this concern is resolve= d. >> While I greatly appreciate Michael's suggestion of text, I wonder whether= this is >> part of a larger problem ... >>=20 >> Cullen recently sent a message to TSVWG about initial use of bandwidth by= ICE >> for STUN: >>=20 >> https://www.ietf.org/mail-archive/web/tsvwg/current/msg14497.html >>=20 >> That message begins with: >>=20 >>> When WebRTC connections start, they send a bunch of STUN packets as part= of >> ICE. >>> Typically most of these STUN packets do not actually reach a valid >>> destination so they have 100% packet loss from the point of view of >>> the sender. This is discussed more in >>> draft-jennings-ice-rtcweb-timing-01 >>=20 >> This feels like part of the same problem - black-holing caused by DSCP se= lection >> feels like it could be dealt with as part of STUN probing, although some c= aution is >> in order (e.g., if EF is used to set up audio). >>=20 >> What's the "right way" to deal with this possibility that non-default DSC= P usage by >> Web RTC may cause black-holing, and which draft should specify the black-= hole- >> avoidance behavior? >>=20 >> Thanks, --David >>=20 >>> -----Original Message----- >>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Michael Welzl >>> Sent: Friday, June 24, 2016 4:52 PM >>> To: Brian E Carpenter >>> Cc: tsvwg@ietf.org >>> Subject: Re: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ?= >>>=20 >>> Hi, >>>=20 >>>=20 >>>> On 24. jun. 2016, at 22.25, Brian E Carpenter >>>> >>> wrote: >>>>=20 >>>>> We believe that draft-ietf-tsvwg-rtcweb-qos should say: if setting >>>>> the DSCP >>> values as proposed here consistently produces packet drops, senders >>> should fall back to DSCP 0. WebRTC shouldn't "fail" because of the DSCP.= >>>>=20 >>>> This is an interesting and worrying result indeed, but it's in no >>>> way specific to WebRTC. I think a generic RFC ("Happy Eyeballs with >>>> Differentiated >>> Services"?) >>>> would be the way to go. >>>=20 >>> Well, if you use the DSCP within your own administrative domain for >>> DiffServ, you should be safe=E2=80=A6. so I guess this problem mostly ma= tters >>> for usage across domains, or even end-to-end. >>> =3D> It seems to me that it=E2=80=99s broader than WebRTC in exactly the= same >>> way as >>> RFC7657 is broader than WebRTC. >>>=20 >>> As a side note, I think the term =E2=80=9CHappy Eyeballs=E2=80=9D is mis= leading here. >>> This term, to me, indicates parallel usage of multiple packet types to >>> see which one(s) >>> succeed(s) and then try to make the best choice. >>> This isn=E2=80=99t what you would do here - we=E2=80=99re talking about a= rare failure >>> situation. It=E2=80=99s really only something I=E2=80=99d suggest as a f= all-back, upon >>> seeing communication failing entirely, over a longer period (perhaps in l= ine with >> a circuit-breaker). >>>=20 >>>=20 >>>> But (as with a lot of recent discussion about IPv6 extension headers >>>> causing packet drops) we really need to understand why >>> this >>>> happens. Is it traffic policing that fails to reclassify and re-mark >>>> packets, misguided firewalls, or what? >>>=20 >>> I have no clue=E2=80=A6 but as my previous email said, we have indicatio= ns >>> that this behavior occurred close to the senders (most of them being >>> in people=E2=80=99s homes), hence it=E2=80=99s more likely that this was= done by a >>> middlebox or an edge router than by a core router. >>> That=E2=80=99s as much as we know... >>>=20 >>> Cheers, >>> Michael >>>=20 >>>=20 >>>>=20 >>>> Regards >>>> Brian >>>>=20 >>>>> On 25/06/2016 00:17, Michael Welzl wrote: >>>>> Dear all, >>>>>=20 >>>>> We recently did DSCP related measurements that lead us to propose a >>>>> change >>> to draft-ietf-tsvwg-rtcweb-qos. >>>>> These measurements are reported in this paper: >>>>> http://heim.ifi.uio.no/~michawe/research/publications/anrw16- >>> measurement.pdf >>>>> ... which will be presented at the ANRW workshop, the Saturday >>>>> before the >>> IETF meeting. >>>>>=20 >>>>> The paper reports on tests between people's homes and 3 servers >>>>> that we >>> ran - one in Oregon (amazon cloud) and two in Norway. This gave us 185 >>> distinct paths (IP address pairs). The test was a TCP handshake, done >>> with raw sockets, and we played around with values in the IP header. >>> Meanwhile, Runa (main >>> author) did some more tests from various public places during a trip >>> from Norway to India, essentially confirming the finding we discuss >>> here; we'll ask for a slot to report about both the data in the ANRW >>> paper and the newer data in the MAPRG session. >>>>>=20 >>>>> The number of data points isn't exactly huge in both cases, but >>>>> still relevant, >>> we believe: it is about a persistent failure that we saw on different >>> paths, and so we think it's probably reasonable to take it into >>> account (given that a fix shouldn't be very complicated either). >>>>>=20 >>>>> We used, as input, DSCP values from the table in draft-ietf-tsvwg-rtcw= eb- >> qos. >>>>> Here are some sentences copy + pasted from our paper: >>>>>=20 >>>>> *** >>>>> "To minimize the chance that congestion-based drops make us believe >>>>> in a >>> failure >>>>> to communicate using certain values in the IP header, we re-tried >>>>> failed >>> packet >>>>> exchanges up to three times, and we sent an ICMP packet just ahead >>>>> of every measurement packet. We only assumed a communication >>>>> failure when the >>> test >>>>> failed three times and the ICMP packet succeeded." >>>>>=20 >>>>> "Considering table 1 in [6], we assumed the flow type =E2=80=9CInterac= tive >>>>> Video with >>> or >>>>> without Audio=E2=80=9D with application priorities =E2=80=9CVery low=E2= =80=9D (DSCP value >>>>> CS1 (8)), >>> =E2=80=9CLow=E2=80=9D >>>>> (DF (0)) or =E2=80=9CMedium=E2=80=9D (AF42 (36)), and flow type =E2=80= =9CAudio=E2=80=9D with >>>>> application >>> prioritiy >>>>> =E2=80=9CHigh=E2=80=9D (EF PHB (46))." >>>>>=20 >>>>> "We did see consistent packet drops too: on 23 paths for DSCP value >>>>> 8, 21 >>> paths >>>>> for 36, 19 for 46." >>>>> *** >>>>>=20 >>>>> We also saw DSCP value changes, but nothing very alarming there - >>>>> in one >>> case, AF42 was changed to AF41, which is even nice :) however, this= >> consistent >>> drop behavior that appears only when using a DSCP value !=3D 0 isn't goo= d at all. >>> Now these things could in principle have happened close to our 3 >>> servers, meaning there were only few devices that did it, but in fact >>> this measurement was a part of a larger measurement campaign in which >>> we also checked where such packet drops typically happened. The result >>> was: most such drops seem to be close to the client, which may >>> indicate that there were in fact multiple such boxes. >>>>>=20 >>>>> We believe that draft-ietf-tsvwg-rtcweb-qos should say: if setting >>>>> the DSCP >>> values as proposed here consistently produces packet drops, senders >>> should fall back to DSCP 0. WebRTC shouldn't "fail" because of the DSCP.= >>>>>=20 >>>>> Cheers, >>>>> Michael >=20 From nobody Tue Jul 12 00:55:38 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDB612D649 for ; Tue, 12 Jul 2016 00:55:36 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 GJYdJib-kJXE for ; Tue, 12 Jul 2016 00:55:34 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 9D47412B062 for ; Tue, 12 Jul 2016 00:55:33 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 070EF428A; Tue, 12 Jul 2016 09:55:30 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_FB92854C-DD99-4452-86D0-D43FE4322720" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 12 Jul 2016 09:55:29 +0200 Message-Id: <3F93402D-B1B1-4FD5-8242-076A5604E551@edvina.net> References: To: Suhas Nandakumar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-sdp-02 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 07:55:37 -0000 --Apple-Mail=_FB92854C-DD99-4452-86D0-D43FE4322720 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi! Some notes from my first reading of this document: * Abstract "This SDP examples provided in this document is still a work in progress, but it aims to align closest to the evolving standards work. =E2=80=9C s/This/The/ s/closest/closely/ (maybe :-) ) * 1. Introduction "For this purpose, SDP is used to construct [RFC3264 ] = Offers/Answers for describing (media and non- media) streams as appropriate for the recipients of the session description to participate in the session. =E2=80=9C I am hesitant to separate =E2=80=9Cmedia and non-media=E2=80=9D so early = in this document. If we refer to the definitions in RFC 3264 there=E2=80=99s only =E2=80=9Cm= edia stream=E2=80=9D and 4566 seems=20 to include everything - not just multimedia - in =E2=80=9Cmedia = stream=E2=80=9D. Do we have a reference for a non-media stream? * Section 3 "[WebRTC <>] proposes JavaScript application to fully specify and = control the signaling plane of a multimedia session as described in the JSEP specification [I-D.ietf-rtcweb-jsep = ]. =E2=80=9C s/application/applications/ Maybe add a third bullet describing SDP=E2=80=99s function to bind the = SDP to the actual media - the ice-pwd=E2=80=99s. There=E2=80=99s a = transitive trust there which we could mention in the bullets. * Section 4 Do we have a definition of a "WebRTC session=E2=80=9D somewhere? "The Offer/Answer [RFC3264 ] model = specifies rule for the bilateral exchange of Session Description Protocol (SDP) messages for creation of multimedia streams. =E2=80=9C s/rule/rules/ I would add =E2=80=9Cbidirectional=E2=80=9D in the front of = =E2=80=9Cmultimedia streams=E2=80=9D "It defines protocol with involved participants exchanging desired session characteristics from each others perspective constructed as SDP to negotiate the session between them.=E2=80=9D This sentence is hard to parse and need a rewrite. Maybe something along =E2=80=9CIt defines a protocol which enables participants of a desired = session to exchange session characteristics, based on a SDP constructed from their own perspective=E2=80=9D I would NOT use the word negotiate here. It=E2=80=99s not really = negotation, it=E2=80=99s an offer/answer exchange=E2=80=A6 It=E2=80=99s really hard = to describe when I=E2=80=99m trying to teach people SDP, but I found that the word =E2=80=9Cnegotiate=E2= =80=9D=20 puts them in the wrong place. Multiple offer/answer exchanges can be seen as a negotiation though. "If the session is accepted the Offer/Answer model guarantees a common view of the multimedia session between the participants.=E2=80=9D After many years of working with SIP and SDP offer/exchanges I=20 would avoid the word =E2=80=9Cguarantees=E2=80=9D in this very sentence. = ;-) "At any time, either participant MAY generate a new SDP offer that updates the session in progress.=E2=80=9D Since this is the brief overview aimed to educate SDP offer/answer, I would rephrase this to: =E2=80=9CAt any time either participant MAY initiate a new offer/answer exchange to update a session in progress by generating a new SDP = offer.=E2=80=9D "With in the context of WebRTC, the Offer/Answer model defines the state-machinery for WebRTC peers to negotiate session descriptions between them during the initial setup stages as well as for eventual session updates.=E2=80=9D There=E2=80=99s the word =E2=80=9Cnegotiate=E2=80=9D again. And you = don=E2=80=99t negotiate SDPs, you negotiate "webrtc sessions=E2=80=9D or =E2=80=9Csessions=E2=80=9D.=20= 5. WebRTC SDP examples The term =E2=80=9Cnon-media=E2=80=9D is used here again. "Supports NAT traversal using ICE mechanism=E2=80=9D I don=E2=80=99t agree that ICE is there to support NAT traversal. It=E2=80= =99s a=20 way to describe it that leads to a lot of misunderstandings. The TURN server supports NAT traversal, ICE is a discovery protocol to find the optimal stream path. ICE is also the way to handle dual stack networks. Maybe rephrasing it would be a good idea to avoid future misunderstandings: =E2=80=9CSupports optimal network path discovery and NAT traversal using = ICE and TURN mechanisms=E2=80=9D Section 5.1: s/Eventhough/Even though/ s/an WebRTC/a WebRTC/ I=E2=80=99ve only glanced over the actual examples, it will need much = more time. Here=E2=80=99s a few quick comments: - a=3Dinactive in 5.2.4 has a reference to RFC 3264. I think a proper = reference would be RFC 4566 SDP - 5.2.5: DTMF is no longer RFC 2833 - it is 4733 now. General: I would like to see some examples using the current IP protocol, not the = legacy IPv4, as well as dual stack examples. - An IPv6 only web browser offering an IPv4 through a relay ice = candidate - A dual stack client - A full IPv6 exchange - maybe switch one of the examples using IPv4 to = IPv6 just to show the syntax of address and port number Regards, /Olle =20 --Apple-Mail=_FB92854C-DD99-4452-86D0-D43FE4322720 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi!

Some = notes from my first reading of this document:

* Abstract
"This SDP examples = provided in this document is still a work in
   progress, but it aims to align =
closest to the evolving standards
   work.
=E2=80=9C
s/This/The/
s/closest/closely/   = (maybe :-) )

* = 1. Introduction
"For this purpose, SDP is used = to
   construct [RFC3264] Offers/Answers for describing (media and non-
   media) streams as appropriate for the recipients of the session
   description to participate in the session.
=E2=80=9C
I am hesitant to separate = =E2=80=9Cmedia and non-media=E2=80=9D so early in this = document.
If we refer to the definitions in RFC = 3264 there=E2=80=99s only =E2=80=9Cmedia stream=E2=80=9D and 4566 = seems 
to include everything - not just = multimedia - in =E2=80=9Cmedia stream=E2=80=9D.

Do we have a reference for a non-media = stream?

* = Section 3
"[WebRTC] proposes JavaScript application to fully specify and = control
   the signaling plane of a multimedia =
session as described in the JSEP
   specification [I-D.ietf-rtcweb-jsep]. =E2=80=9C

s/application/applications/

Maybe add a third bullet describing SDP=E2=80=99=
s function to bind the SDP
to the actual media - the ice-pwd=E2=80=99s. =
There=E2=80=99s a transitive trust
there which we could =
mention in the bullets.

* Section 4
Do we have a =
definition of a "WebRTC session=E2=80=9D somewhere?

"The Offer/Answer [RFC3264] model specifies =
rule for the bilateral
   exchange of Session =
Description Protocol (SDP) messages for creation
   of multimedia streams.
=E2=80=9C
s/rule/rules/
I would add = =E2=80=9Cbidirectional=E2=80=9D in the front of =E2=80=9Cmultimedia = streams=E2=80=9D

"It= defines protocol with involved
   participants =
exchanging desired session characteristics from each
   others perspective constructed as SDP to negotiate the session
   between them.=E2=80=9D
This sentence is hard to parse and need a =
rewrite. Maybe something along

=E2=80=9CIt defines =
a protocol which enables participants of a desired session
to exchange session =
characteristics, based on a SDP constructed
from their own =
perspective=E2=80=9D

I would NOT use the word =
negotiate here. It=E2=80=99s not really negotation,
it=E2=80=99s an =
offer/answer exchange=E2=80=A6 It=E2=80=99s really hard to describe when =
I=E2=80=99m
trying to teach people SDP, but I found that =
the word =E2=80=9Cnegotiate=E2=80=9D 
puts them in the wrong =
place. Multiple offer/answer exchanges can be
seen as a negotiation =
though.

"If the session is accepted the =
Offer/Answer model
   guarantees a common view of the =
multimedia session between the
   participants.=E2=80=9D
After many years of working with SIP and SDP =
offer/exchanges I 
would avoid the word =E2=80=9Cguarantees=E2=80=
=9D in this very sentence. ;-)

"At any time, =
either participant MAY generate a new SDP offer that
   updates the =
session in progress.=E2=80=9D
Since this is the brief =
overview aimed to educate SDP offer/answer,
I would rephrase this =
to:
=E2=80=9CAt any time either participant MAY =
initiate a new offer/answer
exchange to update a =
session in progress by generating a new SDP offer.=E2=80=9D

"With in the context of WebRTC, the =
Offer/Answer model defines the
   state-machinery for =
WebRTC peers to negotiate session descriptions
   between them during the initial setup stages as well as for eventual
   session updates.=E2=80=9D
There=E2=80=99s the word =
=E2=80=9Cnegotiate=E2=80=9D again. And you don=E2=80=99t negotiate =
SDPs,
you negotiate "webrtc sessions=E2=80=9D or =
=E2=80=9Csessions=E2=80=9D. 

5. WebRTC SDP =
examples
The term =E2=80=9Cnon-media=E2=80=9D is used =
here again.

"Supports NAT traversal using ICE =
mechanism=E2=80=9D
I don=E2=80=99t =
agree that ICE is there to support NAT traversal. It=E2=80=99s a =

way to describe it that leads to a lot of misunderstandings. =
The TURN
server supports NAT traversal, ICE is a discovery protocol to =
find the
optimal stream path. ICE is also the way to handle dual stack =
networks.
Maybe rephrasing it would be a good idea to =
avoid
future misunderstandings:
=E2=80=9CSupports optimal network =
path discovery and NAT traversal using ICE and TURN =
mechanisms=E2=80=9D

Section =
5.1:
s/Eventhough/Even though/
s/an WebRTC/a WebRTC/


I=E2=80=99ve =
only glanced over the actual examples, it will need much more time. =
Here=E2=80=99s
a few quick comments:

- a=3Dinactive =
in 5.2.4 has a reference to RFC 3264. I think a proper =
reference
  would be RFC 4566 SDP
- 5.2.5: DTMF is no longer RFC 2833 =
- it is 4733 now.


General:
I would like to see some examples =
using the current IP protocol, not the legacy IPv4,
as well as dual =
stack examples.

- An IPv6 only web browser offering =
an IPv4 through a relay ice candidate
- A dual stack =
client
- A full IPv6 exchange - =
maybe switch one of the examples using IPv4 to IPv6
  just to show the syntax of address and =
port number

Regards,
/Olle

 =

= --Apple-Mail=_FB92854C-DD99-4452-86D0-D43FE4322720-- From nobody Tue Jul 12 05:10:34 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410F412D7B3 for ; Tue, 12 Jul 2016 05:10:32 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 35QnDc-jB4AV for ; Tue, 12 Jul 2016 05:10:28 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 AD5A012D784 for ; Tue, 12 Jul 2016 05:10:26 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 853EF428A; Tue, 12 Jul 2016 14:10:23 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2C1B5AF7-2A23-41F9-A8FF-02CF55A00AC6" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <3F93402D-B1B1-4FD5-8242-076A5604E551@edvina.net> Date: Tue, 12 Jul 2016 14:10:23 +0200 Message-Id: References: <3F93402D-B1B1-4FD5-8242-076A5604E551@edvina.net> To: Suhas Nandakumar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-sdp-02 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 12:10:32 -0000 --Apple-Mail=_2C1B5AF7-2A23-41F9-A8FF-02CF55A00AC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 Jul 2016, at 09:55, Olle E. Johansson wrote: >=20 >=20 > General: > I would like to see some examples using the current IP protocol, not = the legacy IPv4, > as well as dual stack examples. >=20 > - An IPv6 only web browser offering an IPv4 through a relay ice = candidate > - A dual stack client > - A full IPv6 exchange - maybe switch one of the examples using IPv4 = to IPv6 > just to show the syntax of address and port number >=20 In addition I think an offer/answer with different packetization times, = like alaw/30 ms, Opus/60 ms or something similar. Yes, I=E2=80=99m going down = a rat hole, but it will come up and we=E2=80=99d better document a proposal for how = to handle this. If one wants to be messy you can add DTMF or CNG to an offer/answer = using alaw at 8000 hz and Opus at 48000 making it necessary to have multiple = DTMF and CNG for that media stream. But that may be out of scope for this = particular document, even though it may add clarity. /O= --Apple-Mail=_2C1B5AF7-2A23-41F9-A8FF-02CF55A00AC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 12 Jul 2016, at 09:55, Olle E. Johansson <oej@edvina.net> = wrote:


General:
I would like to see some examples using the =
current IP protocol, not the legacy IPv4,
as well as dual stack examples.

- An IPv6 only web browser offering an IPv4 through a relay =
ice candidate
- A dual stack =
client
- A full IPv6 exchange - maybe switch one of =
the examples using IPv4 to IPv6
  just to show the =
syntax of address and port number

In addition = I think an offer/answer with different packetization times, like
alaw/30 ms, Opus/60 ms or something similar. Yes, I=E2=80=99m = going down a rat hole,
but it will come up and = we=E2=80=99d better document a proposal for how to handle = this.

If one = wants to be messy you can add DTMF or CNG to an offer/answer = using
alaw at 8000 hz and Opus at 48000 making it = necessary to have multiple DTMF
and CNG for that = media stream. But that may be out of scope for this particular
document, even though it may add clarity.

/O
= --Apple-Mail=_2C1B5AF7-2A23-41F9-A8FF-02CF55A00AC6-- From nobody Tue Jul 12 05:45:11 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCBB12D0FF for ; Tue, 12 Jul 2016 05:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vEQshoO_KI86 for ; Tue, 12 Jul 2016 05:45:08 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002: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 9A84812D739 for ; Tue, 12 Jul 2016 05:45:07 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id i12so12218918ywa.1 for ; Tue, 12 Jul 2016 05:45:07 -0700 (PDT) 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=maqDqHOBuNIB55ZkCQ7jPRARJx875SXcKVhrLaSvBt8=; b=fsft5lprq9Mg8PaUCcp/1DeeQqK886KSnfFL8ieUGevulCbQyu4Evia8vh5oGb+62h gVk/yRSSY5tFhVKf3YVSSy27i7CP3XPeD1CtRxWAycgtI6XSsgFPa49UCZcnYzOa5nrx e892fikqXWHNoVoCFkNxmyugo6CS7U4tujhjmAXyw3D+nQzISuzN28Qj6vcRVPe+WBqc JGrD4p7SQ5ViBQMCv9ncbyme5SZknKh8JNs2pzD49DGsZaaDQO0UAvRfxZ4qcGv7djBs HubOYC3kLsIuwu49dAZlL8cypECDpjkorbl3jktvoiTqQWW0BGfnFxBaOtkK7hGuzgSa lbbw== 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=maqDqHOBuNIB55ZkCQ7jPRARJx875SXcKVhrLaSvBt8=; b=h/dJqLKsc/NreMCxlhYMcImBBqz8seG7ujsrAu1SuHttPNFjwOksuVvZh6f1CW7XWm jtTIRrUzA+U11iGIqpvUhj3ZTyjzZz4QtuetZkDli8eRER9INJ9gDj8ed7zLvKCcXt3K OgJEWUmbXqh9x3pqrkk8jUp13nT8wwsKnOpaVGb4OmmJo1J/VAto3zzve1u2xGpNe/b+ Y8L54M1jxKWRhWIgfZeU7eviPk4QmcSj2JW4jxCXlPcc8VTlup4WSUmObmHKgxKwmSrn 2e6CkyMI/DnnTSn9RMnzYLjU3pIW6rCwCJP9RoOaCl3g4oxdCJaLXSfChlLcwfTrH5EH fiHQ== X-Gm-Message-State: ALyK8tJ1AiDGNz4svIOYdADK5u0zjyvSCG0Two1tziVCW0xK37zi/b1N4gG3EsggiEXDshU5RE71nSNJ7euioA== X-Received: by 10.129.93.214 with SMTP id r205mr1261847ywb.15.1468327506749; Tue, 12 Jul 2016 05:45:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.121.3 with HTTP; Tue, 12 Jul 2016 05:45:06 -0700 (PDT) In-Reply-To: References: <3F93402D-B1B1-4FD5-8242-076A5604E551@edvina.net> From: Suhas Nandakumar Date: Tue, 12 Jul 2016 18:15:06 +0530 Message-ID: To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=001a114d6e0c742e2c05376fa3ba Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-sdp-02 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 12:45:10 -0000 --001a114d6e0c742e2c05376fa3ba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Olle Thanks for the review. I will go through the other comments in a while but wanted to share one thought on the ptime feedback JSEP-15 says - If this m=3D section is for media with configurable frame sizes, e.g. audio, an "a=3Dmaxptime" line, indicating the smallest of the maximum supported frame sizes out of all codecs included above, as specified in [RFC4566] , Section 6." The current set of examples try to follow JSEP specification to the closest in how the SDP is constructed barring few open issues on handing certain attributes Please let us know your thoughts on various ptimes across codecs is something that should go in JSEP spec SDP rules as well ? Thanks Suhas On Tue, Jul 12, 2016 at 5:40 PM, Olle E. Johansson wrote: > > On 12 Jul 2016, at 09:55, Olle E. Johansson wrote: > > > General: > > I would like to see some examples using the current IP protocol, not the = legacy IPv4, > > as well as dual stack examples. > > > - An IPv6 only web browser offering an IPv4 through a relay ice candidate > > - A dual stack client > > - A full IPv6 exchange - maybe switch one of the examples using IPv4 to I= Pv6 > > just to show the syntax of address and port number > > > In addition I think an offer/answer with different packetization times, > like > alaw/30 ms, Opus/60 ms or something similar. Yes, I=E2=80=99m going down = a rat > hole, > but it will come up and we=E2=80=99d better document a proposal for how t= o handle > this. > > If one wants to be messy you can add DTMF or CNG to an offer/answer using > alaw at 8000 hz and Opus at 48000 making it necessary to have multiple DT= MF > and CNG for that media stream. But that may be out of scope for this > particular > document, even though it may add clarity. > > /O > --001a114d6e0c742e2c05376fa3ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Olle

=C2=A0 Thanks for the review= . I will go through the other comments in a while but wanted to share one t= hought on the ptime feedback

JSEP-15 says
  • If this = m=3D section is for media with configurable frame sizes, e.g. audio, an &qu= ot;a=3Dmaxptime" line, indicating the smallest of the maximum supporte= d frame sizes out of all codecs included above, as specified in=C2=A0[RFC4566], Section 6."
    • The current set of examples tr= y to follow JSEP specification to the closest in how the SDP is constructed= barring few open issues on handing certain attributes
    <= div>=
    Please let us know your thoughts =C2=A0on various pti= mes across codecs is something that should go in JSEP spec SDP rules as wel= l ?

    Thanks
    Suhas

    On Tue, Jul 12, 2016 at 5:4= 0 PM, Olle E. Johansson <oej@edvina.net> wrote:
    On 12 Jul 2016, at 09:55, Olle E. Joha= nsson <oej@edvina.ne= t> wrote:


    General:
    I would like to see some examples using the current=
 IP protocol, not the legacy IPv4,
    as well as dual stack examples.
    = 

    - An IPv6 only =
web browser offering an IPv4 through a relay ice candidate
    - A dual stack clien=
t
    - A full IPv6 excha=
nge - maybe switch one of the examples using IPv4 to IPv6
      just to show the syntax of address and po=
rt number

    In addition I think an o= ffer/answer with different packetization times, like
    alaw/30 ms, Opus/6= 0 ms or something similar. Yes, I=E2=80=99m going down a rat hole,
    but it will come up and we=E2=80=99d better document a proposal for how t= o handle this.

    If one wants to be messy you can ad= d DTMF or CNG to an offer/answer using
    alaw at 8000 hz and Opus a= t 48000 making it necessary to have multiple DTMF
    and CNG for tha= t media stream. But that may be out of scope for this particular
    = document, even though it may add clarity.

    /O

    --001a114d6e0c742e2c05376fa3ba-- From nobody Tue Jul 12 05:57:13 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FDB12D87A; Tue, 12 Jul 2016 05:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.589 X-Spam-Level: X-Spam-Status: No, score=-5.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com 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 BcLOy7aVxzYx; Tue, 12 Jul 2016 05:57:07 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 4F13812D83B; Tue, 12 Jul 2016 05:56:13 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u6CCu1BS013188 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Jul 2016 08:56:05 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u6CCu1BS013188 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1468328165; bh=OOeHswIw7WT0TvrioMYv6TE2AQA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=EZBSeRw3/e6vGoU4WlKCaJUHU7h3jkjwzRT29NX2VrmiveahwzdSBoahzNcrzVeBu 7rt0U3T5TnO59OlikNyFvYFH3HWnbj8P3Ug7souG3ns0GcPL9GGkM9HN0ulRUAyeHi WfID28W703oOspbjdbZdQjJcdGo3NfzbJY7FOdMg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u6CCu1BS013188 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd55.lss.emc.com (RSA Interceptor); Tue, 12 Jul 2016 08:55:06 -0400 Received: from MXHUB305.corp.emc.com (MXHUB305.corp.emc.com [10.146.3.31]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u6CCtoJ9030063 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Tue, 12 Jul 2016 08:55:50 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB305.corp.emc.com ([10.146.3.31]) with mapi id 14.03.0266.001; Tue, 12 Jul 2016 08:55:50 -0400 From: "Black, David" To: "Gorry (erg)" Thread-Topic: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? Thread-Index: AQHRzhJbsZyuYvv6mE+PQ2kNBpP9KZ/5U/cAgAAHhwCAGfiowIAAC+UAgABFHwCAASQSAIAAEh2g Date: Tue, 12 Jul 2016 12:55:49 +0000 Message-ID: References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <648D8616-0AB5-4420-A829-1481B30237F4@erg.abdn.ac.uk> In-Reply-To: <648D8616-0AB5-4420-A829-1481B30237F4@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.97.37.15] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "fluffy@cisco.com" , "Ruediger.Geib@telekom.de" , "tsvwg@ietf.org" , "Black, David" , "rtcweb@ietf.org" , "brian.e.carpenter@gmail.com" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 12:57:12 -0000 PiBUaGUgREFSVCB3b3JrIHdhcm5zIG9mIHRoZSBwaXRmYWxscy4NCj4gDQo+IE15IHN1Z2dlc3Rp b24gaXMgdGhhdCBmb3IgcHJvdG9jb2xzIHVzaW5nIElDRSB0aGF0IFNUVU4gcGFja2V0cyBjb3Vs ZCBiZSB1c2VkIGZvcg0KPiB0aGlzIHBhdGggY2hlY2sgLSBpZiB0aGlzIGlzIGRlc2lyZWQuIEkg YW0gbm90IHN1cmUgd2UgbmVlZCB0byBob2xkIHRoZSBjdXJyZW50IGRyYWZ0DQo+IGZvciB0aGlz IHNvcnQgb2YgYWRkaXRpb24uDQoNCkknZCBhZGQgYSBzZW50ZW5jZSB0byBzYXkgdGhhdCBJQ0Ug dXNlcyBTVFVOIGZvciB0aGlzIHNvcnQgb2YgRFNDUC1zcGVjaWZpYyBwYXRoDQpjaGVjayBhbmQg Y2l0ZSB0aGUgZHJhZnQgdGhhdCBzcGVjaWZpZXMgaG93IHRoYXQgcGF0aCBjaGVja2luZyBpcyBw ZXJmb3JtZWQuDQpXaGljaCBkcmFmdCB3b3VsZCB0aGF0IGJlPw0KDQpJIGNvbmN1ciB0aGF0IHRo aXMgZHJhZnQgb24gRFNDUCB1c2FnZSBzaG91bGQgbm90IHNwZWNpZnkgaG93IHBhdGggY2hlY2tp bmcgaXMgZG9uZS4NCiANCj4gR29ycnkNCj4gDQo+IE9uIDExIEp1bCAyMDE2LCBhdCAxOToyMiwg QmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPiB3cm90ZToNCj4gDQo+ID4+IGFyZSB5 b3UgYXNraW5nLCB3aGV0aGVyIHRoZSB0cmVhdG1lbnQgb2YgdW5leHBlY3RlZCBEU0NQcw0KPiA+ DQo+ID4gTm8sIEknbSBhc2tpbmcgd2hpY2ggZHJhZnQgc2hvdWxkIGRvY3VtZW50IHdoYXQgYSBX ZWJSVEMgYXBwbGljYXRpb24gb3IgYQ0KPiBicm93c2VyDQo+ID4gaG9zdGluZyBhIFdlYlJUQyBh cHBsaWNhdGlvbiBzaG91bGQgZG8gaW4gb3JkZXIgdG8gYmUgcm9idXN0IHRvIGJsYWNrLWhvbGUN Cj4gPiAodW5yZWFjaGFiaWxpdHkpIGJlaGF2aW9yIGNhdXNlZCBieSB1c2Ugb2YgYSBEU0NQIG90 aGVyIHRoYW4gMDAwMDAwLg0KPiA+DQo+ID4+IERpZG4ndCByZWFkIHRoZSBEQVJUIHdvcmsgYmVm b3JlIHJlcGx5aW5nLCBidXQgSSBhc3N1bWUgdGhlIHNpdHVhdGlvbiBpc24ndA0KPiA+PiBjb3Zl cmVkIGluIHN1ZmZpY2llbnQgZGV0YWlsIHRoZXJlLg0KPiA+DQo+ID4gTm9wZSwgaXQgaXNuJ3Qg Li4uDQo+ID4NCj4gPiBUaGFua3MsIC0tRGF2aWQNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBSdWVkaWdlci5HZWliQHRlbGVrb20uZGUgW21haWx0bzpS dWVkaWdlci5HZWliQHRlbGVrb20uZGVdDQo+ID4+IFNlbnQ6IE1vbmRheSwgSnVseSAxMSwgMjAx NiAxMDozNCBBTQ0KPiA+PiBUbzogQmxhY2ssIERhdmlkOyBtaWNoYXdlQGlmaS51aW8ubm87IGJy aWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbQ0KPiA+PiBDYzogZmx1ZmZ5QGNpc2NvLmNvbTsgcnRj d2ViQGlldGYub3JnOyB0c3Z3Z0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBBVzogW3RzdndnXSBG YWxsLWJhY2sgdG8gRFNDUCAwIGluIGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcyA/DQo+ID4+ DQo+ID4+IEhpIERhdmlkLA0KPiA+Pg0KPiA+PiBhcmUgeW91IGFza2luZywgd2hldGhlciB0aGUg dHJlYXRtZW50IG9mIHVuZXhwZWN0ZWQgRFNDUHMNCj4gPj4gLSBzaG91bGQgYmUgZG9jdW1lbnRl ZCB3aXRoaW4gZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zIG9yDQo+ID4+IC0gc2hvdWxkIGJl IGRvY3VtZW50ZWQgd2l0aGluIGRyYWZ0LWplbm5pbmdzLWljZS1ydGN3ZWItdGltaW5nLTAxIG9y DQo+ID4+IC0gc2hvdWxkIGJlIGRvY3VtZW50ZWQgd2l0aGluIGEgdG8gYmUgd3JpdHRlbiBkcmFm dC11bmV4cGVjdGVkLWRzY3AtDQo+ID4+IHRyZWF0bWVudD8NCj4gPj4NCj4gPj4gV2UndmUgZGlz Y3Vzc2VkIGJsZWFjaGluZyB2cyB0cmFuc3BvcnQgb2YgdW5leHBlY3RlZCBEU0NQcyB3aGlsZSB3 b3JraW5nDQo+IG9uDQo+ID4+IGRpZmZzZXJ2LWludGVyY29uIGFzIGEgcG9zc2libGUgbWVhc3Vy ZSAoYnV0IG5ldmVyIGRpc2N1c3NlZCBkcm9wcGluZykuIEkNCj4gZmF2b3IgYQ0KPiA+PiBzZXBh cmF0ZSBhbmQgZ2VuZXJpYyBSRkMgZGVhbGluZyB3aXRoIHRoZSBpc3N1ZSwgaWYgdGhhdCBpcyB3 aGF0IHlvdSBhc2sgZm9yLiBJDQo+IHRoaW5rDQo+ID4+IHRoZSBpc3N1ZSBvZiB1bmV4cGVjdGVk IERTQ1AgdHJlYXRtZW50IGlzIG5vdCBydGN3ZWIvU1RVTi8uLi4gc3BlY2lmaWMuIFRoZQ0KPiA+ PiBzYW1lIGhvbGRzIGZvciB0aGUgYXZvaWRhbmNlIG9mIGJsYWNraG9saW5nIGR1ZSB0byBEU0NQ IG1hcmtzLiBIaW50cyB0byBhdm9pZA0KPiBpdA0KPiA+PiBzaG91bGQgYmUgcGFydCBvZiB0aGF0 IGRyYWZ0Lg0KPiA+Pg0KPiA+PiBEaWRuJ3QgcmVhZCB0aGUgREFSVCB3b3JrIGJlZm9yZSByZXBs eWluZywgYnV0IEkgYXNzdW1lIHRoZSBzaXR1YXRpb24gaXNuJ3QNCj4gPj4gY292ZXJlZCBpbiBz dWZmaWNpZW50IGRldGFpbCB0aGVyZS4NCj4gPj4NCj4gPj4gUmVnYXJkcywNCj4gPj4NCj4gPj4g UnVlZGlnZXINCj4gPj4NCj4gPj4NCj4gPj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQt LS0tLQ0KPiA+PiBWb246IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gSW0g QXVmdHJhZyB2b24gQmxhY2ssIERhdmlkDQo+ID4+IEdlc2VuZGV0OiBNb250YWcsIDExLiBKdWxp IDIwMTYgMTU6NTYNCj4gPj4gQW46IE1pY2hhZWwgV2Vsemw7IEJyaWFuIEUgQ2FycGVudGVyDQo+ ID4+IENjOiBDdWxsZW4gSmVubmluZ3MgKGZsdWZmeSk7IHJ0Y3dlYkBpZXRmLm9yZzsgdHN2d2dA aWV0Zi5vcmcNCj4gPj4gQmV0cmVmZjogUmU6IFt0c3Z3Z10gRmFsbC1iYWNrIHRvIERTQ1AgMCBp biBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MgPw0KPiA+Pg0KPiA+PiBbK3J0Y3dlYl0NCj4g Pj4NCj4gPj4+Pj4gV2UgYmVsaWV2ZSB0aGF0IGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcyBz aG91bGQgc2F5OiBpZiBzZXR0aW5nDQo+ID4+Pj4+IHRoZSBEU0NQDQo+ID4+PiB2YWx1ZXMgYXMg cHJvcG9zZWQgaGVyZSBjb25zaXN0ZW50bHkgcHJvZHVjZXMgcGFja2V0IGRyb3BzLCBzZW5kZXJz DQo+ID4+PiBzaG91bGQgZmFsbCBiYWNrIHRvIERTQ1AgMC4gV2ViUlRDIHNob3VsZG4ndCAiZmFp bCIgYmVjYXVzZSBvZiB0aGUgRFNDUC4NCj4gPj4+Pg0KPiA+Pj4+IFRoaXMgaXMgYW4gaW50ZXJl c3RpbmcgYW5kIHdvcnJ5aW5nIHJlc3VsdCBpbmRlZWQsIGJ1dCBpdCdzIGluIG5vDQo+ID4+Pj4g d2F5IHNwZWNpZmljIHRvIFdlYlJUQy4gSSB0aGluayBhIGdlbmVyaWMgUkZDICgiSGFwcHkgRXll YmFsbHMgd2l0aA0KPiA+Pj4+IERpZmZlcmVudGlhdGVkDQo+ID4+PiBTZXJ2aWNlcyI/KQ0KPiA+ Pj4+IHdvdWxkIGJlIHRoZSB3YXkgdG8gZ28uDQo+ID4+Pg0KPiA+Pj4gV2VsbCwgaWYgeW91IHVz ZSB0aGUgRFNDUCB3aXRoaW4geW91ciBvd24gYWRtaW5pc3RyYXRpdmUgZG9tYWluIGZvcg0KPiA+ Pj4gRGlmZlNlcnYsIHlvdSBzaG91bGQgYmUgc2FmZeKApi4gc28gSSBndWVzcyB0aGlzIHByb2Js ZW0gbW9zdGx5IG1hdHRlcnMNCj4gPj4+IGZvciB1c2FnZSBhY3Jvc3MgZG9tYWlucywgb3IgZXZl biBlbmQtdG8tZW5kLg0KPiA+Pj4gPT4gSXQgc2VlbXMgdG8gbWUgdGhhdCBpdOKAmXMgYnJvYWRl ciB0aGFuIFdlYlJUQyBpbiBleGFjdGx5IHRoZSBzYW1lDQo+ID4+PiB3YXkgYXMNCj4gPj4+IFJG Qzc2NTcgaXMgYnJvYWRlciB0aGFuIFdlYlJUQy4NCj4gPj4NCj4gPj4gV2UgaGF2ZSBhbiBpbW1l ZGlhdGUgaXNzdWUgYWJvdXQgd2hhdCB0byBhZGQgdG8gdGhlIHJ0Y3dlYi1xb3MgZHJhZnQsDQo+ IHdoaWNoIGlzDQo+ID4+IElFU0cgYXBwcm92ZWQsIGFuZCB3aWxsIGdvIHRvIHRoZSBSRkMgRWRp dG9yIG9uY2UgdGhpcyBjb25jZXJuIGlzIHJlc29sdmVkLg0KPiA+PiBXaGlsZSBJIGdyZWF0bHkg YXBwcmVjaWF0ZSBNaWNoYWVsJ3Mgc3VnZ2VzdGlvbiBvZiB0ZXh0LCBJIHdvbmRlciB3aGV0aGVy IHRoaXMNCj4gaXMNCj4gPj4gcGFydCBvZiBhIGxhcmdlciBwcm9ibGVtIC4uLg0KPiA+Pg0KPiA+ PiBDdWxsZW4gcmVjZW50bHkgc2VudCBhIG1lc3NhZ2UgdG8gVFNWV0cgYWJvdXQgaW5pdGlhbCB1 c2Ugb2YgYmFuZHdpZHRoIGJ5IElDRQ0KPiA+PiBmb3IgU1RVTjoNCj4gPj4NCj4gPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90c3Z3Zy9jdXJyZW50L21zZzE0NDk3Lmh0 bWwNCj4gPj4NCj4gPj4gVGhhdCAgbWVzc2FnZSBiZWdpbnMgd2l0aDoNCj4gPj4NCj4gPj4+IFdo ZW4gV2ViUlRDIGNvbm5lY3Rpb25zIHN0YXJ0LCB0aGV5IHNlbmQgYSBidW5jaCBvZiBTVFVOIHBh Y2tldHMgYXMgcGFydA0KPiBvZg0KPiA+PiBJQ0UuDQo+ID4+PiBUeXBpY2FsbHkgbW9zdCBvZiB0 aGVzZSBTVFVOIHBhY2tldHMgZG8gbm90IGFjdHVhbGx5IHJlYWNoIGEgdmFsaWQNCj4gPj4+IGRl c3RpbmF0aW9uIHNvIHRoZXkgaGF2ZSAxMDAlIHBhY2tldCBsb3NzIGZyb20gdGhlIHBvaW50IG9m IHZpZXcgb2YNCj4gPj4+IHRoZSBzZW5kZXIuIFRoaXMgaXMgZGlzY3Vzc2VkIG1vcmUgaW4NCj4g Pj4+IGRyYWZ0LWplbm5pbmdzLWljZS1ydGN3ZWItdGltaW5nLTAxDQo+ID4+DQo+ID4+IFRoaXMg ZmVlbHMgbGlrZSBwYXJ0IG9mIHRoZSBzYW1lIHByb2JsZW0gLSBibGFjay1ob2xpbmcgY2F1c2Vk IGJ5IERTQ1ANCj4gc2VsZWN0aW9uDQo+ID4+IGZlZWxzIGxpa2UgaXQgY291bGQgYmUgZGVhbHQg d2l0aCBhcyBwYXJ0IG9mIFNUVU4gcHJvYmluZywgYWx0aG91Z2ggc29tZSBjYXV0aW9uDQo+IGlz DQo+ID4+IGluIG9yZGVyICAoZS5nLiwgaWYgRUYgaXMgdXNlZCB0byBzZXQgdXAgYXVkaW8pLg0K PiA+Pg0KPiA+PiBXaGF0J3MgdGhlICJyaWdodCB3YXkiIHRvIGRlYWwgd2l0aCB0aGlzIHBvc3Np YmlsaXR5IHRoYXQgbm9uLWRlZmF1bHQgRFNDUA0KPiB1c2FnZSBieQ0KPiA+PiBXZWIgUlRDIG1h eSBjYXVzZSBibGFjay1ob2xpbmcsIGFuZCB3aGljaCBkcmFmdCBzaG91bGQgc3BlY2lmeSB0aGUg YmxhY2stDQo+IGhvbGUtDQo+ID4+IGF2b2lkYW5jZSBiZWhhdmlvcj8NCj4gPj4NCj4gPj4gVGhh bmtzLCAtLURhdmlkDQo+ID4+DQo+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ Pj4gRnJvbTogdHN2d2cgW21haWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTWljaGFlbCBXZWx6bA0KPiA+Pj4gU2VudDogRnJpZGF5LCBKdW5lIDI0LCAyMDE2IDQ6NTIg UE0NCj4gPj4+IFRvOiBCcmlhbiBFIENhcnBlbnRlcg0KPiA+Pj4gQ2M6IHRzdndnQGlldGYub3Jn DQo+ID4+PiBTdWJqZWN0OiBSZTogW3RzdndnXSBGYWxsLWJhY2sgdG8gRFNDUCAwIGluIGRyYWZ0 LWlldGYtdHN2d2ctcnRjd2ViLXFvcyA/DQo+ID4+Pg0KPiA+Pj4gSGksDQo+ID4+Pg0KPiA+Pj4N Cj4gPj4+PiBPbiAyNC4ganVuLiAyMDE2LCBhdCAyMi4yNSwgQnJpYW4gRSBDYXJwZW50ZXINCj4g Pj4+PiA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPg0KPiA+Pj4gd3JvdGU6DQo+ID4+Pj4N Cj4gPj4+Pj4gV2UgYmVsaWV2ZSB0aGF0IGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcyBzaG91 bGQgc2F5OiBpZiBzZXR0aW5nDQo+ID4+Pj4+IHRoZSBEU0NQDQo+ID4+PiB2YWx1ZXMgYXMgcHJv cG9zZWQgaGVyZSBjb25zaXN0ZW50bHkgcHJvZHVjZXMgcGFja2V0IGRyb3BzLCBzZW5kZXJzDQo+ ID4+PiBzaG91bGQgZmFsbCBiYWNrIHRvIERTQ1AgMC4gV2ViUlRDIHNob3VsZG4ndCAiZmFpbCIg YmVjYXVzZSBvZiB0aGUgRFNDUC4NCj4gPj4+Pg0KPiA+Pj4+IFRoaXMgaXMgYW4gaW50ZXJlc3Rp bmcgYW5kIHdvcnJ5aW5nIHJlc3VsdCBpbmRlZWQsIGJ1dCBpdCdzIGluIG5vDQo+ID4+Pj4gd2F5 IHNwZWNpZmljIHRvIFdlYlJUQy4gSSB0aGluayBhIGdlbmVyaWMgUkZDICgiSGFwcHkgRXllYmFs bHMgd2l0aA0KPiA+Pj4+IERpZmZlcmVudGlhdGVkDQo+ID4+PiBTZXJ2aWNlcyI/KQ0KPiA+Pj4+ IHdvdWxkIGJlIHRoZSB3YXkgdG8gZ28uDQo+ID4+Pg0KPiA+Pj4gV2VsbCwgaWYgeW91IHVzZSB0 aGUgRFNDUCB3aXRoaW4geW91ciBvd24gYWRtaW5pc3RyYXRpdmUgZG9tYWluIGZvcg0KPiA+Pj4g RGlmZlNlcnYsIHlvdSBzaG91bGQgYmUgc2FmZeKApi4gc28gSSBndWVzcyB0aGlzIHByb2JsZW0g bW9zdGx5IG1hdHRlcnMNCj4gPj4+IGZvciB1c2FnZSBhY3Jvc3MgZG9tYWlucywgb3IgZXZlbiBl bmQtdG8tZW5kLg0KPiA+Pj4gPT4gSXQgc2VlbXMgdG8gbWUgdGhhdCBpdOKAmXMgYnJvYWRlciB0 aGFuIFdlYlJUQyBpbiBleGFjdGx5IHRoZSBzYW1lDQo+ID4+PiB3YXkgYXMNCj4gPj4+IFJGQzc2 NTcgaXMgYnJvYWRlciB0aGFuIFdlYlJUQy4NCj4gPj4+DQo+ID4+PiBBcyBhIHNpZGUgbm90ZSwg SSB0aGluayB0aGUgdGVybSDigJxIYXBweSBFeWViYWxsc+KAnSBpcyBtaXNsZWFkaW5nIGhlcmUu DQo+ID4+PiBUaGlzIHRlcm0sIHRvIG1lLCBpbmRpY2F0ZXMgcGFyYWxsZWwgdXNhZ2Ugb2YgbXVs dGlwbGUgcGFja2V0IHR5cGVzIHRvDQo+ID4+PiBzZWUgd2hpY2ggb25lKHMpDQo+ID4+PiBzdWNj ZWVkKHMpIGFuZCB0aGVuIHRyeSB0byBtYWtlIHRoZSBiZXN0IGNob2ljZS4NCj4gPj4+IFRoaXMg aXNu4oCZdCB3aGF0IHlvdSB3b3VsZCBkbyBoZXJlIC0gd2XigJlyZSB0YWxraW5nIGFib3V0IGEg cmFyZSBmYWlsdXJlDQo+ID4+PiBzaXR1YXRpb24uIEl04oCZcyByZWFsbHkgb25seSBzb21ldGhp bmcgSeKAmWQgc3VnZ2VzdCBhcyBhIGZhbGwtYmFjaywgdXBvbg0KPiA+Pj4gc2VlaW5nIGNvbW11 bmljYXRpb24gZmFpbGluZyBlbnRpcmVseSwgb3ZlciBhIGxvbmdlciBwZXJpb2QgKHBlcmhhcHMg aW4gbGluZQ0KPiB3aXRoDQo+ID4+IGEgY2lyY3VpdC1icmVha2VyKS4NCj4gPj4+DQo+ID4+Pg0K PiA+Pj4+IEJ1dCAoYXMgd2l0aCBhIGxvdCBvZiByZWNlbnQgZGlzY3Vzc2lvbiBhYm91dCBJUHY2 IGV4dGVuc2lvbiBoZWFkZXJzDQo+ID4+Pj4gY2F1c2luZyBwYWNrZXQgZHJvcHMpIHdlIHJlYWxs eSBuZWVkIHRvIHVuZGVyc3RhbmQgd2h5DQo+ID4+PiB0aGlzDQo+ID4+Pj4gaGFwcGVucy4gSXMg aXQgdHJhZmZpYyBwb2xpY2luZyB0aGF0IGZhaWxzIHRvIHJlY2xhc3NpZnkgYW5kIHJlLW1hcmsN Cj4gPj4+PiBwYWNrZXRzLCBtaXNndWlkZWQgZmlyZXdhbGxzLCBvciB3aGF0Pw0KPiA+Pj4NCj4g Pj4+IEkgaGF2ZSBubyBjbHVl4oCmIGJ1dCBhcyBteSBwcmV2aW91cyBlbWFpbCBzYWlkLCB3ZSBo YXZlIGluZGljYXRpb25zDQo+ID4+PiB0aGF0IHRoaXMgYmVoYXZpb3Igb2NjdXJyZWQgY2xvc2Ug dG8gdGhlIHNlbmRlcnMgKG1vc3Qgb2YgdGhlbSBiZWluZw0KPiA+Pj4gaW4gcGVvcGxl4oCZcyBo b21lcyksIGhlbmNlIGl04oCZcyBtb3JlIGxpa2VseSB0aGF0IHRoaXMgd2FzIGRvbmUgYnkgYQ0K PiA+Pj4gbWlkZGxlYm94IG9yIGFuIGVkZ2Ugcm91dGVyIHRoYW4gYnkgYSBjb3JlIHJvdXRlci4N Cj4gPj4+IFRoYXTigJlzIGFzIG11Y2ggYXMgd2Uga25vdy4uLg0KPiA+Pj4NCj4gPj4+IENoZWVy cywNCj4gPj4+IE1pY2hhZWwNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+DQo+ID4+Pj4gUmVnYXJkcw0K PiA+Pj4+ICBCcmlhbg0KPiA+Pj4+DQo+ID4+Pj4+IE9uIDI1LzA2LzIwMTYgMDA6MTcsIE1pY2hh ZWwgV2Vsemwgd3JvdGU6DQo+ID4+Pj4+IERlYXIgYWxsLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBXZSBy ZWNlbnRseSBkaWQgRFNDUCByZWxhdGVkIG1lYXN1cmVtZW50cyB0aGF0IGxlYWQgdXMgdG8gcHJv cG9zZSBhDQo+ID4+Pj4+IGNoYW5nZQ0KPiA+Pj4gdG8gZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWIt cW9zLg0KPiA+Pj4+PiBUaGVzZSBtZWFzdXJlbWVudHMgYXJlIHJlcG9ydGVkIGluIHRoaXMgcGFw ZXI6DQo+ID4+Pj4+IGh0dHA6Ly9oZWltLmlmaS51aW8ubm8vfm1pY2hhd2UvcmVzZWFyY2gvcHVi bGljYXRpb25zL2FucncxNi0NCj4gPj4+IG1lYXN1cmVtZW50LnBkZg0KPiA+Pj4+PiAuLi4gd2hp Y2ggd2lsbCBiZSBwcmVzZW50ZWQgYXQgdGhlIEFOUlcgd29ya3Nob3AsIHRoZSBTYXR1cmRheQ0K PiA+Pj4+PiBiZWZvcmUgdGhlDQo+ID4+PiBJRVRGIG1lZXRpbmcuDQo+ID4+Pj4+DQo+ID4+Pj4+ IFRoZSBwYXBlciByZXBvcnRzIG9uIHRlc3RzIGJldHdlZW4gcGVvcGxlJ3MgaG9tZXMgYW5kIDMg c2VydmVycw0KPiA+Pj4+PiB0aGF0IHdlDQo+ID4+PiByYW4gLSBvbmUgaW4gT3JlZ29uIChhbWF6 b24gY2xvdWQpIGFuZCB0d28gaW4gTm9yd2F5LiBUaGlzIGdhdmUgdXMgMTg1DQo+ID4+PiBkaXN0 aW5jdCBwYXRocyAoSVAgYWRkcmVzcyBwYWlycykuIFRoZSB0ZXN0IHdhcyBhIFRDUCBoYW5kc2hh a2UsIGRvbmUNCj4gPj4+IHdpdGggcmF3IHNvY2tldHMsIGFuZCB3ZSBwbGF5ZWQgYXJvdW5kIHdp dGggdmFsdWVzIGluIHRoZSBJUCBoZWFkZXIuDQo+ID4+PiBNZWFud2hpbGUsIFJ1bmEgKG1haW4N Cj4gPj4+IGF1dGhvcikgZGlkIHNvbWUgbW9yZSB0ZXN0cyBmcm9tIHZhcmlvdXMgcHVibGljIHBs YWNlcyBkdXJpbmcgYSB0cmlwDQo+ID4+PiBmcm9tIE5vcndheSB0byBJbmRpYSwgZXNzZW50aWFs bHkgY29uZmlybWluZyB0aGUgZmluZGluZyB3ZSBkaXNjdXNzDQo+ID4+PiBoZXJlOyB3ZSdsbCBh c2sgZm9yIGEgc2xvdCB0byByZXBvcnQgYWJvdXQgYm90aCB0aGUgZGF0YSBpbiB0aGUgQU5SVw0K PiA+Pj4gcGFwZXIgYW5kIHRoZSBuZXdlciBkYXRhIGluIHRoZSBNQVBSRyBzZXNzaW9uLg0KPiA+ Pj4+Pg0KPiA+Pj4+PiBUaGUgbnVtYmVyIG9mIGRhdGEgcG9pbnRzIGlzbid0IGV4YWN0bHkgaHVn ZSBpbiBib3RoIGNhc2VzLCBidXQNCj4gPj4+Pj4gc3RpbGwgcmVsZXZhbnQsDQo+ID4+PiB3ZSBi ZWxpZXZlOiBpdCBpcyBhYm91dCBhIHBlcnNpc3RlbnQgZmFpbHVyZSB0aGF0IHdlIHNhdyBvbiBk aWZmZXJlbnQNCj4gPj4+IHBhdGhzLCBhbmQgc28gd2UgdGhpbmsgaXQncyBwcm9iYWJseSByZWFz b25hYmxlIHRvIHRha2UgaXQgaW50bw0KPiA+Pj4gYWNjb3VudCAoZ2l2ZW4gdGhhdCBhIGZpeCBz aG91bGRuJ3QgYmUgdmVyeSBjb21wbGljYXRlZCBlaXRoZXIpLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBX ZSB1c2VkLCBhcyBpbnB1dCwgRFNDUCB2YWx1ZXMgZnJvbSB0aGUgdGFibGUgaW4gZHJhZnQtaWV0 Zi10c3Z3Zy1ydGN3ZWItDQo+ID4+IHFvcy4NCj4gPj4+Pj4gSGVyZSBhcmUgc29tZSBzZW50ZW5j ZXMgY29weSArIHBhc3RlZCBmcm9tIG91ciBwYXBlcjoNCj4gPj4+Pj4NCj4gPj4+Pj4gKioqDQo+ ID4+Pj4+ICJUbyBtaW5pbWl6ZSB0aGUgY2hhbmNlIHRoYXQgY29uZ2VzdGlvbi1iYXNlZCBkcm9w cyBtYWtlIHVzIGJlbGlldmUNCj4gPj4+Pj4gaW4gYQ0KPiA+Pj4gZmFpbHVyZQ0KPiA+Pj4+PiB0 byBjb21tdW5pY2F0ZSB1c2luZyBjZXJ0YWluIHZhbHVlcyBpbiB0aGUgSVAgaGVhZGVyLCB3ZSBy ZS10cmllZA0KPiA+Pj4+PiBmYWlsZWQNCj4gPj4+IHBhY2tldA0KPiA+Pj4+PiBleGNoYW5nZXMg dXAgdG8gdGhyZWUgdGltZXMsIGFuZCB3ZSBzZW50IGFuIElDTVAgcGFja2V0IGp1c3QgYWhlYWQN Cj4gPj4+Pj4gb2YgZXZlcnkgbWVhc3VyZW1lbnQgcGFja2V0LiBXZSBvbmx5IGFzc3VtZWQgYSBj b21tdW5pY2F0aW9uDQo+ID4+Pj4+IGZhaWx1cmUgd2hlbiB0aGUNCj4gPj4+IHRlc3QNCj4gPj4+ Pj4gZmFpbGVkIHRocmVlIHRpbWVzIGFuZCB0aGUgSUNNUCBwYWNrZXQgc3VjY2VlZGVkLiINCj4g Pj4+Pj4NCj4gPj4+Pj4gIkNvbnNpZGVyaW5nIHRhYmxlIDEgaW4gWzZdLCB3ZSBhc3N1bWVkIHRo ZSBmbG93IHR5cGUg4oCcSW50ZXJhY3RpdmUNCj4gPj4+Pj4gVmlkZW8gd2l0aA0KPiA+Pj4gb3IN Cj4gPj4+Pj4gd2l0aG91dCBBdWRpb+KAnSB3aXRoIGFwcGxpY2F0aW9uIHByaW9yaXRpZXMg4oCc VmVyeSBsb3figJ0gKERTQ1AgdmFsdWUNCj4gPj4+Pj4gQ1MxICg4KSksDQo+ID4+PiDigJxMb3fi gJ0NCj4gPj4+Pj4gKERGICgwKSkgb3Ig4oCcTWVkaXVt4oCdIChBRjQyICgzNikpLCBhbmQgZmxv dyB0eXBlIOKAnEF1ZGlv4oCdIHdpdGgNCj4gPj4+Pj4gYXBwbGljYXRpb24NCj4gPj4+IHByaW9y aXRpeQ0KPiA+Pj4+PiDigJxIaWdo4oCdIChFRiBQSEIgKDQ2KSkuIg0KPiA+Pj4+Pg0KPiA+Pj4+ PiAiV2UgZGlkIHNlZSBjb25zaXN0ZW50IHBhY2tldCBkcm9wcyB0b286IG9uIDIzIHBhdGhzIGZv ciBEU0NQIHZhbHVlDQo+ID4+Pj4+IDgsIDIxDQo+ID4+PiBwYXRocw0KPiA+Pj4+PiBmb3IgMzYs IDE5IGZvciA0Ni4iDQo+ID4+Pj4+ICoqKg0KPiA+Pj4+Pg0KPiA+Pj4+PiBXZSBhbHNvIHNhdyBE U0NQIHZhbHVlIGNoYW5nZXMsIGJ1dCBub3RoaW5nIHZlcnkgYWxhcm1pbmcgdGhlcmUgLQ0KPiA+ Pj4+PiBpbiBvbmUNCj4gPj4+IGNhc2UsIEFGNDIgd2FzIGNoYW5nZWQgdG8gQUY0MSwgd2hpY2gg aXMgZXZlbiBuaWNlICA6KSAgICAgaG93ZXZlciwgdGhpcw0KPiA+PiBjb25zaXN0ZW50DQo+ID4+ PiBkcm9wIGJlaGF2aW9yIHRoYXQgYXBwZWFycyBvbmx5IHdoZW4gdXNpbmcgYSBEU0NQIHZhbHVl ICE9IDAgaXNuJ3QgZ29vZCBhdA0KPiBhbGwuDQo+ID4+PiBOb3cgdGhlc2UgdGhpbmdzIGNvdWxk IGluIHByaW5jaXBsZSBoYXZlIGhhcHBlbmVkIGNsb3NlIHRvIG91ciAzDQo+ID4+PiBzZXJ2ZXJz LCBtZWFuaW5nIHRoZXJlIHdlcmUgb25seSBmZXcgZGV2aWNlcyB0aGF0IGRpZCBpdCwgYnV0IGlu IGZhY3QNCj4gPj4+IHRoaXMgbWVhc3VyZW1lbnQgd2FzIGEgcGFydCBvZiBhIGxhcmdlciBtZWFz dXJlbWVudCBjYW1wYWlnbiBpbiB3aGljaA0KPiA+Pj4gd2UgYWxzbyBjaGVja2VkIHdoZXJlIHN1 Y2ggcGFja2V0IGRyb3BzIHR5cGljYWxseSBoYXBwZW5lZC4gVGhlIHJlc3VsdA0KPiA+Pj4gd2Fz OiBtb3N0IHN1Y2ggZHJvcHMgc2VlbSB0byBiZSBjbG9zZSB0byB0aGUgY2xpZW50LCB3aGljaCBt YXkNCj4gPj4+IGluZGljYXRlIHRoYXQgdGhlcmUgd2VyZSBpbiBmYWN0IG11bHRpcGxlIHN1Y2gg Ym94ZXMuDQo+ID4+Pj4+DQo+ID4+Pj4+IFdlIGJlbGlldmUgdGhhdCBkcmFmdC1pZXRmLXRzdndn LXJ0Y3dlYi1xb3Mgc2hvdWxkIHNheTogaWYgc2V0dGluZw0KPiA+Pj4+PiB0aGUgRFNDUA0KPiA+ Pj4gdmFsdWVzIGFzIHByb3Bvc2VkIGhlcmUgY29uc2lzdGVudGx5IHByb2R1Y2VzIHBhY2tldCBk cm9wcywgc2VuZGVycw0KPiA+Pj4gc2hvdWxkIGZhbGwgYmFjayB0byBEU0NQIDAuIFdlYlJUQyBz aG91bGRuJ3QgImZhaWwiIGJlY2F1c2Ugb2YgdGhlIERTQ1AuDQo+ID4+Pj4+DQo+ID4+Pj4+IENo ZWVycywNCj4gPj4+Pj4gTWljaGFlbA0KPiA+DQoNCg== From nobody Tue Jul 12 06:16:55 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184A612D8A7 for ; Tue, 12 Jul 2016 06:16:53 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6DIBRSM-wXQ5 for ; Tue, 12 Jul 2016 06:16:47 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 B08DC12D990 for ; Tue, 12 Jul 2016 06:02:05 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id A0CA6428A; Tue, 12 Jul 2016 15:02:02 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7513E0C8-5BE4-44FD-9CE4-F6406A843CD1" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 12 Jul 2016 15:02:02 +0200 Message-Id: <8DF53681-3A99-4B0F-B519-93F8675E455D@edvina.net> References: <3F93402D-B1B1-4FD5-8242-076A5604E551@edvina.net> To: Suhas Nandakumar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-sdp-02 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 13:16:53 -0000 --Apple-Mail=_7513E0C8-5BE4-44FD-9CE4-F6406A843CD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 Jul 2016, at 14:45, Suhas Nandakumar = wrote: >=20 > Hello Olle >=20 > Thanks for the review. I will go through the other comments in a = while but wanted to share one thought on the ptime feedback >=20 > JSEP-15 says > If this m=3D section is for media with configurable frame sizes, e.g. = audio, an "a=3Dmaxptime" line, indicating the smallest of the maximum = supported frame sizes out of all codecs included above, as specified in = [RFC4566] = , = Section 6.=E2=80=9D That=E2=80=99s a good setting, but not the same. If you have codec Y = with ptimes settable from 10 to 130 and codec Z with ptimes settable = from 20 to 250, the maxptime would be 130 if I understand you right. What I am looking for is the weird situation where I want to offer codec = Y with the default ptime of 40 and codec Z with the default ptime of 50. This is a wormhole, since the a=3Dptime setting is kind of a mystery = that a few brave people have been trying to solve - does it apply to ALL codecs in a offered stream and if so - how to we handle an offer = like above. Codec Y and codec Z may have incompatible ptimes too, so one default ptime for the stream may not work at all.=20 >=20 > The current set of examples try to follow JSEP specification to the = closest in how the SDP is constructed barring few open issues on handing = certain attributes Ok, then this issue, which is generic SDP may be out of scope for this = document - but it will pop up at some unspecified time in the future so I wanted to suggest that the time is now.=20 >=20 > Please let us know your thoughts on various ptimes across codecs is = something that should go in JSEP spec SDP rules as well ? I need to look a bit more into JSEP for that. While waiting for me to do = that, others may offer their opinions :-) /O >=20 > Thanks > Suhas >=20 > On Tue, Jul 12, 2016 at 5:40 PM, Olle E. Johansson > wrote: >=20 >> On 12 Jul 2016, at 09:55, Olle E. Johansson > wrote: >>=20 >>=20 >> General: >> I would like to see some examples using the current IP protocol, not = the legacy IPv4, >> as well as dual stack examples. >>=20 >> - An IPv6 only web browser offering an IPv4 through a relay ice = candidate >> - A dual stack client >> - A full IPv6 exchange - maybe switch one of the examples using IPv4 = to IPv6 >> just to show the syntax of address and port number >>=20 > In addition I think an offer/answer with different packetization = times, like > alaw/30 ms, Opus/60 ms or something similar. Yes, I=E2=80=99m going = down a rat hole, > but it will come up and we=E2=80=99d better document a proposal for = how to handle this. >=20 > If one wants to be messy you can add DTMF or CNG to an offer/answer = using > alaw at 8000 hz and Opus at 48000 making it necessary to have multiple = DTMF > and CNG for that media stream. But that may be out of scope for this = particular > document, even though it may add clarity. >=20 > /O >=20 --Apple-Mail=_7513E0C8-5BE4-44FD-9CE4-F6406A843CD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On 12 Jul 2016, at 14:45, Suhas Nandakumar <suhasietf@gmail.com>= wrote:

    Hello Olle

      Thanks for the review. I will go through the other = comments in a while but wanted to share one thought on the ptime = feedback

    JSEP-15= says
    • If this m=3D = section is for media with configurable frame sizes, e.g. audio, an = "a=3Dmaxptime" line, indicating the smallest of the maximum supported = frame sizes out of all codecs included above, as specified in [RFC4566], Section = 6.=E2=80=9D
    That=E2=80=99s a good = setting, but not the same. If you have codec Y with ptimes settable from = 10 to 130 and codec Z with ptimes settable from 20 to 250,
    the = maxptime would be 130 if I understand you right.

    What I am looking for is the weird situation where = I want to offer codec Y with the default ptime of 40 and codec Z with = the default ptime of 50.
    This is a wormhole, since the a=3Dptime= setting is kind of a mystery that a few brave people have been trying = to solve - does it apply
    to ALL codecs in a offered stream and = if so - how to we handle an offer like above. Codec Y and codec Z may = have incompatible
    ptimes too, so one default ptime for the = stream may not work at all. 
    The current set of examples try to follow JSEP specification = to the closest in how the SDP is constructed barring few open issues on = handing certain = attributes
    Ok, then this = issue, which is generic SDP may be out of scope for this document - but = it will pop up at some unspecified time
    in the future so I = wanted to suggest that the time is now. 

    Please let us know your = thoughts  on various ptimes across codecs is something that should = go in JSEP spec SDP rules as well = ?
    I need to look a bit more = into JSEP for that. While waiting for me to do that, others may offer = their opinions :-)

    /O

    Thanks
    Suhas

    On Tue, Jul 12, 2016 at 5:40 PM, = Olle E. Johansson <oej@edvina.net> wrote:

    On 12 Jul 2016, at 09:55, Olle = E. Johansson <oej@edvina.net> wrote:


    General:
    I would like to see some examples using the current IP =
protocol, not the legacy IPv4,
    as well as dual stack examples.

    - An IPv6 only web browser offering an IPv4 through a relay =
ice candidate
    - A dual stack client
    - A full IPv6 exchange =
- maybe switch one of the examples using IPv4 to IPv6
      just to show the =
syntax of address and port number

    In addition I think an = offer/answer with different packetization times, like
    alaw/30 ms, Opus/60 ms or something similar. Yes, I=E2=80=99m = going down a rat hole,
    but it will come up and = we=E2=80=99d better document a proposal for how to handle = this.

    If one = wants to be messy you can add DTMF or CNG to an offer/answer = using
    alaw at 8000 hz and Opus at 48000 making it = necessary to have multiple DTMF
    and CNG for that = media stream. But that may be out of scope for this particular
    document, even though it may add clarity.

    /O


    = --Apple-Mail=_7513E0C8-5BE4-44FD-9CE4-F6406A843CD1-- From nobody Tue Jul 12 09:19:43 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E62912D1DC; Tue, 12 Jul 2016 09:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.808 X-Spam-Level: X-Spam-Status: No, score=-115.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 GfClyi4kldjL; Tue, 12 Jul 2016 09:19:37 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05ED712D1BD; Tue, 12 Jul 2016 09:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11208; q=dns/txt; s=iport; t=1468340376; x=1469549976; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jZ6SyBk2pC5delmKqH8aXQ8jb6H93jfNKtYdBbjs8hY=; b=JY+mHP74WssXmX/mFQAPGOl8bjBkQ55REbyw1M1g3UNo+xBPkZEUSIMB o/0lwFbyEM9lNFIIrak2oKu7Y7ioVA4bdWrZ1/iyP5z5VE/Aj/ZZ1/DXF meiErPihQGmWZrn3nnmXqZ4TREgLwJusa/cnTgKbp0ols0rgJlQ1rpCAL k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAgB0F4VX/4UNJK1cFoMoVnwGrG2MF?= =?us-ascii?q?oF5IoUsSgIcgRk4FAEBAQEBAQFlJ4RcAQEEAQEBIRE6AgkFBwQCAQgRBAEBAQI?= =?us-ascii?q?CERIDAgICHwYLFAEICAIEDgWIFgMPCA6xC4pfDYQeAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHIEBhyGCVYJDgVAQAgEyKIJCK4IvBYgVhyWJLTQBhg6CeoM1ghaCOIx?= =?us-ascii?q?2iByHdwEeNoIJHIFMbgGIJX8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,352,1464652800"; d="scan'208";a="128780887" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jul 2016 16:19:35 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u6CGJZMl022569 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jul 2016 16:19:35 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 12 Jul 2016 12:19:34 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Tue, 12 Jul 2016 12:19:34 -0400 From: "Cullen Jennings (fluffy)" To: "Black, David" Thread-Topic: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? Thread-Index: AQHRzhJbsZyuYvv6mE+PQ2kNBpP9KZ/5U/cAgAAHhwCAGfiowIACBRkA Date: Tue, 12 Jul 2016 16:19:34 +0000 Message-ID: <09203BA7-ED00-405C-AA66-C31D411A2B11@cisco.com> References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.171.186] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: RTCWeb IETF , Brian Carpenter , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 16:19:39 -0000 DQpzaG9ydCBhbnN3ZXIgaGVyZSBidXQgYXMgRGF2aWQgc3VnZ2VzdGVkIOKApiAgc29tZSBpbXBs ZW1lbnRhdGlvbiB1c2UgdGhlIFNUVU4gcGFja2V0cyBpbiBJQ0UgIG9yIGp1c3QgIGluIFdlYlJU QyBzdHlsZSBsaXZlbmVzcyB0ZXN0cyB0byBkbyB0aGUgdGVzdHMgb2YgaWYgYSBnaXZlbiBEU0NQ IHdvcmtzIG9yIG5vdC4gSW4gZ2VuZXJhbCBJQ0UgaXMgYSBnb29kIHRvb2wgdG8gdGFrZSBhIGJ1 bmNoIG9mIHBvc3NpYmxlIHBhdGhzLCB0ZXN0IHdoaWNoIHdvcmssIGFuZCBzZWxlY3QgdGhlIGJl c3QuIA0KDQoNCg0KPiBPbiBKdWwgMTEsIDIwMTYsIGF0IDk6NTUgQU0sIEJsYWNrLCBEYXZpZCA8 ZGF2aWQuYmxhY2tAZW1jLmNvbT4gd3JvdGU6DQo+IA0KPiBbK3J0Y3dlYl0NCj4gDQo+Pj4+IFdl IGJlbGlldmUgdGhhdCBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3Mgc2hvdWxkIHNheTogaWYg c2V0dGluZyB0aGUgRFNDUA0KPj4gdmFsdWVzIGFzIHByb3Bvc2VkIGhlcmUgY29uc2lzdGVudGx5 IHByb2R1Y2VzIHBhY2tldCBkcm9wcywgc2VuZGVycyBzaG91bGQgZmFsbA0KPj4gYmFjayB0byBE U0NQIDAuIFdlYlJUQyBzaG91bGRuJ3QgImZhaWwiIGJlY2F1c2Ugb2YgdGhlIERTQ1AuDQo+Pj4g DQo+Pj4gVGhpcyBpcyBhbiBpbnRlcmVzdGluZyBhbmQgd29ycnlpbmcgcmVzdWx0IGluZGVlZCwg YnV0IGl0J3MgaW4gbm8gd2F5IHNwZWNpZmljDQo+Pj4gdG8gV2ViUlRDLiBJIHRoaW5rIGEgZ2Vu ZXJpYyBSRkMgKCJIYXBweSBFeWViYWxscyB3aXRoIERpZmZlcmVudGlhdGVkDQo+PiBTZXJ2aWNl cyI/KQ0KPj4+IHdvdWxkIGJlIHRoZSB3YXkgdG8gZ28uDQo+PiANCj4+IFdlbGwsIGlmIHlvdSB1 c2UgdGhlIERTQ1Agd2l0aGluIHlvdXIgb3duIGFkbWluaXN0cmF0aXZlIGRvbWFpbiBmb3IgRGlm ZlNlcnYsIHlvdQ0KPj4gc2hvdWxkIGJlIHNhZmXigKYuIHNvIEkgZ3Vlc3MgdGhpcyBwcm9ibGVt IG1vc3RseSBtYXR0ZXJzIGZvciB1c2FnZSBhY3Jvc3MNCj4+IGRvbWFpbnMsIG9yIGV2ZW4gZW5k LXRvLWVuZC4NCj4+ID0+IEl0IHNlZW1zIHRvIG1lIHRoYXQgaXTigJlzIGJyb2FkZXIgdGhhbiBX ZWJSVEMgaW4gZXhhY3RseSB0aGUgc2FtZSB3YXkgYXMNCj4+IFJGQzc2NTcgaXMgYnJvYWRlciB0 aGFuIFdlYlJUQy4NCj4gDQo+IFdlIGhhdmUgYW4gaW1tZWRpYXRlIGlzc3VlIGFib3V0IHdoYXQg dG8gYWRkIHRvIHRoZSBydGN3ZWItcW9zIGRyYWZ0LCB3aGljaA0KPiBpcyBJRVNHIGFwcHJvdmVk LCBhbmQgd2lsbCBnbyB0byB0aGUgUkZDIEVkaXRvciBvbmNlIHRoaXMgY29uY2VybiBpcyByZXNv bHZlZC4NCj4gV2hpbGUgSSBncmVhdGx5IGFwcHJlY2lhdGUgTWljaGFlbCdzIHN1Z2dlc3Rpb24g b2YgdGV4dCwgSSB3b25kZXIgd2hldGhlciB0aGlzDQo+IGlzIHBhcnQgb2YgYSBsYXJnZXIgcHJv YmxlbSAuLi4NCj4gDQo+IEN1bGxlbiByZWNlbnRseSBzZW50IGEgbWVzc2FnZSB0byBUU1ZXRyBh Ym91dCBpbml0aWFsIHVzZSBvZiBiYW5kd2lkdGggYnkgSUNFIGZvciBTVFVOOg0KPiANCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90c3Z3Zy9jdXJyZW50L21zZzE0NDk3 Lmh0bWwNCj4gDQo+IFRoYXQgIG1lc3NhZ2UgYmVnaW5zIHdpdGg6DQo+IA0KPj4gV2hlbiBXZWJS VEMgY29ubmVjdGlvbnMgc3RhcnQsIHRoZXkgc2VuZCBhIGJ1bmNoIG9mIFNUVU4gcGFja2V0cyBh cyBwYXJ0IG9mIElDRS4NCj4+IFR5cGljYWxseSBtb3N0IG9mIHRoZXNlIFNUVU4gcGFja2V0cyBk byBub3QgYWN0dWFsbHkgcmVhY2ggYSB2YWxpZCBkZXN0aW5hdGlvbiBzbyB0aGV5DQo+PiBoYXZl IDEwMCUgcGFja2V0IGxvc3MgZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgc2VuZGVyLiBU aGlzIGlzIGRpc2N1c3NlZCBtb3JlDQo+PiBpbiBkcmFmdC1qZW5uaW5ncy1pY2UtcnRjd2ViLXRp bWluZy0wMQ0KPiANCj4gVGhpcyBmZWVscyBsaWtlIHBhcnQgb2YgdGhlIHNhbWUgcHJvYmxlbSAt IGJsYWNrLWhvbGluZyBjYXVzZWQgYnkgRFNDUCBzZWxlY3Rpb24gZmVlbHMNCj4gbGlrZSBpdCBj b3VsZCBiZSBkZWFsdCB3aXRoIGFzIHBhcnQgb2YgU1RVTiBwcm9iaW5nLCBhbHRob3VnaCBzb21l IGNhdXRpb24gaXMgaW4gb3JkZXINCj4gKGUuZy4sIGlmIEVGIGlzIHVzZWQgdG8gc2V0IHVwIGF1 ZGlvKS4NCj4gDQo+IFdoYXQncyB0aGUgInJpZ2h0IHdheSIgdG8gZGVhbCB3aXRoIHRoaXMgcG9z c2liaWxpdHkgdGhhdCBub24tZGVmYXVsdCBEU0NQIHVzYWdlIGJ5DQo+IFdlYiBSVEMgbWF5IGNh dXNlIGJsYWNrLWhvbGluZywgYW5kIHdoaWNoIGRyYWZ0IHNob3VsZCBzcGVjaWZ5IHRoZSBibGFj ay1ob2xlLQ0KPiBhdm9pZGFuY2UgYmVoYXZpb3I/DQo+IA0KPiBUaGFua3MsIC0tRGF2aWQNCj4g DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogdHN2d2cgW21haWx0bzp0 c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWljaGFlbCBXZWx6bA0KPj4gU2Vu dDogRnJpZGF5LCBKdW5lIDI0LCAyMDE2IDQ6NTIgUE0NCj4+IFRvOiBCcmlhbiBFIENhcnBlbnRl cg0KPj4gQ2M6IHRzdndnQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW3RzdndnXSBGYWxsLWJh Y2sgdG8gRFNDUCAwIGluIGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcyA/DQo+PiANCj4+IEhp LA0KPj4gDQo+PiANCj4+PiBPbiAyNC4ganVuLiAyMDE2LCBhdCAyMi4yNSwgQnJpYW4gRSBDYXJw ZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4NCj4+IHdyb3RlOg0KPj4+IA0KPj4+ PiBXZSBiZWxpZXZlIHRoYXQgZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zIHNob3VsZCBzYXk6 IGlmIHNldHRpbmcgdGhlIERTQ1ANCj4+IHZhbHVlcyBhcyBwcm9wb3NlZCBoZXJlIGNvbnNpc3Rl bnRseSBwcm9kdWNlcyBwYWNrZXQgZHJvcHMsIHNlbmRlcnMgc2hvdWxkIGZhbGwNCj4+IGJhY2sg dG8gRFNDUCAwLiBXZWJSVEMgc2hvdWxkbid0ICJmYWlsIiBiZWNhdXNlIG9mIHRoZSBEU0NQLg0K Pj4+IA0KPj4+IFRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgYW5kIHdvcnJ5aW5nIHJlc3VsdCBpbmRl ZWQsIGJ1dCBpdCdzIGluIG5vIHdheSBzcGVjaWZpYw0KPj4+IHRvIFdlYlJUQy4gSSB0aGluayBh IGdlbmVyaWMgUkZDICgiSGFwcHkgRXllYmFsbHMgd2l0aCBEaWZmZXJlbnRpYXRlZA0KPj4gU2Vy dmljZXMiPykNCj4+PiB3b3VsZCBiZSB0aGUgd2F5IHRvIGdvLg0KPj4gDQo+PiBXZWxsLCBpZiB5 b3UgdXNlIHRoZSBEU0NQIHdpdGhpbiB5b3VyIG93biBhZG1pbmlzdHJhdGl2ZSBkb21haW4gZm9y IERpZmZTZXJ2LCB5b3UNCj4+IHNob3VsZCBiZSBzYWZl4oCmLiBzbyBJIGd1ZXNzIHRoaXMgcHJv YmxlbSBtb3N0bHkgbWF0dGVycyBmb3IgdXNhZ2UgYWNyb3NzDQo+PiBkb21haW5zLCBvciBldmVu IGVuZC10by1lbmQuDQo+PiA9PiBJdCBzZWVtcyB0byBtZSB0aGF0IGl04oCZcyBicm9hZGVyIHRo YW4gV2ViUlRDIGluIGV4YWN0bHkgdGhlIHNhbWUgd2F5IGFzDQo+PiBSRkM3NjU3IGlzIGJyb2Fk ZXIgdGhhbiBXZWJSVEMuDQo+PiANCj4+IEFzIGEgc2lkZSBub3RlLCBJIHRoaW5rIHRoZSB0ZXJt IOKAnEhhcHB5IEV5ZWJhbGxz4oCdIGlzIG1pc2xlYWRpbmcgaGVyZS4gVGhpcyB0ZXJtLCB0bw0K Pj4gbWUsIGluZGljYXRlcyBwYXJhbGxlbCB1c2FnZSBvZiBtdWx0aXBsZSBwYWNrZXQgdHlwZXMg dG8gc2VlIHdoaWNoIG9uZShzKQ0KPj4gc3VjY2VlZChzKSBhbmQgdGhlbiB0cnkgdG8gbWFrZSB0 aGUgYmVzdCBjaG9pY2UuDQo+PiBUaGlzIGlzbuKAmXQgd2hhdCB5b3Ugd291bGQgZG8gaGVyZSAt IHdl4oCZcmUgdGFsa2luZyBhYm91dCBhIHJhcmUgZmFpbHVyZSBzaXR1YXRpb24uIEl04oCZcw0K Pj4gcmVhbGx5IG9ubHkgc29tZXRoaW5nIEnigJlkIHN1Z2dlc3QgYXMgYSBmYWxsLWJhY2ssIHVw b24gc2VlaW5nIGNvbW11bmljYXRpb24NCj4+IGZhaWxpbmcgZW50aXJlbHksIG92ZXIgYSBsb25n ZXIgcGVyaW9kIChwZXJoYXBzIGluIGxpbmUgd2l0aCBhIGNpcmN1aXQtYnJlYWtlcikuDQo+PiAN Cj4+IA0KPj4+IEJ1dCAoYXMgd2l0aCBhIGxvdCBvZiByZWNlbnQgZGlzY3Vzc2lvbiBhYm91dCBJ UHY2DQo+Pj4gZXh0ZW5zaW9uIGhlYWRlcnMgY2F1c2luZyBwYWNrZXQgZHJvcHMpIHdlIHJlYWxs eSBuZWVkIHRvIHVuZGVyc3RhbmQgd2h5DQo+PiB0aGlzDQo+Pj4gaGFwcGVucy4gSXMgaXQgdHJh ZmZpYyBwb2xpY2luZyB0aGF0IGZhaWxzIHRvIHJlY2xhc3NpZnkgYW5kIHJlLW1hcmsgcGFja2V0 cywNCj4+PiBtaXNndWlkZWQgZmlyZXdhbGxzLCBvciB3aGF0Pw0KPj4gDQo+PiBJIGhhdmUgbm8g Y2x1ZeKApiBidXQgYXMgbXkgcHJldmlvdXMgZW1haWwgc2FpZCwgd2UgaGF2ZSBpbmRpY2F0aW9u cyB0aGF0IHRoaXMNCj4+IGJlaGF2aW9yIG9jY3VycmVkIGNsb3NlIHRvIHRoZSBzZW5kZXJzICht b3N0IG9mIHRoZW0gYmVpbmcgaW4gcGVvcGxl4oCZcyBob21lcyksDQo+PiBoZW5jZSBpdOKAmXMg bW9yZSBsaWtlbHkgdGhhdCB0aGlzIHdhcyBkb25lIGJ5IGEgbWlkZGxlYm94IG9yIGFuIGVkZ2Ug cm91dGVyIHRoYW4NCj4+IGJ5IGEgY29yZSByb3V0ZXIuDQo+PiBUaGF04oCZcyBhcyBtdWNoIGFz IHdlIGtub3cuLi4NCj4+IA0KPj4gQ2hlZXJzLA0KPj4gTWljaGFlbA0KPj4gDQo+PiANCj4+PiAN Cj4+PiBSZWdhcmRzDQo+Pj4gIEJyaWFuDQo+Pj4gDQo+Pj4gT24gMjUvMDYvMjAxNiAwMDoxNywg TWljaGFlbCBXZWx6bCB3cm90ZToNCj4+Pj4gRGVhciBhbGwsDQo+Pj4+IA0KPj4+PiBXZSByZWNl bnRseSBkaWQgRFNDUCByZWxhdGVkIG1lYXN1cmVtZW50cyB0aGF0IGxlYWQgdXMgdG8gcHJvcG9z ZSBhIGNoYW5nZQ0KPj4gdG8gZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zLg0KPj4+PiBUaGVz ZSBtZWFzdXJlbWVudHMgYXJlIHJlcG9ydGVkIGluIHRoaXMgcGFwZXI6DQo+Pj4+IGh0dHA6Ly9o ZWltLmlmaS51aW8ubm8vfm1pY2hhd2UvcmVzZWFyY2gvcHVibGljYXRpb25zL2FucncxNi0NCj4+ IG1lYXN1cmVtZW50LnBkZg0KPj4+PiAuLi4gd2hpY2ggd2lsbCBiZSBwcmVzZW50ZWQgYXQgdGhl IEFOUlcgd29ya3Nob3AsIHRoZSBTYXR1cmRheSBiZWZvcmUgdGhlDQo+PiBJRVRGIG1lZXRpbmcu DQo+Pj4+IA0KPj4+PiBUaGUgcGFwZXIgcmVwb3J0cyBvbiB0ZXN0cyBiZXR3ZWVuIHBlb3BsZSdz IGhvbWVzIGFuZCAzIHNlcnZlcnMgdGhhdCB3ZQ0KPj4gcmFuIC0gb25lIGluIE9yZWdvbiAoYW1h em9uIGNsb3VkKSBhbmQgdHdvIGluIE5vcndheS4gVGhpcyBnYXZlIHVzIDE4NSBkaXN0aW5jdA0K Pj4gcGF0aHMgKElQIGFkZHJlc3MgcGFpcnMpLiBUaGUgdGVzdCB3YXMgYSBUQ1AgaGFuZHNoYWtl LCBkb25lIHdpdGggcmF3IHNvY2tldHMsDQo+PiBhbmQgd2UgcGxheWVkIGFyb3VuZCB3aXRoIHZh bHVlcyBpbiB0aGUgSVAgaGVhZGVyLiBNZWFud2hpbGUsIFJ1bmEgKG1haW4NCj4+IGF1dGhvcikg ZGlkIHNvbWUgbW9yZSB0ZXN0cyBmcm9tIHZhcmlvdXMgcHVibGljIHBsYWNlcyBkdXJpbmcgYSB0 cmlwIGZyb20gTm9yd2F5DQo+PiB0byBJbmRpYSwgZXNzZW50aWFsbHkgY29uZmlybWluZyB0aGUg ZmluZGluZyB3ZSBkaXNjdXNzIGhlcmU7IHdlJ2xsIGFzayBmb3IgYSBzbG90IHRvDQo+PiByZXBv cnQgYWJvdXQgYm90aCB0aGUgZGF0YSBpbiB0aGUgQU5SVyBwYXBlciBhbmQgdGhlIG5ld2VyIGRh dGEgaW4gdGhlIE1BUFJHDQo+PiBzZXNzaW9uLg0KPj4+PiANCj4+Pj4gVGhlIG51bWJlciBvZiBk YXRhIHBvaW50cyBpc24ndCBleGFjdGx5IGh1Z2UgaW4gYm90aCBjYXNlcywgYnV0IHN0aWxsIHJl bGV2YW50LA0KPj4gd2UgYmVsaWV2ZTogaXQgaXMgYWJvdXQgYSBwZXJzaXN0ZW50IGZhaWx1cmUg dGhhdCB3ZSBzYXcgb24gZGlmZmVyZW50IHBhdGhzLCBhbmQgc28NCj4+IHdlIHRoaW5rIGl0J3Mg cHJvYmFibHkgcmVhc29uYWJsZSB0byB0YWtlIGl0IGludG8gYWNjb3VudCAoZ2l2ZW4gdGhhdCBh IGZpeCBzaG91bGRuJ3QNCj4+IGJlIHZlcnkgY29tcGxpY2F0ZWQgZWl0aGVyKS4NCj4+Pj4gDQo+ Pj4+IFdlIHVzZWQsIGFzIGlucHV0LCBEU0NQIHZhbHVlcyBmcm9tIHRoZSB0YWJsZSBpbiBkcmFm dC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MuDQo+Pj4+IEhlcmUgYXJlIHNvbWUgc2VudGVuY2VzIGNv cHkgKyBwYXN0ZWQgZnJvbSBvdXIgcGFwZXI6DQo+Pj4+IA0KPj4+PiAqKioNCj4+Pj4gIlRvIG1p bmltaXplIHRoZSBjaGFuY2UgdGhhdCBjb25nZXN0aW9uLWJhc2VkIGRyb3BzIG1ha2UgdXMgYmVs aWV2ZSBpbiBhDQo+PiBmYWlsdXJlDQo+Pj4+IHRvIGNvbW11bmljYXRlIHVzaW5nIGNlcnRhaW4g dmFsdWVzIGluIHRoZSBJUCBoZWFkZXIsIHdlIHJlLXRyaWVkIGZhaWxlZA0KPj4gcGFja2V0DQo+ Pj4+IGV4Y2hhbmdlcyB1cCB0byB0aHJlZSB0aW1lcywgYW5kIHdlIHNlbnQgYW4gSUNNUCBwYWNr ZXQganVzdCBhaGVhZCBvZiBldmVyeQ0KPj4+PiBtZWFzdXJlbWVudCBwYWNrZXQuIFdlIG9ubHkg YXNzdW1lZCBhIGNvbW11bmljYXRpb24gZmFpbHVyZSB3aGVuIHRoZQ0KPj4gdGVzdA0KPj4+PiBm YWlsZWQgdGhyZWUgdGltZXMgYW5kIHRoZSBJQ01QIHBhY2tldCBzdWNjZWVkZWQuIg0KPj4+PiAN Cj4+Pj4gIkNvbnNpZGVyaW5nIHRhYmxlIDEgaW4gWzZdLCB3ZSBhc3N1bWVkIHRoZSBmbG93IHR5 cGUg4oCcSW50ZXJhY3RpdmUgVmlkZW8gd2l0aA0KPj4gb3INCj4+Pj4gd2l0aG91dCBBdWRpb+KA nSB3aXRoIGFwcGxpY2F0aW9uIHByaW9yaXRpZXMg4oCcVmVyeSBsb3figJ0gKERTQ1AgdmFsdWUg Q1MxICg4KSksDQo+PiDigJxMb3figJ0NCj4+Pj4gKERGICgwKSkgb3Ig4oCcTWVkaXVt4oCdIChB RjQyICgzNikpLCBhbmQgZmxvdyB0eXBlIOKAnEF1ZGlv4oCdIHdpdGggYXBwbGljYXRpb24NCj4+ IHByaW9yaXRpeQ0KPj4+PiDigJxIaWdo4oCdIChFRiBQSEIgKDQ2KSkuIg0KPj4+PiANCj4+Pj4g IldlIGRpZCBzZWUgY29uc2lzdGVudCBwYWNrZXQgZHJvcHMgdG9vOiBvbiAyMyBwYXRocyBmb3Ig RFNDUCB2YWx1ZSA4LCAyMQ0KPj4gcGF0aHMNCj4+Pj4gZm9yIDM2LCAxOSBmb3IgNDYuIg0KPj4+ PiAqKioNCj4+Pj4gDQo+Pj4+IFdlIGFsc28gc2F3IERTQ1AgdmFsdWUgY2hhbmdlcywgYnV0IG5v dGhpbmcgdmVyeSBhbGFybWluZyB0aGVyZSAtIGluIG9uZQ0KPj4gY2FzZSwgQUY0MiB3YXMgY2hh bmdlZCB0byBBRjQxLCB3aGljaCBpcyBldmVuIG5pY2UgIDopICAgICBob3dldmVyLCB0aGlzIGNv bnNpc3RlbnQNCj4+IGRyb3AgYmVoYXZpb3IgdGhhdCBhcHBlYXJzIG9ubHkgd2hlbiB1c2luZyBh IERTQ1AgdmFsdWUgIT0gMCBpc24ndCBnb29kIGF0IGFsbC4NCj4+IE5vdyB0aGVzZSB0aGluZ3Mg Y291bGQgaW4gcHJpbmNpcGxlIGhhdmUgaGFwcGVuZWQgY2xvc2UgdG8gb3VyIDMgc2VydmVycywN Cj4+IG1lYW5pbmcgdGhlcmUgd2VyZSBvbmx5IGZldyBkZXZpY2VzIHRoYXQgZGlkIGl0LCBidXQg aW4gZmFjdCB0aGlzIG1lYXN1cmVtZW50DQo+PiB3YXMgYSBwYXJ0IG9mIGEgbGFyZ2VyIG1lYXN1 cmVtZW50IGNhbXBhaWduIGluIHdoaWNoIHdlIGFsc28gY2hlY2tlZCB3aGVyZQ0KPj4gc3VjaCBw YWNrZXQgZHJvcHMgdHlwaWNhbGx5IGhhcHBlbmVkLiBUaGUgcmVzdWx0IHdhczogbW9zdCBzdWNo IGRyb3BzIHNlZW0gdG8NCj4+IGJlIGNsb3NlIHRvIHRoZSBjbGllbnQsIHdoaWNoIG1heSBpbmRp Y2F0ZSB0aGF0IHRoZXJlIHdlcmUgaW4gZmFjdCBtdWx0aXBsZSBzdWNoDQo+PiBib3hlcy4NCj4+ Pj4gDQo+Pj4+IFdlIGJlbGlldmUgdGhhdCBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3Mgc2hv dWxkIHNheTogaWYgc2V0dGluZyB0aGUgRFNDUA0KPj4gdmFsdWVzIGFzIHByb3Bvc2VkIGhlcmUg Y29uc2lzdGVudGx5IHByb2R1Y2VzIHBhY2tldCBkcm9wcywgc2VuZGVycyBzaG91bGQgZmFsbA0K Pj4gYmFjayB0byBEU0NQIDAuIFdlYlJUQyBzaG91bGRuJ3QgImZhaWwiIGJlY2F1c2Ugb2YgdGhl IERTQ1AuDQo+Pj4+IA0KPj4+PiBDaGVlcnMsDQo+Pj4+IE1pY2hhZWwNCj4+Pj4gDQo+Pj4+IA0K Pj4+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K From nobody Tue Jul 12 09:20:34 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED59212D185; Tue, 12 Jul 2016 09:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.807 X-Spam-Level: X-Spam-Status: No, score=-115.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 WxNIqbANcduQ; Tue, 12 Jul 2016 09:20:31 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E8412D12D; Tue, 12 Jul 2016 09:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5879; q=dns/txt; s=iport; t=1468340431; x=1469550031; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=crArO+E1qjhe66RCfXWxqksF6CBtnIi4D4dBfQr9lLE=; b=JImR3kuAy6zYN5mWpE+Zcj3ChejbcMnf9J1XNHTvYQvBgeltpGkyt7hd l7oOK12tocmXOFuhDBtJEvVwAC16Z74adD1xrUtNBkfxOHA144b3DH6zG 1vWExWCFuRnncBIBc+Iku2yOJsYPKQR8y7bs9u8bf/5hwY2y6DmvFi0Oc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNAgB0F4VX/4YNJK1cgnBOgVIGs3+Cd?= =?us-ascii?q?YIPgXmGGAKBNTgUAQEBAQEBAWUnhF0BBXkQAgEIPwcyFBECBA4FiDDAIwEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARyIIoJVh22CLwWZGwGOU48ukBMBHjaDcW6IJn8BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.28,352,1464652800"; d="scan'208,217";a="122975661" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jul 2016 16:20:30 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u6CGKUiR022261 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jul 2016 16:20:30 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 12 Jul 2016 12:20:29 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Tue, 12 Jul 2016 12:20:29 -0400 From: "Cullen Jennings (fluffy)" To: "Black, David" Thread-Topic: [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? Thread-Index: AQHRzhJbsZyuYvv6mE+PQ2kNBpP9KZ/5U/cAgAAHhwCAGfiowIAAC+UAgABFHwCAASQSAIAAEh2ggAB+LIA= Date: Tue, 12 Jul 2016 16:20:29 +0000 Message-ID: References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <648D8616-0AB5-4420-A829-1481B30237F4@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.171.186] Content-Type: multipart/alternative; boundary="_000_FF3823F7D4744AE3AF0F3935ED8C5381ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Gorry \(erg\)" , "Ruediger.Geib@telekom.de" , "tsvwg@ietf.org" , RTCWeb IETF , Brian Carpenter Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 16:20:33 -0000 --_000_FF3823F7D4744AE3AF0F3935ED8C5381ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 12, 2016, at 8:55 AM, Black, David > wrote: The DART work warns of the pitfalls. My suggestion is that for protocols using ICE that STUN packets could be us= ed for this path check - if this is desired. I am not sure we need to hold the cur= rent draft for this sort of addition. I'd add a sentence to say that ICE uses STUN for this sort of DSCP-specific= path check and cite the draft that specifies how that path checking is performed= . Which draft would that be? I concur that this draft on DSCP usage should not specify how path checking= is done. +1 --_000_FF3823F7D4744AE3AF0F3935ED8C5381ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <662A72B2BDF0DD48A05AEB317C4390DD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    On Jul 12, 2016, at 8:55 AM, Black, David <david.black@emc.com> wrote:
    The DART work warns of the pitfalls.

    My suggestion is that for protocols using ICE that STUN packets could be us= ed for
    this path check - if this is desired. I am not sure we need to hold the cur= rent draft
    for this sort of addition.

    I'd add a sentence to say that ICE uses STUN for this sort of DSCP-specific pa= th
    check and cite the draft that specifies how that path checking is performed.
    Which draft would that be?

    I concur that this draft on DSCP usage should not specify how path checking = is done.

    +1 

    --_000_FF3823F7D4744AE3AF0F3935ED8C5381ciscocom_-- From nobody Tue Jul 12 10:12:13 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 A3E2012D1B7; Tue, 12 Jul 2016 10:12:12 -0700 (PDT) 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.27.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160712171212.5076.26582.idtracker@ietfa.amsl.com> Date: Tue, 12 Jul 2016 10:12:12 -0700 Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: [rtcweb] Extended Last Call: (Transports for WebRTC) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jul 2016 17:12:12 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'Transports for WebRTC' 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-08-01. 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 describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jul 14 01:53:38 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F234612DB6C; Thu, 14 Jul 2016 01:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 EgZh-3yCi84w; Thu, 14 Jul 2016 01:53:19 -0700 (PDT) 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 51DD812DB6A; Thu, 14 Jul 2016 01:53:18 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-da-578752fc5598 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0D.C3.12516.CF257875; Thu, 14 Jul 2016 10:53:16 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.294.0; Thu, 14 Jul 2016 10:53:15 +0200 To: References: <20160712171212.5076.26582.idtracker@ietfa.amsl.com> From: Magnus Westerlund Message-ID: <055e8255-7ed7-b10c-43e7-b54d9542fc37@ericsson.com> Date: Thu, 14 Jul 2016 10:53:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160712171212.5076.26582.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM2K7iu6foPZwgxOHtSwu9itaPNs4n8Wi 5+0NFou1/9rZHVg8liz5yRTAGMVlk5Kak1mWWqRvl8CV0fH5PHPBApmKpRP2MTYwrhbrYuTk kBAwkbi0ZAcbhC0mceHeeiCbi0NI4AijxJbj61ghnOWMEudf/QVzhAUaGCUeTXnFBNIiIiAs ceTRP3YQW0jAQeLSwjmsIDazQJTEopYDYDVsAhYSN380Ao3l4OAVsJd4sbIYJMwioCrRsOAK WFhUIEZifV8CSJhXQFDi5MwnLCA2p4CjxO/3c1lBSpiBOh9sLYMYLi/RvHU2M8RSbYmGpg7W CYyCs5B0z0LomIWkYwEj8ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwJA9uOW37g7G1a8d DzEKcDAq8fAuaGwLF2JNLCuuzD3EKMHBrCTC+zWwPVyINyWxsiq1KD++qDQntfgQozQHi5I4 r/9LxXAhgfTEktTs1NSC1CKYLBMHp1QDY8D6ajkWg0fXD1/+rBgq8N5X9PF32VtX/m5IZFy/ 75q06j+ndxMfZrrxsht11ay5PUn+YnyX2eF73ec/Jt1axSHbZZ1dwNL1fV247omdl3b6XNXU VDyYY/rhnODc0hd/j6fuC4kwabvLXipboiK52Ekw+985Y9Vmhot8bFe2Zzx5seADa8aKbiWW 4oxEQy3mouJEANzfWr9VAgAA Archived-At: Cc: rtcweb@ietf.org, draft-ietf-rtcweb-transports@ietf.org, rtcweb-chairs@ietf.org Subject: Re: [rtcweb] Extended Last Call: (Transports for WebRTC) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jul 2016 08:53:21 -0000 Hi, I have reviewed this document in IETF last call, sorry I missed the last WG last call, thus in this stage instead. I do support the publication of this document. However, I think the below comments do need to be considered before publication approval. 1. Section 3.3: When a client gathers all IPv6 addresses on a host, and both temporary addresses and permanent addresses of the same scope are present, the client SHOULD discard the permanent addresses before exposing addresses to the application or using them in ICE. This is consistent with the default policy described in [RFC6724]. If some of the temporary IPv6 addresses, but not all, are marked deprecated, the client SHOULD discard the deprecated addresses. I haven't noticed this before, but if you have both permanent and temporary addresses, can all the temporary be marked deprecated? If that can occur, does this specification need to say something in this case which should be used, a deprecated temporary or a permanent one? 2. Section 3.4: If TCP connections are used, RTP framing according to [RFC4571] MUST be used, both for the RTP packets and for the DTLS packets used to carry data channels. I think the last part of this sentence, unintentionally excludes the DTLS handshake packets. The ICE TCP spec also specifies that the STUN connectivity checks are using RFC4571 framing. Thus, I think some reformulation of this sentence is in order. 3. Section 3.5: WebRTC implementations MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification [RFC5764], section 5.1.2. All application layer protocol payloads over this DTLS connection are SCTP packets. This text should reference also the update to RFC5764: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ That document is publication requested so even as normative reference it will hopefully have minimal impact on the publication progress of this document. 4. Section 4.2: The implementation MAY turn off use of DSCP markings if it detects symptoms of unexpected behaviour like priority inversion or blocking of packets with certain DSCP markings. The detection of these conditions is implementation dependent. As raised on the TSVWG and RTCWEB mailing list recently in regards to draft-ietf-tsvwg-rtcweb-qos there have been a recent study (https://irtf.org/anrw/2016/anrw16-final17.pdf) showing that non zero DSCP values resulted in consistent failures in 10-13% of the tested paths. So I think it worth considering if this text needs to be sharpen, and possibly actually point to a solution that needs to be specified? 5. Section 8.1: [I-D.martinsen-mmusic-ice-dualstack-fairness] Martinsen, P., Reddy, T., and P. Patil, "ICE IPv4/IPv6 Dual Stack Fairness", draft-martinsen-mmusic-ice- dualstack-fairness-02 (work in progress), February 2015. Can be updated as this is now an WG item in ICE. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jul 14 01:53:46 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB8C12DB7A; Thu, 14 Jul 2016 01:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 zAVx6Jrt4xsY; Thu, 14 Jul 2016 01:53:24 -0700 (PDT) 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 A352612DB75; Thu, 14 Jul 2016 01:53:23 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-0b-57875303a198 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 35.D3.12516.30357875; Thu, 14 Jul 2016 10:53:23 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.294.0; Thu, 14 Jul 2016 10:53:22 +0200 To: "Cullen Jennings (fluffy)" , "Black, David" References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <09203BA7-ED00-405C-AA66-C31D411A2B11@cisco.com> From: Magnus Westerlund Message-ID: <4f7acb04-6b37-0f95-3613-c127ff8b31ad@ericsson.com> Date: Thu, 14 Jul 2016 10:53:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <09203BA7-ED00-405C-AA66-C31D411A2B11@cisco.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM2K7vS5zcHu4wZa/4hZbD69lt+iYzGbx 4+xOVou1/9rZLY69ucvmwOox5fdGVo8jR2azeCxZ8pPJY/Xqh8wBLFFcNimpOZllqUX6dglc GT/e1xVMFK648WQ6UwPjVv4uRk4OCQETib4fX1ggbDGJC/fWs3UxcnEICRxhlPjT8ZAdwlnO KHFnxTU2kCphgRCJnoubwTpEBCIlFi15wQJRNJtJYvG7rewgCWaBLIm2rVuYQWw2AQuJmz8a wZp5BewlNi7vBIuzCKhKbDn3Fsjm4BAViJFY35cAUSIocXLmE7D5nAK2Es2rvrJBjLSQmDn/ PCOELS/RvHU22BghAW2JhqYO1gmMgrOQtM9C0jILScsCRuZVjKLFqcXFuelGxnqpRZnJxcX5 eXp5qSWbGIHhfXDLb90djKtfOx5iFOBgVOLhXdDYFi7EmlhWXJl7iFGCg1lJhPdrYHu4EG9K YmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBsa0znVWh48ssC0v k3xkJJLZ5iHXd3znr1PdCqtvyslbKN582h+uHmWmuPZZeEMUl/7+AMep6j94LVqzdl6evsk+ Xm1b2kzVKrfNj1S89Q34F+/eseOcoXd6l+zNsLtqC8VE3nkf8H+8UN9uA8cE87D9XHXRzKHL tfXf2ThWz04oFP4k8OPIXCWW4oxEQy3mouJEAOuz8rBrAgAA Archived-At: Cc: RTCWeb IETF , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jul 2016 08:53:26 -0000 Den 2016-07-12 kl. 18:19, skrev Cullen Jennings (fluffy): > > short answer here but as David suggested … some implementation use > the STUN packets in ICE or just in WebRTC style liveness tests to > do the tests of if a given DSCP works or not. In general ICE is a > good tool to take a bunch of possible paths, test which work, and > select the best. I do agree that how you do the path checks when setting DSCP values != 0 is dependent on the context. For the WebRTC I do agree doing checks using ICE is quite reasonable. We already have similar path testing usages of ICE in the ECN for RTP specification (RFC6679), see Section 7.2.1. I will note that taking this as blueprint for DSCP testing, what is needed clearly requires a new separate specification. The components needs are: 1) A new STUN parameter to request the ICE peer to echo the DSCP field value received. 2) A ICE capability parameter to be used in signalling negotiations to determine capability for this feature. 3) Behaviour specification on how to test values and interpret responses. This include things like if one should actually establish multiple candidate pairs one with DSCP testing and one without? So the question here is how to proceed with this issue. So I would suggest the following way forward. 1. draft-ietf-tsvwg-rtcweb-qos identifies the issue and recommends the user to apply path verification methods but don't specify them. 2. Someone takes on the task to write a DSCP path verification extension to ICE. 3. The natural place to indicate the need/recommendation for implementing this functionality would be in draft-ietf-rtcweb-transports (Currently in IETF LC). However, here I think we need to have a discussion if RTCWEB WG wants to only place a suitable warning about the need, and indicate future forthcoming specification or if we hold this document up until this solution is available? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jul 14 05:00:39 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3610112D5BF for ; Thu, 14 Jul 2016 05:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wr6DwpOxXUKQ for ; Thu, 14 Jul 2016 05:00:35 -0700 (PDT) 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 CA2FA12B04B for ; Thu, 14 Jul 2016 05:00:34 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-a4-57877ee0b0b9 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A0.2D.12926.0EE77875; Thu, 14 Jul 2016 14:00:32 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0294.000; Thu, 14 Jul 2016 14:00:32 +0200 From: Christer Holmberg To: Suhas Nandakumar , "rtcweb@ietf.org" Thread-Topic: [rtcweb] draft-ietf-rtcweb-sdp-02 submitted Thread-Index: AQHR2MAhVY8UzqHalEq8VwQLZfwqW6AX7xqA Date: Thu, 14 Jul 2016 12:00:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D3AD51DEBF59christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2J7iO6DuvZwg/n9VhZr/7WzW+yc28Hs wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGW8PNDBXvDLt6J/wzm2BsY1Tl2MnBwSAiYS k3b8ZoewxSQu3FvP1sXIxSEkcIRR4sbLb4wQzmJGid2/jrF0MXJwsAlYSHT/0wZpEBEIlPix 9ygTiC0MFP75eyMzRNxSYtvZtywQtpHE/SVfwOIsAqoSV2duYAOxeQWsJJb9OwkWFxIIkNi6 6grYEZxAM09MPM8KYjMCHfT91Bqw+cwC4hK3nsxngjhUQGLJnvPMELaoxMvH/8DqRQX0JL5/ nQ0VV5S4On05VG+8xKvPZ9kh9gpKnJz5hGUCo+gsJGNnISmbhaQMIm4g8f7cfGYIW1ti2cLX ULa+xMYvZxkhbGuJQ9M3sCCrWcDIsYpRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMA4Pbvmt uoPx8hvHQ4wCHIxKPLwLGtvChVgTy4orcw8xSnAwK4nwdtS2hwvxpiRWVqUW5ccXleakFh9i lOZgURLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpg9Lz4YM8e+dDOKSHRkx4v3ZjeUeK9atE1 hrbtqZOrVrt80FTUrZxwv8ydceJhk3Ml5eIOcdNXxWlkmJmFBGXWv91aY/12L6tUDEuUzydB 1gN19kXhn8MqEt6bv+DLVO6YOyuxKcpXg21x627vBev2Hdr5Ojjohpcpg/Z7D6aTplZ3lc5t efddiaU4I9FQi7moOBEApc12Vb8CAAA= Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-sdp-02 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jul 2016 12:00:37 -0000 --_000_D3AD51DEBF59christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, The examples are not aligned with all of the latest versions of associated = drafts. See below. Q1: Assuming we want to be compliant with draft-ice-5245bis (even though both J= SEP and your draft still reference RFC 5245), you should use the SDP 'ice-o= ptions: ice2=92 attribute (draft-ietf-mmusic-ice-sip-sdp). Q2: I think the SDP =91dtls-id=92 attribute (draft-ietf-mmusic-sdp-dtls) should= be added. Q3: According to draft-bundle, you need to include the SDP =91rtcp-mux-only=92 = attribute in bundle-only m- lines. Also in general I think it would be good to have some mux-exclusive example= s, since they support of non-mux is optional (and since some vendors have i= ndicated that they will not support non-mux long term). Regards, Christer From: rtcweb > on b= ehalf of Suhas Nandakumar > Date: Friday 8 July 2016 at 05:26 To: "rtcweb@ietf.org" > Subject: [rtcweb] draft-ietf-rtcweb-sdp-02 submitted Hello All We have submitted the -02 version of RTCWEB SDP examples draft which wen= t through quite a bit of content re-shuffling and updates to match (attempt= ) the latest versions of BUNDLE, JSEP and related drafts. Many thanks to Paul for starting the review of the draft that triggered few= formatting changes, changes related to consistency of attribute values and= their ordering, to enhance the readability throughout the draft. Please refer to the following HTML version while reviewing/reading the draf= t: https://tools.ietf.org/id/draft-ietf-rtcweb-sdp-02.html [[ It might take a short while for the data-tracker to render the above HTM= L version though ]] Here is the high-level summary of changes 1. As far as possible, the examples reflect latest BUNDLE and JSEP requirem= ents. 2. SCTP examples are updated 3. Visual markers, separators are added in the SDP table 4. SSRC values, IP Address , Port numbers, CNAMEs are consistent to a great= extent now 5. Attributes ordering is consistent across all the examples now 6. RID, Simulcast examples are matched against their latest draft versions. Please give it a read and let us know your comments/feedback. Cheers Suhas/Cullen --_000_D3AD51DEBF59christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <17739C6C0ED2A942B875CC0A5649348F@ericsson.com> Content-Transfer-Encoding: quoted-printable
    Hi,

    The examples are not aligned with all of the latest versions of associated = drafts. See below.

    Q1:

    Assuming we wan= t to be compliant with draft-ice-5245bis (even though both JSEP and your dr= aft still reference RFC 5245), you should use the SDP 'ice-options: ice2=92 attribute (draft-ietf-mmusic-ice-sip-sdp).



    Q2:

    I think the SDP =91dtls-id=92 attribute (draft-ietf-mmusic-sdp-dtls) should be added.


    Q3:

    According to draft-bundle, you need to include the SDP =91rtcp-mux-only=92 = attribute in bundle-only m- lines.

    Also in general I think it would be good to have some mux-exclusive example= s, since they support of non-mux is optional (and since some vendors have i= ndicated that they will not support non-mux long term).


    Regards,

    Christer


     

    From: rtcweb <rtcweb-bounces@ietf.org> on behalf of Suhas= Nandakumar <suhasietf@gmail.com<= /a>>
    Date: Friday 8 July 2016 at 05:26 To: "    rtcweb@ietf.org" <= rtcweb@ietf.org>
    Subject: [rtcweb] draft-ietf-rtcweb= -sdp-02 submitted

    Hello All

       We have submitted the -02 version of RTCWEB SDP examples = draft which went through quite a bit of content re-shuffling and updates to= match (attempt) the latest versions of BUNDLE, JSEP and related drafts.&nb= sp;

    Many thanks to Paul for starting the review of the draft that triggere= d few formatting changes, changes related to consistency of attribute value= s and their ordering, to enhance the readability throughout the draft.

    Please refer to the following HTML version while reviewing/reading the= draft: 


    [[ It might take a short while for the data-tracker to render the abov= e HTML version though ]]

    Here is the high-level summary of changes
    1. As far as possible, the examples reflect latest BUNDLE and JSEP req= uirements.
    2. SCTP examples are updated 
    3. Visual markers, separators are added in the SDP table
    4. SSRC values, IP Address , Port numbers, CNAMEs are consistent to a = great extent now
    5. Attributes ordering is consistent across all the examples now
    6. RID, Simulcast examples are matched against their latest draft vers= ions.

    Please give it a read and let us know your comments/feedback.

    Cheers
    Suhas/Cullen

    --_000_D3AD51DEBF59christerholmbergericssoncom_-- From nobody Thu Jul 14 06:03:51 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AC312D7D3 for ; Thu, 14 Jul 2016 06:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 k-3i_ST7rjV4 for ; Thu, 14 Jul 2016 06:03:45 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 93ED612D9CC for ; Thu, 14 Jul 2016 06:03:44 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id i12so71233542ywa.1 for ; Thu, 14 Jul 2016 06:03:44 -0700 (PDT) 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=7KfTokdNFJOfS0hUMz9EhpiHEvieuu7JHOqu0rKeVLU=; b=WIqy4Itj/xRP6gZf9gcLzW67Vlg3MS1S+zkG5Px+thgLtK8nZ6yb9lvsVBHN4pL7lT rDNiLsqHn5R3tCjk/If5qoKjthz5ayRtJD/qRhwihTsBp5h4OYb/HtinFa8j5ixdwHKZ +Tskgnxb4Kqp+aTdw9CMsSp/hMMODVPaIfm2vLa0H0sZpJgQgslnCPyxYo0gNAxezVhz JuLv8qmlvPSG20xVOw7nttu3v1/4yigkkBfxqHZl8KDx/xhaREOttdOfbl9wMMqnNhDo yKKUnuiSSI1UTOHYian1UALQWyLNml4yqBIejFDNhYWxHLCCiJ5A9szI9GnuOp4h1vMc y2Ow== 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=7KfTokdNFJOfS0hUMz9EhpiHEvieuu7JHOqu0rKeVLU=; b=A69NYKEbSr+dIJUziBKWcJL6Pr9gJ/Nrc09zZkWAncgRoE9G1t9Ogr0qZFEFtbcoAm nfht9EF3jjcYV3LrEg/Lf+R8PL7z7gD1HNbqWBlCDvYZf4/UADlaMhjrhLuGUYQ0nbLy gqfQqMrFhmNX17yYq6r5gJJxn4FBshB+ahyktpRzzZku/VDrnfZiJuc9TIDU8LbRnfFY mU2BoiBuPn4bvWcfe291vIIjzo9vNE4ZP/dKKWviHbN2icUNc/ffb7kasNiO25Tod6kd R1/g5ucuHYdLL1SPcwqa/p1J9pQ+3kSNRHwc/ZZolDKWW0WIRr/gVs5stvzylbSuXbc+ buEg== X-Gm-Message-State: ALyK8tJK1XyR9ksTvwZwdTb7vfx0OOU6d9KUVb0deg6VeTUxexsLtult8uWLbBUsL9toHwW6WxG+WHpGr8ca/A== X-Received: by 10.37.8.199 with SMTP id 190mr9299237ybi.187.1468501423580; Thu, 14 Jul 2016 06:03:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.121.3 with HTTP; Thu, 14 Jul 2016 06:03:43 -0700 (PDT) In-Reply-To: References: From: Suhas Nandakumar Date: Thu, 14 Jul 2016 18:33:43 +0530 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113db05ab47b1f05379821da Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-sdp-02 submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jul 2016 13:03:48 -0000 --001a113db05ab47b1f05379821da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Christer Thanks for reviewing the draft. Here are few general comments on how the SDP examples are laid out in the current version - It aligns closest to JSEP-14 and its dependencies - Wherever there is conflicts between JSEP-14 and BUNDLE-31 , i made a choice to stick with JSEP-14 In our presentation at IETF-96 we plan to bring up these differences as one of the open issues Please see inline for specific feedback items. On Thu, Jul 14, 2016 at 5:30 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > The examples are not aligned with all of the latest versions of associate= d > drafts. See below. > > Q1: > > Assuming we want to be compliant with draft-ice-5245bis (even though both > JSEP and your draft still reference RFC 5245), you should use the SDP 'ic= e-options: > ice2=E2=80=99 attribute (draft-ietf-mmusic-ice-sip-sdp). > > [suhas] - Agree .. it is one of open issues on draft alignments with JSEP > > > Q2: > > I think the SDP =E2=80=98dtls-id=E2=80=99 attribute (draft-ietf-mmusic-sd= p-dtls) should > be added. > > [suhas] . same issues as previous one. JSEP-15 doesn't list draft-ietf-mmusic-sdp-dtls as dependency > > Q3: > > According to draft-bundle, you need to include the SDP =E2=80=98rtcp-mux-= only=E2=80=99 > attribute in bundle-only m- lines. > > Also in general I think it would be good to have some mux-exclusive > examples, since they support of non-mux is optional (and since some vendo= rs > have indicated that they will not support non-mux long term). > > [suhas] .. There are few offers that include rtcp-mux-only (atleast 5.3.1) .. I agree we can add concrete examples on this. Also to note JSEP doesn't list rtcp-mux-only in its SDP construction rules. We hope to clarify these open issues at the upcoming meeting. > > Regards, > > Christer > > > > > From: rtcweb on behalf of Suhas Nandakumar < > suhasietf@gmail.com> > Date: Friday 8 July 2016 at 05:26 > To: "rtcweb@ietf.org" > Subject: [rtcweb] draft-ietf-rtcweb-sdp-02 submitted > > Hello All > > We have submitted the -02 version of RTCWEB SDP examples draft which > went through quite a bit of content re-shuffling and updates to match > (attempt) the latest versions of BUNDLE, JSEP and related drafts. > > Many thanks to Paul for starting the review of the draft that triggered > few formatting changes, changes related to consistency of attribute value= s > and their ordering, to enhance the readability throughout the draft. > > Please refer to the following HTML version while reviewing/reading the > draft: > > https://tools.ietf.org/id/draft-ietf-rtcweb-sdp-02.html > > [[ It might take a short while for the data-tracker to render the above > HTML version though ]] > > Here is the high-level summary of changes > 1. As far as possible, the examples reflect latest BUNDLE and JSEP > requirements. > 2. SCTP examples are updated > 3. Visual markers, separators are added in the SDP table > 4. SSRC values, IP Address , Port numbers, CNAMEs are consistent to a > great extent now > 5. Attributes ordering is consistent across all the examples now > 6. RID, Simulcast examples are matched against their latest draft version= s. > > Please give it a read and let us know your comments/feedback. > > Cheers > Suhas/Cullen > > --001a113db05ab47b1f05379821da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hello Christer

    =C2=A0Thanks for reviewi= ng the draft. Here are few general comments on how the SDP examples are lai= d out in the current version
    =C2=A0 - It aligns closest to JSEP-1= 4 and its dependencies
    =C2=A0 - Wherever there is =C2=A0conflicts= between JSEP-14 and BUNDLE-31 , i made a choice to stick with JSEP-14=C2= =A0

    In our presentation at IETF-96 we plan to brin= g up these differences as one of the open issues

    P= lease see inline for specific feedback items.


    On Thu, Jul 14, 2016 at 5:= 30 PM, Christer Holmberg <christer.holmberg@ericsson.com&= gt; wrote:
    Hi,

    The examples are not aligned with all of the latest versions of associated = drafts. See below.

    Q1:

    Assuming we want to be compliant wit= h draft-ice-5245bis (even though both JSEP and your draft still reference R= FC 5245), you should use the SDP 'ice-options: ice2=E2=80=99 attribute (draft-ietf-mmusic-ice-sip-sdp).

    [suhas] - Agree .. it is one of open issu= es on draft alignments with JSEP=C2=A0


    Q2:

    I think the SDP =E2=80=98dtls-id=E2=80=99 attribute=C2=A0(draft-ietf-mmusic-sdp-dtls) should be added.


    [suhas] . same issues as p= revious one. JSEP-15 doesn't list=C2=A0draft-i= etf-mmusic-sdp-dtls as dependency
    =C2=A0

    Q3:

    According to draft-bundle, you need to include the SDP =E2=80=98rtcp-mux-on= ly=E2=80=99 attribute in bundle-only m- lines.

    Also in general I think it would be good to have some mux-exclusive example= s, since they support of non-mux is optional (and since some vendors have i= ndicated that they will not support non-mux long term).


    [suhas] .. There are few o= ffers that include rtcp-mux-only (atleast 5.3.1) .. I agree we can add conc= rete examples on this. Also to note JSEP doesn't list rtcp-mux-only in = its SDP construction rules.=C2=A0 We hope to clarify these open issues at t= he upcoming meeting.=C2=A0

    Regards,

    Christer


    =C2=A0

    From: rtcweb <rtcweb-bounces@ietf.org> = on behalf of Suhas Nandakumar <suhasietf@gmail.com>
    Date: Friday 8 July 2016 at 05:26 To: "rtcweb@ietf.org" <rtcweb@ietf.org>
    Subject: [rtcweb] draft-ietf-rtcweb= -sdp-02 submitted

    Hello All

    =C2=A0 =C2=A0We have submitted the -02 version of RTCWEB SDP examples = draft which went through quite a bit of content re-shuffling and updates to= match (attempt) the latest versions of BUNDLE, JSEP and related drafts.=C2= =A0

    Many thanks to Paul for starting the review of the draft that triggere= d few formatting changes, changes related to consistency of attribute value= s and their ordering, to enhance the readability throughout the draft.

    Please refer to the following HTML version while reviewing/reading the= draft:=C2=A0


    [[ It might take a short while for the data-tracker to render the abov= e HTML version though ]]

    Here is the high-level summary of changes
    1. As far as possible, the examples reflect latest BUNDLE and JSEP req= uirements.
    2. SCTP examples are updated=C2=A0
    3. Visual markers, separators are added in the SDP table
    4. SSRC values, IP Address , Port numbers, CNAMEs are consistent to a = great extent now
    5. Attributes ordering is consistent across all the examples now
    6. RID, Simulcast examples are matched against their latest draft vers= ions.

    Please give it a read and let us know your comments/feedback.

    Cheers
    Suhas/Cullen


    --001a113db05ab47b1f05379821da-- From nobody Thu Jul 14 14:13:40 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C6C12D7B4; Thu, 14 Jul 2016 14:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.589 X-Spam-Level: X-Spam-Status: No, score=-5.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com 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 BvxfeqrxT4Mg; Thu, 14 Jul 2016 14:13:37 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 5287512D603; Thu, 14 Jul 2016 14:13:37 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u6ELDXoT020304 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Jul 2016 17:13:33 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u6ELDXoT020304 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1468530814; bh=v4xoEyPPi9qY4pHnF7ZDsM9MMhs=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=UcMNUiZC0pdK/UtK9dI9T795MsbfqsAniEUz4aREjlFjC/lNeCXHn0DtzklHiWlVT D+XJUAMWbAm5d0cikHwdkrWhSPfRsKqQ8U+HhRWDDIDKe1v5QHwvKLtyoU/A8RlTzy F9AnE44P/cBJ+fARdjH4Guwx1f844QSsBn3UdLvg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u6ELDXoT020304 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd55.lss.emc.com (RSA Interceptor); Thu, 14 Jul 2016 17:12:29 -0400 Received: from MXHUB303.corp.emc.com (MXHUB303.corp.emc.com [10.146.3.29]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u6ELDHBr013851 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Thu, 14 Jul 2016 17:13:17 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB303.corp.emc.com ([10.146.3.29]) with mapi id 14.03.0266.001; Thu, 14 Jul 2016 17:13:17 -0400 From: "Black, David" To: Magnus Westerlund Thread-Topic: [tsvwg] [rtcweb] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? Thread-Index: AQHR3a0xSaHR8IoUw0uUzlMNtf/AVqAYaeJg Date: Thu, 14 Jul 2016 21:13:16 +0000 Message-ID: References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <09203BA7-ED00-405C-AA66-C31D411A2B11@cisco.com> <4f7acb04-6b37-0f95-3613-c127ff8b31ad@ericsson.com> In-Reply-To: <4f7acb04-6b37-0f95-3613-c127ff8b31ad@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.41.102] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: RTCWeb IETF , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jul 2016 21:13:39 -0000 TWFnbnVzLA0KDQpJIHRoaW5rIHRoYXQncyBhIGZpbmUgc3VnZ2VzdGlvbi4gICBJIHRoaW5rIHRo ZSBuZXh0IHN0ZXAgaXM6DQoNCj4gMy4gVGhlIG5hdHVyYWwgcGxhY2UgdG8gaW5kaWNhdGUgdGhl IG5lZWQvcmVjb21tZW5kYXRpb24gZm9yDQo+IGltcGxlbWVudGluZyB0aGlzIGZ1bmN0aW9uYWxp dHkgd291bGQgYmUgaW4gZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0cw0KPiAoQ3VycmVudGx5 IGluIElFVEYgTEMpLiBIb3dldmVyLCBoZXJlIEkgdGhpbmsgd2UgbmVlZCB0byBoYXZlIGENCj4g ZGlzY3Vzc2lvbiBpZiBSVENXRUIgV0cgd2FudHMgdG8gb25seSBwbGFjZSBhIHN1aXRhYmxlIHdh cm5pbmcgYWJvdXQgdGhlDQo+IG5lZWQsIGFuZCBpbmRpY2F0ZSBmdXR1cmUgZm9ydGhjb21pbmcg c3BlY2lmaWNhdGlvbiBvciBpZiB3ZSBob2xkIHRoaXMNCj4gZG9jdW1lbnQgdXAgdW50aWwgdGhp cyBzb2x1dGlvbiBpcyBhdmFpbGFibGU/DQoNCkknbGwgYXR0ZW5kIHRoZSBUaHUgUlRDV0VCIHNl c3Npb24gaW4gQmVybGluIHRvIHNlZSBob3cgdGhpcyBjb21lcyBvdXQsDQphZnRlciB3aGljaCBp dCBzaG91bGQgYmUgc3RyYWlnaHRmb3J3YXJkIGZvciB0aGUgZHJhZnQgYXV0aG9ycyBhbmQgeW91 cnMNCnRydWx5IHRvIHdyaXRlIHRoZSBzZW50ZW5jZSBvciB0d28gdGhhdCBkcmFmdC1pZXRmLXRz dndnLXJ0Y3dlYi1xb3Mgd2lsbA0KbmVlZC4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQgW21haWx0bzpt YWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDE0 LCAyMDE2IDQ6NTMgQU0NCj4gVG86IEN1bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5KTsgQmxhY2ssIERh dmlkDQo+IENjOiBSVENXZWIgSUVURjsgTWljaGFlbCBXZWx6bDsgdHN2d2dAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFt0c3Z3Z10gW3J0Y3dlYl0gRmFsbC1iYWNrIHRvIERTQ1AgMCBpbiBkcmFm dC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MgPw0KPiANCj4gRGVuIDIwMTYtMDctMTIga2wuIDE4OjE5 LCBza3JldiBDdWxsZW4gSmVubmluZ3MgKGZsdWZmeSk6DQo+ID4NCj4gPiBzaG9ydCBhbnN3ZXIg aGVyZSBidXQgYXMgRGF2aWQgc3VnZ2VzdGVkIOKApiAgc29tZSBpbXBsZW1lbnRhdGlvbiB1c2UN Cj4gPiB0aGUgU1RVTiBwYWNrZXRzIGluIElDRSAgb3IganVzdCAgaW4gV2ViUlRDIHN0eWxlIGxp dmVuZXNzIHRlc3RzIHRvDQo+ID4gZG8gdGhlIHRlc3RzIG9mIGlmIGEgZ2l2ZW4gRFNDUCB3b3Jr cyBvciBub3QuIEluIGdlbmVyYWwgSUNFIGlzIGENCj4gPiBnb29kIHRvb2wgdG8gdGFrZSBhIGJ1 bmNoIG9mIHBvc3NpYmxlIHBhdGhzLCB0ZXN0IHdoaWNoIHdvcmssIGFuZA0KPiA+IHNlbGVjdCB0 aGUgYmVzdC4NCj4gDQo+IEkgZG8gYWdyZWUgdGhhdCBob3cgeW91IGRvIHRoZSBwYXRoIGNoZWNr cyB3aGVuIHNldHRpbmcgRFNDUCB2YWx1ZXMgIT0gMA0KPiBpcyBkZXBlbmRlbnQgb24gdGhlIGNv bnRleHQuIEZvciB0aGUgV2ViUlRDIEkgZG8gYWdyZWUgZG9pbmcgY2hlY2tzDQo+IHVzaW5nIElD RSBpcyBxdWl0ZSByZWFzb25hYmxlLg0KPiANCj4gV2UgYWxyZWFkeSBoYXZlIHNpbWlsYXIgcGF0 aCB0ZXN0aW5nIHVzYWdlcyBvZiBJQ0UgaW4gdGhlIEVDTiBmb3IgUlRQDQo+IHNwZWNpZmljYXRp b24gKFJGQzY2NzkpLCBzZWUgU2VjdGlvbiA3LjIuMS4gSSB3aWxsIG5vdGUgdGhhdCB0YWtpbmcg dGhpcw0KPiBhcyBibHVlcHJpbnQgZm9yIERTQ1AgdGVzdGluZywgd2hhdCBpcyBuZWVkZWQgY2xl YXJseSByZXF1aXJlcyBhIG5ldw0KPiBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uLiBUaGUgY29tcG9u ZW50cyBuZWVkcyBhcmU6IDEpIEEgbmV3IFNUVU4NCj4gcGFyYW1ldGVyIHRvIHJlcXVlc3QgdGhl IElDRSBwZWVyIHRvIGVjaG8gdGhlIERTQ1AgZmllbGQgdmFsdWUgcmVjZWl2ZWQuDQo+IDIpIEEg SUNFIGNhcGFiaWxpdHkgcGFyYW1ldGVyIHRvIGJlIHVzZWQgaW4gc2lnbmFsbGluZyBuZWdvdGlh dGlvbnMgdG8NCj4gZGV0ZXJtaW5lIGNhcGFiaWxpdHkgZm9yIHRoaXMgZmVhdHVyZS4gMykgQmVo YXZpb3VyIHNwZWNpZmljYXRpb24gb24gaG93DQo+IHRvIHRlc3QgdmFsdWVzIGFuZCBpbnRlcnBy ZXQgcmVzcG9uc2VzLiBUaGlzIGluY2x1ZGUgdGhpbmdzIGxpa2UgaWYgb25lDQo+IHNob3VsZCBh Y3R1YWxseSBlc3RhYmxpc2ggbXVsdGlwbGUgY2FuZGlkYXRlIHBhaXJzIG9uZSB3aXRoIERTQ1Ag dGVzdGluZw0KPiBhbmQgb25lIHdpdGhvdXQ/DQo+IA0KPiBTbyB0aGUgcXVlc3Rpb24gaGVyZSBp cyBob3cgdG8gcHJvY2VlZCB3aXRoIHRoaXMgaXNzdWUuIFNvIEkgd291bGQNCj4gc3VnZ2VzdCB0 aGUgZm9sbG93aW5nIHdheSBmb3J3YXJkLg0KPiANCj4gMS4gZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3 ZWItcW9zIGlkZW50aWZpZXMgdGhlIGlzc3VlIGFuZCByZWNvbW1lbmRzIHRoZQ0KPiB1c2VyIHRv IGFwcGx5IHBhdGggdmVyaWZpY2F0aW9uIG1ldGhvZHMgYnV0IGRvbid0IHNwZWNpZnkgdGhlbS4N Cj4gDQo+IDIuIFNvbWVvbmUgdGFrZXMgb24gdGhlIHRhc2sgdG8gd3JpdGUgYSBEU0NQIHBhdGgg dmVyaWZpY2F0aW9uIGV4dGVuc2lvbg0KPiB0byBJQ0UuDQo+IA0KPiAzLiBUaGUgbmF0dXJhbCBw bGFjZSB0byBpbmRpY2F0ZSB0aGUgbmVlZC9yZWNvbW1lbmRhdGlvbiBmb3INCj4gaW1wbGVtZW50 aW5nIHRoaXMgZnVuY3Rpb25hbGl0eSB3b3VsZCBiZSBpbiBkcmFmdC1pZXRmLXJ0Y3dlYi10cmFu c3BvcnRzDQo+IChDdXJyZW50bHkgaW4gSUVURiBMQykuIEhvd2V2ZXIsIGhlcmUgSSB0aGluayB3 ZSBuZWVkIHRvIGhhdmUgYQ0KPiBkaXNjdXNzaW9uIGlmIFJUQ1dFQiBXRyB3YW50cyB0byBvbmx5 IHBsYWNlIGEgc3VpdGFibGUgd2FybmluZyBhYm91dCB0aGUNCj4gbmVlZCwgYW5kIGluZGljYXRl IGZ1dHVyZSBmb3J0aGNvbWluZyBzcGVjaWZpY2F0aW9uIG9yIGlmIHdlIGhvbGQgdGhpcw0KPiBk b2N1bWVudCB1cCB1bnRpbCB0aGlzIHNvbHV0aW9uIGlzIGF2YWlsYWJsZT8NCj4gDQo+IA0KPiBD aGVlcnMNCj4gDQo+IE1hZ251cyBXZXN0ZXJsdW5kDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFNl cnZpY2VzLCBNZWRpYSBhbmQgTmV0d29yayBmZWF0dXJlcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFC L1RYTQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBo b25lICArNDYgMTAgNzE0ODI4Nw0KPiBGw6Ryw7ZnYXRhbiA2ICAgICAgICAgICAgICAgICB8IE1v YmlsZSArNDYgNzMgMDk0OTA3OQ0KPiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWls dG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From nobody Fri Jul 15 22:05:48 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B93F12D638; Fri, 15 Jul 2016 22:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 r2j_TveAFnRd; Fri, 15 Jul 2016 22:05:41 -0700 (PDT) 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 DE68F12D665; Fri, 15 Jul 2016 22:05:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id EF2C07C89C1; Sat, 16 Jul 2016 07:05:38 +0200 (CEST) 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 8obze9kQqJMD; Sat, 16 Jul 2016 07:05:38 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:4ef:5a6f:6b24:1d27] (unknown [IPv6:2001:470:de0a:1:4ef:5a6f:6b24:1d27]) by mork.alvestrand.no (Postfix) with ESMTPSA id E58D87C84D7; Sat, 16 Jul 2016 07:05:37 +0200 (CEST) To: Magnus Westerlund , ietf@ietf.org References: <20160712171212.5076.26582.idtracker@ietfa.amsl.com> <055e8255-7ed7-b10c-43e7-b54d9542fc37@ericsson.com> From: Harald Alvestrand Message-ID: <5789C0A0.1000709@alvestrand.no> Date: Sat, 16 Jul 2016 07:05:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <055e8255-7ed7-b10c-43e7-b54d9542fc37@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: rtcweb@ietf.org, draft-ietf-rtcweb-transports@ietf.org, rtcweb-chairs@ietf.org Subject: Re: [rtcweb] Extended Last Call: (Transports for WebRTC) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jul 2016 05:05:43 -0000 Thank you, I have filed these as issue #22 to #26 at github.com/rtcweb-wg/rtcweb-transport/issues. I think issue #25, which I entitled "DSCP bleaching", may be the difficult one to resolve. From nobody Mon Jul 18 00:56:02 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C6F12D188; Mon, 18 Jul 2016 00:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 7EiI4mZ6MgmI; Mon, 18 Jul 2016 00:55:53 -0700 (PDT) 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 7BF8C12D16C; Mon, 18 Jul 2016 00:55:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 84E567C8CCD; Mon, 18 Jul 2016 09:55:51 +0200 (CEST) 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 KGACg9FJaL8m; Mon, 18 Jul 2016 09:55:49 +0200 (CEST) Received: from [IPv6:2001:67c:370:176:6878:c63e:2ed8:62a6] (unknown [IPv6:2001:67c:370:176:6878:c63e:2ed8:62a6]) by mork.alvestrand.no (Postfix) with ESMTPSA id 176997C8CCC; Mon, 18 Jul 2016 09:55:49 +0200 (CEST) To: "Black, David" , Magnus Westerlund References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <09203BA7-ED00-405C-AA66-C31D411A2B11@cisco.com> <4f7acb04-6b37-0f95-3613-c127ff8b31ad@ericsson.com> From: Harald Alvestrand Message-ID: <578C8B84.8030800@alvestrand.no> Date: Mon, 18 Jul 2016 09:55:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: RTCWeb IETF , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 07:55:56 -0000 David, repeating for transparency what I asked in person: Can you post the links to the measurements that led to the conclusion that non-arrival of DSCP-marked packets is a big enough problem that we should develop specific mechanisms to detect it? I'd like to make sure we're all on the same page wrt what the problem is, how we can measure it, and in what contexts the problems are likely to have significant impact. (I worry in particular about how many false positives a blackhole detection mechanism is likely to have, and how much this will in turn increase randomness in performance as percieved by the user, making performance problems harder to diagnose.) On 07/14/2016 11:13 PM, Black, David wrote: > Magnus, > > I think that's a fine suggestion. I think the next step is: > >> 3. The natural place to indicate the need/recommendation for >> implementing this functionality would be in draft-ietf-rtcweb-transports >> (Currently in IETF LC). However, here I think we need to have a >> discussion if RTCWEB WG wants to only place a suitable warning about the >> need, and indicate future forthcoming specification or if we hold this >> document up until this solution is available? > I'll attend the Thu RTCWEB session in Berlin to see how this comes out, > after which it should be straightforward for the draft authors and yours > truly to write the sentence or two that draft-ietf-tsvwg-rtcweb-qos will > need. > > Thanks, --David > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Thursday, July 14, 2016 4:53 AM >> To: Cullen Jennings (fluffy); Black, David >> Cc: RTCWeb IETF; Michael Welzl; tsvwg@ietf.org >> Subject: Re: [tsvwg] [rtcweb] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? >> >> Den 2016-07-12 kl. 18:19, skrev Cullen Jennings (fluffy): >>> short answer here but as David suggested … some implementation use >>> the STUN packets in ICE or just in WebRTC style liveness tests to >>> do the tests of if a given DSCP works or not. In general ICE is a >>> good tool to take a bunch of possible paths, test which work, and >>> select the best. >> I do agree that how you do the path checks when setting DSCP values != 0 >> is dependent on the context. For the WebRTC I do agree doing checks >> using ICE is quite reasonable. >> >> We already have similar path testing usages of ICE in the ECN for RTP >> specification (RFC6679), see Section 7.2.1. I will note that taking this >> as blueprint for DSCP testing, what is needed clearly requires a new >> separate specification. The components needs are: 1) A new STUN >> parameter to request the ICE peer to echo the DSCP field value received. >> 2) A ICE capability parameter to be used in signalling negotiations to >> determine capability for this feature. 3) Behaviour specification on how >> to test values and interpret responses. This include things like if one >> should actually establish multiple candidate pairs one with DSCP testing >> and one without? >> >> So the question here is how to proceed with this issue. So I would >> suggest the following way forward. >> >> 1. draft-ietf-tsvwg-rtcweb-qos identifies the issue and recommends the >> user to apply path verification methods but don't specify them. >> >> 2. Someone takes on the task to write a DSCP path verification extension >> to ICE. >> >> 3. The natural place to indicate the need/recommendation for >> implementing this functionality would be in draft-ietf-rtcweb-transports >> (Currently in IETF LC). However, here I think we need to have a >> discussion if RTCWEB WG wants to only place a suitable warning about the >> need, and indicate future forthcoming specification or if we hold this >> document up until this solution is available? >> >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From nobody Mon Jul 18 01:16:10 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD8B12D0F7; Mon, 18 Jul 2016 01:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 93exBY_3yqvb; Mon, 18 Jul 2016 01:16:03 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD7D12D095; Mon, 18 Jul 2016 01:16:02 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-cf-578c904026fd Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1D.A2.27088.0409C875; Mon, 18 Jul 2016 10:16:01 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.294.0; Mon, 18 Jul 2016 10:16:00 +0200 To: Harald Alvestrand , "Black, David" References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <09203BA7-ED00-405C-AA66-C31D411A2B11@cisco.com> <4f7acb04-6b37-0f95-3613-c127ff8b31ad@ericsson.com> <578C8B84.8030800@alvestrand.no> From: Magnus Westerlund Message-ID: Date: Mon, 18 Jul 2016 10:15:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <578C8B84.8030800@alvestrand.no> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyM2K7sa7jhJ5wg/W/uSy2Hl7LbnGsr4vN Yu2/diDrzV02BxaPKxOusHocOTKbxWPJkp9MAcxRXDYpqTmZZalF+nYJXBnzHy9gLXitUbHv Qg9LA+NKxS5GTg4JAROJ/t67LBC2mMSFe+vZuhi5OIQEjjBKzL37mhXCWc4oceXBTUaQKmGB EImNR/YzgdgiQPa1A9OhinYwS1zfs5a5i5GDg1nAReL6nGqQGjYBC4mbPxrZQGxeAXuJmQs/ gs1hEVCVuNL6jg2kXFQgRmJ9XwJEiaDEyZlPWEDCnAK6Ep8bwcLMQFNmzj/PCGHLSzRvnc0M YgsJaEs0NHWwTmAUnIWkexaSlllIWhYwMq9iFC1OLU7KTTcy0kstykwuLs7P08tLLdnECAzl g1t+G+xgfPnc8RCjAAejEg/vguPd4UKsiWXFlbmHGCU4mJVEeFsaesKFeFMSK6tSi/Lji0pz UosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MIoe6Nq4dsu1HfOYvXwMl5xMs5mn t9n8+paG764Owd84fmguPynYvibwPnOeXOn/aPWNU1fYmlhnC57j9ndfuEI0wMH++w4HoeQJ GVdv6s3w1biu5LYpUqpm7bmPE+d84Iqco5k81fB78i3uadoV+x7NC2ZsfBt5vDBsivvBBXwJ a8T28FWpsSmxFGckGmoxFxUnAgCr7uQIYQIAAA== Archived-At: Cc: RTCWeb IETF , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 08:16:06 -0000 Den 2016-07-18 kl. 09:55, skrev Harald Alvestrand: > David, > > repeating for transparency what I asked in person: > > Can you post the links to the measurements that led to the conclusion > that non-arrival of DSCP-marked packets is a big enough problem that we > should develop specific mechanisms to detect it? > https://irtf.org/anrw/2016/anrw16-final17.pdf > I'd like to make sure we're all on the same page wrt what the problem > is, how we can measure it, and in what contexts the problems are likely > to have significant impact. > > (I worry in particular about how many false positives a blackhole > detection mechanism is likely to have, and how much this will in turn > increase randomness in performance as percieved by the user, making > performance problems harder to diagnose.) > > > On 07/14/2016 11:13 PM, Black, David wrote: >> Magnus, >> >> I think that's a fine suggestion. I think the next step is: >> >>> 3. The natural place to indicate the need/recommendation for >>> implementing this functionality would be in draft-ietf-rtcweb-transports >>> (Currently in IETF LC). However, here I think we need to have a >>> discussion if RTCWEB WG wants to only place a suitable warning about the >>> need, and indicate future forthcoming specification or if we hold this >>> document up until this solution is available? >> I'll attend the Thu RTCWEB session in Berlin to see how this comes out, >> after which it should be straightforward for the draft authors and yours >> truly to write the sentence or two that draft-ietf-tsvwg-rtcweb-qos will >> need. >> >> Thanks, --David >> >>> -----Original Message----- >>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>> Sent: Thursday, July 14, 2016 4:53 AM >>> To: Cullen Jennings (fluffy); Black, David >>> Cc: RTCWeb IETF; Michael Welzl; tsvwg@ietf.org >>> Subject: Re: [tsvwg] [rtcweb] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? >>> >>> Den 2016-07-12 kl. 18:19, skrev Cullen Jennings (fluffy): >>>> short answer here but as David suggested … some implementation use >>>> the STUN packets in ICE or just in WebRTC style liveness tests to >>>> do the tests of if a given DSCP works or not. In general ICE is a >>>> good tool to take a bunch of possible paths, test which work, and >>>> select the best. >>> I do agree that how you do the path checks when setting DSCP values != 0 >>> is dependent on the context. For the WebRTC I do agree doing checks >>> using ICE is quite reasonable. >>> >>> We already have similar path testing usages of ICE in the ECN for RTP >>> specification (RFC6679), see Section 7.2.1. I will note that taking this >>> as blueprint for DSCP testing, what is needed clearly requires a new >>> separate specification. The components needs are: 1) A new STUN >>> parameter to request the ICE peer to echo the DSCP field value received. >>> 2) A ICE capability parameter to be used in signalling negotiations to >>> determine capability for this feature. 3) Behaviour specification on how >>> to test values and interpret responses. This include things like if one >>> should actually establish multiple candidate pairs one with DSCP testing >>> and one without? >>> >>> So the question here is how to proceed with this issue. So I would >>> suggest the following way forward. >>> >>> 1. draft-ietf-tsvwg-rtcweb-qos identifies the issue and recommends the >>> user to apply path verification methods but don't specify them. >>> >>> 2. Someone takes on the task to write a DSCP path verification extension >>> to ICE. >>> >>> 3. The natural place to indicate the need/recommendation for >>> implementing this functionality would be in draft-ietf-rtcweb-transports >>> (Currently in IETF LC). However, here I think we need to have a >>> discussion if RTCWEB WG wants to only place a suitable warning about the >>> need, and indicate future forthcoming specification or if we hold this >>> document up until this solution is available? >>> >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> ---------------------------------------------------------------------- >>> Services, Media and Network features, Ericsson Research EAB/TXM >>> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> Färögatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jul 18 08:39:16 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAFC12D9CE; Mon, 18 Jul 2016 08:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 sj3ySL93f40F; Mon, 18 Jul 2016 08:39:09 -0700 (PDT) Received: from nov-007-i513.relay.mailchannels.net (nov-007-i513.relay.mailchannels.net [46.232.183.67]) (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 2EC3912DAB8; Mon, 18 Jul 2016 08:27:13 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7A2871BC3DC; Mon, 18 Jul 2016 15:27:08 +0000 (UTC) Received: from rcentral501.webserversystems.com (ip-10-27-139-41.us-west-2.compute.internal [10.27.139.41]) by relay.mailchannels.net (Postfix) with ESMTPA id B01981BC63E; Mon, 18 Jul 2016 15:27:07 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from rcentral501.webserversystems.com (rcentral501.webserversystems.com [10.132.194.146]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.6.16); Mon, 18 Jul 2016 15:27:08 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1468855627987:1225881082 X-MC-Ingress-Time: 1468855627986 Received: from pool-71-162-135-19.phlapa.fios.verizon.net ([71.162.135.19]:52974 helo=[192.168.1.12]) by rcentral501.webserversystems.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bPASE-0005wZ-HJ; Mon, 18 Jul 2016 11:27:34 -0400 References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <09203BA7-ED00-405C-AA66-C31D411A2B11@cisco.com> <4f7acb04-6b37-0f95-3613-c127ff8b31ad@ericsson.com> <578C8B84.8030800@alvestrand.no> To: rtcweb@ietf.org, tsvwg@ietf.org From: Randell Jesup Message-ID: <56c27238-3e26-7924-a84f-1d3db1f8d0dd@jesup.org> Date: Mon, 18 Jul 2016 11:24:34 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------36A82F6212DA3351186BD180" X-AuthUser: randell@jesup.org Archived-At: Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jul 2016 15:39:12 -0000 This is a multi-part message in MIME format. --------------36A82F6212DA3351186BD180 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/18/2016 4:15 AM, Magnus Westerlund wrote: > Den 2016-07-18 kl. 09:55, skrev Harald Alvestrand: >> David, >> >> repeating for transparency what I asked in person: >> >> Can you post the links to the measurements that led to the conclusion >> that non-arrival of DSCP-marked packets is a big enough problem that we >> should develop specific mechanisms to detect it? >> > > https://irtf.org/anrw/2016/anrw16-final17.pdf Interesting (especially the drops; remarking to 0 is what I'd expect). 10+ % chance of a non-working path definitely requires us to anticipate it. Using ICE makes some sense, but I'm a little concerned at multiplying the combinatorial number of connectivity checks yet again. Note this would need to be redone on ICE restart or any connection change of course. Intermediate route changes could also cause it to suddenly fail if DSCP is in-use. Fallback to DSCP 0 (or re-probing) on connection loss (or when doing media retransmits?) may also be needed, though restarting ICE should work, if ICE can re-establish quickly. -- Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way too much spam --------------36A82F6212DA3351186BD180 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    On 7/18/2016 4:15 AM, Magnus Westerlun= d wrote:
    Den 2016-07-18 kl. 09:55, skrev Harald Alvestrand:
    David,

    repeating for transparency what I asked in person:

    Can you post the links to the measurements that led to the conclusion
    that non-arrival of DSCP-marked packets is a big enough problem that we
    should develop specific mechanisms to detect it?


    https://irtf.org/anrw/2016/anrw16-final17.pdf

    Interesting (especially the drops; remarking to 0 is what I'd expect).=C2=A0 10+ % chance of a non-working path definitely requires= us to anticipate it.

    Using ICE makes some sense, but I'm a little concerned at multiplying the combinatorial number of connectivity checks yet again.

    Note this would need to be redone on ICE restart or any connection change of course.

    Intermediate route changes could also cause it to suddenly fail if DSCP is in-use.=C2=A0 Fallback to DSCP 0 (or re-probing) on connectio= n loss (or when doing media retransmits?) may also be needed, though restarting ICE should work, if ICE can re-establish quickly.

    --=20
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too=
 much spam
    --------------36A82F6212DA3351186BD180-- From nobody Tue Jul 19 02:22:57 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917E312DF75; Tue, 19 Jul 2016 02:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JrB69KShfG93; Tue, 19 Jul 2016 02:22:51 -0700 (PDT) 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 B939212DF51; Tue, 19 Jul 2016 02:10:59 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-1f-578deea10d5b Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7E.19.18043.1AEED875; Tue, 19 Jul 2016 11:10:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.294.0; Tue, 19 Jul 2016 11:10:57 +0200 To: Randell Jesup , , References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <09203BA7-ED00-405C-AA66-C31D411A2B11@cisco.com> <4f7acb04-6b37-0f95-3613-c127ff8b31ad@ericsson.com> <578C8B84.8030800@alvestrand.no> <56c27238-3e26-7924-a84f-1d3db1f8d0dd@jesup.org> From: Magnus Westerlund Message-ID: <2a211ff6-6288-61bb-98af-0101b337e72f@ericsson.com> Date: Tue, 19 Jul 2016 11:10:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <56c27238-3e26-7924-a84f-1d3db1f8d0dd@jesup.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM2K7pe6id73hBnsWsVuc3ZZlsfZfO7vF sTd32RyYPZYs+cnk8WH5OrYApigum5TUnMyy1CJ9uwSujLuzrzMVfBOsuDTnMVsD4za+LkZO DgkBE4kF5yezQ9hiEhfurWfrYuTiEBI4wijx9No+ZghnOZDzqo0VpEpYIESi5+JmFhBbRCBQ oqHjPgtE0UIWibWdn8GK2AQsJG7+aGQDsXkF7CUmTdrJCGKzCKhKXP3VzdTFyMEhKhAjsb4v AaJEUOLkzCdgMzkFbCU+TjjEDGIzA42ZOf88I4QtL9G8dTZYXEhAW6KhqYN1AqPALCTts5C0 zELSsoCReRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYIAe3PLbagfjweeOhxgFOBiVeHgV JHvDhVgTy4orcw8xSnAwK4nw9r8FCvGmJFZWpRblxxeV5qQWH2KU5mBREuf1f6kYLiSQnliS mp2aWpBaBJNl4uCUamBct1EmcSr3st5gVztBN5EAjYv71m4VFzq8/23W3yW2DF9E34ZK6CZy bZsu9Y9XlXnlKifXc/rC9s9aJ1z8KrVgQZn4rXUlj/q2Xdd0Uol5wnqs+lxy3eV284SZQVt+ /fmzenv09WVR7q+OeebJyi/4xHxCer+UWvjjNSWt4oc+iETkc6Q8KRdVYinOSDTUYi4qTgQA OkkLG0wCAAA= Archived-At: Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jul 2016 09:22:56 -0000 See inline. Den 2016-07-18 kl. 17:24, skrev Randell Jesup: > On 7/18/2016 4:15 AM, Magnus Westerlund wrote: >> Den 2016-07-18 kl. 09:55, skrev Harald Alvestrand: >>> David, >>> >>> repeating for transparency what I asked in person: >>> >>> Can you post the links to the measurements that led to the conclusion >>> that non-arrival of DSCP-marked packets is a big enough problem that we >>> should develop specific mechanisms to detect it? >>> >> >> https://irtf.org/anrw/2016/anrw16-final17.pdf > > Interesting (especially the drops; remarking to 0 is what I'd expect). > 10+ % chance of a non-working path definitely requires us to anticipate it. Yes, the measured set is small, but the existance proof for black holes due to DSCP !=0 is not good. > > Using ICE makes some sense, but I'm a little concerned at multiplying > the combinatorial number of connectivity checks yet again. This is one of the design questions. For ECN we did the choice to run the ECT path verification after we found a working path using the normal connectivity checks. The trade-off there was that it was more important to find a path with basic connectivity, rather than looking for path that supports ECN. For DSCP that choice might be different, but the alternative to make the DSCP checks sequential to basic connectivity is a clear possibility. > > Note this would need to be redone on ICE restart or any connection > change of course. Yes > > Intermediate route changes could also cause it to suddenly fail if DSCP > is in-use. Fallback to DSCP 0 (or re-probing) on connection loss (or > when doing media retransmits?) may also be needed, though restarting ICE > should work, if ICE can re-establish quickly. > Yes, I think such monitoring is needed. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jul 20 01:43:58 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53DD12B037 for ; Wed, 20 Jul 2016 01:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 sFItru2tN8Nz for ; Wed, 20 Jul 2016 01:43:53 -0700 (PDT) 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 9239512B040 for ; Wed, 20 Jul 2016 01:43:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 8A27A7C8D36 for ; Wed, 20 Jul 2016 10:43:31 +0200 (CEST) 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 k-4wGjQrK4Va for ; Wed, 20 Jul 2016 10:43:30 +0200 (CEST) Received: from [IPv6:2001:67c:370:176:f479:d798:cce4:8836] (unknown [IPv6:2001:67c:370:176:f479:d798:cce4:8836]) by mork.alvestrand.no (Postfix) with ESMTPSA id 687A47C8D35 for ; Wed, 20 Jul 2016 10:43:30 +0200 (CEST) To: rtcweb@ietf.org References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <09203BA7-ED00-405C-AA66-C31D411A2B11@cisco.com> <4f7acb04-6b37-0f95-3613-c127ff8b31ad@ericsson.com> <578C8B84.8030800@alvestrand.no> <56c27238-3e26-7924-a84f-1d3db1f8d0dd@jesup.org> <2a211ff6-6288-61bb-98af-0101b337e72f@ericsson.com> From: Harald Alvestrand Message-ID: <578F39B0.4090409@alvestrand.no> Date: Wed, 20 Jul 2016 10:43:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <2a211ff6-6288-61bb-98af-0101b337e72f@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 08:43:56 -0000 On 07/19/2016 11:10 AM, Magnus Westerlund wrote: > See inline. > > Den 2016-07-18 kl. 17:24, skrev Randell Jesup: >> On 7/18/2016 4:15 AM, Magnus Westerlund wrote: >>> Den 2016-07-18 kl. 09:55, skrev Harald Alvestrand: >>>> David, >>>> >>>> repeating for transparency what I asked in person: >>>> >>>> Can you post the links to the measurements that led to the conclusion >>>> that non-arrival of DSCP-marked packets is a big enough problem >>>> that we >>>> should develop specific mechanisms to detect it? >>>> >>> >>> https://irtf.org/anrw/2016/anrw16-final17.pdf >> >> Interesting (especially the drops; remarking to 0 is what I'd expect). >> 10+ % chance of a non-working path definitely requires us to >> anticipate it. > > Yes, the measured set is small, but the existance proof for black > holes due to DSCP !=0 is not good. Absolutely. Note that what has been shown to exist is black holes for TCP with DSCP. There are arguments that there are TCP-specific design patterns for cheap firewalls that would cause this, but we have no proof of non-existence for UDP black holes. The black hole problem is addressed by the current text in -transport (section 4.2) as follows: The implementation MAY turn off use of DSCP markings if it detects symptoms of unexpected behaviour like priority inversion or blocking of packets with certain DSCP markings. The detection of these conditions is implementation dependent. I think it is the last sentence that we're discussing modifications to. Is that correct? From nobody Wed Jul 20 01:47:14 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6F212DAEC for ; Wed, 20 Jul 2016 01:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 rQeYVXVEYSA6 for ; Wed, 20 Jul 2016 01:47:10 -0700 (PDT) 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 DC50212B040 for ; Wed, 20 Jul 2016 01:47:09 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bPn9o-0005Ao-77; Wed, 20 Jul 2016 10:47:08 +0200 Received: from dhcp-a140.meeting.ietf.org ([31.133.161.64]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bPn9n-0006g1-JV; Wed, 20 Jul 2016 10:47:08 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <578F39B0.4090409@alvestrand.no> Date: Wed, 20 Jul 2016 10:47:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <634A101D-3898-46E7-B276-FCEB747CC893@ifi.uio.no> References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <09203BA7-ED00-405C-AA66-C31D411A2B11@cisco.com> <4f7acb04-6b37-0f95-3613-c127ff8b31ad@ericsson.com> <578C8B84.8030800@alvestrand.no> <56c27238-3e26-7924-a84f-1d3db1f8d0dd@jesup.org> <2a211ff6-6288-61bb-98af-0101b337e72f@ericsson.com> <578F39B0.4090409@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 23 msgs/h 9 sum rcpts/h 26 sum msgs/h 10 total rcpts 44748 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5B2D6BB2DCEFAF1A2E48E3C3F67AA3425830D862 X-UiO-SPAM-Test: remote_host: 31.133.161.64 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 8 total 8 max/h 8 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jul 2016 08:47:13 -0000 > On 20. jul. 2016, at 10.43, Harald Alvestrand = wrote: >=20 > On 07/19/2016 11:10 AM, Magnus Westerlund wrote: >> See inline. >>=20 >> Den 2016-07-18 kl. 17:24, skrev Randell Jesup: >>> On 7/18/2016 4:15 AM, Magnus Westerlund wrote: >>>> Den 2016-07-18 kl. 09:55, skrev Harald Alvestrand: >>>>> David, >>>>>=20 >>>>> repeating for transparency what I asked in person: >>>>>=20 >>>>> Can you post the links to the measurements that led to the = conclusion >>>>> that non-arrival of DSCP-marked packets is a big enough problem >>>>> that we >>>>> should develop specific mechanisms to detect it? >>>>>=20 >>>>=20 >>>> https://irtf.org/anrw/2016/anrw16-final17.pdf >>>=20 >>> Interesting (especially the drops; remarking to 0 is what I'd = expect). >>> 10+ % chance of a non-working path definitely requires us to >>> anticipate it. >>=20 >> Yes, the measured set is small, but the existance proof for black >> holes due to DSCP !=3D0 is not good.=20 >=20 > Absolutely. >=20 > Note that what has been shown to exist is black holes for TCP with = DSCP. > There are arguments that there are TCP-specific design patterns for > cheap firewalls that would cause this, but we have no proof of > non-existence for UDP black holes. We got that message from Harald at the MAPRG presentation. Agree - we = should (and are planning to) try to repeat these tests with UDP.=20 Cheers, Michael > The black hole problem is addressed by the current text in -transport > (section 4.2) as follows: >=20 > The implementation MAY turn off use of DSCP markings if it detects > symptoms of unexpected behaviour like priority inversion or blocking > of packets with certain DSCP markings. The detection of these > conditions is implementation dependent. >=20 > I think it is the last sentence that we're discussing modifications = to. > Is that correct? >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jul 22 03:41:45 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A515E12E04E for ; Fri, 22 Jul 2016 03:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fIXw98eHilgs for ; Fri, 22 Jul 2016 03:41:41 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 B770612E04C for ; Fri, 22 Jul 2016 03:41:41 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id l72so157240072oig.2 for ; Fri, 22 Jul 2016 03:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=jnj00Gt5m34c21OxNtbBOpN772oy+SLDDY3kpPlcEKk=; b=RwnntQi4TP5YtCWxX3Oj9Mnm8vD6EnWLQjJY3BUjGR6K3zsfMLmQHBEbLPs/8/WbmW BWjEL4zDv3WFrUXUnFoIR0fu49FxddunyIRS101b9cHDUiTLvl2snNidVa7cGI+npSnM GiOcey1PIZSq4OYAkJz6+GyBpET5U/JJl57rU3+RQULzw4e0vTKoEEYz0pMVnrggJ1JW 98OYcbXE8VYgG6EukUhy3kdDpc/MFRh46CDIRQhO2yMps83CV9sLXVRhi4qMXZYhGVem tj+ZDpTsBRlOeX2t18lqCBvrSSqmsW5HfYCZSylVoLPg7h4vMRokPFJFqyWswRe77RQA zpFw== 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; bh=jnj00Gt5m34c21OxNtbBOpN772oy+SLDDY3kpPlcEKk=; b=N7L1R4I62NpISXbIfwDwDtGPO3m4xDPxiRXwv64SM0b+gb1DaOjBvM6TLyk70xY7Fw pgoPnzjR+mXIZD/dmJHcL9VM1u2JfWiO5cJev4a3Qrqg8hvySg51J7pGE0ThOs6RkTOx Sbx9FQ2gyPhvi5MQSOZN+gvuH+Ceau/fqri37cFwCxw2g95WZb2j2MfV6EmPPjvkCznE 3Nfhd5M+mkzirCJcX3+y9RrpwA2hHjFf4iiAcJ20cGReOjx25LzGlNQWoWPgvRTpXfn+ u+MKh+AzQiw4bf9p4m6gsathw+Sjbo5rHlyF4a/pWey7rjFQfKTOHVoLDcH+IwQr+3+7 tHuA== X-Gm-Message-State: AEkoout8UnqD94qK0SvmfFnr5PN2thUGI/yB3YOB2j4sAyRhKAOzR16n72bEHf2o3RBPamhOZK0C+Al6lnTP1g== X-Received: by 10.202.58.6 with SMTP id h6mr1371014oia.71.1469184100926; Fri, 22 Jul 2016 03:41:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.222.213 with HTTP; Fri, 22 Jul 2016 03:41:11 -0700 (PDT) From: Ted Hardie Date: Fri, 22 Jul 2016 12:41:11 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a113cdc9c720bd20538371446 Archived-At: Subject: [rtcweb] Critical review request X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jul 2016 10:41:44 -0000 --001a113cdc9c720bd20538371446 Content-Type: text/plain; charset=UTF-8 RTCWEB has a critical dependency on the output of both the ICE and MMUSIC drafts. In the MMUSIC group just now, the ICE chairs asked for review of ice-bis: https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/ and https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/. Progress in MMUSIC (and thus in RTCWEB) depends on these. Please review them and let the chairs of RTCWEB and ICE know you're taking them on. Thanks, Ted --001a113cdc9c720bd20538371446 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    RTCWEB has a critical dependency on the output of bot= h the ICE and MMUSIC drafts.=C2=A0 In the MMUSIC group just now, the ICE ch= airs asked for review of ice-bis:
    https://datatracker.ietf.org/doc/draft-ie= tf-ice-rfc5245bis/ and https://datatracker.ietf.org/doc/draft-ietf-ice-trickl= e/.=C2=A0

    Progress in MMUSIC (and thus in RTCWEB) de= pends on these.=C2=A0

    Please review them and let the chairs of RTCW= EB and ICE know you're taking them on.

    Thanks,
    Ted
    --001a113cdc9c720bd20538371446-- From nobody Sat Jul 23 02:38:07 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C964F12D5EB for ; Sat, 23 Jul 2016 02:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6Vy97bWTmNNA for ; Sat, 23 Jul 2016 02:38:04 -0700 (PDT) Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.105]) (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 DB09312B054 for ; Sat, 23 Jul 2016 02:38:04 -0700 (PDT) Received: from smtp14.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3B08960192 for ; Sat, 23 Jul 2016 05:38:04 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp14.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 0211E60142 for ; Sat, 23 Jul 2016 05:38:03 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.61.167.19] ([UNAVAILABLE]. [173.38.220.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Sat, 23 Jul 2016 05:38:04 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 23 Jul 2016 03:38:03 -0600 To: RTCWeb IETF Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [rtcweb] Comment on draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jul 2016 09:38:06 -0000 I think the draft should point out the privacy issues only happen with = split tunnel VPNs and many VPNs are not split. From nobody Tue Jul 26 00:42:36 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7745912D178; Tue, 26 Jul 2016 00:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 J04T4WI2B0ll; Tue, 26 Jul 2016 00:42:30 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 6962212B05B; Tue, 26 Jul 2016 00:42:29 -0700 (PDT) X-AuditID: c1b4fb2d-54bff70000000eb1-3c-57971463abce Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id BA.5A.03761.36417975; Tue, 26 Jul 2016 09:42:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.301.0; Tue, 26 Jul 2016 09:42:26 +0200 References: <20160720080244.22515.31653.idtracker@ietfa.amsl.com> To: From: Magnus Westerlund Message-ID: <297e2c18-a432-54e0-8d55-1a721031cafe@ericsson.com> Date: Tue, 26 Jul 2016 09:42:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160720080244.22515.31653.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM2K7qG6yyPRwg973phYve1ayW6z9185u cezNXTYHZo8lS34yBTBGcdmkpOZklqUW6dslcGWcm7mPreCMdMXXTxcYGxhfiXYxcnJICJhI fJq8h7WLkYtDSGA9o8TdbTvZIJzljBL3ertYQKqEBYIl5s5pZAexhQQcJZovrGIGsUUEhCSm 909gArGZBewlrvxaA1bDJmAhcfNHIxuIzQsU/9awnhXEZhFQlTjQvwnI5uAQFYiRWN+XAFEi KHFy5hOwVZwCThJHZy1jASkBGflgaxnEdHmJ5q2zmSEu0JZoaOpgncAoMAtJ9yyEjllIOhYw Mq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAzJg1t+6+5gXP3a8RCjAAejEg/vguBp4UKs iWXFlbmHGCU4mJVEeHcITw8X4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1 ILUIJsvEwSnVwBiR5Me99eDbDJa5R++/uye6gPXfbKUFp8KydNc55dx549K3WCFWxoApzC/j 9+3XQbOYtBUubFNfoL7rSfWL90oXZ+QduK17bI6+hYx3qO1ux58vPhzcECo48cMSj9U7FopZ TZgeHiA18RQb06YbvFEqyvxdUdEmado797prz/QojKzNde/0KldiKc5INNRiLipOBACUncNX RQIAAA== Archived-At: Cc: "rtcweb@ietf.org" , tsvwg Subject: Re: [rtcweb] [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-17.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jul 2016 07:42:31 -0000 AVTCORE WG, (cc RTCWEB and TSVWG) The AD plans to approve this at the end of the Week. So if you have any issues with the new text, this is the time to raise it. Cheers Magnus Den 2016-07-20 kl. 10:02, skrev internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance of the IETF. > > Title : Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions > Authors : Colin Perkins > Varun Singh > Filename : draft-ietf-avtcore-rtp-circuit-breakers-17.txt > Pages : 25 > Date : 2016-07-20 > > Abstract: > The Real-time Transport Protocol (RTP) is widely used in telephony, > video conferencing, and telepresence applications. Such applications > are often run on best-effort UDP/IP networks. If congestion control > is not implemented in these applications, then network congestion can > lead to uncontrolled packet loss, and a resulting deterioration of > the user's multimedia experience. The congestion control algorithm > acts as a safety measure, stopping RTP flows from using excessive > resources, and protecting the network from overload. At the time of > this writing, however, while there are several proprietary solutions, > there is no standard algorithm for congestion control of interactive > RTP flows. > > This document does not propose a congestion control algorithm. It > instead defines a minimal set of RTP circuit breakers: conditions > under which an RTP sender needs to stop transmitting media data, to > protect the network from excessive congestion. It is expected that, > in the absence of long-lived excessive congestion, RTP applications > running on best-effort IP networks will be able to operate without > triggering these circuit breakers. To avoid triggering the RTP > circuit breaker, any standards-track congestion control algorithms > defined for RTP will need to operate within the envelope set by these > RTP circuit breaker algorithms. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-17 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-circuit-breakers-17 > > > 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/ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jul 26 02:35:41 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9B912D09C for ; Tue, 26 Jul 2016 02:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 72E8TW-9R-sa for ; Tue, 26 Jul 2016 02:35:38 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 5D4ED12B03D for ; Tue, 26 Jul 2016 02:35:38 -0700 (PDT) X-AuditID: c1b4fb2d-55fff70000000eb1-6d-57972ee667be Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id D1.B3.03761.6EE27975; Tue, 26 Jul 2016 11:35:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.208]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0301.000; Tue, 26 Jul 2016 11:35:34 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: JSEP: Associate answer with offer Thread-Index: AdHexV6/LpEDnFnISjqdHvLt16PumQ== Date: Tue, 26 Jul 2016 09:35:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B476E6187@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_7594FB04B1934943A5C02806D1A2204B476E6187ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM2K7ru4LvenhBh/bJS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsL3y5kLNhtWvOhawNzAeFK7i5GTQ0LAROLuzw2sXYxcHEIC 6xklujeuZ4FwljBK3Nr8krmLkYODTcBCovsfWIOIgLrE5YcX2EFsYQEtiVsr57JDxPUl7rVt gbL1JD48ec4KYrMIqEqcvLKUBcTmFfCVmPVgNyOIzSggJvH91BomEJtZQFzi1pP5TBAHCUgs 2XOeGcIWlXj5+B8rhK0ksWL7JUaI+nyJnvYeRoiZghInZz5hmcAoOAvJqFlIymYhKYOI60gs 2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2MQJD/+CW 37o7GFe/djzEKMDBqMTDuyB4WrgQa2JZcWXuIUYJDmYlEd5LutPDhXhTEiurUovy44tKc1KL DzFKc7AoifP6v1QMFxJITyxJzU5NLUgtgskycXBKNTCG+0htEONawWuoLKZ/9tu8zwrOc5r5 vleayqSmKodqzfp6/VT0w+MmF/Z0PvQRUMpoeHD2Z9VuhdjOONb3TCK5t359mvulZhJzfW2v /In7rbcLl0/nyGLt17r5npnZ/SVf4989ic1OKa9uTHA+6t76eO87sU/tfC5aZm7Pz4SedeXY Gfli8gIlluKMREMt5qLiRACtfJq3eQIAAA== Archived-At: Subject: [rtcweb] JSEP: Associate answer with offer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jul 2016 09:35:40 -0000 --_000_7594FB04B1934943A5C02806D1A2204B476E6187ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Assume the following: 1) Alice calls createOffer(), and sends the generated offer (offer X) = towards Bob. 2) Alice calls createOffer() again, and sends the generated offer (off= er Y) towards Bob. 3) Alice receives an answer from Bob. How does Alice know whether the answer is associated with offer X (in which= case I assume Alice should discard it) or with offer Y? Since JSEP allows multiple outstanding offers (per section 3.2), there need= s to be a mechanism for associating an answer with a specific offer. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B476E6187ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi,

     

    Assume the following:

     

    1)      Alice calls createOffer(), and sends the generated = offer (offer X) towards Bob.

    2)      Alice calls createOffer() again, and sends the gene= rated offer (offer Y) towards Bob.

    3)      Alice receives an answer from Bob.

     

    How does Alice know whether the answer is associated= with offer X (in which case I assume Alice should discard it) or with offe= r Y?

     

    Since JSEP allows multiple outstanding offers (per s= ection 3.2), there needs to be a mechanism for associating an answer with a= specific offer.

     

    Regards,

     

    Christer

    --_000_7594FB04B1934943A5C02806D1A2204B476E6187ESESSMB209erics_-- From nobody Tue Jul 26 11:48:40 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB2112D8D4 for ; Tue, 26 Jul 2016 11:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 K94-QxxXeL7a for ; Tue, 26 Jul 2016 11:48:35 -0700 (PDT) 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 6518412D59E for ; Tue, 26 Jul 2016 11:48:35 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id b62so36051793iod.3 for ; Tue, 26 Jul 2016 11:48:35 -0700 (PDT) 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; bh=M81nRnLNyBzHEahAM0+SpE3YZHpCLgkFHLdw/d/FkZw=; b=JR8r+Wrz/GRMYdpg46+ivC1FrCzkHzsXvLtoHO98UPLbMHqy5MmwhvsMD4JT+H0cI4 h02YtKTwNDiZo+O9bWwc78M+0XDZXB5Pdw1EGoSxGIRsFZ3RalSykLIZBjD+lv5yJ5e+ CFi7z0ScqTtwZBAipzmtcC7HwZ8FC5gZ7uL5KUu3BjnqzaQzxy2e1djjjZhhZFrvpXpy 7tbHoK+uoG/B9j0qC/TET6n5d+ISy+jHltrO+8vSv7PNfRGJShHi6TzebK56S2rp+wZs KfegFvX8eN4EkAyBigmSyN46sP1eGmmJnDqMbO0DOBFtfToZ+UtFSwCuX+M2m71vnOIV MCxA== 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; bh=M81nRnLNyBzHEahAM0+SpE3YZHpCLgkFHLdw/d/FkZw=; b=k0LCrwvef1WfNcCRZvPRoLXLoesbHac5kgKF5lhTtbLToU1TfRX73E7q6jhBKtUhNY IZ2J4c1NuSQ82Eo1QdV000GlzVjbdyuvXdMnW0qGXVa7s13/ujnrhHPHMAOEUuEf7+/x VpOrt7wsvPnJzZoh0b8cOqmfhi1k8aVdZqOkF3WN3iaEZvklPs6vCpcmLlQC03GSQ9Jh veNkiUhikWyU4yiUk/pZH23cosB/kmYWhetk/NIQ9tv0/gMFTXWDPkug9IodICdomQSP upSArA2frhxpJEnVZasVX4vG31Dw78wO8N/h3+lNHyef+zpDtLsZ2L4b85eYEIDgzKcR /5Cw== X-Gm-Message-State: AEkoouuvr3PjYYau0YxfyZ+vXhttscrR3YiJFzo6pUDNnffHJZPrglfItR9OwvRB/Y42FCH6YWOioyZTZc8WiQ== X-Received: by 10.157.58.53 with SMTP id j50mr14013409otc.118.1469558914396; Tue, 26 Jul 2016 11:48:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.222.213 with HTTP; Tue, 26 Jul 2016 11:48:04 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Tue, 26 Jul 2016 11:48:04 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1147191011b9d505388e5977 Archived-At: Subject: [rtcweb] Fwd: RTCWEB session notes X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jul 2016 18:48:39 -0000 --001a1147191011b9d505388e5977 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Many thanks to Bo for the notes from our session. Please review and comment on the list, so that we can update them for the mintues, Thanks, Ted Hi! > > > > Here are my notes from the RTCWEB session July 22. > > > > Cheers, > > Bo > ------------------------------ RTCWEB Administrivia Note taker: Bo Burman Jabber scribe: Olle E. Johansson The chairs pointed out that the WG progress depends on a few drafts in other WG (ICE bis , Trickle ICE and STUN bis ) that urgently need review and solicited volunteers to review them. Eric Rescorla and Magnus Westerlund accepted to review. DSCP Black-holing Issue David Black (TSVWG co-chair) presented the DSCP black-hole issue with -rtcweb-transports draft that was recently discussed on the list. This issue needs to be solved and described, even though both -rtcweb-transports and the referenced draft-ietf-tsvwg-rtcweb-qos has gone through IESG review. Magnus Westerlund has suggested a solution to the list, but what should the -rtcweb-transports draft say about DSCP black-holing and the possibility to use ICE to avoid it? The WG discussed this and concluded that the issue should be described by the -rtcweb-transports draft. Ted Hardie summarized the discussion by suggesting a text formulation for a resolution that seemed acceptable to the WG: =E2=80=9CWe will treat DSCP-induced path failure parallel with othe= r types of path failures and resolve it by using ICE restart. Note: There is a problem with multiple DSCP codepoints on a single transport, where one might be blocked and other might get through. In this case, the ICE probes, using one DSCP codepoint, may succeed while others fail. This is complex and should be warned about. A likely viable solution is ICE restart with DSCP markings turned off, but detection requires watching the multiple-DCSP-codepoint-using channels for differential failures=E2=80=9D. = If there are other proposals for resolution, please contact Harald. Cullen Jennings asked David if this solution was acceptable, but David wanted to see the text proposal. The -rtcweb-transports author Harald Alvestrand took on the action item and will work with Justin Uberti to send a text proposal to the list. Draft status update JSEP A number of tracker issues were discussed and concluded on. *Codecs in re-offer [PR #269]* The proposed solution is that codecs in an SDP re-offer can only be a subset of what was negotiated, not what the remote sent (which will be strange if the re-offering part is the originally answering one). Paul Kyzivat (remote) commented that this is an old story in SIP Offer/Answer and turned out to be a bad answer. The topic is discussed in RFC 6337. In an SDP re-offer, you should offer everything you are capable of and think is interesting. A brief discussion concluded that this would cause change of codec depending on who sends the re-offer, for example if A and B offer (foo, bar) and (bar, foo), respectively (with order reflecting preferences). So, the SDP re-offer should, as proposed in the slide, include a subset of what was negotiated before. Paul was not happy with this, but did not think it worth pursuing. *Enforce max-bundle on offer processing [PR #282]* There was a long discussion on how to enforce max-bundle; the conclusion is basically to go with the proposal on the slide (only the first m=3D line is accepted), per design and for symmetry reasons. A clarification to that rule was found when an offer is received with some m=3D lines bundled and some not; you accept all m=3D lines that are possible to bundle with the first m=3D line. *Rewrite LS handling text to indicate edge cases and that we're living with them [PR #276 & #263]* The conclusion was to go with the proposal, even if this is a simple LS group strategy. Justin Uberti commented (via Jabber) that it is always possible to let the JavaScript (app) to create new m=3D lines that have a n= ew LS group if it wants to. *addIceCandidate() and ICE restart [#250]* The conclusion was that we need an unambiguous indication in ICE: =E2=80=9C= this is the last candidate=E2=80=9D for a certain ufrag, which should (probably) be specified in JSEP and not in any ICE WG specification. *Roll back ICE restart [#250]* Decision to go with what is described on the slide. *SDP o=3D line increment [#239]* While the proposed solution on the slide was accepted, it was noted that the proposal on the slide goes against what was agreed at last meeting. Emil Ivov also commented that Trickle ICE for SIP does exactly what is described on the slide. Jonathan Lennox said that we should make sure this is compatible with whatever is done in trickle ICE SIP stacks. *addTrack assignment [#288]* Peter Thatcher commented that it is necessary to scope this down even more compared to what is proposed on the slide, to in some cases not allow re-using m-sections after an ICE restart. There=E2=80=99s still some risk t= hat another edge case will turn up. Adam Roach suggested that a better approach might be to instead detail what =E2=80=9Ccompatible=E2=80=9D means. Justin = Uberti wondered how to normatively define that m-sections are =E2=80=9Ccompatible=E2=80=9D,= but supports adding stricter text that allows for better determinism. Peter said that it is always possible to use addTransceiver to avoid any ambiguity with addTrack. Ted commented that this is a substantial algorithm change. He then gave Peter and Justin the task to generate fresh text that captures Peter=E2=80=99s point for scoping down even more and send it to the mailing= list. draft-ietf-rtcweb-sdp *Open issue: a=3Drtcp usage* There are three apparently conflicting statements around use of =E2=80=9Ca= =3Drtcp=E2=80=9D in JSEP, BUNDLE-31 and ICE-SIP-SDP-08. This seems more appropriate to discuss in MMUSIC WG. JSEP should be consistent with whatever solution is specified by BUNDLE and ICE-SIP-SDP, but should be allowed to make it clear what the implementation should do. Bug #296 was opened in the JSEP tracker. Ted suggested to send the entire slide deck to MMUSIC WG and ask for time to present it during their session on Friday July 22nd. *Open issue: a=3Dfingerprint* BUNDLE-31 was thought to be correct and JSEP should align with that. *Open issue: a=3Drtcp-mux-only* The conclusion is to update JSEP to align with BUNDLE-31. JSEP bug #297 opened. *JSEP SDP Usage vs Generic SDP Usage* Christer commented that it would be good to note that provisional answer is used in JSEP, but is not possible in generic (RFC 3264) SDP usage without specific signaling. *ICEbis vs RFC 5245 reference* Cullen suggested that this draft should reference ICE bis, trickle ICE and STUN bis rather than the predecessors, which was not challenged by the WG. *Next steps* This draft is really hard to review and the chairs are really grateful for Paul=E2=80=99s ongoing review of it, but it would be great if someone else = was able to review it too. Jonathan commented that it would be good if the SDP examples in this draft could be automatically extracted and used for testing. Cullen explained that this is the intent. He also clarified that the examples are currently not machine generated, mainly because none of the current implementations support all of what is in this draft and it would take much work to support all of it. If someone is able to provide machine-generated examples that could replace the hand-generated ones currently in the draft, they would happily be accepted. Justin Uberti offered via Jabber to write some JavaScript to machine-generate SDP examples. Tim Panton proposed to have a look at the possibility having ORTC generate SDP. Summing Up Ted stressed once more that review of RTCWEB documents, mainly the JSEP draft, is really needed if we are going to be able to take all needed documents to WGLC before IETF 97 in Seoul in November. Alissa Cooper (ART co-AD) asked if the previously discussed, organized draft review activities are still planned. The RTCWEB chairs explained that the situation has proven to be less bad than was originally thought, but some reviews will likely will needed. We will likely need some review activity during September, maybe as virtual interim meetings or in some type of review teams, which will hopefully take us to WGLC for all the documents before IETF 97 in Seoul. --001a1147191011b9d505388e5977 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Many thanks to Bo for the notes from our session= .=C2=A0 Please review and comment on the list, so that we can update them f= or the mintues,

    Thanks,

    Ted


    Hi!

    =C2=A0

    Here are my notes from the RTCWEB session July 22.

    =C2=A0

    Cheers,

    Bo

    RTCWEB

    Administrivia

    Note taker: Bo Burman

    Jabber scribe: Olle E. Johansson

    The chairs pointed out that the WG progress depends = on a few drafts in other WG (ICE bis, Trickle ICE and STUN bis) that urgently need review and solicited voluntee= rs to review them. Eric Rescorla and Magnus Westerlund accepted to review.<= u>

    =C2=A0

    DSCP Black-holing Issue

    David Black (TSVWG co-chair) presented the DSCP blac= k-hole issue with -rtcweb-transports draft that was recently discussed = on the list. This issue needs to be solved and described, even though both = -rtcweb-transports and the referenced draft-ietf-tsvwg-rtcweb-qos has gone through IESG review. Magnus Westerlund has suggested a solution t= o the list, but what should the -rtcweb-transports draft say about DSCP bla= ck-holing and the possibility to use ICE to avoid it?

    The WG discussed this and concluded that the issue s= hould be described by the -rtcweb-transports draft. Ted Hardie summarized t= he discussion by suggesting a text formulation for a resolution that seemed= acceptable to the WG: =E2=80=9CWe will treat DSCP-induced path failure parallel with other types of path failures and r= esolve it by using ICE restart. Note: There is a problem with multiple DSCP= codepoints on a single transport, where one might be blocked and other mig= ht get through. In this case, the ICE probes, using one DSCP codepoint, may succeed while others fail. This = is complex and should be warned about. A likely viable solution is ICE rest= art with DSCP markings turned off, but detection requires watching the mult= iple-DCSP-codepoint-using channels for differential failures=E2=80=9D. If there are other proposals for resol= ution, please contact Harald. Cullen Jennings asked David if this solution = was acceptable, but David wanted to see the text proposal. The -rtcweb-tran= sports author Harald Alvestrand took on the action item and will work with Justin Uberti to send a text proposal t= o the list.

    =C2=A0

    Draft status update<= /h2>

    JSEP

    A number of tracker issues were discussed and conclu= ded on.

    Codecs in re-offer [PR #269]

    The proposed solution is that codecs in an SDP re-of= fer can only be a subset of what was negotiated, not what the remote sent (= which will be strange if the re-offering part is the originally answering o= ne). Paul Kyzivat (remote) commented that this is an old story in SIP Offer/Answer and turned out to be a bad a= nswer. The topic is discussed in RFC 6337. In an SDP re-offer, you should o= ffer everything you are capable of and think is interesting. A brief discus= sion concluded that this would cause change of codec depending on who sends the re-offer, for example if A and = B offer (foo, bar) and (bar, foo), respectively (with order reflecting pref= erences). So, the SDP re-offer should, as proposed in the slide, include a = subset of what was negotiated before. Paul was not happy with this, but did not think it worth pursuing.<= u>

    Enforce max-bundle on offer processing [PR #282]<= u>

    There was a long discussion on how to enforce max-bu= ndle; the conclusion is basically to go with the proposal on the slide (onl= y the first m=3D line is accepted), per design and for symmetry reasons. A = clarification to that rule was found when an offer is received with some m=3D lines bundled and some not; you a= ccept all m=3D lines that are possible to bundle with the first m=3D line.<= u>

    Rewrite LS handling text to indicate edge cases a= nd that we're living with them [PR #276 & #263]

    The conclusion was to go with the proposal, even if = this is a simple LS group strategy. Justin Uberti commented (via Jabber) th= at it is always possible to let the JavaScript (app) to create new m=3D lin= es that have a new LS group if it wants to.

    addIceCandidate() and ICE restart [#250]

    The conclusion was that we need an unambiguous indic= ation in ICE: =E2=80=9Cthis is the last candidate=E2=80=9D for a certain uf= rag, which should (probably) be specified in JSEP and not in any ICE WG spe= cification.

    Roll back ICE restart [#250]

    Decision to go with what is described on the slide.<= u>

    SDP o=3D line increment [#239]<= /p>

    While the proposed solution on the slide was accepte= d, it was noted that the proposal on the slide goes against what was agreed= at last meeting. Emil Ivov also commented that Trickle ICE for SIP does ex= actly what is described on the slide. Jonathan Lennox said that we should make sure this is compatible with what= ever is done in trickle ICE SIP stacks.

    addTrack assignment [#288]

    Peter Thatcher commented that it is necessary to sco= pe this down even more compared to what is proposed on the slide, to in som= e cases not allow re-using m-sections after an ICE restart. There=E2=80=99s= still some risk that another edge case will turn up. Adam Roach suggested that a better approach might be to instead d= etail what =E2=80=9Ccompatible=E2=80=9D means. Justin Uberti wondered how t= o normatively define that m-sections are =E2=80=9Ccompatible=E2=80=9D, but = supports adding stricter text that allows for better determinism. Peter said that it is always possible to use addTransceiver to avoid any a= mbiguity with addTrack. Ted commented that this is a substantial algorithm = change. He then gave Peter and Justin the task to generate fresh text that = captures Peter=E2=80=99s point for scoping down even more and send it to the mailing list.

    =C2=A0

    draft-ietf-rtcweb-sdp

    Open issue: a=3Drtcp usage

    There are three apparently conflicting statements ar= ound use of =E2=80=9Ca=3Drtcp=E2=80=9D in JSEP, BUNDLE-31 and ICE-SIP-SDP-0= 8. This seems more appropriate to discuss in MMUSIC WG. JSEP should be cons= istent with whatever solution is specified by BUNDLE and ICE-SIP-SDP, but should be allowed to make it clear what the implement= ation should do. Bug #296 was opened in the JSEP tracker. Ted suggested to = send the entire slide deck to MMUSIC WG and ask for time to present it duri= ng their session on Friday July 22nd.

    Open issue: a=3Dfingerprint

    BUNDLE-31 was thought to be correct and JSEP should = align with that.

    Open issue: a=3Drtcp-mux-only

    The conclusion is to update JSEP to align with BUNDL= E-31. JSEP bug #297 opened.

    JSEP SDP Usage vs Generic SDP Usage=

    Christer commented that it would be good to note tha= t provisional answer is used in JSEP, but is not possible in generic (RFC 3= 264) SDP usage without specific signaling.

    ICEbis vs RFC 5245 reference

    Cullen suggested that this draft should reference IC= E bis, trickle ICE and STUN bis rather than the predecessors, which was not= challenged by the WG.

    Next steps

    This draft is really hard to review and the chairs a= re really grateful for Paul=E2=80=99s ongoing review of it, but it would be= great if someone else was able to review it too.

    Jonathan commented that it would be good if the SDP = examples in this draft could be automatically extracted and used for testin= g. Cullen explained that this is the intent. He also clarified that the exa= mples are currently not machine generated, mainly because none of the current implementations support all of what is = in this draft and it would take much work to support all of it. If someone = is able to provide machine-generated examples that could replace the hand-g= enerated ones currently in the draft, they would happily be accepted. Justin Uberti offered via Jabber to write = some JavaScript to machine-generate SDP examples. Tim Panton proposed to ha= ve a look at the possibility having ORTC generate SDP.

    =C2=A0

    Summing Up

    Ted stressed once more that review of RTCWEB documen= ts, mainly the JSEP draft, is really needed if we are going to be able to t= ake all needed documents to WGLC before IETF 97 in Seoul in November.

    Alissa Cooper (ART co-AD) asked if the previously di= scussed, organized draft review activities are still planned. The RTCWEB ch= airs explained that the situation has proven to be less bad than was origin= ally thought, but some reviews will likely will needed. We will likely need some review activity during Septem= ber, maybe as virtual interim meetings or in some type of review teams, whi= ch will hopefully take us to WGLC for all the documents before IETF 97 in S= eoul.

    =C2=A0


    --001a1147191011b9d505388e5977-- From nobody Wed Jul 27 07:22:22 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFA512DADD for ; Wed, 27 Jul 2016 07:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qTn5TXlTslZp for ; Wed, 27 Jul 2016 07:22:07 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 8C12E12DAB3 for ; Wed, 27 Jul 2016 07:22:06 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id f6so50313237ith.0 for ; Wed, 27 Jul 2016 07:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=v1IcATz7ScBo8pbhjH6a5TH9PJw6rVbTCfgS1YZFOvI=; b=fpKAmOBnLg00/seIm+5SyDo8XXEzMiUN4MRhx6/SwvKvSgY6jKbxCoNrJlGnEqReMN eMZWlctpxpektwp+Yb/AMiHBboacjZixfBsSxOgvmrSLZcAaAZD4W2KvmZwzyCDRxDS8 ET6ai2YLPTIspl4tiuy1aQEE2kCQcvNMWSOasWK4YB/8zOD4GOUE+GmtCavt3Hrj5sP3 Z7RnsB+QeLFHf/vEXAWh0Z+AMD3reJTT826UmfHQy6fF23nT69TdC04hhYyJMN8uXyVF WYttJpwqgBd4TzM9RCEWPL46UrJRWgdv2CS+agLtmVx4id+zSsTG+cF4gNAw+xdsNC/h byBQ== 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; bh=v1IcATz7ScBo8pbhjH6a5TH9PJw6rVbTCfgS1YZFOvI=; b=NkKhHVyy4kJQJSIIMaQHBfYxlin3//yR8qVcvdWW3LGRt6ijRsLdLezX/f3ptZIbXs N/9VfTkhAYglffxiOR5lIuiuy8rhz2Pq7kz3+j6xwJ7vVNzwvXg7zjhUCscS5ywnog3m nRD9uhtMbZ1eorIovLJO7XkeJgXa1K1a6ycI8CxayFO2nYR1PJn0ZSoeuSamL+vZm0XL AObSIjm2zMM2Q6TegohAtRaAhk4/RImLtg8Ghm8jLbXFf4F9A3N+d+8bm/RE6KUjQQzk pJPh9hjWhn+EIRcwdf8dQHYUTqtOsJqXpTr8lQaTsawOnfP9Z8XqL3G6gZ0I0DtMf4mn Cszg== X-Gm-Message-State: AEkoouslM/YHHwAEw0DlKSANIN9LKE/A3br+Cp11x6wrlMIAVUhDHXgts7vs+yvOyvzx7x1O1+lkTI4mZ81zTw== X-Received: by 10.36.123.72 with SMTP id q69mr34971311itc.33.1469629325785; Wed, 27 Jul 2016 07:22:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.115.134 with HTTP; Wed, 27 Jul 2016 07:22:05 -0700 (PDT) From: Andy Hutton Date: Wed, 27 Jul 2016 15:22:05 +0100 Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=001a1145a578ea4bee05389ebdb4 Archived-At: Subject: [rtcweb] JSEP Direction in offers. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jul 2016 14:22:09 -0000 --001a1145a578ea4bee05389ebdb4 Content-Type: text/plain; charset=UTF-8 https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-15#section-5.2.4 states: "[RFC3264] direction attributes (defined in Section 6.1) in offers are chosen according to the states of the RtpSender and RtpReceiver of a given RtpTransceiver" I spent some time thinking about this and trying to work out whether it worked for re-offers and my conclusion is that the above statement is not strictly correct but hopefully this is not a big problem. It all depends on what the above statement means by "the states of the RtpSender/Receiver". My understanding is that to change the direction an application calls setDirection() on the transceiver before createOffer and this would cause the direction to be set accordingly in the offer but actually the RTCRtpTransceiverDirection does not change until setLocal or setRemote is called. Would it make sense to change the statement in 5.2.4 to: "[RFC3264] direction attributes (defined in Section 6.1) in offers are chosen according to the currently preferred direction requested using setDirection() or if no change is requested the current direction of the RtpTransceiver" Regards Andy --001a1145a578ea4bee05389ebdb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    https://tools.ietf.org/html/draft-ietf-rtcweb-jse= p-15#section-5.2.4 states:

    "[RFC3264] direction attributes = (defined in Section 6.1) in offers are=C2=A0chosen according to the states = of the RtpSender and RtpReceiver of a=C2=A0given RtpTransceiver"

    I spent some time thinking about this and trying to work = out whether it worked for re-offers and my conclusion is that the above sta= tement is not strictly correct but hopefully this is not a =C2=A0big proble= m. It all depends on what the above statement means by "the states of = the RtpSender/Receiver". My understanding is that to change the direct= ion an application calls setDirection() on the transceiver before createOff= er and this would cause the direction to be set accordingly in the offer bu= t actually the RTCRtpTransceiverDirection does not change until setLocal or= setRemote is called. =C2=A0

    Would it make sense t= o change the statement in 5.2.4 to:

    "[RFC3264= ] direction attributes (defined in Section 6.1) in offers are=C2=A0chosen a= ccording to the currently preferred direction requested using setDirection(= ) or if no change is requested the current direction of the RtpTransceiver&= quot;

    Regards
    Andy
    --001a1145a578ea4bee05389ebdb4-- From nobody Wed Jul 27 07:37:03 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3F912DAD2 for ; Wed, 27 Jul 2016 07:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nO_dFyadY2Dy for ; Wed, 27 Jul 2016 07:37:01 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 BA08112DB48 for ; Wed, 27 Jul 2016 07:37:00 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id f6so50752455ith.0 for ; Wed, 27 Jul 2016 07:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=MtYg1hvwGrnfmwMwtAk6u1f4yAAxX43//TrJ8TpN4lo=; b=Z+1GJs/FOYLYGp9M5Ix6G5Db9PTY66uygUJ8kuVdq1F304wpPSGHLzHfk6/bzLTep+ yG0AwFsO3eodmwhaAAiqjCzBBO7ugG0RSmQ/eCr9/0VNngBelM3G21j+XnacnCExS9MT icCb1WeFoEDQrVw8+zAgCBWLVDErTgb7+de7gGOFxt0bGysgroMGmVmdedJIg+TB0FZo Bx7A+NToL3DvLAEHXd56nfbFkBbSK1v28cGr3BS5SBg2Vbtim4v6E9d5ZJ8P16/fL3VQ Z9t57d4fWj7/JMaQxIb2ifxp52ZW3x2ExTjoOuGlCO/51rdiChb+nsSVknTGC3TIvFxk mc0g== 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; bh=MtYg1hvwGrnfmwMwtAk6u1f4yAAxX43//TrJ8TpN4lo=; b=l8idlz+v4296rbW93W3o0LwDG8We17U+/XrMgWmjvo9JRBMifCSKj9Tg1JvldwAa3F XM39p84JnMqGI712wK+jqSjB8gcw/SlVZLodpINyoo8AxxgFXmbm7NbA7j4ad4CvakmY sqyQ6lmxGY6fF4VOc8nqjYK+rjUDiDW8AQ+66fjQenO1OFGhmSw1igLDI+q9205gMVUp 2/yips5auR6y0ZACqW1z5oE2x+qhCNpHUoiFRs8RJQbFaaSzALF5KHzX/p8CAsvQfvVk GH9A87FlXBTX6BqD/xTs428JS9K+LxXtglcN7EaRbQltsVum8A/uvOu8P6MK7+ePTEm4 dOpA== X-Gm-Message-State: AEkoouu8vqqCBsfbR6FqPZVsJKZdfXsqmnL/9mursSGW2l3KJSRqVq8W4GXREDNS7mK7qxvYCKkkg/DVVw5+/w== X-Received: by 10.36.123.72 with SMTP id q69mr35060022itc.33.1469630219863; Wed, 27 Jul 2016 07:36:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.115.134 with HTTP; Wed, 27 Jul 2016 07:36:59 -0700 (PDT) From: Andy Hutton Date: Wed, 27 Jul 2016 15:36:59 +0100 Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=001a1145a57834ce5b05389ef3b7 Archived-At: Subject: [rtcweb] Codecs in re-offer [PR #269] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jul 2016 14:37:02 -0000 --001a1145a57834ce5b05389ef3b7 Content-Type: text/plain; charset=UTF-8 The issue of whether a re-offer in WebRTC must be limited to the set of codec's within the previously negotiated envelope was discussed during IETF96 but I don't think a conclusion was reached. Justin mentioned that this had been discussed previously so sorry for bringing it up again I cannot remember all the old arguments and a quick search did not find that discussion. Personally I don't get the argument for making this a restriction in WebRTC even if there are potential workaround solutions like creating a new PC. As was mentioned in the meeting there are ways around the toggling of codec's depending on who creates the next offer without imposing a restriction which is likely to be a cause of interoperability issues. At a minimum I would suggest that WebRTC implementations must be able to receive and process and offer/answer which is not within the previously negotiated envelop and that should be stated something in JSEP. However I think it would also be preferable if the re-offer could contain the full set of capabilities. Regards Andy --001a1145a57834ce5b05389ef3b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    The issue of whether a re-offer in WebRTC must be= limited to the set of codec's within the previously negotiated envelop= e was discussed during IETF96 but I don't think a conclusion was reache= d.

    Justin mentioned that this had been discussed p= reviously so sorry for bringing it up again I cannot remember all the old a= rguments and a quick search did not find that discussion.

    Personally I don't get the argument for making this a restricti= on in WebRTC even if there are potential workaround solutions like creating= a new PC. As was mentioned in the meeting there are ways around the toggli= ng of codec's depending on who creates the next offer without imposing = a restriction which is likely to be a cause of interoperability issues.=C2= =A0

    At a minimum I would suggest that WebRTC imple= mentations must be able to receive and process and offer/answer which is no= t within the previously negotiated envelop and that should be stated someth= ing in JSEP.=C2=A0 However I think it would also be preferable if the re-of= fer could contain the full set of capabilities.

    Re= gards
    Andy
    --001a1145a57834ce5b05389ef3b7-- From nobody Wed Jul 27 08:16:04 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C077412DB17 for ; Wed, 27 Jul 2016 08:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KrvBcXN2SQMz for ; Wed, 27 Jul 2016 08:16:02 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::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 1445412DBE1 for ; Wed, 27 Jul 2016 08:16:02 -0700 (PDT) Received: by mail-pa0-x236.google.com with SMTP id pp5so11310883pac.3 for ; Wed, 27 Jul 2016 08:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SsZMTzXSk3dmHBHqLq6sca1B3tRKbhcEMwQI729RTH4=; b=qug6XJi0TWIDsG5CIKpDuCSzd7+6IFmssvkkXj2XMYh8IB89qOE7ZwRM0BZqZINtv7 w+A8wQBWYn5AWGTHVfyAGCVOaIG0q++R0hLg1029KJOv50rkSaOMon4WVD0gs4XuPaow 4gpKarIzM+9WjqVOUaC8y92SPDio36ZZSDFQHg9IHhjBRA1JKRUa9dLpFwa2/8D+I7+S jCWknmHk7FbPr3JyFGqrq0mkTUitVFhqBpzg86lIT+4WZSSAAjeFTZhRIJjseJAXjMGK ZvvEKWrcA3nZ9kDVJOTnbMnBiux9S15k3S6VjbgdhkLWwJ5uWSqeQ/iLDsMorbSf4FUF Fwlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SsZMTzXSk3dmHBHqLq6sca1B3tRKbhcEMwQI729RTH4=; b=EonsWp7f/YYvhhqMEPsXcoTMSpo5vRV0xZcqKc+r/Ibe+5KXZocySfEH3vVv5JF7ej k4TD5Jra04b9ZLb1bIF3F9XuCKi489ud0A//pmz4wZ3T0fRvO/qQP8Ddpi0tXIH3MUj1 +TXbog0+Umi3RktTnVJkvN0ZIsBZsvpNdJvGg49QCIcKhYgnvJQQDT7qpXqXMn3wWq34 2nuEyV4++3MwoAT6b1oi27YluNmO8mGAa71j/GAy5dgdiOdHc4L7wAHQjkLnhHTqPiDL 20wf6YIMW0O+XKq36Rzo9mduPjKS2qHW6DcK3EtJ8hUgE/e/XiLfEDix3DVu+58CTUnF zezA== X-Gm-Message-State: AEkoouvz1Ha7tjmPES7mcAGcfwl3hXQRsGiLdJnmST7/bxN/1xN4QN5EckIR0WMcv6ml2Q== X-Received: by 10.66.199.72 with SMTP id ji8mr50357162pac.52.1469632561425; Wed, 27 Jul 2016 08:16:01 -0700 (PDT) Received: from [10.212.52.251] (mobile-166-176-187-33.mycingular.net. [166.176.187.33]) by smtp.gmail.com with ESMTPSA id e68sm10149489pfk.1.2016.07.27.08.15.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Jul 2016 08:16:00 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E6C884CB-3841-4850-9717-DB7F0C0FD30F Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13G34) In-Reply-To: Date: Wed, 27 Jul 2016 08:15:58 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Andy Hutton Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP Direction in offers. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jul 2016 15:16:04 -0000 --Apple-Mail-E6C884CB-3841-4850-9717-DB7F0C0FD30F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable This text needs to be revised to reflect the operation of the setDirection A= PI. In particular, neither RtpReceiver nor RtpSender have a state attribute a= s referred to in this text. See the slides from the last WebRTC WG virtual interim (starting at slide 19= ): https://www.w3.org/2011/04/webrtc/wiki/images/1/12/WebRTCWG-2016-06-28.pdf > On Jul 27, 2016, at 7:22 AM, Andy Hutton wrote= : >=20 >=20 > https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-15#section-5.2.4 states= : >=20 > "[RFC3264] direction attributes (defined in Section 6.1) in offers are cho= sen according to the states of the RtpSender and RtpReceiver of a given RtpT= ransceiver" >=20 > I spent some time thinking about this and trying to work out whether it wo= rked for re-offers and my conclusion is that the above statement is not stri= ctly correct but hopefully this is not a big problem. It all depends on wha= t the above statement means by "the states of the RtpSender/Receiver". My un= derstanding is that to change the direction an application calls setDirectio= n() on the transceiver before createOffer and this would cause the direction= to be set accordingly in the offer but actually the RTCRtpTransceiverDirect= ion does not change until setLocal or setRemote is called. =20 >=20 > Would it make sense to change the statement in 5.2.4 to: >=20 > "[RFC3264] direction attributes (defined in Section 6.1) in offers are cho= sen according to the currently preferred direction requested using setDirect= ion() or if no change is requested the current direction of the RtpTransceiv= er" >=20 > Regards > Andy > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-E6C884CB-3841-4850-9717-DB7F0C0FD30F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    This text needs to be revis= ed to reflect the operation of the setDirection API. In particular, neither R= tpReceiver nor RtpSender have a state attribute as referred to in this text.=

    See the slides from the last WebRTC WG virtual int= erim (starting at slide 19):

    On Jul 27= , 2016, at 7:22 AM, Andy Hutton <andyhutton.ietf@gmail.com> wrote:


    https://tools.ietf.org/html/draft-ietf-= rtcweb-jsep-15#section-5.2.4 states:

    "[RFC3264] direction attribu= tes (defined in Section 6.1) in offers are chosen according to the stat= es of the RtpSender and RtpReceiver of a given RtpTransceiver"
    =
    I spent some time thinking about this and trying to work out w= hether it worked for re-offers and my conclusion is that the above statement= is not strictly correct but hopefully this is not a  big problem. It a= ll depends on what the above statement means by "the states of the RtpSender= /Receiver". My understanding is that to change the direction an application c= alls setDirection() on the transceiver before createOffer and this would cau= se the direction to be set accordingly in the offer but actually the RTCRtpT= ransceiverDirection does not change until setLocal or setRemote is called. &= nbsp;

    Would it make sense to change the statement i= n 5.2.4 to:

    "[RFC3264] direction attributes (define= d in Section 6.1) in offers are chosen according to the currently prefe= rred direction requested using setDirection() or if no change is requested t= he current direction of the RtpTransceiver"

    Reg= ards
    Andy
    ____________________= ___________________________
    rtcweb mailing list
    rtcweb@ietf.org
    <= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
    = --Apple-Mail-E6C884CB-3841-4850-9717-DB7F0C0FD30F-- From nobody Wed Jul 27 09:00:48 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CD312D600 for ; Wed, 27 Jul 2016 09:00:47 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 PAmE61JZ44av for ; Wed, 27 Jul 2016 09:00:45 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 714CA12D5C7 for ; Wed, 27 Jul 2016 09:00:45 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id j124so54210463ith.1 for ; Wed, 27 Jul 2016 09:00:45 -0700 (PDT) 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:from:date:message-id:subject:to :cc; bh=Q3r0oI4mv4QM1SvIA8VKYbbY1bWxz9odY/4QmTPdx70=; b=dS0QjpXsJWQQu3Q+3xn4AA9C3NSCW77uZhDCFMg0DN+U7krS/+/7FkwWOjgUybXIUs vH48+kNJAO1NMrw+PLOYwy58DZfc+NYF+Kq6AZd6oLY2ACiGkC7CYM0CcmZFwZ2CFysX laYYwYR+TGq8kyHFWP9J8wIdOjYTPDSceEM8Q8ENZoQienSo+wSFgrgBLQTrqPxSEWq+ vQgWcvLH5dqbSfDKt/FmJk6GedMIxSamYOwjcM58L99i/KcJ3mnFuje2zUp44ZQAnjRA VsXZqBFsLZZMwy9dBieID7WUMPWbbXdgU8EKPpvhUP6Cs2ajLajLAOq44P7QtQBfddpE CiDw== 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=Q3r0oI4mv4QM1SvIA8VKYbbY1bWxz9odY/4QmTPdx70=; b=a2S0xsmKonv/nyXGIsdh+Xr2qIGuQmcx/1gJEFgzPb5y8/ssXOpKLep8aeVuplagKB KnVdQqclffjK0JQr7SR2QkUCKokwMmPjQWjRfVsMpM1wxWO+1a3r7S7DRr0BA7pAjT/6 DsgwCXR2hX7ZCfomfqA9gZkuL2WvJOdMBOBhhhFRy7hTG/ZF65JW/HLlc5GyQqE+5vOP SpbaWdgovVOKyJnC5xqx3Hks0s3pFUyveDj9fHNiHD/l6rZZyby3M3MGWR3tmjFeUfFV Z4W96Cwdz+BR8ZeGN2ZCuKjfzfed1b9NU+wla2Pj9OVISASIY4Ke/HVUJhIf3Qf2IRg+ kGeQ== X-Gm-Message-State: AEkoousc40eKtmxZS3m1LEmwlmICC7nYw77ZQL6XzejVVcpmlbiDOKvOvd38GVJ7NzK99w== X-Received: by 10.36.43.131 with SMTP id h125mr33908697ita.89.1469635231951; Wed, 27 Jul 2016 09:00:31 -0700 (PDT) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com. [209.85.223.172]) by smtp.gmail.com with ESMTPSA id b89sm3035494iod.30.2016.07.27.09.00.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jul 2016 09:00:30 -0700 (PDT) Received: by mail-io0-f172.google.com with SMTP id 38so74403311iol.0 for ; Wed, 27 Jul 2016 09:00:30 -0700 (PDT) X-Received: by 10.107.130.39 with SMTP id e39mr32241389iod.66.1469635229747; Wed, 27 Jul 2016 09:00:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.62.139 with HTTP; Wed, 27 Jul 2016 09:00:29 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Wed, 27 Jul 2016 12:00:29 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Andy Hutton Content-Type: multipart/alternative; boundary=001a113ec7ecd1c6120538a01dc1 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codecs in re-offer [PR #269] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jul 2016 16:00:47 -0000 --001a113ec7ecd1c6120538a01dc1 Content-Type: text/plain; charset=UTF-8 I agree that re-offer should contain the full set of codecs or this will cause interesting problems with 3pcc or SIP interop. The order of codecs should ideally be the same as currently negotiated to avoid codec flips. Essentially, what this means all supported codecs not currently negotiated should be added to the end of the offer after the currently negotiated ones. Regards, _____________ Roman Shpount On Wed, Jul 27, 2016 at 10:36 AM, Andy Hutton wrote: > > The issue of whether a re-offer in WebRTC must be limited to the set of > codec's within the previously negotiated envelope was discussed during > IETF96 but I don't think a conclusion was reached. > > Justin mentioned that this had been discussed previously so sorry for > bringing it up again I cannot remember all the old arguments and a quick > search did not find that discussion. > > Personally I don't get the argument for making this a restriction in > WebRTC even if there are potential workaround solutions like creating a new > PC. As was mentioned in the meeting there are ways around the toggling of > codec's depending on who creates the next offer without imposing a > restriction which is likely to be a cause of interoperability issues. > > At a minimum I would suggest that WebRTC implementations must be able to > receive and process and offer/answer which is not within the previously > negotiated envelop and that should be stated something in JSEP. However I > think it would also be preferable if the re-offer could contain the full > set of capabilities. > > Regards > Andy > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a113ec7ecd1c6120538a01dc1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I agree that re-offer should contain the full set of codec= s or this will cause interesting problems with 3pcc or SIP interop. The ord= er of codecs should ideally be the same as currently negotiated to avoid co= dec flips. Essentially, what this means all supported codecs not currently = negotiated should be added to the end of the offer after the currently nego= tiated ones.

    Regards,

    _____________
    Roman Shpount

    On Wed, Jul 27, 2016 at 10:36 AM, Andy Hutto= n <andyhutton.ietf@gmail.com> wrote:

    The issue of whether a re-offe= r in WebRTC must be limited to the set of codec's within the previously= negotiated envelope was discussed during IETF96 but I don't think a co= nclusion was reached.

    Justin mentioned that this h= ad been discussed previously so sorry for bringing it up again I cannot rem= ember all the old arguments and a quick search did not find that discussion= .

    Personally I don't get the argument for maki= ng this a restriction in WebRTC even if there are potential workaround solu= tions like creating a new PC. As was mentioned in the meeting there are way= s around the toggling of codec's depending on who creates the next offe= r without imposing a restriction which is likely to be a cause of interoper= ability issues.=C2=A0

    At a minimum I would suggest= that WebRTC implementations must be able to receive and process and offer/= answer which is not within the previously negotiated envelop and that shoul= d be stated something in JSEP.=C2=A0 However I think it would also be prefe= rable if the re-offer could contain the full set of capabilities.

    Regards
    Andy

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


    --001a113ec7ecd1c6120538a01dc1-- From nobody Thu Jul 28 03:44:52 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2973312DE34 for ; Thu, 28 Jul 2016 03:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vBB-T8Tf0VcN for ; Thu, 28 Jul 2016 03:44:43 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 9923212E1A9 for ; Thu, 28 Jul 2016 03:44:40 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id u186so164834340ita.0 for ; Thu, 28 Jul 2016 03:44:40 -0700 (PDT) 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=VTch0dInip5FHVHkHE6VX44Qbmw2nDNTWVX2KQaXE4M=; b=iMlcTH7+uKN7i4oz45imW1X3B0YLLvhrQNxcLs33psF8OP9TSVnfW66nI5iUK3yKrG 1J5PKdwT68G+XGHJ2oRUFnIFUcrX4qDxp+drJUiVGEVLVTmu21APiM3hSXzCu9lAoRGv Tsv5Ys7QQU06KhTa1fyoyOMFXYVQF93tCreQoItTvWTjjrm76962CZna4iCka8+67/KS aP3i5wpuBugGSYZ+O7v9as5GFCxnS6jFVoR6eGR7RtmX8G/JszsNQNs0CMeH2LHOvKZo BfhN5qimZThe8ylKtvee14V7z4MYY+5prkn7q08fOC+9HzVYBQrzAnB7UsXr8s7G4SA+ L+ug== 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=VTch0dInip5FHVHkHE6VX44Qbmw2nDNTWVX2KQaXE4M=; b=bB4PwHAcpvmiudGVBL88OjHAmiiFYbHcjHY9MjA0nn/XodGuxA2NMetJJjF7qt36Ib cDFwEc/bP8IiWkZsYoPsJzzEhhdiACX64I/2Vvo3DlcDAKEHtwE9l5EYf8Q12S/nAikV ihfTD4zdXSU5IJcTA1rjfaxrpnJk+RyU7/UDfZcbH5mbO2o6U96PozaPochKQcARjP0K TI7VNHIj/fhZ2hxavpHlzLfiG6Z+2zGKxRVetbYSN25iodB8xdjEGoH2Oxx8a1alHCq2 ioeWqHn+aSDm2nrbYuRVe4juPw3MfXYBh8FVV4KR8Gctgr0WQkA7AOjKToUlJ8/MjyEB Zh2Q== X-Gm-Message-State: ALyK8tJ8xR7722vRffE2MxCD2qoZjc+LksqqWK+eIGeWHyVPDKZPcIeKw84atTy6vuhSuLtcicJFIPx/jLNXWQ== X-Received: by 10.36.19.16 with SMTP id 16mr109334849itz.41.1469702679966; Thu, 28 Jul 2016 03:44:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.115.134 with HTTP; Thu, 28 Jul 2016 03:44:39 -0700 (PDT) In-Reply-To: References: From: Andy Hutton Date: Thu, 28 Jul 2016 11:44:39 +0100 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=001a1140591a2a4e370538afd2e3 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codecs in re-offer [PR #269] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jul 2016 10:44:50 -0000 --001a1140591a2a4e370538afd2e3 Content-Type: text/plain; charset=UTF-8 I found the original discussion which mainly occurred in GitHub at https://github.com/rtcweb-wg/jsep/issues/266 but I could not find any conclusion to this on the mailing list. IMHO we have got this wrong and need to think again the default case should be that an offer contains the full set of capabilities not what was previously negotiated. In the GitHUB #266 discussion a use case is mentioned in which the application (SFU) wants to initiate a new offer/answer because something changed such as a new party joining a conference. In this scenario it may be that the applications wants the endpoint and not the SFU to generate the offer because it wants the full set of capabilities to be re-negotiated, this is common in existing SIP scenarios. The default behavior in JSEP should be for the offer to contain the full set of capabilities of the endpoint. Regards Andy On Wed, Jul 27, 2016 at 5:00 PM, Roman Shpount wrote: > > I agree that re-offer should contain the full set of codecs or this will cause interesting problems with 3pcc or SIP interop. The order of codecs should ideally be the same as currently negotiated to avoid codec flips. Essentially, what this means all supported codecs not currently negotiated should be added to the end of the offer after the currently negotiated ones. > > Regards, > > _____________ > Roman Shpount > > On Wed, Jul 27, 2016 at 10:36 AM, Andy Hutton wrote: >> >> >> The issue of whether a re-offer in WebRTC must be limited to the set of codec's within the previously negotiated envelope was discussed during IETF96 but I don't think a conclusion was reached. >> >> Justin mentioned that this had been discussed previously so sorry for bringing it up again I cannot remember all the old arguments and a quick search did not find that discussion. >> >> Personally I don't get the argument for making this a restriction in WebRTC even if there are potential workaround solutions like creating a new PC. As was mentioned in the meeting there are ways around the toggling of codec's depending on who creates the next offer without imposing a restriction which is likely to be a cause of interoperability issues. >> >> At a minimum I would suggest that WebRTC implementations must be able to receive and process and offer/answer which is not within the previously negotiated envelop and that should be stated something in JSEP. However I think it would also be preferable if the re-offer could contain the full set of capabilities. >> >> Regards >> Andy >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > --001a1140591a2a4e370538afd2e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I found the original discussion which mainly occurred= in GitHub at=C2=A0https://github.com/rtcweb-wg/jsep/issues/266 but I could not find any = conclusion to this on the mailing list.

    IMHO we ha= ve got this wrong and need to think again the default case should be that a= n offer contains the full set of capabilities not what was previously negot= iated. In the GitHUB #266 discussion a use case is mentioned in which the a= pplication (SFU) wants to initiate a new offer/answer because something cha= nged such as a new party joining a conference.=C2=A0 In this scenario it ma= y be that the applications wants the endpoint and not the SFU to generate t= he offer because it wants the full set of capabilities to be re-negotiated,= this is common in existing SIP scenarios.

    The def= ault behavior in JSEP should be for the offer to contain the full set of ca= pabilities of the endpoint.

    Regards
    Andy=




    On Wed, Jul 27, 2016 at 5:00 PM= , Roman Shpount <roman@telurix.com<= /a>> wrote:
    >
    > I agree that re-offer should contain the ful= l set of codecs or this will cause interesting problems with 3pcc or SIP in= terop. The order of codecs should ideally be the same as currently negotiat= ed to avoid codec flips. Essentially, what this means all supported codecs = not currently negotiated should be added to the end of the offer after the = currently negotiated ones.
    >
    > Regards,
    >
    > _______= ______
    > Roman Shpount
    >
    > On Wed, Jul 27, 2016 at 10:36 = AM, Andy Hutton <    andyhutton= .ietf@gmail.com> wrote:
    >>
    >>
    >> The issu= e of whether a re-offer in WebRTC must be limited to the set of codec's= within the previously negotiated envelope was discussed during IETF96 but = I don't think a conclusion was reached.
    >>
    >> Justin = mentioned that this had been discussed previously so sorry for bringing it = up again I cannot remember all the old arguments and a quick search did not= find that discussion.
    >>
    >> Personally I don't get t= he argument for making this a restriction in WebRTC even if there are poten= tial workaround solutions like creating a new PC. As was mentioned in the m= eeting there are ways around the toggling of codec's depending on who c= reates the next offer without imposing a restriction which is likely to be = a cause of interoperability issues.
    >>
    >> At a minimum I= would suggest that WebRTC implementations must be able to receive and proc= ess and offer/answer which is not within the previously negotiated envelop = and that should be stated something in JSEP.=C2=A0 However I think it would= also be preferable if the re-offer could contain the full set of capabilit= ies.
    >>
    >> Regards
    >> Andy
    >>
    >&g= t; _______________________________________________
    >> rtcweb maili= ng list
    >> rtcweb@ietf.org<= br>>> https:= //www.ietf.org/mailman/listinfo/rtcweb
    >>
    >
    --001a1140591a2a4e370538afd2e3--