From nobody Tue Nov 1 15:34: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 A1D0E1294D6 for ; Tue, 1 Nov 2016 15:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 WX5A-GDvtNEk for ; Tue, 1 Nov 2016 15:34:12 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 476BA129416 for ; Tue, 1 Nov 2016 15:34:12 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id b35so68919474uaa.3 for ; Tue, 01 Nov 2016 15:34:12 -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=XKSSK1W63qVR5HEqcs2KhgfIZTcsiUV4E5I27ty8Xdw=; b=GJH4S0/00eJpzdSxrMMhFxeMuvyA/WmGtFwDlylKFgkW2lnbHZMxpjvSE2mMpBtF2b nNuK7UwUc+22+eQlsb4IDspT2o4ejv1rdBgEShFf/TReJ6FPcEZ2Bo1XN7lq84hZyKnK 4JRXQZ3trL7D3nVMOFhYgh5fQYyBpEUkr9c+MGRROyxHlGLJh7DHoc1hebjGx9H1l6P6 VLt8frvBoZSnrBrc1merJbmVVj73DaS9k1cqRjj13x9YH9XHhHpKdssANDYurYZkSHV9 1tre8yHTYkIYxi5LbmkX5hL5eglK0FAJf80nnFptEoS2Rtf9bWWnXiF1biaDH/m9P9rU lJIQ== 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=XKSSK1W63qVR5HEqcs2KhgfIZTcsiUV4E5I27ty8Xdw=; b=K2A6rvSrpVlER18lykMTBG94EHNhHHWZVOYljoVkiyjbrSdZOe94l/YAN1erUxayMj p4J9oMKCm86OV/dqhzbnNSZckHubtk0DKiCbS9KZM7yR+zyPLOMMbEkL5ZLRiFjmNgNf LL2b2Pdhwh0ejKzaBnt4u5DdlKF9EwXTmIWYmll06+18gxL5PwePYWgd/0enlWCg5uo/ 0sWGXxYYXmSKTRLQnkqe6KxMiUfJMBacAwnL91YOcGnERiineMbGzIOuNR7q4RGBH6XT /Iz6OzGa0vjupXB79KAba9RNczbsKyjpzKV3sMGSBEk12WAP2296laatQCyGnb1ECaaZ BLpA== X-Gm-Message-State: ABUngvf5nk2/R1EZHX/7R9GtEUPzogFX7jgtoZ2FRzJ+sMxeaSYiXrNW0+cydffRvdWL7v3bO+y2j7L9Ij6rpg== X-Received: by 10.176.3.84 with SMTP id 78mr243375uat.117.1478039650988; Tue, 01 Nov 2016 15:34:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Tue, 1 Nov 2016 15:33:50 -0700 (PDT) From: Bernard Aboba Date: Tue, 1 Nov 2016 15:33:50 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a113f03265c899b054044ec41 Archived-At: Subject: [rtcweb] JSEP Section 5.3.1: Effect of setLocal/setRemote on transceiver.direction 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, 01 Nov 2016 22:34:13 -0000 --001a113f03265c899b054044ec41 Content-Type: text/plain; charset=UTF-8 JSEP Section 5.3.1 says: o A direction attribute, determined by applying the rules regarding the offered direction specified in [RFC3264], Section 6.1 , and then intersecting with the direction of the associated RtpTransceiver. For example, in the case where an m= section is offered as "sendonly", and the local transceiver is set to "sendrecv", the result in the answer is a "recvonly" direction. [BA] Overall, this raises the question whether setLocal/setRemoteDescription can change the value of transceiver.direction to something other than what was set in transceiver.setDirection(), and if so, whether the change is persistent. For example: transceiver.setDirection("sendrecv"); // ... pc.setRemoteDescription(sendOnlyOffer).then( // Is transceiver.direction now "recvonly"? ) pc.createOffer().then{ // Does the offer created indicate "sendrecv" or "recvonly"? } A similar question was raised on the W3C WEBRTC WG list by Taylor: https://lists.w3.org/Archives/Public/public-webrtc/2016Nov/0009.html --001a113f03265c899b054044ec41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
JSEP Section 5.3.1 says:

   o  A direction attribute, determined by app=
lying the rules regarding
      the offered direction specified in [RFC3264], Section=C2=A06.1, and
      then intersecting with the direction of the associated
      RtpTransceiver.  For example, in the case where an m=3D section is
      offered as "sendonly", and the local transceiver is set to
      "sendrecv", the result in the answer is a "recvonly&qu=
ot; direction.

[BA] Overall= , this raises the question whether setLocal/setRemoteDescription can change= the
value of transceiver.direction to something other than what = was set in transceiver.setDirection(),
and if so, whether the cha= nge is persistent.=C2=A0

For example:

transceiver.setDirection("sendrecv");

= // ...

= pc.setRemoteDescription(sendOnlyOffer).then(

= // Is transceiver.direction now "recvonly"?=C2=A0

)


pc.createOffer().then{

= // Does the offer created indicate "sendrecv" or "recvonly&q= uot;?

}


A similar ques= tion was raised on the W3C WEBRTC WG list by Taylor:
--001a113f03265c899b054044ec41-- From nobody Wed Nov 2 05:55: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 5D9421295BB for ; Wed, 2 Nov 2016 05:55:39 -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 3rvF3wMXFxo2 for ; Wed, 2 Nov 2016 05:55:37 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 0E530129400 for ; Wed, 2 Nov 2016 05:55:36 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-01-5819e246da43 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 79.23.03250.642E9185; Wed, 2 Nov 2016 13:55:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0319.002; Wed, 2 Nov 2016 13:54:11 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: JSEP WGLC: Christer's comments on section 3 - Part I Thread-Index: AQHSME3t8FqpE1oRDUKtzBZVQ19PUg== Date: Wed, 2 Nov 2016 12:54:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7uq77I8kIg3Mr2CzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuZft1kLlilVPF/wlrmB8ZRUFyMnh4SAicTTScfYuxi5OIQE 1jFKrH3xkwXCWcwocW31SrYuRg4ONgELie5/2iANIgLqEpcfXmAHsYUFbCVa/rxihYg7Scxq XAdl60ns6utmA7FZBFQk9r5tYAaxeQWsJR5PPc0CYjMKiEl8P7WGCcRmFhCXuPVkPhPEQQIS S/acZ4awRSVePv7HCnKCKNDMNffDIMJKEj82XGKBaNWTuDF1ChuEbS2xePJHVghbW2LZwtdQ awUlTs58wjKBUWQWkm2zkLTPQtI+C0n7LCTtCxhZVzGKFqcWJ+WmGxnppRZlJhcX5+fp5aWW bGIERsTBLb8NdjC+fO54iFGAg1GJh/fDWokIIdbEsuLK3EOMEhzMSiK8L+9LRgjxpiRWVqUW 5ccXleakFh9ilOZgURLnNVt5P1xIID2xJDU7NbUgtQgmy8TBKdXAOOOuk/3X+LwpNqvubVqS 1ZgT995q3vYPpR4aPDc9nTy5/R8W73b0cjcNeVK2x23zrj2vp2n+nf5BwfXjLnOJt3m1e+4/ SIsPePTlWqfpQ8UJTIZTr9tetzy+e3VW2+Rll5cK/JmbninLPWPG92n7A84rq5i7BOhOWRrX +CRQ9e0aydkMDMwMb5RYijMSDbWYi4oTAc7Z7gCEAgAA Archived-At: Subject: [rtcweb] JSEP WGLC: Christer's comments on section 3 - Part I 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, 02 Nov 2016 12:55:39 -0000 Hi, Some initial comments on Section 3. I will comment on the forking stuff in a separate e-mail. --- Section 3.2 says: "the DTLS-SRTP parameters [RFC5763] sent to a remote party indicate what certificate the local side will use in DTLS setup" 1) I am not sure what "parameters" the text is referring to. If it=B9s the fingerprint, I think the text should reference RFC 4572. 2) I think we should simply have a generic statement that, following the rules in RFC3264, parameters indicate receiving capabilities - unless explicitly indicated otherwise. --- Section 3.2 says: "JSEP also allows for an answer to be treated as provisional by the application. Provisional answers provide a way for an answerer to communicate initial session parameters back to the offerer, in order to allow the session to begin, while allowing a final answer to be specified later. This concept of a final answer is important to the offer/answer model; when such an answer is received, any extra resources allocated by the caller can be released, now that the exact session configuration is known." 1) I would like explicit text saying that this is a deviation from RFC 3264, where there is no such thing as a provisional answer. I would like to have a dedicated =B3Deviations to RFC3264=B2 (or something similar) sect= ion. 2) I would like explicit text saying that the final answer may be completely different (in terms of candidates, codecs, accepted m- line etc) from the provisional answer. 3) Related to 2), the final answer may also require NEW resources to be allocated. --- Section 3.2 says: "To support this, the JSEP media layer can provide an offer via the createOffer() method whenever the Javascript application needs one for the signaling. The answerer can send back zero or more provisional answers, and finally end the offer-answer exchange by sending a final answer. The state machine for this is as follows:" 1) I would like to explicitly note that the generated offer is not applied (and any previously applied offer is not removed) until setLocalDescription() is called. --- Section 3.3 says: "In the WebRTC specification, session descriptions are formatted as SDP messages." 1) To me it is unclear what an =B3SDP message=B2 is, so I suggest we say = =B3SDP syntax=B2, as we also do later in the section. ---- Section 3.4 says: "In order to give the application control over various common session parameters, JSEP provides control surfaces which tell the browser how to generate session descriptions.=B2 1) What is =B3control surface=B2? Are you talking about the interface in Section 4? ---- Section 3.4.1 talks about =B3RtpTranceivers=B2, =B3RtpSenders=B2 and =B3RtpReceivers=B2. 1) I think they should be introduced in their own section (not within the Session Description Protocol section). 2) I think it should be explained what an RtpXXX really is. At a minimum there should be a reference to the appropriate W3C document. But, as there is text on how they related to SDP m- lines etc, 1 or 2 sentences describing what they are would also be useful. --- Section 3.5.2.1 says: "The m=3D line can be identified in one of two ways; either by a m=3D l= ine index, or a MID. The m=3D line index is a zero-based index, with index N referring to the N+1th m=3D line in the SDP sent by the entity which sent the IceCandidate. The MID uses the "media stream identification" attribute, as defined in [RFC5888], Section 4, to identify the m=3D line." 1) Where is the m=3D line index located? 2) Where is the MID attribute located? Earlier in the section the text says that the candidate lines are the ONLY information within the IceCandidiate object. 3) I have some trouble to parse "the SDP sent by the entity which sent the IceCandidate". What entity? --- Section 3.5.3 contains requirements regarding what a browser MUST do - e.g., allowing the application to select what types of ICE candidates are used. 1) I am not sure why such requirements are listed here. But, in any case, is there a mechanism for applications for selecting candidate types etc? If so, what mechanism? Regards, Christer From nobody Wed Nov 2 10:44: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 01FCA129579 for ; Wed, 2 Nov 2016 10:43:57 -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 joXNOVAZsUcZ for ; Wed, 2 Nov 2016 10:43:55 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36D112964E for ; Wed, 2 Nov 2016 10:43:54 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id c47so13453854qtc.2 for ; Wed, 02 Nov 2016 10:43:54 -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=0vVozsgakqYDJFip4t66TaNYbMU+BaHHxx4G2f8HjtE=; b=LCwCAAZmqA+3AppxLe1zTJStL4Ot3wtkj95Or10ibHlCTOiYuDY2hqyPc1FlrWLS0N EZBU9FDvHBCXD+0DBYOfb7x8J1Ns3IjOGJRXtS0YEwkScg3dD3vQ6rXFACkGrxiXckaL fe/spwFj2cajuebm+GVs1aNvSA76nQYsHMhYwGVdUYzxfa+4apsgqCtOgmKY9ymxNqWx jZKb4PsT4M1DIiaIIKn91QSnqofZ9H9QhXwo57SusBu+6/k5E5g7fVsBmUkTBKTChQe2 MRgh2v8mIvuwdkzFlr7RZjGM+GaMQV5SYMdhaAMFDhsAkb3+T1GWSu++0d5S9BkP147u Qcfw== 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=0vVozsgakqYDJFip4t66TaNYbMU+BaHHxx4G2f8HjtE=; b=ABJ6VBwa1KsWd7XXvRbe3rtVtRCEYDC1lYn6czc0UoTaoXzO0oIVvqx66ujjGvGJax mbgEeQHowqqgVU+iEZk9DeKyBXY94evVlVlV9q8Sksqg06W4N+7mQrQIcl9fsdovOMZv tXrFd5SVv08DFqcw25/9rmtcWfT7Bz8EeNQiahXPjHy1sd9lc8K3cgnVJLgEdkvJEQWS hu0dQBSfMsavYB+Q69ZuUN+VcYp51UUKzBF9I28ngtcKr/zRJ+/AKLcwxfAU44BRZd5U AnBIaVq9GJ0wGiS+ceQBU3MV6dK2RajAKrnZoqJrnVKl90rbg75RS+TCNprAXRta10nV /SLg== X-Gm-Message-State: ABUngvdpXbUAq0KXdsB+c7LhDBnjiNsiTsFIHL9k7KfQBsrbda8v1ybcP5UrvNWAoftCxaAAGuseNkzdscUsRg== X-Received: by 10.237.39.37 with SMTP id n34mr2824214qtd.128.1478108633619; Wed, 02 Nov 2016 10:43:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.140.8 with HTTP; Wed, 2 Nov 2016 10:43:23 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Wed, 2 Nov 2016 10:43:23 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c06c9d40c3a88054054fc72 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP WGLC: Christer's comments on section 3 - Part I 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, 02 Nov 2016 17:43:57 -0000 --94eb2c06c9d40c3a88054054fc72 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the review, Christer. I've broken these up into issues #373 through #379 in the github repo, so we can track them there. regards, Ted On Wed, Nov 2, 2016 at 5:54 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > Some initial comments on Section 3. I will comment on the forking stuff i= n > a separate e-mail. > > > --- > > Section 3.2 says: > > "the DTLS-SRTP parameters [RFC5763] sent to a remote party indicate wh= at > certificate the local side will use in DTLS setup" > > 1) I am not sure what "parameters" the text is referring to. If it=C2=B9s= the > fingerprint, I think the text should reference RFC 4572. > > 2) I think we should simply have a generic statement that, following the > rules in RFC3264, parameters indicate receiving capabilities - unless > explicitly indicated otherwise. > > --- > > Section 3.2 says: > > "JSEP also allows for an answer to be treated as provisional by the > application. Provisional answers provide a way for an answerer to > communicate initial session parameters back to the offerer, in order > to allow the session to begin, while allowing a final answer to be > specified later. This concept of a final answer is important to the > offer/answer model; when such an answer is received, any extra > resources allocated by the caller can be released, now that the exact > session configuration is known." > > 1) I would like explicit text saying that this is a deviation from RFC > 3264, where there is no such thing as a provisional answer. I would like > to have a dedicated =C2=B3Deviations to RFC3264=C2=B2 (or something simil= ar) section. > > 2) I would like explicit text saying that the final answer may be > completely different (in terms of candidates, codecs, accepted m- line > etc) from the provisional answer. > > 3) Related to 2), the final answer may also require NEW resources to be > allocated. > > --- > > Section 3.2 says: > > "To support this, the JSEP media layer > can provide an offer via the createOffer() method whenever the > Javascript application needs one for the signaling. The answerer ca= n > send back zero or more provisional answers, and finally end the > offer-answer exchange by sending a final answer. The state machine > for this is as follows:" > > 1) I would like to explicitly note that the generated offer is not applie= d > (and any previously applied offer is not removed) until > setLocalDescription() is called. > > --- > > Section 3.3 says: > > "In the WebRTC specification, session descriptions are formatted as > SDP messages." > > > 1) To me it is unclear what an =C2=B3SDP message=C2=B2 is, so I suggest w= e say =C2=B3SDP > syntax=C2=B2, as we also do later in the section. > > ---- > > Section 3.4 says: > > "In order to give the application control over various common sessio= n > parameters, JSEP provides control surfaces which tell the browser h= ow > to generate session descriptions.=C2=B2 > > > 1) What is =C2=B3control surface=C2=B2? Are you talking about the interfa= ce in > Section 4? > > ---- > > Section 3.4.1 talks about =C2=B3RtpTranceivers=C2=B2, =C2=B3RtpSenders=C2= =B2 and > =C2=B3RtpReceivers=C2=B2. > > 1) I think they should be introduced in their own section (not within the > Session Description Protocol section). > > 2) I think it should be explained what an RtpXXX really is. At a minimum > there should be a reference to the appropriate W3C document. But, as ther= e > is text on how they related to SDP m- lines etc, 1 or 2 sentences > describing what they are would also be useful. > > --- > > Section 3.5.2.1 says: > > "The m=3D line can be identified in one of two ways; either by a m=3D= line > index, or a MID. The m=3D line > index is a zero-based index, with index N referring to the N+1th m= =3D > line in the SDP sent by the entity > which sent the IceCandidate. The MID uses the "media stream > identification" attribute, as defined in > [RFC5888], Section 4, to identify the m=3D line." > > > 1) Where is the m=3D line index located? > > 2) Where is the MID attribute located? Earlier in the section the text > says that the candidate lines are the ONLY > information within the IceCandidiate object. > > 3) I have some trouble to parse "the SDP sent by the entity which sent th= e > IceCandidate". What entity? > > --- > > Section 3.5.3 contains requirements regarding what a browser MUST do - > e.g., allowing the application to select what types of ICE candidates are > used. > > 1) I am not sure why such requirements are listed here. But, in any case, > is there a mechanism for applications for selecting candidate types etc? > If so, what mechanism? > > > Regards, > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --94eb2c06c9d40c3a88054054fc72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the review, Christer.=C2=A0 I've = broken these up into issues #373 through #379 in the github repo, so we can= track them there.

regards,

Ted

On Wed, Nov 2, 2016 at 5:= 54 AM, Christer Holmberg <christer.holmberg@ericsson.com&= gt; wrote:

Hi,

Some initial comments on Section 3. I will comment on the forking stuff in<= br> a separate e-mail.


---

Section 3.2 says:

=C2=A0 =C2=A0"the DTLS-SRTP parameters [RFC5763] sent to a remote part= y indicate what
=C2=A0 =C2=A0certificate the local side will use in DTLS setup"

1) I am not sure what "parameters" the text is referring to. If i= t=C2=B9s the
fingerprint, I think the text should reference RFC 4572.

2) I think we should simply have a generic statement that, following the rules in RFC3264, parameters indicate receiving capabilities - unless
explicitly indicated otherwise.

---

Section 3.2 says:

=C2=A0 =C2=A0"JSEP also allows for an answer to be treated as provisio= nal by the
=C2=A0 =C2=A0 application.=C2=A0 Provisional answers provide a way for an a= nswerer to
=C2=A0 =C2=A0 communicate initial session parameters back to the offerer, i= n order
=C2=A0 =C2=A0 to allow the session to begin, while allowing a final answer = to be
=C2=A0 =C2=A0 specified later. This concept of a final answer is important = to the
=C2=A0 =C2=A0 offer/answer model; when such an answer is received, any extr= a
=C2=A0 =C2=A0 resources allocated by the caller can be released, now that t= he exact
=C2=A0 =C2=A0 session configuration is known."

1) I would like explicit text saying that this is a deviation from RFC
3264, where there is no such thing as a provisional answer. I would like to have a dedicated =C2=B3Deviations to RFC3264=C2=B2 (or something similar= ) section.

2) I would like explicit text saying that the final answer may be
completely different (in terms of candidates, codecs, accepted m- line
etc) from the provisional answer.

3) Related to 2), the final answer may also require NEW resources to be
allocated.

---

Section 3.2 says:

=C2=A0 =C2=A0 "To support this, the JSEP media layer
=C2=A0 =C2=A0 =C2=A0can provide an offer via the createOffer() method whene= ver the
=C2=A0 =C2=A0 =C2=A0Javascript application needs one for the signaling.=C2= =A0 The answerer can
=C2=A0 =C2=A0 =C2=A0send back zero or more provisional answers, and finally= end the
=C2=A0 =C2=A0 =C2=A0offer-answer exchange by sending a final answer.=C2=A0 = The state machine
=C2=A0 =C2=A0 =C2=A0for this is as follows:"

1) I would like to explicitly note that the generated offer is not applied<= br> (and any previously applied offer is not removed) until
setLocalDescription() is called.

---

Section 3.3 says:

=C2=A0 =C2=A0 =C2=A0"In the WebRTC specification, session descriptions= are formatted as
=C2=A0 =C2=A0 =C2=A0 SDP messages."


1) To me it is unclear what an =C2=B3SDP message=C2=B2 is, so I suggest we = say =C2=B3SDP
syntax=C2=B2, as we also do later in the section.

----

Section 3.4 says:

=C2=A0 =C2=A0 =C2=A0"In order to give the application control over var= ious common session
=C2=A0 =C2=A0 =C2=A0 parameters, JSEP provides control surfaces which tell = the browser how
=C2=A0 =C2=A0 =C2=A0 to generate session descriptions.=C2=B2


1) What is =C2=B3control surface=C2=B2? Are you talking about the interface= in
Section 4?

----

Section 3.4.1 talks about =C2=B3RtpTranceivers=C2=B2, =C2=B3RtpSenders=C2= =B2 and
=C2=B3RtpReceivers=C2=B2.

1) I think they should be introduced in their own section (not within the Session Description Protocol section).

2) I think it should be explained what an RtpXXX really is. At a minimum there should be a reference to the appropriate W3C document. But, as there<= br> is text on how they related to SDP m- lines etc, 1 or 2 sentences
describing what they are would also be useful.

---

Section 3.5.2.1 says:

=C2=A0 =C2=A0 "The m=3D line can be identified in one of two ways; eit= her by a m=3D line
index, or a MID.=C2=A0 The m=3D line
=C2=A0 =C2=A0 =C2=A0index is a zero-based index, with index N referring to = the N+1th m=3D
line in the SDP sent by the entity
=C2=A0 =C2=A0 =C2=A0which sent the IceCandidate.=C2=A0 The MID uses the &qu= ot;media stream
identification" attribute, as defined in
=C2=A0 =C2=A0 =C2=A0[RFC5888], Section 4, to identify the m=3D line."<= br>

1) Where is the m=3D line index located?

2) Where is the MID attribute located? Earlier in the section the text
says that the candidate lines are the ONLY
information within the IceCandidiate object.

3) I have some trouble to parse "the SDP sent by the entity which sent= the
IceCandidate". What entity?

---

Section 3.5.3 contains requirements regarding what a browser MUST do -
e.g., allowing the application to select what types of ICE candidates are used.

1) I am not sure why such requirements are listed here. But, in any case, is there a mechanism for applications for selecting candidate types etc? If so, what mechanism?


Regards,

Christer

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

--94eb2c06c9d40c3a88054054fc72-- From nobody Wed Nov 2 11:52:54 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 A7B5D1296D1 for ; Wed, 2 Nov 2016 11:52:52 -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 G5SkmXhTD2DF for ; Wed, 2 Nov 2016 11:52:49 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 39407129B57 for ; Wed, 2 Nov 2016 11:52:39 -0700 (PDT) X-AuditID: c1b4fb30-b87ff70000000cb2-23-581a35f4eb2f Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id E8.9D.03250.4F53A185; Wed, 2 Nov 2016 19:52:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Wed, 2 Nov 2016 19:52:36 +0100 From: Christer Holmberg To: Ted Hardie Thread-Topic: [rtcweb] JSEP WGLC: Christer's comments on section 3 - Part I Thread-Index: AQHSME3t8FqpE1oRDUKtzBZVQ19PUqDF79eAgAAkGVY= Date: Wed, 2 Nov 2016 18:52:35 +0000 Message-ID: <6EF48837-9C2D-4903-A164-CCD116DDA9E6@ericsson.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6EF488379C2D4903A164CCD116DDA9E6ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbHdVferqVSEwZ+VUhZr/7WzWzTOtXNg 8tg56y67x5IlP5kCmKK4bFJSczLLUov07RK4MqYdespYsCSpYs/tv2wNjJMDuhg5OSQETCQa fh5iB7GFBNYxSrTdN+1i5AKyFzNKHF36hrmLkYODTcBCovufNkiNiICyxN4rO9hAbGYBdYk7 i8+B9QoLeEls/7mOBaLGW2LCvimsELaVxO9Xs5hAbBYBFYm52y6ygYzkFbCXmNWhCLGqgVHi euNOsDmcAoESkxf/AbMZBcQkvp9awwSxS1zi1pP5TBA3C0gs2XOeGcIWlXj5+B8ryExmgWSJ T3vUQcK8AoISJ2c+YZnAKDwLSfcshKpZSKogSvQkbkydwgZha0ssW/iaGcLWlZjx7xALsvgC RvZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIFxc3DLb4MdjC+fOx5iFOBgVOLhLfgvGSHE mlhWXJl7iFGCg1lJhPeIiVSEEG9KYmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tSs1NT C1KLYLJMHJxSDYyeURXnT/8Kf/TjxZ9rGmJNXSuEd/4ozXLZ8XHFHPFvbya224kU79oy55y5 blHUpyWharp+9yV2vlzIolJiKJT+cdoErtPZ9/dpHJ3EtCzye8hrhe/nW3u/9bH4iia4J9d2 ZVm+2uyak8B+KPvsxsDeVQ9fbupd5aX2i1VjTc3BV4W7tdZP6q5QYinOSDTUYi4qTgQANIhb wpcCAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP WGLC: Christer's comments on section 3 - Part I 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, 02 Nov 2016 18:52:53 -0000 --_000_6EF488379C2D4903A164CCD116DDA9E6ericssoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Sorry, I forgot you wanted reviewers to create GitHub issues. Regards, Christer Sent from my iPhone On 2 Nov 2016, at 19.43, Ted Hardie > wrote: Thanks for the review, Christer. I've broken these up into issues #373 thr= ough #379 in the github repo, so we can track them there. regards, Ted On Wed, Nov 2, 2016 at 5:54 AM, Christer Holmberg > wrote: Hi, Some initial comments on Section 3. I will comment on the forking stuff in a separate e-mail. --- Section 3.2 says: "the DTLS-SRTP parameters [RFC5763] sent to a remote party indicate what certificate the local side will use in DTLS setup" 1) I am not sure what "parameters" the text is referring to. If it=B9s the fingerprint, I think the text should reference RFC 4572. 2) I think we should simply have a generic statement that, following the rules in RFC3264, parameters indicate receiving capabilities - unless explicitly indicated otherwise. --- Section 3.2 says: "JSEP also allows for an answer to be treated as provisional by the application. Provisional answers provide a way for an answerer to communicate initial session parameters back to the offerer, in order to allow the session to begin, while allowing a final answer to be specified later. This concept of a final answer is important to the offer/answer model; when such an answer is received, any extra resources allocated by the caller can be released, now that the exact session configuration is known." 1) I would like explicit text saying that this is a deviation from RFC 3264, where there is no such thing as a provisional answer. I would like to have a dedicated =B3Deviations to RFC3264=B2 (or something similar) sect= ion. 2) I would like explicit text saying that the final answer may be completely different (in terms of candidates, codecs, accepted m- line etc) from the provisional answer. 3) Related to 2), the final answer may also require NEW resources to be allocated. --- Section 3.2 says: "To support this, the JSEP media layer can provide an offer via the createOffer() method whenever the Javascript application needs one for the signaling. The answerer can send back zero or more provisional answers, and finally end the offer-answer exchange by sending a final answer. The state machine for this is as follows:" 1) I would like to explicitly note that the generated offer is not applied (and any previously applied offer is not removed) until setLocalDescription() is called. --- Section 3.3 says: "In the WebRTC specification, session descriptions are formatted as SDP messages." 1) To me it is unclear what an =B3SDP message=B2 is, so I suggest we say = =B3SDP syntax=B2, as we also do later in the section. ---- Section 3.4 says: "In order to give the application control over various common session parameters, JSEP provides control surfaces which tell the browser how to generate session descriptions.=B2 1) What is =B3control surface=B2? Are you talking about the interface in Section 4? ---- Section 3.4.1 talks about =B3RtpTranceivers=B2, =B3RtpSenders=B2 and =B3RtpReceivers=B2. 1) I think they should be introduced in their own section (not within the Session Description Protocol section). 2) I think it should be explained what an RtpXXX really is. At a minimum there should be a reference to the appropriate W3C document. But, as there is text on how they related to SDP m- lines etc, 1 or 2 sentences describing what they are would also be useful. --- Section 3.5.2.1 says: "The m=3D line can be identified in one of two ways; either by a m=3D l= ine index, or a MID. The m=3D line index is a zero-based index, with index N referring to the N+1th m=3D line in the SDP sent by the entity which sent the IceCandidate. The MID uses the "media stream identification" attribute, as defined in [RFC5888], Section 4, to identify the m=3D line." 1) Where is the m=3D line index located? 2) Where is the MID attribute located? Earlier in the section the text says that the candidate lines are the ONLY information within the IceCandidiate object. 3) I have some trouble to parse "the SDP sent by the entity which sent the IceCandidate". What entity? --- Section 3.5.3 contains requirements regarding what a browser MUST do - e.g., allowing the application to select what types of ICE candidates are used. 1) I am not sure why such requirements are listed here. But, in any case, is there a mechanism for applications for selecting candidate types etc? If so, what mechanism? Regards, Christer _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_6EF488379C2D4903A164CCD116DDA9E6ericssoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

Sorry, I forgot you wanted reviewers to crea= te GitHub issues.

Regards,

Christer


Sent from my iPhone

On 2 Nov 2016, at 19.43, Ted Hardie <ted.ietf@gmail.com> wrote:

Thanks for the review, Christer.  I've broken these up into issue= s #373 through #379 in the github repo, so we can track them there.

regards,

Ted

On Wed, Nov 2, 2016 at 5:54 AM, Christer Holmber= g <chr= ister.holmberg@ericsson.com> wrote:

Hi,

Some initial comments on Section 3. I will comment on the forking stuff in<= br> a separate e-mail.


---

Section 3.2 says:

   "the DTLS-SRTP parameters [RFC5763] sent to a remote part= y indicate what
   certificate the local side will use in DTLS setup"

1) I am not sure what "parameters" the text is referring to. If i= t=B9s the
fingerprint, I think the text should reference RFC 4572.

2) I think we should simply have a generic statement that, following the rules in RFC3264, parameters indicate receiving capabilities - unless
explicitly indicated otherwise.

---

Section 3.2 says:

   "JSEP also allows for an answer to be treated as provisio= nal by the
    application.  Provisional answers provide a way for an a= nswerer to
    communicate initial session parameters back to the offerer, i= n order
    to allow the session to begin, while allowing a final answer = to be
    specified later. This concept of a final answer is important = to the
    offer/answer model; when such an answer is received, any extr= a
    resources allocated by the caller can be released, now that t= he exact
    session configuration is known."

1) I would like explicit text saying that this is a deviation from RFC
3264, where there is no such thing as a provisional answer. I would like to have a dedicated =B3Deviations to RFC3264=B2 (or something similar) sect= ion.

2) I would like explicit text saying that the final answer may be
completely different (in terms of candidates, codecs, accepted m- line
etc) from the provisional answer.

3) Related to 2), the final answer may also require NEW resources to be
allocated.

---

Section 3.2 says:

    "To support this, the JSEP media layer
     can provide an offer via the createOffer() method whene= ver the
     Javascript application needs one for the signaling.&nbs= p; The answerer can
     send back zero or more provisional answers, and finally= end the
     offer-answer exchange by sending a final answer.  = The state machine
     for this is as follows:"

1) I would like to explicitly note that the generated offer is not applied<= br> (and any previously applied offer is not removed) until
setLocalDescription() is called.

---

Section 3.3 says:

     "In the WebRTC specification, session descriptions= are formatted as
      SDP messages."


1) To me it is unclear what an =B3SDP message=B2 is, so I suggest we say = =B3SDP
syntax=B2, as we also do later in the section.

----

Section 3.4 says:

     "In order to give the application control over var= ious common session
      parameters, JSEP provides control surfaces which tell = the browser how
      to generate session descriptions.=B2


1) What is =B3control surface=B2? Are you talking about the interface in Section 4?

----

Section 3.4.1 talks about =B3RtpTranceivers=B2, =B3RtpSenders=B2 and
=B3RtpReceivers=B2.

1) I think they should be introduced in their own section (not within the Session Description Protocol section).

2) I think it should be explained what an RtpXXX really is. At a minimum there should be a reference to the appropriate W3C document. But, as there<= br> is text on how they related to SDP m- lines etc, 1 or 2 sentences
describing what they are would also be useful.

---

Section 3.5.2.1 says:

    "The m=3D line can be identified in one of two ways; eit= her by a m=3D line
index, or a MID.  The m=3D line
     index is a zero-based index, with index N referring to = the N+1th m=3D
line in the SDP sent by the entity
     which sent the IceCandidate.  The MID uses the &qu= ot;media stream
identification" attribute, as defined in
     [RFC5888], Section 4, to identify the m=3D line."<= br>

1) Where is the m=3D line index located?

2) Where is the MID attribute located? Earlier in the section the text
says that the candidate lines are the ONLY
information within the IceCandidiate object.

3) I have some trouble to parse "the SDP sent by the entity which sent= the
IceCandidate". What entity?

---

Section 3.5.3 contains requirements regarding what a browser MUST do -
e.g., allowing the application to select what types of ICE candidates are used.

1) I am not sure why such requirements are listed here. But, in any case, is there a mechanism for applications for selecting candidate types etc? If so, what mechanism?


Regards,

Christer

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

--_000_6EF488379C2D4903A164CCD116DDA9E6ericssoncom_-- From nobody Thu Nov 3 11:16: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 D1381129AEA for ; Thu, 3 Nov 2016 11:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, T_KAM_HTML_FONT_INVALID=0.01] 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 eIA0GqBPHHVO for ; Thu, 3 Nov 2016 11:16:18 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5A2129ACF for ; Thu, 3 Nov 2016 11:15:46 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id q130so68154191qke.1 for ; Thu, 03 Nov 2016 11:15:46 -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=2KrV/vevCOCUVTDF8ebNgb4RFuBXKkcc+K+luQ5dMLE=; b=Gfl9o2jzL9TzJXm3b4oSpBg1yVVyBCVY+Cbx0SL7hdrfXwPdFkfFeGfD5wYHkUt3Mk o1F5WQDIWrshncIbE/3HJugvcsyHH3oWkG67wj8pQm8SQPr6TOKEq0x2y9R+c3BE6gTP XecHjQ3NgLmORl5JJdeczga0QiO+mKBZSzC2dpvPLz5ZAwt46DnHeszWpz9wpvFjDkwM IJrKz0CBpokNy5oXppq0wSJ+z7OF9aL5GgY8PD3GQfqjn2/zXooLuzzTBmJ0twhz0SA4 MfTQ0zlvfm6YIkV9slAP7TO0+/GMlHcWD1WBA3qlGgrWxPhqBGXJCsizbxxZLFtEMthW g4lw== 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=2KrV/vevCOCUVTDF8ebNgb4RFuBXKkcc+K+luQ5dMLE=; b=S99TZkGnbe7fei0CHddY/hvLh6/tieI0J3eroEhi/ONYAZVMmVZlRv1yD2qcuU5wM4 OR4y5HBU1sOjsuZNrAiYhGv7MdZ/WX71uDXVg1pvuFopk4u/2dsP7UWEb0/yn4kN3L4S anMJmu2OYtqGUO/cFuWqJ/vdMoZ8cspREHX9t5J+WfLiK7VD+1DJfOCXiuswqA3LItv2 CHnN7+wHctr0ctLKkHz7HwYrl7N7Zo1rKK9CwR2+zYgfyqmypBMGCO1GfNsbJ9C43Oml bCgKICnGJ9yppQjaZh0Ee1dVLBwrXf/SLo7ahTRyXlH5fxmCmt6ajS+DZPODr4U7MZ7T FDpA== X-Gm-Message-State: ABUngvfSSaf/83GSN2qvL17hWuxBIvS0KegdLTC0oi2nwJZdlrRHERBApYw7SJFBcbRHMJojvbqqdjwqEeMnOw== X-Received: by 10.55.91.193 with SMTP id p184mr817889qkb.301.1478196945091; Thu, 03 Nov 2016 11:15:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.140.8 with HTTP; Thu, 3 Nov 2016 11:15:14 -0700 (PDT) From: Ted Hardie Date: Thu, 3 Nov 2016 11:15:14 -0700 Message-ID: To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=001a114e2cf6d206aa0540698b22 Archived-At: Subject: [rtcweb] Updated draft agenda 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, 03 Nov 2016 18:16:20 -0000 --001a114e2cf6d206aa0540698b22 Content-Type: text/plain; charset=UTF-8 Howdy, The chairs currently plan to update the draft agenda for IETF 97 with the following; please let us know by close of business November 4th, if you feel we have this wrong. Note that the timing for Day two is not included, just the topics. This is because getting JSEP issues squared away is job one for the working group, and we will, if necessary, defer other topics to the mailing list. regards, Ted, Cullen, Sean Monday WG Status Update - 5 mins JSEP- 90 mins IP Handling- 15 mins FEC - 15 mins Wednesday JSEP - Revisit if needed Overview draft Security Architecture draft (RTCP & RFC 7941 issues) draft-copeland-rtcweb-p2p-idp --001a114e2cf6d206aa0540698b22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

=
The chairs currently plan to update the draft agenda= for IETF 97 with the following; please let us know by close of business No= vember 4th, if you feel we have this wrong.=C2=A0

Note that the timing for Day two is not included, just the top= ics.=C2=A0 This is because getting JSEP issues squared away is job one for = the working group, and we will, if necessary, defer other topics to the mai= ling list.=C2=A0

regards,

Ted, Cullen, Sean

Monday
WG Status Update - 5 mins
JSEP- 90 min= s =C2=A0
IP Handling- 15 mins
FEC - 15 mins
Wednesday
JSEP - Revisit if needed
Overview draft
Secu= rity Architecture draft (RTCP & RFC 7941 issues)
draft-copeland-rtcweb-p2p-idp
--001a114e2cf6d206aa0540698b22-- From nobody Tue Nov 8 10: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 4561F129881 for ; Tue, 8 Nov 2016 10:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hgT8d7v3CAVX for ; Tue, 8 Nov 2016 10:43:51 -0800 (PST) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B839812959C for ; Tue, 8 Nov 2016 10:43:50 -0800 (PST) Received: from [172.20.10.5] (2.150.52.103.tmi.telenormobil.no [2.150.52.103]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id uA8Ihv6g008609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 8 Nov 2016 19:43:59 +0100 To: rtcweb@ietf.org References: From: Philipp Hancke Message-ID: Date: Tue, 8 Nov 2016 19:43:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Working Group Last Call: JSEP 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, 08 Nov 2016 18:43:57 -0000 Am 21.10.2016 um 21:25 schrieb Ted Hardie: > The chairs would like to start a working group last call on > draft-ietf-rtcweb-jset-17 to end on November 9th, 2016, 17:00 KST. > > Please review thoroughly, as working through the last comments will be the > major effort of our working group meeting in Seoul. One question: why is pranswer still in there? The major use-case for this seems to be transport warm-up (4.1.7.1) for which I think transceivers are the new way as shown in http://w3c.github.io/webrtc-pc/#simple-peer-to-peer-example-with-warm-up pranswer has not seen much traffic on this list. Together with BUNDLE it seems to have been broken in Chrome since 2014 if I understand https://bugs.chromium.org/p/webrtc/issues/detail?id=3349 correctly. And I recall it being broken in 2013 when using DTLS. From nobody Tue Nov 8 21:57:33 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 6BF4B1294E0 for ; Tue, 8 Nov 2016 21:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (768-bit key) reason="fail (bad RSA signature)" header.d=sdiwc.info 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 l21w1my-mDbE for ; Tue, 8 Nov 2016 21:57:30 -0800 (PST) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 678DE129479 for ; Tue, 8 Nov 2016 21:57:30 -0800 (PST) Received: (qmail 6747 invoked by uid 0); 9 Nov 2016 05:57:27 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy2.mail.unifiedlayer.com with SMTP; 9 Nov 2016 05:57:27 -0000 Received: from box817.bluehost.com ([66.147.244.117]) by cmgw2 with id 5hsN1u00W2Yhrsa01hsR8a; Tue, 08 Nov 2016 22:52:26 -0700 X-Authority-Analysis: v=2.1 cv=PIacp5aC c=1 sm=1 tr=0 a=1ZWhLoquM75l/9xp6o4QLQ==:117 a=1ZWhLoquM75l/9xp6o4QLQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=1oJP67jkp3AA:10 a=L24OOQBejmoA:10 a=ZZnuYtJkoWoA:10 a=N1z6yVdWAAAA:8 a=sr0zx1tDjMXzmhjZlRoA:9 a=CjuIK1q_8ugA:10 a=FST94vGo_0DdB_9W1aeC:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sdiwc.info; s=default; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding: Content-Type:MIME-Version; bh=GAYNc6nQTVeoX/hA3aagsICjV65DpD6u9glpY6WjjxE=; b=X0MAeTm5yBS/DgueOFiCVtAowpXbU1uoTtqwO61IHFEE5xSLwNjph8ZtwsiJZ7wBw2rQE9sBSM GYdZRZxjiVKKEtZyxCfMTFM+vvpH5RHBTNwWlp7B3K4wDC1dJod+b9; Received: from [127.0.0.1] (port=44254 helo=box817.bluehost.com) by box817.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1c4Lo8-0007xv-91 for rtcweb@ietf.org; Tue, 08 Nov 2016 22:52:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 08 Nov 2016 22:52:24 -0700 From: Jackie Blanco To: rtcweb@ietf.org Message-ID: <222192b413a8aa83714683830c5e6c42@sdiwc.info> X-Sender: jackie@sdiwc.info User-Agent: Roundcube Webmail/1.0.6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box817.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sdiwc.info X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Exim-ID: 1c4Lo8-0007xv-91 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (box817.bluehost.com) [127.0.0.1]:44254 X-Source-Auth: jackie@sdiwc.info X-Email-Count: 10 X-Source-Cap: c2Rpd2NuZXQ7c2Rpd2NuZXQ7Ym94ODE3LmJsdWVob3N0LmNvbQ== Archived-At: Subject: [rtcweb] Call for papers, participation and special session - Cyber Security, Cyber Welfare and Digital Forensic 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, 09 Nov 2016 05:57:31 -0000 Call for papers, participation and special session: The Fifth International Conference on Cyber Security, Cyber Welfare and Digital Forensic (CyberSec2017) St. Mary's University, Addis Ababa, Ethiopia April 22-24, 2017 http://sdiwc.net/conferences/6th-international-cyber-security-cyber-welfare-digital-forensic/ The conference aims to enable researchers build connections between different digital applications and engineering. The conference welcomes papers on the following research topics: - Cyber Security - Cyber Welfare - Digital Forensic - Cyber Crimes - Security Protocol Registered papers will be published in the Society of Digital Information and Wireless Communications' Digital Library and in the proceedings of the conference. Special Session Mechanics: Special Sessions may address one or more tracks, but they should be organized under a unified theme. Each special session should attract 6 registered papers. These papers will be part of the Conference Proceedings, and they will be published in the proceedings of the conference and will be sent to at least 10 indexing places. DEADLINES Paper Submission: March 1, 2017 Notification of Acceptance: March 15, 2017 Camera Ready & Registration: April 6, 2017 From nobody Wed Nov 9 17:22: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 DB84A1294AC for ; Wed, 9 Nov 2016 17:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 vauwC7NajlJ3 for ; Wed, 9 Nov 2016 17:22:50 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 0D6A1129536 for ; Wed, 9 Nov 2016 17:22:50 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id 20so189040573uak.0 for ; Wed, 09 Nov 2016 17:22:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=yW8JJRTBSjYHbeglY3oNMMAzNwDlSgciSl0CX4JLCgw=; b=v8TqVtoKjohaT+bg9BMjyZEvn823tDzgNMj6ReAwBu5GCmXuOgGRR2pjFxKkTrlVST jUJIgtZZ1HKWCYlI0L3Hs2kiu5EyxpCJhYAG/9IGmG8YqM5TdJjm4iOz9/c//GYsjX4r 5Fejskg43mXKZbLOAQ2kampci59mGB5dwxHG8AjfeGWmlhy0qms/3gkQo67BvN352CtZ 5YJGA8RVgs4ZWdqXzVgDiRreP1S0wBzMXvj5OJjOfMzvRGcIew6tzsbpHMZbQoJ/ZN7N 0XSgDxxRvdlgzw8Xca0aU362pPu4JBCpt+5xskEtX434MFtaOIUf8Hu8V6N/1fH6i4Cp NN1Q== 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=yW8JJRTBSjYHbeglY3oNMMAzNwDlSgciSl0CX4JLCgw=; b=T7bwykvVqOiaX36YTGhQm+EE4WXB7ZQY5vP8iEUrbht7ZhvH99QwyjX0BpEw5SF8dw d5aK//v1VSvMBc1JF7wWs8imHGZAlRg7sithv7Bxq1J/UDmhuowMiRMqbcgJwBEx6eDV 4vdjS6hxnTGtoSPWfyvTkE9MQwf996cesfEKW8he1MBv/I7j17x/VDq9XmjRZxDaT25w IRz7VTv47GamomwrUWPI/kmuVSd86JGmlFPZD2NiLWNTVGydtzWwcN84g3bg4lbT0kH5 hgRqeOsBYTZjByr076L8WRGbmehU+KA6VOPccAY6FgBV/6KfNvpWbWm7emBUKtBbBdQP urZA== X-Gm-Message-State: ABUngvcOVa+9oL0E77KZM73aGotnXE5a4NqOA0W2DZaQrwZcNAfQlBluSefvKT7MI5zVrCv9hW72BCa7B520Lw== X-Received: by 10.176.3.84 with SMTP id 78mr1805774uat.117.1478740968937; Wed, 09 Nov 2016 17:22:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Wed, 9 Nov 2016 17:22:28 -0800 (PST) From: Bernard Aboba Date: Wed, 9 Nov 2016 17:22:28 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a113f03262b21d40540e83609 Archived-At: Subject: [rtcweb] JSEP Section 4.2.3: setDirection() 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, 10 Nov 2016 01:22:52 -0000 --001a113f03262b21d40540e83609 Content-Type: text/plain; charset=UTF-8 Section 4.2.3: The setDirection method sets the direction of a transceiver, which affects the direction attribute of the associated m= section on future calls to createOffer and createAnswer. [BA] "sets the direction of a transceiver" is a bit confusing because setDirection() doesn't immediately change whether an RtpSender can send or an RtpReceiver can receive. Since setDirection does immediately change the value of the transceiver.direction attribute you might say "sets the transceiver.direction attribute" instead. Also, an application may want to determine the current direction (e.g. whether an RtpSender can send or an RtpReceiver can receive) as opposed to the pending direction (provided by transceiver.direction). Taylor agreed to create a WebRTC 1.0 PR to add the concept of current direction (e.g. by adding a currentDirection attribute). It would therefore be useful to add some text to Section 4.2.3 explaining the distinction. For example: "Note that while setDirection sets the transceiver.direction attribute immediately, this pending direction does not immediately affect whether an RtpSender will send or RtpReceiver will receive. After calls to setLocal/setRemoteDescription, the direction currently in effect is represented by transceiver.currentDirection (the attribute Taylor will be defining)." --001a113f03262b21d40540e83609 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Section 4.2.3:

   The setDirection method sets the direction of a transceiver, w=
hich
   affects the direction attribute of the associated m=3D section on
   future calls to createOffer and createAnswer.

[BA] "sets th=
e direction of a transceiver" is a bit confusing because
setDirection() doesn't immediately change= whether an RtpSender can
send or an=
 RtpReceiver can receive.  Since setDirection does
immediately change the value of the transceiver.direction
attribute you might say "sets the=
 transceiver.direction attribute" instead. 

Also, an applicati=
on may want to determine the current
direction (e.g. whether an RtpSender can send or an RtpReceiver
can receive) as opposed to the pending directi=
on (provided
by transceiver.directio=
n).  Taylor agreed to create a WebRTC 1.0
PR to add the concept of current direction (e.g. by adding
a currentDirection attribute).  It would there=
fore be useful to add some text
to S=
ection 4.2.3 explaining the distinction.  For example:

"Note t=
hat while setDirection sets the transceiver.direction
attribute immediately, this pending direction does not im=
mediately
affect whether an RtpSende=
r will send or RtpReceiver will receive. 
After calls to setLocal/setRemoteDescription, the direction currently=

in effect is represented by transce=
iver.currentDirection (the attribute
Taylor will be defining)."
--001a113f03262b21d40540e83609-- From nobody Wed Nov 9 17:36:56 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 2DF4712959B for ; Wed, 9 Nov 2016 17:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 kdy8bVF_7TCU for ; Wed, 9 Nov 2016 17:36:52 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 4E45A1294AC for ; Wed, 9 Nov 2016 17:36:52 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id b35so189159511uaa.3 for ; Wed, 09 Nov 2016 17:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PrwNP4nfy0PuV3auAzGILmz1DU/xaTka6fiVYdpwjfU=; b=CPxRkvLycjfdoCaT6dYBqgaHMl7Yom6lfEXumv0wSuMRvi1buOEMj3wI0e3eTo6UHk arjwl1k1WfW+wPo9mvfvvJVHD3a5VqqLXDn1xfJkEOHSzWQpNm0aGF527I8RqT0SPV7/ 4e22ZapmZp9QWEGNi9vI6IKeiZ6RROhKIwB77DdzU9dzX/Yo6WorAPKirtNnA9GPX2Kx +F+6PWYX9j5+8uxj+SIqvVN122Lurb5gF3QI8P9vfMP/1IQ4TNa2qLvMiRX7pDqqQc5Y jWCT9HeZIINej6rwqsH0S68hJK2ZJKXyjSmnD+qzA8LAhpEKojN0Bi8RnEwVkL5dxySU JyCA== 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=PrwNP4nfy0PuV3auAzGILmz1DU/xaTka6fiVYdpwjfU=; b=l2HaZHaUTsq/1NMgeD5TxAj9yhiQyyfO8ABR9o3IZfgJGctNA6Vqokdg+0e/4EhnM1 HjflKe3r2dJxJjiZD3S+MFLXTZOC3Qb7REP2fBcqWHX7DxrCfb1nz9hepW/kFU9FcnrT G24FG0JiDROaxGCdvVgjO3yX7BlGKBBRRF53fR8Ix/T5nF3Y2s75xPOebmwF1vArqw7L Xl4AZssZExqhElonVwx89S6uPlYVCsb8FMv01hbcfizMX5DSo4KM4w3gcoPX+oJERBid BUYE99VNB2BY3gs2HvymAVDAvYlSIqnzzfjfhJFHQ9SI+6aqKQ1MNqc5E/Y3xlu84vs+ JAHA== X-Gm-Message-State: ABUngvdJVIUW+gS9FcgVS7DM4CSubkY13EUXZVCify9xJoULF7AYfU1ABEBhnPLYMC1cslPYsPn0CwugR2JuQQ== X-Received: by 10.159.34.41 with SMTP id 38mr1881935uad.160.1478741811357; Wed, 09 Nov 2016 17:36:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Wed, 9 Nov 2016 17:36:31 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Wed, 9 Nov 2016 17:36:31 -0800 Message-ID: To: Philipp Hancke Content-Type: multipart/alternative; boundary=001a1135df646170680540e86842 Archived-At: Cc: "rtcweb@ietf.org" , Shijun Sun Subject: Re: [rtcweb] Working Group Last Call: JSEP 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, 10 Nov 2016 01:36:54 -0000 --001a1135df646170680540e86842 Content-Type: text/plain; charset=UTF-8 +1. One of the reasons we added setDirection() was to be able to handle the "warm up" case with no recourse to pranswer (as demonstrated in Example 12 in Section 11.2 as you cite). Given that, it is hard to motivate an implementation to support pranswer (e.g. in the Edge WebRTC 1.0 feature now in Windows Insider Preview, we left out support for pranswer). On Tue, Nov 8, 2016 at 10:43 AM, Philipp Hancke wrote: > Am 21.10.2016 um 21:25 schrieb Ted Hardie: > >> The chairs would like to start a working group last call on >> draft-ietf-rtcweb-jset-17 to end on November 9th, 2016, 17:00 KST. >> >> Please review thoroughly, as working through the last comments will be the >> major effort of our working group meeting in Seoul. >> > > One question: why is pranswer still in there? The major use-case for this > seems to be transport warm-up (4.1.7.1) for which I think transceivers are > the new way as shown in http://w3c.github.io/webrtc-pc > /#simple-peer-to-peer-example-with-warm-up > > pranswer has not seen much traffic on this list. Together with BUNDLE it > seems to have been broken in Chrome since 2014 if I understand > https://bugs.chromium.org/p/webrtc/issues/detail?id=3349 correctly. And I > recall it being broken in 2013 when using DTLS. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1135df646170680540e86842 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1. =C2=A0

One of the reasons we added setDir= ection() was to be able to handle the "warm up" case with no reco= urse to pranswer (as demonstrated in Example 12 in Section 11.2 as you cite= ).

Given that, it is hard to motivate an implement= ation to support pranswer (e.g. in the Edge WebRTC 1.0 feature now in Windo= ws Insider Preview, we left out support for pranswer).=C2=A0



=
On Tue, Nov 8, 2016 at 10:43 AM, Philipp Hancke = <fippo@goodadvice.pages.de> wrote:
Am 21.10.2016 um 21:25 schrieb Ted Hard= ie:
The chairs would like to start a working group last call on
draft-ietf-rtcweb-jset-17 to end on November 9th, 2016, 17:00 KST.

Please review thoroughly, as working through the last comments will be the<= br> major effort of our working group meeting in Seoul.

 One question: why is pranswer still in there? The major use-case for this s= eems to be transport warm-up (4.1.7.1) for which I think transceivers are t= he new way as shown in http:= //w3c.github.io/webrtc-pc/#simple-peer-to-peer-example-with-warm-= up

pranswer has not seen much traffic on this list. Together with BUNDLE it se= ems to have been broken in Chrome since 2014 if I understand https://bugs.chromium.org/p/webrtc/issues/detail?id= =3D3349 correctly. And I recall it being broken in 2013 when using DTLS= .


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

--001a1135df646170680540e86842-- From nobody Wed Nov 9 22:28: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 145A412940F for ; Wed, 9 Nov 2016 22:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 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, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xn87sqodMpiT for ; Wed, 9 Nov 2016 22:28:38 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 4CDA5129408 for ; Wed, 9 Nov 2016 22:28:38 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id x190so282898707qkb.0 for ; Wed, 09 Nov 2016 22:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+5jfcpn03/KmKbQUvSaBVNXpSNPMndloXGbN+eoBNz0=; b=i7x2hvlWLAx8yfrI2cTzhbQd6Ap12UPmBm7YtW6/nEvPrzqrqSd1GHTWpl2Jk0vEt0 t6J6H7Ha/HTZDxUT7/6wu7ho9SFeO6fltzYfW1tFeqNmZWQ4w80dLVwgipoSDOcmEI1g CTUGSPlcpOxGc2Mf5tq8dqMlQcWkbQSjSriAu/Bwi8A2+eqQoilWoS43dqTd24LrScKa GCJTSOiUlNQwfXNRnaA3MmboKcB5RI4EbodJ06rC/eCa9lmosfkT2ySzcwTIVgasKvEU vyBi6mOgTLDICm499QXVYlNS6rVFByOlOvFvs9+fcoQ7wRif6dNutTS8JuJDRx5SNmod +/dg== 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=+5jfcpn03/KmKbQUvSaBVNXpSNPMndloXGbN+eoBNz0=; b=H31IZnefn9Cu76FvHojkdzJotnGh0Sq66AZb5DujONsLYXEQX+dlWGqgA39Te0QK/v aTGYabwk/Ei8aQCWo3piGvcjN6v4OlrZl9NY3nqDWOuxLaNsDS9QS/EAUEzONvBXf2hu 11TbbRyzw6tVYFiQjD/7u1Gt50ZXHNplFBTqSzaQ8hfUWslV2jA/cvD5q3jR5rPG7J6d 5zb2DOl6tBd/VZE4sIMUJSaYn7y2ENJiBNag3QBE2meFMW71YHtVU/htu8qPFVjNAmUw pXUlHxja4UMGiHduekJP37SiN9ehVateK5G/8jKEcpd5QWcr+5P83A4vvDrzDMrmWbW6 xUzw== X-Gm-Message-State: ABUngveiR/dzPOrvGw9sCjPpEVk73xBgrTFf4ZaUYGGaxQ0M/qKSloeP0+wGy/Ct4Sox+O65RV+L6n9bpu79p6wm X-Received: by 10.55.4.134 with SMTP id 128mr3777184qke.281.1478759317291; Wed, 09 Nov 2016 22:28:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.41.134 with HTTP; Wed, 9 Nov 2016 22:28:36 -0800 (PST) In-Reply-To: References: From: Taylor Brandstetter Date: Wed, 9 Nov 2016 22:28:36 -0800 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a114c8946d1272f0540ec7b64 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP Section 4.2.3: setDirection() 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, 10 Nov 2016 06:28:40 -0000 --001a114c8946d1272f0540ec7b64 Content-Type: text/plain; charset=UTF-8 If we add a negotiatedDirection attribute, should we add something in JSEP about it? It deals with SDP, so that seems logical. On Wed, Nov 9, 2016 at 5:22 PM, Bernard Aboba wrote: > Section 4.2.3: > > The setDirection method sets the direction of a transceiver, which > affects the direction attribute of the associated m= section on > future calls to createOffer and createAnswer. > > > [BA] "sets the direction of a transceiver" is a bit confusing because > > setDirection() doesn't immediately change whether an RtpSender can > > send or an RtpReceiver can receive. Since setDirection does > > immediately change the value of the transceiver.direction > > attribute you might say "sets the transceiver.direction attribute" instead. > > > Also, an application may want to determine the current > > direction (e.g. whether an RtpSender can send or an RtpReceiver > > can receive) as opposed to the pending direction (provided > > by transceiver.direction). Taylor agreed to create a WebRTC 1.0 > > PR to add the concept of current direction (e.g. by adding > > a currentDirection attribute). It would therefore be useful to add some text > > to Section 4.2.3 explaining the distinction. For example: > > > "Note that while setDirection sets the transceiver.direction > > attribute immediately, this pending direction does not immediately > > affect whether an RtpSender will send or RtpReceiver will receive. > > After calls to setLocal/setRemoteDescription, the direction currently > > in effect is represented by transceiver.currentDirection (the attribute > > Taylor will be defining)." > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a114c8946d1272f0540ec7b64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If we add a negotiatedDirection attribute, should we add s= omething in JSEP about it? It deals with SDP, so that seems logical.
<= div class=3D"gmail_extra">
On Wed, Nov 9, 201= 6 at 5:22 PM, Bernard Aboba <bernard.aboba@gmail.com> = wrote:
Section 4.2.3:
=
   The setDirection method sets the direction of a transceiver, which
   affects the direction attribute of the associated m=3D section on
   future calls to createOffer and createAnswer.

[BA] "sets the direction of a transceiver&qu=
ot; is a bit confusing because
setDirection() doesn't immediately change whether =
an RtpSender can
send or an RtpReceiver can receive.  Since setDirection does
immediately change the va=
lue of the transceiver.direction
attribute you might say "sets the transceiver.direc=
tion attribute" instead. 

Also, an application may want to determine the current
direction (e.g. whether an=
 RtpSender can send or an RtpReceiver
can receive) as opposed to the pending direction (p=
rovided
by tra=
nsceiver.direction).  Taylor agreed to create a WebRTC 1.0
PR to add the concept of curr=
ent direction (e.g. by adding
a currentDirection attribute).  It would therefore be usefu=
l to add some text
to Section 4.2.3 explaining the distinction.  For example:

"Note that while setDirection=
 sets the transceiver.direction
attribute immediately, this pending direction does not im=
mediately
affe=
ct whether an RtpSender will send or RtpReceiver will receive. 
After calls to setLocal/s=
etRemoteDescription, the direction currently
in effect is represented by transceiver.curr=
entDirection (the attribute
Taylor will be defining)."


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

--001a114c8946d1272f0540ec7b64-- From nobody Wed Nov 9 22:35:37 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 DC138129492 for ; Wed, 9 Nov 2016 22:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 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_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 dTV7Lp2jIYsO for ; Wed, 9 Nov 2016 22:35:31 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C4F129604 for ; Wed, 9 Nov 2016 22:35:31 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id t79so10899385wmt.0 for ; Wed, 09 Nov 2016 22:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oDUlrNwXT9NjwBS/8YxqG7bHaA25KjsyWX5LUAe7k+Y=; b=oIRQmxBkEhd0gzvtRIuUis5h7kRm9e104i5SkYfTn+h9iA7bF0ICRY49bkWi+K6THG 9YR81asRieIlLAw5YqCqZt8fmq6wyaAcoKtLQykbVUGqeEZruvN0H3ymtp1k1V6j3wxS Hm8bt6DpvTdSl1/0M0gGm7jvoR26QwA65SiEt+ihxSgpAs5TlVxWRViDVrIVzrcwkCg+ evhwp1hitJmFhP9QVdoc9A5epxa3wY063Ttobycf4Il1y7cy19U6Sn2OF64ku2cYWvdu 1XHY1ynaFICldG2JVBivbhcT6s331xFrPLRXhJ+Pwvn71JLNTBQJ6QeZ7KORqaOPMIxH HU7g== 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=oDUlrNwXT9NjwBS/8YxqG7bHaA25KjsyWX5LUAe7k+Y=; b=CNy7kAgUJMhQ5cYeoGI7XJhKwsumyNBwyU2eR3KdyathZKd4nWtO18RuW8iZ8p5G1C +0HdwHjjzGaJr9H/NVxwwXkN3bb2O7bgUPWGOTbp+7FfeVxgIvJS5bov7SkMu/BOXHiZ OP7BVNp4Vy4w50Tl/8aBWa2GsL2rHpfGahxc0ELrI6Joa46ERrjRWLuhsZaIdaypu2Rj K3FmOsvIbevUbSXL2ZR2m9iGL7pmFKW/yIaWEuJ8j2/J/FeAsjVfYkh0aK3zNtsaXN8B LRQ44o3is+brzI0y+R8budeNG6QV9MnnujnagvLFTG64whSgalTc8cJzFB7xboQgbFx/ kcAg== X-Gm-Message-State: ABUngvcDkGHngN5zUBmJTduoANhoRl0ZmFnRZtfqntlycDkMf9M1iy3WBcNf1D7HzBQwF4s14pkVOobprTNfu6FM X-Received: by 10.194.149.143 with SMTP id ua15mr3555240wjb.48.1478759729878; Wed, 09 Nov 2016 22:35:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.8.131 with HTTP; Wed, 9 Nov 2016 22:35:09 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Wed, 9 Nov 2016 22:35:09 -0800 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=089e0122897c68c41d0540ec9487 Archived-At: Cc: "rtcweb@ietf.org" , Shijun Sun Subject: Re: [rtcweb] Working Group Last Call: JSEP 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, 10 Nov 2016 06:35:35 -0000 --089e0122897c68c41d0540ec9487 Content-Type: text/plain; charset=UTF-8 Agreed. The sole purpose it serves at this point is to enable serial forking. I would be happy to remove it. On Wed, Nov 9, 2016 at 5:36 PM, Bernard Aboba wrote: > +1. > > One of the reasons we added setDirection() was to be able to handle the > "warm up" case with no recourse to pranswer (as demonstrated in Example 12 > in Section 11.2 as you cite). > > Given that, it is hard to motivate an implementation to support pranswer > (e.g. in the Edge WebRTC 1.0 feature now in Windows Insider Preview, we > left out support for pranswer). > > > > On Tue, Nov 8, 2016 at 10:43 AM, Philipp Hancke > wrote: > >> Am 21.10.2016 um 21:25 schrieb Ted Hardie: >> >>> The chairs would like to start a working group last call on >>> draft-ietf-rtcweb-jset-17 to end on November 9th, 2016, 17:00 KST. >>> >>> Please review thoroughly, as working through the last comments will be >>> the >>> major effort of our working group meeting in Seoul. >>> >> >> One question: why is pranswer still in there? The major use-case for this >> seems to be transport warm-up (4.1.7.1) for which I think transceivers are >> the new way as shown in http://w3c.github.io/webrtc-pc >> /#simple-peer-to-peer-example-with-warm-up >> >> pranswer has not seen much traffic on this list. Together with BUNDLE it >> seems to have been broken in Chrome since 2014 if I understand >> https://bugs.chromium.org/p/webrtc/issues/detail?id=3349 correctly. And >> I recall it being broken in 2013 when using DTLS. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e0122897c68c41d0540ec9487 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed. The sole purpose it serves at this point is to ena= ble serial forking.=C2=A0

I would be happy to remove it.=

On We= d, Nov 9, 2016 at 5:36 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
+1. = =C2=A0

One of the reasons we added setDirection() was to be ab= le to handle the "warm up" case with no recourse to pranswer (as = demonstrated in Example 12 in Section 11.2 as you cite).

Given that, it is hard to motivate an implementation to support pran= swer (e.g. in the Edge WebRTC 1.0 feature now in Windows Insider Preview, w= e left out support for pranswer).=C2=A0


<= /div>

On Tue, Nov 8, 2016 at 10:4= 3 AM, Philipp Hancke <fippo@goodadvice.pages.de> wro= te:
Am 21.10.2016 um 21:25 schrieb = Ted Hardie:
The chairs would like to start a working group last call on
draft-ietf-rtcweb-jset-17 to end on November 9th, 2016, 17:00 KST.

Please review thoroughly, as working through the last comments will be the<= br> major effort of our working group meeting in Seoul.

 One question: why is pranswer still in there? The major use-case for this s= eems to be transport warm-up (4.1.7.1) for which I think transceivers are t= he new way as shown in http:= //w3c.github.io/webrtc-pc/#simple-peer-to-peer-example-with-warm-= up

pranswer has not seen much traffic on this list. Together with BUNDLE it se= ems to have been broken in Chrome since 2014 if I understand https://bugs.chromium.org/p/webrtc/issues/detail?id= =3D3349 correctly. And I recall it being broken in 2013 when using DTLS= .


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


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

--089e0122897c68c41d0540ec9487-- From nobody Wed Nov 9 23:30:32 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 3F5EE129416 for ; Wed, 9 Nov 2016 23:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 D5aoxj0QoNZz for ; Wed, 9 Nov 2016 23:30:29 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 5CCA2128B38 for ; Wed, 9 Nov 2016 23:30:29 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id 12so194133583uas.2 for ; Wed, 09 Nov 2016 23:30:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VgF8vvbj3HgQFOb7HetOphUm3OrbE6UCWDJyf6IpiHk=; b=0AQrCgvLJWteulLnMclshmPDSw8ZGQeio4NiqyNHoEqVh2l3UQnmNLhPjFnMbVi8zf 8oSQxu3kTDMT7E+VXcCuemuepOAbaMrF032YS7/2xqCRMvwy3F1hXRUSrp21QOxkn8xb 8RVWTc9eEyG+Tx3NSx/FXuO+3TugloSFNVX2BpwdO2YRa2HOEXZML8mQ6BY2Fyjr3tLJ ZbYEJs84BRvyHmC7SayWPHbqVZt2WX3kLgjxvT776kDMeEEjLet//M2AYf3V6CnDn5WX +5e8n0KDg7UfXRfqxPBctG81bEgwUbIJ+m/TKynkf7SVHF4mGWJK3nShBUvlw6uhudaD +hnQ== 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=VgF8vvbj3HgQFOb7HetOphUm3OrbE6UCWDJyf6IpiHk=; b=ki1Lw+toOn+xsu9zXwrLzi7NlsZ9K+YIQWuDgpDuLPP0Gm3lZJ9nUc7XzM3mP8pwOE P1ce4ED9+MRPYRDIbSqMuZwKWPKA/zPfA7VwA5MX74EBe7VPtnwuHWEWTel3TeVz1q73 u8F0bEd/3gckkaYz6MDKHQjuzdHikKiO4n3BOsVm3MeBWIWgmX0yh4XoAFnZtW6ipY46 hUiWLBckaNUVExnu6iuNAM9HT6GO7x9M1+ncCXPm1P5dNBnzNp8pedr/kag2f7f0iNZy BzHfru3vFsWneO4DixQTICU1VJMeJjqWWfUH6vVr7GTDfyPj8ZjxNm+IWQEOj0Q59JvV s3yw== X-Gm-Message-State: ABUngvfakvPM3v8RjijSz8FP4TdbcSezWadBgZdFW2w/1dpyxLnoHdbkqIAfJDvA7Q1P+obanJvxoYSmT9G28g== X-Received: by 10.176.3.84 with SMTP id 78mr2457125uat.117.1478763028432; Wed, 09 Nov 2016 23:30:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Wed, 9 Nov 2016 23:30:08 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Wed, 9 Nov 2016 23:30:08 -0800 Message-ID: To: Taylor Brandstetter Content-Type: multipart/alternative; boundary=001a113f0326044f9a0540ed5951 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP Section 4.2.3: setDirection() 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, 10 Nov 2016 07:30:31 -0000 --001a113f0326044f9a0540ed5951 Content-Type: text/plain; charset=UTF-8 Yes, we should add something in JSEP since it is related to SDP. On Wed, Nov 9, 2016 at 10:28 PM, Taylor Brandstetter wrote: > If we add a negotiatedDirection attribute, should we add something in JSEP > about it? It deals with SDP, so that seems logical. > > On Wed, Nov 9, 2016 at 5:22 PM, Bernard Aboba > wrote: > >> Section 4.2.3: >> >> The setDirection method sets the direction of a transceiver, which >> affects the direction attribute of the associated m= section on >> future calls to createOffer and createAnswer. >> >> >> [BA] "sets the direction of a transceiver" is a bit confusing because >> >> setDirection() doesn't immediately change whether an RtpSender can >> >> send or an RtpReceiver can receive. Since setDirection does >> >> immediately change the value of the transceiver.direction >> >> attribute you might say "sets the transceiver.direction attribute" instead. >> >> >> Also, an application may want to determine the current >> >> direction (e.g. whether an RtpSender can send or an RtpReceiver >> >> can receive) as opposed to the pending direction (provided >> >> by transceiver.direction). Taylor agreed to create a WebRTC 1.0 >> >> PR to add the concept of current direction (e.g. by adding >> >> a currentDirection attribute). It would therefore be useful to add some text >> >> to Section 4.2.3 explaining the distinction. For example: >> >> >> "Note that while setDirection sets the transceiver.direction >> >> attribute immediately, this pending direction does not immediately >> >> affect whether an RtpSender will send or RtpReceiver will receive. >> >> After calls to setLocal/setRemoteDescription, the direction currently >> >> in effect is represented by transceiver.currentDirection (the attribute >> >> Taylor will be defining)." >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --001a113f0326044f9a0540ed5951 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, we should add something in JSEP since it is related t= o SDP.=C2=A0

On Wed, Nov 9, 2016 at 10:28 PM, Taylor Brandstetter <= ;deadbeef@google.c= om> wrote:
If we add a negotiatedDirection attribute, should we add something in JSEP= about it? It deals with SDP, so that seems logical.

On Wed, Nov= 9, 2016 at 5:22 PM, Bernard Aboba <bernard.aboba@gmail.com><= /span> wrote:
Section 4.2.3:

   The setDirec=
tion method sets the direction of a transceiver, which
   affects the direction attribute of the associated m=3D section on
   future calls to createOffer and createAnswer.

[BA] &quo=
t;sets the direction of a transceiver" is a bit confusing because
<=
/pre>
setDirection() doesn't immediately change whether an RtpSender ca=
n
send or an RtpReceiver can receive.  Since setDirection does
<=
pre class=3D"m_148173284083451107m_-4013911434958878094gmail-newpage" style=
=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">=
immediately change the value of the transceiver.direction
attribute=
 you might say "sets the transceiver.direction attribute" instead=
. 

Also, an application may want to determine the current<=
/pre>
direction (e.g. whether an RtpSender can send or an RtpReceiver
=

can receive) as opposed to the pending direction (provided
by transc=
eiver.direction).  Taylor agreed to create a WebRTC 1.0
PR to add the=
 concept of current direction (e.g. by adding
a currentDirection attr=
ibute).  It would therefore be useful to add some text
to Section 4.2=
.3 explaining the distinction.  For example:

"Note th=
at while setDirection sets the transceiver.direction
attribute immedi=
ately, this pending direction does not immediately
affect whether an =
RtpSender will send or RtpReceiver will receive. 
After calls to setL=
ocal/setRemoteDescription, the direction currently
in effect is repre=
sented by transceiver.currentDirection (the attribute
Taylor will be =
defining)."


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


--001a113f0326044f9a0540ed5951-- From nobody Fri Nov 11 15:13:35 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 6F2FA129853 for ; Fri, 11 Nov 2016 15:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 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_FONT_FACE_BAD=0.981, 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 aYsciO_8Drfx for ; Fri, 11 Nov 2016 15:13:33 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 7B338129771 for ; Fri, 11 Nov 2016 15:13:32 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id x186so25009181vkd.1 for ; Fri, 11 Nov 2016 15:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=tRvtkR73RhaWRF25xr64nHrS5AZdRNl89P2/qxVsY7s=; b=hyeJ/onNynSB6FRG0FeByPsJRVcWdBIXsQTGwI14VkKE4auQZt3jJOl4/aQ7G2sS7h yMPFXZWrR41w2emWvowp0fSbltKBUOQ8QMTSgtvovLovUKAK6pYXAA5U9MkfuquUWSzY eIVTK7t4rOC/lBPHWiaR2obZ0HroQyrdfseLbGUl68BKd14sGPtduCerg9Olrs2XFeoZ yS/4jqXaab6bCH8Xnkkm0DjlDi7L1LKcfzw2VMceQz26w3nsMvYMfqXFNytwegnORjgI MEcHU4UHLubZXV8K+RdhaRZNkH31Wv9jqxjiUjiZoWyb7/W7Mv4B7a4N0jHIfE6JCAVk uzng== 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=tRvtkR73RhaWRF25xr64nHrS5AZdRNl89P2/qxVsY7s=; b=FNTz5Vvy/79+Wutk7PYvWa56bsnqwr30S/vC/rNspu6ASvusXrm2YgEPv7GSyz4QoF P9ZN1aftW1W5fiFqOG7OvczvFB/MFyc5se4Vq/fui2ubX1dLKb7OEKGAknn0SAFCtdS8 OidvJ2k/Heot+auH+e0382rvPSFLihLU8r1GF9SfGlbQ9ESZ+r2e0IW2Lc0SL4jlyzMD I3JKwCUloWe1dk/c42ZXpr59WHERaOYZklUO9TZjoIiDCxz7/ju1r9/LrktF2HRUb50S ZnE9VNSNaIMQP7PPzim+ynWIW5t+3406nk8Z7jgkHhfyGaTcCsp3JV6QDbe6C31kbY9f 3Njg== X-Gm-Message-State: ABUngvcysjjRwigUC1FvKDPWQ+/qdWPfsV2g1zozmN7WpxjaVnmugPl0BQ4gbBI/Q+it+oDbb8xzWqHW0MjvBA== X-Received: by 10.31.134.77 with SMTP id i74mr3775477vkd.57.1478906011332; Fri, 11 Nov 2016 15:13:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Fri, 11 Nov 2016 15:13:11 -0800 (PST) From: Bernard Aboba Date: Fri, 11 Nov 2016 15:13:11 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a114115b676364905410ea3e6 Archived-At: Subject: [rtcweb] JSEP: When the "current direction" changes 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, 11 Nov 2016 23:13:34 -0000 --001a114115b676364905410ea3e6 Content-Type: text/plain; charset=UTF-8 According to WebRTC 1.0 Section 5.4 (and JSEP Section 4.2.3) setDirection() does not take effect immediately: "The setDirection method sets the direction of the RTCRtpTransceiver. Calls to setDirection() do not take effect immediately. Instead, future calls to createOffer and createAnswer mark the corresponding media description as sendrecv, sendonly, recvonly or inactive as defined in [JSEP] (section 5.2.2. and section 5.3.2.). Calling setDirection() sets the negotiation-needed flag." My understanding is that setDirection immediately sets the transceiver.direction attribute, but that the "current direction" (distinct from the direction attribute) is only changed by calls to setLocal/setRemoteDescription. The question is when the "current direction" changes, and how this relates to the direction expressed in the currentLocalDescription and currentRemoteDescription. Some concrete examples: Example 1 1. The direction provided in the currentLocalDescription (e.g. the "current direction") is "sendrecv" and setDirection("recvonly") is called. Since setDirection does not change currentLocalDescription, the RtpSender does not stop sending, correct? 2. createOffer() is called. A "recvonly" offer is generated. 3. setLocalDescription(RecvOnlyOffer) is called. Now the direction in pendingLocalDescription changes to "recvonly", but the direction in currentLocalDescription is still "sendrecv". The RtpSender still does not stop sending, correct? 4. setRemoteDescription(SendOnlyAnswer) is called. Now the direction in currentLocalDescription is "recvonly". So, the RtpSender will now stop sending, right? Example 2 1. The value of transceiver.direction is "sendrecv" and a "sendonly" offer is received so that setRemoteDescription(SendOnlyOffer) is called. Since this does not change currentLocalDescription (still "sendrecv"), the RtpSender does not stop sending, correct? 2. createAnswer() is called. A "recvonly" answer is generated. RtpSender is still sending. 3. setLocalDescription(RecvOnlyAnswer) is called. Now the direction in currentLocalDescription changes to "recvonly", so the RtpSender stops sending, right? --001a114115b676364905410ea3e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A= ccording to WebRTC 1.0 Section 5.4 (and JSEP Section 4.2.3) setDirection() = does not take effect immediately:

"The setDirection method sets the direction of the = RTCRtpTransceiver. Calls to setDirection() do not take effect immediately. = Instead, future calls to createOffer and createAnswer mark the correspondin= g media description as sendrecv, sendonly, recvonly or inactive as defined = in [JSEP] (section 5.2.2. and section 5.3.2.). Calling setDirection() sets = the negotiation-needed flag."

My understanding is that setDirection immediately sets = the transceiver.direction attribute, but that the "current direction&q= uot; (distinct from the direction attribute) is only changed by calls to se= tLocal/setRemoteDescription.

The question is when the "current direction" change= s, and how this relates to the direction expressed in the currentLocalDescr= iption and currentRemoteDescription.=C2=A0 Some concrete examples:=C2=A0

Example 1

  1. The direction provided in th= e currentLocalDescription (e.g. the "current direction") is "= ;sendrecv" and setDirection("recvonly") is called. Since set= Direction does not change currentLocalDescription, the RtpSender does not s= top sending, correct?
  2. createOffer() is called. A "recvonly" offer = is generated.
  3. setLocalDescription(RecvOnlyOffer) is called. Now the directio= n in pendingLocalDescription changes to "recvonly", but the direc= tion in currentLocalDescription is still "sendrecv".=C2=A0 The Rt= pSender still does not stop sending, correct?
  4. setRemoteDescription(SendOnlyA= nswer) is called. Now the direction in currentLocalDescription is "rec= vonly".=C2=A0 So, the RtpSender will now stop sending, right?

    5. = Example 2
    <= font color=3D"#333333" face=3D"-apple-system, blinkmacsystemfont, segoe ui,= helvetica, arial, sans-serif, apple color emoji, segoe ui emoji, segoe ui = symbol">
    1. The value of transceiver.direct= ion is "sendrecv" and a "sendonly" offer is received so= that setRemoteDescription(SendOnlyOffer) is called. Since this does not ch= ange currentLocalDescription (still "sendrecv"), the RtpSender do= es not stop sending, correct?
    2. createAnswer() is called.=C2=A0 A "recvonly" answer is= generated.=C2=A0 RtpSender is still sending.
    3. setLocalDescription(RecvOnlyAnswer) is called. N= ow the direction in currentLocalDescription changes to "recvonly"= , so the RtpSender stops sending, right?
--001a114115b676364905410ea3e6-- From nobody Fri Nov 11 15:33:26 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 F101312948C for ; Fri, 11 Nov 2016 15:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, 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 mWe2hSphkUWE for ; Fri, 11 Nov 2016 15:33:23 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 098EA129487 for ; Fri, 11 Nov 2016 15:33:23 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id 20so25047221uak.0 for ; Fri, 11 Nov 2016 15:33:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=5oycFNXrZkdGkPoOXc5VGd2JHA1I9jlXzgd03hetzlc=; b=jGApBiVXvOHAeQe5oNol/H1ccgs8jKUR8dWP4vX+BD7N2/CzCvbRCTAwCec1p/VONI PirzcshaTjv4zuyDh8WB1y9MXA/7+fHb9HHJjkdm9tb5Sbt75vKe/0F5p/8wpjR/qlsD A1165My9wnFk6NjD3sNTsJb6OmtVTbXOeSKYI3RM2immGZJJZvXNZVcqzaQNP9c2828T h8Xnh96CkFSsiyHhlMGbIWOK4qqZdb+GxIOntQIjoHehhDFAnuREPStyJ/BtVGjSolw2 T9PPcWdGtYpR22GNF+RsTVe9qv+dXKi892uNOvPe7DM8Tv2ESWE+jA2uhQp7RY6OivsZ j7Hg== 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=5oycFNXrZkdGkPoOXc5VGd2JHA1I9jlXzgd03hetzlc=; b=XMPjCSX0WlGj1slmGKj0WHR+xpEg/cxZNRqy/Ia6H3FqLN8Z2gnGSXmX1O3jRNjRV7 231YqRIcrrB1KikpM4t+688Buek6cjtIyhZKrTTmjVVvcBW26yW3o6wMnY8NUtteeyke FaJcEQ8UkVhYm3HOUEkLxM2He37tKu3yHghrSsjyZvMp43gFGy0y/lQ6B0OjmMDLM2So hktCF7jv+hS5XL/cYGnmYRsR5iFvUPmZO86LRkiTYHhazIF43uyiOwraXI3k0wHuC14P DT3PURVcAPk4jAwV+KwbUcENDXg9dnmrIM0DJauPUtT0sWXjk2BpHHs+d1qxQFIgfKXv Zoog== X-Gm-Message-State: ABUngvcihF/+LGEHgQSsBcRhs/AeW+eFmVn6a8TnoGWfdo2mifMHQ+totGOqT81pjaiyZJt8RyQTG2ULMdgmxQ== X-Received: by 10.176.84.207 with SMTP id q15mr3096863uaa.177.1478907201920; Fri, 11 Nov 2016 15:33:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Fri, 11 Nov 2016 15:33:01 -0800 (PST) From: Bernard Aboba Date: Fri, 11 Nov 2016 15:33:01 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1b03b66d245d05410eeae2 Archived-At: Subject: [rtcweb] JSEP: RemoveTrack() 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, 11 Nov 2016 23:33:26 -0000 --94eb2c1b03b66d245d05410eeae2 Content-Type: text/plain; charset=UTF-8 JSEP Section 4.1.2 talks about addTrack(), but there is no equivalent section relating to removeTrack(). The current text relating to removeTrack in WebRTC 1.0 Section 5.1 is a bit confusing: "Stops sending media from sender. The RTCRtpSender will still appear in getSenders. Doing so will cause future calls to createOffer to mark the media description for the corresponding transceiver as recvonlyor inactive, as defined in [JSEP ] (section 5.2.2. )." [BA] Since the above text refers to future calls marking the media description, this sounds a lot like a call to setDirection("recvonly") or setDirection("inactive"). However, this would not result in the sender immediately stopping the sending of media. Since removeTrack is reversible, I would presume it is not equivalent to transceiver.stop() which would be permanent. While setting the encodings[].active attribute to false would stop sending, that would seem inconsistent with the reference to future calls, which seems to lean more towards setting the direction of the transceiver. --94eb2c1b03b66d245d05410eeae2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
JSEP Section 4.1.2 talks about addTrack(), but there is no= equivalent section relating to removeTrack().=C2=A0

The= current text relating to removeTrack in WebRTC 1.0 Section 5.1 is a bit co= nfusing:

"Stops sending media from=C2=A0= sen= der. The=C2=A0RTCRtpSender=C2=A0will still appear in=C2=A0<= code style=3D"color:orange;font-size:0.9em;font-family:menlo,consolas,"= ;dejavu sans mono",monaco,monospace">getSenders. Doing so will ca= use future calls to=C2=A0= createOffer=C2=A0to mark the=C2=A0media descript= ion=C2=A0for the corresponding transceiver as=C2=A0recvonlyor=C2=A0inactive, as defined in=C2=A0[JSEP] (section 5.2.2.)."

[BA] Since the above text refers to future calls ma= rking the media description, this sounds a lot like a call to setDirection(= "recvonly") or setDirection("inactive").=C2=A0 However,= this would not result in the sender immediately stopping the sending of me= dia.

Since removeTrack is reversible, I = would presume it is not equivalent to transceiver.stop() which would be per= manent.=C2=A0 While setting the encodings[].active attribute to false would= stop sending, that would seem inconsistent with the reference to future ca= lls, which seems to lean more towards setting the direction of the transcei= ver.
--94eb2c1b03b66d245d05410eeae2-- From nobody Fri Nov 11 16:55:50 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 88F20129CDF for ; Fri, 11 Nov 2016 16:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 rJwx2MMkcIay for ; Fri, 11 Nov 2016 16:55:45 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 380961297F7 for ; Fri, 11 Nov 2016 16:55:45 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id c47so19371030qtc.2 for ; Fri, 11 Nov 2016 16:55:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7DakAV75zE5rJ/MhBG3u306XCv4V7jUQSFSjoF1d8+E=; b=kRX3tsnKcZUu28jeNcMhywwz/aZH+CMr+4CqxVxszFFqIavPYtSnyt9ESH+x2G4Dyt AnSzpVes1AGwaCcBLt0MvhvM5Ihw9N/BlrWZnna5E6HHljCiF1vnSbm+8slzO6oZfH7U i9gWPyJ5GOjmszhNSjf5XibMRfoRE+vGp5Hf5exvF2fUeTd3vFrrqtll8Z3/Zh/wW9U9 yuNttjTLfW0O1p9r76wrVqUCj99OnwPjBDgkjdfD+SJRWys+A83AfyxR2KU7ET4Oo7vK T4sm+9RMrpi/LmhQ6jw1Z1ycE9l9CwMBVmnq+gnFzMgNeeBA7e04NZj11lzvvy2C81S8 /rOg== 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=7DakAV75zE5rJ/MhBG3u306XCv4V7jUQSFSjoF1d8+E=; b=mtLw0uZZhvojh5tQpRklHCdnXSOKWrm36gf0yy2IIZPgMeFdiBDGh4PilhtcpvNmg8 a70BYeu9oQPV0SwIdCEEIkgHQ4wic2YyyyjlljQwXngp1FDMFlaODGzHCR4VfbG9Oo4q R5NnR+7csqBBvdd5orq5d2Wm6FyCiPhAnqcMk3veg9Pl0CHt9jWwa4NRMYDD+NNiJS4g ufAtkLciZWDJ+xxsqjN6CxcYUzfQwyABKI7S5aNGYjZ2eMOpnAEOUtsrDPQP3mbpsh72 ggcns8i0usK35bHM8+gxRPHk7W3UabmQd8L0/4g/fY2Kgz9mXxz0FzjjG6azNJvrK09+ b9Sg== X-Gm-Message-State: ABUngveZTOs5ra9AOjK3uw+ZdRJkZqV8iF9FSpDFmINkl+Fk6pd9x40bM/x0zAxVp+5ulQx9URJ7raHYPIpdiIx4 X-Received: by 10.237.35.60 with SMTP id h57mr1535665qtc.245.1478912144130; Fri, 11 Nov 2016 16:55:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.41.134 with HTTP; Fri, 11 Nov 2016 16:55:43 -0800 (PST) In-Reply-To: References: From: Taylor Brandstetter Date: Fri, 11 Nov 2016 16:55:43 -0800 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a113e5ef401a39b0541101178 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: When the "current direction" changes 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, 12 Nov 2016 00:55:48 -0000 --001a113e5ef401a39b0541101178 Content-Type: text/plain; charset=UTF-8 I'd expect the new "currentDirection" attribute to represent the direction in the last applied answer. So it would only change in the last step of the two examples. However, I don't think there's a 1:1 mapping between currentDirection and "is sender sending/is receiver receiving". After a sendrecv or recvonly offer is applied, we MUST be prepared to receive media, before an answer is received. And I'd somewhat expect that after a recvonly or inactive offer is applied, we should stop sending media (step 3 of example 1; Chrome currently works this way). Though I can't find anything explicitly stating this in RFC3264. On Fri, Nov 11, 2016 at 3:13 PM, Bernard Aboba wrote: > According to WebRTC 1.0 Section 5.4 (and JSEP Section 4.2.3) > setDirection() does not take effect immediately: > > "The setDirection method sets the direction of the RTCRtpTransceiver. > Calls to setDirection() do not take effect immediately. Instead, future > calls to createOffer and createAnswer mark the corresponding media > description as sendrecv, sendonly, recvonly or inactive as defined in > [JSEP] (section 5.2.2. and section 5.3.2.). Calling setDirection() sets the > negotiation-needed flag." > > My understanding is that setDirection immediately sets the > transceiver.direction attribute, but that the "current direction" (distinct > from the direction attribute) is only changed by calls to > setLocal/setRemoteDescription. > > The question is when the "current direction" changes, and how this relates > to the direction expressed in the currentLocalDescription and > currentRemoteDescription. Some concrete examples: > > Example 1 > > 1. The direction provided in the currentLocalDescription (e.g. the > "current direction") is "sendrecv" and setDirection("recvonly") is called. > Since setDirection does not change currentLocalDescription, the RtpSender > does not stop sending, correct? > 2. createOffer() is called. A "recvonly" offer is generated. > 3. setLocalDescription(RecvOnlyOffer) is called. Now the direction in > pendingLocalDescription changes to "recvonly", but the direction in > currentLocalDescription is still "sendrecv". The RtpSender still does not > stop sending, correct? > 4. setRemoteDescription(SendOnlyAnswer) is called. Now the direction > in currentLocalDescription is "recvonly". So, the RtpSender will now stop > sending, right? > > > Example 2 > > > 1. The value of transceiver.direction is "sendrecv" and a "sendonly" > offer is received so that setRemoteDescription(SendOnlyOffer) is > called. Since this does not change currentLocalDescription (still > "sendrecv"), the RtpSender does not stop sending, correct? > 2. createAnswer() is called. A "recvonly" answer is generated. > RtpSender is still sending. > 3. setLocalDescription(RecvOnlyAnswer) is called. Now the direction in > currentLocalDescription changes to "recvonly", so the RtpSender stops > sending, right? > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a113e5ef401a39b0541101178 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd expect the new "currentDirection" attrib= ute to represent the direction in the last applied answer. So it would only= change in the last step of the two examples.

However, I= don't think there's a 1:1 mapping between currentDirection and &qu= ot;is sender sending/is receiver receiving". After a sendrecv or recvo= nly offer is applied, we MUST be prepared to receive media, before an answe= r is received. And I'd somewhat expect that after a recvonly or inactiv= e offer is applied, we should stop sending media (step 3 of example 1; Chro= me currently works this way). Though I can't find anything explicitly s= tating this in RFC3264.

On Fri, Nov 11, 2016 at 3:13 PM, Bernard Aboba <b= ernard.aboba@gmail.com> wrote:

According to WebRTC 1.0 Section 5.4 (and JSEP Section 4.2.3) setDirectio= n() does not take effect immediately:

"The setDirection method sets the direction of = the RTCRtpTransceiver. Calls to setDirection() do not take effect immediate= ly. Instead, future calls to createOffer and createAnswer mark the correspo= nding media description as sendrecv, sendonly, recvonly or inactive as defi= ned in [JSEP] (section 5.2.2. and section 5.3.2.). Calling setDirection() s= ets the negotiation-needed flag."

My understanding is that setDirection immediately s= ets the transceiver.direction attribute, but that the "current directi= on" (distinct from the direction attribute) is only changed by calls t= o setLocal/setRemoteDescription.

The question is when the "current direction" ch= anges, and how this relates to the direction expressed in the currentLocalD= escription and currentRemoteDescription.=C2=A0 Some concrete examples:=C2= =A0

Example 1

  1. The direction provided= in the currentLocalDescription (e.g. the "current direction") is= "sendrecv" and setDirection("recvonly") is called. Sin= ce setDirection does not change currentLocalDescription, the RtpSender does= not stop sending, correct?
  2. createOffer() is called. A "recvonly" = offer is generated.
  3. setLocalDescription(RecvOnlyOffer) is called. Now t= he direction in pendingLocalDescription changes to "recvonly", bu= t the direction in currentLocalDescription is still "sendrecv".= =C2=A0 The RtpSender still does not stop sending, correct?
  4. setRemoteDescript= ion(SendOnlyAnswer) is called. Now the direction in currentLocalDescri= ption is "recvonly".=C2=A0 So, the RtpSender will now stop sendin= g, right?

=
Example 2<= /font>

=
  1. The value of = transceiver.direction is "sendrecv" and a "sendonly" of= fer is received so that setRemoteDescription(SendOnlyOffer) is called.= Since this does not change currentLocalDescription (still "sendrecv&q= uot;), the RtpSender does not stop sending, correct?
  2. createAnswer() is called.=C2=A0 A "r= ecvonly" answer is generated.=C2=A0 RtpSender is still sending.
    3. setLocalDescription(= RecvOnlyAnswer) is called. Now the direction in currentLocalDescription cha= nges to "recvonly", so the RtpSender stops sending, right?

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

--001a113e5ef401a39b0541101178-- From nobody Sat Nov 12 05:58:49 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 95EE61294E9 for ; Sat, 12 Nov 2016 05:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 DmJnMBjzWft3 for ; Sat, 12 Nov 2016 05:58:44 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464651293F8 for ; Sat, 12 Nov 2016 05:58:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 661CC7C3B99 for ; Sat, 12 Nov 2016 14:58:42 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XH5l0yFrhHrv for ; Sat, 12 Nov 2016 14:58:40 +0100 (CET) Received: from [10.53.206.103] (unknown [88.128.80.102]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0FF407C3B98 for ; Sat, 12 Nov 2016 14:58:40 +0100 (CET) To: rtcweb@ietf.org References: From: Harald Alvestrand Message-ID: Date: Sat, 12 Nov 2016 14:58:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] PR-Answer (Re: Working Group Last Call: JSEP) 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, 12 Nov 2016 13:58:46 -0000 (Changing subject to reflect the specific point raised) On 11/08/2016 07:43 PM, Philipp Hancke wrote: > Am 21.10.2016 um 21:25 schrieb Ted Hardie: >> The chairs would like to start a working group last call on >> draft-ietf-rtcweb-jset-17 to end on November 9th, 2016, 17:00 KST. >> >> Please review thoroughly, as working through the last comments will >> be the >> major effort of our working group meeting in Seoul. > > One question: why is pranswer still in there? The major use-case for > this seems to be transport warm-up (4.1.7.1) for which I think > transceivers are the new way as shown in > http://w3c.github.io/webrtc-pc/#simple-peer-to-peer-example-with-warm-up > > pranswer has not seen much traffic on this list. Together with BUNDLE > it seems to have been broken in Chrome since 2014 if I understand > https://bugs.chromium.org/p/webrtc/issues/detail?id=3349 correctly. > And I recall it being broken in 2013 when using DTLS. I can't speak to whether it's broken in general or in a subset of cases, but the demo at https://webrtc.github.io/samples/src/content/peerconnection/pr-answer/ still works. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From nobody Sat Nov 12 23:14: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 54BC01295BE for ; Sat, 12 Nov 2016 23:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 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, T_FILL_THIS_FORM_SHORT=0.01] 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 hxAlIgVgjnrY for ; Sat, 12 Nov 2016 23:14:43 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 F18C9129465 for ; Sat, 12 Nov 2016 23:14:42 -0800 (PST) X-AuditID: c1b4fb30-dc07098000007ca6-45-582812e1b9bc Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 1C.F3.31910.1E218285; Sun, 13 Nov 2016 08:14:41 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.319.2; Sun, 13 Nov 2016 08:13:40 +0100 To: Ted Hardie , "rtcweb@ietf.org" , Alissa Cooper , Cullen Jennings , Sean Turner References: From: Magnus Westerlund Message-ID: <40497c7e-2c2a-d137-93f4-ff657e77b8fd@ericsson.com> Date: Sun, 13 Nov 2016 16:13:34 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM2K7me5DIY0Ig/erxS2mn/nLaNExmc1i 7b92dosrqxqZLRrn2jmwekz5vZHV48uTl0weO2fdZfdYsuQnk8fBg4wBrFFcNimpOZllqUX6 dglcGc8O72MtmJtb0XthPVMD46PgLkZODgkBE4nX65tZuhi5OIQE1jFKTGm4wQjhLGeU2Dd1 GRNIlbCAscSx7d/AEiICGxkldl36yQqSEBIIkJjd/pUFxGYTsJC4+aORDcTmFbCXuLT/OjuI zSKgKnH+8FswW1QgRuL6s0dQNYISJ2c+AevlFAiUmLWkAcjm4GAG6n2wtQwkzCwgL9G8dTYz xCptiYamDtYJjPyzkHTPQuiYhaRjASPzKkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzAoD24 5bfBDsaXzx0PMQpwMCrx8G5IU48QYk0sK67MPcQowcGsJMJ7mU8jQog3JbGyKrUoP76oNCe1 +BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQbGGYqaNXbSznv3z/vMtGEe78fc9Y0q mp8+J2zOYZkU4Hy631w2jefxz8Xeu1g0hcK6Ctd3VCdzfd4ZNm/uy39LkiWS5986o93ILJtU 1bf8u8r83uMufn6fmL9s7Iyf6C+7/bp9j3qv8YXNOcveVWfkXjoWeOZSoOie9QfPMLR0br+y v+Fb5K8vSizFGYmGWsxFxYkAzEKENlYCAAA= Archived-At: Subject: Re: [rtcweb] Working Group Last Call: JSEP 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: Sun, 13 Nov 2016 07:14:45 -0000 Hi, As I am late, and we are having the discussion tomorrow I am taking the easiest route for me to get my feedback out to the WG and authors, thus an email rather than Github issues. So here are my comments on the -17 version of JSEP. 1. Terminology: m= section. I would propose that the document creates a terminology section and are explicit that m= section and SDP Media Description are the same thing. 2. There are a couple of terms that would really need a definition and also possibly some reflection of how they relate to the RTCWeb terms, like WebRTC Endpoint. So the terms I really like defined are: JSEP endpoint JSEP implementation 3. Section 3.6: JSEP implementations will not transmit non-square pixels, but SHOULD receive and render such video with the correct aspect ratio. I have two issues with this. First of all, shouldn't JSEP implementations be WebRTC endpoints? The second is these statement that says that a JSEP/WebRTC foo will not do a thing. In most cases that is not necessary, as there would be no issues if a particular implementation supports this functionality. So, I think this should be written as: WebRTC endpoints does not need to support transmission of non-square pixels, but SHOULD receive and render such video with the correct aspect ratio. 4. Section 3.6.2: When communicating with a non-JSEP endpoint, multiple relevant "a=imageattr recv" attributes may be received. If this occurs, attributes other than the one with the highest "q=" value MUST be ignored. There is to my knowledge nothing preventing multiple parameters sets to have the same preference value (q). Thus, the formulation of this sentence needs to be addressed. 5. Section 3.6.2: If an "a=imageattr recv" attribute references a different video codec than what has been selected for the MediaStreamTrack, it MUST be ignored. So, to my understanding there can be multiple video codecs and multiple RTP PTs that have been negotiated as possible to use. Is selected just the single currently used one, one or all the possible ones here? 6. Section 3.6.2: If the attribute includes a "sar=" (sample aspect ratio) value set to something other than "1.0", indicating the receiver wants to receive non-square pixels, this cannot be satisfied and the sender MUST NOT transmit the track. Another instances where the language should allow for flexibility if an implementation goes beyond the defined mandatory support. Changing "this cannot be" to "if this cannot be" may resolve it. Also, isn't the relevant "MUST NOT" is to not accept this in the negotiation? 7. Section 3.7: JSEP supports simulcast of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section. I think this should be explcit that it is "simulcast transmission of a MediaStreamTrack". 8. Section 5.1.1: This list of mandatory-to-implement specifications is derived from the requirements outlined in [I-D.ietf-rtcweb-rtp-usage]. R-5 [RFC4568] MUST NOT be implemented to signal SDES SRTP keying information. So, the list of mandatory-to-implement includes also some to not implement. That is fine, but probably should be moved to its own list, or rename the list so that it can contain both types. Secondly, this specific requirement I think comes from the security docs, rather than rtp-usage. 9. Section 5.1.1: R-2 [RFC5764] MUST be supported for signaling the UDP/TLS/RTP/SAVPF [RFC5764], TCP/DTLS/RTP/SAVPF [I-D.nandakumar-mmusic-proto-iana-registration], "UDP/DTLS/ SCTP" [I-D.ietf-mmusic-sctp-sdp], and "TCP/DTLS/SCTP" [I-D.ietf-mmusic-sctp-sdp] RTP profiles. I would note that [I-D.nandakumar-mmusic-proto-iana-registration] is actually published as RFC 7850. 10. Section 5.1.1: R-12 [RFC5761] MUST be implemented to signal multiplexing of RTP and RTCP. This should include the updated as ref also. 11. Section 5.1.1: R-15 [RFC3556] with bandwidth modifiers MAY be supported for specifying RTCP bandwidth as a fraction of the media bandwidth, RTCP fraction allocated to the senders and setting maximum media bit-rate boundaries. So, why wasn't support of RR and RS bandwidth modifiers made a MUST? Secondly, the RR and RS attributes do not specify the bandwidth as fraction of the media bandwidth. The specify RTP session level limits for RTCP bandwidth. 12. Section 5.1.1: R-16 TODO: any others? Please remove this. 13. Section 5.1.3: For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/ RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of these two profiles for each media m= line they produce in an offer. Do I understand this correct, we are requiring support for the "TCP/DTLS/RTP/SAVPF" proto so that in cases an endpoint supports the optional to support ICE TCP, they can indicate it, and any WebRTC endpoint will accept it, even if that is just one option? I do know that different profiles are a negotiation issue. But, wouldn't it be more reasonable in this case to use UDP/TLS/RTP/SAVPF in all cases where one offer any candidates that also use UDP? And only use TCP/DTLS/RTP/SAVPF in cases only TCP candidates are signalled, thus not forcing TCP/DTLS/RTP/SAVPF onto clients that doesn't support it? 14. Section 5.1.3: Otherwise, assume that AVPF is being used in an AVP compatible mode and use AVP timing, i.e., "trr-int=4". I find this sentence confusing. I think this should be clarified to say: Otherwise, assume that AVPF is being used in an AVP compatible mode, i.e. use AVPF timing configured with a "trr-int=4". 15. Section 5.1.3: Spurious space in: For data m= sections, JSEP endpoints MUST support receiving the "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards compatibility) profiles. 16. Section 5.2.1: o Session Information ("i="), URI ("u="), Email Address ("e="), Phone Number ("p="), Bandwidth ("b="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. Considering that b=CT is not useless, I am a bit surprised to see b= on this list. Yes, b=CT: is only useful is one like to provide a upper total bandwidth limitation. So, maybe some discussion of the possible choice? 17. Section 5.2.1: This is done in the order that their associated RtpTransceivers were added to the PeerConnection and excludes RtpTransceivers that are stopped and not associated with an m= section (either due to an m= section being recycled or an RtpTransceiver having been stopped before being associated with an m= section) . I am bit surprised to see "recycled" on a list of things that may occur in generating an initial offer? Can that really occur? 18. Section 5.2.1: o An "a=mid" line, as specified in [RFC5888], Section 4. When generating mid values, it is RECOMMENDED that the values be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 11. Just to note that to my understanding we are having discussion if this should be referencing a more specific generation algorithm. Such a change is likely to affect text on RID also: 19. Section 5.2.1: The list of RTCP feedback mechanisms that SHOULD/MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. I would request that we don't use the quite confusing "SHOULD/MUST" and instead write something like: mechanisms that are recommended or mandated to be supported 20. Section 5.3.1: o If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the maximum supported frame sizes out of all codecs included above, as specified in [RFC4566], Section 6. In most cases the maxptime attribute doesn't affect the frame size of the encoder, instead it affects the maximum amount of media that are packetized into a RTP payload, i.e. how many frames that are included. 21. Section 5.3.1: Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or TRANSPORT): I react to "bundle into another m= section". I though they where "bundled with"? 22. Section 5.7.2: o If present, a single "a=rtcp" attribute MUST be parsed as specified in [RFC3605], Section 2.1, but its value is ignored, as this information is superfluous when using ICE. This is another case, where there is an exception to what is written if one has supports the non RTP/RTCP mux usage. Thus, this should be ammended to included such an exception. 23. Section 5.7.2: What about additional a= attributes? Any attribute supported by the implementation MAY be parsed? 24. Section 5.8: + Find the RtpTransceiver that corresponds to the m= section with the same MID in the created offer. + Set the value of the RtpTransceiver's mid attribute to the MID of the m= section. I find this text strange. If you already know the MID, why is it being set in the second sub-bullet? 25. Section 5.8: * If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in [RFC5761], Section 5.1.1. If RTCP mux is not indicated, but was indicated in a previous description, this MUST result in an error. I note that there can be difference here between an offer and an answer if the RTCP mux indication may have changed or not between these two description. 26. Section 5.9: o For any specified "CT" bandwidth value, set this as the limit for the maximum total bitrate for all m= sections, as specified in Section 5.8 of [RFC4566]. The implementation can decide how to allocate the available bandwidth between m= sections to simultaneously meet any limits on individual m= sections, as well as this overall session limit. I think this text can be improved to make it clearer that CT doesn't imply a fixed over time divide of the bandwidth between RTP streams. As long as individual media sources streams stay within other requirements such as b=AS/TIAS they can be changed dynamically. 27. Section 5.10: * If the media section has RTCP mux enabled, discard any RTCP component, and begin or continue muxing RTCP over the RTP component, as specified in [RFC5761], Section 5.1.3. Otherwise, prepare to transmit RTCP over the RTCP component; if no RTCP component exists, because RTCP mux was previously enabled, this MUST result in an error. I think this should say "any RTCP ICE component".. 28. Section 5.10: When sending RTCP feedback, use the SSRC of an outgoing Source RTP Stream as the RTCP sender SSRC; if no outgoing Source RTP Stream exists, choose a random one. This is okay, but could be slightly more open in regards to sending feedback packets efficiently. Section 5.4.1 in https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream/?include_text=1 is providing more detailed rules for things to consider. 29. Section 6: If any payload type could map to more than one RtpReceiver, map to the RtpReceiver whose m= section appears earliest in the local description. I think this is a bad advice. I think it should say that if this is the case, PT should not be used to try to determine which m= section it belongs to. I think wrongly attributing a packet is worse than dropping it in cases where the information is incomplete. This rule can result in that one associate an SSRC with the wrong m= section. 30. Section 6: If the packet has a MID and that MID is in the table mapping MID to RtpReceiver, update the incoming SSRC mapping table to include an entry that maps the packet's SSRC to the RtpReceiver for that MID. This is all fine, but requires an addition. If there was already a MID associated with the SSRC, i.e. a new MID has been assigned to this SSRC, then there is deleting in the old MIDs association table that needs to happen. 31. Section 6: I think this section should be updated to work with the BUNDLE text as that matures. I understand that there are a few additional cases one likes to cover for non WebRTC endpoints, but still, lets not introduce unnecessary failure cases over that. 32. Section 6: The RTCP packet routing. This doesn't match my view of how RTCP processing happens. I think the "deliver a copy of the packet to the RtpReceiver associated with that SSRC." Is the part that I have most issues with. What I find more relevant and correct and likely matching more implementations are" deliver the information to the RtpReceiver associated with that SSRC. 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 Sun Nov 13 14:43:49 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 74F22129627 for ; Sun, 13 Nov 2016 14:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 OMee_ugBSsYy for ; Sun, 13 Nov 2016 14:43:44 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F9F129559 for ; Sun, 13 Nov 2016 14:43:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id A7A787C35C9 for ; Sun, 13 Nov 2016 23:43:42 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3794-Gb02PhG for ; Sun, 13 Nov 2016 23:43:40 +0100 (CET) Received: from [IPv6:2001:67c:370:144:7111:36fc:aa8c:75c1] (t2001067c03700144711136fcaa8c75c1.hotel-wired.v6.meeting.ietf.org [IPv6:2001:67c:370:144:7111:36fc:aa8c:75c1]) by mork.alvestrand.no (Postfix) with ESMTPSA id 32A557C35C8 for ; Sun, 13 Nov 2016 23:43:39 +0100 (CET) To: "rtcweb@ietf.org" From: Harald Alvestrand Message-ID: <3ec33eba-b130-e986-0fce-ab97f8d0e601@alvestrand.no> Date: Sun, 13 Nov 2016 23:43:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [rtcweb] HTA's review of JSEP-17 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: Sun, 13 Nov 2016 22:43:47 -0000 Long plane rides have advantages. These are my notes; I will file github issues in a few hours on the points where I think we need discussion. Overall, this draft looks almost ready to go. It seems comprehensive (sometimes mind-numbingly so), and I think we will learn little more by going over it in theory; now it's time to take the software we've written, match it up against the spec, and see if we can make them match.= That said, there are issues. Some of which I have noted below. - Agree with Magnus on the need for a terminology section. It would be nice to choose just one out of "media section" vs "m=3D section", but if you really want both, please define the two terms as being equal. - Section 1.1: Leftover mention of modifying the offer before doing set-local-description. The text should instead say "inspect, and if you don't like it, change settings and iterate". - Section 3.6: "all dimensions assume square pixels". Given the affordance for non-square pixels elsewhere, I think this should say "all dimensions are measured in pixels, whether square or not". - Section 3.6.1 describes mandatory constraints applied to an incoming track resulting in a new offer-answer exchange. Since this is "action at a distance" (modify the track and the PeerConnection emits a negotiation-needed), I think this needs to be synced with the webrtc-1.0 API spec, and possibly even media-capture. Also, what's the state of the track between the changing of constraints at the receiver and the renegotiation? It seems to me that the track should be scaled at the receiver to fit the agreed-upon constraints. - Section 3.6.1 "no resolutions .. SHOULD be represented by x=3D0 and y=3D= 0 values". Is there any reason not t o make this a MUST? - Section 3.6.1 gives an example with a minimum resolution of 16x16 - where did that come from? If we want to admit to the existence of macroblocks, we may want to say that the implementation can specify step sizes (typically 16) in its imageattr values. - Section 3.7 Simulcast - I'm not sure it's true that the information about number of layers is not surfaced through any API - the number of elements in the encoding list, and their active/passive state, which is accessible through getSettings(), should surely give a hint about this. - Section 3.8.2 - "the media flow from these sessions can be managed by specifying SDP direction attributes in the descriptions". This seems out of place. Surely flipping track.muted is a much simpler way of managing them if the problem is what to play to the user? - Section 4.1.1 - the description of "relay" - is it worth noting that the degre of obfuscation is under the control of the application based on its choice of turn servers? And that browser-configured turn servers also matter here? - Section 4.1.2 addTrack: Worth noting that using addTransceiver in have-remote-offer will cause negotiaiton-needed to be fired when the track returns to stable? - Section 4.1.5 createOffer: The statement about this being async is either a requirement or out of scope. I'd suggest out of scope (it is purely an API property); the alternative is saying "it is an async operation". - Section 4.1.7.1 - the term "inactive" final answer is introduced without a defintion. Need to either define "inactive" or use another term= =2E - Section 4.1.7.2 Rollback - "and possibly the answerer as well" is wishy-washy. Suggest "and the answerer if it has done set-remote-description". - Section 4.1.7.2 This is the first mention of "pending local / remote description". Suggest link to definition. - Section 4.1.7.2 "RTPTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed". The term "removed" is undefined. Deleted, discarded, destroyed or detached from the PeerConnection? Suggestion: "stopped and removed from the PeerConnection". (if the JS app still has a reference to them, it may still inspect the object). - Section 4.1.8 setLocalDescription - "the PeerConnection must be able to simultaneously support... until a final answer is received". This is unclear for several reasons - suggest "while the connection is in the have-local-offer or have-remote-pranswer state". (There's a race condition here between media and signalling, of course.) - Section 4.1.10 currentLocalDescription - "a copy of the current negotiated local description" is ambiguous (see issue raised in webrtc-1.0 - https://github.com/w3c/webrtc-pc/issues/921). Suggest making language here less normative - "shows the current negotiated local description" would probably be weak enough. - Section 4.1.15 setConfiguration - "and may result in a change to media state". Not sure this belongs here - it can lead to a cascade of events that may end up changing media state, but it is not the call that directly causes the change. Suggest deleting. - Section 4.1.16 addIceCandidate - suggest deleting the "end-of-candidates" text here, and saying separately that there is a means of indicating end of candidates. There seems to be consensus that mixing the two was an API design mistake, discussions are about how to get out of it. - Section 4.2.4 setCodecPreferences - "However, the codec preferences cannot change the order of the media formats after an answer containing the transceiver has been applied". I don't understand why we can't change the order in order to have the new order reflected on the next offer/answer exchange - there would be no immediate effect, but the current language locks in the order permanently, without a clear justification for why it has to be that way. - Sction 5.1.1 R-16: TODOs should be deleted before Last Call :-) Also sugggest renumbering the trailing sentence as R-16. - Section 5.1.2: Suggest using a different letter on the numbering. U-1 and U-2? - Section 5.2.1 "an m=3D section being recycled" - first use of term "recycled". Link? - Section 5.2.1 CreateOffer "given that no candidates have yet been gathered" - when people remember the pre-gathered candidate pool, this can be confusing. Suggest adding a note at the top of this section saying that CreateOffer doesn't cause candidate gathering and does not take candidates from the pre-gathered pool, and thus, no candidates are available at the initial call to CreateOffer. All subsequent references to "no candidates have yet been gathered" in this section should be replaced with "no candidates are available". - Section 5.2.1 bullet 2 (first list) references use of the default candidate (which doesn't exist here). Suggest saying "UDP/TLS/RTP/SAVPF" and moving the default candidate language to subsequent offers. - Section 5.2.1 CreateOffer - bullet on imageattr - limits on images that can be decoded - suggest adding text that this is also included on recvonly lines because direction of lines can change. - Section 5.2.1 "The following attributes ... MUST appear only in "m=3D" sections which either have a unique address or which are associated with the bundle-tag". This is different from BUNDLE 8.1 - they should either say the same thing or have a clear explanation of the difference. - Section 5.2.1 "a=3Dfingerprint" - needs rewriting for the multiple-fingerprint-algorithm case (4572bis). Issue already filed? - Section 5.2.2 Subsequent offers - is there any reason to allow NOT incrementing the session-version? - Section 5.2.2 The example of rollback doesn't make sense - it works if "an offer is created with version N+1" is replaced with "an offer is created with version N+1 and installed with SetLocalDescription" - Section 5.2.2 recycling of zero-port m-lines - should it specify that the new m=3D section MUST have a different mid than the replaced m=3D sec= tion? - Section 5.2.2 "the following adjustments are made based on the content of the corresponding m=3D section in the current remote description" - needs to be contained by "if there is a current remote description". - Section 5.3.1 I'm unsure about the language on lipsync groups. I can't figure out without more careful analysis if it works for the case of 1A+1V replying to 1A+1V - in almost any other case, I think the result is that answer doesn't have LS groups. - Section 5.3.1 needs the same kind of intro as the previous one about no candidates being available even if gathered. - Section 5.3.2 Subsequent answers - like SetCodecPreference, this also cements initial priority. Why? - Section 5.7.1 Session-level parsing, b=3D lines: This is the first time= they're mentioned. Is there an affordance for adding them when generating offers/answers? I didn't catch any language like "add any other field you feel like", but I may have overlooked it. - Section 5.8 Applying a local description - on errrors, "processing MUST stop and an error MUST be returned" - should it also say that the state of the PC needs to be returned to the pre-apply-LD state? - Section 5.8 - "begin gathering candidates for it" - or take them from the pool. - Section 5.8 - style: a bullet starting with "if" and a next bullet starting with "or" is awkward. - Section 5.9 - "AS must be ignored" - should also apply to TIAS? - Section 5.9 "If more accurate control of bandwidth is needed, TIAS should be used" - this is the wrong place for that statement, we're not choosing here. If this is wanted, just write "TIAS gives more accurate control of bandwidth than AS". - Section 5.10 "If the media section has been rejected ... discard any associated ICE components". Only if it's not a bundled section. - Section 5.10 in general - there are a lot of bullets that apply only to M-sections that designate a transport. Should those bullets be broken out in a separate list? - Section 5.10 - "If no outgoing Source RTP stream exists, choose a random one" - "one" should be "SSRC" for clarity. - Section 6: "this is only a strawman" language needs deleting. We're in WG Last Call. - Section 6: For tables where many-to-one mappings are expected (such as SSRC to receiver when simulcast, RTX or FEC is active), it might be worth noting this. For tables where many-to-one is an error (such as MID to RTPReceiver), it might be worth noting that too. - Section 6: "If the packet's payload type is in the payload type table, update.." - this will have interesting consequences ("last one wins") if the sender sends two streams with the same PT and different SSRCs. Suggest discarding packets where a SSRC->Receiver mapping already exists for that PT. This gives issues when changing SSRC for a stream; tradeoff needs evaluating. That's all - no comments on examples :-) - --=20 Surveillance is pervasive. Go Dark. From nobody Sun Nov 13 17:16:59 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 E3AC512965E for ; Sun, 13 Nov 2016 17:16:56 -0800 (PST) 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 Z1wmucPPeMsf for ; Sun, 13 Nov 2016 17:16:54 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33A71295F0 for ; Sun, 13 Nov 2016 17:16:53 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id w33so39262791qtc.3 for ; Sun, 13 Nov 2016 17:16:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C3F+5d0Z8M95gQ3OsuD/z0UK1DHzBabPbrHCKirw2Uo=; b=av5BCu9pLFjzGn4Nm5f/1PguXRiSz56WPIbBulScagdfwduOKihZzIEfkQQKTGwsIV 4rkVsP6V9lm8Xkw49bywyGGq8E4qKxwmHX+nOfKN1D0PETg5iIU29yVtRz4a18TW4TPB rT0BVjXSUhRXy1G0R0Kj7bbR2Kxw7PZ/tgYYQ9gjv0hPOj2ZjewNQjHwqQeDqQ0vAWPp MuM7q+LyUkIWRzq1u3yEhjK0vb0oyv/gZTIqMeBegiuP9qAn5ikpwK+1NoKeQ+7MCrgS mIuvGO1lJfdJb14VoHvVA+frqjqa2w79taJgUq81GRXxZbPHruDecYrZENOWKppwyGtK +TnA== 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=C3F+5d0Z8M95gQ3OsuD/z0UK1DHzBabPbrHCKirw2Uo=; b=Edg5O4B8FZrCPdjAHKvtzWrfxi6UUdYoCWSJrCUje4iNoVPgFy6AKlHLtki2nLGSOf as6VQssRSh3rrmqNDNpjVB66qVssEfBoGsB1VKibWlQ9T2opRrP/s9gzDKI0CbDohXby PlkWpL66lAk0GN+Mr+jEsHkvb2s981yB0ryNOp+/V0MhbIegtaNWfz87AkXA7sbq5/9b CeG8r1eyuP9tA86MEPGeDoGvBc/dVa5jEOTPz3vonNcopU5dkRAu4jOkIYoIe2WIpdbg AYZiPf4lYfOzbiOuRrn2IdkWfwrjGGjs907IigWqjTwvrZoFvUT5OjSpRdgKuX5WcwdB RvmA== X-Gm-Message-State: ABUngvdz+U0rDCfXEx+DAVSoJzV6Bh0cNcaxeIZiE61qvs6viCBHi2/7fXBUdfQWMdxljj9ojUIg0VqpVB26mw== X-Received: by 10.200.37.221 with SMTP id f29mr10047978qtf.123.1479086212979; Sun, 13 Nov 2016 17:16:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.165.100 with HTTP; Sun, 13 Nov 2016 17:16:22 -0800 (PST) In-Reply-To: <40497c7e-2c2a-d137-93f4-ff657e77b8fd@ericsson.com> References: <40497c7e-2c2a-d137-93f4-ff657e77b8fd@ericsson.com> From: Ted Hardie Date: Mon, 14 Nov 2016 10:16:22 +0900 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a113f41a851233f054138989e Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working Group Last Call: JSEP 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, 14 Nov 2016 01:16:57 -0000 --001a113f41a851233f054138989e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Magnus, I've added github issues for most of these in the range 387 to 408. The two final issues here (numbers 31 and 32), both related to section 6, weren't really clear enough for me to provide a useful summary. Can you try to rephrase those? It would be great if you can do that by adding them to the issues list, but I'll try to add them if you update them here. thanks, Ted On Sun, Nov 13, 2016 at 4:13 PM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > As I am late, and we are having the discussion tomorrow I am taking the > easiest route for me to get my feedback out to the WG and authors, thus a= n > email rather than Github issues. > > So here are my comments on the -17 version of JSEP. > > 1. Terminology: m=3D section. I would propose that the document creates a > terminology section and are explicit that m=3D section and SDP Media > Description are the same thing. > > 2. There are a couple of terms that would really need a definition and > also possibly some reflection of how they relate to the RTCWeb terms, lik= e > WebRTC Endpoint. So the terms I really like defined are: > > JSEP endpoint > JSEP implementation > > 3. Section 3.6: > > JSEP > implementations will not transmit non-square pixels, but SHOULD > receive and render such video with the correct aspect ratio. > > I have two issues with this. First of all, shouldn't JSEP implementations > be WebRTC endpoints? The second is these statement that says that a > JSEP/WebRTC foo will not do a thing. In most cases that is not necessary, > as there would be no issues if a particular implementation supports this > functionality. So, I think this should be written as: > > WebRTC endpoints does not need to support transmission of non-square > pixels, but SHOULD > receive and render such video with the correct aspect ratio. > > 4. Section 3.6.2: > > When communicating with a non-JSEP endpoint, multiple relevant > "a=3Dimageattr recv" attributes may be received. If this occurs, > attributes other than the one with the highest "q=3D" value MUST be > ignored. > > There is to my knowledge nothing preventing multiple parameters sets to > have the same preference value (q). Thus, the formulation of this sentenc= e > needs to be addressed. > > 5. Section 3.6.2: > > If an "a=3Dimageattr recv" attribute references a different video code= c > than what has been selected for the MediaStreamTrack, it MUST be > ignored. > > So, to my understanding there can be multiple video codecs and multiple > RTP PTs that have been negotiated as possible to use. Is selected just th= e > single currently used one, one or all the possible ones here? > > 6. Section 3.6.2: > > If the attribute includes a "sar=3D" (sample aspect ratio) value set t= o > something other than "1.0", indicating the receiver wants to receive > non-square pixels, this cannot be satisfied and the sender MUST NOT > transmit the track. > > Another instances where the language should allow for flexibility if an > implementation goes beyond the defined mandatory support. Changing "this > cannot be" to "if this cannot be" may resolve it. Also, isn't the relevan= t > "MUST NOT" is to not accept this in the negotiation? > > 7. Section 3.7: > > JSEP supports simulcast of a MediaStreamTrack, where multiple > encodings of the source media can be transmitted within the context > of a single m=3D section. > > I think this should be explcit that it is "simulcast transmission of a > MediaStreamTrack". > > 8. Section 5.1.1: > > This list of mandatory-to-implement specifications is derived from > the requirements outlined in [I-D.ietf-rtcweb-rtp-usage]. > > R-5 [RFC4568] MUST NOT be implemented to signal SDES SRTP keying > information. > > So, the list of mandatory-to-implement includes also some to not > implement. That is fine, but probably should be moved to its own list, or > rename the list so that it can contain both types. > > Secondly, this specific requirement I think comes from the security docs, > rather than rtp-usage. > > 9. Section 5.1.1: > R-2 [RFC5764] MUST be supported for signaling the UDP/TLS/RTP/SAVPF > [RFC5764], TCP/DTLS/RTP/SAVPF > [I-D.nandakumar-mmusic-proto-iana-registration], "UDP/DTLS/ > SCTP" [I-D.ietf-mmusic-sctp-sdp], and "TCP/DTLS/SCTP" > [I-D.ietf-mmusic-sctp-sdp] RTP profiles. > > I would note that [I-D.nandakumar-mmusic-proto-iana-registration] is > actually published as RFC 7850. > > 10. Section 5.1.1: > R-12 [RFC5761] MUST be implemented to signal multiplexing of RTP and > RTCP. > > This should include the updated as ref also. > > > 11. Section 5.1.1: > > R-15 [RFC3556] with bandwidth modifiers MAY be supported for > specifying RTCP bandwidth as a fraction of the media bandwidth, > RTCP fraction allocated to the senders and setting maximum > media bit-rate boundaries. > > So, why wasn't support of RR and RS bandwidth modifiers made a MUST? > > Secondly, the RR and RS attributes do not specify the bandwidth as > fraction of the media bandwidth. The specify RTP session level limits for > RTCP bandwidth. > > 12. Section 5.1.1: > > R-16 TODO: any others? > > Please remove this. > > 13. Section 5.1.3: > > For media m=3D sections, JSEP endpoints MUST support both the "UDP/TLS= / > RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of > these two profiles for each media m=3D line they produce in an offer. > > Do I understand this correct, we are requiring support for the > "TCP/DTLS/RTP/SAVPF" proto so that in cases an endpoint supports the > optional to support ICE TCP, they can indicate it, and any WebRTC endpoin= t > will accept it, even if that is just one option? I do know that different > profiles are a negotiation issue. But, wouldn't it be more reasonable in > this case to use UDP/TLS/RTP/SAVPF in all cases where one offer any > candidates that also use UDP? And only use TCP/DTLS/RTP/SAVPF in cases on= ly > TCP candidates are signalled, thus not forcing TCP/DTLS/RTP/SAVPF onto > clients that doesn't support it? > > 14. Section 5.1.3: > Otherwise, assume that AVPF is being used in an AVP > compatible mode and use AVP timing, i.e., "trr-int=3D4". > > I find this sentence confusing. I think this should be clarified to say: > > Otherwise, assume that AVPF is being used in an AVP > compatible mode, i.e. use AVPF timing configured with a "trr-int=3D= 4". > > 15. Section 5.1.3: > > Spurious space in: > > For data m=3D sections, JSEP endpoints MUST support receiving the > "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards > compatibility) profiles. > > 16. Section 5.2.1: > o Session Information ("i=3D"), URI ("u=3D"), Email Address ("e=3D"), > Phone Number ("p=3D"), Bandwidth ("b=3D"), Repeat Times ("r=3D"), a= nd > Time Zones ("z=3D") lines are not useful in this context and SHOULD > NOT be included. > > Considering that b=3DCT is not useless, I am a bit surprised to see b=3D = on > this list. Yes, b=3DCT: is only useful is one like to provide a upper tot= al > bandwidth limitation. So, maybe some discussion of the possible choice? > > 17. Section 5.2.1: > > This is done in the order > that their associated RtpTransceivers were added to the > PeerConnection and excludes RtpTransceivers that are stopped and not > associated with an m=3D section (either due to an m=3D section being > recycled or an RtpTransceiver having been stopped before being > associated with an m=3D section) . > > I am bit surprised to see "recycled" on a list of things that may occur i= n > generating an initial offer? Can that really occur? > > 18. Section 5.2.1: > > o An "a=3Dmid" line, as specified in [RFC5888], Section 4. When > generating mid values, it is RECOMMENDED that the values be 3 > bytes or less, to allow them to efficiently fit into the RTP > header extension defined in > [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 11. > > > Just to note that to my understanding we are having discussion if this > should be referencing a more specific generation algorithm. > > Such a change is likely to affect text on RID also: > > 19. Section 5.2.1: > The list of > RTCP feedback mechanisms that SHOULD/MUST be supported is > specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. > > I would request that we don't use the quite confusing "SHOULD/MUST" and > instead write something like: > > mechanisms that are recommended or mandated to be supported > > 20. Section 5.3.1: > > o 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. > > In most cases the maxptime attribute doesn't affect the frame size of the > encoder, instead it affects the maximum amount of media that are packetiz= ed > into a RTP payload, i.e. how many frames that are included. > > 21. Section 5.3.1: > > Each m=3D section which is not bundled into another m=3D section, MUST > contain the following attributes (which are of category IDENTICAL or > TRANSPORT): > > I react to "bundle into another m=3D section". I though they where "bundl= ed > with"? > > 22. Section 5.7.2: > o If present, a single "a=3Drtcp" attribute MUST be parsed as > specified in [RFC3605], Section 2.1, but its value is ignored, as > this information is superfluous when using ICE. > > This is another case, where there is an exception to what is written if > one has supports the non RTP/RTCP mux usage. Thus, this should be ammende= d > to included such an exception. > > 23. Section 5.7.2: > > What about additional a=3D attributes? Any attribute supported by the > implementation MAY be parsed? > > 24. Section 5.8: > > + Find the RtpTransceiver that corresponds to the m=3D section > with the same MID in the created offer. > > + Set the value of the RtpTransceiver's mid attribute to the > MID of the m=3D section. > > I find this text strange. If you already know the MID, why is it being se= t > in the second sub-bullet? > > 25. Section 5.8: > > * If RTCP mux is indicated, prepare to demux RTP and RTCP from > the RTP ICE component, as specified in [RFC5761], > Section 5.1.1. If RTCP mux is not indicated, but was indicated > in a previous description, this MUST result in an error. > > I note that there can be difference here between an offer and an answer i= f > the RTCP mux indication may have changed or not between these two > description. > > 26. Section 5.9: > o For any specified "CT" bandwidth value, set this as the limit for > the maximum total bitrate for all m=3D sections, as specified in > Section 5.8 of [RFC4566]. The implementation can decide how to > allocate the available bandwidth between m=3D sections to > simultaneously meet any limits on individual m=3D sections, as well > as this overall session limit. > > I think this text can be improved to make it clearer that CT doesn't impl= y > a fixed over time divide of the bandwidth between RTP streams. As long as > individual media sources streams stay within other requirements such as > b=3DAS/TIAS they can be changed dynamically. > > 27. Section 5.10: > > * If the media section has RTCP mux enabled, discard any RTCP > component, and begin or continue muxing RTCP over the RTP > component, as specified in [RFC5761], Section 5.1.3. > Otherwise, prepare to transmit RTCP over the RTCP component; if > no RTCP component exists, because RTCP mux was previously > enabled, this MUST result in an error. > > I think this should say "any RTCP ICE component".. > > 28. Section 5.10: > When sending RTCP feedback, use the > SSRC of an outgoing Source RTP Stream as the RTCP sender SSRC; > if no outgoing Source RTP Stream exists, choose a random one. > > This is okay, but could be slightly more open in regards to sending > feedback packets efficiently. Section 5.4.1 in > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-mult > i-stream/?include_text=3D1 is providing more detailed rules for things to > consider. > > 29. Section 6: > > If > any payload type could map to more than one RtpReceiver, map to > the RtpReceiver whose m=3D section appears earliest in the local > description. > > I think this is a bad advice. I think it should say that if this is the > case, PT should not be used to try to determine which m=3D section it bel= ongs > to. I think wrongly attributing a packet is worse than dropping it in cas= es > where the information is incomplete. This rule can result in that one > associate an SSRC with the wrong m=3D section. > > 30. Section 6: > If the packet has a MID and that MID is in the table mapping MID > to RtpReceiver, update the incoming SSRC mapping table to include > an entry that maps the packet's SSRC to the RtpReceiver for that > MID. > > This is all fine, but requires an addition. If there was already a MID > associated with the SSRC, i.e. a new MID has been assigned to this SSRC, > then there is deleting in the old MIDs association table that needs to > happen. > > 31. Section 6: > > I think this section should be updated to work with the BUNDLE text as > that matures. I understand that there are a few additional cases one like= s > to cover for non WebRTC endpoints, but still, lets not introduce > unnecessary failure cases over that. > > 32. Section 6: > > The RTCP packet routing. This doesn't match my view of how RTCP processin= g > happens. I think the "deliver a copy of the packet to > the RtpReceiver associated with that SSRC." > > Is the part that I have most issues with. What I find more relevant and > correct and likely matching more implementations are" > > deliver the information to > the RtpReceiver associated with that SSRC. > > > Cheers > > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --001a113f41a851233f054138989e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Magnus,

I've added gith= ub issues for most of these in the range 387 to 408.=C2=A0 The two final is= sues here (numbers 31 and 32), both related to section 6, weren't reall= y clear enough for me to provide a useful summary.=C2=A0 Can you try to rep= hrase those?=C2=A0 It would be great if you can do that by adding them to t= he issues list, but I'll try to add them if you update them here.
thanks,

Ted

On Sun, Nov 13, 2016 at 4:13 PM, Magnus Westerlund= <magnus.westerlund@ericsson.com> wrote:
Hi,

As I am late, and we are having the discussion tomorrow I am taking the eas= iest route for me to get my feedback out to the WG and authors, thus an ema= il rather than Github issues.

So here are my comments on the -17 version of JSEP.

1. Terminology: m=3D section. I would propose that the document creates a t= erminology section and are explicit that m=3D section and SDP Media Descrip= tion are the same thing.

2. There are a couple of terms that would really need a definition and also= possibly some reflection of how they relate to the RTCWeb terms, like WebR= TC Endpoint. So the terms I really like defined are:

JSEP endpoint
JSEP implementation

3. Section 3.6:

JSEP
=C2=A0 =C2=A0implementations will not transmit non-square pixels, but SHOUL= D
=C2=A0 =C2=A0receive and render such video with the correct aspect ratio.
I have two issues with this. First of all, shouldn't JSEP implementatio= ns be WebRTC endpoints? The second is these statement that says that a JSEP= /WebRTC foo will not do a thing. In most cases that is not necessary, as th= ere would be no issues if a particular implementation supports this functio= nality. So, I think this should be written as:

WebRTC endpoints does not need to support transmission of non-square pixels= , but SHOULD
=C2=A0 =C2=A0receive and render such video with the correct aspect ratio.
4. Section 3.6.2:

=C2=A0 =C2=A0When communicating with a non-JSEP endpoint, multiple relevant=
=C2=A0 =C2=A0"a=3Dimageattr recv" attributes may be received.=C2= =A0 If this occurs,
=C2=A0 =C2=A0attributes other than the one with the highest "q=3D"= ; value MUST be
=C2=A0 =C2=A0ignored.

There is to my knowledge nothing preventing multiple parameters sets to
have the same preference value (q). Thus, the formulation of this sentence = needs to be addressed.

5. Section 3.6.2:

=C2=A0 =C2=A0If an "a=3Dimageattr recv" attribute references a di= fferent video codec
=C2=A0 =C2=A0than what has been selected for the MediaStreamTrack, it MUST = be
=C2=A0 =C2=A0ignored.

So, to my understanding there can be multiple video codecs and multiple RTP= PTs that have been negotiated as possible to use. Is selected just the sin= gle currently used one, one or all the possible ones here?

6. Section 3.6.2:

=C2=A0 =C2=A0If the attribute includes a "sar=3D" (sample aspect = ratio) value set to
=C2=A0 =C2=A0something other than "1.0", indicating the receiver = wants to receive
=C2=A0 =C2=A0non-square pixels, this cannot be satisfied and the sender MUS= T NOT
=C2=A0 =C2=A0transmit the track.

Another instances where the language should allow for flexibility if an imp= lementation goes beyond the defined mandatory support. Changing "this = cannot be" to "if this cannot be" may resolve it. Also, isn&= #39;t the relevant "MUST NOT" is to not accept this in the negoti= ation?

7.=C2=A0 Section 3.7:

=C2=A0 =C2=A0JSEP supports simulcast of a MediaStreamTrack, where multiple<= br> =C2=A0 =C2=A0encodings of the source media can be transmitted within the co= ntext
=C2=A0 =C2=A0of a single m=3D section.

I think this should be explcit that it is "simulcast transmission of a= MediaStreamTrack".

8. Section 5.1.1:

=C2=A0 =C2=A0This list of mandatory-to-implement specifications is derived = from
=C2=A0 =C2=A0the requirements outlined in [I-D.ietf-rtcweb-rtp-usage].

 =C2=A0 =C2=A0R-5=C2=A0 =C2=A0[RFC4568] MUST NOT be implemented to signal SD= ES SRTP keying
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0information.

So, the list of mandatory-to-implement includes also some to not implement.= That is fine, but probably should be moved to its own list, or rename the = list so that it can contain both types.

Secondly, this specific requirement I think comes from the security docs, r= ather than rtp-usage.

9. Section 5.1.1:
=C2=A0 =C2=A0R-2=C2=A0 =C2=A0[RFC5764] MUST be supported for signaling the = UDP/TLS/RTP/SAVPF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC5764], TCP/DTLS/RTP/SAVPF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.nandakumar-mmusic-proto-iana-re= gistration], "UDP/DTLS/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SCTP" [I-D.ietf-mmusic-sctp-sdp], an= d "TCP/DTLS/SCTP"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-mmusic-sctp-sdp] RTP profiles.<= br>
I would note that [I-D.nandakumar-mmusic-proto-iana-registration] is a= ctually published as RFC 7850.

10. Section 5.1.1:
=C2=A0 =C2=A0R-12=C2=A0 [RFC5761] MUST be implemented to signal multiplexin= g of RTP and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP.

This should include the updated as ref also.


11. Section 5.1.1:

=C2=A0 R-15=C2=A0 [RFC3556] with bandwidth modifiers MAY be supported for =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specifying RTCP bandwidth as a fraction o= f the media bandwidth,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP fraction allocated to the senders an= d setting maximum
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0media bit-rate boundaries.

So, why wasn't support of RR and RS bandwidth modifiers made a MUST?
Secondly, the RR and RS attributes do not specify the bandwidth as fraction= of the media bandwidth. The specify RTP session level limits for RTCP band= width.

12. Section 5.1.1:

=C2=A0 =C2=A0R-16=C2=A0 TODO: any others?

Please remove this.

13. Section 5.1.3:

=C2=A0 =C2=A0For media m=3D sections, JSEP endpoints MUST support both the = "UDP/TLS/
=C2=A0 =C2=A0RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles an= d MUST indicate one of
=C2=A0 =C2=A0these two profiles for each media m=3D line they produce in an= offer.

Do I understand this correct, we are requiring support for the "TCP/DT= LS/RTP/SAVPF" proto so that in cases an endpoint supports the optional= to support ICE TCP, they can indicate it, and any WebRTC endpoint will acc= ept it, even if that is just one option? I do know that different profiles = are a negotiation issue. But, wouldn't it be more reasonable in this ca= se to use UDP/TLS/RTP/SAVPF in all cases where one offer any candidates tha= t also use UDP? And only use TCP/DTLS/RTP/SAVPF in cases only TCP candidate= s are signalled, thus not forcing TCP/DTLS/RTP/SAVPF onto clients that does= n't support it?

14. Section 5.1.3:
Otherwise, assume that AVPF is being used in an AVP
=C2=A0 =C2=A0 =C2=A0 compatible mode and use AVP timing, i.e., "trr-in= t=3D4".

I find this sentence confusing. I think this should be clarified to say:
Otherwise, assume that AVPF is being used in an AVP
=C2=A0 =C2=A0 =C2=A0 compatible mode, i.e. use AVPF timing configured with = a "trr-int=3D4".

15. Section 5.1.3:

Spurious space in:

For data m=3D sections, JSEP endpoints MUST support receiving the
=C2=A0 =C2=A0 =C2=A0 "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP",= or "DTLS/SCTP" (for backwards
=C2=A0 =C2=A0 =C2=A0 compatibility) profiles.

16. Section 5.2.1:
=C2=A0 =C2=A0o=C2=A0 Session Information ("i=3D"), URI ("u= =3D"), Email Address ("e=3D"),
=C2=A0 =C2=A0 =C2=A0 Phone Number ("p=3D"), Bandwidth ("b=3D= "), Repeat Times ("r=3D"), and
=C2=A0 =C2=A0 =C2=A0 Time Zones ("z=3D") lines are not useful in = this context and SHOULD
=C2=A0 =C2=A0 =C2=A0 NOT be included.

Considering that b=3DCT is not useless, I am a bit surprised to see b=3D on= this list. Yes, b=3DCT: is only useful is one like to provide a upper tota= l bandwidth limitation. So, maybe some discussion of the possible choice?
17. Section 5.2.1:

This is done in the order
=C2=A0 =C2=A0that their associated RtpTransceivers were added to the
=C2=A0 =C2=A0PeerConnection and excludes RtpTransceivers that are stopped a= nd not
=C2=A0 =C2=A0associated with an m=3D section (either due to an m=3D section= being
=C2=A0 =C2=A0recycled or an RtpTransceiver having been stopped before being=
=C2=A0 =C2=A0associated with an m=3D section) .

I am bit surprised to see "recycled" on a list of things that may= occur in generating an initial offer? Can that really occur?

18. Section 5.2.1:

=C2=A0 =C2=A0o=C2=A0 An "a=3Dmid" line, as specified in [RFC5888]= , Section 4.=C2=A0 When
=C2=A0 =C2=A0 =C2=A0 generating mid values, it is RECOMMENDED that the valu= es be 3
=C2=A0 =C2=A0 =C2=A0 bytes or less, to allow them to efficiently fit into t= he RTP
=C2=A0 =C2=A0 =C2=A0 header extension defined in
=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-mmusic-sdp-bundle-negotiation], Section= 11.


Just to note that to my understanding we are having discussion if this shou= ld be referencing a more specific generation algorithm.

Such a change is likely to affect text on RID also:

19. Section 5.2.1:
The list of
=C2=A0 =C2=A0 =C2=A0 RTCP feedback mechanisms that SHOULD/MUST be supported= is
=C2=A0 =C2=A0 =C2=A0 specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1.=

I would request that we don't use the quite confusing "SHOULD/MUST= " and instead write something like:

mechanisms that are recommended or mandated to be supported

20. Section 5.3.1:

=C2=A0 =C2=A0o=C2=A0 If this m=3D section is for media with configurable fr= ame sizes,
=C2=A0 =C2=A0 =C2=A0 e.g. audio, an "a=3Dmaxptime" line, indicati= ng the smallest of the
=C2=A0 =C2=A0 =C2=A0 maximum supported frame sizes out of all codecs includ= ed above, as
=C2=A0 =C2=A0 =C2=A0 specified in [RFC4566], Section 6.

In most cases the maxptime attribute doesn't affect the frame size of t= he encoder, instead it affects the maximum amount of media that are packeti= zed into a RTP payload, i.e. how many frames that are included.

21. Section 5.3.1:

=C2=A0 =C2=A0Each m=3D section which is not bundled into another m=3D secti= on, MUST
=C2=A0 =C2=A0contain the following attributes (which are of category IDENTI= CAL or
=C2=A0 =C2=A0TRANSPORT):

I react to "bundle into another m=3D section". I though they wher= e "bundled with"?

22. Section 5.7.2:
=C2=A0 =C2=A0o=C2=A0 If present, a single "a=3Drtcp" attribute MU= ST be parsed as
=C2=A0 =C2=A0 =C2=A0 specified in [RFC3605], Section 2.1, but its value is = ignored, as
=C2=A0 =C2=A0 =C2=A0 this information is superfluous when using ICE.

This is another case, where there is an exception to what is written if one= has supports the non RTP/RTCP mux usage. Thus, this should be ammended to = included such an exception.

23. Section 5.7.2:

What about additional a=3D attributes? Any attribute supported by the imple= mentation MAY be parsed?

24. Section 5.8:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 Find the RtpTransceiver that corr= esponds to the m=3D section
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with the same MID in the created = offer.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 Set the value of the RtpTransceiv= er's mid attribute to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MID of the m=3D section.

I find this text strange. If you already know the MID, why is it being set = in the second sub-bullet?

25. Section 5.8:

=C2=A0 =C2=A0 =C2=A0*=C2=A0 If RTCP mux is indicated, prepare to demux RTP = and RTCP from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the RTP ICE component, as specified in [R= FC5761],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 5.1.1.=C2=A0 If RTCP mux is not i= ndicated, but was indicated
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in a previous description, this MUST resu= lt in an error.

I note that there can be difference here between an offer and an answer if = the RTCP mux indication may have changed or not between these two descripti= on.

26. Section 5.9:
=C2=A0 o=C2=A0 For any specified "CT" bandwidth value, set this a= s the limit for
=C2=A0 =C2=A0 =C2=A0 the maximum total bitrate for all m=3D sections, as sp= ecified in
=C2=A0 =C2=A0 =C2=A0 Section 5.8 of [RFC4566].=C2=A0 The implementation can= decide how to
=C2=A0 =C2=A0 =C2=A0 allocate the available bandwidth between m=3D sections= to
=C2=A0 =C2=A0 =C2=A0 simultaneously meet any limits on individual m=3D sect= ions, as well
=C2=A0 =C2=A0 =C2=A0 as this overall session limit.

I think this text can be improved to make it clearer that CT doesn't im= ply a fixed over time divide of the bandwidth between RTP streams. As long = as individual media sources streams stay within other requirements such as = b=3DAS/TIAS they can be changed dynamically.

27. Section 5.10:

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 If the media section has RTCP mux enabled, dis= card any RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0component, and begin or continue muxing R= TCP over the RTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0component, as specified in [RFC5761], Sec= tion 5.1.3.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Otherwise, prepare to transmit RTCP over = the RTCP component; if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0no RTCP component exists, because RTCP mu= x was previously
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enabled, this MUST result in an error.
I think this should say "any RTCP ICE component"..

28. Section 5.10:
When sending RTCP feedback, use the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC of an outgoing Source RTP Stream as = the RTCP sender SSRC;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if no outgoing Source RTP Stream exists, = choose a random one.

This is okay, but could be slightly more open in regards to sending feedbac= k packets efficiently. Section 5.4.1 in https://datatracker.ietf.org/doc/draft-ietf-= avtcore-rtp-multi-stream/?include_text=3D1 is providing more detai= led rules for things to consider.

29. Section 6:

If
=C2=A0 =C2=A0 =C2=A0 any payload type could map to more than one RtpReceive= r, map to
=C2=A0 =C2=A0 =C2=A0 the RtpReceiver whose m=3D section appears earliest in= the local
=C2=A0 =C2=A0 =C2=A0 description.

I think this is a bad advice. I think it should say that if this is the cas= e, PT should not be used to try to determine which m=3D section it belongs = to. I think wrongly attributing a packet is worse than dropping it in cases= where the information is incomplete. This rule can result in that one asso= ciate an SSRC with the wrong m=3D section.

30. Section 6:
=C2=A0 =C2=A0 =C2=A0 If the packet has a MID and that MID is in the table m= apping MID
=C2=A0 =C2=A0 =C2=A0 to RtpReceiver, update the incoming SSRC mapping table= to include
=C2=A0 =C2=A0 =C2=A0 an entry that maps the packet's SSRC to the RtpRec= eiver for that
=C2=A0 =C2=A0 =C2=A0 MID.

This is all fine, but requires an addition. If there was already a MID asso= ciated with the SSRC, i.e. a new MID has been assigned to this SSRC, then t= here is deleting in the old MIDs association table that needs to happen.
31. Section 6:

I think this section should be updated to work with the BUNDLE text as that= matures. I understand that there are a few additional cases one likes to c= over for non WebRTC endpoints, but still, lets not introduce unnecessary fa= ilure cases over that.

32. Section 6:

The RTCP packet routing. This doesn't match my view of how RTCP process= ing happens. I think the "deliver a copy of the packet to
=C2=A0 =C2=A0 =C2=A0 the RtpReceiver associated with that SSRC."

Is the part that I have most issues with. What I find more relevant and cor= rect and likely matching more implementations are"

deliver the information to
=C2=A0 =C2=A0 =C2=A0 the RtpReceiver associated with that SSRC.


Cheers


Magnus Westerlund

-----------------------------------------------------------------= -----
Services, Media and Network features, Ericsson Research EAB/TXM
-----------------------------------------------------------------= -----
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------= -----


--001a113f41a851233f054138989e-- From nobody Sun Nov 13 18:10:26 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 02160129441 for ; Sun, 13 Nov 2016 18:10:25 -0800 (PST) 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 Vak23J13bEeZ for ; Sun, 13 Nov 2016 18:10:23 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 B0D0B1293EE for ; Sun, 13 Nov 2016 18:10:22 -0800 (PST) X-AuditID: c1b4fb30-dc07098000007ca6-56-58291d0c635e Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 54.F0.31910.C0D19285; Mon, 14 Nov 2016 03:10:21 +0100 (CET) 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.319.2; Mon, 14 Nov 2016 03:08:16 +0100 To: Ted Hardie References: <40497c7e-2c2a-d137-93f4-ff657e77b8fd@ericsson.com> From: Magnus Westerlund Message-ID: Date: Mon, 14 Nov 2016 11:08:10 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM2K7pS6vrGaEwa6PnBbTz/xltOiYzGax 9l87u8WVVY3MFo1z7RxYPab83sjq8eXJSyaPnbPusnssWfKTyePgQcYA1igum5TUnMyy1CJ9 uwSujB0rJrAW3G1hrDi96D5bA2NXQhcjJ4eEgInEvH3P2boYuTiEBNYxStzZ/Z4ZwlnOKHFm +iZGkCphAWOJY9u/gdkiAsoSe6/sgOo4yyixedJHFhCHWaCPUeL01SlgVWwCFhI3fzSygdi8 AvYSrw9tYQexWQRUJXp+HQCzRQViJK4/ewRVIyhxcuYTFhCbUyBQYsOtdiYQmxlozsz55xkh bHmJ5q2zmUFsIQFtiYamDtYJjAKzkLTPQtIyC0nLAkbmVYyixanFSbnpRkZ6qUWZycXF+Xl6 eaklmxiBQX1wy2+DHYwvnzseYhTgYFTi4f1QrxEhxJpYVlyZe4hRgoNZSYTXXlozQog3JbGy KrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OKWBIr/wj7O+vMdvixkKV 6z/4L64vy8kVPhC1ptcwJax83sQ5QZVBmnHZRyv2bWJSyOut6BGY0Pj6jdv618UsZi8E1njm CfDEengfWGtbEPOp4/8ZWbfYbZ08iTPUJ13rTGGdPHHdp4z7v3gPXPrbdoCFKzOs78r+s5uP OqkaPrkrdGxaIOOSqAglluKMREMt5qLiRADlQwL5ZgIAAA== Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Working Group Last Call: JSEP 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, 14 Nov 2016 02:10:25 -0000 Thanks Ted, I think these two comments actually can be added as comments to Colin's earlier issue. https://github.com/rtcweb-wg/jsep/issues/364 I will do that. Cheers Magnus Den 2016-11-14 kl. 10:16, skrev Ted Hardie: > Hi Magnus, > > I've added github issues for most of these in the range 387 to 408. The > two final issues here (numbers 31 and 32), both related to section 6, > weren't really clear enough for me to provide a useful summary. Can you > try to rephrase those? It would be great if you can do that by adding > them to the issues list, but I'll try to add them if you update them here. > > thanks, > > Ted > > On Sun, Nov 13, 2016 at 4:13 PM, Magnus Westerlund > > > wrote: > > Hi, > > As I am late, and we are having the discussion tomorrow I am taking > the easiest route for me to get my feedback out to the WG and > authors, thus an email rather than Github issues. > > So here are my comments on the -17 version of JSEP. > > 1. Terminology: m= section. I would propose that the document > creates a terminology section and are explicit that m= section and > SDP Media Description are the same thing. > > 2. There are a couple of terms that would really need a definition > and also possibly some reflection of how they relate to the RTCWeb > terms, like WebRTC Endpoint. So the terms I really like defined are: > > JSEP endpoint > JSEP implementation > > 3. Section 3.6: > > JSEP > implementations will not transmit non-square pixels, but SHOULD > receive and render such video with the correct aspect ratio. > > I have two issues with this. First of all, shouldn't JSEP > implementations be WebRTC endpoints? The second is these statement > that says that a JSEP/WebRTC foo will not do a thing. In most cases > that is not necessary, as there would be no issues if a particular > implementation supports this functionality. So, I think this should > be written as: > > WebRTC endpoints does not need to support transmission of non-square > pixels, but SHOULD > receive and render such video with the correct aspect ratio. > > 4. Section 3.6.2: > > When communicating with a non-JSEP endpoint, multiple relevant > "a=imageattr recv" attributes may be received. If this occurs, > attributes other than the one with the highest "q=" value MUST be > ignored. > > There is to my knowledge nothing preventing multiple parameters sets to > have the same preference value (q). Thus, the formulation of this > sentence needs to be addressed. > > 5. Section 3.6.2: > > If an "a=imageattr recv" attribute references a different video codec > than what has been selected for the MediaStreamTrack, it MUST be > ignored. > > So, to my understanding there can be multiple video codecs and > multiple RTP PTs that have been negotiated as possible to use. Is > selected just the single currently used one, one or all the possible > ones here? > > 6. Section 3.6.2: > > If the attribute includes a "sar=" (sample aspect ratio) value set to > something other than "1.0", indicating the receiver wants to receive > non-square pixels, this cannot be satisfied and the sender MUST NOT > transmit the track. > > Another instances where the language should allow for flexibility if > an implementation goes beyond the defined mandatory support. > Changing "this cannot be" to "if this cannot be" may resolve it. > Also, isn't the relevant "MUST NOT" is to not accept this in the > negotiation? > > 7. Section 3.7: > > JSEP supports simulcast of a MediaStreamTrack, where multiple > encodings of the source media can be transmitted within the context > of a single m= section. > > I think this should be explcit that it is "simulcast transmission of > a MediaStreamTrack". > > 8. Section 5.1.1: > > This list of mandatory-to-implement specifications is derived from > the requirements outlined in [I-D.ietf-rtcweb-rtp-usage]. > > R-5 [RFC4568] MUST NOT be implemented to signal SDES SRTP keying > information. > > So, the list of mandatory-to-implement includes also some to not > implement. That is fine, but probably should be moved to its own > list, or rename the list so that it can contain both types. > > Secondly, this specific requirement I think comes from the security > docs, rather than rtp-usage. > > 9. Section 5.1.1: > R-2 [RFC5764] MUST be supported for signaling the UDP/TLS/RTP/SAVPF > [RFC5764], TCP/DTLS/RTP/SAVPF > [I-D.nandakumar-mmusic-proto-iana-registration], "UDP/DTLS/ > SCTP" [I-D.ietf-mmusic-sctp-sdp], and "TCP/DTLS/SCTP" > [I-D.ietf-mmusic-sctp-sdp] RTP profiles. > > I would note that [I-D.nandakumar-mmusic-proto-iana-registration] is > actually published as RFC 7850. > > 10. Section 5.1.1: > R-12 [RFC5761] MUST be implemented to signal multiplexing of RTP and > RTCP. > > This should include the updated as ref also. > > > 11. Section 5.1.1: > > R-15 [RFC3556] with bandwidth modifiers MAY be supported for > specifying RTCP bandwidth as a fraction of the media bandwidth, > RTCP fraction allocated to the senders and setting maximum > media bit-rate boundaries. > > So, why wasn't support of RR and RS bandwidth modifiers made a MUST? > > Secondly, the RR and RS attributes do not specify the bandwidth as > fraction of the media bandwidth. The specify RTP session level > limits for RTCP bandwidth. > > 12. Section 5.1.1: > > R-16 TODO: any others? > > Please remove this. > > 13. Section 5.1.3: > > For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/ > RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of > these two profiles for each media m= line they produce in an offer. > > Do I understand this correct, we are requiring support for the > "TCP/DTLS/RTP/SAVPF" proto so that in cases an endpoint supports the > optional to support ICE TCP, they can indicate it, and any WebRTC > endpoint will accept it, even if that is just one option? I do know > that different profiles are a negotiation issue. But, wouldn't it be > more reasonable in this case to use UDP/TLS/RTP/SAVPF in all cases > where one offer any candidates that also use UDP? And only use > TCP/DTLS/RTP/SAVPF in cases only TCP candidates are signalled, thus > not forcing TCP/DTLS/RTP/SAVPF onto clients that doesn't support it? > > 14. Section 5.1.3: > Otherwise, assume that AVPF is being used in an AVP > compatible mode and use AVP timing, i.e., "trr-int=4". > > I find this sentence confusing. I think this should be clarified to say: > > Otherwise, assume that AVPF is being used in an AVP > compatible mode, i.e. use AVPF timing configured with a > "trr-int=4". > > 15. Section 5.1.3: > > Spurious space in: > > For data m= sections, JSEP endpoints MUST support receiving the > "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards > compatibility) profiles. > > 16. Section 5.2.1: > o Session Information ("i="), URI ("u="), Email Address ("e="), > Phone Number ("p="), Bandwidth ("b="), Repeat Times ("r="), and > Time Zones ("z=") lines are not useful in this context and SHOULD > NOT be included. > > Considering that b=CT is not useless, I am a bit surprised to see b= > on this list. Yes, b=CT: is only useful is one like to provide a > upper total bandwidth limitation. So, maybe some discussion of the > possible choice? > > 17. Section 5.2.1: > > This is done in the order > that their associated RtpTransceivers were added to the > PeerConnection and excludes RtpTransceivers that are stopped and not > associated with an m= section (either due to an m= section being > recycled or an RtpTransceiver having been stopped before being > associated with an m= section) . > > I am bit surprised to see "recycled" on a list of things that may > occur in generating an initial offer? Can that really occur? > > 18. Section 5.2.1: > > o An "a=mid" line, as specified in [RFC5888], Section 4. When > generating mid values, it is RECOMMENDED that the values be 3 > bytes or less, to allow them to efficiently fit into the RTP > header extension defined in > [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 11. > > > Just to note that to my understanding we are having discussion if > this should be referencing a more specific generation algorithm. > > Such a change is likely to affect text on RID also: > > 19. Section 5.2.1: > The list of > RTCP feedback mechanisms that SHOULD/MUST be supported is > specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. > > I would request that we don't use the quite confusing "SHOULD/MUST" > and instead write something like: > > mechanisms that are recommended or mandated to be supported > > 20. Section 5.3.1: > > o If this m= section is for media with configurable frame sizes, > e.g. audio, an "a=maxptime" line, indicating the smallest of the > maximum supported frame sizes out of all codecs included above, as > specified in [RFC4566], Section 6. > > In most cases the maxptime attribute doesn't affect the frame size > of the encoder, instead it affects the maximum amount of media that > are packetized into a RTP payload, i.e. how many frames that are > included. > > 21. Section 5.3.1: > > Each m= section which is not bundled into another m= section, MUST > contain the following attributes (which are of category IDENTICAL or > TRANSPORT): > > I react to "bundle into another m= section". I though they where > "bundled with"? > > 22. Section 5.7.2: > o If present, a single "a=rtcp" attribute MUST be parsed as > specified in [RFC3605], Section 2.1, but its value is ignored, as > this information is superfluous when using ICE. > > This is another case, where there is an exception to what is written > if one has supports the non RTP/RTCP mux usage. Thus, this should be > ammended to included such an exception. > > 23. Section 5.7.2: > > What about additional a= attributes? Any attribute supported by the > implementation MAY be parsed? > > 24. Section 5.8: > > + Find the RtpTransceiver that corresponds to the m= section > with the same MID in the created offer. > > + Set the value of the RtpTransceiver's mid attribute to the > MID of the m= section. > > I find this text strange. If you already know the MID, why is it > being set in the second sub-bullet? > > 25. Section 5.8: > > * If RTCP mux is indicated, prepare to demux RTP and RTCP from > the RTP ICE component, as specified in [RFC5761], > Section 5.1.1. If RTCP mux is not indicated, but was indicated > in a previous description, this MUST result in an error. > > I note that there can be difference here between an offer and an > answer if the RTCP mux indication may have changed or not between > these two description. > > 26. Section 5.9: > o For any specified "CT" bandwidth value, set this as the limit for > the maximum total bitrate for all m= sections, as specified in > Section 5.8 of [RFC4566]. The implementation can decide how to > allocate the available bandwidth between m= sections to > simultaneously meet any limits on individual m= sections, as well > as this overall session limit. > > I think this text can be improved to make it clearer that CT doesn't > imply a fixed over time divide of the bandwidth between RTP streams. > As long as individual media sources streams stay within other > requirements such as b=AS/TIAS they can be changed dynamically. > > 27. Section 5.10: > > * If the media section has RTCP mux enabled, discard any RTCP > component, and begin or continue muxing RTCP over the RTP > component, as specified in [RFC5761], Section 5.1.3. > Otherwise, prepare to transmit RTCP over the RTCP component; if > no RTCP component exists, because RTCP mux was previously > enabled, this MUST result in an error. > > I think this should say "any RTCP ICE component".. > > 28. Section 5.10: > When sending RTCP feedback, use the > SSRC of an outgoing Source RTP Stream as the RTCP sender SSRC; > if no outgoing Source RTP Stream exists, choose a random one. > > This is okay, but could be slightly more open in regards to sending > feedback packets efficiently. Section 5.4.1 in > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream/?include_text=1 > > is providing more detailed rules for things to consider. > > 29. Section 6: > > If > any payload type could map to more than one RtpReceiver, map to > the RtpReceiver whose m= section appears earliest in the local > description. > > I think this is a bad advice. I think it should say that if this is > the case, PT should not be used to try to determine which m= section > it belongs to. I think wrongly attributing a packet is worse than > dropping it in cases where the information is incomplete. This rule > can result in that one associate an SSRC with the wrong m= section. > > 30. Section 6: > If the packet has a MID and that MID is in the table mapping MID > to RtpReceiver, update the incoming SSRC mapping table to include > an entry that maps the packet's SSRC to the RtpReceiver for that > MID. > > This is all fine, but requires an addition. If there was already a > MID associated with the SSRC, i.e. a new MID has been assigned to > this SSRC, then there is deleting in the old MIDs association table > that needs to happen. > > 31. Section 6: > > I think this section should be updated to work with the BUNDLE text > as that matures. I understand that there are a few additional cases > one likes to cover for non WebRTC endpoints, but still, lets not > introduce unnecessary failure cases over that. > > 32. Section 6: > > The RTCP packet routing. This doesn't match my view of how RTCP > processing happens. I think the "deliver a copy of the packet to > the RtpReceiver associated with that SSRC." > > Is the part that I have most issues with. What I find more relevant > and correct and likely matching more implementations are" > > deliver the information to > the RtpReceiver associated with that SSRC. > > > 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 > > ---------------------------------------------------------------------- > > -- 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 Sun Nov 13 20:22:38 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 3E7841294F0; Sun, 13 Nov 2016 20:22:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147909735721.27119.17649092592939811318.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 20:22:37 -0800 Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, smccammon@amsl.com Subject: [rtcweb] rtcweb - Update to a Meeting Session Request for IETF 97 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: Mon, 14 Nov 2016 04:22:37 -0000 An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the rtcweb working group. --------------------------------------------------------- Working Group Name: Real-Time Communication in WEB-browsers Area Name: Applications and Real-Time Area Session Requester: Stephanie McCammon Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 100 Conflicts to Avoid: First Priority: tls rmcat aqm avtcore avtext clue dispatch httpbis stir acme mmusic payload sipcore perc Second Priority: dprive tcpinc straw tsvwg tsvarea ace uta netvc capport Third Priority: insipid irtfopen ianaplan dane opsawg Special Requests: --------------------------------------------------------- From nobody Sun Nov 13 20:41: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 01BDF12954D for ; Sun, 13 Nov 2016 20:41:09 -0800 (PST) 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, HTML_NONELEMENT_30_40=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 KMLXwyy4JqIa for ; Sun, 13 Nov 2016 20:41:07 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43666127058 for ; Sun, 13 Nov 2016 20:41:07 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id x190so83306165qkb.0 for ; Sun, 13 Nov 2016 20:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Fi/N5rdDHUNjeC3MR6p/o1JsU6W/0abSTBDCZZ4EHR0=; b=oeMuD1DR/rQIGyKBTW43V3IHtwQrPZ5UwBfQSOgtMKRUYojBVMbKDQVhf8/JzDSVw5 h1IM7znBN/MBk1u3cR0nxrwnNlnuZXcXvrFjESuxWV709vBWqbzoNZivKIjGSdATDXjn QCLtNSUg4gJierpjQoatuTjhL6Rt/dI64Yp08mvwREVJ6lJymWjJKUNvomEvcF+1QbMN o3F3NmJYUnA/NNHg2cTMhrPOXJbPNSVeolMz6OZTSAx4D38dNhYBowJJcvVBC6jJ9jl7 rshnzvOsc5QNOnH1bdqF82NWmk10TC4T9UrB665LulXihW5atWKuMzhHotBeRGc4lEnp QZ8g== 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=Fi/N5rdDHUNjeC3MR6p/o1JsU6W/0abSTBDCZZ4EHR0=; b=Oxwx9Kr1ogXqBu433V7Dm3NIWPB7GAGtlv3p/W2YgOedjcpOKWAwSUN8wLqJtsc1O8 Q84fwOIzIx3HsQimyUhPxPuoRerjYZxu0Blmk4qmCysxjZhYmQgsDEjZ5nTLZnwuvxpl P9lBE9ad1t2NVmSbpmTGjRP2I79cGvafp/anY3AgHqjBceItKU6ZmJOo5J0Sx5IoLFhq p+HnFlI45pl1LNDZozbAU1+gGnc6np+2KWDq9AaXWl+jZdOLcMAr0/Z0YR5TAOctllD2 VFpKNpCQJHWqF8pvJUgQT7v2HnIUzTu8I2HLVBI1Duco96BAEjrKiO5z+fg+60+6Tm4B n6Kg== X-Gm-Message-State: ABUngvdOPol/XT075eJQ0A52rL0YP7eedrET7jRT2Rn2V4tbQ6Nfa1sKNwkdelmbboJQa5ddBXioOKJ5izMW+Q== X-Received: by 10.55.100.204 with SMTP id y195mr16592390qkb.23.1479098466298; Sun, 13 Nov 2016 20:41:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.165.100 with HTTP; Sun, 13 Nov 2016 20:40:36 -0800 (PST) In-Reply-To: <147909735721.27119.17649092592939811318.idtracker@ietfa.amsl.com> References: <147909735721.27119.17649092592939811318.idtracker@ietfa.amsl.com> From: Ted Hardie Date: Mon, 14 Nov 2016 13:40:36 +0900 Message-ID: To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=94eb2c05c874abf10705413b72af Archived-At: Subject: [rtcweb] Fwd: rtcweb - Update to a Meeting Session Request for IETF 97 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, 14 Nov 2016 04:41:09 -0000 --94eb2c05c874abf10705413b72af Content-Type: text/plain; charset=UTF-8 Howdy, Just a clarification on this--we are really anxious to get the JSEP discussion complete this week; after getting the reviews from Magnus and Harald, we got a little concerned that we might not be able to get through that and the other agenda items. We will discuss the timing a bit at the session later today. regards, Ted, Cullen, Sean An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the rtcweb working group. --------------------------------------------------------- Working Group Name: Real-Time Communication in WEB-browsers Area Name: Applications and Real-Time Area Session Requester: Stephanie McCammon Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 100 Conflicts to Avoid: First Priority: tls rmcat aqm avtcore avtext clue dispatch httpbis stir acme mmusic payload sipcore perc Second Priority: dprive tcpinc straw tsvwg tsvarea ace uta netvc capport Third Priority: insipid irtfopen ianaplan dane opsawg Special Requests: --------------------------------------------------------- --94eb2c05c874abf10705413b72af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

Just a clarification on= this--we are really anxious to get the JSEP discussion complete this week;= after getting the reviews from Magnus and Harald, we got a little concerne= d that we might not be able to get through that and the other agenda items.= =C2=A0 We will discuss the timing a bit at the session later today.
regards,

Ted, Cullen, Sean



An update to a meeting session request has just been submitted by Stephanie= McCammon, on behalf of the rtcweb working group.


---------------------------------------------------------
Working Group Name: Real-Time Communication in WEB-browsers
Area Name: Applications and Real-Time Area
Session Requester: Stephanie McCammon

Number of Sessions: 2
Length of Session(s):=C2=A0 2 Hours, 1 Hour
Number of Attendees: 100
Conflicts to Avoid:
=C2=A0First Priority: tls rmcat aqm avtcore avtext clue dispatch httpbis st= ir acme mmusic payload sipcore perc
=C2=A0Second Priority: dprive tcpinc straw tsvwg tsvarea ace uta netvc capp= ort
=C2=A0Third Priority: insipid irtfopen ianaplan dane opsawg


Special Requests:

---------------------------------------------------------


--94eb2c05c874abf10705413b72af-- From nobody Sun Nov 13 22:59:56 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 AC842129415; Sun, 13 Nov 2016 22:59:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147910679370.27945.17030347455909724644.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 22:59:53 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-16.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: Mon, 14 Nov 2016 06:59:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF. Title : Overview: Real Time Protocols for Browser-based Applications Author : Harald T. Alvestrand Filename : draft-ietf-rtcweb-overview-16.txt Pages : 23 Date : 2016-11-13 Abstract: This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications WebRTC compliant implementations are supposed to follow. This document is a work item of the RTCWEB working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-overview-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 15 18:47: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 48D1612963A for ; Tue, 15 Nov 2016 18:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 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_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 O3bpd0pVZihI for ; Tue, 15 Nov 2016 18:47:30 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED8D129630 for ; Tue, 15 Nov 2016 18:47:30 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id q130so159578978qke.1 for ; Tue, 15 Nov 2016 18:47:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4asrJQssk16jyiDIdJSLy34/EKrFMXit1TCGmgw+5M4=; b=WybxW++8awV+uRz4aZFmUX6/GWJJIzWmUmgejuDjMHmLPeegDHOJM1HRXj3fowkDAl tHahpoRWNVXiUvFvQMVnmjdLvO09pa9fK/dJe8+sLQlQR6FEE050oGtejrip+2WswmGs T8iYGm6cz76JUNA/AfDHENdAO0GaHSkM8B+N9KGMXLAGfAe29WeabTo9ZuKi4siX/J4y s/stDFyL8Ez7AmIpWkKU9KQxU6zsz3HcFkcMitF5yOjJtGgPkLKgnB+LAGubB0LZ+6NE LugqFLfymRRWHc1n5Q+rpEc3AmNZZEikevcL11xN4mzJ1UMheQM+S7eZoDg4bmjl5v/d IY/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4asrJQssk16jyiDIdJSLy34/EKrFMXit1TCGmgw+5M4=; b=I6lCus0+lKqCRV+9v6vTJ9BjK9ciZwIYHHZRuGh2mOivk/nO//J9Az+Ue445TO/agv fqgCZgBSUKGfLl5A8FSQb8zbIS/axXRJwAoujRc7IDrjXtI5upQhfDH00HtrnTrTxeC9 SSImI0uo6YoqtHsGX3oTsYtySz7GDlGoh0Eb3p+X0gLX3nILseV4Zi5BD1ykQVkZ+Ea8 4rzsMUNQDqjh1D24iRok4nbXn/CGl5nU6fIuxwBYjLcq4s+D16C+gaVmn7rmTF2GGXGa IODlcnJHRA3I+/awngfca2FvdEdGWJJQDLpQUhicb2sriOVUnUZVoCRZ/r6f7H1XHuHS O1gA== X-Gm-Message-State: AKaTC02zMLqJjulFrgiWlLBKqOATwPW8HY7DjaQ+ywREnGl9fg3GM7hhWwSEGcszqMQeJEBnyK8aXk6H3HzYtXrC X-Received: by 10.55.106.134 with SMTP id f128mr908353qkc.121.1479264449397; Tue, 15 Nov 2016 18:47:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Wed, 16 Nov 2016 02:47:18 +0000 Message-ID: To: Bernard Aboba , Philipp Hancke Content-Type: multipart/alternative; boundary=001a114fddf6094a9a0541621827 Archived-At: Cc: "rtcweb@ietf.org" , Shijun Sun Subject: Re: [rtcweb] Working Group Last Call: JSEP 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, 16 Nov 2016 02:47:32 -0000 --001a114fddf6094a9a0541621827 Content-Type: text/plain; charset=UTF-8 I'm late to the party, but a hardy +1 for removing pranswer from me. On Thu, Nov 10, 2016 at 10:36 AM Bernard Aboba wrote: > +1. > > One of the reasons we added setDirection() was to be able to handle the > "warm up" case with no recourse to pranswer (as demonstrated in Example 12 > in Section 11.2 as you cite). > > Given that, it is hard to motivate an implementation to support pranswer > (e.g. in the Edge WebRTC 1.0 feature now in Windows Insider Preview, we > left out support for pranswer). > > > > On Tue, Nov 8, 2016 at 10:43 AM, Philipp Hancke > wrote: > > Am 21.10.2016 um 21:25 schrieb Ted Hardie: > > The chairs would like to start a working group last call on > draft-ietf-rtcweb-jset-17 to end on November 9th, 2016, 17:00 KST. > > Please review thoroughly, as working through the last comments will be the > major effort of our working group meeting in Seoul. > > > One question: why is pranswer still in there? The major use-case for this > seems to be transport warm-up (4.1.7.1) for which I think transceivers are > the new way as shown in > http://w3c.github.io/webrtc-pc/#simple-peer-to-peer-example-with-warm-up > > pranswer has not seen much traffic on this list. Together with BUNDLE it > seems to have been broken in Chrome since 2014 if I understand > https://bugs.chromium.org/p/webrtc/issues/detail?id=3349 correctly. And I > recall it being broken in 2013 when using DTLS. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a114fddf6094a9a0541621827 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm late to the party, but a hardy=C2=A0+1 for removin= g pranswer from me.

On T= hu, Nov 10, 2016 at 10:36 AM Bernard Aboba <bernard.aboba@gmail.com> wrote:
+1. =C2=A0

One of the= reasons we added setDirection() was to be able to handle the "warm up= " case with no recourse to pranswer (as demonstrated in Example 12 in = Section 11.2 as you cite).

Given that, it is hard to motivate an = implementation to support pranswer (e.g. in the Edge WebRTC 1.0 feature now= in Windows Insider Preview, we left out support for pranswer).=C2=A0
=

<= /div>


On Tue, Nov 8, 2016 at 10:43 AM, Philipp Hancke = <fippo@goodadvice.pages.de= > wrote:
Am 21.10.2016 um 21:25 schrieb Ted Ha= rdie:
The chairs would like to start a working group last call on
draft-ietf-rtcweb-jset-17 to end on November 9th, 2016, 17:00 KST.

Please review thoroughly, as working through the last comments will be the<= br class=3D"gmail_msg"> major effort of our working group meeting in Seoul.

 One question: why is pranswer still in there? The major use-case for this s= eems to be transport warm-up (4.1.7.1) for which I think transceivers are t= he new way as shown in http://w3c.github.io/webrtc-pc/#simple-peer-to-peer-example-= with-warm-up

pranswer has not seen much traffic on this list. Together with BUNDLE it se= ems to have been broken in Chrome since 2014 if I understand https://bugs.chromium.org/p/webrtc/i= ssues/detail?id=3D3349 correctly. And I recall it being broken in 2013 = when using DTLS.


_______________________________________________
rtcweb mailing list
rt= cweb@ietf.org
https://www.ietf.org/mailman/listinf= o/rtcweb

_______________________________________________
rtcweb mailing list
rt= cweb@ietf.org
https://www.ietf.org/mailman/listinf= o/rtcweb
--001a114fddf6094a9a0541621827-- From nobody Tue Nov 15 23:26: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 672D9129542 for ; Tue, 15 Nov 2016 23:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, 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=gC56OhN8; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=AnWnmbHV 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 e__R7Jb67OVy for ; Tue, 15 Nov 2016 23:26:00 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A57129421 for ; Tue, 15 Nov 2016 23:25:59 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2ED58207FD for ; Wed, 16 Nov 2016 02:25:59 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 16 Nov 2016 02:25:59 -0500 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-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=/2HwXdlt3F7ViAtTkX8rcXoViaw=; b=gC56Oh N8XuB0aQSqNCESxe52VH3GXevI2NagqlTJxpTtI9AKxrkd6JFyOC1vC91NitlFKS gYoY+DmCWFUeQwnJl7Hrz5IvtmKAA3UKWUzi38tuzIVzqt6nxvGTKJLYM/glDiWQ Qy0bT13Sl4DEJu+p5XEs4N12OIG2JIQU35IQ8= 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-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=/2HwXdlt3F7ViA tTkX8rcXoViaw=; b=AnWnmbHVJLybhRckyEGh4CPHrmvRBdaE44GydL5pfYRTEE +/PKztm1WV8QU0PwE4j8jclp5YFuu4f7wVLhE6WCdOzdRhHQT87dUicD8BLcffzL rwgEAP/ZpQBi4QLQ3sXeJHaheJwZS5NJG7C9Jc763w8o7PZo4UlDlmTQ+gqks= X-ME-Sender: X-Sasl-enc: txjlR/h1CSGXMqRu1E7ZnwSEaKk9Y7xyrZ5wQWb/QH/m 1479281158 Received: from [10.24.126.92] (unknown [128.107.241.178]) by mail.messagingengine.com (Postfix) with ESMTPA id 8BE6C2442C for ; Wed, 16 Nov 2016 02:25:58 -0500 (EST) From: Alissa Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 16 Nov 2016 16:25:56 +0900 To: RTCWeb IETF Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [rtcweb] tweaks for ip-handling language 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, 16 Nov 2016 07:26:01 -0000 This still needs the fix for =E2=80=9Call possible candidates.=E2=80=9D OLD Gathering all possible candidates SHOULD only be performed when some = form of user consent has been provided; this thwarts the typical = drive-by enumeration attacks. The details of this consent are left to = the implementation; one potential mechanism is to key this off = getUserMedia consent. The getUserMedia suggestion takes into account = that the user has provided some consent to the application already; that = when doing so the user typically wants to engage in a conversational = session, which benefits most from an optimal network path, and lastly, = the fact that the underlying issue is complex and difficult to explain, = making explicit consent for enumeration troublesome. NEW Gathering all possible candidates MUST only be performed when some form = of user consent has been provided; this thwarts the typical drive-by = enumeration attacks. The details of this consent are left to the = implementation. One potential mechanism is to tie this consent to = getUserMedia consent. Such a mechanism might be chosen based on the fact = that the user has provided some consent to the application already; that = when doing so the user typically wants to engage in a conversational = session, which benefits most from an optimal network path, and lastly, = the fact that the underlying issue is complex and difficult to explain, = making explicit consent for enumeration troublesome.= From nobody Wed Nov 16 15:26: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 93A721294E3 for ; Wed, 16 Nov 2016 15:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 ZGCeqWduN2mo for ; Wed, 16 Nov 2016 15:26:16 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D901293DB for ; Wed, 16 Nov 2016 15:26:15 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id x190so196665348qkb.0 for ; Wed, 16 Nov 2016 15:26:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RD/BaeKpnmjj/xhiYN0u2z9HyKQmWM8AmOR47n/uWFc=; b=DMHKjbmz7Z4suMh4wPFY0a1/7fei+c6vRDWhFgZHBg6Q55r5b9flMZ5gEY1qUQPNa9 Hn1/vzpxH7fd/UyuywrzifyWTpH00QfFNOM3daUTir9eP+ZI5v9fVelmGTiy6a1jl0oL 0GizXb7OcD5r7ycjbZstxK6eryysDqJ8hxvrkQWHVvPBKzbANGgJt5+m9e8vNNfrrYcs UuCQt/CaU5XYQ7pwuC+ZhOZBs9p6UtqF11jumvtbaqgfRkv0J+q8ff2n2NWKpO71zQ+E 4LoGjDnXVWHtT1mKS9ZtBWwvCaVWTZbSAv+KmRpkESVLTWgnu2zI4QPYHfbMYXaxEDFI yorg== 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=RD/BaeKpnmjj/xhiYN0u2z9HyKQmWM8AmOR47n/uWFc=; b=G7xe5YalsjlmjRXa0Il9ljcr54zQv+S3ufmyXOCFM2PAbFK08XEzH5cCIWqnsnMSVO Jl/bOYbegaLxjUgGOqYJAXZW7dORV52PzmyQB62anVoyKeGNn6RcPfbUyoXOVQhCYjeA V5ERi8gs46UpKCu5z4erRswymJxCmF5q02uAspMHRa6t4mBqzyyRzr1tmAqOrO9acUji lXrtwJc0C+WeuMRuHNpZ1MkLCgzPHrgx/Oo68pI385nbasDTTqlVmSFzvpDSTMubv4jE E6caSHM9FQ3bhdm6DcsB7CqLuKRs1gydtJtBlReJOEjKbxHoH94QXb6uC6tTZIaQN4lq 8PYA== X-Gm-Message-State: AKaTC01KUgt4JvPbtNBht4qh7xU5+JdAl28E8FTanPL0dhwH6XC4YBn/3JEXNkIQMqcDdbDviRErYrKtCkPBbQ== X-Received: by 10.55.99.141 with SMTP id x135mr129418qkb.147.1479338774976; Wed, 16 Nov 2016 15:26:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 16 Nov 2016 15:26:14 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 17 Nov 2016 08:26:14 +0900 Message-ID: To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] tweaks for ip-handling language 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, 16 Nov 2016 23:26:17 -0000 This looks like a good change on its own. However, reading the document, I find that the "all possible candidates" issue is hard to fix. This text is part of the rationale for the different modes. Placing a requirement here - before we've established the baseline - is probably the wrong thing to do. I think that restructuring the corresponding section might be the best plan. The text in question isn't rationale; it doesn't really belong where it is. Thus, I would recommend this structure: 1. define the 4 modes 2. recommend that mode 2 is the default. 3. include this text - tweaked slightly - to explain how user consent is necessary to use mode 1 4. explain that modes 3 and 4 might be made the default in certain contexts 5. include the other rationale to justify the design On 16 November 2016 at 16:25, Alissa Cooper wrote: > This still needs the fix for =E2=80=9Call possible candidates.=E2=80=9D > > OLD > Gathering all possible candidates SHOULD only be performed when some form= of user consent has been provided; this thwarts the typical drive-by enume= ration attacks. The details of this consent are left to the implementation= ; one potential mechanism is to key this off getUserMedia consent. The get= UserMedia suggestion takes into account that the user has provided some con= sent to the application already; that when doing so the user typically want= s to engage in a conversational session, which benefits most from an optima= l network path, and lastly, the fact that the underlying issue is complex a= nd difficult to explain, making explicit consent for enumeration troublesom= e. > > NEW > Gathering all possible candidates MUST only be performed when some form o= f user consent has been provided; this thwarts the typical drive-by enumera= tion attacks. The details of this consent are left to the implementation. = One potential mechanism is to tie this consent to getUserMedia consent. Suc= h a mechanism might be chosen based on the fact that the user has provided = some consent to the application already; that when doing so the user typica= lly wants to engage in a conversational session, which benefits most from a= n optimal network path, and lastly, the fact that the underlying issue is c= omplex and difficult to explain, making explicit consent for enumeration tr= oublesome. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Nov 16 15:58: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 D589E129400 for ; Wed, 16 Nov 2016 15:58:07 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 uNVpNq834VjU for ; Wed, 16 Nov 2016 15:58:06 -0800 (PST) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB1C1296D8 for ; Wed, 16 Nov 2016 15:57:42 -0800 (PST) Received: by mail-yb0-x22e.google.com with SMTP id d128so47394499ybh.2 for ; Wed, 16 Nov 2016 15:57:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L4xWu+H7wM57hJSCRcMUbesxFxuOXDDscF8fEh5faYk=; b=gDpvRLppNUFHSoW4MD7AXBN5BFq3FmBXUgRxmTG44vmLCqIoLpdo2afC7PMvaelmo5 HY1pstuMaIufpsB5ORvRKyKrgkvL7oH7b28EFEocCKTJjvIaWukl3Qxiy+p2B29kNc+d zFw5WuIddkwdWh9zxZXIjVIn5GUyqbN2gWyQGKB5rPAJoiUP9zklzIGbftfFz15G2vl7 B6FX8VCzcJl/YFddS/regDCx8R4xHs6lPmw6kYt7Pq1SOmo8GEn8BUiMT5tI6Wp1u8Rn z7CggRyofwJmNqMETL441NKIw7YxXNZORbTf4ybe+ovoIaFk4a/bVdWKikIK4Qt87bPz IQ7A== 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=L4xWu+H7wM57hJSCRcMUbesxFxuOXDDscF8fEh5faYk=; b=nAsdsg+8E6+iQltAiPhQudghBKCK6bZtSuMErMZUR6spJ6956nDXVKW2644+aVmcRW SHkibmhht9c6rInC0CYwZiNl89uFxRKMoOIeShkxfMQMzfYiaRwcjRZZyE3B7cDzhovw c6e48ks5tujdXpQLyhSFn5tS1lNx3s96aZzgPIinfNSMjwbNbmli40ZpT9ZlGNbsxE+g SPp0+8RsUQApQXsIqjoNWydBjGIbpA06IK7aKWSbCkA54j82OKYBYA5aoMWsxfpOcdv+ mzznZb2+d86kzSLCG1qotuXIpjkFxocsMNKLxWdq515zziElqN+cq1bd2lT25o1a2fog DZQQ== X-Gm-Message-State: AKaTC00d7GYyRxoWxlS+EZUgM+HRp8iK4eIo56xthErnXI3aEmEVrd0G5TELeLoziOgUSycbO3bw7MTgEFV7Xg== X-Received: by 10.37.171.169 with SMTP id v38mr126215ybi.80.1479340661648; Wed, 16 Nov 2016 15:57:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Wed, 16 Nov 2016 15:57:01 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 17 Nov 2016 08:57:01 +0900 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c050f4aa3f949054173d618 Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] tweaks for ip-handling language 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, 16 Nov 2016 23:58:08 -0000 --94eb2c050f4aa3f949054173d618 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I generally agree with Martin's comments, with the following exception. I would remove everything after "off getUserMedia consent." It has no normative effect and is simply rationale. -Ekr On Thu, Nov 17, 2016 at 8:26 AM, Martin Thomson wrote: > This looks like a good change on its own. However, reading the > document, I find that the "all possible candidates" issue is hard to > fix. This text is part of the rationale for the different modes. > Placing a requirement here - before we've established the baseline - > is probably the wrong thing to do. > > I think that restructuring the corresponding section might be the best > plan. The text in question isn't rationale; it doesn't really belong > where it is. > > Thus, I would recommend this structure: > 1. define the 4 modes > 2. recommend that mode 2 is the default. > 3. include this text - tweaked slightly - to explain how user consent > is necessary to use mode 1 > 4. explain that modes 3 and 4 might be made the default in certain contex= ts > 5. include the other rationale to justify the design > > > On 16 November 2016 at 16:25, Alissa Cooper wrote: > > This still needs the fix for =E2=80=9Call possible candidates.=E2=80=9D > > > > OLD > > Gathering all possible candidates SHOULD only be performed when some > form of user consent has been provided; this thwarts the typical drive-by > enumeration attacks. The details of this consent are left to the > implementation; one potential mechanism is to key this off getUserMedia > consent. The getUserMedia suggestion takes into account that the user ha= s > provided some consent to the application already; that when doing so the > user typically wants to engage in a conversational session, which benefit= s > most from an optimal network path, and lastly, the fact that the underlyi= ng > issue is complex and difficult to explain, making explicit consent for > enumeration troublesome. > > > > NEW > > Gathering all possible candidates MUST only be performed when some form > of user consent has been provided; this thwarts the typical drive-by > enumeration attacks. The details of this consent are left to the > implementation. One potential mechanism is to tie this consent to > getUserMedia consent. Such a mechanism might be chosen based on the fact > that the user has provided some consent to the application already; that > when doing so the user typically wants to engage in a conversational > session, which benefits most from an optimal network path, and lastly, th= e > fact that the underlying issue is complex and difficult to explain, makin= g > explicit consent for enumeration troublesome. > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --94eb2c050f4aa3f949054173d618 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I generally agree with Martin's comments, with the fol= lowing exception.

I would remove everything after "= off getUserMedia consent." It has no = normative effect
and is s= imply rationale.

-Ekr


On Thu, Nov 17, 2016 at 8:26 AM, Martin Th= omson <martin.thomson@gmail.com> wrote:
This looks like a good change on its own.=C2=A0 Howeve= r, reading the
document, I find that the "all possible candidates" issue is hard= to
fix.=C2=A0 This text is part of the rationale for the different modes.
Placing a requirement here - before we've established the baseline - is probably the wrong thing to do.

I think that restructuring the corresponding section might be the best
plan.=C2=A0 The text in question isn't rationale; it doesn't really= belong
where it is.

Thus, I would recommend this structure:
1. define the 4 modes
2. recommend that mode 2 is the default.
3. include this text - tweaked slightly - to explain how user consent
is necessary to use mode 1
4. explain that modes 3 and 4 might be made the default in certain contexts=
5. include the other rationale to justify the design


On 16 November 2016 at 16:25, Alissa Cooper <alissa@cooperw.in> wrote:
> This still needs the fix for =E2=80=9Call possible candidates.=E2=80= =9D
>
> OLD
> Gathering all possible candidates SHOULD only be performed when some f= orm of user consent has been provided; this thwarts the typical drive-by en= umeration attacks.=C2=A0 The details of this consent are left to the implem= entation; one potential mechanism is to key this off getUserMedia consent.= =C2=A0 The getUserMedia suggestion takes into account that the user has pro= vided some consent to the application already; that when doing so the user = typically wants to engage in a conversational session, which benefits most = from an optimal network path, and lastly, the fact that the underlying issu= e is complex and difficult to explain, making explicit consent for enumerat= ion troublesome.
>
> NEW
> Gathering all possible candidates MUST only be performed when some for= m of user consent has been provided; this thwarts the typical drive-by enum= eration attacks.=C2=A0 The details of this consent are left to the implemen= tation. One potential mechanism is to tie this consent to getUserMedia cons= ent. Such a mechanism might be chosen based on the fact that the user has p= rovided some consent to the application already; that when doing so the use= r typically wants to engage in a conversational session, which benefits mos= t from an optimal network path, and lastly, the fact that the underlying is= sue is complex and difficult to explain, making explicit consent for enumer= ation troublesome.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

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

--94eb2c050f4aa3f949054173d618-- From nobody Wed Nov 16 19:55:09 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 388F0129484 for ; Wed, 16 Nov 2016 19:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 QHT6zSbrmMUQ for ; Wed, 16 Nov 2016 19:55:05 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C178012949E for ; Wed, 16 Nov 2016 19:55:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E1A737C3C3E for ; Thu, 17 Nov 2016 04:55:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jb9cAek0xSQ for ; Thu, 17 Nov 2016 04:54:58 +0100 (CET) Received: from [IPv6:2001:67c:370:128:f80a:302c:408f:ee3] (t2001067c03700128f80a302c408f0ee3.v6.meeting.ietf.org [IPv6:2001:67c:370:128:f80a:302c:408f:ee3]) by mork.alvestrand.no (Postfix) with ESMTPSA id D3F7E7C3C3A for ; Thu, 17 Nov 2016 04:54:57 +0100 (CET) To: rtcweb@ietf.org References: From: Harald Alvestrand Message-ID: Date: Thu, 17 Nov 2016 04:54:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2E254D80E1534836434AF20E" Archived-At: Subject: Re: [rtcweb] tweaks for ip-handling language 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, 17 Nov 2016 03:55:08 -0000 This is a multi-part message in MIME format. --------------2E254D80E1534836434AF20E Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 11/17/2016 12:57 AM, Eric Rescorla wrote: > I generally agree with Martin's comments, with the following exception. > > I would remove everything after "off getUserMedia consent." It has no > normative effect > and is simply rationale. If we have rough consensus that the rationale is not unreasonable, I like leaving rationale in. > > -Ekr > > > On Thu, Nov 17, 2016 at 8:26 AM, Martin Thomson > > wrote: > > This looks like a good change on its own. However, reading the > document, I find that the "all possible candidates" issue is hard to > fix. This text is part of the rationale for the different modes. > Placing a requirement here - before we've established the baseline - > is probably the wrong thing to do. > > I think that restructuring the corresponding section might be the best > plan. The text in question isn't rationale; it doesn't really belong > where it is. > > Thus, I would recommend this structure: > 1. define the 4 modes > 2. recommend that mode 2 is the default. > 3. include this text - tweaked slightly - to explain how user consent > is necessary to use mode 1 > 4. explain that modes 3 and 4 might be made the default in certain > contexts > 5. include the other rationale to justify the design > > > On 16 November 2016 at 16:25, Alissa Cooper > wrote: > > This still needs the fix for “all possible candidates.” > > > > OLD > > Gathering all possible candidates SHOULD only be performed when > some form of user consent has been provided; this thwarts the > typical drive-by enumeration attacks. The details of this consent > are left to the implementation; one potential mechanism is to key > this off getUserMedia consent. The getUserMedia suggestion takes > into account that the user has provided some consent to the > application already; that when doing so the user typically wants > to engage in a conversational session, which benefits most from an > optimal network path, and lastly, the fact that the underlying > issue is complex and difficult to explain, making explicit consent > for enumeration troublesome. > > > > NEW > > Gathering all possible candidates MUST only be performed when > some form of user consent has been provided; this thwarts the > typical drive-by enumeration attacks. The details of this consent > are left to the implementation. One potential mechanism is to tie > this consent to getUserMedia consent. Such a mechanism might be > chosen based on the fact that the user has provided some consent > to the application already; that when doing so the user typically > wants to engage in a conversational session, which benefits most > from an optimal network path, and lastly, the fact that the > underlying issue is complex and difficult to explain, making > explicit consent for enumeration troublesome. > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. --------------2E254D80E1534836434AF20E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 11/17/2016 12:57 AM, Eric Rescorla wrote:
I generally agree with Martin's comments, with the following exception.

I would remove everything after "off getUserMedia consent." It has no normative effect
and is simply rationale.

If we have rough consensus that the rationale is not unreasonable, I like leaving rationale in.



-Ekr


On Thu, Nov 17, 2016 at 8:26 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
This looks like a good change on its own.  However, reading the
document, I find that the "all possible candidates" issue is hard to
fix.  This text is part of the rationale for the different modes.
Placing a requirement here - before we've established the baseline -
is probably the wrong thing to do.

I think that restructuring the corresponding section might be the best
plan.  The text in question isn't rationale; it doesn't really belong
where it is.

Thus, I would recommend this structure:
1. define the 4 modes
2. recommend that mode 2 is the default.
3. include this text - tweaked slightly - to explain how user consent
is necessary to use mode 1
4. explain that modes 3 and 4 might be made the default in certain contexts
5. include the other rationale to justify the design


On 16 November 2016 at 16:25, Alissa Cooper <alissa@cooperw.in> wrote:
> This still needs the fix for “all possible candidates.”
>
> OLD
> Gathering all possible candidates SHOULD only be performed when some form of user consent has been provided; this thwarts the typical drive-by enumeration attacks.  The details of this consent are left to the implementation; one potential mechanism is to key this off getUserMedia consent.  The getUserMedia suggestion takes into account that the user has provided some consent to the application already; that when doing so the user typically wants to engage in a conversational session, which benefits most from an optimal network path, and lastly, the fact that the underlying issue is complex and difficult to explain, making explicit consent for enumeration troublesome.
>
> NEW
> Gathering all possible candidates MUST only be performed when some form of user consent has been provided; this thwarts the typical drive-by enumeration attacks.  The details of this consent are left to the implementation. One potential mechanism is to tie this consent to getUserMedia consent. Such a mechanism might be chosen based on the fact that the user has provided some consent to the application already; that when doing so the user typically wants to engage in a conversational session, which benefits most from an optimal network path, and lastly, the fact that the underlying issue is complex and difficult to explain, making explicit consent for enumeration troublesome.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

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



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



-- 
Surveillance is pervasive. Go Dark.
--------------2E254D80E1534836434AF20E-- From nobody Wed Nov 16 22:52:06 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 C888212943D for ; Wed, 16 Nov 2016 22:52:04 -0800 (PST) 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 Hs84pxbkCON0 for ; Wed, 16 Nov 2016 22:52:01 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 C3A5212948D for ; Wed, 16 Nov 2016 22:52:01 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id w33so123720713qtc.3 for ; Wed, 16 Nov 2016 22:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=9/SG5jlPLLzQ20CzmY1VeMRob1XugkM/VvDkVJBRbrA=; b=Zqv0thQGgdu+8uHchIcMVJTOJp99xnPVeO1ZbiLrYN2GaN23I49b2nnHRcHUc0kzVe AJDdndFxgZlbfLIOb3pfqLgqAD3/HCxU9p1EXN91Xl+PpYVl7UilB7lQl5PSxf6Vj/0/ eBAmbMuz+zUZKrFfmeHgvoIUz5mZzZywkJhXMZXOPXJBOFA+eiPyktBA8IKconl6Tkie RAdCg8zeRHdypp/1+LsOLpDTSo+/G9irIiIu+YNFH/7vKYLyZ5/yYUAA0uiP2BGMbsGO /i7iM0THFipmUd0TxtLAu/Fh/FgunWq5Zt89KR3cYQHrPKhaXukDfggf7WojxehbjgSS J9tQ== 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=9/SG5jlPLLzQ20CzmY1VeMRob1XugkM/VvDkVJBRbrA=; b=nHIMnnXk4t1QDK6/x2RX3JcsmPqTplP6v9V/XdI792DzMBLO4yEM4Wmby5RMJPghKM IqvswXBLCeNHOJI5Uu+QXSZ0J1cdBt3S2Z7WW7EfXK7J9wtPESoCwkTm2vBVNirsWOHF cAgZst0Cl1lmICVJn+OIj2lj7I7e1n5SALDkQ/SMKeg1OxOkL1g3FvHX9IIxu73knyKi R17wMPpDKmdbo3TZDMj/4u7A7/BYvxHgAQMlVwzbjJwM9VVCYFioPQPW/II8Nro46xk1 881WWCOGf2+zoQMMfgsfXid7AtvphOXH8bVCJ2IMFhiGcrEnGaIFXaiJ5obwKT2ZD953 kulQ== X-Gm-Message-State: AKaTC02pm4oC8IUynSM4DFJ58c6kGAISucTyGw3xEfdjcvMFiWyhDKuK+H04mF0PezH02/Dq6VY9tdJNlyaA2w== X-Received: by 10.200.56.186 with SMTP id f55mr829602qtc.75.1479365520894; Wed, 16 Nov 2016 22:52:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.165.100 with HTTP; Wed, 16 Nov 2016 22:51:30 -0800 (PST) From: Ted Hardie Date: Thu, 17 Nov 2016 15:51:30 +0900 Message-ID: To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=001a113978b45db3da054179a03c Archived-At: Subject: [rtcweb] Agenda for Friday's meeting 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, 17 Nov 2016 06:52:05 -0000 --001a113978b45db3da054179a03c Content-Type: text/plain; charset=UTF-8 The key thing for tomorrow's meeting is nailing down the text on the IP handling. We will do that, and then ask for any known issues against the security drafts, which have been dormant for a long time (we had anticipated some external reviews, which did not happen, so the issues list will be small). I am hopeful that the meeting will be much shorter than the allotted time, given the small number of items, but we really want to close on IP handling this week, so it does not come back to the list without a sense of the room. thanks, Ted --001a113978b45db3da054179a03c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The key thing for tomorrow's meeting is= nailing down the text on the IP handling.=C2=A0 We will do that, and then = ask for any known issues against the security drafts, which have been dorma= nt for a long time (we had anticipated some external reviews, which did not= happen, so the issues list will be small).=C2=A0

I am hopefu= l that the meeting will be much shorter than the allotted time, given the s= mall number of items, but we really want to close on IP handling this week,= so it does not come back to the list without a sense of the room.

<= /div>thanks,

Ted
--001a113978b45db3da054179a03c-- From nobody Thu Nov 17 18:15:23 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 0016A1299FD for ; Thu, 17 Nov 2016 18:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 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_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 E8EdIUGY18As for ; Thu, 17 Nov 2016 18:15:20 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2FF129A00 for ; Thu, 17 Nov 2016 18:15:17 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id q130so246757614qke.1 for ; Thu, 17 Nov 2016 18:15:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=XIZ4fqJkH+qSIzS4mNBI+DJ8uxt9JBiEkqoUnnzmfp8=; b=ObMfhSNQOb/lTY/aXj9aa8hSYLhilEUoyRyOHl5SUc4ZupK6eVXhVHNeFZzgGTfb0R mtjK/HmMe94MHWMQRbi4kcB/jWSxqVoZSQmUPdXPC7UDoaZC7vnll3GzhIdr3s4AAoyH rZj/dJF692amw/Kt0mwvEavdXqI30qYU1oPQfD9kPJMX1MaTLLveduxdcFfaZTeb7Znv LGMLwVhgopFG3Ah5JUx/LjaCtv+OYDi3VyPO67DGywoN44VcbzFN6gwW0y8+9eRMV2Dm hVlJpNpC+//WwDzJMIz5HZ95gjZoDY+cbP90sWtd5epb+UasEf3mY8R5KV99FPv1K86O VbYQ== 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=XIZ4fqJkH+qSIzS4mNBI+DJ8uxt9JBiEkqoUnnzmfp8=; b=bpwNPsBFLbNHqjV0MiC9+boQrqC3QyuNnhcAP4baI2Bfte0P+2DzFAySldbl7JK2xn H6/PHFjWuhYihxHaN6spI5u6JFM+ZAwZ56Ad1j0YMzNThCWg333/4/Bot4lg32LIjr9j AVakz4jlNGz85qpa+rdN1EukitmwgUwr9+3lUsk1RLVLMaSTO1X0k9w6rBGmtFVdgWQJ w8LIzvTwwx7jXo8D/t8ZUQRiebernum9VwSAyJPesPJCHJJVGpm0HHClgsxqS46Vrykp xYqar9xtEk++9aSIQOUTgJhwM73hSA6qYzq/UIk2y2nzGAN29NFZxCNchzRCkjqsNbeJ FJGA== X-Gm-Message-State: AKaTC01RIICWeMoc5qNwGW+I+jzeorX9rgUAi3Ui+THf6EQVNwa7eNXhAz4Stv4Q4aKFeWhTqhoE6CaUgDJcwSBe X-Received: by 10.55.106.134 with SMTP id f128mr8280819qkc.121.1479435316733; Thu, 17 Nov 2016 18:15:16 -0800 (PST) MIME-Version: 1.0 From: Peter Thatcher Date: Fri, 18 Nov 2016 02:15:05 +0000 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a114fddf6862465054189e0e2 Archived-At: Subject: [rtcweb] Pull Requests for moving the demux algorithm from JSEP to BUNDLE 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, 18 Nov 2016 02:15:22 -0000 --001a114fddf6862465054189e0e2 Content-Type: text/plain; charset=UTF-8 In the RTCWEB meeting on Wednesday, Cullen mentioned we would make two PRs to move the demux algorithm from JSEP to BUNDLE, one in JSEP and one in BUNDLE. I have made those two PRs: https://github.com/rtcweb-wg/jsep/pull/411/files https://github.com/cdh4u/draft-sdp-bundle/pull/16/files --001a114fddf6862465054189e0e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the RTCWEB meeting on Wednesday, Cullen mentioned we wo= uld make two PRs to move the demux algorithm from JSEP to BUNDLE, one in JS= EP and one in BUNDLE.=C2=A0 I have made those two PRs:

<= a href=3D"https://github.com/rtcweb-wg/jsep/pull/411/files">https://github.= com/rtcweb-wg/jsep/pull/411/files



<= /div>
--001a114fddf6862465054189e0e2-- From nobody Thu Nov 17 18:57: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 C04341299FD for ; Thu, 17 Nov 2016 18:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 t-QaaSurBLgv for ; Thu, 17 Nov 2016 18:57:39 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D271299F7 for ; Thu, 17 Nov 2016 18:57:39 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id n204so247770999qke.2 for ; Thu, 17 Nov 2016 18:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sT4i9YWMyfRKdSinh8TSL8IMcA741UJ46TGglpwXH4I=; b=CvdBWpS2bah/fWtz8taCzEXB06box1Dq5FlZiOcCBPYL5c2DDiLUCo0W6ZtzEc5Hab fUD9cn7EillosXVzd0BItyCLjVVL2cKXPKpjAYRkRC7XlK3SPeWHM3BPbOxzeRgvQXf/ aW1ssd0l//1HXgaPO1Fyovc9LB3HDL9jzfqeUSzL/fUJ3wQhh9Z/fn/guPjfnaF5Wetp v4nYxOsR466RxCYfhSlvfeKsvKyp2zbFI/xNcSbIDw0WuA8dm70Vkd+rLpimzYT+DFxU Lcqr3lxTVKqK19dV7DCOYGyujehiJ0l6rgj1HYHni5zyPOwfz0xqgsq5Ln++vKwpMyGa gBqg== 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=sT4i9YWMyfRKdSinh8TSL8IMcA741UJ46TGglpwXH4I=; b=FUOZa4dGbeyr678LISX9QhC0phJlE4P4GVoE/1exdPbt6OT6r12Omyaa+MXH/IIlN1 y1/Ng9OGCA81b0JgzHhpl15DznbpmpXYZsfIs04y7LE5KvtPJHtZTddVPT7mdDMTGf4Z zqAaAadXXfLxScdsG+/sXTt+qajMShy9qV4FIrqn+PQm+aoyqGWChDc7FFJHhN/xO0eZ nJdMoHMO5XsW6GJzgETe4QczT0wFl7FlBPkEFEScMm47ZEGEGB5lBTWCmQIEC8P8Ip98 4hLrvQCgA8PcimZiitDNHY38IYfEq+yvWck53ngfv2h+9z3Z3dNa0794ROGD9GKZo87e 4VTA== X-Gm-Message-State: AKaTC02u7Wurjbp7igI2LKqXmgYgXa0+SXmwFIZEc5HTdoCuD0ybHO+ISuTY5aBp0O6RunLaYPS9dnusNe53Aw== X-Received: by 10.55.99.141 with SMTP id x135mr7433701qkb.147.1479437858635; Thu, 17 Nov 2016 18:57:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 17 Nov 2016 18:57:38 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 18 Nov 2016 11:57:38 +0900 Message-ID: To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] tweaks for ip-handling language 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, 18 Nov 2016 02:57:42 -0000 Taking ekr's suggestion... 4. Detailed Design We define four modes of WebRTC behavior, reflecting different privacy/media tradeoffs: Mode 1: Enumerate all addresses: WebRTC will bind to all interfaces individually and use them all to attempt communication with STUN servers, TURN servers, or peers. This will converge on the best media path, and is ideal when media performance is the highest priority, but it discloses the most information. As such, this should only be performed when the user has explicitly given consent for local media access, as indicated in design idea #3 above. Mode 2: Default route + the single associated local address: By binding solely to the wildcard address, media packets will follow the kernel routing table rules, which will typically result in the same route as the application's HTTP traffic. In addition, the associated private address will be discovered through getsockname, as mentioned above. This ensures that direct connections can still be established even when local media access is not granted, e.g., for data channel applications. Mode 3: Default route only: This is the the same as Mode 2, except that the associated private address is not provided, which may cause traffic to hairpin through a NAT, fall back to the application TURN server, or fail altogether, with resulting quality implications. Mode 4: Force proxy: This forces all WebRTC media traffic through a proxy, if one is configured. If the proxy does not support UDP (as is the case for all HTTP and most SOCKS [RFC1928] proxies), or the WebRTC implementation does not support UDP proxying, the use of UDP will be disabled, and TCP will be used to send and receive media through the proxy. Use of TCP will result in reduced quality, in addition to any performance considerations associated with sending all WebRTC media through the proxy server. Mode 1 MUST NOT be used without user consent. User agents SHOULD use Mode 2 by default, though they might choose a stricter default polic= y in certain circumstances. Gathering all possible candidates MUST only be performed when some form of user consent has been provided; this thwarts the typical drive-by enumeration attacks. The details of this consent are left to the implementation. One potential mechanism is to tie this consent to getUserMedia consent. The main ideas for the design are the following: 1. By default, WebRTC should follow normal IP routing rules, to the extent that this is easy to determine (i.e., not considering proxies). This can be accomplished by binding local sockets to the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to route WebRTC traffic the same way as it would HTTP traffic, and allows only the 'typical' public addresses to be discovered. 2. By default, support for direct connections between hosts (i.e., without traversing a NAT or relay server) should be maintained. To accomplish this, the local IPv4 and IPv6 addresses of the interface used for outgoing STUN traffic should still be surfaced as candidates, even when binding to the wildcard addresses as mentioned above. The appropriate addresses here can be discovered by the common trick of binding sockets to the wildcard addresses, connect()ing those sockets to some well-known public IP address (one particular example being "8.8.8.8"), and then reading the bound local addresses via getsockname(). This approach requires no data exchange; it simply provides a mechanism for applications to retrieve the desired information from the kernel routing table. 4. Determining whether a web proxy is in use is a complex process, as the answer can depend on the exact site or address being contacted. Furthermore, web proxies that support UDP are not widely deployed today. As a result, when WebRTC is made to go through a proxy, it typically must use TCP, either ICE-TCP [RFC6544] or TURN-over-TCP [RFC5766]. Naturally, this has attendant costs on media quality and also proxy performance. 5. RETURN [I-D.ietf-rtcweb-return] is a new proposal for explicit proxying of WebRTC media traffic. When RETURN proxies are deployed, media and STUN checks will go through the proxy, but without the performance issues associated with sending through a typical web proxy. Note that when a RETURN proxy is configured for the interface associated with the default route, Mode 2 and 3 will cause any external media traffic to go through the RETURN proxy. This provides a way to ensure the proxy is used for external traffic, but without the performance issues of forcing all media through said proxy. On 17 November 2016 at 08:26, Martin Thomson wro= te: > This looks like a good change on its own. However, reading the > document, I find that the "all possible candidates" issue is hard to > fix. This text is part of the rationale for the different modes. > Placing a requirement here - before we've established the baseline - > is probably the wrong thing to do. > > I think that restructuring the corresponding section might be the best > plan. The text in question isn't rationale; it doesn't really belong > where it is. > > Thus, I would recommend this structure: > 1. define the 4 modes > 2. recommend that mode 2 is the default. > 3. include this text - tweaked slightly - to explain how user consent > is necessary to use mode 1 > 4. explain that modes 3 and 4 might be made the default in certain contex= ts > 5. include the other rationale to justify the design > > > On 16 November 2016 at 16:25, Alissa Cooper wrote: >> This still needs the fix for =E2=80=9Call possible candidates.=E2=80=9D >> >> OLD >> Gathering all possible candidates SHOULD only be performed when some for= m of user consent has been provided; this thwarts the typical drive-by enum= eration attacks. The details of this consent are left to the implementatio= n; one potential mechanism is to key this off getUserMedia consent. The ge= tUserMedia suggestion takes into account that the user has provided some co= nsent to the application already; that when doing so the user typically wan= ts to engage in a conversational session, which benefits most from an optim= al network path, and lastly, the fact that the underlying issue is complex = and difficult to explain, making explicit consent for enumeration troubleso= me. >> >> NEW >> Gathering all possible candidates MUST only be performed when some form = of user consent has been provided; this thwarts the typical drive-by enumer= ation attacks. The details of this consent are left to the implementation.= One potential mechanism is to tie this consent to getUserMedia consent. Su= ch a mechanism might be chosen based on the fact that the user has provided= some consent to the application already; that when doing so the user typic= ally wants to engage in a conversational session, which benefits most from = an optimal network path, and lastly, the fact that the underlying issue is = complex and difficult to explain, making explicit consent for enumeration t= roublesome. >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Nov 17 19:07:28 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 DC996129A00 for ; Thu, 17 Nov 2016 19:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 4sTo6DSdaHKp for ; Thu, 17 Nov 2016 19:07:25 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B9B129784 for ; Thu, 17 Nov 2016 19:07:25 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id q130so247844311qke.1 for ; Thu, 17 Nov 2016 19:07:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=wp0a58VFtgw4q0FZ62i5Xx4Fl2E9IiBaz01F40TuEPU=; b=g0gmyLB4ajnx43qalJdaTXOQdSJwfSUORHYmUQk6o6uNFfk0TV+mbZkc5ioLuuLP6X Na/XrAXGdFbnwBKEF6U9CB1h/Pv144/6LSgX4MyUUxqWtIfxgNvEBc2xVhm2QVXIBXRr +8Rgf29l4w9W86LtCc2yYcBYK9fcOStzroSVUQisGV2SeGunkKXWLVdI5vzrKRJmvbQJ SBgVuhYW7ECc7PbXnKnTRwvW3/gaZlch4GCD/EAj4To4I4WhAp3JkGRUHBwHK7fSWvcJ rWHbM8acokxIb4ldfWBpaE/fWxdmcLyQAOUotxx7zz8QhWrK1TlB70keNoJNKDb2TGEE HbXQ== 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=wp0a58VFtgw4q0FZ62i5Xx4Fl2E9IiBaz01F40TuEPU=; b=EpJXp+evOH9sC1uJxStTY94KHLvpsEJUhOCVrGccnCfLP7SOqW8oMbWa9SNZMlMXzg KRJPDOaFW/SaGmRhxyd2L+G+XlWDlrUbgqVw8kz9wIII7cn2rjtRKh8ALxGkNt8ZLpri iX/qfXllvVOiSFn+54rrYInDvpgn9VWeQalP7ogkbbuTtzc9cHmRI5cOyxB44OcDCJPj QYLCun2RggDV2fog4Qy5xN6+O5Vk7hbCa7nC53XgRTVcefi2ahwgTfAwjD8F/W35SibX oJmvyiLpA8Jl08K4YI9J7lIsKbPfJxTfM1g8VRzl8VflicNehHvTW4uxrWosE/wWlsv1 Aq/A== X-Gm-Message-State: AKaTC037yBOvc3o3c08ZYw0Os7Kbmemqn/mox+EcAugt53s1g0SUSJWYuaJI9gdy7RuyI+b7qT7lvqPxWbUCRQ== X-Received: by 10.55.12.2 with SMTP id 2mr7834123qkm.68.1479438444350; Thu, 17 Nov 2016 19:07:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 17 Nov 2016 19:07:23 -0800 (PST) From: Martin Thomson Date: Fri, 18 Nov 2016 12:07:23 +0900 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [rtcweb] IP handling text 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, 18 Nov 2016 03:07:27 -0000 4. Detailed Design We define four modes of WebRTC behavior, reflecting different privacy/media tradeoffs: Mode 1: Enumerate all addresses: WebRTC will bind to all interfaces individually and use them all to attempt communication with STUN servers, TURN servers, or peers. This will converge on the best media path, and is ideal when media performance is the highest priority, but it discloses the most information. Mode 2: Default route + the single associated local address: By binding solely to the wildcard address, media packets will follow the kernel routing table rules, which will typically result in the same route as the application's HTTP traffic. In addition, the associated private address will be discovered through getsockname, as mentioned above. This ensures that direct connections can still be established even when local media access is not granted, e.g., for data channel applications. Mode 3: Default route only: This is the the same as Mode 2, except that the associated private address is not provided, which may cause traffic to hairpin through a NAT, fall back to the application TURN server, or fail altogether, with resulting quality implications. Mode 4: Force proxy: This forces all WebRTC media traffic through a proxy, if one is configured. If the proxy does not support UDP (as is the case for all HTTP and most SOCKS [RFC1928] proxies), or the WebRTC implementation does not support UDP proxying, the use of UDP will be disabled, and TCP will be used to send and receive media through the proxy. Use of TCP will result in reduced quality, in addition to any performance considerations associated with sending all WebRTC media through the proxy server. Mode 1 MUST NOT be used without user consent. This thwarts the typical drive-by enumeration attacks. The details of this consent are left to the implementation. One potential mechanism is to tie this consent to getUserMedia consent. User agents SHOULD use Mode 2 by default, though they might choose a stricter default policy in certain circumstances. The main ideas for the design are the following: 1. By default, WebRTC should follow normal IP routing rules, to the extent that this is easy to determine (i.e., not considering proxies). This can be accomplished by binding local sockets to the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to route WebRTC traffic the same way as it would HTTP traffic, and allows only the 'typical' public addresses to be discovered. 2. By default, support for direct connections between hosts (i.e., without traversing a NAT or relay server) should be maintained. To accomplish this, the local IPv4 and IPv6 addresses of the interface used for outgoing STUN traffic should still be surfaced as candidates, even when binding to the wildcard addresses as mentioned above. The appropriate addresses here can be discovered by the common trick of binding sockets to the wildcard addresses, connect()ing those sockets to some well-known public IP address (one particular example being "8.8.8.8"), and then reading the bound local addresses via getsockname(). This approach requires no data exchange; it simply provides a mechanism for applications to retrieve the desired information from the kernel routing table. 4. Determining whether a web proxy is in use is a complex process, as the answer can depend on the exact site or address being contacted. Furthermore, web proxies that support UDP are not widely deployed today. As a result, when WebRTC is made to go through a proxy, it typically must use TCP, either ICE-TCP [RFC6544] or TURN-over-TCP [RFC5766]. Naturally, this has attendant costs on media quality and also proxy performance. 5. RETURN [I-D.ietf-rtcweb-return] is a new proposal for explicit proxying of WebRTC media traffic. When RETURN proxies are deployed, media and STUN checks will go through the proxy, but without the performance issues associated with sending through a typical web proxy. Note that when a RETURN proxy is configured for the interface associated with the default route, Mode 2 and 3 will cause any external media traffic to go through the RETURN proxy. This provides a way to ensure the proxy is used for external traffic, but without the performance issues of forcing all media through said proxy. From nobody Thu Nov 17 19:24: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 310811293D8 for ; Thu, 17 Nov 2016 19:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 cwDWpCxNzypA for ; Thu, 17 Nov 2016 19:24:47 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214991294B9 for ; Thu, 17 Nov 2016 19:24:47 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id x190so247689281qkb.0 for ; Thu, 17 Nov 2016 19:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=iT6WUgB8KuM1XaLRqvNdtNbgneyk9on8HxxPKyFPJcM=; b=nDyme21LmflYgQZ5DqsTo6hZIoe5qdTBLHxX9w/ncNERaLAOKuRra0xpykDX8Db+1j i0uDWdsoWuots2yKotqGRbWKobYvXWE+u3VFbgSZFLLqEs8IPa2X2yWsoKOcmWydWtrn l6WT6jMrXOiUEJKNLEbkIkdMzQ4xWgoLjNEzY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=iT6WUgB8KuM1XaLRqvNdtNbgneyk9on8HxxPKyFPJcM=; b=XETE+04/hapdx10PTssX6xXPmxZTlL1agZsNZC/nf5vMK2oBjJlrVUzfFYVHPmEzCA DP8KRe2Anv4oTCMcLF+03SYpEU850Egh4xEJIcgnwDgcJ0NeNEtml2cGSrmWLphWxhX7 y1Ig5wT2H0cSTCl6YfeFTc86maMtYTYkGgPL/MSU7ESNTpuCCZKt+d7rYJ/pLg9ylK87 8YKa04qJhCws4Trd3zNaQp/Ejv7Lv5OxXAW2ypfqTRcyrtPjAIff0TREgToqTZPv6YQA HImcxW/sMpGhlhI9DX21iyFNO0lu/1t5bZYJJyoQKseZS+0Us7pTqkECd+M5LRb5a6EU JSNg== X-Gm-Message-State: AKaTC02sYP6Fa4hTvT5bMnk+hTWgJ/syc5DSov25cNjHlZU63ETBv6EjcRoAFRCi+YTpBw== X-Received: by 10.55.141.199 with SMTP id p190mr8066958qkd.232.1479439486195; Thu, 17 Nov 2016 19:24:46 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:b9df:82e8:a23b:4ec0? ([2001:67c:370:128:b9df:82e8:a23b:4ec0]) by smtp.gmail.com with ESMTPSA id n191sm3085134qke.19.2016.11.17.19.24.45 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Nov 2016 19:24:45 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4DE32636-8749-43BD-A910-C03FFC358095@sn3rd.com> Date: Fri, 18 Nov 2016 12:24:22 +0900 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] WGLC: draft-ietf-rtcweb-overview 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, 18 Nov 2016 03:24:50 -0000 This is a working group last call for the "Overview: Real Time Protocols = for Browser-based Applications" draft available @ = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/. Please = review this draft and send your comments to the list by 9 December 2016.=20= Thanks, T,C,&S= From nobody Thu Nov 17 19:44:53 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 DF1D41295C8 for ; Thu, 17 Nov 2016 19:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 SZXIg4tUVXBT for ; Thu, 17 Nov 2016 19:44:50 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F16E1293D6 for ; Thu, 17 Nov 2016 19:44:50 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id x190so248075388qkb.0 for ; Thu, 17 Nov 2016 19:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=2KP2uG4sl/qdKwm78YUid2aCDFxi4kCpcStlFIgATKU=; b=uudKRg0dw1seEqEx55vhSo/udLYJSPzs7ruC83Bqp67WJHdh0ux78mmFbBt6s6Gl6G aN1iBxMZ2FPMMIU+dHkoE2cEUggoox8t9OkEBU4yTaSDfX/MtXm4yCneuQh9UDnbep0m O3Ux9zD11Stx0yGXdY3icAGC4cxMclGBs1EXv5xlO8U+HsgxspkaoM/k/8sBFp0I/ioW 3snOyqpM7oW9/JXkx2w0yivI/JeuoRJ+B+yZMGRpvJsgj3l+A0Q7h3zlBfqWYvVQZRl/ biRfctRlG2zwRYHiKyhbx9EmwMMoyvsPbqnGF/7QMFOa9HeDfLl9tL0EhoPjYYQ462oF tkzQ== 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=2KP2uG4sl/qdKwm78YUid2aCDFxi4kCpcStlFIgATKU=; b=au1jzt6CYP8KXFC6lj42ZIEoPvuzrcfRxk8oUgydQbxWnqWlZoCzBxVX85sleQs3xv aO0Dw9DparEmxaQWf3nZ6dL9IJSN9xLn3L1mmPVnhGG6KhHQA3xEITYEHiVdV+Ga82Jg Rv8KCW5R5MO7wCxVr2tgawUxjLh3R8HTIrC138TaZU+s/AjjDM97PGq7+dAkyXESikXI 91JA/yFMVMspBtt464a+/La0xvFZMVpkh9w72HcQbDdUSEgDzHFnZwyrBJ9H1pQlk3Jl 0yzz/GOLum2s/SzZ91cTw5f7hMvIcagNUCHqo8X1Fr0h/TyjSJz9LHNB5SNOMbL6Jo7V W9jA== X-Gm-Message-State: AKaTC00Bg0jQ5/+iuZcMLMoWHyxUhwDQ5XPy/Yh7spzWz6T9EGrvkKGvx89bviLjKwdZkZLHd04HD0oLWFYTMg== X-Received: by 10.55.74.1 with SMTP id x1mr8494247qka.316.1479440689374; Thu, 17 Nov 2016 19:44:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 17 Nov 2016 19:44:48 -0800 (PST) From: Martin Thomson Date: Fri, 18 Nov 2016 12:44:48 +0900 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [rtcweb] PR for changes discussed today 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, 18 Nov 2016 03:44:52 -0000 https://github.com/juberti/draughts/pull/30 I fixed the markers that were obvious. I separately opened an issue on the definition of proxy. https://github.com/juberti/draughts/issues/29 From nobody Fri Nov 18 00:02:47 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 E303A1294C1 for ; Fri, 18 Nov 2016 00:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 ySInjJaW53eE for ; Fri, 18 Nov 2016 00:02:42 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5221294AE for ; Fri, 18 Nov 2016 00:02:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 09C317C3C74 for ; Fri, 18 Nov 2016 09:02:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4SN3t6ppZ7a for ; Fri, 18 Nov 2016 09:02:38 +0100 (CET) Received: from [10.35.133.196] (unknown [58.123.138.206]) by mork.alvestrand.no (Postfix) with ESMTPSA id ABA667C3C43 for ; Fri, 18 Nov 2016 09:02:37 +0100 (CET) To: rtcweb@ietf.org References: <3ec33eba-b130-e986-0fce-ab97f8d0e601@alvestrand.no> From: Harald Alvestrand Message-ID: <1fb6bb68-127b-c42b-ea89-d305ddc2e49e@alvestrand.no> Date: Fri, 18 Nov 2016 09:02:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <3ec33eba-b130-e986-0fce-ab97f8d0e601@alvestrand.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] HTA's review of JSEP-17 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, 18 Nov 2016 08:02:46 -0000 Finally found the peace of mind to get these into the github buganizer. On 11/13/2016 11:43 PM, Harald Alvestrand wrote: > Long plane rides have advantages. > > These are my notes; I will file github issues in a few hours on the > points where I think we need discussion. > > Overall, this draft looks almost ready to go. It seems comprehensive > (sometimes mind-numbingly so), and I think we will learn little more by= > going over it in theory; now it's time to take the software we've > written, match it up against the spec, and see if we can make them matc= h. > > That said, there are issues. Some of which I have noted below. > > - Agree with Magnus on the need for a terminology section. It would be > nice to choose just one out of "media section" vs "m=3D section", but i= f > you really want both, please define the two terms as being equal. Added to #387 > > - Section 1.1: Leftover mention of modifying the offer before doing > set-local-description. The text should instead say "inspect, and if you= > don't like it, change settings and iterate". Filed as #412 > > - Section 3.6: "all dimensions assume square pixels". Given the > affordance for non-square pixels elsewhere, I think this should say "al= l > dimensions are measured in pixels, whether square or not". Filed as #413 > > - Section 3.6.1 describes mandatory constraints applied to an incoming > track resulting in a new offer-answer exchange. Since this is "action a= t > a distance" (modify the track and the PeerConnection emits a > negotiation-needed), I think this needs to be synced with the webrtc-1.= 0 > API spec, and possibly even media-capture. > > Also, what's the state of the track between the changing of constraints= > at the receiver and the renegotiation? It seems to me that the track > should be scaled at the receiver to fit the agreed-upon constraints. Filed as #414. > > - Section 3.6.1 "no resolutions .. SHOULD be represented by x=3D0 and y= =3D0 > values". Is there any reason not t o make this a MUST? Filed as #415 > > - Section 3.6.1 gives an example with a minimum resolution of 16x16 - > where did that come from? If we want to admit to the existence of > macroblocks, we may want to say that the implementation can specify ste= p > sizes (typically 16) in its imageattr values. Filed as #416 > > - Section 3.7 Simulcast - I'm not sure it's true that the information > about number of layers is not surfaced through any API - the number of > elements in the encoding list, and their active/passive state, which is= > accessible through getSettings(), should surely give a hint about this.= Filed as #417, with suggestion to remove text. > > - Section 3.8.2 - "the media flow from these sessions can be managed by= > specifying SDP direction attributes in the descriptions". This seems ou= t > of place. Surely flipping track.muted is a much simpler way of managing= > them if the problem is what to play to the user? Filed as #418 > > - Section 4.1.1 - the description of "relay" - is it worth noting that > the degre of obfuscation is under the control of the application based > on its choice of turn servers? And that browser-configured turn servers= > also matter here? Filed as #419 > > - Section 4.1.2 addTrack: Worth noting that using addTransceiver in > have-remote-offer will cause negotiaiton-needed to be fired when the > track returns to stable? Filed as #420 > > - Section 4.1.5 createOffer: The statement about this being async is > either a requirement or out of scope. I'd suggest out of scope (it is > purely an API property); the alternative is saying "it is an async > operation". Filed as #421 > > - Section 4.1.7.1 - the term "inactive" final answer is introduced > without a defintion. Need to either define "inactive" or use another te= rm. > > - Section 4.1.7.2 Rollback - "and possibly the answerer as well" is > wishy-washy. Suggest "and the answerer if it has done > set-remote-description". > > - Section 4.1.7.2 This is the first mention of "pending local / remote > description". Suggest link to definition. > > - Section 4.1.7.2 "RTPTransceivers that were created by applying a > remote offer that was subsequently rolled back MUST be removed". The > term "removed" is undefined. Deleted, discarded, destroyed or detached > from the PeerConnection? Suggestion: "stopped and removed from the > PeerConnection". (if the JS app still has a reference to them, it may > still inspect the object). Filed as #422 (merged) > > - Section 4.1.8 setLocalDescription - "the PeerConnection must be able > to simultaneously support... until a final answer is received". This is= > unclear for several reasons - suggest "while the connection is in the > have-local-offer or have-remote-pranswer state". (There's a race > condition here between media and signalling, of course.) > > - Section 4.1.10 currentLocalDescription - "a copy of the current > negotiated local description" is ambiguous (see issue raised in > webrtc-1.0 - https://github.com/w3c/webrtc-pc/issues/921). Suggest > making language here less normative - "shows the current negotiated > local description" would probably be weak enough. > > - Section 4.1.15 setConfiguration - "and may result in a change to medi= a > state". Not sure this belongs here - it can lead to a cascade of events= > that may end up changing media state, but it is not the call that > directly causes the change. Suggest deleting. > > - Section 4.1.16 addIceCandidate - suggest deleting the > "end-of-candidates" text here, and saying separately that there is a > means of indicating end of candidates. There seems to be consensus that= > mixing the two was an API design mistake, discussions are about how to > get out of it. Filed as #423 > > - Section 4.2.4 setCodecPreferences - "However, the codec preferences > cannot change the order of the media formats after an answer containing= > the transceiver has been applied". I don't understand why we can't > change the order in order to have the new order reflected on the next > offer/answer exchange - there would be no immediate effect, but the > current language locks in the order permanently, without a clear > justification for why it has to be that way. Filed as #424 > > - Sction 5.1.1 R-16: TODOs should be deleted before Last Call :-) Also= > sugggest renumbering the trailing sentence as R-16. > > - Section 5.1.2: Suggest using a different letter on the numbering. U-1= > and U-2? Filed as #425 > > - Section 5.2.1 "an m=3D section being recycled" - first use of term > "recycled". Link? > > - Section 5.2.1 CreateOffer "given that no candidates have yet been > gathered" - when people remember the pre-gathered candidate pool, this > can be confusing. Suggest adding a note at the top of this section > saying that CreateOffer doesn't cause candidate gathering and does not > take candidates from the pre-gathered pool, and thus, no candidates are= > available at the initial call to CreateOffer. All subsequent references= > to "no candidates have yet been gathered" in this section should be > replaced with "no candidates are available". Broken out as #428 (above and below are #426) > > - Section 5.2.1 bullet 2 (first list) references use of the default > candidate (which doesn't exist here). Suggest saying "UDP/TLS/RTP/SAVPF= " > and moving the default candidate language to subsequent offers. > > - Section 5.2.1 CreateOffer - bullet on imageattr - limits on images > that can be decoded - suggest adding text that this is also included on= > recvonly lines because direction of lines can change. > > - Section 5.2.1 "The following attributes ... MUST appear only in "m=3D= " > sections which either have a unique address or which are associated wit= h > the bundle-tag". This is different from BUNDLE 8.1 - they should either= > say the same thing or have a clear explanation of the difference. > > - Section 5.2.1 "a=3Dfingerprint" - needs rewriting for the > multiple-fingerprint-algorithm case (4572bis). Issue already filed? > > - Section 5.2.2 Subsequent offers - is there any reason to allow NOT > incrementing the session-version? > > - Section 5.2.2 The example of rollback doesn't make sense - it works i= f > "an offer is created with version N+1" is replaced with "an offer is > created with version N+1 and installed with SetLocalDescription" > > - Section 5.2.2 recycling of zero-port m-lines - should it specify that= > the new m=3D section MUST have a different mid than the replaced m=3D s= ection? > > - Section 5.2.2 "the following adjustments are made based on the conten= t > of the corresponding m=3D section in the current remote description" - > needs to be contained by "if there is a current remote description". Filed as #426. A couple of things in the list may be substantive enough to be worth their own bugs. > > - Section 5.3.1 I'm unsure about the language on lipsync groups. I can'= t > figure out without more careful analysis if it works for the case of > 1A+1V replying to 1A+1V - in almost any other case, I think the result > is that answer doesn't have LS groups. Filed as #427 > > - Section 5.3.1 needs the same kind of intro as the previous one about > no candidates being available even if gathered. Added to #428 > > - Section 5.3.2 Subsequent answers - like SetCodecPreference, this also= > cements initial priority. Why? Added to #424 > > - Section 5.7.1 Session-level parsing, b=3D lines: This is the first ti= me > they're mentioned. Is there an affordance for adding them when > generating offers/answers? I didn't catch any language like "add any > other field you feel like", but I may have overlooked it. Rethinking this subject, adding fields applies only to SDP sent to the remote end, where rewriting is obviously allowed. Not filing bug. > > - Section 5.8 Applying a local description - on errrors, "processing > MUST stop and an error MUST be returned" - should it also say that the > state of the PC needs to be returned to the pre-apply-LD state? Filed as #429 > > - Section 5.8 - "begin gathering candidates for it" - or take them from= > the pool. > > - Section 5.8 - style: a bullet starting with "if" and a next bullet > starting with "or" is awkward. > > - Section 5.9 - "AS must be ignored" - should also apply to TIAS? > > - Section 5.9 "If more accurate control of bandwidth is needed, TIAS > should be used" - this is the wrong place for that statement, we're not= > choosing here. If this is wanted, just write "TIAS gives more accurate > control of bandwidth than AS". > > - Section 5.10 "If the media section has been rejected ... discard any > associated ICE components". Only if it's not a bundled section. > > - Section 5.10 in general - there are a lot of bullets that apply only > to M-sections that designate a transport. Should those bullets be broke= n > out in a separate list? > > - Section 5.10 - "If no outgoing Source RTP stream exists, choose a > random one" - "one" should be "SSRC" for clarity. Filed as #430 > > - Section 6: "this is only a strawman" language needs deleting. We're i= n > WG Last Call. > > - Section 6: For tables where many-to-one mappings are expected (such a= s > SSRC to receiver when simulcast, RTX or FEC is active), it might be > worth noting this. For tables where many-to-one is an error (such as MI= D > to RTPReceiver), it might be worth noting that too. > > - Section 6: "If the packet's payload type is in the payload type table= , > update.." - this will have interesting consequences ("last one wins") i= f > the sender sends two streams with the same PT and different SSRCs. > Suggest discarding packets where a SSRC->Receiver mapping already exist= s > for that PT. This gives issues when changing SSRC for a stream; tradeof= f > needs evaluating. Filed as #431 > > That's all - no comments on examples :-) > > > > > > > > > > > > > > > - > > > --=20 Surveillance is pervasive. Go Dark. From nobody Fri Nov 18 00:04: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 2FE451295B4 for ; Fri, 18 Nov 2016 00:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 78LIeKJChteP for ; Fri, 18 Nov 2016 00:04:34 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43271294AE for ; Fri, 18 Nov 2016 00:04:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 034E27C3C7F for ; Fri, 18 Nov 2016 09:04:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y81i7G2iOND9 for ; Fri, 18 Nov 2016 09:04:30 +0100 (CET) Received: from [10.35.133.196] (unknown [58.123.138.206]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1D3497C3C74 for ; Fri, 18 Nov 2016 09:04:28 +0100 (CET) To: rtcweb@ietf.org References: <4DE32636-8749-43BD-A910-C03FFC358095@sn3rd.com> From: Harald Alvestrand Message-ID: <0db1ab97-861d-5000-41e7-8e31124a4778@alvestrand.no> Date: Fri, 18 Nov 2016 09:04:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <4DE32636-8749-43BD-A910-C03FFC358095@sn3rd.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] WGLC: draft-ietf-rtcweb-overview 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, 18 Nov 2016 08:04:35 -0000 On 11/18/2016 04:24 AM, Sean Turner wrote: > This is a working group last call for the "Overview: Real Time Protocols for Browser-based Applications" draft available @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/. Please review this draft and send your comments to the list by 9 December 2016. Note that the github repo is https://github.com/rtcweb-wg/rtcweb-overview. Help with filing issues will be appreciated. > > Thanks, > T,C,&S > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From nobody Sat Nov 19 05:13: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 A347C129500 for ; Sat, 19 Nov 2016 05:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 6nebOjwdE0vT for ; Sat, 19 Nov 2016 05:13:42 -0800 (PST) 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 776FD127A90 for ; Sat, 19 Nov 2016 05:13:40 -0800 (PST) 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 A9176428A; Sat, 19 Nov 2016 14:13:31 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <0db1ab97-861d-5000-41e7-8e31124a4778@alvestrand.no> Date: Sat, 19 Nov 2016 14:13:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <65D8332F-04FA-4B06-9423-C41B3E2815E2@edvina.net> References: <4DE32636-8749-43BD-A910-C03FFC358095@sn3rd.com> <0db1ab97-861d-5000-41e7-8e31124a4778@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.3124) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WGLC: draft-ietf-rtcweb-overview 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, 19 Nov 2016 13:13:45 -0000 > On 18 Nov 2016, at 09:04, Harald Alvestrand = wrote: >=20 > On 11/18/2016 04:24 AM, Sean Turner wrote: >> This is a working group last call for the "Overview: Real Time = Protocols for Browser-based Applications" draft available @ = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/. Please = review this draft and send your comments to the list by 9 December 2016.=20= >=20 > Note that the github repo is = https://github.com/rtcweb-wg/rtcweb-overview. >=20 > Help with filing issues will be appreciated. I=E2=80=99ve opened a few issues. Some of them editor-picky and some = just things I noticed, but nothing very major. Cheers, /O= From nobody Mon Nov 21 13:24: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 78C8E129BE4 for ; Mon, 21 Nov 2016 13:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 SA__kA2NsgcF for ; Mon, 21 Nov 2016 13:24:07 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 B23671295E6 for ; Mon, 21 Nov 2016 13:24:07 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id 51so237723351uai.1 for ; Mon, 21 Nov 2016 13:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WPyQBZyTQnHwYMW3GFDJvOaQqfyJ3YzyEtCzpspM0U0=; b=TFMt8JkzNcQm7xX6H8Vbv7pjKJkx4x0PpFvKYvY+lRwTKBIAIn2kJgeL7OfAiAl697 ul1/+ejLRrG3ZJJtt5FMyL7LbJvaX5LZx6ZMwOQ86dQ2EpG/GR1df2QvmF1Vu+u3pPzf dSpuGTW9vBqlulTDPMekzlKZ/JePAnFU4LSMwOZCVyo05APIoXmeX06MxBISgpeKeO+o cLioJUC/UFJ4N3I+Ujb/icGc1K++uaWE+gv7gRXQv6pl37yi+Ijx17zOClzRFc79IgsA m10fXDYbrsme2Y4F6j00tP+pJNUIteW//S9cmxJSkxMiJD4M2XeAPrNm4rkIyi2luFUx P4Ew== 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=WPyQBZyTQnHwYMW3GFDJvOaQqfyJ3YzyEtCzpspM0U0=; b=NJBoIn1vXzclX4mPwZhnD1Rst5RlFYsaES6vUhYV1odBFODYiSucAz9nIKA35ra/w2 5gbnnpcNwx0ezKibbhY1NVhyjFOvcW74bEgABxRVSKNZylSObxka4pceOayLW9L7ANCu tRaEB/Amwpp76X5hKOLBsJpqNzRQRfwjfDTFz6lBCwXVVIdREPwllwMEhpcKmaWm4M3M 9xGgdMc0HdQYsTsf5ut5MmvuuRr5+cYy3TX2slAaLflFbRchlCyEk5fAttfGHDP5XDZs Od5ZwGBfVhKW5MCZXyW+D6MmOWLUKyAv4dVDtwvvrhkfQBsgCxmDj0VicGyQIIH3+pGW yHUA== X-Gm-Message-State: AKaTC03fVIFw1NUjZKMWTvtNQQWDQtAowsW06JAzcRC1ORv4ZK/IUl/srdNyQQkFYryHekupK64Ond1aLTfSlw== X-Received: by 10.176.82.118 with SMTP id j51mr8462540uaa.161.1479763446641; Mon, 21 Nov 2016 13:24:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.16.10 with HTTP; Mon, 21 Nov 2016 13:23:46 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Mon, 21 Nov 2016 13:23:46 -0800 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=94eb2c190cb096bad20541d64695 Archived-At: Cc: "" Subject: Re: [rtcweb] Pull Requests for moving the demux algorithm from JSEP to BUNDLE 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, 21 Nov 2016 21:24:09 -0000 --94eb2c190cb096bad20541d64695 Content-Type: text/plain; charset=UTF-8 A small typo: "do not it include it" -> "do not include it" On Thu, Nov 17, 2016 at 6:15 PM, Peter Thatcher wrote: > In the RTCWEB meeting on Wednesday, Cullen mentioned we would make two PRs > to move the demux algorithm from JSEP to BUNDLE, one in JSEP and one in > BUNDLE. I have made those two PRs: > > https://github.com/rtcweb-wg/jsep/pull/411/files > > https://github.com/cdh4u/draft-sdp-bundle/pull/16/files > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --94eb2c190cb096bad20541d64695 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A small typo:

"do not it include it" =C2=A0-> "do not include it&= quot;

= On Thu, Nov 17, 2016 at 6:15 PM, Peter Thatcher <pthatcher@google.com> wrote:

--94eb2c190cb096bad20541d64695-- From nobody Mon Nov 28 03:14: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 F3717129E39; Mon, 28 Nov 2016 03:14:11 -0800 (PST) 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 QH7Yw0NDpCso; Mon, 28 Nov 2016 03:14:10 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 66893129E53; Mon, 28 Nov 2016 03:03:25 -0800 (PST) X-AuditID: c1b4fb3a-d644398000007918-a4-583c0efbecbf Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 2A.4A.31000.BFE0C385; Mon, 28 Nov 2016 12:03:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Mon, 28 Nov 2016 12:03:16 +0100 From: Christer Holmberg To: Peter Thatcher , "" , "mmusic@ietf.org" Thread-Topic: [rtcweb] Pull Requests for moving the demux algorithm from JSEP to BUNDLE Thread-Index: AQHSSWcEgU9hIep6aEaFnfzjdNpmRg== Date: Mon, 28 Nov 2016 11:03:15 +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.9.160926 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D461DD03139E5christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7tO5vPpsIg0+vjC2mLn/MYnFt+WtW i7X/2tkdmD0WbCr1WLLkJ1MAUxSXTUpqTmZZapG+XQJXxp+rdgUTFCvuv8psYLwh08XIySEh YCJxfcEGli5GLg4hgXWMEls3v2YGSQgJLGaU2PXcrIuRg4NNwEKi+582SFhEoFzix5rtLCC2 sECExJzG9UwQ8UiJtn1n2EHKRQT0JI7MSQAJswioSuw5MpURxOYVsJY4MPs+C8T0AImXO6cz g5RzCgRKnLpmDhJmFBCT+H5qDdhEZgFxiVtP5jNBXCkgsWTPeWYIW1Ti5eN/rCCtokCb1twP gwgrSfzYcIkFojVBomdfLyvEVkGJkzOfsExgFJmFZOosJGWzkJRBxHUkFuz+xAZha0ssW/ia GcY+c+AxVK+1xJbDTazIahYwcqxiFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIy1g1t+W+1g PPjc8RCjAAejEg/vhy9WEUKsiWXFlbmHGCU4mJVEeAN5bSKEeFMSK6tSi/Lji0pzUosPMUpz sCiJ85qtvB8uJJCeWJKanZpakFoEk2Xi4JRqYNQWC7DbnPH8/Mcgz/oUMyMlo4pG/18LjW+U /A8ujN3sUu93Qo/hgs/j0OIrDk/vfPnKdYBld8ZRweA4x+ZzDUKRQk7Wgl2Pv9qKzDa+qX+o Yfv7AJ5Wjs2F6+Tt5OwkVkk1nmw7Pi+pIOH6zfeftB6Gb9mZk7cs8ubjzWIzoivP9m/q/qLr r8RSnJFoqMVcVJwIANoqSqyxAgAA Archived-At: Subject: Re: [rtcweb] Pull Requests for moving the demux algorithm from JSEP to BUNDLE 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, 28 Nov 2016 11:14:12 -0000 --_000_D461DD03139E5christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The BUNDLE pull request contains the following text: "Note: The following algorithm does not yet have WG consensus but is includ= ed here as something concrete for the working group to discuss." My question is: does someone have an issue with the algorithm? If not, I su= ggest we remove the note, merge the pull request and submit a new version o= f the draft. Regards, Christer From: rtcweb > on b= ehalf of "pthatcher@google.com" > Date: Friday 18 November 2016 at 05:15 To: "rtcweb@ietf.org" > Subject: [rtcweb] Pull Requests for moving the demux algorithm from JSEP to= BUNDLE In the RTCWEB meeting on Wednesday, Cullen mentioned we would make two PRs = to move the demux algorithm from JSEP to BUNDLE, one in JSEP and one in BUN= DLE. I have made those two PRs: https://github.com/rtcweb-wg/jsep/pull/411/files https://github.com/cdh4u/draft-sdp-bundle/pull/16/files --_000_D461DD03139E5christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9B9DBD7A1BE7DC44A5B104AFCE98EC7E@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

The BUNDLE pull request contains the following text:

"Note: The following algorithm does not yet have WG consensus but is i= ncluded here as something concrete for the working group to discuss."<= /p>


My question is: does someone have an issue with the algorithm? If not,= I suggest we remove the note, merge the pull request and submit a new vers= ion of the draft.

Regards,

Christer


From: rtcweb <rtcweb-bounces@ietf.org> on behalf of "= ;pthatcher@google.com" <= ;pthatcher@google.com>
Date: Friday 18 November 2016 at 05= :15
To: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Subject: [rtcweb] Pull Requests for= moving the demux algorithm from JSEP to BUNDLE

In the RTCWEB meeting on Wednesday, Cullen mentioned we wo= uld make two PRs to move the demux algorithm from JSEP to BUNDLE, one in JS= EP and one in BUNDLE.  I have made those two PRs:




--_000_D461DD03139E5christerholmbergericssoncom_-- From nobody Mon Nov 28 04:18: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 E16A4129552; Mon, 28 Nov 2016 04:18:44 -0800 (PST) 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 J0wDKmDUd9WE; Mon, 28 Nov 2016 04:18:42 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 77452129585; Mon, 28 Nov 2016 04:18:41 -0800 (PST) X-AuditID: c1b4fb30-c294498000000c18-cb-583c209f4667 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 29.CB.03096.F902C385; Mon, 28 Nov 2016 13:18:39 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.319.2; Mon, 28 Nov 2016 13:18:16 +0100 To: Christer Holmberg , Peter Thatcher , "" , "mmusic@ietf.org" References: From: Magnus Westerlund Message-ID: <3d285cea-c995-d492-9ebc-2222def9f8a5@ericsson.com> Date: Mon, 28 Nov 2016 13:18:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM2K7ru58BZsIg109ZhZTlz9msbi2/DWr xdp/7ewOzB4LNpV6LFnykymAKYrLJiU1J7MstUjfLoEr4/bRzUwFDQIVjat6mRsYe3i7GDk5 JARMJHbvPMncxcjFISSwjlHiz6rFbBDOckaJBzPeMYJUCQtESMxpXM8EkhARWMso0TrxL1RL E6PEoilnmUCq2AQsJG7+aGQDsXkF7CWW7HkFZrMIqEq0b10HZosKxEh8WveXHaJGUOLkzCcs IDangI3Esz27gWo4OJiBeh9sLQMJMwvISzRvnc0MYgsJaEs0NHWwTmDkn4WkexZCxywkHQsY mVcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBAbiwS2/DXYwvnzueIhRgINRiYf3wxerCCHW xLLiytxDjBIczEoivBryNhFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEec1W3g8XEkhPLEnNTk0t SC2CyTJxcEo1MJbdXuaiVBQsNFXad3GIygP5q4VJoY59DcsV6kQ/Tto+LWi6wxeWopgvLcVX +66aHpNgU7w9s2H6tWLmtv6wXTtu6yeesJ+8xGdji7pL8rd9emlTvP4a37K9+viesdnT8iXX +FREOT/eir4UEiKz5eyq9OYUJbXT7q8U2eO+zX24NuBIn2/mbCWW4oxEQy3mouJEACUgcFRA AgAA Archived-At: Subject: Re: [rtcweb] Pull Requests for moving the demux algorithm from JSEP to BUNDLE 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, 28 Nov 2016 12:18:45 -0000 Den 2016-11-28 kl. 12:03, skrev Christer Holmberg: > Hi, > > The BUNDLE pull request contains the following text: > > "Note: The following algorithm does not yet have WG consensus but is > included here as something concrete for the working group to discuss." > > > My question is: does someone have an issue with the algorithm? If not, I > suggest we remove the note, merge the pull request and submit a new > version of the draft. Yes, Colin and I are working on an updated text proposal for both Bundle and JSEP. I hope that we will have something ready before the end of the week. Cheers Magnus > > Regards, > > Christer > > > From: rtcweb > > on behalf of "pthatcher@google.com " > > > Date: Friday 18 November 2016 at 05:15 > To: "rtcweb@ietf.org " > > Subject: [rtcweb] Pull Requests for moving the demux algorithm from JSEP > to BUNDLE > > In the RTCWEB meeting on Wednesday, Cullen mentioned we would make two > PRs to move the demux algorithm from JSEP to BUNDLE, one in JSEP and one > in BUNDLE. I have made those two PRs: > > https://github.com/rtcweb-wg/jsep/pull/411/files > > https://github.com/cdh4u/draft-sdp-bundle/pull/16/files > > > > > _______________________________________________ > 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 Tue Nov 29 02:39: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 2CF6A129672; Tue, 29 Nov 2016 02:39:00 -0800 (PST) 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 KfDY4ncsdr1e; Tue, 29 Nov 2016 02:38:59 -0800 (PST) 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 8B193129667; Tue, 29 Nov 2016 02:38:58 -0800 (PST) X-AuditID: c1b4fb2d-4612998000001117-36-583d5ac0a88d Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id D7.BC.04375.0CA5D385; Tue, 29 Nov 2016 11:38:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.16]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Tue, 29 Nov 2016 11:38:14 +0100 From: Christer Holmberg To: Magnus Westerlund , Peter Thatcher , "" , "mmusic@ietf.org" Thread-Topic: [rtcweb] Pull Requests for moving the demux algorithm from JSEP to BUNDLE Thread-Index: AQHSSWcEgU9hIep6aEaFnfzjdNpmRqDuP2wAgAGJl4A= Date: Tue, 29 Nov 2016 10:38:14 +0000 Message-ID: References: <3d285cea-c995-d492-9ebc-2222def9f8a5@ericsson.com> In-Reply-To: <3d285cea-c995-d492-9ebc-2222def9f8a5@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8563955CF53D2E449BAB4DC9A7BFDB98@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7pe6BKNsIg5/7NC2mLn/MYnFt+WtW i7X/2tkdmD0WbCr1WLLkJ1MAUxSXTUpqTmZZapG+XQJXxooDOxgLNglWnHx5laWBcQ1fFyMn h4SAicScH9MZuxi5OIQE1jFKzNm7ngnCWcwosW/6d/YuRg4ONgELie5/2iBxEYG1jBJ3/nxj AekWFoiQmNMI0sAJlIiUaNt3hh3CtpK4uW0DWJxFQFWivecRI4jNK2AtcXTJSWaIBTsYJVY2 rGcGSXAKOEgcWdgHVsQoICbx/dQasGZmAXGJW0/mM0GcKiCxZM95ZghbVOLl43+sIMeJCuhJ rLkfBhFWlLg6fTlUq57EjalT2CBsa4nvE75DxbUlli18zQxxj6DEyZlPWCYwis1Csm0WkvZZ SNpnIWmfhaR9ASPrKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzACDu45bfuDsbVrx0PMQpw MCrx8Ba42UQIsSaWFVfmHmKU4GBWEuGNjbSNEOJNSaysSi3Kjy8qzUktPsQozcGiJM5rtvJ+ uJBAemJJanZqakFqEUyWiYNTqoFR8GCk/mHGR8Gn5+VGfbsfU83GmsC30LjUsbz52tl1exqf 5RTt//Ti2CvmU3yXztbm71iZkuRg5W2ldq9UuuHlT+OTDw75pb9a6H5nimHi+6O1ZSnLpTuv K3nclGg03Vm6vWjeSrZz8w0O/RWe65FkxB60qalfSl4y6IVk0KNVLD5saz5/6F2qxFKckWio xVxUnAgAEB1OCawCAAA= Archived-At: Subject: Re: [rtcweb] Pull Requests for moving the demux algorithm from JSEP to BUNDLE 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, 29 Nov 2016 10:39:00 -0000 Ok - I=B9ll wait :) On 28/11/16 14:18, "Magnus Westerlund" wrote: >Den 2016-11-28 kl. 12:03, skrev Christer Holmberg: >> Hi, >> >> The BUNDLE pull request contains the following text: >> >> "Note: The following algorithm does not yet have WG consensus but is >> included here as something concrete for the working group to discuss." >> >> >> My question is: does someone have an issue with the algorithm? If not, I >> suggest we remove the note, merge the pull request and submit a new >> version of the draft. > >Yes, Colin and I are working on an updated text proposal for both Bundle >and JSEP. I hope that we will have something ready before the end of the >week. > >Cheers > >Magnus > >> >> Regards, >> >> Christer >> >> >> From: rtcweb > >> on behalf of "pthatcher@google.com " >> > >> Date: Friday 18 November 2016 at 05:15 >> To: "rtcweb@ietf.org " > > >> Subject: [rtcweb] Pull Requests for moving the demux algorithm from JSEP >> to BUNDLE >> >> In the RTCWEB meeting on Wednesday, Cullen mentioned we would make two >> PRs to move the demux algorithm from JSEP to BUNDLE, one in JSEP and one >> in BUNDLE. I have made those two PRs: >> >> https://github.com/rtcweb-wg/jsep/pull/411/files >> >> https://github.com/cdh4u/draft-sdp-bundle/pull/16/files >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > >--=20 > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > From nobody Wed Nov 30 11:24: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 6A0221293D8 for ; Wed, 30 Nov 2016 11:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 V80ChydQS29S for ; Wed, 30 Nov 2016 11:24:30 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E15129986 for ; Wed, 30 Nov 2016 11:24:30 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id n6so198480286qtd.1 for ; Wed, 30 Nov 2016 11:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=1OFFU3c4ResuF4ZtGygcezeZ3vUJHdrjmKm694U/7Ko=; b=Eld7gi2XYMuSMQMdZAmnH5xZbvNM2SWJNdelg/MS+X4ERO5/kEkoYa70MkDQ1j2vKz cgboY+rNAKyqyJtNuEzHmLCtOUcfS+E0+MUrtEXB5JRiId0VjwLBNLmBR8TLkgCrYlOf czG2CW7abzEnRmEUj99zqCu8M3NvAmdQkHHeo= 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 :content-transfer-encoding:message-id:references:to; bh=1OFFU3c4ResuF4ZtGygcezeZ3vUJHdrjmKm694U/7Ko=; b=itIsAHkvTwr+T03fBIe0yp7jw8FYfTxwaY9MC/GqsIF4dWyiufHn8g0kXyrHtNRVYk V+fzncWNxTKdOtuJiHWafVnSZ1c/st6gy6+fQ1ugxMOjlxlDXXdD02bFynMkAcS0/NLB qYOBa/dviF6WFKjWe/1/vu+XIDUze2NO+khYfq2UmPvdMc7o2S1WAED2vMzs6OHmyPDW wQGEZsFs3fJ6myluu+xsxIbAXk2bdiBrf0dES1gtYqhL+mC1yTK/2LGJ0Yn1saKPQL2+ 32SFy/s8fbVPIFb0ia1RJkyQY0JE1PHpyxU5RumvjTfJybSyRx2BbJtf3SDAMcmXYRlw ONMA== X-Gm-Message-State: AKaTC01Qc5f/cMfS0oURhWPqeC/AOFmpxtDiHjJuP187bLPTaDKt3/54b2vDQPZHnKx/7A== X-Received: by 10.200.37.101 with SMTP id 34mr30208492qtn.273.1480533869294; Wed, 30 Nov 2016 11:24:29 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id e24sm27086166qkj.12.2016.11.30.11.24.28 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 30 Nov 2016 11:24:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <4DE32636-8749-43BD-A910-C03FFC358095@sn3rd.com> Date: Wed, 30 Nov 2016 14:24:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <257990CE-C053-4799-8695-905A1E4A3CB1@sn3rd.com> References: <4DE32636-8749-43BD-A910-C03FFC358095@sn3rd.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [rtcweb] Reminder -> Re: WGLC: draft-ietf-rtcweb-overview <- 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, 30 Nov 2016 19:24:32 -0000 Just a reminder after the US-holidaze that this WGLC ends on 9 December = 2016. spt > On Nov 17, 2016, at 22:24, Sean Turner wrote: >=20 > This is a working group last call for the "Overview: Real Time = Protocols for Browser-based Applications" draft available @ = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/. Please = review this draft and send your comments to the list by 9 December 2016.=20= >=20 > Thanks, > T,C,&S