From nobody Thu Nov 1 17:37:26 2018 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 6913F128DFD; Thu, 1 Nov 2018 17:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 1OJ7B0ZKEWDC; Thu, 1 Nov 2018 17:37:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B465120072; Thu, 1 Nov 2018 17:37:18 -0700 (PDT) Received: from Orochi.local ([38.98.37.141]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA20b8tt088461 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 1 Nov 2018 19:37:14 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [38.98.37.141] claimed to be Orochi.local To: draft-ietf-rtcweb-security.all@ietf.org, "rtcweb@ietf.org" From: Adam Roach Message-ID: <5a2ed698-e353-4cb9-9c33-6450a843aefe@nostrum.com> Date: Thu, 1 Nov 2018 19:36:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [rtcweb] AD Review: draft-ietf-rtcweb-security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 02 Nov 2018 00:37:25 -0000 This is my AD review for draft-ietf-rtcweb-security. I think this document is ready to go into IETF last call, modulo the ICE citation issue. I plan to issue last call for this document at the same time as draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-ip-handling, so it will wait for those to become ready. I'm marking the document as "revised ID needed" pending the ICE reference update. I also have a number of non-blocking comments that should be treated the same as IETF last-call comments. /a --------------------------------------------------------------------------- ID Nits reports:   == The document seems to contain a disclaimer for pre-RFC5378 work, but was      first submitted on or after 10 November 2008.  The disclaimer is usually      necessary only for documents that revise or obsolete older RFCs, and that      take significant amounts of text from those RFCs.  If you can contact all      authors of the source material and they are willing to grant the BCP78      rights to the IETF Trust, you can and should remove the disclaimer.      Otherwise, the disclaimer is needed and you can ignore this comment.      (See the Legal Provisions document at      https://trustee.ietf.org/license-info for more information.)   -- Obsolete informational reference (is this intentional?): RFC 6222      (Obsoleted by RFC 7022) --------------------------------------------------------------------------- [DISCUSS] Per the discussion around Cluster 238 dependencies, please reference RFC 8445 instead of RFC 5245. --------------------------------------------------------------------------- §1: >  The Real-Time Communications on the Web (RTCWEB) working group is >  tasked with standardizing protocols for real-time communications >  between Web browsers, generally called "WebRTC" I plan to close RTCWEB as soon as Cluster 238 is published, at which point this text will be out of date. Consider rephrasing in a way that will survive the passage of time better. --------------------------------------------------------------------------- §1: >  In the system shown in Figure 1, Alice and Bob both have WebRTC >  enabled browsers... Please add Alice and Bob to Figure 1. Nit: "WebRTC-emabled" --------------------------------------------------------------------------- §2: Please update to match the RFC 8174 boilerplate. Regardless of whether this update is made, there seem to be some ambiguous uses of RFC 2119 language (e.g. §4.3: "This service must be provided for both data and voice/video") that need a bit of auditing. --------------------------------------------------------------------------- §3.1: >  While the browser has access to local resources such as keying >  material, files, the camera and the microphone, Consider adding an Oxford comma. --------------------------------------------------------------------------- §3.1: >  [Note: in many cases browsers are explicitly designed to avoid >  dialogs with the semantics of "click here to screw yourself", as I hate to be a wet blanket, but this phrasing seems out of character for an RFC. Consider something less colloquial (and perhaps with less rough connotations) than "screw" here. --------------------------------------------------------------------------- > 3.2.  Same Origin Policy Nit: "Same-Origin" --------------------------------------------------------------------------- §3.2: >  Many other resources are accessible but isolated.  For instance, >  while scripts are allowed to make HTTP requests via the >  XMLHttpRequest() API Consider informatively citing https://xhr.spec.whatwg.org/ (or something better if you can find it). --------------------------------------------------------------------------- §4.1.2.2: >  to avoid the users just clicking through.  Note also that the user >  interface chrome must clearly display elements showing that the call Consider defining the term "chrome" for those readers who may not be familiar with it. --------------------------------------------------------------------------- §4.1.3: >  target.  Callee-oriented consent provided by the calling site not >  work well because a malicious site can claim that the user is calling Nit: "...does not work well..." (or "...would not work well...") >  cryptographically established identity.  While not suitable for all Nit: "cryptographically-established" --------------------------------------------------------------------------- §4.1.4: >  Even if calls are only possible from HTTPS [RFC2818] sites, if the >  site embeds active content (e.g., JavaScript) that is fetched over >  HTTP or from an untrusted site, because that JavaScript is executed >  in the security context of the page [finer-grained]. I can't parse this sentence. Consider reworking. --------------------------------------------------------------------------- §4.2.3: >  o  Use or RTCP as an implicit reachability check. Nit: "Use of..." --------------------------------------------------------------------------- §4.2.4: >  In addition, either side may wish to hide their location entirely by >  forcing all traffic through a TURN server. Suggested improvement: "...hide their location from the other..." (to avoid implying that this hides their location from either the web server or the STUN server) --------------------------------------------------------------------------- §4.3: >  However, we must examine this >  technology to the WebRTC context, where the threat model is somewhat >  different. Nit: "...in the WebRTC context..." --------------------------------------------------------------------------- §4.3: >  MITM attack or by diverting them entirely.  (Note that this attack Please expand "MITM" on first use. --------------------------------------------------------------------------- §4.3.2.1: >  All the calling service needs to do to avoid >  triggering a key continuity warning is to tell the browser that "this >  is a call to user Y" where Y is close to X. I read the meaning of the term "close" here to mean "confusable with X," although it took some work to arrive at that conclusion. If "confusable" is the intention, I would suggest phrasing it in that way. --------------------------------------------------------------------------- §4.3.2.2: >  simply ignore such indicators even in the rather more dire case of >  mixed content warnings. Nit: "mixed-content" --------------------------------------------------------------------------- §4.3.2.3: >  However, a new generation of Web-based identity >  providers (BrowserID, Federated Google Login, Facebook Connect, >  OAuth, OpenID, WebFinger), has recently been developed Consider adding informative citations for at least BrowserID, OAuth, OpenID, and Webfinger [RFC7033], if not the other systems. --------------------------------------------------------------------------- §4.3.2.4: >  I.e., I must be able to verify that >  the person I am calling has engaged a secure media mode. Is this possible in the general case? For non-browser endpoints (or for modified browswers), this verification seems to be impossible (unless I've missed some mechanism in the system that can guarantee this property). Clearly I'm not asking for a change in design, but it seems that this statement needs to be caveated to indicate that it requires trust in the remote endpoint to enforce the indicated policy, and that this trust cannot be verified; at least, not as WebRTC is designed today. A simple forward citation to §4.3.3 might serve the purpose. --------------------------------------------------------------------------- §4.4.1: >  While persistent endpoint identifiers can be a useful security >  feature (see Section 4.3.2.1 they can also represent a privacy threat Nit: missing a closing paren. --------------------------------------------------------------------------- §4.2.2: Consider citing https://www.w3.org/TR/fingerprinting-guidance/ for further information. From nobody Thu Nov 1 18:15:40 2018 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 3B23F130DF2; Thu, 1 Nov 2018 18:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 fbexW9gmqMxE; Thu, 1 Nov 2018 18:15:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D304130DE3; Thu, 1 Nov 2018 18:15:26 -0700 (PDT) Received: from Orochi.local ([38.98.37.141]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA21FHKU094512 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 1 Nov 2018 20:15:23 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [38.98.37.141] claimed to be Orochi.local To: draft-ietf-rtcweb-ip-handling.all@ietf.org, "rtcweb@ietf.org" From: Adam Roach Message-ID: <773c8e91-a1d2-8c9e-fd19-c8b181f6dad1@nostrum.com> Date: Thu, 1 Nov 2018 20:15:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [rtcweb] AD review: draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 02 Nov 2018 01:15:34 -0000 This is my AD review for draft-ietf-rtcweb-ip-handling. I think this document is ready to go into IETF last call, modulo the ICE citation issue. I plan to issue last call for this document at the same time as draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-security, so it will wait for those to become ready. I'm marking the document as "revised ID needed" pending the ICE reference update. --------------------------------------------------------------------------- [DISCUSS] Per the discussion around Cluster 238 dependencies, please reference RFC 8445 instead of RFC 5245. --------------------------------------------------------------------------- §2: Please update to match the RFC 8174 boilerplate. --------------------------------------------------------------------------- §5.2: >  Future versions of this document may define additional modes and/or >  update the recommended default modes. Suggest: "Future documents may...", as future consensus may be to update rather than replace this document. From nobody Fri Nov 2 09:36:07 2018 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 70266130DF5 for ; Fri, 2 Nov 2018 09:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 WDZaxhSR1jqL for ; Fri, 2 Nov 2018 09:36:03 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 0B6FD130DEC for ; Fri, 2 Nov 2018 09:36:03 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id p64-v6so4002992itp.0 for ; Fri, 02 Nov 2018 09:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q+4m8zCcuimfsWd9IJVijt4aTLUslMst0nY/lTMdB8M=; b=BorqrXLfsrxPL/b8CgFkUDJy1DT2aauD9FweQHIjW8ooGJmIyx21GHR02O1e/KFEqm gXQpDjJsN0fImDwdGv3J166+OjDg50NvtXoAjnl+BBdaWscD2dQsmMvkeyx4Qaub16HM aSxganLkn7Qx+IWyxu32mg13ewE+Gqi9Y9Wq0hBIICFtKIYU9+QraTSM7N0tc3mH7BMN UELbv6dAIRwWRhAxc9tRmkybUTpQimng3DU0by66RALHmVlf6iBhddctZCYLkoBZCbMG dheBGCK84pMZKJGrgQxirjbXCIqzwEn3lBxg2IHEZXobx3p4Sf+8wEfZiZebRsrXN15P XioA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q+4m8zCcuimfsWd9IJVijt4aTLUslMst0nY/lTMdB8M=; b=DKXeIImCnP0VPnsx7J3CnbvxLf+qg5JBFgQ5IAX1zgY5dTgvNQpCyfp8KAnV188alN VXwQnuxo2yM/mYtW9ZQuZQN4YX7X4YblgnRSK64cIEjZOb2SXu74IvH/QVo97EwcOF7t xehZ0i39E/JcWfvjZWQPhV2oTHwDOoLZdmYkNmWvQPkM5xBOhtKpXkmwq8qeklgZqS0q 7V0Q4QT/HzdD1knVFaynWwZEaTIR7Z1F/43qMzN1TSGWtUQ5I2oJPQI412x3gyhbLQF1 6GEHDcyfITyET6iAa4MM9fVy7Fuf2DoIrL9CPLZ7wJcFNZgMeGHuoys827EyKmiLTosp Izwg== X-Gm-Message-State: AGRZ1gJfdZLQog4bZ2NO+tYVl1UO+tRFJ5WnrUJgs9W0+YNIBC/q/djw Dp/8Vcj5zkj1251KiFoCYQjXiFbBGDQzpK9g5Zt5ng== X-Google-Smtp-Source: AJdET5dG1VhrD+r/PyEvvkglwK0fykaTipE10FnGP3uefo9iKbSezOYfnIs1ult2KbbJ5JB+FijutgBtghou6wJ2WvI= X-Received: by 2002:a24:fac2:: with SMTP id v185-v6mr357693ith.153.1541176561831; Fri, 02 Nov 2018 09:36:01 -0700 (PDT) MIME-Version: 1.0 References: <773c8e91-a1d2-8c9e-fd19-c8b181f6dad1@nostrum.com> In-Reply-To: <773c8e91-a1d2-8c9e-fd19-c8b181f6dad1@nostrum.com> From: Justin Uberti Date: Fri, 2 Nov 2018 09:35:49 -0700 Message-ID: To: Adam Roach Cc: draft-ietf-rtcweb-ip-handling.all@ietf.org, RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000081aa050579b121fa" Archived-At: Subject: Re: [rtcweb] AD review: draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 02 Nov 2018 16:36:06 -0000 --00000000000081aa050579b121fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable See https://github.com/rtcweb-wg/ip-handling/pull/1 Will send out a new version of the doc when the upload tool reopens. On Thu, Nov 1, 2018 at 6:15 PM Adam Roach wrote: > This is my AD review for draft-ietf-rtcweb-ip-handling. > > I think this document is ready to go into IETF last call, modulo the ICE > citation issue. I plan to issue last call for this document at the same > time > as draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-security, so it > will > wait for those to become ready. > > I'm marking the document as "revised ID needed" pending the ICE reference > update. > > -------------------------------------------------------------------------= -- > > [DISCUSS] > > Per the discussion around Cluster 238 dependencies, please reference RFC > 8445 > instead of RFC 5245. > > -------------------------------------------------------------------------= -- > > =C2=A72: > > Please update to match the RFC 8174 boilerplate. > > -------------------------------------------------------------------------= -- > > =C2=A75.2: > > > Future versions of this document may define additional modes and/or > > update the recommended default modes. > > Suggest: "Future documents may...", as future consensus may be to update > rather > than replace this document. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00000000000081aa050579b121fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Will send out a new version of th= e doc when the upload tool reopens.

On Thu, Nov 1, 2018 at 6:15 PM Adam Roach <adam@nostrum.com> wrote:
This is my AD review for draft-ietf-rtcweb-ip-han= dling.

I think this document is ready to go into IETF last call, modulo the ICE citation issue. I plan to issue last call for this document at the same tim= e
as draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-security, so it will
wait for those to become ready.

I'm marking the document as "revised ID needed" pending the I= CE reference
update.

---------------------------------------------------------------------------=

[DISCUSS]

Per the discussion around Cluster 238 dependencies, please reference RFC 8445
instead of RFC 5245.

---------------------------------------------------------------------------=

=C2=A72:

Please update to match the RFC 8174 boilerplate.

---------------------------------------------------------------------------=

=C2=A75.2:

=C2=A0>=C2=A0 Future versions of this document may define additional mod= es and/or
=C2=A0>=C2=A0 update the recommended default modes.

Suggest: "Future documents may...", as future consensus may be to= update
rather
than replace this document.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--00000000000081aa050579b121fa-- From nobody Sat Nov 3 01:38:58 2018 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 9D4C2129BBF for ; Sat, 3 Nov 2018 01:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 8QhYq4GCDOr4 for ; Sat, 3 Nov 2018 01:38:54 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E81124BAA for ; Sat, 3 Nov 2018 01:38:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 1A34C7C3D40 for ; Sat, 3 Nov 2018 09:38:52 +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 djnGpO4fzwgD for ; Sat, 3 Nov 2018 09:38:50 +0100 (CET) Received: from [IPv6:2001:67c:370:128:e6a7:a0ff:fe0b:6b0c] (unknown [IPv6:2001:67c:370:128:e6a7:a0ff:fe0b:6b0c]) by mork.alvestrand.no (Postfix) with ESMTPSA id 8D3757C38D8 for ; Sat, 3 Nov 2018 09:38:49 +0100 (CET) To: "rtcweb@ietf.org" From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <75f60e2f-d4c9-8d48-1f71-2ca3b733edee@alvestrand.no> Date: Sat, 3 Nov 2018 09:38:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A7CA4284466BBCE090CD6C14" Content-Language: en-GB Archived-At: Subject: [rtcweb] JSEP nit: Size of in the o= line X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2018 08:38:57 -0000 This is a multi-part message in MIME format. --------------A7CA4284466BBCE090CD6C14 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable JSEP -24 currently says: The sess-id MUST be representable by a 64-bit signed integer, and the initial value MUST be less than (2**62)-1, as required by [RFC3264 ]. It is= RECOMMENDED that the sess-id be constructed by generating a 64-bit quantity with the two highest bits being set to zero and the remaining 62 bits being cryptographically random. There are two problems here: - RFC 3264 actually doesn't place that restriction on the sess-id, that's the restriction on the version field. - Deployed code (libwebrtc) generates sess-ids that are larger than 2^62-= 1 Quote from RFC 3264: The offer (and answer) MUST be a valid SDP message, as defined by RFC = 2327 [1 ], with one exception. RFC 2327 mandates that either an e or a p line is present in the SDP message. This specification relaxes that constraint; an SDP formulated for an offer/answer application MAY omit both the e and p lines. The numeric value of the session id and version in the o line MUST be representable with a 64 bit signed integer. The initial value of the version MUST be less than (2**62)-1, to avoid rollovers. Although the SDP specification allows for multiple session descriptions to be concatenated together into a large SDP message, an SDP message used in the offer/answer model MUST contain exactly one session description. So what's easiest to change, deployed code or JSEP? This note is also filed as https://github.com/rtcweb-wg/jsep/issues/855 --=20 Surveillance is pervasive. Go Dark. --------------A7CA4284466BBCE090CD6C14 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

JSEP -24 currently says:

      The sess-id MUST be representable by a 64-bit signed
      integer, and the initial value MUST be less than (2**62)-1, as
      required by [RFC3264].  It is RECOMMENDED that the sess-id be
      constructed by generating a 64-bit quantity with the two highest
      bits being set to zero and the remaining 62 bits being
      cryptographically random.

There are two problems here:

- RFC 3264 actually doesn't place that restriction on the sess-id, that's the restriction on the version field.

- Deployed code (libwebrtc) generates sess-ids that are larger than 2^62-1

Quote from RFC 3264:

   The offer (and answer) MUST be a valid SDP message, as defined by RFC
   2327 [1], with one exception.  RFC 2327 mandates that either an e or
   a p line is present in the SDP message.  This specification relaxes
   that constraint; an SDP formulated for an offer/answer application
   MAY omit both the e and p lines.  The numeric value of the session id
   and version in the o line MUST be representable with a 64 bit signed
   integer.  The initial value of the version MUST be less than
   (2**62)-1, to avoid rollovers.  Although the SDP specification allows
   for multiple session descriptions to be concatenated together into a
   large SDP message, an SDP message used in the offer/answer model MUST
   contain exactly one session description.

So what's easiest to change, deployed code or JSEP?

This note is also filed as https://github.com/rtcweb-wg/jsep/issues/855

-- 
Surveillance is pervasive. Go Dark.
--------------A7CA4284466BBCE090CD6C14-- From nobody Sat Nov 3 10:17:43 2018 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 2A026126CB6 for ; Sat, 3 Nov 2018 10:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 Drb2PM0-LA59 for ; Sat, 3 Nov 2018 10:17:40 -0700 (PDT) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 2AA06124D68 for ; Sat, 3 Nov 2018 10:17:40 -0700 (PDT) Received: by mail-it1-x129.google.com with SMTP id e11so4026841itl.5 for ; Sat, 03 Nov 2018 10:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ghUgu/l4MVuzu65+LQfeIgldA1UrYMR3+MQVvXP2SWA=; b=u5JMWt5seefg7KWVdzAatU9LISNQfgO8PNGGaRSt4ey0gRMOdxovrHglYDTnUKPOJB ZFn1Dd4PW3UsZmDaXv41laSsTEG6qVQ4k1Nc8njwb13RJ60+CfwLciLtEx0CcIBVrKVg DueJquMPwl43vD223mWbwc5FZW9DVw6RpdqemWSeUi70cquepuM/+xjU9W3cYuGagIVH v9a/DfYkvRwL/cN/77zTk8XddiJl6zl6Qn8YzMUr53R3KRY11ElhsCBh7eW2ju+3iNO4 IwV52+1FtIehjsZlumJq7r1ltauECdBBgwLPLKwIak7eLlzbnGleAdKm2YKUHaO37HzL FuLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ghUgu/l4MVuzu65+LQfeIgldA1UrYMR3+MQVvXP2SWA=; b=Fb1Y7oI16zgpyGiBoD3dcgwlt6lRutzzpPxe2gWPg1jPkx7urOFP7iiF/GLbGdwolC 8+ttDe/z0ukitFOY8WijvRLA9dPIwUBUntzJock9sbnnB7JdsxoOCA746aP73HrYfBrQ kvSf54p5kpNH+aKz2djGzhrGmLiN5DtGzNJZ7QLK8T1Tr/jwOMk7PxsIgc4NHNSzGD5M WPnkzXhX+3iIWQCLoRP0dn96yILYbE3UnNvAXKM5GwlMjAvi0YawRF3F4aOp8IUN436N bbCFl4FkwXAzbcxtCpkTV+c95nLIkbnC0eVaN4CT+nZdKg4ScZn9bv3C9/Pqp2ocvgkC LTpw== X-Gm-Message-State: AGRZ1gLqGfKSSgBLeeaaDqvX9n7UsScSkQ9WaAc884Gwfl2gtGD/zTjd gJU4l08RyItwVTSYLJ5wF/CEoAj8vdVRTcredQYwKD6GyAyC8w== X-Google-Smtp-Source: AJdET5e35ItuXu6aX125NB0zCqdNBnOD/DSEcMTJBQbbh/9gJvab1eO5FWduJlTr7OFUC2+q672+awdbKfOK5MXUeVY= X-Received: by 2002:a24:f60b:: with SMTP id u11-v6mr1443069ith.45.1541265458946; Sat, 03 Nov 2018 10:17:38 -0700 (PDT) MIME-Version: 1.0 References: <75f60e2f-d4c9-8d48-1f71-2ca3b733edee@alvestrand.no> In-Reply-To: <75f60e2f-d4c9-8d48-1f71-2ca3b733edee@alvestrand.no> From: Justin Uberti Date: Sat, 3 Nov 2018 10:17:27 -0700 Message-ID: To: Harald Alvestrand Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000002ff2bb0579c5d480" Archived-At: Subject: Re: [rtcweb] JSEP nit: Size of in the o= line X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2018 17:17:42 -0000 --0000000000002ff2bb0579c5d480 Content-Type: text/plain; charset="UTF-8" Agreed. Suggested new text: The sess-id MUST be representable by a 64-bit signed integer, and the value MUST be less than (2**63)-1, to prevent negatives. It is RECOMMENDED that the sess-id be constructed by generating a 64-bit quantity with the highest bit set to zero and the remaining 63 bits being cryptographically random. On Sat, Nov 3, 2018 at 1:39 AM Harald Alvestrand wrote: > JSEP -24 currently says: > > The sess-id MUST be representable by a 64-bit signed > integer, and the initial value MUST be less than (2**62)-1, as > required by [RFC3264 ]. It is RECOMMENDED that the sess-id be > constructed by generating a 64-bit quantity with the two highest > bits being set to zero and the remaining 62 bits being > cryptographically random. > > There are two problems here: > > - RFC 3264 actually doesn't place that restriction on the sess-id, that's > the restriction on the version field. > > - Deployed code (libwebrtc) generates sess-ids that are larger than 2^62-1 > > Quote from RFC 3264: > > The offer (and answer) MUST be a valid SDP message, as defined by RFC > 2327 [1 ], with one exception. RFC 2327 mandates that either an e or > a p line is present in the SDP message. This specification relaxes > that constraint; an SDP formulated for an offer/answer application > MAY omit both the e and p lines. The numeric value of the session id > and version in the o line MUST be representable with a 64 bit signed > integer. The initial value of the version MUST be less than > (2**62)-1, to avoid rollovers. Although the SDP specification allows > for multiple session descriptions to be concatenated together into a > large SDP message, an SDP message used in the offer/answer model MUST > contain exactly one session description. > > So what's easiest to change, deployed code or JSEP? > > This note is also filed as https://github.com/rtcweb-wg/jsep/issues/855 > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000002ff2bb0579c5d480 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed. Suggested new text:

      The sess-id MUST be representable by a 64-bit signed
      integer, and the value MUST be less than (2**63)-1, to prevent
      negatives.  It is RECOMMENDED that the sess-id be
      constructed by generating a 64-bit quantity with the highest
      bit set to zero and the remaining 63 bits being
      cryptographically random.

On Sat, Nov 3, 2018 at 1:39 AM Harald Alvestrand <= harald@alvestrand.no> wrote:=
=20 =20 =20

JSEP -24 currently says:

      The sess-id MUST be representable by a 64-bit signed
      integer, and the initial value MUST be less than (2**62)-1, as
      required by [RFC3264].  It is RECOMMENDED that the sess-id be
      constructed by generating a 64-bit quantity with the two highest
      bits being set to zero and the remaining 62 bits being
      cryptographically random.

There are two problems here:

- RFC 3264 actually doesn't place that restriction on the sess-id, that's the restriction on the version field.

- Deployed code (libwebrtc) generates sess-ids that are larger than 2^62-1

Quote from RFC 3264:

   The offer (and answer) MUST be a valid SDP message, as defin=
ed by RFC=

   2327 [1], with one e=
xception.  RFC 2327 mandates that either an e or
   a p line is present in the SDP message.  This specification relaxes
   that constraint; an SDP formulated for an offer/answer application
   MAY omit both the e and p lines.  The numeric value of the session id
   and version in the o line MUST be representable with a 64 bit signed
   integer.  The initial value of the version MUST be less than
   (2**62)-1, to avoid rollovers.  Although the SDP specification allows
   for multiple session descriptions to be concatenated together into a
   large SDP message, an SDP message used in the offer/answer model MUST
   contain exactly one session description.

So what's easiest to change, deployed code or JSEP?

This note is also filed as https://github.c= om/rtcweb-wg/jsep/issues/855

--=20
Surveillance is pervasive. Go Dark.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000002ff2bb0579c5d480-- From nobody Sat Nov 3 10:19:43 2018 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 E91AB124D68; Sat, 3 Nov 2018 10:19:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <154126557588.10280.1919574498136228272@ietfa.amsl.com> Date: Sat, 03 Nov 2018 10:19:35 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-11.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2018 17:19:36 -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 WG of the IETF. Title : WebRTC IP Address Handling Requirements Author : Justin Uberti Filename : draft-ietf-rtcweb-ip-handling-11.txt Pages : 12 Date : 2018-11-03 Abstract: This document provides information and requirements for how IP addresses should be handled by WebRTC implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-11 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Nov 3 10:25:10 2018 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 60E49126CB6 for ; Sat, 3 Nov 2018 10:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 cE5sN62PeJCz for ; Sat, 3 Nov 2018 10:25:05 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 86F58123FFD for ; Sat, 3 Nov 2018 10:25:05 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id d6so7384447itl.4 for ; Sat, 03 Nov 2018 10:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=llBPw8ltOInVYQH3mk4TS5iqlsbF3dpgVvaCfG2Ue8k=; b=pLnxYIyYw7aFz/JYBCp51AEXfICoGyIfPzT5L7uogJ8W5LMz3vDnnDh4Cu1N0bR3aj R1KsFWImWJLWtDEAp8ODiiPDDCwIVdemy/eggZTQhE1z1OU3s3O5R5FO3R1i48osz98U LbLQ8aBKMpRh9q0PgMKID53bo4lNsfg8i9Z9QbKDGcp/YFaydc0m0NT+wp97p3Db1J3e 8JjwoQkbOathv6dpfo6qnqiK2+6jKi9+fwsQK3i/yaVmOS8UCIK0SymivPYzMm23bHRe GFnUbTllw4oTMXW7cw1eb5D/yxdiZwC695XDQfqI9M9f1OrVYXYnT1dAQE3C2wcnOrsb SVSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=llBPw8ltOInVYQH3mk4TS5iqlsbF3dpgVvaCfG2Ue8k=; b=LC0X2N/6euVvjrj8vNfVtD4jPuXcF+Q+t3pftrHJ0pFFdzJH+cx/vB9AgMykn4lHd3 bzbJH2cptUi/TKwHJyz2alnLNZJMCgZMysJ+6HrM3XbGnSVxUKWjzY4nFPijjtUn8U88 cxEm4a5N1W/hhzKlb+OaojxNmbyI+MSZMxZ5aTaCZM35Jj4iklMrty79bv+5RuVWB9z0 zGghVj73XMmcv9qJDLMYj59gxf8kSPVO22tjiIrzOSf1+aV7NA+u9g/BcA6mc22bUJiA Vomg7Bxp0uhKf0udL2P7ZQ0rm7zNpaZT31IkQCmMZ71p9VWbKvxmd9pOfT56F83dDMKX JOtQ== X-Gm-Message-State: AGRZ1gKwQLlnYJKuot8fuxLy4INRHkGvIElfQwXgokVx22zD0mDSaMZR xpsvJ5qSss4ZsRsc1Z8zi5Tr+O+6N6yh4twH0yU+s9vyf66rQA== X-Google-Smtp-Source: AJdET5duoSrgre86+fMwfICOmpXDGKVn10KMOkJMm6HYGWqBcZVjzDfVJxEZGXDxCSaZz0WRj+40V0A95rO6CAXC2KE= X-Received: by 2002:a02:966e:: with SMTP id c101-v6mr2045629jai.58.1541265904417; Sat, 03 Nov 2018 10:25:04 -0700 (PDT) MIME-Version: 1.0 References: <773c8e91-a1d2-8c9e-fd19-c8b181f6dad1@nostrum.com> In-Reply-To: From: Justin Uberti Date: Sat, 3 Nov 2018 10:24:52 -0700 Message-ID: To: Adam Roach Cc: draft-ietf-rtcweb-ip-handling.all@ietf.org, RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000bd3f630579c5ee4c" Archived-At: Subject: Re: [rtcweb] AD review: draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2018 17:25:09 -0000 --000000000000bd3f630579c5ee4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-11 On Fri, Nov 2, 2018 at 9:35 AM Justin Uberti wrote: > See https://github.com/rtcweb-wg/ip-handling/pull/1 > > Will send out a new version of the doc when the upload tool reopens. > > On Thu, Nov 1, 2018 at 6:15 PM Adam Roach wrote: > >> This is my AD review for draft-ietf-rtcweb-ip-handling. >> >> I think this document is ready to go into IETF last call, modulo the ICE >> citation issue. I plan to issue last call for this document at the same >> time >> as draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-security, so it >> will >> wait for those to become ready. >> >> I'm marking the document as "revised ID needed" pending the ICE referenc= e >> update. >> >> >> ------------------------------------------------------------------------= --- >> >> [DISCUSS] >> >> Per the discussion around Cluster 238 dependencies, please reference RFC >> 8445 >> instead of RFC 5245. >> >> >> ------------------------------------------------------------------------= --- >> >> =C2=A72: >> >> Please update to match the RFC 8174 boilerplate. >> >> >> ------------------------------------------------------------------------= --- >> >> =C2=A75.2: >> >> > Future versions of this document may define additional modes and/or >> > update the recommended default modes. >> >> Suggest: "Future documents may...", as future consensus may be to update >> rather >> than replace this document. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > --000000000000bd3f630579c5ee4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 2, 2018 at 9:35 AM Justin Ube= rti <juberti@google.com> wr= ote:
Will send out a new version of the doc when t= he upload tool reopens.

On Thu, Nov 1, 2018 at 6:15 PM Adam Roach <adam@nostrum.com> wrote:
=
This is my AD review for draft-ietf-rtcweb-i= p-handling.

I think this document is ready to go into IETF last call, modulo the ICE citation issue. I plan to issue last call for this document at the same tim= e
as draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-security, so it will
wait for those to become ready.

I'm marking the document as "revised ID needed" pending the I= CE reference
update.

---------------------------------------------------------------------------=

[DISCUSS]

Per the discussion around Cluster 238 dependencies, please reference RFC 8445
instead of RFC 5245.

---------------------------------------------------------------------------=

=C2=A72:

Please update to match the RFC 8174 boilerplate.

---------------------------------------------------------------------------=

=C2=A75.2:

=C2=A0>=C2=A0 Future versions of this document may define additional mod= es and/or
=C2=A0>=C2=A0 update the recommended default modes.

Suggest: "Future documents may...", as future consensus may be to= update
rather
than replace this document.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000bd3f630579c5ee4c-- From nobody Sat Nov 3 10:44:45 2018 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 C55A0123FFD for ; Sat, 3 Nov 2018 10:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 GFSgf01epGhE for ; Sat, 3 Nov 2018 10:44:41 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 1CAEA126CB6 for ; Sat, 3 Nov 2018 10:44:41 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id b7-v6so7410519itd.5 for ; Sat, 03 Nov 2018 10:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=YJ2bCODLr9YD2iELHMzStMHaeeB1Hhft70Uqr+ADIt8=; b=M340Zz8VgJWjJTZkUbvJGsBCVHqH61mXc3RXjbW0uKXSAqN5zyIaRaaICDRbP7zkEF O37d1eDkOQtnqUbHFHlRFImD30xfEumTAkCJsrdspaS5l74WhSz9wjPiPFrHDMg+XCyA qG1XS8OysN28/1LK/tHgTNyn3v5xLjFxEE3eyOxLNySDWmFcpQuFFz4NyZyQqfXurJmE JzB9y4H+czN2f/MLSlyfGFDIzGtr1mBA0mIjarczLOyFOQe/eCN+/yqatyW8DcCqmP4j mJOSL1YSeogBNEUTNjQA4osNaRY2YqJ6Q9dBDQE2ncw/mNBzVVGQkl/IhQInSfKZlVwK ZSjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=YJ2bCODLr9YD2iELHMzStMHaeeB1Hhft70Uqr+ADIt8=; b=YnI8gPFhnF9+GxlVLI7ekS5LzreVCQWS4TAIyrIahnAteoeGSrnnEb4sb/w0t+OXJa 9esPYCSENRpG6201bH2MLLVGB6wxdKVRPJp1/ZkkyciUA/32JTl6DxDY8eo7UZdGJdaW sIAxgj8yBUNhuGc1OsFdSGeiSJYbQOQn7Ww0C7vWh9hqqzFX9qSayR17YG3ebnbeNd1W MHYNz/u+LrIaJsQlHS8+lHlklH5djo/3C3/H8m65uXeWhZEbo0PhQTZuuf1Cgo5CxLJK 7hN2obqTwGZe9fBJhsdCLKyD2xz0FiLDW7pCsDqSTnan4TjypcKOq3vb1UhyRDrQgp4U HbLA== X-Gm-Message-State: AGRZ1gKVRZs56bCX6ak4v16smK7jOjhpoi9vyI2HHZtC6ivd+j5X82R6 7ZgjP5x6+N+1DtJEwIdJwBFC1jfHVoGqZVniYgQ76fcyB2I= X-Google-Smtp-Source: AJdET5ev5AHHEOZWB7u7sX7+CpuzdObA09YUrSd4fatNqKDzZtavNgm76PeqCc1kRy7wVOqCzmwGmQIMWPU3trMKaTk= X-Received: by 2002:a24:f60b:: with SMTP id u11-v6mr1500862ith.45.1541267079592; Sat, 03 Nov 2018 10:44:39 -0700 (PDT) MIME-Version: 1.0 References: <154126685980.10230.15547151974684728173.idtracker@ietfa.amsl.com> In-Reply-To: <154126685980.10230.15547151974684728173.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Sat, 3 Nov 2018 10:44:27 -0700 Message-ID: To: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000c8b0a00579c63486" Archived-At: Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-ip-handling-ex-mdns-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2018 17:44:44 -0000 --000000000000c8b0a00579c63486 Content-Type: text/plain; charset="UTF-8" An extension document for rtcweb-ip-handling that defines new modes that make use of the mDNS technique described in rtcweb-mdns-ice-candidates . ---------- Forwarded message --------- From: Date: Sat, Nov 3, 2018 at 10:41 AM Subject: New Version Notification for draft-uberti-rtcweb-ip-handling-ex-mdns-00.txt To: Justin Uberti , Jeroen de Borst , Qingsi Wang , Youenn Fablet A new version of I-D, draft-uberti-rtcweb-ip-handling-ex-mdns-00.txt has been successfully submitted by Justin Uberti and posted to the IETF repository. Name: draft-uberti-rtcweb-ip-handling-ex-mdns Revision: 00 Title: WebRTC IP Address Handling Extensions for Multicast DNS Document date: 2018-11-03 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-uberti-rtcweb-ip-handling-ex-mdns-00.txt Status: https://datatracker.ietf.org/doc/draft-uberti-rtcweb-ip-handling-ex-mdns/ Htmlized: https://tools.ietf.org/html/draft-uberti-rtcweb-ip-handling-ex-mdns-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-uberti-rtcweb-ip-handling-ex-mdns Abstract: This document extends the previous WebRTC IP Address Handling Requirements with new modes that make use of Multicast DNS ICE candidates, and updates the recommendations accordingly. 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. The IETF Secretariat --000000000000c8b0a00579c63486 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
An extension document for rtcweb-ip-handling that define= s new modes that make use of the mDNS technique described in rtcweb-m= dns-ice-candidates.

= ---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Sat, Nov 3, 2018 at 10:41 AM
Subject: New Version Notificat= ion for draft-uberti-rtcweb-ip-handling-ex-mdns-00.txt
To: Justin Uberti= <juberti@google.com>, Jero= en de Borst <jeroendb@google.com<= /a>>, Qingsi Wang <qingsi@google= .com>, Youenn Fablet <youenn@= apple.com>



A new version of I-D, draft-uberti-rtcweb-ip-handling-ex-mdns-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-uberti-rtcweb-ip-handli= ng-ex-mdns
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WebRTC IP Address Handling Extensi= ons for Multicast DNS
Document date:=C2=A0 2018-11-03
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ube= rti-rtcweb-ip-handling-ex-mdns-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-uberti-rtcweb-ip-handl= ing-ex-mdns/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-uberti-rtcweb-ip-handling-ex-mdns-0= 0
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-uberti-rtcweb-ip-h= andling-ex-mdns


Abstract:
=C2=A0 =C2=A0This document extends the previous WebRTC IP Address Handling<= br> =C2=A0 =C2=A0Requirements with new modes that make use of Multicast DNS ICE=
=C2=A0 =C2=A0candidates, and updates the recommendations accordingly.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--000000000000c8b0a00579c63486-- From nobody Sat Nov 3 15:33:34 2018 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 A59D4130DC3; Sat, 3 Nov 2018 15:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 z25XOayYVFCP; Sat, 3 Nov 2018 15:33:23 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117B112F1A5; Sat, 3 Nov 2018 15:33:23 -0700 (PDT) Received: from dhcp-9bba.meeting.ietf.org (dhcp-9bba.meeting.ietf.org [31.133.155.186]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA3MXFSO040783 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 3 Nov 2018 17:33:17 -0500 (CDT) (envelope-from adam@nostrum.com) To: Justin Uberti Cc: draft-ietf-rtcweb-ip-handling.all@ietf.org, RTCWeb IETF References: <773c8e91-a1d2-8c9e-fd19-c8b181f6dad1@nostrum.com> From: Adam Roach Message-ID: Date: Sun, 4 Nov 2018 05:33:14 +0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4ACB752FA543771CE813C4A4" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] AD review: draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2018 22:33:33 -0000 This is a multi-part message in MIME format. --------------4ACB752FA543771CE813C4A4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for the fast turn-around! /a On 11/4/18 00:24, Justin Uberti wrote: > https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-11 > > On Fri, Nov 2, 2018 at 9:35 AM Justin Uberti > wrote: > > See https://github.com/rtcweb-wg/ip-handling/pull/1 > > Will send out a new version of the doc when the upload tool reopens. > > On Thu, Nov 1, 2018 at 6:15 PM Adam Roach > wrote: > > This is my AD review for draft-ietf-rtcweb-ip-handling. > > I think this document is ready to go into IETF last call, > modulo the ICE > citation issue. I plan to issue last call for this document at > the same time > as draft-ietf-rtcweb-security-arch and > draft-ietf-rtcweb-security, so it > will > wait for those to become ready. > > I'm marking the document as "revised ID needed" pending the > ICE reference > update. > > --------------------------------------------------------------------------- > > [DISCUSS] > > Per the discussion around Cluster 238 dependencies, please > reference RFC > 8445 > instead of RFC 5245. > > --------------------------------------------------------------------------- > > §2: > > Please update to match the RFC 8174 boilerplate. > > --------------------------------------------------------------------------- > > §5.2: > >  >  Future versions of this document may define additional > modes and/or >  >  update the recommended default modes. > > Suggest: "Future documents may...", as future consensus may be > to update > rather > than replace this document. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --------------4ACB752FA543771CE813C4A4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks for the fast turn-around!

/a

On 11/4/18 00:24, Justin Uberti wrote:

On Fri, Nov 2, 2018 at 9:35 AM Justin Uberti <juberti@google.com> wrote:

Will send out a new version of the doc when the upload tool reopens.

On Thu, Nov 1, 2018 at 6:15 PM Adam Roach <adam@nostrum.com> wrote:
This is my AD review for draft-ietf-rtcweb-ip-handling.

I think this document is ready to go into IETF last call, modulo the ICE
citation issue. I plan to issue last call for this document at the same time
as draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-security, so it
will
wait for those to become ready.

I'm marking the document as "revised ID needed" pending the ICE reference
update.

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

[DISCUSS]

Per the discussion around Cluster 238 dependencies, please reference RFC
8445
instead of RFC 5245.

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

§2:

Please update to match the RFC 8174 boilerplate.

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

§5.2:

 >  Future versions of this document may define additional modes and/or
 >  update the recommended default modes.

Suggest: "Future documents may...", as future consensus may be to update
rather
than replace this document.

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


--------------4ACB752FA543771CE813C4A4-- From nobody Sat Nov 3 16:04:23 2018 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 B35CF128766 for ; Sat, 3 Nov 2018 16:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] 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 Ex7l9mo1wMop for ; Sat, 3 Nov 2018 16:04:19 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F8C129619 for ; Sat, 3 Nov 2018 16:04:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 60CC67C575C; Sun, 4 Nov 2018 00:04:16 +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 dDNWt-7JarL8; Sun, 4 Nov 2018 00:04:13 +0100 (CET) Received: from [172.20.18.215] (110-170-235-6.static.asianet.co.th [110.170.235.6]) by mork.alvestrand.no (Postfix) with ESMTPSA id F2E957C392F; Sun, 4 Nov 2018 00:04:12 +0100 (CET) To: Justin Uberti Cc: RTCWeb IETF References: <75f60e2f-d4c9-8d48-1f71-2ca3b733edee@alvestrand.no> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <08f6a3a1-e73d-83d2-78e4-233a95c538ed@alvestrand.no> Date: Sun, 4 Nov 2018 00:04:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E150589786EFB5A1682804D0" Content-Language: en-GB Archived-At: Subject: Re: [rtcweb] JSEP nit: Size of in the o= line X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2018 23:04:22 -0000 This is a multi-part message in MIME format. --------------E150589786EFB5A1682804D0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 11/03/2018 06:17 PM, Justin Uberti wrote: > Agreed. Suggested new text: Suggested addition: "As stated in RFC 3264, ...." - these are not new requirements, they're repeating old requirements. > > The sess-id MUST be representable by a 64-bit signed > integer, and the value MUST be less than (2**63)-1, to prevent > negatives. It is RECOMMENDED that the sess-id be > constructed by generating a 64-bit quantity with the highest > bit set to zero and the remaining 63 bits being > cryptographically random. Suggested addition:   The sess-version MUST be less than (2**62) - 1, to avoid overflow when incrementing. > > On Sat, Nov 3, 2018 at 1:39 AM Harald Alvestrand > wrote: > > JSEP -24 currently says: > > The sess-id MUST be representable by a 64-bit signed > integer, and the initial value MUST be less than (2**62)-1, as > required by [RFC3264 ]. It is RECOMMENDED that the sess-id be > constructed by generating a 64-bit quantity with the two highest > bits being set to zero and the remaining 62 bits being > cryptographically random. > > There are two problems here: > > - RFC 3264 actually doesn't place that restriction on the sess-id, > that's the restriction on the version field. > > - Deployed code (libwebrtc) generates sess-ids that are larger > than 2^62-1 > > Quote from RFC 3264: > > The offer (and answer) MUST be a valid SDP message, as defined by RFC > 2327 [1 ], with one exception. RFC 2327 mandates that either an e or > a p line is present in the SDP message. This specification relaxes > that constraint; an SDP formulated for an offer/answer application > MAY omit both the e and p lines. The numeric value of the session id > and version in the o line MUST be representable with a 64 bit signed > integer. The initial value of the version MUST be less than > (2**62)-1, to avoid rollovers. Although the SDP specification allows > for multiple session descriptions to be concatenated together into a > large SDP message, an SDP message used in the offer/answer model MUST > contain exactly one session description. > > So what's easiest to change, deployed code or JSEP? > > This note is also filed as > https://github.com/rtcweb-wg/jsep/issues/855 > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Surveillance is pervasive. Go Dark. --------------E150589786EFB5A1682804D0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/03/2018 06:17 PM, Justin Uberti wrote:
Agreed. Suggested new text:

Suggested addition: "As stated in RFC 3264, ...." - these are not new requirements, they're repeating old requirements.

      The sess-id MUST be representable by a 64-bit signed
      integer, and the value MUST be less than (2**63)-1, to prevent
      negatives.  It is RECOMMENDED that the sess-id be
      constructed by generating a 64-bit quantity with the highest
      bit set to zero and the remaining 63 bits being
      cryptographically random.

Suggested addition:

  The sess-version MUST be less than (2**62) - 1, to avoid overflow when incrementing.


On Sat, Nov 3, 2018 at 1:39 AM Harald Alvestrand <harald@alvestrand.no> wrote:

JSEP -24 currently says:

      The sess-id MUST be representable by a 64-bit signed
      integer, and the initial value MUST be less than (2**62)-1, as
      required by [RFC3264].  It is RECOMMENDED that the sess-id be
      constructed by generating a 64-bit quantity with the two highest
      bits being set to zero and the remaining 62 bits being
      cryptographically random.

There are two problems here:

- RFC 3264 actually doesn't place that restriction on the sess-id, that's the restriction on the version field.

- Deployed code (libwebrtc) generates sess-ids that are larger than 2^62-1

Quote from RFC 3264:

   The offer (and answer) MUST be a valid SDP message, as defined by RFC
   2327 [1], with one exception.  RFC 2327 mandates that either an e or
   a p line is present in the SDP message.  This specification relaxes
   that constraint; an SDP formulated for an offer/answer application
   MAY omit both the e and p lines.  The numeric value of the session id
   and version in the o line MUST be representable with a 64 bit signed
   integer.  The initial value of the version MUST be less than
   (2**62)-1, to avoid rollovers.  Although the SDP specification allows
   for multiple session descriptions to be concatenated together into a
   large SDP message, an SDP message used in the offer/answer model MUST
   contain exactly one session description.

So what's easiest to change, deployed code or JSEP?

This note is also filed as https://github.com/rtcweb-wg/jsep/issues/855

-- 
Surveillance is pervasive. Go Dark.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Surveillance is pervasive. Go Dark.
--------------E150589786EFB5A1682804D0-- From nobody Sat Nov 3 23:50:59 2018 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 0D9F1130DF5 for ; Sat, 3 Nov 2018 23:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 RpuKGgNf2VaB for ; Sat, 3 Nov 2018 23:50:54 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 4200C130DFA for ; Sat, 3 Nov 2018 23:50:54 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id o19-v6so4269033iod.3 for ; Sat, 03 Nov 2018 23:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1zecHfsaL6anVhR6r79AohrEcZ+oC0M8BJOSuqwPNcQ=; b=N6X0pzuSNL1kdqnpiw4MPctAsnIXMhWuMaLWQ4GIcaZE7qDKh25fD+z+SAOIZzn0+2 4Zi4lYLD0cKryUlnXqiLCBBtDPLL8qBpkmF4F37P7VWIykRRsxmQ+K1P8LsQJPawna5a wtNrwM/f/EYmiZxv8F5YbXYt4EO/dsVXmtCC+Ed7DsGgJPJ39dF3ms8QL80eZsCkUpIM P2saALJIY1+Vq7PrcpYGA/wvOtcMzWUazd8UuCmYtmtIrBcrxrO038A92AcbSm8ibHc/ 59C69MW31P/M9+fIEwyUSyQt9c1KZjT3bBj8mn9zLEqeU+p5iJjHaHkqauOGxg14Yrjk n4ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1zecHfsaL6anVhR6r79AohrEcZ+oC0M8BJOSuqwPNcQ=; b=TeSsMazdVco9RT+LA3rDvnv0b31iOKNjcFG3+7K3mr1gsEoIbv/PB5yKnSMzD+1Keh juUTU7fGBbUjVxWRUUZnlzGrhM6zCBO+f37nW+WMjykBWZFWwbIaajCn7/SLrq0Czt+i rJJ1XJ7tm/izYPaje6dVBoBkxJB2Utu9OrAO7vGdlAGYKr7xjRUm+ZschCcvN/hzyQUA KjSvgoO0M5lN3DN6t2OozWvAAxXecaQWRkHMxVJScBatp1jnfpGTg3hb802Zp1R4OeAR 6OB037xkw2pMB8s37DkoyxW//l+ybsNfog68lq9B/DPgOfazFWiTKmKlImJr3qa4xYuO bCVg== X-Gm-Message-State: AGRZ1gIxL9apk3n7gR5o/weZ/uFcFJ1EwrNs+wiMLd/C8pUhxyPf0bcd C6kW5HKVL4wHzdgZ3ZNn4Mwe6uddR6Ki/n17n63pk89l3Jw= X-Google-Smtp-Source: AJdET5cDj/MEsbe6rjhT8ubXQIfEL6SL6YNpDb0dkzGC0Jh9gaqxD8Pq2uDGf7yqx8+X3mwQ/L9/uSKVYx4SdG9OoRc= X-Received: by 2002:a5e:980f:: with SMTP id s15-v6mr13939990ioj.87.1541314253120; Sat, 03 Nov 2018 23:50:53 -0700 (PDT) MIME-Version: 1.0 References: <75f60e2f-d4c9-8d48-1f71-2ca3b733edee@alvestrand.no> <08f6a3a1-e73d-83d2-78e4-233a95c538ed@alvestrand.no> In-Reply-To: <08f6a3a1-e73d-83d2-78e4-233a95c538ed@alvestrand.no> From: Justin Uberti Date: Sat, 3 Nov 2018 23:50:41 -0700 Message-ID: To: Harald Alvestrand Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000008bbcc50579d130e8" Archived-At: Subject: Re: [rtcweb] JSEP nit: Size of in the o= line X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 06:50:57 -0000 --0000000000008bbcc50579d130e8 Content-Type: text/plain; charset="UTF-8" SGTM On Sat, Nov 3, 2018 at 4:04 PM Harald Alvestrand wrote: > On 11/03/2018 06:17 PM, Justin Uberti wrote: > > Agreed. Suggested new text: > > > Suggested addition: "As stated in RFC 3264, ...." - these are not new > requirements, they're repeating old requirements. > > > The sess-id MUST be representable by a 64-bit signed > integer, and the value MUST be less than (2**63)-1, to prevent > negatives. It is RECOMMENDED that the sess-id be > constructed by generating a 64-bit quantity with the highest > bit set to zero and the remaining 63 bits being > cryptographically random. > > > Suggested addition: > > The sess-version MUST be less than (2**62) - 1, to avoid overflow when > incrementing. > > > On Sat, Nov 3, 2018 at 1:39 AM Harald Alvestrand > wrote: > >> JSEP -24 currently says: >> >> The sess-id MUST be representable by a 64-bit signed >> integer, and the initial value MUST be less than (2**62)-1, as >> required by [RFC3264 ]. It is RECOMMENDED that the sess-id be >> constructed by generating a 64-bit quantity with the two highest >> bits being set to zero and the remaining 62 bits being >> cryptographically random. >> >> There are two problems here: >> >> - RFC 3264 actually doesn't place that restriction on the sess-id, that's >> the restriction on the version field. >> >> - Deployed code (libwebrtc) generates sess-ids that are larger than 2^62-1 >> >> Quote from RFC 3264: >> >> The offer (and answer) MUST be a valid SDP message, as defined by RFC >> 2327 [1 ], with one exception. RFC 2327 mandates that either an e or >> a p line is present in the SDP message. This specification relaxes >> that constraint; an SDP formulated for an offer/answer application >> MAY omit both the e and p lines. The numeric value of the session id >> and version in the o line MUST be representable with a 64 bit signed >> integer. The initial value of the version MUST be less than >> (2**62)-1, to avoid rollovers. Although the SDP specification allows >> for multiple session descriptions to be concatenated together into a >> large SDP message, an SDP message used in the offer/answer model MUST >> contain exactly one session description. >> >> So what's easiest to change, deployed code or JSEP? >> >> This note is also filed as https://github.com/rtcweb-wg/jsep/issues/855 >> >> -- >> Surveillance is pervasive. Go Dark. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > -- > Surveillance is pervasive. Go Dark. > > --0000000000008bbcc50579d130e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
SGTM

= On Sat, Nov 3, 2018 at 4:04 PM Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
On 11/03/2018 06:1= 7 PM, Justin Uberti wrote:
=20
Agreed. Suggested new text:

Suggested addition: "As stated in RFC 3264, ...." - these are= not new requirements, they're repeating old requirements.

      The sess-id MUST b=
e representable by a 64-bit signed
      integer, and the value MUST be less than (2**63)-1, to prevent
      negatives.  It is RECOMMENDED that the sess-id be
      constructed by generating a 64-bit quantity with the highest
      bit set to zero and the remaining 63 bits being
      cryptographically random.

Suggested addition:

=C2=A0 The sess-version MUST be less than (2**62) - 1, to avoid overflo= w when incrementing.


On Sat, Nov 3, 2018 at 1:39 AM Harald Alvestrand <har= ald@alvestrand.no> wrote:

JSEP -24 currently says:

      The sess-id MUST be represe=
ntable by a 64-bit signed
      integer, and the initial value MUST be less than (2**62)-1, as
      required by [RFC3264].  It is RECOMMENDED that the sess-id be
      constructed by generating a 64-bit quantity with the two highest
      bits being set to zero and the remaining 62 bits being
      cryptographically random.

There are two problems here:

- RFC 3264 actually doesn't place that restriction on th= e sess-id, that's the restriction on the version field.

- Deployed code (libwebrtc) generates sess-ids that are larger than 2^62-1

Quote from RFC 3264:

   The offer (and answer) MUST be=
 a valid SDP message, as defined by RFC
   2327 [1], with one e=
xception.  RFC 2327 mandates that either an e or
   a p line is present in the SDP message.  This specification relaxes
   that constraint; an SDP formulated for an offer/answer application
   MAY omit both the e and p lines.  The numeric value of the session id
   and version in the o line MUST be representable with a 64 bit signed
   integer.  The initial value of the version MUST be less than
   (2**62)-1, to avoid rollovers.  Although the SDP specification allows
   for multiple session descriptions to be concatenated together into a
   large SDP message, an SDP message used in the offer/answer model MUST
   contain exactly one session description.

So what's easiest to change, deployed code or JSEP?

This note is also filed as https://github.com/rtcweb-wg/jsep= /issues/855

--=20
Surveillance is pervasive. Go Dark.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.= org
https://www.ietf.org/mailman/listinfo/rtcweb


--=20
Surveillance is pervasive. Go Dark.
--0000000000008bbcc50579d130e8-- From nobody Sun Nov 4 01:13:39 2018 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 56BE2127332 for ; Sun, 4 Nov 2018 01:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 xJXWrWH9Pmub for ; Sun, 4 Nov 2018 01:13:35 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0D1127133 for ; Sun, 4 Nov 2018 01:13:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 631FD7C574D for ; Sun, 4 Nov 2018 09:13:33 +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 wMo1Y1pBoscY for ; Sun, 4 Nov 2018 09:13:32 +0100 (CET) Received: from [172.20.18.215] (110-170-235-6.static.asianet.co.th [110.170.235.6]) by mork.alvestrand.no (Postfix) with ESMTPSA id A21B07C3B80 for ; Sun, 4 Nov 2018 09:13:31 +0100 (CET) To: "rtcweb@ietf.org" From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> Date: Sun, 4 Nov 2018 09:13:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Archived-At: Subject: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 08:13:38 -0000 In JSEP, we have the following text: =C2=A0=C2=A0 In addition, JSEP does not provide a mechanism to handle an = incoming =C2=A0=C2=A0 offer requesting simulcast from the JSEP endpoint.=C2=A0 Thi= s means that =C2=A0=C2=A0 setting up simulcast in the case where the JSEP endpoint rec= eives the =C2=A0=C2=A0 initial offer requires out-of-band signaling or SDP inspecti= on. In WEBRTC, we have been grappling with the problem of simulcast setup, and it seems that we have no obvious API surface that can be used for this purpose - creating transceivers (as we do for outgoing) doesn't fit the bill, because incoming SDP causes transceivers to be created wihout interacting with the API surface. I tried to drum up a test that would create such a setup based on SDP, but found that in conformance with JSEP, this doesn't work. Can someone tell me why we decided to not allow an incoming offer with a=3Dsimulcast and a=3Drid ... recv in it to generate outgoing simulcast capability? The test in question: https://github.com/web-platform-tests/wpt/pull/13902 Harald --=20 Surveillance is pervasive. Go Dark. From nobody Sun Nov 4 01:34:44 2018 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 11476127332 for ; Sun, 4 Nov 2018 01:34:43 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 oZTSV7QIV3th for ; Sun, 4 Nov 2018 01:34:40 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 9966E127133 for ; Sun, 4 Nov 2018 01:34:40 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id e22-v6so2954561pfn.8 for ; Sun, 04 Nov 2018 01:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Dg/z8mb9hnHRW92aLVJ2d4HfqSrrg5WmsIsqtM0SvxI=; b=gO4mHfVmtOVJA1+NGN7jhGQgS+p8itksl4/vJoklZqCygwO0vHdKqjoQ+q4Y+sZOVS EvyYY1snMRiUzUjtZsD/sPkq3QE+CAt93MyUWLTVG62c5XRpx9HTbfJPQ0uWFOYPhOQ/ snMSFHcwjKIaTxKR2412AODOedDmjFYCycK1Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Dg/z8mb9hnHRW92aLVJ2d4HfqSrrg5WmsIsqtM0SvxI=; b=LSnHft5br9A9Zk7rYVYIKDvP1jyD4kd+YvP7UEIkzZFBAeqwv2Yv/iau0N2d92Fk2B SGGKCKDnFhGncv9eJI7dwdFLugteWuP2Nwf3CcV2Bazgzp0R4rRZTP81ORrY/Ese8xWH ZgMGFY6YGrdkun6hEf4HH7/wvvlJ3dVWktQ61EEQJtjrCE/pq92rRo6PvllGAUDxtfU3 qt1mnzjWwRXUVMXUX/aucGrit1s8yGDKM7A6K9xv9wdfqJ77XSor689j5UfXZgGXQjTw /yxkFAnoZpK7IFW1xuW6De3siU8ANh0kueZFQctR0GY+cR+i4hYYGtjQBtcPWc7qB8kv TfIw== X-Gm-Message-State: AGRZ1gKlmjKZ+7mhH5U0GerGjOsVWTyFkLgii/4C4fQ2DKnKGTMda2b9 mkTOBr4OiNt/Z7gowTP8qoclGQDDiHipIQ== X-Google-Smtp-Source: AJdET5eYiCXcwWONM3zvTc+D362dO2/0zmnMkY85nFNavt8Ye/dL26YrgvY8rCwIuh0xdYMAMFR8aQ== X-Received: by 2002:a62:8012:: with SMTP id j18-v6mr17814316pfd.202.1541320480091; Sun, 04 Nov 2018 01:34:40 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:d0d8:d08:476c:d5cd? ([2001:67c:370:128:d0d8:d08:476c:d5cd]) by smtp.gmail.com with ESMTPSA id a4-v6sm14530622pgw.68.2018.11.04.01.34.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Nov 2018 01:34:38 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A7DAEB5F-0DE1-47E2-B6F8-6E91B9D1A873" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Sun, 4 Nov 2018 15:34:35 +0700 In-Reply-To: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> Cc: "rtcweb@ietf.org" To: Harald Alvestrand References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 08:34:43 -0000 --Apple-Mail=_A7DAEB5F-0DE1-47E2-B6F8-6E91B9D1A873 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4Nov, 2018, at 15:13, Harald Alvestrand = wrote: >=20 > In JSEP, we have the following text: >=20 >=20 > In addition, JSEP does not provide a mechanism to handle an = incoming > offer requesting simulcast from the JSEP endpoint. This means that > setting up simulcast in the case where the JSEP endpoint receives = the > initial offer requires out-of-band signaling or SDP inspection. >=20 > In WEBRTC, we have been grappling with the problem of simulcast setup, > and it seems that we have no obvious API surface that can be used for > this purpose - creating transceivers (as we do for outgoing) doesn't = fit > the bill, because incoming SDP causes transceivers to be created = wihout > interacting with the API surface. >=20 > I tried to drum up a test that would create such a setup based on SDP, > but found that in conformance with JSEP, this doesn't work. >=20 > Can someone tell me why we decided to not allow an incoming offer with > a=3Dsimulcast and a=3Drid ... recv in it to generate outgoing = simulcast > capability? >=20 > The test in question: >=20 > https://github.com/web-platform-tests/wpt/pull/13902 I can=E2=80=99t answer your question of why not. But it is working in Firefox as this test shows=20 = https://searchfox.org/mozilla-central/source/dom/media/tests/mochitest/tes= t_peerConnection_simulcastAnswer.html#59 = I would have to look into the details, but I think for it to work you = have to setup the RTP senders before setting the Offer (which is = arguably not a nice API design). Which usually is not a big problem as = the server which wants to receive simulcast knows how many RID=E2=80=99s = it wants to get. Best Nils Ohlmeier= --Apple-Mail=_A7DAEB5F-0DE1-47E2-B6F8-6E91B9D1A873 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 4Nov, 2018, at 15:13, Harald Alvestrand <harald@alvestrand.no> wrote:

In = JSEP, we have the following text:


   In addition, JSEP does not provide a mechanism = to handle an incoming
   offer requesting = simulcast from the JSEP endpoint.  This means that
   setting up simulcast in the case where the JSEP = endpoint receives the
   initial offer requires = out-of-band signaling or SDP inspection.

In = WEBRTC, we have been grappling with the problem of simulcast setup,
and it seems that we have no obvious API surface that can be = used for
this purpose - creating transceivers (as we do = for outgoing) doesn't fit
the bill, because incoming SDP = causes transceivers to be created wihout
interacting with = the API surface.

I tried to drum up a test = that would create such a setup based on SDP,
but found = that in conformance with JSEP, this doesn't work.

Can someone tell me why we decided to not allow an incoming = offer with
a=3Dsimulcast and a=3Drid ... recv in it to = generate outgoing simulcast
capability?

The test in question:

https://github.com/web-platform-tests/wpt/pull/13902

I= can=E2=80=99t answer your question of why not.
But = it is working in Firefox as this test shows 
https://searchfox.org/mozilla-central/source/dom/media/tests/mo= chitest/test_peerConnection_simulcastAnswer.html#59

I would have to look = into the details, but I think for it to work you have to setup the RTP = senders before setting the Offer (which is arguably not a nice API = design). Which usually is not a big problem as the server which wants to = receive simulcast knows how many RID=E2=80=99s it wants to = get.

Best
  Nils = Ohlmeier
= --Apple-Mail=_A7DAEB5F-0DE1-47E2-B6F8-6E91B9D1A873-- From nobody Sun Nov 4 01:04:32 2018 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 E46E6130E10 for ; Sun, 4 Nov 2018 01:04:30 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 S9hOphsKRJ67 for ; Sun, 4 Nov 2018 01:04:28 -0800 (PST) Received: from smtp121.iad3b.emailsrvr.com (smtp121.iad3b.emailsrvr.com [146.20.161.121]) (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 00C0E130E11 for ; Sun, 4 Nov 2018 01:04:27 -0800 (PST) Received: from smtp16.relay.iad3b.emailsrvr.com (localhost [127.0.0.1]) by smtp16.relay.iad3b.emailsrvr.com (SMTP Server) with ESMTP id ED02FC011E; Sun, 4 Nov 2018 04:04:26 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp16.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5F255C010B; Sun, 4 Nov 2018 04:04:25 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.68.211.195] ([UNAVAILABLE]. [173.39.121.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.7.12); Sun, 04 Nov 2018 04:04:26 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_3847EC66-5492-4C74-A965-F798C6CB0E66" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <3283c7fe-6cc6-71b8-1208-d65e00c2df8e@nostrum.com> Date: Sun, 4 Nov 2018 16:04:30 +0700 Cc: draft-ietf-rtcweb-security-arch.all@ietf.org, RTCWeb IETF Message-Id: <73D9B935-234F-4DCF-AA1B-B8E958DF66B7@iii.ca> References: <3283c7fe-6cc6-71b8-1208-d65e00c2df8e@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] AD Review: draft-ietf-rtcweb-security-arch X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 09:04:31 -0000 --Apple-Mail=_3847EC66-5492-4C74-A965-F798C6CB0E66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 31, 2018, at 9:48 AM, Adam Roach wrote: >=20 > =3D=3D The document seems to contain a disclaimer for pre-RFC5378 = work, but was > first submitted on or after 10 November 2008. The disclaimer is = usually > necessary only for documents that revise or obsolete older RFCs, = and that > take significant amounts of text from those RFCs. If you can = contact all > authors of the source material and they are willing to grant the = BCP78 > rights to the IETF Trust, you can and should remove the = disclaimer. > Otherwise, the disclaimer is needed and you can ignore this = comment. > (See the Legal Provisions document at > https://trustee.ietf.org/license-info = for more information.) I belive the draft cut and paste in significant text from pre-RFC5378 = based drafts thus I don't think we can fix this.=20 --Apple-Mail=_3847EC66-5492-4C74-A965-F798C6CB0E66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 31, 2018, at 9:48 AM, Adam Roach <adam@nostrum.com> = wrote:

  =3D=3D The document seems to contain a = disclaimer for pre-RFC5378 work, but was
     first submitted = on or after 10 November 2008.  The disclaimer is usually
     necessary only for documents that = revise or obsolete older RFCs, and that
     take significant = amounts of text from those RFCs.  If you can contact all
     authors of the source material and = they are willing to grant the BCP78
     rights to the = IETF Trust, you can and should remove the disclaimer.
     Otherwise, the disclaimer is needed = and you can ignore this comment.
     (See the Legal = Provisions document at
     https://trustee.ietf.org/license-info for more = information.)

I = belive the draft cut and paste in significant text from pre-RFC5378 = based drafts thus I don't think we can fix this. 

= --Apple-Mail=_3847EC66-5492-4C74-A965-F798C6CB0E66-- From nobody Sun Nov 4 11:30:38 2018 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 69728130DC0 for ; Sun, 4 Nov 2018 11:30:37 -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 pvI08QS7Jmtl for ; Sun, 4 Nov 2018 11:30:35 -0800 (PST) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 630A412D7F8 for ; Sun, 4 Nov 2018 11:30:35 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id 124so3873446vsp.12 for ; Sun, 04 Nov 2018 11:30:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=oDC2aHdEu9EY058GNKj2uiSgmsRja/aJylhnRmY/qV8=; b=JiiYLh9x42zKQGhSsLNEaiAAy1K+yhbXq7x/DcWJd2XFTmqNsDSX9/aQP6mAkWjqCd /wLotw6HGqHV2GgHlLQbiEG5cupHGT+ENrThi4xOmY5y5NKItvaqol5hGXrb0dUjfd/e s763Y3Wp3Z23I1h2u1d4RX6ztDjYNl8sEcxLPn4O/Q5QB2RJ81rRSMabdHpNcnlUfv/b YGqkjsS7E9LoWJEbAk15Le1/Lb9Yq5gF5sMs/6haI0c5cHLS+Ci+pb+VA+eX5wwkTjpN giv8LbnNGhXh1Ir025LcIDV8jyFtiFrAIJjyx2gvI0seJHw+iAFD+oWutZAXn7EkoNd+ DvOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oDC2aHdEu9EY058GNKj2uiSgmsRja/aJylhnRmY/qV8=; b=WKrnY224oujFOeOiYZHZKDAoqJRUolS97rnZ776dG/th2ewdUa45diVhPxxMVlaK5N 0dyaJfJYGMjP1ADDnhJKpqC1ZP6vF9DzhYtwUq7zzaYj4HoD4it4ggiE5jnHzG720/e9 05J13PQuCd6d1yrUOxEuJvaRe4yno99W01Bewj2HHRdc389gjaiazQ4bWtZzWylz+b1j Qak7wFZ7XHEWVhzfBxQFrKK7S+syizoZRMfKH4laNlNkFzpuG/onRO6VAHhjxGF5tsir PmlxmozL78EPP6SF/a8YwMIDleV4AZ1Y0YwVxKRnALhOpfUbWDOWypCLKLaDKX6QDw3q r9GA== X-Gm-Message-State: AGRZ1gIJskueo+uPZF+K5lYj7bvOmGFO4qfeg8JmztoaZ1uC0WPZF2om zTsWMo4EUKFBitlrpa6tCCrm9ZqTUkVzLkndY5bFwLPX X-Google-Smtp-Source: AJdET5eGfbMbsgi533HvbWMYn8fYCxbiRXSKQlCji4XwlaLKpq0YSJUPKZjwKubh1/bCFiQQ7n7Ktd1BEQz++ALWepM= X-Received: by 2002:a67:4d4f:: with SMTP id a76mr4720599vsb.167.1541359833986; Sun, 04 Nov 2018 11:30:33 -0800 (PST) MIME-Version: 1.0 From: Bernard Aboba Date: Sun, 4 Nov 2018 14:30:23 -0500 Message-ID: To: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000603ca80579dbcda5" Archived-At: Subject: [rtcweb] JSEP Question: Receipt of an offer requesting sending of simulcast X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 19:30:37 -0000 --000000000000603ca80579dbcda5 Content-Type: text/plain; charset="UTF-8" In a conferencing scenario, typically the conference server will send an Offer to the browser, since it alone knows how many conference participants there are, and therefore how many m-lines to include. In such a scenario it is also common for the conference server to receive simulcast from the browser. Therefore in order to make such a scenario work, it is necessary for the browser to be able to receive an Offer from the conference server indicating the desire for the browser to send simulcast, and for the browser to generate an appropriate Answer to the conference server. A WPT test for this scenario has been suggested (see: https://github.com/web-platform-tests/wpt/pull/13902 ) and in developing the test, it would be helpful to understand how things are supposed to work, exactly. JSEP Section 3.7 currently states: In addition, JSEP does not provide a mechanism to handle an incoming offer requesting simulcast from the JSEP endpoint. This means that setting up simulcast in the case where the JSEP endpoint receives the initial offer requires out-of-band signaling or SDP inspection. However, in the case where the JSEP endpoint sets up simulcast in its in initial offer, any established simulcast streams will continue to work upon receipt of an incoming re-offer. Future versions of this specification may add additional APIs to handle the incoming initial offer scenario. draft-ietf-mmusic-simulcast makes it clear how a conferencing server can request that the browser send simulcast, namely by including a=rid:X recv lines, so there does seem to be a mechanism, but the boundaries of what it supports and does not support is somewhat fuzzy. For example, it is not currently clear (at least to me) exactly how much of the SDP in the Offer is reflected in the encoding parameters that manifest on the Answering side. I would expect the number of encodings and the rids to show up in transceiver.sender.getParameters(). But should anything else be expected? For example, if the SDP in the Offer contains max-fr, will this be reflected in values of the maxFramerate attribute of the encodings on the Answering side? Is there any circumstance in which the Answerer will find other encoding parameters set, such as maxBitrate or resolutionScaleDownBy? --000000000000603ca80579dbcda5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In a conferencing scenario, typicall= y the conference server will send an Offer to the browser, since it alone k= nows how many conference participants there are, and therefore how many m-l= ines to include.=C2=A0 In such a scenario it is also common for the confere= nce server to receive simulcast from the browser.=C2=A0

Therefore in order to make such a scenario work, it is necessary for = the browser to be able to receive an Offer from the conference server indic= ating the desire for the browser to send simulcast, and for the browser to = generate an appropriate Answer to the conference server.

A WPT test for this scenario has been suggested (see: https://github.com/web-p= latform-tests/wpt/pull/13902 ) and in developing the test, it would be = helpful to understand how things are supposed to work, exactly.=C2=A0
=

JSEP Section 3.7 currently states:=C2=A0

= 
  =
 In addition, JSEP does not provide a mechanism to handle an incoming
   offer requesting simulcast from the JSEP endpoint.  This means that
   setting up simulcast in the case where the JSEP endpoint receives the
   initial offer requires out-of-band signaling or SDP inspecti=
on.
   However, in the case where the JSEP endpoint sets up simulcast in its
   in initial offer, any established simulcast streams will continue to
   work upon receipt of an incoming re-offer.  Future versions of this
   specification may add additional APIs to handle the incoming initial
   offer scenario.

draft-ietf-mmusic-simulca= st makes it clear how a conferencing server can request that the browser se= nd simulcast, namely by including a=3Drid:X recv lines, so there does seem = to be a mechanism, but the boundaries of what it supports and does not supp= ort is somewhat fuzzy.=C2=A0

For example, it is no= t currently clear (at least to me) exactly how much of the SDP in the Offer= is reflected in the encoding parameters that manifest on the Answering sid= e.=C2=A0 I would expect the number of encodings and the rids to show up in = transceiver.sender.getParameters().=C2=A0 But should anything else be expec= ted?=C2=A0 For example, if the SDP in the Offer contains max-fr, will this = be reflected in values of the maxFramerate attribute of the encodings on th= e Answering side?=C2=A0 Is there any circumstance in which the Answerer wil= l find other encoding parameters set, such as maxBitrate or resolutionScale= DownBy?=C2=A0

--000000000000603ca80579dbcda5-- From nobody Sun Nov 4 14:03:37 2018 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 ABFA0128CB7 for ; Sun, 4 Nov 2018 14:03:35 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtRbXyJ3Dct5 for ; Sun, 4 Nov 2018 14:03:33 -0800 (PST) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 56CBE12872C for ; Sun, 4 Nov 2018 14:03:33 -0800 (PST) Received: by mail-ua1-x92d.google.com with SMTP id v24so2485111uap.13 for ; Sun, 04 Nov 2018 14:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3IUulZZKjC7ZpQ/cS/1GdDnuMqTpR55FnryIha+wnSI=; b=yxXc9PXXqw5NDYz9EyCWWpyy7V8DXm+RuVPe2jhj0LUfy9ZGJevwTUqW5ozNkysHpM rZNTomooV2NENydmuQaJp4xmdaqkpaY0oRgN1Jxjge9lHTcx8Cz5cvw8gQ45qSlpUYD/ W+zaEpq8gXoYSHOugaG4Su6UL3KWTC9agZo3z9p8owLhuF4FVsTHjsXnEMuFZJRShfDA wx1m5aK2MZjByQ2QdIhMgHzwcm/RZt8NjiFGXJpSpETsL4O/3mVeFqNzgg+MDVdsRFn2 iC3s6bDhveq4zZJvsB3QI8hH3r2AoUIBDi19Yrlt0V9NepE1E9Cd3PYZu7vuftCbKSoX uAjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3IUulZZKjC7ZpQ/cS/1GdDnuMqTpR55FnryIha+wnSI=; b=gi15MmekS+2XAM8svXECGxLvI6z5Z5VKtaIO6mLG9dZtTUMlEJl1j2ly15FkM2pVDf uflSPq3Bq8gYYqMp1Gknj4zPsCOSxiMULN7X0QrschPgeA+xzBdwOx6EFICewtlYJy+j qFbT0licYWG4NKVrcSboIPAJHcrbjeIBnPtFOjqGU/HmU2W+qbV7CHNSYXv6rqvPEYuz 6deLuhMz9HG2AmOqmASchtd+DUwXO00wD1f39qaYT9AJ4c8H8372BEk7Ajj08e9YesMd 07QFCX7uYf89hc9KEcr2EvT4tLbaq5OZNQGcUYrxryM/uLVwyTp0wmXhpS9pvd9lTN7A 6SkA== X-Gm-Message-State: AGRZ1gL7JPapr3bQVqRI4O0a0rh7F8yHWnpUhKYlzZi8qO/TEeSneS0+ v7HRRJplDOSMqFqXg5BzB/rkw3+b2DMwEyi/qUosZQSS X-Google-Smtp-Source: AJdET5fLnnjY8vziK7v3SA7F0R2pVK/sIp3DxG6BYk0oQKk2Q3EmTYNJTKfR0EbtkjASdoZWyyTmiahcd4MMehUV168= X-Received: by 2002:ab0:526:: with SMTP id 35mr8514609uax.84.1541369012335; Sun, 04 Nov 2018 14:03:32 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 4 Nov 2018 23:03:20 +0100 Message-ID: To: Harald Alvestrand Cc: rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 22:03:36 -0000 On Sun, 4 Nov 2018 at 09:13, Harald Alvestrand wrote= : > In WEBRTC, we have been grappling with the problem of simulcast setup, > and it seems that we have no obvious API surface that can be used for > this purpose - creating transceivers (as we do for outgoing) doesn't fit > the bill, because incoming SDP causes transceivers to be created wihout > interacting with the API surface. That's the exact problem: the fact that media parameters are given to the other party by sharing a blob that the receiver must consume before it even knows what it contains and, once consumed, it must rely on "events" fired out of context (cannot correlate the received SDP blob and peerconnection/stream events generated after consuming it). And worse, once such a SDP blob is received and blindly consumed, "things" happen without app knowledge or consent. For example and as said by Nils, Firefox can conform to simulcast settings on receipt of a remote SDP offer, but if we think about it, it means that the remote decides in behalf of us (we cannot decide how to send simulcast but, instead, the remote can force us to send simulcast as it wishes (and not how we wish) by just sending us a blob reoffer. The problem is the SDP as "API surface" as it's been always. IMHO we shouldn't waste more energies adding more hacks to the current API to fight the SDP O/A nature and, instead, we should move to a SDP-less specification ASAP in which the remote party cannot blindly mandate the local peer what to send at any time. --=20 I=C3=B1aki Baz Castillo From nobody Sun Nov 4 14:37:16 2018 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 8074E1276D0 for ; Sun, 4 Nov 2018 14:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 dSNfPDm24Svo for ; Sun, 4 Nov 2018 14:37:12 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 02EDD126DBF for ; Sun, 4 Nov 2018 14:37:12 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id r10-v6so7439119wrv.6 for ; Sun, 04 Nov 2018 14:37:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Igv0AYDyYT+juV2ui4OSoY0UaU3JkDvaAXcb4QslWU=; b=VU3G5RmkD9MHjNiliFHE5K7DxjqSVjTvG/CmwpQ9556ND3nO7SVJ+tUWX+/cAMJ2XQ eec7b6OqQCgA3ivhi2HpURGjXc7iU9MstbESioWNPdnDi5gbyHGo1C2UgQA/NncxOyLp NOsYdfnlhjw/U6iTfI9cdHk4Cgez8mVS77x7MLuCUTYG9sNOIWLWHCTaG7250MpIRx8Z qK8JdZuRgTNfLIMKe78RwAl62coJvQ4yNkAjWo5O8gJdpewam0ZT2vv8dGA+jGDFLhsc AghbSr5XWbeyuuBbGlk3o/0VotoTwNWBOwARc8SXgNscmAhdG1lJVPnFztrsMoy7X/sc XXog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Igv0AYDyYT+juV2ui4OSoY0UaU3JkDvaAXcb4QslWU=; b=PMKqN6TApxDqpQRF/Wy1hxOxpYbgxRaVSk2a6ZtH/0ZVEtQ5mYHSOPdKIFcYi3jQp3 ti3wbtd1UD9zecYmmbn8ENm/uzNEviVoBOsiqics7FaZ4ciM/SVjJL+OXra8H2neCmNk +CSy81mOwre56A2Cq1/QjFYroU79Vx7UVinO4NZrdeVC23AP0sN0QCJTZwmG4GaHoFPA krkw6WIdcdbBHD0ClDsZy3VQcCYU3MvrgmrOA+rnWDPrJf+SOhIlyAEUk4vKfGWAWgsD ADjfCQ9dOqUq4QgdDRG1tdPMXH4d8S4XaDFB7YkulT5Zz1llsbNSE9YFDQZM9lO+S4a6 tpKA== X-Gm-Message-State: AGRZ1gLdedA4s3tGFgzkwTrO8fLr4aJNBdMd34HghVTbap3H8Th8p+xP q3n9Vg7QQEPHluqTidgeR3ZKW2qwoIX/d71Eyc0= X-Google-Smtp-Source: AJdET5cSgBlaA8JBNwB03AReTKXgdgRPyVU/N4mZARz9HwDMg68mv751jitt+hLM4W/72u6IJ+UvKWB4Xp2lF1IiqBU= X-Received: by 2002:a5d:664e:: with SMTP id f14-v6mr17844410wrw.218.1541371030267; Sun, 04 Nov 2018 14:37:10 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: Sergio Garcia Murillo Date: Sun, 4 Nov 2018 23:36:58 +0100 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Harald Alvestrand , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000b9ed5d0579de6860" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 22:37:14 -0000 --000000000000b9ed5d0579de6860 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with I=C3=B1aki that the remote side should not be able to start simulcast locally without app involvement. IMHO best would be to keep things as they are, do not allow to receive a simulcast offer. Instead, send a remote offer without simulcast from sfu, add transceiver with simulcast encodings, create answer without simulcast m line, and trigger renegotiate needed event so the app creates a new sdp offer sdp with the simulcast m line this time. Convoluted but better than opening a new rabbit hole. Best regards Sergio El dom., 4 nov. 2018 23:03, I=C3=B1aki Baz Castillo escribi= =C3=B3: > On Sun, 4 Nov 2018 at 09:13, Harald Alvestrand > wrote: > > In WEBRTC, we have been grappling with the problem of simulcast setup, > > and it seems that we have no obvious API surface that can be used for > > this purpose - creating transceivers (as we do for outgoing) doesn't fi= t > > the bill, because incoming SDP causes transceivers to be created wihout > > interacting with the API surface. > > That's the exact problem: the fact that media parameters are given to > the other party by sharing a blob that the receiver must consume > before it even knows what it contains and, once consumed, it must rely > on "events" fired out of context (cannot correlate the received SDP > blob and peerconnection/stream events generated after consuming it). > > And worse, once such a SDP blob is received and blindly consumed, > "things" happen without app knowledge or consent. For example and as > said by Nils, Firefox can conform to simulcast settings on receipt of > a remote SDP offer, but if we think about it, it means that the remote > decides in behalf of us (we cannot decide how to send simulcast but, > instead, the remote can force us to send simulcast as it wishes (and > not how we wish) by just sending us a blob reoffer. > > The problem is the SDP as "API surface" as it's been always. IMHO we > shouldn't waste more energies adding more hacks to the current API to > fight the SDP O/A nature and, instead, we should move to a SDP-less > specification ASAP in which the remote party cannot blindly mandate > the local peer what to send at any time. > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000b9ed5d0579de6860 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with I=C3=B1aki that the remote side should not b= e able to start simulcast locally without app involvement.=C2=A0

IMHO best would be to keep things as the= y are, do not allow to receive a simulcast offer. Instead, send a remote of= fer without simulcast from sfu, add transceiver with simulcast encodings,= =C2=A0 create answer without simulcast m line, and trigger renegotiate need= ed event so the app creates a new sdp offer sdp with the simulcast m line t= his time.

Convoluted but= better than opening a new rabbit hole.

Best regards
Sergio



El dom., 4 nov. 2018 23:03, I=C3=B1aki Baz Castillo= <ibc@aliax.net> escribi=C3=B3:<= br>
On Sun, 4 Nov 2018 at 09:13, Harald= Alvestrand <harald@alvestrand.no> wrote:
> In WEBRTC, we have been grappling with the problem of simulcast setup,=
> and it seems that we have no obvious API surface that can be used for<= br> > this purpose - creating transceivers (as we do for outgoing) doesn'= ;t fit
> the bill, because incoming SDP causes transceivers to be created wihou= t
> interacting with the API surface.

That's the exact problem: the fact that media parameters are given to the other party by sharing a blob that the receiver must consume
before it even knows what it contains and, once consumed, it must rely
on "events" fired out of context (cannot correlate the received S= DP
blob and peerconnection/stream events generated after consuming it).

And worse, once such a SDP blob is received and blindly consumed,
"things" happen without app knowledge or consent. For example and= as
said by Nils, Firefox can conform to simulcast settings on receipt of
a remote SDP offer, but if we think about it, it means that the remote
decides in behalf of us (we cannot decide how to send simulcast but,
instead, the remote can force us to send simulcast as it wishes (and
not how we wish) by just sending us a blob reoffer.

The problem is the SDP as "API surface" as it's been always. = IMHO we
shouldn't waste more energies adding more hacks to the current API to fight the SDP O/A nature and, instead, we should move to a SDP-less
specification ASAP in which the remote party cannot blindly mandate
the local peer what to send at any time.

--
I=C3=B1aki Baz Castillo
<i= bc@aliax.net>

_______________________________________________
rtcweb mailing list
rtc= web@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb<= /a>
--000000000000b9ed5d0579de6860-- From nobody Sun Nov 4 14:42:48 2018 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 50D901276D0 for ; Sun, 4 Nov 2018 14:42:46 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0fTq_1-GoYb for ; Sun, 4 Nov 2018 14:42:44 -0800 (PST) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 D027F12872C for ; Sun, 4 Nov 2018 14:42:43 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id y27so2213667vsi.1 for ; Sun, 04 Nov 2018 14:42:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WCYuy8hCxJiwWdZxKnBk5OZ//pFBsk8CUsOF6Umg49A=; b=q+2Wxn04aFO1wAYAVbRywQGKgyup91ohxG1SgwdW+g8E1XkjG58A5Qnm7zErrbcOcE /1JwQbAog20BtMNWIYuWMtxdEOJE5OIInLjuFrKSUiV6MftTPc3hhykWDXqMV1kMBmwt RFKJg8A1vaLKnnjK73HC9BuZ2IevvF18r5+0ReFP8t75rhLB6CTdBmXlnuKiC2wpeXGC BgfSltfV1FSocrZbqJnD4iLOPMt2lGuYCRBCUXvVe5GdBJ9+8++i1rqRz6Yu74ljKe1b 6YRK0Hu5NIS2uyz6WHldqKgyy0e5DmjP8yR53zPsBRix6CTfJbIqeHYSWf5613vn6w1v WkKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WCYuy8hCxJiwWdZxKnBk5OZ//pFBsk8CUsOF6Umg49A=; b=Gbe5gXQn/6JtJiKwp0+gyVun7dgiUb9Y33eiswvdRfY8rP/+OojAhuKvbZ69TYiKUj KfZc0IWrfbhxKrd9ijJ9f+vvC/fgV4ykwLi93fG6jIpMrL5FfhHlfgb8mpCG5fEjb9/6 shfDeuhp55bg4wpoTckZizr9zyYVbCtE9Z76KKSJppjiiBXEBAmgpAXZ8luExhvMtfjZ ZYVyw/79O1XN6ksVQvo+/0wIcQ0svvPQD+eMYPjVHUkVI9Y7sAua4z47mbx1yIqNaOqm LkUtP/btVRtDgp7cspzqzmiPWxcg/ODbffjAHDL1J4H65pHRHIBZu2qqMpV1woCbm8ly u/HQ== X-Gm-Message-State: AGRZ1gJCX1AZ7A1SAJtq2G3gE9eJtArW5axtsgw/tDqVp4Gw6FPtHbqp K3Ia+tU2mEDthvHkLSSjLcPu8PFJV7usZOYbhWKpSg== X-Google-Smtp-Source: AJdET5fjsgUAtaG9gHvt6qBROHyfA3YVrl+2mVd8cW/5y4yxl1mC69BmHh+NjePJsx1pcffsDLkL0lBcHDJbKX/NsJY= X-Received: by 2002:a67:6281:: with SMTP id w123-v6mr8566927vsb.68.1541371362849; Sun, 04 Nov 2018 14:42:42 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 4 Nov 2018 23:42:31 +0100 Message-ID: To: sergio.garcia.murillo@gmail.com Cc: Harald Alvestrand , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 22:42:46 -0000 On Sun, 4 Nov 2018 at 23:37, Sergio Garcia Murillo wrote: > > I agree with I=C3=B1aki that the remote side should not be able to start = simulcast locally without app involvement. > > IMHO best would be to keep things as they are, do not allow to receive a = simulcast offer. Instead, send a remote offer without simulcast from sfu, a= dd transceiver with simulcast encodings, create answer without simulcast m= line, and trigger renegotiate needed event so the app creates a new sdp of= fer sdp with the simulcast m line this time. Unrelated, but funny fact: * Use unified-plan in Chrome. * Enable simulcast in a m=3Dvideo section via offer munging (append additional a=3Dssrc lines, etc). * Later remove the video track via pc.removeTrack(transceiver.sender). * Multiple a=3Dssrc lines are still there. * If later the same transceiver is re-enabled for sending a (new) video track (transceiver.sender.replaceTrack(newTrack)) simulcast is automatically enabled. Not sure if expected, and not sure what should happen when using the standard simulcast API sender.setParameters(), but IMHO it's funny. Oh, and call transceiver.sender.replaceTrack(audioTrack) and auto-magically the m=3Dsection will change from m=3Dvideo to m=3Daudio XDD --=20 I=C3=B1aki Baz Castillo From nobody Sun Nov 4 14:47:35 2018 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 B0D0812DDA3 for ; Sun, 4 Nov 2018 14:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 NVhS74eTKZDX for ; Sun, 4 Nov 2018 14:47:31 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 99F4212872C for ; Sun, 4 Nov 2018 14:47:31 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id v205so4051601vsc.3 for ; Sun, 04 Nov 2018 14:47:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KTxRaQU+x2RzPt55D2eefNo+MSptbp1RdxvLG2pSZpg=; b=JYhiYS631ZIt8hprtUmv5lo6hjtEam0rD+11po6W+gV8D5PS8SnxzCYDyqpjVvw1D4 3eJVVvZagAi8Jcm8p1AFPXeTIFD8GCeG6lk7j85wmmGFOY2aK693NnEKZ8N1rIa1pn0x 7w5/EJeDoerwsIBX3DzpZpLAbC62pT/iCFrVbgRw6NmwhOGejjcaNk5mtNmOOic+n8lU j6ph8Ch+DtDLMlA616BsOFSluwhrs9+y65TZlOhOh/yHUzJaIY/yj1D1q3M0wsfLmibr OI8asM6JR1ymRsMC2sqoo/AkP47a2VSzXPq4YDlDpF00Ri1vYXIdaoLKj6yreDhzLfzT YWsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KTxRaQU+x2RzPt55D2eefNo+MSptbp1RdxvLG2pSZpg=; b=KQF5EjHy39LhvQi5wc5GhAVyrTOysNj2lDnE6tQ+y0YExKD3igkVD8868VU2ZusVXm 6o3zVZfv4tJ4fnZ+ZrF0eTk8vmoXaShc0EEGZnHIGMMjpD3oSNOj/Fv5QDHKs6wst6BU v/Ah3ERRPHdMsnkgkwTBEYysu5aP9D6MYIPsihAq/BypIN26jBbkm3mUYepLfCRAg7m/ lWFwi9I1KWnzV7aP233qI6bHH5RHFSDcI/IRn1fnQmxnhjFbxZaZ/coloTnkZ58h6cm1 1wkWx/B/5Qoi49gHSBiBZSMUjxbQxJ5BtqRhDf6vZwqPb7VSCVt3O9YW5s4FH4Ckiti1 A7FQ== X-Gm-Message-State: AGRZ1gL1qqLVhko7AwWhUDGmr3J1GlLDgnWVU5XL3rZe+/qBwTZlnUuL FUPJUnr5rrmZDmW7EcZS5yuDfdK6EBUblCm495w= X-Google-Smtp-Source: AJdET5c/fZhxWbQq7KLKh79eqKShhztA5+aVX3JDHKZLczrIx33Is1W6h0Ta68flAeriQbaDXmoIyp00Rq0fUMF1ns4= X-Received: by 2002:a67:ebc3:: with SMTP id y3mr7660696vso.75.1541371650399; Sun, 04 Nov 2018 14:47:30 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: Bernard Aboba Date: Sun, 4 Nov 2018 17:47:19 -0500 Message-ID: To: Nils Ohlmeier Cc: Harald Alvestrand , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000b065c40579de8d30" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 22:47:34 -0000 --000000000000b065c40579de8d30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nils said: " would have to look into the details, but I think for it to work you have to setup the RTP senders before setting the Offer (which is arguably not a nice API design). Which usually is not a big problem as the server which wants to receive simulcast knows how many RID=E2=80=99s it wants to get." [BA] Typically the Offerer is a conference server, not a browser. And it is sending an Offer to receive simulcast, not to send it. The browser does have to setup its RtpSender to send simulcast based on the Offer from the conference server, once applied. Some aspects of this seem clear - the number of encodings should correspond to the number in the Offer, and the RIDs should match. But some other aspects are not as clear - in the test, the Offer contained max-fr in the a=3Drid:X recv lines. In the FF implementation do these result in setting of maxFramerate attributes in the RtpSender? " On Sun, Nov 4, 2018 at 3:34 AM Nils Ohlmeier wrote: > > > On 4Nov, 2018, at 15:13, Harald Alvestrand wrote: > > In JSEP, we have the following text: > > > In addition, JSEP does not provide a mechanism to handle an incoming > offer requesting simulcast from the JSEP endpoint. This means that > setting up simulcast in the case where the JSEP endpoint receives the > initial offer requires out-of-band signaling or SDP inspection. > > In WEBRTC, we have been grappling with the problem of simulcast setup, > and it seems that we have no obvious API surface that can be used for > this purpose - creating transceivers (as we do for outgoing) doesn't fit > the bill, because incoming SDP causes transceivers to be created wihout > interacting with the API surface. > > I tried to drum up a test that would create such a setup based on SDP, > but found that in conformance with JSEP, this doesn't work. > > Can someone tell me why we decided to not allow an incoming offer with > a=3Dsimulcast and a=3Drid ... recv in it to generate outgoing simulcast > capability? > > The test in question: > > https://github.com/web-platform-tests/wpt/pull/13902 > > > I can=E2=80=99t answer your question of why not. > But it is working in Firefox as this test shows > > https://searchfox.org/mozilla-central/source/dom/media/tests/mochitest/te= st_peerConnection_simulcastAnswer.html#59 > > I would have to look into the details, but I think for it to work you hav= e > to setup the RTP senders before setting the Offer (which is arguably not = a > nice API design). Which usually is not a big problem as the server which > wants to receive simulcast knows how many RID=E2=80=99s it wants to get. > > Best > Nils Ohlmeier > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000b065c40579de8d30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nils said:=C2=A0

" would have to l= ook into the details, but I think for it to work you have to setup the RTP = senders before setting the Offer (which is arguably not a nice API design).= Which usually is not a big problem as the server which wants to receive si= mulcast knows how many RID=E2=80=99s it wants to get."

<= /div>
[BA] Typically the Offerer is a conference server, not a browser.= And it is sending an Offer to receive simulcast, not to send it.=C2=A0 The= browser does have to setup its RtpSender to send simulcast based on the Of= fer from the conference server, once applied. Some aspects of this seem cle= ar - the number of encodings should correspond to the number in the Offer, = and the RIDs should match.=C2=A0 But some other aspects are not as clear - = in the test, the Offer contained max-fr in the a=3Drid:X recv lines.=C2=A0 = In the FF implementation do these result in setting of maxFramerate attribu= tes in the RtpSender?

"


On 4Nov, 2018, at 15:13= , Harald Alvestrand <harald@alvestrand.no> wrote:

In JSEP,= we have the following text:


=C2=A0=C2=A0 In addition, JSEP does= not provide a mechanism to handle an incoming
=C2=A0=C2=A0 offer reques= ting simulcast from the JSEP endpoint.=C2=A0 This means that
=C2=A0=C2= =A0 setting up simulcast in the case where the JSEP endpoint receives the=C2=A0=C2=A0 initial offer requires out-of-band signaling or SDP inspecti= on.

In WEBRTC, we have been grappling with the problem of simulcast = setup,
and it seems that we have no obvious API surface that can be used= for
this purpose - creating transceivers (as we do for outgoing) doesn&= #39;t fit
the bill, because incoming SDP causes transceivers to be creat= ed wihout
interacting with the API surface.

I tried to drum up a = test that would create such a setup based on SDP,
but found that in conf= ormance with JSEP, this doesn't work.

Can someone tell me why we= decided to not allow an incoming offer with
a=3Dsimulcast and a=3Drid .= .. recv in it to generate outgoing simulcast
capability?

The test= in question:

https://github.com/web-platform-tests/wpt/pull= /13902

I can=E2=80=99t answe= r your question of why not.
But it is working in Firefox as this = test shows=C2=A0

I would have to look into the details, but I think for it t= o work you have to setup the RTP senders before setting the Offer (which is= arguably not a nice API design). Which usually is not a big problem as the= server which wants to receive simulcast knows how many RID=E2=80=99s it wa= nts to get.

Best
=C2=A0 Nils Ohlmeier
<= /div>_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000b065c40579de8d30-- From nobody Sun Nov 4 14:50:46 2018 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 36ADE128D09 for ; Sun, 4 Nov 2018 14:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 m2cC0Ra2JWI1 for ; Sun, 4 Nov 2018 14:50:42 -0800 (PST) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 A4072128C65 for ; Sun, 4 Nov 2018 14:50:42 -0800 (PST) Received: by mail-vk1-xa2a.google.com with SMTP id o10-v6so1590824vki.6 for ; Sun, 04 Nov 2018 14:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hcBimRyMtJv7YbcVzuNA5c0Ua1KnUp73cLwXh0zYRZc=; b=KPVnLfHu5spM2T3ZXgTfP7++NqHbcNfEQbEt1/niBeQ8u+jVGvc8PxrnWF2Xa2U/C3 U/XgsTB4tH9u/y7W9Rwx2hMr/dy2Qc8lZ59imehXLrcIlDOvc2ABjMNWRiOdUL/GAOaQ 35QdF1/+/IrocTpxjZh+P41jwG2EMYw1lSj7mfIaAqSsinO9YhwAhjxf09hBlzT1cmcs oxiCfLV9wTS+8XQ2BkZ0yHfqTdKVXW3sPK7Nl0hLj+1pc61/vTGcZE3ASwRZX9OF464l 4hUAUqHpDmtQfJeTcQYScoT5UYqxuzJf+M5jjWFNXebwi0q+sJ4kbQsQ9XXKhBmW2wHD Q2DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hcBimRyMtJv7YbcVzuNA5c0Ua1KnUp73cLwXh0zYRZc=; b=aSU5SPxHHADx/MzoGlcBPrdl43AjdY9owyF4lxHfFw0b4mA4MwYKCqtQJkUGY0manJ DZsuj7dDhsl0BCoHCWIulFINcBco+2XB59MQD61r45l9OozdD8lfy3k63X8GP5vgaj3T rFRG88N7brcfC0fOOSGPgrcgjErVjovU2HPPjX1tlq6J7DAh5ntUYy2Z3TKcqJMGbrwZ CiAzQFJ69unxZ7VaihBkztecGZybR0Px83Ea4dwQBxjfzBzCfFjWzLez5JIeBrSBdNbN 7yfq6SzAZ9Xc2uN92fAnbYrc/roukShd2we3u84NodW9Boga/luSm5NyyEQUUsc8Jpu8 MNCA== X-Gm-Message-State: AGRZ1gIzXHbeg8K0XLaabt5v2UavhiPH6Iq7NwRxWRuaxx5vRtWKSx6W m/cIEHVAGX19I2kpsFpiZNPBQ9KFoNcemmEKcdk= X-Google-Smtp-Source: AJdET5cT/X0dFb2GUESyjazvx7r6n/kK2tr55pwwtPYHHiCmJT7VLKLYnBukbGhMUbmmrDcZ2po3f+0xjf/fIyowqqY= X-Received: by 2002:a1f:2ed7:: with SMTP id u206mr8391952vku.72.1541371841402; Sun, 04 Nov 2018 14:50:41 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: Bernard Aboba Date: Sun, 4 Nov 2018 17:50:30 -0500 Message-ID: To: Sergio Garcia Murillo Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000012dd020579de990c" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 22:50:45 -0000 --00000000000012dd020579de990c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sergio said: "I agree with I=C3=B1aki that the remote side should not be able to start simulcast locally without app involvement. IMHO best would be to keep things as they are, do not allow to receive a simulcast offer. Instead, send a remote offer without simulcast from sfu, add transceiver with simulcast encodings, create answer without simulcast m line, and trigger renegotiate needed event so the app creates a new sdp offer sdp with the simulcast m line this time." [BA] That won't work because the conferencing server is the only one that knows how many participants are in the conference, so it needs to send the Offer. On Sun, Nov 4, 2018 at 5:37 PM Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > I agree with I=C3=B1aki that the remote side should not be able to start > simulcast locally without app involvement. > > IMHO best would be to keep things as they are, do not allow to receive a > simulcast offer. Instead, send a remote offer without simulcast from sfu, > add transceiver with simulcast encodings, create answer without simulcas= t > m line, and trigger renegotiate needed event so the app creates a new sdp > offer sdp with the simulcast m line this time. > > Convoluted but better than opening a new rabbit hole. > > Best regards > Sergio > > > > El dom., 4 nov. 2018 23:03, I=C3=B1aki Baz Castillo escri= bi=C3=B3: > >> On Sun, 4 Nov 2018 at 09:13, Harald Alvestrand >> wrote: >> > In WEBRTC, we have been grappling with the problem of simulcast setup, >> > and it seems that we have no obvious API surface that can be used for >> > this purpose - creating transceivers (as we do for outgoing) doesn't f= it >> > the bill, because incoming SDP causes transceivers to be created wihou= t >> > interacting with the API surface. >> >> That's the exact problem: the fact that media parameters are given to >> the other party by sharing a blob that the receiver must consume >> before it even knows what it contains and, once consumed, it must rely >> on "events" fired out of context (cannot correlate the received SDP >> blob and peerconnection/stream events generated after consuming it). >> >> And worse, once such a SDP blob is received and blindly consumed, >> "things" happen without app knowledge or consent. For example and as >> said by Nils, Firefox can conform to simulcast settings on receipt of >> a remote SDP offer, but if we think about it, it means that the remote >> decides in behalf of us (we cannot decide how to send simulcast but, >> instead, the remote can force us to send simulcast as it wishes (and >> not how we wish) by just sending us a blob reoffer. >> >> The problem is the SDP as "API surface" as it's been always. IMHO we >> shouldn't waste more energies adding more hacks to the current API to >> fight the SDP O/A nature and, instead, we should move to a SDP-less >> specification ASAP in which the remote party cannot blindly mandate >> the local peer what to send at any time. >> >> -- >> I=C3=B1aki Baz Castillo >> >> >> _______________________________________________ >> 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 > --00000000000012dd020579de990c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sergio said:=C2=A0

"I agree with I= =C3=B1aki that the remote side should not be able to start simulcast locall= y without app involvement.=C2=A0
IMHO best would be to keep thing= s as they are, do not allow to receive a simulcast offer. Instead, send a r= emote offer without simulcast from sfu, add transceiver with simulcast enco= dings,=C2=A0 create answer without simulcast m line, and trigger renegotiat= e needed event so the app creates a new sdp offer sdp with the simulcast m = line this time."

[BA] That won't work bec= ause the conferencing server is the only one that knows how many participan= ts are in the conference, so it needs to send the Offer.=C2=A0
<= br>
On Sun, Nov 4, 2018 at 5:37 = PM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
I agree with I=C3=B1aki that the remote = side should not be able to start simulcast locally without app involvement.= =C2=A0

IMHO best would be to k= eep things as they are, do not allow to receive a simulcast offer. Instead,= send a remote offer without simulcast from sfu, add transceiver with simul= cast encodings,=C2=A0 create answer without simulcast m line, and trigger r= enegotiate needed event so the app creates a new sdp offer sdp with the sim= ulcast m line this time.

Convoluted but better than opening a new rabbit hole.

Best regards
Sergio



El dom., 4 nov. 2018 23:03, I=C3=B1a= ki Baz Castillo <ibc@= aliax.net> escribi=C3=B3:
On= Sun, 4 Nov 2018 at 09:13, Harald Alvestrand <harald@alvestrand.no= > wrote:
> In WEBRTC, we have been grappling with the problem of simulcast setup,=
> and it seems that we have no obvious API surface that can be used for<= br> > this purpose - creating transceivers (as we do for outgoing) doesn'= ;t fit
> the bill, because incoming SDP causes transceivers to be created wihou= t
> interacting with the API surface.

That's the exact problem: the fact that media parameters are given to the other party by sharing a blob that the receiver must consume
before it even knows what it contains and, once consumed, it must rely
on "events" fired out of context (cannot correlate the received S= DP
blob and peerconnection/stream events generated after consuming it).

And worse, once such a SDP blob is received and blindly consumed,
"things" happen without app knowledge or consent. For example and= as
said by Nils, Firefox can conform to simulcast settings on receipt of
a remote SDP offer, but if we think about it, it means that the remote
decides in behalf of us (we cannot decide how to send simulcast but,
instead, the remote can force us to send simulcast as it wishes (and
not how we wish) by just sending us a blob reoffer.

The problem is the SDP as "API surface" as it's been always. = IMHO we
shouldn't waste more energies adding more hacks to the current API to fight the SDP O/A nature and, instead, we should move to a SDP-less
specification ASAP in which the remote party cannot blindly mandate
the local peer what to send at any time.

--
I=C3=B1aki Baz Castillo
<i= bc@aliax.net>

_______________________________________________
rtcweb mailing list
rtc= web@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb<= /a>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--00000000000012dd020579de990c-- From nobody Sun Nov 4 14:52:53 2018 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 814F6128CF3 for ; Sun, 4 Nov 2018 14:52:52 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KN5syHmBN8HE for ; Sun, 4 Nov 2018 14:52:50 -0800 (PST) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 9B584128C65 for ; Sun, 4 Nov 2018 14:52:50 -0800 (PST) Received: by mail-ua1-x930.google.com with SMTP id v24so2508245uap.13 for ; Sun, 04 Nov 2018 14:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LcGLQyHIgfkcutOFtHjvjkKnwOMGjIbyB4GKWwL8LcI=; b=feLDSB+H+ijogdX4kbhmeklB7w5FihsB8C68rrj5MEPlpHr6F9EEnO3QXt6MJ5JlVO h7auqJx7vHsVJJF1XW+LtZ6eMhwI9mmQx56WxZSbMcbwTilqrgMo3FY7tBRboL4DFwln OfPkjn8EFaBmTPz6wLo6lnsMqshgAh+iJs7qNCDzcEGFjMm5ibZ5kbJxHOGenRV2egNS 8LQczbtdv4H0fhKy03phbIv5b75PoYJYx4YjBv6rz+8dHkU9UCw57qaqO3tAqb7YCrl3 /P2aIZatT1dfm2ny9NSKsnDuqpCIJe4vSeU0mn7l9YoQERGemkfc8h8QSh8VwfAFqAeR 1VJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LcGLQyHIgfkcutOFtHjvjkKnwOMGjIbyB4GKWwL8LcI=; b=NO/bk2o33w1kRaGvucM664zoTBNsZbP3etG6AlGAkDGgct+06WwyHn5Tet8FkUbcrJ M0T0qAr9OWXymGrEzxGDUey2znKbukMqImeKSt/HriZQw41OoO7avGet5Kt7NtsX5PMB 2kk+u/0pkVajKo9KfZywN59z2IsoxygHUFuE1pC0zoP1cesYNdNfAePJ2x3+JERgD9oU qZW4X6zCtDfxIaP51QiWxBOrrjeChPIQ0+VeOe8xXS5R5YxkBLK8KGDn9mG5Web83FHD MZsiagtbY7TFj014TXhQC2M6LRg8KHD0FqzhtSMwaqRcGtwpat1t6MTE0FUGcYAChZUB zLwA== X-Gm-Message-State: AGRZ1gKLIceHkZxB8I9bSvXjg/F5R3cBCMy+CUy6B+AxDQikTWmIiXOM YNUS7K7t0K07D6EGRjLUhPBIY8v0YghyM1ekZYx7w4prGBo= X-Google-Smtp-Source: AJdET5emZwKGT/0WsAhvLlLpYO+PncJU89o+REL1EMW4rAz30xkwUWgBJWoNW/qHQ0twSMIMrUC1aF8WVEmIQoQLltQ= X-Received: by 2002:ab0:2519:: with SMTP id j25mr6696052uan.68.1541371969529; Sun, 04 Nov 2018 14:52:49 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 4 Nov 2018 23:52:38 +0100 Message-ID: To: Bernard Aboba Cc: nohlmeier@mozilla.com, rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 22:52:53 -0000 On Sun, 4 Nov 2018 at 23:47, Bernard Aboba wrote: > [BA] Typically the Offerer is a conference server, not a browser. And it = is sending an Offer to receive simulcast, not to send it. The browser does= have to setup its RtpSender to send simulcast based on the Offer from the = conference server, once applied. Some aspects of this seem clear - the numb= er of encodings should correspond to the number in the Offer, and the RIDs = should match. But some other aspects are not as clear - in the test, the O= ffer contained max-fr in the a=3Drid:X recv lines. In the FF implementatio= n do these result in setting of maxFramerate attributes in the RtpSender? Hi Bernard, before entering into implementation details, do you really agree that the remote should be able to force the local peer what and how to send media? Also, you are assuming the scenario in which the conference server offers a peer to receive simulcast from him. Where does such an assumption come from? We don't need that assumption in WebRTC land. If the conference *application* wants to ask peers to send simulcast can be achieved by tons of ways (via custom messages or whatever), we should not reduce everything to the "SIP world" in which everything is expressed by sending a SDP. --=20 I=C3=B1aki Baz Castillo From nobody Sun Nov 4 14:56:01 2018 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 7481E128D68 for ; Sun, 4 Nov 2018 14:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 0Ccc-VVuw27F for ; Sun, 4 Nov 2018 14:55:58 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 9817C128CF3 for ; Sun, 4 Nov 2018 14:55:57 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id k15-v6so4482852wre.12 for ; Sun, 04 Nov 2018 14:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5u14sHYAU44wQPnbsH5flvz2t/3jQD01vLomf4EgON8=; b=DQL7Rq0hESULnIcq350sQpcJkAnuXxpmkWEMBgLgJSX5lNJn5VtIN18Hn1eofgo3Yz JiSVz2f6ahmqpie/ahoHgEjEZlGkCrPAjcfMqKsgmisZocxI5Y8lj2UuRuxkh2Wq/VX0 5GNHBNr8PiEq4azsC5Gs11BMjHKV3yn1j/ISTmKZvUCaVQt3KI74g2e2FBJ/zC+DMWO8 XpPj/NCaAOysSZDjae/4llz5/ioHTal2KqVakaWdG4afU1UCsigdPVbXYCrHU9acuI/o j1TcJYvOHwmkl2NqVlyEhg2subVBSoZFHmZgfqU6F415M7Ze8uTj2U7eHe0wDvg+eMA3 SL1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5u14sHYAU44wQPnbsH5flvz2t/3jQD01vLomf4EgON8=; b=lpMzHFJ9WXZe4T6x6F82b3N3cDCCgp8wyKOu8076zgAnmqeD7siWLoNrshRU13DpuS 7QiEkd1KXOu83hm0FfS5N5u4A6iqXK2lFAP/bHEiUCngnTQDMQmCaKydkixqRgWIzJhV Lq6ysGH3zmPubN/f9kS2OX+BEX0T5eAKeKakun6ZuBBpE/N8PAdHGTIgmOTX+uSs21E0 Hf3ZjPhcigG7o5CY+V2Tw5MFYVpwCC7oU6GmQTCp6e91+Gr304S++VXrORZ0R9yvwCmv MQohqdEAC9WLJ2j0sMJOPqDYRhxqPQdG6P8l3AIKIb4229DKy4WR6sa3U7MzUsymN2as o0Qg== X-Gm-Message-State: AGRZ1gIBB+x2ar1PuowBsnSD0c9S00gkgbcArltvQpWGaXat5RcJ6bd5 2Q1y51FJdqJ0zeHOzzZvgfy1uCIn8YCuyqSG5uk= X-Google-Smtp-Source: AJdET5eRc1j3F7QMYujX7I/6LjOVwvq7MA5he7OOgZnIbOFUcVMBB6y6ftTyJcw+j8VQ47ozrpNsFjyNb69nwBLgWeY= X-Received: by 2002:a5d:664e:: with SMTP id f14-v6mr17879103wrw.218.1541372155934; Sun, 04 Nov 2018 14:55:55 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: Sergio Garcia Murillo Date: Sun, 4 Nov 2018 23:55:43 +0100 Message-ID: To: Bernard Aboba Cc: Nils Ohlmeier , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000d23f7c0579deab11" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 22:56:00 -0000 --000000000000d23f7c0579deab11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable How does the app set up the rtp sender? How does the app knows that the offer has simulcast enabled and the rids without sdp inspection? Best regards Sergio El dom., 4 nov. 2018 23:47, Bernard Aboba escribi=C3=B3: > Nils said: > > " would have to look into the details, but I think for it to work you hav= e > to setup the RTP senders before setting the Offer (which is arguably not = a > nice API design). Which usually is not a big problem as the server which > wants to receive simulcast knows how many RID=E2=80=99s it wants to get." > > [BA] Typically the Offerer is a conference server, not a browser. And it > is sending an Offer to receive simulcast, not to send it. The browser do= es > have to setup its RtpSender to send simulcast based on the Offer from the > conference server, once applied. Some aspects of this seem clear - the > number of encodings should correspond to the number in the Offer, and the > RIDs should match. But some other aspects are not as clear - in the test= , > the Offer contained max-fr in the a=3Drid:X recv lines. In the FF > implementation do these result in setting of maxFramerate attributes in t= he > RtpSender? > > " > On Sun, Nov 4, 2018 at 3:34 AM Nils Ohlmeier > wrote: > >> >> >> On 4Nov, 2018, at 15:13, Harald Alvestrand wrote: >> >> In JSEP, we have the following text: >> >> >> In addition, JSEP does not provide a mechanism to handle an incoming >> offer requesting simulcast from the JSEP endpoint. This means that >> setting up simulcast in the case where the JSEP endpoint receives the >> initial offer requires out-of-band signaling or SDP inspection. >> >> In WEBRTC, we have been grappling with the problem of simulcast setup, >> and it seems that we have no obvious API surface that can be used for >> this purpose - creating transceivers (as we do for outgoing) doesn't fit >> the bill, because incoming SDP causes transceivers to be created wihout >> interacting with the API surface. >> >> I tried to drum up a test that would create such a setup based on SDP, >> but found that in conformance with JSEP, this doesn't work. >> >> Can someone tell me why we decided to not allow an incoming offer with >> a=3Dsimulcast and a=3Drid .... recv in it to generate outgoing simulcast >> capability? >> >> The test in question: >> >> https://github.com/web-platform-tests/wpt/pull/13902 >> >> >> I can=E2=80=99t answer your question of why not. >> But it is working in Firefox as this test shows >> >> https://searchfox.org/mozilla-central/source/dom/media/tests/mochitest/t= est_peerConnection_simulcastAnswer.html#59 >> >> I would have to look into the details, but I think for it to work you >> have to setup the RTP senders before setting the Offer (which is arguabl= y >> not a nice API design). Which usually is not a big problem as the server >> which wants to receive simulcast knows how many RID=E2=80=99s it wants t= o get. >> >> Best >> Nils Ohlmeier >> _______________________________________________ >> 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 > --000000000000d23f7c0579deab11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= How does the app set up the rtp sender?
<= br>
How does the app knows that the offer has simulcast enabled a= nd the rids without sdp inspection?

Best regards
Sergio



El dom., 4 nov. 2018 23:47, = Bernard Aboba <bernard.aboba@gmail.com> escribi=C3=B3:
Nils said:=C2=A0
" would have to look into the details, but I think for it= to work you have to setup the RTP senders before setting the Offer (which = is arguably not a nice API design). Which usually is not a big problem as t= he server which wants to receive simulcast knows how many RID=E2=80=99s it = wants to get."

[BA] Typically the Offerer is = a conference server, not a browser. And it is sending an Offer to receive s= imulcast, not to send it.=C2=A0 The browser does have to setup its RtpSende= r to send simulcast based on the Offer from the conference server, once app= lied. Some aspects of this seem clear - the number of encodings should corr= espond to the number in the Offer, and the RIDs should match.=C2=A0 But som= e other aspects are not as clear - in the test, the Offer contained max-fr = in the a=3Drid:X recv lines.=C2=A0 In the FF implementation do these result= in setting of maxFramerate attributes in the RtpSender?

nohlmeier@mozilla.com> wrote:


On 4Nov, 2018, at 15:13, Harald Alvestrand <hara= ld@alvestrand.no> wrote:

In JSEP, we have the following text:


= =C2=A0=C2=A0 In addition, JSEP does not provide a mechanism to handle an in= coming
=C2=A0=C2=A0 offer requesting simulcast from the JSEP endpoint.= =C2=A0 This means that
=C2=A0=C2=A0 setting up simulcast in the case whe= re the JSEP endpoint receives the
=C2=A0=C2=A0 initial offer requires ou= t-of-band signaling or SDP inspection.

In WEBRTC, we have been grapp= ling with the problem of simulcast setup,
and it seems that we have no o= bvious API surface that can be used for
this purpose - creating transcei= vers (as we do for outgoing) doesn't fit
the bill, because incoming = SDP causes transceivers to be created wihout
interacting with the API su= rface.

I tried to drum up a test that would create such a setup base= d on SDP,
but found that in conformance with JSEP, this doesn't work= .

Can someone tell me why we decided to not allow an incoming offer = with
a=3Dsimulcast and a=3Drid .... recv in it to generate outgoing simu= lcast
capability?

The test in question:

https://github.com/web-platform-tests/wpt/pull/13902

I can=E2=80=99t answer your qu= estion of why not.
But it is working in Firefox as this test show= s=C2=A0

I would have to look into the detail= s, but I think for it to work you have to setup the RTP senders before sett= ing the Offer (which is arguably not a nice API design). Which usually is n= ot a big problem as the server which wants to receive simulcast knows how m= any RID=E2=80=99s it wants to get.

Best
=C2= =A0 Nils Ohlmeier
______________________________________________= _
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listi= nfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listi= nfo/rtcweb
--000000000000d23f7c0579deab11-- From nobody Sun Nov 4 14:56:26 2018 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 646C7130E5E for ; Sun, 4 Nov 2018 14:56:17 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkEm5Rp8hUwi for ; Sun, 4 Nov 2018 14:56:15 -0800 (PST) Received: from mail-ua1-x943.google.com (mail-ua1-x943.google.com [IPv6:2607:f8b0:4864:20::943]) (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 561EC130E0F for ; Sun, 4 Nov 2018 14:56:15 -0800 (PST) Received: by mail-ua1-x943.google.com with SMTP id d8so2524446ual.2 for ; Sun, 04 Nov 2018 14:56:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tPlBeWWYKUI8EOdfpwkT466YFlAsf/t1CpOzE2/GL/0=; b=F9jfb2NBUlpRrdOyvq29UX8cPXragnKjFCL6KAjKQ181Xtz8OKMfE5r6R+xOCp+Npl zUk4Yjp/n31KyRlF4JonXasyE+xab6d/oJGcMFBqx7EhShgHVdgnesRfJf8PtvT3yIVh 0uJnwe8GYhdYDAPcdaSW2sR7kSD1M8hT2njKGDuNb0mgyDEMFzvhk+pXxsbyS7TxRFKm GkQd+JzYipybNViLBNsWJVB42QJkr1QiIHwhWgjhkUv9dgai24+0TgTiOYChc4gIwQsC 5H96Mb3H2lJ4vggrmFaeN/Z1lQ/nHv81Q7Z2vGd5+/BJ5QSJZjZtWJCyFpguYENJbEh/ 3rjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tPlBeWWYKUI8EOdfpwkT466YFlAsf/t1CpOzE2/GL/0=; b=efz34IcFjpIrMXLwLRK4WUmJGJNdzI1pmsINEb7CLAzDZAS7T/3yTQ8Og9q/t//KCY klNwfDx2RHrGLq1NQJ3vrfd/SoP1vxAGHWESN9wwvsnRAAd5uUkoRnXsfPSbgra8hxjw tLq3OrvCWwa+VjO3e4vC8Ycj8ayrRHs+aZ04TnACyoLlLuh63hHRsoN3dUVVU8QLU13D /QvBl7MW/3b1S+UhU5ZNSPWUFxWDEU0i3jRmWolVegtCY/sk9uKPOJ5zrTVEZ/c3bY7L 3HZI5H3PMGNlQVV+uAdh85Oaxg+sb/hAtXB96VCsX9pvqbsDaEHcooeEk/pAbDhAeqdN F65g== X-Gm-Message-State: AGRZ1gKdXFop5eTYHMGnBWY5FrXZXJPaSHPQjm3b8mHVktlb56T7D5SD 7EjlNGcz8RFlCZaO+j+Naa4QzxcwGqZeCGQM87lAvQ== X-Google-Smtp-Source: AJdET5fqG35P+wACQXXngT/pVM96eFdkoveRAuxSixqGJpCmpaL9YJRB8IKxgAlw8d1si0YNsXyMmYVQ4lrK/6z5aII= X-Received: by 2002:ab0:526:: with SMTP id 35mr8563342uax.84.1541372174395; Sun, 04 Nov 2018 14:56:14 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 4 Nov 2018 23:56:03 +0100 Message-ID: To: Bernard Aboba Cc: sergio.garcia.murillo@gmail.com, rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 22:56:25 -0000 On Sun, 4 Nov 2018 at 23:50, Bernard Aboba wrote: > > Sergio said: > > "I agree with I=C3=B1aki that the remote side should not be able to start= simulcast locally without app involvement. > IMHO best would be to keep things as they are, do not allow to receive a = simulcast offer. Instead, send a remote offer without simulcast from sfu, a= dd transceiver with simulcast encodings, create answer without simulcast m= line, and trigger renegotiate needed event so the app creates a new sdp of= fer sdp with the simulcast m line this time." > > [BA] That won't work because the conferencing server is the only one that= knows how many participants are in the conference, so it needs to send the= Offer. Yes, and when other peers want to join the conference, the server can provide them with a JSON like this: { useSimulcast : true, simulcastStreams: [ { rid: 1, priority: "high", maxBitrate: 100000 }, { rid2 1, priority: "medium", maxBitrate: 300000 } ] } so the peer creates a peerconnection, adds a video transceiver, sets the corresponding encodings into its RtpSender and we are done. We don't need to reduce/constraint the media signaling preferences to SDP l= and. --=20 I=C3=B1aki Baz Castillo From nobody Sun Nov 4 14:58:39 2018 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 1317D128CF3 for ; Sun, 4 Nov 2018 14:58:38 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofxCUIEZiAIL for ; Sun, 4 Nov 2018 14:58:35 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 70729128D68 for ; Sun, 4 Nov 2018 14:58:35 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id s9so4040667vsk.7 for ; Sun, 04 Nov 2018 14:58:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZctCsEX1n+7OaXWZlqRJmPUvFjpxibbfNaAhXfx0DOY=; b=BAHVHFR8WMqGMnjw8SRma/DmebltSb2betgZIeaN2dppXZCsFJxle6VgDrwjODZu85 t81NIYPyqTHACsMMvkylgQovTO0bTJ5sHH1u8i1pmRSHUDqkO/jkwTd24bRChl5hYpsR eYLPhB5RSHrMWzpG/ScO+qZyWD1eW3m97g6EDIAiza5UjRpWvqkIxMbGITszBFtN4D41 EgSjWNU2JtFLes8S/Rot9R2YSghdr9VNh9cSzWFq5KgVJQrWWiOaYMVUlXk25df02GVs Lv1sAcBXKQ8CK6qcO5VDLy39//KapA70B9bWQ9hi8Ay/C22tD0lnd+2r+53P3qWrn/xE aQDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZctCsEX1n+7OaXWZlqRJmPUvFjpxibbfNaAhXfx0DOY=; b=S0bqktCAHLiKG/s7T2ZX30MIwzi6Dzh0VD48bi1gJ3uAoiV/PUFc1FZtf999t2zFl9 JdeKQl/x4osJ36bt5m+T/zvf3iN+57AQRLzV/Ovk3OWNx2qectTtuMBwd7iIuNdS1as0 msNgGl1ZJlBaEzETkGXB2l8L+BM4wHYQ2DLsB6zVkyaYBl2l1nfIiSNidtQwNHW3GKzf e5IWFeRB8XXNA6JmCc382AENVEIDe8xqhu1nejcKRzfbNArqwZw1iihuNIfn/eUsz5CE jPKxUqdKReFp0w/i7l0kACv7QK36zWnqQx8vsy8CZq0mClhhEBAyzfv4YsEsQo9nzmwV ZNEA== X-Gm-Message-State: AGRZ1gLxHzQARd2CvpDJYGXm7Ybztn28xc/PDFr7yQKjW4RfPf6wIDiN O/sBNhuVyEAzchdp3xeqFZzD/6uBu9NATps9Txd1xQ== X-Google-Smtp-Source: AJdET5eAz36IzidY2p1SRlOkhS9xsSiun4mRmtDeOX+LJeQLPbD77rzHbBXW3EewMjxgICN3jRDt5kSki6gfU+oFlmA= X-Received: by 2002:a67:3edc:: with SMTP id a89mr4199886vsi.136.1541372314472; Sun, 04 Nov 2018 14:58:34 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 4 Nov 2018 23:58:23 +0100 Message-ID: To: sergio.garcia.murillo@gmail.com Cc: Bernard Aboba , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 22:58:38 -0000 On Sun, 4 Nov 2018 at 23:56, Sergio Garcia Murillo wrote: > > How does the app set up the rtp sender? > > How does the app knows that the offer has simulcast enabled and the rids = without sdp inspection? Ironically the app would know all those details *after* having consuming the remote SDP and after having enabled simulcast as the remote wishes. This is, without app consent and without app knowledge. This is a big NO-WAY. --=20 I=C3=B1aki Baz Castillo From nobody Sun Nov 4 15:31:15 2018 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 5D7D612F295 for ; Sun, 4 Nov 2018 15:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 Jbv3-cB7zQyc for ; Sun, 4 Nov 2018 15:31:12 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 93A5B1293FB for ; Sun, 4 Nov 2018 15:31:12 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id p74so4094408vsc.0 for ; Sun, 04 Nov 2018 15:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5ojctdJ3CmGM2+YQB3KTB+eEsP5mlRbtzZgfBdQwnfA=; b=MmnNBtfTgvvnxBT10wdKdGVAKDg6LOUF2q1G8x1COXzljHWS+FvWjwPQ0p0TO+xRZ/ TFTxpt0YGOsTIEeU0XeVKx0VeLOhM1dc/cvR15hrGB4Rm3GLn5Ic/xipA44RBjdeMGQa cQdpPhZDC25l7RJUtSzh8WCLMxJBamCDQnhoM6y4Gkz9lGnwDw6XUSLnjUm1pm9U8nTq qdlz4FObOeU5sCeFpuOLWizxRV6vE49owS9DrGGoQO3haSDVfyj1QW2cgclaEIKD5NAq 2AZCmU73PaKrjBXPpixzAlkTM04qY+jrAmZj63lRw+Rhp6iqbR2jhRHExi90kt5lP17q OR+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5ojctdJ3CmGM2+YQB3KTB+eEsP5mlRbtzZgfBdQwnfA=; b=uEVaE3Tc6Oi5rtd06hi6KonyYoGF+z+XN7zTAEcax7wjcqnM/IsyOs4mzfEBHm23ER dBZlj1n9yDEFmKLVYXGeI6oSam/ubCXwokT0LH1bUkvgrDuOHYwM0kinhEDlODbICQIp 044nw55WlJ5bsvyiAT9H7q2cMzhBvc/UG73Nl1ZDqqamWG5SG/Bxdva0XLWTdhLacIhH bioGKdAF25WRbBo/GNaq3x2erTNhIwLt4+rgigLutzomSBOfLPYjcxSujZl+Cw1sTp7U JGPDKUFfv6MJLYXLbZTRqCR4eaHnlsNWLvbsHI4+HBmrHblNOEhN6h8GuOK84jLA1nFe VhbA== X-Gm-Message-State: AGRZ1gLOeqCceKHkDaBT6mSvDzTNz2/iJZBQPk/x1TQjXUnfnxdoXLq5 X+SezSZjoeM1D0RVNW5M37uL+fQY7v0UbxPryqE= X-Google-Smtp-Source: AJdET5fOK0KdSAreMDITDWSUBWTgwJejd7gTSKbBvBYdXi7E280jbxsOUgnU5ggcq5/LH93I5VJTI6D7tRhbyo87aps= X-Received: by 2002:a67:ebc3:: with SMTP id y3mr7697356vso.75.1541374271038; Sun, 04 Nov 2018 15:31:11 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: Bernard Aboba Date: Sun, 4 Nov 2018 18:30:59 -0500 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Nils Ohlmeier , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000e42b7c0579df2979" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 23:31:14 -0000 --000000000000e42b7c0579df2979 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Inaki said: "Hi Bernard, before entering into implementation details, do you really agree that the remote should be able to force the local peer what and how to send media?" [BA] The remote can't force the local peer to send media. The local peer still has to configure the direction and encodings to describe how and whether to send simulcast. The main simulcast information communicated in the Offer is the maximum number of streams the conferencing server can accept and the RID names. On Sun, Nov 4, 2018 at 5:52 PM I=C3=B1aki Baz Castillo wrot= e: > On Sun, 4 Nov 2018 at 23:47, Bernard Aboba > wrote: > > [BA] Typically the Offerer is a conference server, not a browser. And i= t > is sending an Offer to receive simulcast, not to send it. The browser do= es > have to setup its RtpSender to send simulcast based on the Offer from the > conference server, once applied. Some aspects of this seem clear - the > number of encodings should correspond to the number in the Offer, and the > RIDs should match. But some other aspects are not as clear - in the test= , > the Offer contained max-fr in the a=3Drid:X recv lines. In the FF > implementation do these result in setting of maxFramerate attributes in t= he > RtpSender? > > Hi Bernard, before entering into implementation details, do you really > agree that the remote should be able to force the local peer what and > how to send media? > > Also, you are assuming the scenario in which the conference server > offers a peer to receive simulcast from him. Where does such an > assumption come from? We don't need that assumption in WebRTC land. If > the conference *application* wants to ask peers to send simulcast can > be achieved by tons of ways (via custom messages or whatever), we > should not reduce everything to the "SIP world" in which everything is > expressed by sending a SDP. > > -- > I=C3=B1aki Baz Castillo > > --000000000000e42b7c0579df2979 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inaki said:=C2=A0

"Hi Bernard, bef= ore entering into implementation details, do you really
agree that the= remote should be able to force the local peer what and
how to send= media?"

[BA] The remote can't force the = local peer to send media. The local peer still has to configure the directi= on and encodings to describe how and whether to send simulcast. The main si= mulcast information communicated in the Offer is the maximum number of stre= ams the conferencing server can accept and the RID names.=C2=A0
=
On Sun, Nov 4, 2018 at 5:52= PM I=C3=B1aki Baz Castillo <ibc@aliax.= net> wrote:
On Sun, 4 Nov 20= 18 at 23:47, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> [BA] Typically the Offerer is a conference server, not a browser. And = it is sending an Offer to receive simulcast, not to send it.=C2=A0 The brow= ser does have to setup its RtpSender to send simulcast based on the Offer f= rom the conference server, once applied. Some aspects of this seem clear - = the number of encodings should correspond to the number in the Offer, and t= he RIDs should match.=C2=A0 But some other aspects are not as clear - in th= e test, the Offer contained max-fr in the a=3Drid:X recv lines.=C2=A0 In th= e FF implementation do these result in setting of maxFramerate attributes i= n the RtpSender?

Hi Bernard, before entering into implementation details, do you really
agree that the remote should be able to force the local peer what and
how to send media?

Also, you are assuming the scenario in which the conference server
offers a peer to receive simulcast from him. Where does such an
assumption come from? We don't need that assumption in WebRTC land. If<= br> the conference *application* wants to ask peers to send simulcast can
be achieved by tons of ways (via custom messages or whatever), we
should not reduce everything to the "SIP world" in which everythi= ng is
expressed by sending a SDP.

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>= ;
--000000000000e42b7c0579df2979-- From nobody Sun Nov 4 15:33:54 2018 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 871D5130DD2 for ; Sun, 4 Nov 2018 15:33:52 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei4dOZQ9CUhl for ; Sun, 4 Nov 2018 15:33:50 -0800 (PST) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 AB81E12F295 for ; Sun, 4 Nov 2018 15:33:50 -0800 (PST) Received: by mail-ua1-x931.google.com with SMTP id o17so2536344uad.8 for ; Sun, 04 Nov 2018 15:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NG3SZDDDq7gVERJ57LMrtlGO6t0yijR1yvhosluXhsE=; b=WOpvtHma/cbUIqEzsTM7+K29uy9u4B/h06rW2DdLZOCywHhUve97FWfbZs+UN43TGW nwkgft5TYk0ZSNxW4e7vTuTXC2pAlS5OXMnLisay7Rne7L4rBvNiInHMhkM+15Et6xlg iAR5+PmfIXWJEYTsGMAL5VAZzPPyURsy/iywu8HqELl0i0+1ktsD62tC0BXgN1YIPllP LBm+qnqs+Rx/OsoZSBmTBHkXDWugoTHRzSjeuu70kxDJ63U3QmWEs3JiM05yMBgoSY0w 4LiNG9WcFrgkPdeubmVeoSWaLuukWK6S5Mht3sS5cK5oy3pjUoxEMeiAf4mevy7Lt0sj ivEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NG3SZDDDq7gVERJ57LMrtlGO6t0yijR1yvhosluXhsE=; b=naGKdPx9NMZ1iFxWoaMD8+HJN5vyHcBCISh+FdsCKzjbPtE7G4Mo5IhIsRangtHXqB 1rlG/U4k45awIwYSqp5PnVMYVaVd3fsVmeGE+NMiJwmOiZofZAQLIq973EizOoZMYP4k HvlIXe6AMYWjO80abZSmX8RHRVg50ixI69qYRLsC3Pmiu8buIGRO/mjuvZjpSIIfz/LQ OrXxZSIkJPKP0YGVsXM8DfJrL2wNHQY3rbUFCo+giadpuvNG9ROVWSRjZ6X9hzHVH5Lt uPgJQtAndkKo7grRtX3rt+wmLxhVjrc26mIt4/gUnyLhcwegU7tQKM6pXuTM7xcmgcly rmtw== X-Gm-Message-State: AGRZ1gLGwdMZ3KEOT5XEr2upU0LXhw6k4YFt5YYjLv9uiRHp3Wv6DTmA 8HuPSZ/YzXim9lcEnvH4tspXbC7YgOsD3n0kRhppiA== X-Google-Smtp-Source: AJdET5edqz0r2wqMCTV3DYmoKpYg0WQtiYhKhKfC7tkmOC/rLY/4YCSVITJOTod9ssyYQ8ukyJNuAaOqH+5TRH7Dsq4= X-Received: by 2002:ab0:3392:: with SMTP id y18mr9133669uap.117.1541374429464; Sun, 04 Nov 2018 15:33:49 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 00:33:37 +0100 Message-ID: To: Bernard Aboba Cc: nohlmeier@mozilla.com, rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 23:33:53 -0000 On Mon, 5 Nov 2018 at 00:31, Bernard Aboba wrote: > > Inaki said: > > "Hi Bernard, before entering into implementation details, do you really > agree that the remote should be able to force the local peer what and > how to send media?" > > [BA] The remote can't force the local peer to send media. The local peer = still has to configure the direction and encodings to describe how and whet= her to send simulcast. The main simulcast information communicated in the O= ffer is the maximum number of streams the conferencing server can accept an= d the RID names. Once the remote (the conf server) sends its SDP offer, the local peer can just blindly trust it and consume it via pc.setRemoteDescription(), and once done, the party has already started: - The transceiver has been automatically created. - If the local pc had a video track, a simulcast enabled RtpSender has been automatically created. - etc etc, everything without app knowledge/consent. --=20 I=C3=B1aki Baz Castillo From nobody Sun Nov 4 15:35:09 2018 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 6A3DD12F295 for ; Sun, 4 Nov 2018 15:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 SodQYi9ABAf2 for ; Sun, 4 Nov 2018 15:35:05 -0800 (PST) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 5F1ED1293FB for ; Sun, 4 Nov 2018 15:35:05 -0800 (PST) Received: by mail-vk1-xa2d.google.com with SMTP id 185so1601745vkv.13 for ; Sun, 04 Nov 2018 15:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cRKqav+LO5PknDm3j9INw40Q35IMNPO4Hgry5flvq0k=; b=VVMvlIRoHOerOn1alUKyWBfe/Nugt+9fbX5jQ/rwY3OTuu63vXPDYAMoyyWbq90mTe ZNnQ8q356MJKkihK8ken5aFRn+40gTuP9xtO4K/kmKNOBFYperBEqCoWFcwTK46J8Nef Xy41wOEtOaxtuGiSQMFe2FFfcDSkl9LIrUzogZHKpChmW3tQO+lt0WuYy4J3hxemb+DF tzJr7HvshIvBxgKJQb7xaYpG8cpThx/O2wyQFc6rBjtUqHcQypS5qVJWByWVaw+ujulO U40IGjuZjkdUDuf0jlIqWYTDE3JLe3To9SVQlrUsMDfvkkJD319c3dIRiPjO68Nd7fhf wJ/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cRKqav+LO5PknDm3j9INw40Q35IMNPO4Hgry5flvq0k=; b=XmaNCdfj0Vg7Wv8UN3+7/z1mgxzdgpzztF0F8E0H/S34qOS6LIrJ3zGHveOvZrqxJn ydIwT3a3ZYTStRCF7X3nH9b9/owBwXSFIWLmxIzQE9YQtdv8eC+kLXSZk7pNV4OJhsW3 Cy3JfHv7WiPlkEc3tIq90YFN9R0TFTKqX+w/mkEXYjsYRhpYnjNC+1Whp73G2zAqWbaC Nk6cLTx9T9f+Qa+VUBTp68yNbp0WLga1jcmwR+R0xPnUweP+x/TwCnwTorG3lLtdkXDM 8L6AsBuBQZbYLYPVCCwHR6FrXu01TXRGqzN5HHENjcTHfEoyLyHkZfXBkq0ZtbjDcVa4 iheQ== X-Gm-Message-State: AGRZ1gIqVHU+AKjQk6qQrUFV7xQwaVnq9t0qwpH3xaVsmdWxHLR3lOeX tS6vxS2Gt7s/o5Cs35TnX8710ZMpPgE5Q6kW4CM= X-Google-Smtp-Source: AJdET5eRsW3CiJhvUoIIXuXgly5RfjBYLvNH4Wo8C99E8f9Sqpzsaz+60JFaQoiEtQZHU6pnrTvQ3nVCB/Y/jgS1ZIQ= X-Received: by 2002:a1f:5a01:: with SMTP id o1mr3515641vkb.4.1541374504239; Sun, 04 Nov 2018 15:35:04 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: Bernard Aboba Date: Sun, 4 Nov 2018 18:34:53 -0500 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Sergio Garcia Murillo , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000ca89600579df3780" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 23:35:07 -0000 --000000000000ca89600579df3780 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sergio said: "Ironically the app would know all those details *after* having consuming the remote SDP and after having enabled simulcast as the remote wishes. This is, without app consent and without app knowledge. This is a big NO-WAY." [BA] All the Offer communicates is that the conferencing server can receive up to a maximum number of simulcast streams and the RID names. So presumably the application still has to call transceiver.sender.setParameters() to set the other details of the simulcast transmission (such as whether streams are active, their resolution scale, maximum framerate, etc.). On Sun, Nov 4, 2018 at 5:58 PM I=C3=B1aki Baz Castillo wrot= e: > On Sun, 4 Nov 2018 at 23:56, Sergio Garcia Murillo > wrote: > > > > How does the app set up the rtp sender? > > > > How does the app knows that the offer has simulcast enabled and the rid= s > without sdp inspection? > > Ironically the app would know all those details *after* having > consuming the remote SDP and after having enabled simulcast as the > remote wishes. This is, without app consent and without app knowledge. > > This is a big NO-WAY. > > > -- > I=C3=B1aki Baz Castillo > > --000000000000ca89600579df3780 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sergio said:=C2=A0

"Ironically the= app would know all those details *after* having
consuming the remote = SDP and after having enabled simulcast as the
remote wishes. This is, wi= thout app consent and without app knowledge.

This is a big NO-= WAY."

[BA] All the Offer communicates i= s that the conferencing server can receive up to a maximum number of simulc= ast streams and the RID names. So presumably the application still has to c= all transceiver.sender.setParameters() to set the other details of the simu= lcast transmission (such as whether streams are active, their resolution sc= ale, maximum framerate, etc.).=C2=A0

On Sun, Nov 4, 2018 at 5:58 PM I=C3=B1aki Baz Castillo= <ibc@aliax.net> wrote:
On Sun, 4 Nov 2018 at 23:56, Sergio Garcia = Murillo
<se= rgio.garcia.murillo@gmail.com> wrote:
>
> How does the app set up the rtp sender?
>
> How does the app knows that the offer has simulcast enabled and the ri= ds without sdp inspection?

Ironically the app would know all those details *after* having
consuming the remote SDP and after having enabled simulcast as the
remote wishes. This is, without app consent and without app knowledge.

This is a big NO-WAY.


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>= ;
--000000000000ca89600579df3780-- From nobody Sun Nov 4 15:38:25 2018 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 A38A81293FB for ; Sun, 4 Nov 2018 15:38:23 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbrvy6snMPSe for ; Sun, 4 Nov 2018 15:38:22 -0800 (PST) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 D836412F295 for ; Sun, 4 Nov 2018 15:38:21 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id 124so4059944vsp.12 for ; Sun, 04 Nov 2018 15:38:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0CWVXtZGXPQqUJ+Zla5VFtwMYoyD5o+kg0AlwLwU94Y=; b=a5+sa0pMcu6JGgRvS10l8nC17xEhWhJzO9WdjOy66vykcNqCbIC9iBbZovY59A7dY4 j7NXBQ6+SVJLmKCCUhqCV/yR+qL+RADZzih09PDyE5tYxF/uX/ZfPVQ7GKuqoEaa5fcp iCsCPPr1YMqP8TVu2+chDmvE82HWfGV43DADUL/9vgcKrK6ODckZiehSOkR046f9cahp 00/RgVvdln6JfgDwU75cHY5htjHgRhyKUvVmTdfOETx9PX91v+vrtzpQHGvU1UBmMDJE zSSyT4DXdgB//q48/myRRwCkXJBAoNLteDt3PMPIEGs2stclAAMCuaYhcQezGKCp7rV5 wZuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0CWVXtZGXPQqUJ+Zla5VFtwMYoyD5o+kg0AlwLwU94Y=; b=RsCWUzrGmmvR/+nOOuTJgWYyeeM3KDi8VGnFLlJ3qqf2PRI1z+d9UUZ6ON9UWEL0l7 o/NG2aPW5Ql4ohzektAWwKa0v2YVsP+p7pSDElvTNuoMxnMg0tjwr15+ZfyoBrSG9PAO f5TmRVeww5OhsIjL6Kplsz5xO98Y7C3qk8LbULde+yMmXlvSGSQQfLVj5ZKn5DQuf9WN BQk8XIyiopMPcXkNstDJjLj3sFryCl9TEcK+0ACoYslX8w7QDJju6v8yqut4YoBGlCBh gkc2N5UtGyNMDqZ/Uh8iwKGAHA24CDhIsltyrxoZW7rhG6mAJf+0ujUy++yicNlmQcRH 3fMA== X-Gm-Message-State: AGRZ1gJrSj4MuXpTxR7EqAfZ0/xnuPa1JbeEx9EtoDk6jcHIvXC9H8Xm 7MG5v4gKVYo2vbwul1whRTU3VSKFsdYTwVXbS60xXw== X-Google-Smtp-Source: AJdET5c5OWw5TjjK/3cMxLZ/kySrNStXgNuiVxTdWvcZ6vCrvNYNqDdOYLla6y4Fyxr3MJ+Tt4p3UhY7r2psWgpPaOQ= X-Received: by 2002:a67:3659:: with SMTP id d86mr8414483vsa.17.1541374700937; Sun, 04 Nov 2018 15:38:20 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 00:38:09 +0100 Message-ID: To: Bernard Aboba Cc: sergio.garcia.murillo@gmail.com, rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 23:38:24 -0000 On Mon, 5 Nov 2018 at 00:35, Bernard Aboba wrote: > > Sergio said: > > "Ironically the app would know all those details *after* having > consuming the remote SDP and after having enabled simulcast as the > remote wishes. This is, without app consent and without app knowledge. > > This is a big NO-WAY." > > [BA] All the Offer communicates is that the conferencing server can recei= ve up to a maximum number of simulcast streams and the RID names. So presum= ably the application still has to call transceiver.sender.setParameters() t= o set the other details of the simulcast transmission (such as whether stre= ams are active, their resolution scale, maximum framerate, etc.). As told above, there is no way for the app to decide that upon receipt of the remote offer, since there is no API hook to set those simulcast and encodings parameters. In fact, Firefox obeys the simulcast parameters of the remote offer automatically and start sending all the simulcast streams as requested by the remote offerer. So, the thing here is whether WebRTC 1.0 (SDP based) deserves even more API hacks to enable this feature (manage sending simulcast upon receipt of a remote offer) or if's just better to leave this feature unsupported and wait for a proper non SDP based API (WebRTC-NG?). --=20 I=C3=B1aki Baz Castillo From nobody Sun Nov 4 16:06:43 2018 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 AD0C3130DD2 for ; Sun, 4 Nov 2018 16:06:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 kLvugWf-RfF5 for ; Sun, 4 Nov 2018 16:06:40 -0800 (PST) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (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 2AC401294D0 for ; Sun, 4 Nov 2018 16:06:40 -0800 (PST) Received: by mail-vk1-xa2b.google.com with SMTP id y14so1621213vkd.1 for ; Sun, 04 Nov 2018 16:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zUAisl0VeS/QFaNkxK3pV1hASqPpHWiMKWljMfLLxBw=; b=LNSYXQKhyxtl93Xhh/zw8D4yFgeriRnr8+v2mHqWbYlmD7wzddz+sxvCQYK0XYnqNl GUXQIxMnBoR9sJHMrR/lfu8+wGaKEpZHgrURFl52jvURx9zubegnq/es/RNe+0juz42t /8GKbJOPZW7tgJuv2vCzDzop40cWMF+kRSOO7RA9BEUsbUud5fYcH1Jnce8OjcohQKif OL9E2cCq2X+SVJLojsaAs1sS6Nfy4afrR/63qjGsYVJQsq1RCfHpsWW5F9uDNzZiRMHm 7dCSecEdoKRfIiI1672Rt9gckQGl6ODDWeq9MY3UWfM8Iv8ajuI+Ux/1ogCfYhsI3Gv9 dQeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zUAisl0VeS/QFaNkxK3pV1hASqPpHWiMKWljMfLLxBw=; b=XD5iZ6N3aBmTFtXV/y9AHXfW2nfEn5PtjDUEmAAmSTaOtIcwmFXqkroOyWY8tJLxLY 0ghMXWf5uXUF9iXp+U64m+q9piEicwqrMnLIk3u1FFTBe5AGvu/XYb+hKm3O07Pjwf2Z dxRxGYys7aaB5gE1v8GvQ6wx0Ib2D6VYyNbblV4Lc7peQpoSB8cN7NOKC0RCGSzLiAkN OMESsWfO99zAyyLSrg3vv/4J1b4G6O6DIsozu0/Z8fSTjuxlKpgjFdVoloDq3APqkG+b MwszBG0cUuy+k5oVT7+DhetkQPz6ueK6F6Ltr+H1NgLpOyBGsAA+L4RUO0y4Rv/APx9B a2zA== X-Gm-Message-State: AGRZ1gJFN1+kN1QnRaPKcImXSMa9uhar8BGU1I5c39Ijhs0F/bN0eBgh B5fntv36DP98WJZae/AhdqE= X-Google-Smtp-Source: AJdET5e8/W8rRYSU8neqbFeWCG8HWdIKmeaWOzSWmJgJGVuCqOwD25XL9atXNjHPldcvgBh8AU0p7A== X-Received: by 2002:a1f:490:: with SMTP id 138mr7261142vke.48.1541376398905; Sun, 04 Nov 2018 16:06:38 -0800 (PST) Received: from ?IPv6:2600:380:4d7c:e02c:7c47:e696:f71a:e45c? ([2600:380:4d7c:e02c:7c47:e696:f71a:e45c]) by smtp.gmail.com with ESMTPSA id k77sm1406794vkd.17.2018.11.04.16.06.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Nov 2018 16:06:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Sun, 4 Nov 2018 19:06:36 -0500 Cc: sergio.garcia.murillo@gmail.com, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3442D892-6D7A-42EE-AE19-455E7684F31F@gmail.com> References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 00:06:42 -0000 On Nov 4, 2018, at 6:38 PM, I=C3=B1aki Baz Castillo wrote: >=20 > As told above, there is no way for the app to decide that upon receipt of t= he remote offer, since there is no API hook to set those simulcast and encod= ings parameters. [BA] There is sender.setParameters(), which can turn simulcast encodings on/= off or set other parameters relating to simulcast. > In fact, Firefox obeys the simulcast > parameters of the remote offer automatically and start sending all the sim= ulcast streams as requested by the remote offerer. [BA] That doesn=E2=80=99t seem like a good idea. For example, the applicatio= n could start sending 3 simulcast streams, all at the same bitrate, resoluti= on or framerate. Might make more sense for the default for Offer-created str= eans to be active: false until the application decides differently with setP= arameters().=20 > wait for a proper non SDP based API (WebRTC-NG?). [BA] No need to wait for a non-SDP API, it=E2=80=99s been implemented and al= ready handles this case quite nicely ;)= From nobody Sun Nov 4 16:08:34 2018 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 DAFC31294D0 for ; Sun, 4 Nov 2018 16:08:32 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtWeRFjr8uCu for ; Sun, 4 Nov 2018 16:08:31 -0800 (PST) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 038F81293FB for ; Sun, 4 Nov 2018 16:08:31 -0800 (PST) Received: by mail-vk1-xa30.google.com with SMTP id l186so1625313vke.0 for ; Sun, 04 Nov 2018 16:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sDPP9Rt2kWETUsd/Y7J2zEnQ3AquR9h556pOwQrNH8M=; b=JJy4X+ylad8SWao/kvZZe8ZU383hxi68/hyGaTQYxqqx3Gj6tfd6XZYBIsMnnENFFB J74UXc2gQwfeQQpjIxvDZfmwOLzy3lpBlGxgZq6nEKX8lDgr2sjRovbysD5gHxD471mE 6wbFj85IFROBS9naa/0VDseMDDNegr1YVKk0lrU4c3xx9QDCjrU8eQPYZQ1o5htCugsw wdiM6U/+nsq6ijuh0/L8f59AkrpYRCY+iTwnNWBAliBD9zeiHakTMs5XKUi8laBR6h3H AjEzsrzR/iuoiEwKzmKnDV3B1MysvrbzROMlnyC8xJOKsCKuGH7x74aYTgFmKjbnJk95 V7BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sDPP9Rt2kWETUsd/Y7J2zEnQ3AquR9h556pOwQrNH8M=; b=H5CKEHai3aneZJwSzpdOjbR8tw1fgfhFRx3hY+fVyaQyiQrhzQFWy/dzY8t3xt94ex rBciMlZeHHcOJqqtxUvYW+8A3GKvHUx+OMU1Evw3x08XYTD5sp7/FGYTHkX/RgWZQOR1 +KNz7N7lZJRJHVQAfiMdCzHf6SvcxiC0ziqK+i5XfyY0Bx3hqPYw2DSpss78Dh9ODxYt nZqErGiOnLIToYSQ9G1JZ6vGY4J81Rug/nPmOWzQupG3+m4rU2eNNMEL1DsPeuURN7HB g1+tZUYuEFdNnyoU0RPHu0NQfv7yulrwT/MUQNOeKeiTlLL6Sv/dmRDAZ56kuzIwGzIR DSGQ== X-Gm-Message-State: AGRZ1gKhy02VKf+FiWmMq6YcC97UEFaEM4SNZnYC+MvTee0VmK4I50JR PVvVPBVA0T6zUjvlPa37KqRi2gq3kKcV1+m1zvouCw== X-Google-Smtp-Source: AJdET5c5JC6rmI1Op6Iuiln0FSdV2dSy7g+dVge0dhe9q1f4wEjdASCjyhVi7ri3KgG1/3El1epJ55qeJNSc+6Upw+8= X-Received: by 2002:a1f:346:: with SMTP id 67mr2384181vkd.10.1541376509973; Sun, 04 Nov 2018 16:08:29 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <3442D892-6D7A-42EE-AE19-455E7684F31F@gmail.com> In-Reply-To: <3442D892-6D7A-42EE-AE19-455E7684F31F@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 01:08:18 +0100 Message-ID: To: Bernard Aboba Cc: sergio.garcia.murillo@gmail.com, rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 00:08:33 -0000 On Mon, 5 Nov 2018 at 01:06, Bernard Aboba wrote: > > On Nov 4, 2018, at 6:38 PM, I=C3=B1aki Baz Castillo wrote= : > > > > As told above, there is no way for the app to decide that upon receipt = of the remote offer, since there is no API hook to set those simulcast and = encodings parameters. > > [BA] There is sender.setParameters(), which can turn simulcast encodings = on/off or set other parameters relating to simulcast. You receive a SDP blob, pass it to pc.setRemoteDescription() and... and right now you are already sending simulcast streams. --=20 I=C3=B1aki Baz Castillo From nobody Sun Nov 4 16:20:02 2018 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 159EE130DD2; Sun, 4 Nov 2018 16:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=apple.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 C50MjzapoU73; Sun, 4 Nov 2018 16:19:47 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 B0CCF130E01; Sun, 4 Nov 2018 16:19:47 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.22/8.16.0.22) with SMTP id wA501xCd024738; Sun, 4 Nov 2018 16:19:46 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : from : subject : message-id : date : cc : to; s=20180706; bh=gkL4CMVPiZWKRiHnhTR/c4jXteFPT04uGfGofkSHqPA=; b=wl7rExabYmj8aYwK9D2hmUuvcAbIChEkWjQAu83L+bvaK1tupdPxQafy3USmRMevPccU eo3Ha6wa7OVfPqz7yaT3FRZXWR0H+HVMBdKSQOImioLW+iTdKAZzk5CTLPigqZlqGCcd iq8CB5sUcpp+J4HKm6ZRleqWbMgorcWlvKQs48xGvgwXp1RauMRJ3Ar0ZtCAJgNNDd03 14AB7uHKwVowa5T+HVgb0k4pJLK4IrrAb4P3xCVqyWHqeq0a7sjXC7MJc2O/S7yAEfep M0Skj0HJ1ERkBn/b6Qo2qM7Ti17nrLlgZKx6+DoxjI+iofaCKSUZgeiOcEx7DoeQiaAL HA== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2nhab730nh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 04 Nov 2018 16:19:46 -0800 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ma1-mmpp-sz11.apple.com (ma1-mmpp-sz11.apple.com [17.171.128.33]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PHP00GUL28YPR30@ma1-mtap-s01.corp.apple.com>; Sun, 04 Nov 2018 16:19:46 -0800 (PST) Received: from process_viserion-daemon.ma1-mmpp-sz11.apple.com by ma1-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PHP00N001CW0Y00@ma1-mmpp-sz11.apple.com>; Sun, 04 Nov 2018 16:19:46 -0800 (PST) X-Va-A: X-Va-T-CD: 8f06955753c9914ccee2ead7b013056e X-Va-E-CD: 3aff4d1e31abfdf3d4431ab8fb3cfe87 X-Va-R-CD: b7ef2668a01b66eb24691e801e63c290 X-Va-CD: 0 X-Va-ID: 64d0c7fc-3806-4743-ba75-8d66e52c8010 X-V-A: X-V-T-CD: 8f06955753c9914ccee2ead7b013056e X-V-E-CD: 3aff4d1e31abfdf3d4431ab8fb3cfe87 X-V-R-CD: b7ef2668a01b66eb24691e801e63c290 X-V-CD: 0 X-V-ID: a541b8fd-c7d7-49a5-8785-919b25dc6ef4 Received: from process_milters-daemon.ma1-mmpp-sz11.apple.com by ma1-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PHP004001MGK300@ma1-mmpp-sz11.apple.com>; Sun, 04 Nov 2018 16:19:46 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-04_17:,, signatures=0 Received: from [17.234.143.171] (unknown [17.234.143.171]) by ma1-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PHP00BEB28QQW20@ma1-mmpp-sz11.apple.com>; Sun, 04 Nov 2018 16:19:46 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <9FB4DA1B-B45C-41A0-85FF-A7E09199F380@apple.com> Date: Mon, 05 Nov 2018 07:19:36 +0700 Cc: TAPS WG IETF list To: rtcweb@ietf.org X-Mailer: Apple Mail (2.3445.100.36) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-04_17:, , signatures=0 Archived-At: Subject: [rtcweb] Discussing WebRTC API mappings in TAPS X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 00:19:49 -0000 Hello rtcweb, Based on recent proposals for WebRTC APIs to run over QUIC, the Transport Services (TAPS) working group will be spending some time this week looking at the usefulness and applicability of our flexible transport APIs for use in WebRTC. One of the main goals is providing an API surface that will work well across protocols and require minimal application effort to adopt, as well as being able to dynamically use newer protocols. We'd like to get input and feedback on how well such a model can serve the WebRTC use case. Please join us in our discussion if you're interested! Wednesday, November 7 1540-1710 Afternoon Session II Transport Services WG Room: Meeting 2 Thanks, Tommy From nobody Sun Nov 4 16:22:01 2018 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 258F5130E01 for ; Sun, 4 Nov 2018 16:22:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 usphJCxlx2dG for ; Sun, 4 Nov 2018 16:21:56 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 89916130DD2 for ; Sun, 4 Nov 2018 16:21:56 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id m15so10282871itl.4 for ; Sun, 04 Nov 2018 16:21:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=SmUz3Hryd5IqQ47lpqqoBnn6FKDsMFHGuXeX7Q8Wo9g=; b=CiYgOdHOVQ56Yn83vcy8AirbSMUlwivLW1B/ixdAlseyaJECIXSroWp5t+ADK49ksy X4+6tsB/mP+DE9Aeimh6Nhe8CK33JBtJDeV00Zu0ZZKXS6Tr8JnzqV2ruyWipm0VLaD5 CvifFv4UWEyEQtNFsNNlW2T0px7mgIA9vzIhs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=SmUz3Hryd5IqQ47lpqqoBnn6FKDsMFHGuXeX7Q8Wo9g=; b=kpaZMR36O4aHGtkOyvNkZAM1HX6gYOtCGKnUZNSzW5C7Go1zJl0++0hs3Gjyh63M93 gX234/57g6u3Qi1UzQ8G7xQbPkYDKvmQnYBiS0dGqB/W9Cyf1lfETvK/GqMBHdc+Z6XZ 4eGb5XFpz5hscJ/o8M8rudPOGdsXHdgdCmLnUm2cJNEahiJm0T/YtH8imXnm87m/ePSo 4wvWgSljveWgwtgUlbldxjKxF5fW1+CbKHx/Vovpsyub0uicC9GRxE7tprHpc0dafnLy Vkq2AVxVA2rLk8fljRhaFktf5jtJf95Jm/kvSy3jaKJCI00QX95vZwvyDDlZ5FvCnB28 sp6A== X-Gm-Message-State: AGRZ1gIFmXmeIfr2ILYWKXtWbpWrrixieGC4ibHZHgqmFQhXbYPx+x6a 6oo6xUJdRIzTSdbQdn+HBNe73g== X-Google-Smtp-Source: AJdET5dJcbaa/P9b5wqGnfMLFPu/g1mbvItnBCshges+TT3+qGxg+b/+9OD0/reCYwmqAnNqFGo2iQ== X-Received: by 2002:a24:414f:: with SMTP id x76-v6mr5458156ita.30.1541377315849; Sun, 04 Nov 2018 16:21:55 -0800 (PST) Received: from [10.6.6.153] ([209.58.147.244]) by smtp.gmail.com with ESMTPSA id o14-v6sm5926447ito.3.2018.11.04.16.21.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Nov 2018 16:21:54 -0800 (PST) From: Nils Ohlmeier Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_087FCA06-157F-4218-BFE5-844298A3F660" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Mon, 5 Nov 2018 07:21:49 +0700 In-Reply-To: Cc: Bernard Aboba , rtcweb@ietf.org To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 00:22:00 -0000 --Apple-Mail=_087FCA06-157F-4218-BFE5-844298A3F660 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5Nov, 2018, at 06:38, I=C3=B1aki Baz Castillo = wrote: >=20 > As told above, there is no way for the app to decide that upon receipt > of the remote offer, since there is no API hook to set those simulcast > and encodings parameters. In fact, Firefox obeys the simulcast > parameters of the remote offer automatically and start sending all the > simulcast streams as requested by the remote offerer. Here is a fiddle which demonstrates that just putting simulcast into the = offer, but not calling setEncodings() does not activate simulcast: = https://jsfiddle.net/x6qgab87/ So the other side can=E2=80=99t force simulcast on the browser. If you = provide me with a demo which shows that it is possible, then that is a = bug I=E2=80=99ll happily fix for you. Best Nils Ohlmeier= --Apple-Mail=_087FCA06-157F-4218-BFE5-844298A3F660 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 5Nov, 2018, at 06:38, I=C3=B1aki Baz Castillo <ibc@aliax.net> = wrote:

As told above, there is no way for the app to decide that = upon receipt
of the remote offer, since there is no API = hook to set those simulcast
and encodings parameters. In = fact, Firefox obeys the simulcast
parameters of the remote = offer automatically and start sending all the
simulcast = streams as requested by the remote offerer.

Here is a = fiddle which demonstrates that just putting simulcast into the offer, = but not calling setEncodings() does not activate simulcast: https://jsfiddle.net/x6qgab87/
So the other = side can=E2=80=99t force simulcast on the browser. If you provide me = with a demo which shows that it is possible, then that is a bug I=E2=80=99= ll happily fix for you.

Best
  Nils = Ohlmeier
= --Apple-Mail=_087FCA06-157F-4218-BFE5-844298A3F660-- From nobody Sun Nov 4 16:26:44 2018 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 02E9A12896A for ; Sun, 4 Nov 2018 16:26:43 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3b4Ijf8tbc3 for ; Sun, 4 Nov 2018 16:26:41 -0800 (PST) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 23F40128766 for ; Sun, 4 Nov 2018 16:26:41 -0800 (PST) Received: by mail-vk1-xa36.google.com with SMTP id y14so1627384vkd.1 for ; Sun, 04 Nov 2018 16:26:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2xQoj1ShpKh0KmiyKrUB54q88hZI6ztvWXqcQDyzASw=; b=SkTkSUVbox24ZbgB1aOY9jLI9cZ818Km72H1HwW/nzRMH/mGjWGNfa47ov6xCnUvYG Eu6ZDLlnFcjx3lmT/qgXrqXoV1Uvyg4jSEI8e1LLJefAhWJCiuyY/FcLiqBWmvyDve5X xN9TpefTXqFy6x56it6Kcnd5KaDlPtXGvT3eU9Dae1yYZmyPasHHfeV9TGR1FaZbneMm 14EJ3pjGd6nUm9bMWXyvuuBfebv8I07dm1S8zQ5mqnk8Rr6TJujFKYw5vV+3NGesTTYc 6aa9qtyXNccQDUvdN/pAg9hu4ZQhGuqwg9PplKXQKPpW4kHa3d9868tSC9NZWWd6Sr9I znVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2xQoj1ShpKh0KmiyKrUB54q88hZI6ztvWXqcQDyzASw=; b=ONbkp0xRVIe/N0kEs+PqkpPUsl146ID0zrlnjRu1GE7egK+rQaKiubJOtmykiovZma bZBUTZ8q62ilGsU/gF+fNMAT0B7257T70qhW/Jizpi9OS6E86M4Sm+WLZL/gbUsQ9mIq PjsW0ZUEFHHFJzXbTrGhKjV6Fj7xk1X1qN8IhhJM0YhGGeId6nabmHsL/Ry3sSLPmCnN T7OqLM4K1fMf2VtH1zzKMWrsgNvx8aph7leLXwnf/cW9zw8lNL/2iEmHncoIVQ/73wjt LC/WXsekXud8YZ59AqIK6GShpZ+YjxFcjyqQ1x1T/4Km3CBQOy4C7XgnzKzEiwbWkTHj kGQQ== X-Gm-Message-State: AGRZ1gJARUKTvCHDwMtrwUdvaKckz+mFF15EMU9VBvPhYcJ+KYIX/r0u DIMA6o29OBDzDsPL+cIPrgv7ILzVUSkYEQq9/sCBoupg21w= X-Google-Smtp-Source: AJdET5e3ryG1lAlpafZjR6Odr2D8polvlBH49f1GSVI6EtQey0u9JRwECOEg3cF1YKRir6shxVRGVxtZVYEX/CE2CZw= X-Received: by 2002:a1f:8b48:: with SMTP id n69mr774858vkd.12.1541377600148; Sun, 04 Nov 2018 16:26:40 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 01:26:28 +0100 Message-ID: To: nohlmeier@mozilla.com Cc: Bernard Aboba , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 00:26:43 -0000 (On Mon, 5 Nov 2018 at 01:21, Nils Ohlmeier wrote: > > Here is a fiddle which demonstrates that just putting simulcast into the = offer, but not calling setEncodings() does not activate simulcast: https://= jsfiddle.net/x6qgab87/ > So the other side can=E2=80=99t force simulcast on the browser. If you pr= ovide me with a demo which shows that it is possible, then that is a bug I= =E2=80=99ll happily fix for you. Ok, that's new. I remember many months ago when I reported this (I was in fact producing simulcast based on remote SDP offer) and it was not necessary to call sender.setParameters({ encodings }) after sRD and before createOffer. Ok, this behavior makes more sense. BUT: it's not feasible because you need to use hardcoded/fixed rid values (or manually do SDP parsing). --=20 I=C3=B1aki Baz Castillo From nobody Sun Nov 4 16:37:30 2018 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 44B2312896A for ; Sun, 4 Nov 2018 16:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 v_3ZFde6xw4g for ; Sun, 4 Nov 2018 16:37:26 -0800 (PST) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 20082128766 for ; Sun, 4 Nov 2018 16:37:26 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id z13-v6so5201040wrs.3 for ; Sun, 04 Nov 2018 16:37:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5ufencf7PU3EvuWzyQvHNIXinboe0ESd91pGYRgTbFo=; b=uJ8mpXeYKe7aC9MSZ3uukcaRCG5JYLkRhu98IB2oRCZ62J2sPMk564z5OgO1i/6N8t NsIBpo4J2fypCkLXGCY/95yGINU1l9Im30/9rzKYmQLKVjbszboAZcl1zdqIMIcAK65q qyGhikz2uiWF2x1Q4LWLkiMcj3GUBXCYHcKOIgjjVSoXEtGWYE+9n814mNVQUlTdO6qh BnjFvADmJSPXz66j76JXOYHPpE7MkU7qOaIXbtqJk0DkD/1D1Y707Lpbb8niYKnG4tKC BUfZMyigX0jmnrBSBBdk+jv5utQdtbGkscpHawu5nRzBP8/Lo3eKV5Ct8nkOyJrQ4C9o 9Ndw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5ufencf7PU3EvuWzyQvHNIXinboe0ESd91pGYRgTbFo=; b=kpdsnqQMVCyaSKMI+5ftF7MTf6Sgzrv3W3gfop0kKqw56ZI1nblv7wMgG3zURNyxlB 4ilxcxR7YeKxPxusi+Wiiyqg7ohxeZSdAk9EwC7Enz/+ZgiON88qxC99ILqhAh9Mdiow PPhdiqN5FtQlnd5bmgUG0Z2UHeefxd4ciz8x4gI11DPuC2ylUt8P8HHZBkPOIxf5gW+1 /QjHuP+PsILIv53A6BXHBPVhpwFoEDNN/RTH/+RDlonuaOe1iTHt/kCjynYjnZ5jvUm2 5nXEqUc5eHTovVxeshC7Qhd3iU9OFsXUf/hHgWwVf6bmdOZ9uG8H61XQex1DWTXt2bxx pNdA== X-Gm-Message-State: AGRZ1gLgjBLEQVtWTmu2RetCwgCM1lRrO7s/SHt7I7o/ylTmSV06AoYg iRXtk5UmwtY1fLnMH35pL1RHByrKSqpyD+qemgo= X-Google-Smtp-Source: AJdET5dlYNRr/wlA8e8K4cuFulCoW9/vRwzI9tpHn98G5oS8LLy+5G1z/IT9UB8pXush+eXPpXUyjrGVv7fcJNnHpPg= X-Received: by 2002:adf:9170:: with SMTP id j103-v6mr13426375wrj.217.1541378244525; Sun, 04 Nov 2018 16:37:24 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: Sergio Garcia Murillo Date: Mon, 5 Nov 2018 01:37:12 +0100 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Nils Ohlmeier , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000bac2ea0579e01668" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 00:37:28 -0000 --000000000000bac2ea0579e01668 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable there could be a way to overcome this by setting all the send encodings active flag to false when receiving a simulcast offer. Then app can do a getParameters, get layer num and rids, configure the settings and enable the desired ones by setting active to true. Best regards Sergio El lun., 5 nov. 2018 1:26, I=C3=B1aki Baz Castillo escribi= =C3=B3: > (On Mon, 5 Nov 2018 at 01:21, Nils Ohlmeier wrote= : > > > > Here is a fiddle which demonstrates that just putting simulcast into th= e > offer, but not calling setEncodings() does not activate simulcast: > https://jsfiddle.net/x6qgab87/ > > So the other side can=E2=80=99t force simulcast on the browser. If you = provide > me with a demo which shows that it is possible, then that is a bug I=E2= =80=99ll > happily fix for you. > > Ok, that's new. I remember many months ago when I reported this (I was > in fact producing simulcast based on remote SDP offer) and it was not > necessary to call sender.setParameters({ encodings }) after sRD and > before createOffer. > > Ok, this behavior makes more sense. BUT: it's not feasible because you > need to use hardcoded/fixed rid values (or manually do SDP parsing). > > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000bac2ea0579e01668 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
there could be a way to overcome this b= y setting all the send encodings active flag to false when receiving a simu= lcast offer. Then app can do a getParameters, get layer num and rids, confi= gure the settings and enable the desired ones by setting active to true.
Best regards
Sergio

El lu= n., 5 nov. 2018 1:26, I=C3=B1aki Baz Castillo <ibc@aliax.net> escribi= =C3=B3:
(On Mon, 5 Nov 2018 at 01:2= 1, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
>
> Here is a fiddle which demonstrates that just putting simulcast into t= he offer, but not calling setEncodings() does not activate simulcast: https://jsfiddle.net/x6qgab87/
> So the other side can=E2=80=99t force simulcast on the browser. If you= provide me with a demo which shows that it is possible, then that is a bug= I=E2=80=99ll happily fix for you.

Ok, that's new. I remember many months ago when I reported this (I was<= br> in fact producing simulcast based on remote SDP offer) and it was not
necessary to call sender.setParameters({ encodings }) after sRD and
before createOffer.

Ok, this behavior makes more sense. BUT: it's not feasible because you<= br> need to use hardcoded/fixed rid values (or manually do SDP parsing).


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listi= nfo/rtcweb
--000000000000bac2ea0579e01668-- From nobody Sun Nov 4 16:41:44 2018 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 128F112896A for ; Sun, 4 Nov 2018 16:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFSxBwoN99pH for ; Sun, 4 Nov 2018 16:41:41 -0800 (PST) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 CA7AA128766 for ; Sun, 4 Nov 2018 16:41:40 -0800 (PST) Received: by mail-ua1-x935.google.com with SMTP id s26so2581302uao.0 for ; Sun, 04 Nov 2018 16:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SegZIwJGfVRmDTeAgbROJw1bntwf+RSAfY6NdDtBC8U=; b=pC+1M/fRJFZpQ+vsHFJqzGSc3muYL53jh/ybjZV/Mo+3EA03N/CCHBlDr/rRnrQ7Ms aliTmtkzpETiBjIah3ETq999xlvcjTp1Exy+AuWOWvH70dKUrdpGVvkpyk19ywNvX7L7 GIBW4TJFkrmrAPYUjIkvsApJo+X8L/VZZnQ0B0Ootmc4zM+KFZs0oqWjHh/F+zBIujt8 9uk+Bg2rVcrgH+eY4BxoHrLIriMOHWHlxuOv1mc7ETYlh5IKxP6DlA9tJ51uFzIhARoB ZhOzu2g2Lnb+QT59dLRVk61m5TZYGPUb+KOI1vLsW+PuSuUoEcH/AF1DMb5DTB2MZLCs UcRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SegZIwJGfVRmDTeAgbROJw1bntwf+RSAfY6NdDtBC8U=; b=oj/uOKYW/6TxDuAihDsbNFrTjt2yOxcmhiTakvuR5j4mnAubpcBQ+pXGJscEpSYGvZ 2o6qX9pSldDLxI6mgfY5H5e7w+KrNH0Rf+2AJIsFPPpA9zSaR0ZuMx8DijWD8jYAZeTT twTkw+5OOeqI+UPP5oQYNhlcm+434JPqHvbqDVWi3tylZDPleZ0Bcof55Txau05v+8Lo vOqWMtDwaxqo6VsvHwAAtX3WC3ywINE9q1WclpNmswlT09/tMAXl6Tgx8gTbvK2uEFDT Ptg/LyU8+XIrLaUJHTHitpIWN9c8KKHPPudmwveSv0OJ3OrrghGtYFbEmBTdGo6CKH3c +7qQ== X-Gm-Message-State: AGRZ1gIcYsALZjbb5nTqNO8xtybcDfZB6IE9Hl8dUIbL5i4tzKp+8I8h 99Qp+zOutHTs4S9njWpmQvoTncs2yCWqlbns6GYqug== X-Google-Smtp-Source: AJdET5dA9TBF176Qi8McJjnMCk6rnOd6Bjc05hYFhez/fPsaaH1+tnU3uagQRQa6BAxxCx5szC350ihKsuqcSSexEQ8= X-Received: by 2002:ab0:3392:: with SMTP id y18mr9194335uap.117.1541378499809; Sun, 04 Nov 2018 16:41:39 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 01:41:28 +0100 Message-ID: To: sergio.garcia.murillo@gmail.com Cc: nohlmeier@mozilla.com, rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 00:41:43 -0000 Mmm, true, RtpReceiver does also have a getParameter() so the app can get the desired list of rids. On Mon, 5 Nov 2018 at 01:37, Sergio Garcia Murillo wrote: > > there could be a way to overcome this by setting all the send encodings a= ctive flag to false when receiving a simulcast offer. Then app can do a get= Parameters, get layer num and rids, configure the settings and enable the d= esired ones by setting active to true. > > Best regards > Sergio > > El lun., 5 nov. 2018 1:26, I=C3=B1aki Baz Castillo escrib= i=C3=B3: >> >> (On Mon, 5 Nov 2018 at 01:21, Nils Ohlmeier wrot= e: >> > >> > Here is a fiddle which demonstrates that just putting simulcast into t= he offer, but not calling setEncodings() does not activate simulcast: https= ://jsfiddle.net/x6qgab87/ >> > So the other side can=E2=80=99t force simulcast on the browser. If you= provide me with a demo which shows that it is possible, then that is a bug= I=E2=80=99ll happily fix for you. >> >> Ok, that's new. I remember many months ago when I reported this (I was >> in fact producing simulcast based on remote SDP offer) and it was not >> necessary to call sender.setParameters({ encodings }) after sRD and >> before createOffer. >> >> Ok, this behavior makes more sense. BUT: it's not feasible because you >> need to use hardcoded/fixed rid values (or manually do SDP parsing). >> >> >> -- >> I=C3=B1aki Baz Castillo >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb --=20 I=C3=B1aki Baz Castillo From nobody Sun Nov 4 18:57:43 2018 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 7FAA5128BCC for ; Sun, 4 Nov 2018 18:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qXmA4GGC-YmT for ; Sun, 4 Nov 2018 18:57:39 -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 B0B991298C5 for ; Sun, 4 Nov 2018 18:57:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 129DE7C576F; Mon, 5 Nov 2018 03:57:37 +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 fJz6woSBl5Fb; Mon, 5 Nov 2018 03:57:36 +0100 (CET) Received: from [172.20.18.215] (110-170-235-6.static.asianet.co.th [110.170.235.6]) by mork.alvestrand.no (Postfix) with ESMTPSA id 230E07C5754; Mon, 5 Nov 2018 03:57:34 +0100 (CET) To: Sergio Garcia Murillo , =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= Cc: RTCWeb IETF References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: Date: Mon, 5 Nov 2018 03:57:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 02:57:41 -0000 On 11/04/2018 11:36 PM, Sergio Garcia Murillo wrote: > I agree with I=C3=B1aki that the remote side should not be able to star= t > simulcast locally without app involvement.=C2=A0 > > IMHO best would be to keep things as they are, do not allow to receive > a simulcast offer. Instead, send a remote offer without simulcast from > sfu, add transceiver with simulcast encodings,=C2=A0 create answer with= out > simulcast m line, and trigger renegotiate needed event so the app > creates a new sdp offer sdp with the simulcast m line this time. The question at hand is: If the remote SDP indicates that the remote end is willing to receive 3 simulcast layers, and the browser is able to send 3 simulcast layers, how many simulcast encodings should be represented in the sender.getParameters() returned after the negotiation completes - and what are the implications of that? Remember that we already decided (in WEBRTC) that the number of encodings in the sender.getParameters() is the way the browser tells the Javascript what the maximum number of simulcast encodings it can configure is. At no point did I want to address how many of those layers should be enabled; I think the same thing as we do in other places (enable 1 layer by default, others must be enabled by setParameters()) is fine. From nobody Sun Nov 4 19:02:13 2018 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 10802130934 for ; Sun, 4 Nov 2018 19:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 dFe6qXYNC32f for ; Sun, 4 Nov 2018 19:02: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 DB0E6126BED for ; Sun, 4 Nov 2018 19:02:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 352827C576F; Mon, 5 Nov 2018 04:02:03 +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 kSuDmNzhmBE6; Mon, 5 Nov 2018 04:02:02 +0100 (CET) Received: from [172.20.18.215] (110-170-235-6.static.asianet.co.th [110.170.235.6]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3EF7D7C5754; Mon, 5 Nov 2018 04:02:00 +0100 (CET) To: Sergio Garcia Murillo , =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= Cc: RTCWeb IETF References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: Date: Mon, 5 Nov 2018 04:01:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 03:02:08 -0000 On 11/04/2018 11:36 PM, Sergio Garcia Murillo wrote: > I agree with Iñaki that the remote side should not be able to start > simulcast locally without app involvement.  > > IMHO best would be to keep things as they are, do not allow to receive > a simulcast offer. Instead, send a remote offer without simulcast from > sfu, add transceiver with simulcast encodings,  create answer without > simulcast m line, and trigger renegotiate needed event so the app > creates a new sdp offer sdp with the simulcast m line this time. The problem is that there is no way under current WEBRTC procedures to increase the number of encodings on a sender after creating the sender. we're already in the rabbit hole. From nobody Sun Nov 4 21:16:42 2018 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 0FA5D128CF2 for ; Sun, 4 Nov 2018 21:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 fNKMDLE17fQl for ; Sun, 4 Nov 2018 21:16:37 -0800 (PST) Received: from smtp65.iad3b.emailsrvr.com (smtp65.iad3b.emailsrvr.com [146.20.161.65]) (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 8E3D51277C8 for ; Sun, 4 Nov 2018 21:16:37 -0800 (PST) Received: from smtp9.relay.iad3b.emailsrvr.com (localhost [127.0.0.1]) by smtp9.relay.iad3b.emailsrvr.com (SMTP Server) with ESMTP id 3F45E202AF; Mon, 5 Nov 2018 00:16:36 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp9.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A7E6E202B3; Mon, 5 Nov 2018 00:16:34 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.68.221.190] ([UNAVAILABLE]. [173.39.121.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.7.12); Mon, 05 Nov 2018 00:16:36 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_0D1B1352-B757-44B3-9A00-64C0145DD4FC" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Mon, 5 Nov 2018 12:16:31 +0700 Cc: Bernard Aboba , RTCWeb IETF Message-Id: <5FB0A50F-DAF3-47C4-A5F5-8DA20586C9E2@iii.ca> References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 05:16:40 -0000 --Apple-Mail=_0D1B1352-B757-44B3-9A00-64C0145DD4FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 5, 2018, at 5:52 AM, I=C3=B1aki Baz Castillo = wrote: >=20 > Hi Bernard, before entering into implementation details, do you really > agree that the remote should be able to force the local peer what and > how to send media? I agree with Bernard.=20 It's not about force something to do something - the app can always do = whatever it wants with offers and answers - it's about the local side = being able to interop with a changing remote side without having to = worry about anything local. Every time the browsers add new features, = it's pretty awesome if my application gets them without even worrying = about them if there is no need to worry about them.=20 --Apple-Mail=_0D1B1352-B757-44B3-9A00-64C0145DD4FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 5, 2018, at 5:52 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> = wrote:

Hi Bernard, before entering into implementation = details, do you really
agree that the remote should be able to = force the local peer what and
how to send = media?

I agree with Bernard. 

It's not about force something to do = something - the app can always do whatever it wants with offers and = answers -  it's about the local side being able to interop with a = changing remote side without having to worry about anything local. Every = time the browsers add new features, it's pretty awesome if my = application gets them without even worrying about them if there is no = need to worry about them. 



= --Apple-Mail=_0D1B1352-B757-44B3-9A00-64C0145DD4FC-- From nobody Sun Nov 4 22:41:14 2018 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 2916512F18C for ; Sun, 4 Nov 2018 22:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Be4aH6fy9Ad7 for ; Sun, 4 Nov 2018 22:41:10 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 0A08E12EB11 for ; Sun, 4 Nov 2018 22:41:10 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id d10-v6so8128239wrs.5 for ; Sun, 04 Nov 2018 22:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QvRoc0j6ANpwseutkxt3qjH/9UlMVAb08sEpUxIkAGc=; b=Txgfz5RVj9Dl24q2Z49eP22d1elyT1ezdlKdsiFvbo0k9g53AlILTPywJEW8SzYwEL TQHwUX1xOEBmnDrDhE1wfvHDxKsgv5zGPbbte08vqNkfPwVPEI3J1TinhOApePiKmJTe 1zArVl0jQ8gYmShQaeafUhC+4N1QdsA6ha51SpHRD8t8PaSQlw3QmlPgaUgN5uQ8Aknm ErDcdkr+sPXRXjOnmq4B64XzC5N4dHDv7VDQ4eVog2GvOul03rgBnf99N78HBvA8ipkQ d3Iw1s7+lgQamv5n71HJk4SMgxoMguxG6BwowQ+4FzRLgZTtqXQSH5TXCxpgnhwB7Bfz IhJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QvRoc0j6ANpwseutkxt3qjH/9UlMVAb08sEpUxIkAGc=; b=d/U8dwYHHpidOfqLFzVkCirdUdDPQahnSHTQxEvZtBosUMdRpDU3RNLQLNLfHuQa8t gBfIoKzeVaR9ZQjX8BByYyFiwtnrQhp4JVvfHGoFw6vO2xDwT5l9XDSXpv1M/C4gY+SX f7RoCZYX96vXbdJ4Pfp/Irbq1RK1LSMv+o7TBRErRTHd3p+YP8hEhfdZqDC/9jBlosfx LD8c8JR/4J1yM7LuAQ47QhlPL9Mh6BhAY16zrPIz1rjIcpUxs0n+xUUjwS/LMDBEkfua 1CxnGSwFQtwJHuyiA4zzln3kpPTMkKcn9j3ncafZcrowABJLmbIBF0nFbj+leRyMffGy fbRg== X-Gm-Message-State: AGRZ1gIdU3rTOP1iYKmuvSO+bv2SEKFQuov6MLMwdjJAMM7Y5+5E+UJL FEU7sy6HN77TRdgOIICAPOuQLUbeWHaUsu4T9dQ= X-Google-Smtp-Source: AJdET5fECoAuhycbGwROgoRrsUktBRcm427EaIHst3TEvSmVB9ACyxRnh6+cq1LSawl2yUPeX9ErSxa7q+pSd1nt0+Q= X-Received: by 2002:adf:eb8e:: with SMTP id t14-v6mr18627246wrn.109.1541400068281; Sun, 04 Nov 2018 22:41:08 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: Sergio Garcia Murillo Date: Mon, 5 Nov 2018 07:40:56 +0100 Message-ID: To: Harald Alvestrand Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000086da790579e52b39" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 06:41:12 -0000 --00000000000086da790579e52b39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That would create a new rtpsender with all the encodings and not reuse the initial transceiver as it dont support simulcast. It should be supported under current specs. Best regards Sergio El lun., 5 nov. 2018 4:02, Harald Alvestrand escribi=C3=B3: > On 11/04/2018 11:36 PM, Sergio Garcia Murillo wrote: > > I agree with I=C3=B1aki that the remote side should not be able to star= t > > simulcast locally without app involvement. > > > > IMHO best would be to keep things as they are, do not allow to receive > > a simulcast offer. Instead, send a remote offer without simulcast from > > sfu, add transceiver with simulcast encodings, create answer without > > simulcast m line, and trigger renegotiate needed event so the app > > creates a new sdp offer sdp with the simulcast m line this time. > > The problem is that there is no way under current WEBRTC procedures to > increase the number of encodings on a sender after creating the sender. > > we're already in the rabbit hole. > > --00000000000086da790579e52b39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That would create a new rtpsender with all the encodings = and not reuse the initial transceiver as it dont support simulcast.=C2=A0
=C2=A0
It should b= e supported under current specs.

Best regards
Sergio


El l= un., 5 nov. 2018 4:02, Harald Alvestrand <harald@alvestrand.no> escribi=C3=B3:
On 11/04/2018 11:36 PM, Sergio Garcia Murillo wrote:
> I agree with I=C3=B1aki that the remote side should not be able to sta= rt
> simulcast locally without app involvement.=C2=A0
>
> IMHO best would be to keep things as they are, do not allow to receive=
> a simulcast offer. Instead, send a remote offer without simulcast from=
> sfu, add transceiver with simulcast encodings,=C2=A0 create answer wit= hout
> simulcast m line, and trigger renegotiate needed event so the app
> creates a new sdp offer sdp with the simulcast m line this time.

The problem is that there is no way under current WEBRTC procedures to
increase the number of encodings on a sender after creating the sender.

we're already in the rabbit hole.

--00000000000086da790579e52b39-- From nobody Mon Nov 5 00:03:30 2018 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 6470F128CFD for ; Mon, 5 Nov 2018 00:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 xhHkMlkEg97j for ; Mon, 5 Nov 2018 00:03:26 -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 D66F11274D0 for ; Mon, 5 Nov 2018 00:03:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0842C7C3F6D; Mon, 5 Nov 2018 09:03:24 +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 QBSZ86Zz8-0d; Mon, 5 Nov 2018 09:03:22 +0100 (CET) Received: from [IPv6:2001:67c:370:128:e6a7:a0ff:fe0b:6b0c] (unknown [IPv6:2001:67c:370:128:e6a7:a0ff:fe0b:6b0c]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4F0357C3CF7; Mon, 5 Nov 2018 09:03:20 +0100 (CET) To: Sergio Garcia Murillo Cc: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , RTCWeb IETF References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> Date: Mon, 5 Nov 2018 09:03:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B9E68439E229EC321B9D3CD6" Content-Language: en-GB Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 08:03:28 -0000 This is a multi-part message in MIME format. --------------B9E68439E229EC321B9D3CD6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 11/05/2018 07:40 AM, Sergio Garcia Murillo wrote: > That would create a new rtpsender with all the encodings and not reuse > the initial transceiver as it dont support simulcast. We don't have a means of replacing the transceiver associated with a media section. So replacing it would mean rejecting the already negotiated media section and adding a new media section that has exactly the same properties, except that it has the properties of the media section that the original offer requested. I must admit that I have problems understanding what the problem is with adding multiple (disabled) encodings on the created transceiver. >   > It should be supported under current specs. > > Best regards > Sergio > > > El lun., 5 nov. 2018 4:02, Harald Alvestrand > escribió: > > On 11/04/2018 11:36 PM, Sergio Garcia Murillo wrote: > > I agree with Iñaki that the remote side should not be able to start > > simulcast locally without app involvement.  > > > > IMHO best would be to keep things as they are, do not allow to > receive > > a simulcast offer. Instead, send a remote offer without > simulcast from > > sfu, add transceiver with simulcast encodings,  create answer > without > > simulcast m line, and trigger renegotiate needed event so the app > > creates a new sdp offer sdp with the simulcast m line this time. > > The problem is that there is no way under current WEBRTC procedures to > increase the number of encodings on a sender after creating the > sender. > > we're already in the rabbit hole. > -- Surveillance is pervasive. Go Dark. --------------B9E68439E229EC321B9D3CD6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/05/2018 07:40 AM, Sergio Garcia Murillo wrote:
That would create a new rtpsender with all the encodings and not reuse the initial transceiver as it dont support simulcast.

We don't have a means of replacing the transceiver associated with a media section. So replacing it would mean rejecting the already negotiated media section and adding a new media section that has exactly the same properties, except that it has the properties of the media section that the original offer requested.

I must admit that I have problems understanding what the problem is with adding multiple (disabled) encodings on the created transceiver.
 
It should be supported under current specs.

Best regards
Sergio


El lun., 5 nov. 2018 4:02, Harald Alvestrand <harald@alvestrand.no> escribió:
On 11/04/2018 11:36 PM, Sergio Garcia Murillo wrote:
> I agree with Iñaki that the remote side should not be able to start
> simulcast locally without app involvement. 
>
> IMHO best would be to keep things as they are, do not allow to receive
> a simulcast offer. Instead, send a remote offer without simulcast from
> sfu, add transceiver with simulcast encodings,  create answer without
> simulcast m line, and trigger renegotiate needed event so the app
> creates a new sdp offer sdp with the simulcast m line this time.

The problem is that there is no way under current WEBRTC procedures to
increase the number of encodings on a sender after creating the sender.

we're already in the rabbit hole.


-- 
Surveillance is pervasive. Go Dark.
--------------B9E68439E229EC321B9D3CD6-- From nobody Mon Nov 5 01:00:17 2018 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 BA5D5128CFD for ; Mon, 5 Nov 2018 01:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 2WlUCUxCScN4 for ; Mon, 5 Nov 2018 01:00:12 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 62B951274D0 for ; Mon, 5 Nov 2018 01:00:12 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id q12-v6so7214461wmq.0 for ; Mon, 05 Nov 2018 01:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=UgKeM6gMAy2IrltJXiMXjpM6FHVBcJjckMHRzZWoDLg=; b=cb/Uiz2ffm8Cmm2H9jOPI+3BzjDtXb+qNyUca65cIulj51/uDhVpKyCasl/BhCuhwv r+2I3eOHgWKddELJtCuVVRIeZVc/2ILZ+ZCrq1Pw5T3P0j9mJDlBu+QNgXhpi0u2M4vp dfThWAx8r3p0dWDVXGbF1SQkTCUgqx+AwAfLzkOWLQ/Njf+x1n/So+yLh6gbe9FRufSr IUrdOqJbcQoZlUijvOEXYK/DDEdZfJWcgjw9j63vJ9gT0XV0ScJvI6JMZ+6LsT/1p57V UBdTE/IX29cGV3QihuZIuQ3cFCL7D6wpzDRgaSuM1pYGjrhTjVssd+wtx8MKL6vZp4IP sz2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=UgKeM6gMAy2IrltJXiMXjpM6FHVBcJjckMHRzZWoDLg=; b=HGJ8zp7nfRgsMZjBokswtCAVKwEgMyr3oMshqDoM05m837HpupwR+wibiS2Dtu/C45 deIGeQ5Of7In/xSPd9ObG5aTx6yDeDOpRKJojRXiuhu5dwbuDDosJW5TVkcaYTAgYjIR zEYyeAn09z6Bd9DxpEyaIoxYjIeJHoErYLKPgPt3gmGQ6S3qL6dNfGzi6ahJZJHPyXIb 8WxW5DERMYXjcDYYrAkxQ3ysfjBYbA8KT20ENHEBu8ISYNQJksyoHI+XC07DIbnzyYQg yrUjFU4PkroUC8H1CzE45jGHoC4yzDJo188BmivL89nnoAazT3QGMY4KLat16goqtIyb 3PDw== X-Gm-Message-State: AGRZ1gK8KdlUqxy7yPJlA/segEXG2MZL+OU7uRsGN5LRNMW/EEAa+88c /87V0KpioWRCsFF3ZeLr0P2jcDYI X-Google-Smtp-Source: AJdET5fpOl11gACBXp9o+jruXNdIT61id2O8vyXv+tB1FV2wlY0am6MvcMwKEQKut/gyGY06ewj6mg== X-Received: by 2002:a1c:6283:: with SMTP id w125-v6mr5385027wmb.117.1541408410522; Mon, 05 Nov 2018 01:00:10 -0800 (PST) Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id t77-v6sm60749348wme.18.2018.11.05.01.00.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 01:00:09 -0800 (PST) To: Harald Alvestrand Cc: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , RTCWeb IETF References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> From: Sergio Garcia Murillo Message-ID: Date: Mon, 5 Nov 2018 10:03:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 09:00:15 -0000 On 05/11/2018 9:03, Harald Alvestrand wrote: > On 11/05/2018 07:40 AM, Sergio Garcia Murillo wrote: >> That would create a new rtpsender with all the encodings and not >> reuse the initial transceiver as it dont support simulcast. > > We don't have a means of replacing the transceiver associated with a > media section. So replacing it would mean rejecting the already > negotiated media section and adding a new media section that has > exactly the same properties, except that it has the properties of the > media section that the original offer requested. I am not talking about replacing a transceiver but adding a new one and renegotiate. The initial O/A will drop the simulcast attribute on the answer and create a recvonly transceiver, and then create a new transceiver with simulcast encoding that will require a O/A. > > I must admit that I have problems understanding what the problem is > with adding multiple (disabled) encodings on the created transceiver. My fears are that this change may not be self contained within a single chapter/paragraph but spawn over all the spec and introducing new edge cases we have to solve in sections that are already closed. Best regards Sergio From nobody Mon Nov 5 03:45:55 2018 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 7A2B312EB11 for ; Mon, 5 Nov 2018 03:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 6dnbAvuKfOiQ for ; Mon, 5 Nov 2018 03:45:51 -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 E357912D4E8 for ; Mon, 5 Nov 2018 03:45:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id EB7117C0C76; Mon, 5 Nov 2018 12:45:48 +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 rzOxaYIyDqjW; Mon, 5 Nov 2018 12:45:47 +0100 (CET) Received: from [IPv6:2001:67c:1232:144:e6a7:a0ff:fe0b:6b0c] (unknown [IPv6:2001:67c:1232:144:e6a7:a0ff:fe0b:6b0c]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0FB707C0C33; Mon, 5 Nov 2018 12:45:45 +0100 (CET) To: Sergio Garcia Murillo Cc: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , RTCWeb IETF References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> Date: Mon, 5 Nov 2018 12:45:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 11:45:54 -0000 On 11/05/2018 10:03 AM, Sergio Garcia Murillo wrote: > On 05/11/2018 9:03, Harald Alvestrand wrote: >> On 11/05/2018 07:40 AM, Sergio Garcia Murillo wrote: >>> That would create a new rtpsender with all the encodings and not >>> reuse the initial transceiver as it dont support simulcast. >> >> We don't have a means of replacing the transceiver associated with a >> media section. So replacing it would mean rejecting the already >> negotiated media section and adding a new media section that has >> exactly the same properties, except that it has the properties of the >> media section that the original offer requested. > I am not talking about replacing a transceiver but adding a new one > and renegotiate. The initial O/A will drop the simulcast attribute on > the answer and create a recvonly transceiver, and then create a new > transceiver with simulcast encoding that will require a O/A. OK, so we have the same picture in mind of what will happen in your proposal. We end up with an useless transceiver and a new transceiver that is suggested by the browser end, in a new media section; it's impossible to use the media section that the (initiating) server proposed. That seems ugly. >> >> I must admit that I have problems understanding what the problem is >> with adding multiple (disabled) encodings on the created transceiver. > > My fears are that this change may not be self contained within a > single chapter/paragraph but spawn over all the spec and introducing > new edge cases we have to solve in sections that are already closed. Are there closed sections? I do fear that simulcast will continue to affect parts of the spec that we don't expect it to. But we don't have the luxury of specifying it halfway; either we rip it out altogether, or we specify it in enough detail for interoperable implementation. > > Best regards > Sergio -- Surveillance is pervasive. Go Dark. From nobody Mon Nov 5 03:51:31 2018 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 CF3E21277CC for ; Mon, 5 Nov 2018 03:51:29 -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 XWmJimqppmH6 for ; Mon, 5 Nov 2018 03:51:28 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 3F68A127133 for ; Mon, 5 Nov 2018 03:51:28 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id 124-v6so3084933wmw.0 for ; Mon, 05 Nov 2018 03:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=VCZC3843t9wJ2A+Evxkb5FTHCcSWqgyaQ+cY+HjkFQg=; b=ZQ6zWxhl1yvQ+U44LCzZu0VuXyZnP4hJOPYwf3KC+AZ931UDgx85eHZM3jugkC4u59 BrwL/8D6ihN5SheCNRbAaPRXhfkvbqdZjVfcq+dFvIZo2nlsbnt4E0gMBA1iP4cwGar/ Jtpuix03QTOC3HsA3H6Oicbn/Lku5a/9MetzogqgGUgED7pIylrss2b5+6vM00GUT38Q wK0v7ImcLln25JZnVDx7DsFnUwbNHwFyFfmHrw853ckbZ7/fIiFgM57ltrFv8Wd62fhk O8VJEuZTAzb+35tZShZiutw+8uUBSAz9Lw3YZbst7VOZjahhTrK4ae2thiaNX9fq8Pwu mdPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=VCZC3843t9wJ2A+Evxkb5FTHCcSWqgyaQ+cY+HjkFQg=; b=RAqnpUk50Qff6qVeyLwNTSug8QGBnd2cBuf0nw+o8/+o22UTYJS34eG30toelMoFYX PoiFBrseiA8VddtNyoa0qlXQQgdnUYhPMmuA+ouIQEwGgsqkIMdTs+8XyPzilwAvXThy Cev5p2Fkn5ae9t7m/patq1XSrUculfyd+0OBbYI0+5B5aQzo4noXHGDD4ZT4FTRfgimF aZj9FC+nxf2fKi4s6+DPkJnp+ojbqt9Y20HJOcLtrg7TpHKhbu7CMvY6K2AImvS5KHgq /AP1xBuHQiD0aYYGxsWGh6jKicKKfqUjNKdXEq0Y5jf8Qw9C/lsN9oeIS5lh6pvXyp9z Gdrw== X-Gm-Message-State: AGRZ1gIMpy6R4xPtx48+Ynho7DVBRJk0EUOhFnm6MY5oN6wtSDKN4fmD sxvlkh//kC3UpK2GvE7GN8KTvJoS X-Google-Smtp-Source: AJdET5fcXZ1fJdEDVsoUjtesD79InlOFfz4XpzPfthyWtuv5vKXa0tT+fZAYornZm8vApsOqayTxbw== X-Received: by 2002:a1c:ee89:: with SMTP id j9-v6mr5738485wmi.58.1541418686454; Mon, 05 Nov 2018 03:51:26 -0800 (PST) Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id b5-v6sm28298888wrs.34.2018.11.05.03.51.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 03:51:25 -0800 (PST) To: Harald Alvestrand Cc: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , RTCWeb IETF References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> From: Sergio Garcia Murillo Message-ID: Date: Mon, 5 Nov 2018 12:54:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> Content-Type: multipart/alternative; boundary="------------A8B0A9CD2D2B4204A3C133E8" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 11:51:30 -0000 This is a multi-part message in MIME format. --------------A8B0A9CD2D2B4204A3C133E8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 05/11/2018 12:45, Harald Alvestrand wrote: >> I am not talking about replacing a transceiver but adding a new one >> and renegotiate. The initial O/A will drop the simulcast attribute on >> the answer and create a recvonly transceiver, and then create a new >> transceiver with simulcast encoding that will require a O/A. > OK, so we have the same picture in mind of what will happen in your > proposal. We end up with an useless transceiver and a new transceiver > that is suggested by the browser end, in a new media section; it's > impossible to use the media section that the (initiating) server proposed. It will not be useless, just recvonly. Many of the SFU devs that I know (including myself) plan to use sendonly/recvonly transceivers anyway to avoid having to match transceivers for incoming and outgoing tracks. Best regards Sergio --------------A8B0A9CD2D2B4204A3C133E8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 05/11/2018 12:45, Harald Alvestrand wrote:
I am not talking about replacing a transceiver but adding a new one
and renegotiate. The initial O/A will drop the simulcast attribute on
the answer and create a recvonly transceiver, and then create a new
transceiver with simulcast encoding that will require a O/A.

OK, so we have the same picture in mind of what will happen in your
proposal. We end up with an useless transceiver and a new transceiver
that is suggested by the browser end, in a new media section; it's
impossible to use the media section that the (initiating) server proposed.

It will not be useless, just recvonly. Many of the SFU devs that I know (including myself) plan to use sendonly/recvonly transceivers anyway to avoid having to match transceivers for incoming and outgoing tracks.

Best regards

Sergio

--------------A8B0A9CD2D2B4204A3C133E8-- From nobody Mon Nov 5 04:06:21 2018 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 57F48128CFD for ; Mon, 5 Nov 2018 04:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilW8LJqpV0U7 for ; Mon, 5 Nov 2018 04:06:16 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 C14171277CC for ; Mon, 5 Nov 2018 04:06:16 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id y27so3099847vsi.1 for ; Mon, 05 Nov 2018 04:06:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Tluvj3eR/4eFIal7my+hdNLELT/Glw7xEhyBFqAvy7M=; b=gTLd9X1wbWiyk9TwjYDh9524+zFwLSaBCr7eQre3IVjwxBNGmkB1QUetTriF9zh1gJ jB1uvhLaKmdBjQwyFpuwkA2RvI+e3tpKYk0jM4iETI2dJ/E+MZrKak7kMeHqLkdKBNuE 6VlodAcCS9rr8pyoJnvoyAIr2W9/hU6o8ZKvPdV6AMqfrM/dSrQXmh1dvp+K9Bv7g1Ao SaLk84PsPRehzJDwCBn9jDCGUvN4L3UMufgJHFeB8GwGkEz30eAgjewATL9u0j2bG7dh 4jRiWUwRh5UIqiMf8D1b3kDYKgW4cSlAzybTG8vxpzylwn3EYJmzMMYY+Zl3cD+r6bcB 5GEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Tluvj3eR/4eFIal7my+hdNLELT/Glw7xEhyBFqAvy7M=; b=Enpg8Ymn041+f+S89Qhom65njXcfBGHV4F4hf/5bOj8QJSGBBntMXgdtrMVgLUxkqj iaCx/g0meXtEGMxdtjUuOwZ04VTAWy8H5IDtHkXLDBCWp1GT5EuG8JN1Y6FIVD49NwEN wf6k0EfZeGfcj3RNff9PAh7ZBA306UflrtmiOkTg8MZTxyDohBwLNix764X0985TLQrm oo7TVpNA8LIptu1m9dSTQRmygKNpcH7E1/onvZ8mxrlU615Yd4iUHxFRR6ByrqKyxOuG DPpxeF6aN5rKkevmhnfGWADi5Q5tQWKxUyytagUcCo/nVOdhc6eVIIBCIsCdKijX25aO e4bA== X-Gm-Message-State: AGRZ1gI+tO7S756G0133U0gR3XC+I/TVwJr9gCh+q4uu5hER6cELpy1k f0zmFx8GYg8GdQm+J5E6pxyao6/MAJZuCBP4XNVJ6oGC X-Google-Smtp-Source: AJdET5eVJ605KMr78UiJiOGrsylYv2RckVEJjFH7xpzpcG5w+mw6VOyADxxwrm8zlszNRKgOjEjwQ42KNS5k5sWeU1o= X-Received: by 2002:a67:3659:: with SMTP id d86mr9144872vsa.17.1541419575378; Mon, 05 Nov 2018 04:06:15 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 13:06:04 +0100 Message-ID: To: Harald Alvestrand Cc: sergio.garcia.murillo@gmail.com, rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 12:06:19 -0000 On Mon, 5 Nov 2018 at 03:57, Harald Alvestrand wrote= : > If the remote SDP indicates that the remote end is willing to receive 3 > simulcast layers, and the browser is able to send 3 simulcast layers, > how many simulcast encodings should be represented in the > sender.getParameters() returned after the negotiation completes - and > what are the implications of that? This is a very good point. Yes, even if we inspect receiver.getParameters() after pc.setRemoteDescription(offer), we'd just get the number of encodings wished by the remote, and having to correlate such a number with the local limit (do we have an API to know the local limit before calling sender.setParameters()?) would be an implementation and usage nightmare. --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 5 04:12:16 2018 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 B456E1277CC for ; Mon, 5 Nov 2018 04:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WWT0u5H4Npw for ; Mon, 5 Nov 2018 04:12:08 -0800 (PST) Received: from mail-vk1-xa41.google.com (mail-vk1-xa41.google.com [IPv6:2607:f8b0:4864:20::a41]) (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 C7296127133 for ; Mon, 5 Nov 2018 04:12:07 -0800 (PST) Received: by mail-vk1-xa41.google.com with SMTP id y14so1949832vkd.1 for ; Mon, 05 Nov 2018 04:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZYuUKrmrWMQ325PrXKeUWCGIv/ytiAdVGFfE3qa6BFQ=; b=Fdli9lvP0rIqaxX1OFUOBep9ToBNmVUr/hid/I6sYNQEPCKqGn7xI2gEvuSoFmAPSd lc3bpOoaAMEgY1JDjeeLhI1YOB13h0hi7UZOf8rj2SuE7fPWaBC56xKAho7/5svKABEt qxNMH1A1SN1o5Or5YOFe1Uh1/Qiwr4VQQ9wa1Zt2d/DF3AkCNGkS1EU8ugnc5jF4P5Yk BT5+dseA5U4aiHZ0Ugwg4AMzOcM9TYOCGj+PGZXA85Vl5DYC7Hdc/X2vrUY6tfwOzY14 9jDQo5F/xbBgmBjpz6Ye92DmQmwsMrYe9001eDwGjHppGMrneG30VLpHheH9sybpn2Ys RYwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZYuUKrmrWMQ325PrXKeUWCGIv/ytiAdVGFfE3qa6BFQ=; b=iHK4FSRJiIl8YHj41OA72QexcRPc4nSDYqyoagzOcwHFzXc+xFESnB8IY3Ko63wHOi 1Y+bWoY4ru9Fw86iX0NaZHKrGkOqdnb87BWIMVJ9o/3Kas2CnQXizXsBOjNz29vxuNgw lAlG0ihF1KcF9TgfRJcFELbJ2OYzvcVvgpT2Or9ii7xNXiD7xSTgKz6Hqk4Ty34sXMCw EMz0cqrppceqUL4gVbtonIjROD/BeKNKbPECD8bLZt0dEhUDeXLOGLuEDsDDrN1S8uFo yRCyXb3/nGvBpf2QNoLNDJmBPvEs6CD76C1StvoBJCxA+wp/UUcn3YylD75LTnHBEoqv CEIw== X-Gm-Message-State: AGRZ1gLUsjI6IHMNT/bf3VzFkoagA8vfDTJB3C4nMOKWkrl+D3sCp5Nn S/AY0dUVO+tsj432NhnOD4Vj2NF9HeYQdSpRcGYWODah X-Google-Smtp-Source: AJdET5cxBvDYY1CDeCbgfR+lRoSevgGqT4NytbLVyj99aqT3jOX/x3oKGo+0sRmpRf1kH9AziPtojoIb10KGRvOSHms= X-Received: by 2002:a1f:ed86:: with SMTP id l128mr9367912vkh.21.1541419926505; Mon, 05 Nov 2018 04:12:06 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> In-Reply-To: <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 13:11:55 +0100 Message-ID: To: Harald Alvestrand Cc: sergio.garcia.murillo@gmail.com, rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 12:12:15 -0000 On Mon, 5 Nov 2018 at 12:45, Harald Alvestrand wrote= : > > On 11/05/2018 10:03 AM, Sergio Garcia Murillo wrote: > > I am not talking about replacing a transceiver but adding a new one > > and renegotiate. The initial O/A will drop the simulcast attribute on > > the answer and create a recvonly transceiver, and then create a new > > transceiver with simulcast encoding that will require a O/A. > OK, so we have the same picture in mind of what will happen in your > proposal. We end up with an useless transceiver and a new transceiver > that is suggested by the browser end, in a new media section; it's > impossible to use the media section that the (initiating) server proposed= . > > That seems ugly. So: - receive a remote offer with a single m=3Dvideo section requesting local simulcast - reply with a=3Drecvonly (fxxx you, conference server) - reoffer with a new m=3Dvideo with "correlated" simulcast settings - have the conference server like that And... all this party instead of just telling the client (via custom messaging before it "joins" the conference) the desired simulcast settings? :) --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 5 04:14:38 2018 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 3B0EB1277CC for ; Mon, 5 Nov 2018 04:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LUHMW4x3Cm1 for ; Mon, 5 Nov 2018 04:14:36 -0800 (PST) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 205A1127133 for ; Mon, 5 Nov 2018 04:14:36 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id v205so4948935vsc.3 for ; Mon, 05 Nov 2018 04:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LYbD2wNPl+Q+kYR/HfalsOVG8oA1SakFwDryg4VmTRg=; b=r13IgTGNAGATRzNAiNypOeBNKxjIj4PdL1WxWladTQFjwF1oi1f4+bnPjlgtsrDPgv xe5xuwUZ+ce4YApIJpR4KbufUZc7Xs8D+flk4m9DLhQsnZUibYZj90COmUm1kP9EnvfE TUjGTTs+PNUeOQW5K9CRbgo6IdkpaMyxbBX+hzC5lYegaA6S6KO00w94e624HzlD6sAJ Qceaqh+M4ORd8hg5p9L17nk1VlxIw0DJMIeDb5Gmnd/blMPCxXXjwi+/zdppuxnEVLbt 9SRWo3DLGMS4JZTTKZ6DkYobVMlANX70XoBc2/Nry5CZJSWGNx1n+oXG0bVSTmiPD01i ZOxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LYbD2wNPl+Q+kYR/HfalsOVG8oA1SakFwDryg4VmTRg=; b=JMzFx9G9P44Xynwhvq83M9wk1pJc8XrZjjcrrU74JacmG0EWYfA+ToQlnybL9MomxO lqcVwuvNi83F8jXehbnIb8rTmZ6tVI2vNPSjp3YS6LRSBzenBziptoAKXxl/q0cYZyxj cIkAEjSKTGvsOLixuIAQFJbeT6Tl4SG0aA+qWXg5DPqPz7mPykbaHife3nZrxqa1IbsU gwICCa0G7QDNm36/CQUcpziRID/ON/XLsk5V7uXO+cUB9UDf0tDuUaJsvSj2cvjUypsq 4v4Adu7hOx0eSP9CdFQ6AmFO2JmAQK+pB243uWBm/ycS2SI7gxVPnr9OX6T3D3CI+HaD 0O/Q== X-Gm-Message-State: AGRZ1gLaNCOE6JcYPzkSgxoxXs7bRuj/NaHT02IfosqX8ZuXm/kDoVo/ jHUYXVJVAHYT5CG1h1WG92gbFYAWkSCe78ASc4lJFQ== X-Google-Smtp-Source: AJdET5cQ0BHGt1iIhv+WUmyduoTjtX+irU1F1NPpdmq033fBpA8E5YTJ87x/CI5wgBZj/I3lKLbZDnxxB1X5KunKtn8= X-Received: by 2002:a67:584:: with SMTP id 126mr9025025vsf.67.1541420074811; Mon, 05 Nov 2018 04:14:34 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <5FB0A50F-DAF3-47C4-A5F5-8DA20586C9E2@iii.ca> In-Reply-To: <5FB0A50F-DAF3-47C4-A5F5-8DA20586C9E2@iii.ca> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 13:14:23 +0100 Message-ID: To: Cullen Jennings Cc: Bernard Aboba , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 12:14:38 -0000 If you excluded the word "interop" from any rationale, life would be much better, specially here where such an interop: 1) does not exist 2) is not needed To be clear: No app in the world is or will be NEVER ready to enable simulcast auto-magically just because it eventually receives a different SDP offer from the remote. The app developers would already figured out different ways to enable simulcast that would just not allow such an auto-magic "upgrade". On Mon, 5 Nov 2018 at 06:16, Cullen Jennings wrote: > > > On Nov 5, 2018, at 5:52 AM, I=C3=B1aki Baz Castillo wrote= : > > Hi Bernard, before entering into implementation details, do you really > agree that the remote should be able to force the local peer what and > how to send media? > > > I agree with Bernard. > > It's not about force something to do something - the app can always do wh= atever it wants with offers and answers - it's about the local side being = able to interop with a changing remote side without having to worry about a= nything local. Every time the browsers add new features, it's pretty awesom= e if my application gets them without even worrying about them if there is = no need to worry about them. > > > --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 5 04:22:15 2018 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 93ADD1298C5 for ; Mon, 5 Nov 2018 04:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 aqBNjFQm-7bu for ; Mon, 5 Nov 2018 04:22:12 -0800 (PST) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 901CF127133 for ; Mon, 5 Nov 2018 04:22:11 -0800 (PST) Received: by mail-wm1-x32b.google.com with SMTP id f1-v6so6249250wmg.1 for ; Mon, 05 Nov 2018 04:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=z6tox9Dx8MxVwVfcdcEkUoivlUcsQtvANQwBtheUyUY=; b=OEnOhAKnISzy2+Z8bnd281XpyiWAX43EukvBXD/oqeZuRvGW3k6ToVGIWwrcSeprgj F7+SoXby3PJg+9pCHgRvYS9PqerD14G6gyLhdDe5L5aScSU6Y2gWhS0TWCw+mENiZZJY F5diAm2G5//b8D4xv0vde4b9frcJmD51ak3Y9EbNOYCLB1WFChhwv2RVQRTe9Dd5DNZh B3ol9Y5MFMjkLjreo7jfstysEkRRlrsLx8ZxT5wNBa/jwYD/JpUz6TnT41mn0ftKQnOb G3yQfiGxSvEs1Y4MEkMaRYK36S7vYx3ZlIt5SJYHKdPBdHHY4adHlxkYLBg4vUydeE/U 0xfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=z6tox9Dx8MxVwVfcdcEkUoivlUcsQtvANQwBtheUyUY=; b=fxOKjltKxiAXPy1ah8SyQvyMx2d/zZXMnLUejQgpDFjgNNWv/5xvx8GpWsh9DjHye+ 14qN7V785hGny1pE210OaN0IpN7ivBMIaEPYgmVWQq4wbyv1UA4y+XJy0GRHa7dXimiA 7enTTtZXGdrprKpvVHTTM4zlKkVmy4RzHoy5Iod1GjmdUkKbMVhNC2SdUAXy+phyQZ05 24S0n/htKTgsTS27/2blel8CueXDfsGZ7bZDXHTPZ5c8xDqrb+YDkkh5hOVu/e9e3EvC 88CYy5gm/3ljN4gxZgEYfYkn7j/21/t+zDB+w/0u7hlpv9IbyM2K/JaCLbJ6gI+tp9RA DQsw== X-Gm-Message-State: AGRZ1gLynXNJbdduNhQgMJ67Op/932lzFbRvscfbvo7jMXmMOYK8vol3 tXmAqTW0OUR53t7/b4Ic1wNmGee5 X-Google-Smtp-Source: AJdET5epr0nB0akerHwhqhM8JwwV4ks8UvAAvE6ZSnvmg9Es4dFE0VxYRHM2HNEtfJsk2VCZoNsDzQ== X-Received: by 2002:a1c:60c2:: with SMTP id u185-v6mr5908675wmb.80.1541420529896; Mon, 05 Nov 2018 04:22:09 -0800 (PST) Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id t14-v6sm33591468wra.63.2018.11.05.04.22.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 04:22:09 -0800 (PST) To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , Harald Alvestrand Cc: rtcweb@ietf.org References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> From: Sergio Garcia Murillo Message-ID: <7b85f46f-782b-de88-3598-70d9613f9981@gmail.com> Date: Mon, 5 Nov 2018 13:25:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 12:22:14 -0000 On 05/11/2018 13:11, Iñaki Baz Castillo wrote: > On Mon, 5 Nov 2018 at 12:45, Harald Alvestrand wrote: >> On 11/05/2018 10:03 AM, Sergio Garcia Murillo wrote: >>> I am not talking about replacing a transceiver but adding a new one >>> and renegotiate. The initial O/A will drop the simulcast attribute on >>> the answer and create a recvonly transceiver, and then create a new >>> transceiver with simulcast encoding that will require a O/A. >> OK, so we have the same picture in mind of what will happen in your >> proposal. We end up with an useless transceiver and a new transceiver >> that is suggested by the browser end, in a new media section; it's >> impossible to use the media section that the (initiating) server proposed. >> >> That seems ugly. > So: > > - receive a remote offer with a single m=video section requesting > local simulcast > - reply with a=recvonly (fxxx you, conference server) > - reoffer with a new m=video with "correlated" simulcast settings > - have the conference server like that > > And... all this party instead of just telling the client (via custom > messaging before it "joins" the conference) the desired simulcast > settings? :) > Not sure if you are responding to  Harald or to me.  If it is to me, my "do nothing" proposal to enable simulcast when the offer is sent by the SFU (just in case anyone wants to do it): -SFU sends an offer with all the available streams/tracks (no simulcast m-line) -Browser reply with recvonly on all m-lines -Browsers reoffer with an additional m-line (sendonly?) with simulcast -SFU answers No change to the spec at the cost of an additional round trip. Note that this is almost the same case than if the browser sends and initial offer with simulcast, sfu answers with recvonly, and then re-offers with all the available streams/track. Also, note that many of SFU devs (at minimum Iñaki and me)  are not even sending SDP on the wire but doing renegotiations locally. Best regards Sergio From nobody Mon Nov 5 04:28:53 2018 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 86A19128CFD for ; Mon, 5 Nov 2018 04:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLNJzr0YefCH for ; Mon, 5 Nov 2018 04:28:49 -0800 (PST) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 A8AE9127133 for ; Mon, 5 Nov 2018 04:28:49 -0800 (PST) Received: by mail-ua1-x934.google.com with SMTP id d8so3093212ual.2 for ; Mon, 05 Nov 2018 04:28:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2IzskHWnASkK6Y5ubLtMLXu8gCQ6Bfml0nSL5mTSMI8=; b=up3qMSdjnSPQv/H7oPEdExygfF1jtjsWoBnLOxBJw2XwplBpOO2+z7G9uL9wVO/g8O yv6KwOZiKthE/QoRQ3DFVMDcgLOZXgqCPdbOeofHGYfEP5LznKMHlv79BVsEeHJa9pgz A6vEBbmQnA6FA55FNMQSqTAPbvOOG2zREhH7x/wsaQXRf1+nx6uSuq7DZUbcW8UDi3W4 ZyblWA/IXgeD7gtXxoA7Asrkx2NHg+HgD0r5/orIFBbjuUQAmLl1LbIOBoCgOblwDPfQ JjCsdq+qpTACcu3FzR24veZ55aKoisTUr9YWUx3X1ivoWi3Zt5Tg7SjYVXUMdik/ddMJ e1mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2IzskHWnASkK6Y5ubLtMLXu8gCQ6Bfml0nSL5mTSMI8=; b=JSPWt+40fCYCKtAUeM+C0ir5oFefeJS5y95i+wR4l2yNCug18cYV3luCEogxc3FDHm t1yBhk/vBB+ZvDMnTxwMFL0GdRH8mEPFoA+tLMd7LCh6+luts1Ji1WonSGrmtIBEgm2C c+4d+UUDURP8/rYTZFXE5TbUFN1TyyQeovN1t7e7quPUg/vAUnYPnjW0Qala+2dA9vnH hJa6f7f4u/VasK6jSSRokhZNjhWR9vK2hF8IFTAheZhpBRcoo3TgEJIRfu3Dauhfrvv9 zsdukIWvpkAVuFRTfJI4xEIKf9HhLWJNREVescSCENzAXh7pSWIe6LsEl+4jsXQNbknb Gedg== X-Gm-Message-State: AGRZ1gJiPKQoK+dc7e8nsX+yzc3IawXpnXJ6PIo3c+1lD4HfzQiOOYVa 8mWj4aoj8Pw1bUtbUs4f8SEvW1sCI83rmnpvbH9j6w== X-Google-Smtp-Source: AJdET5dG3KM7F/9mSFnNnkwlZbjhqUEvE931K4vWzf/TtNtufhbDaY1XJgVTvURjRBkN1f/E7W+J+Mi4QDkiDedc4T0= X-Received: by 2002:ab0:2519:: with SMTP id j25mr7559434uan.68.1541420928599; Mon, 05 Nov 2018 04:28:48 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> <7b85f46f-782b-de88-3598-70d9613f9981@gmail.com> In-Reply-To: <7b85f46f-782b-de88-3598-70d9613f9981@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 13:28:30 +0100 Message-ID: To: sergio.garcia.murillo@gmail.com Cc: Harald Alvestrand , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 12:28:52 -0000 On Mon, 5 Nov 2018 at 13:22, Sergio Garcia Murillo wrote: > Not sure if you are responding to Harald or to me. If it is to me, my > "do nothing" proposal to enable simulcast when the offer is sent by the > SFU (just in case anyone wants to do it): > > -SFU sends an offer with all the available streams/tracks (no simulcast > m-line) > -Browser reply with recvonly on all m-lines > -Browsers reoffer with an additional m-line (sendonly?) with simulcast > -SFU answers > > No change to the spec at the cost of an additional round trip. Note that > this is almost the same case than if the browser sends and initial offer > with simulcast, sfu answers with recvonly, and then re-offers with all > the available streams/track. > > Also, note that many of SFU devs (at minimum I=C3=B1aki and me) are not = even > sending SDP on the wire but doing renegotiations locally. Ok, let me clarify: Of course your approach would work, and also mine (signal server desired recv simulcast by other means but SDP before the client joins), but I strongly believe that people wishing to enable simulcast in clients by just receiving an offer from the server is because they have a fixed architecture in which the server sends the offer, expect a "full featured" answer and that's all. Probably their servers do not allow receiving reoffers from clients (you know the pain of managing both send and recv streams within a single m=3D section when you want to control sending/receiving codecs, etc). --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 5 05:03:53 2018 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 9835E1298C5 for ; Mon, 5 Nov 2018 05:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 1SRCOj23JCjM for ; Mon, 5 Nov 2018 05:03:50 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 52A17129C6A for ; Mon, 5 Nov 2018 05:03:50 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id p2-v6so7956906wmc.2 for ; Mon, 05 Nov 2018 05:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=iTkQ6Jb4WrLeAgUr+Vf/sozFeJu+MQffDjogyjmLZS8=; b=vBe+pcZvtt10rab86l6xfCZvz7ySsWKAX4q2exIFJ+6jJcUJUpKZGMy4hlINSV0Obl CyqJGjiTZhdebm9flhMXmI/Zix+4Y273zMLBIM8TsSp6gmiyi5/XWcfe5Lzs9q6HNKgs w2ZdezkJgfzB5fCHihoNgbwNVuAnZqzB85oswPJ8i9c8WR4SYua7lNcUXmurK9Wz7VhK p9tLUAdZwnG1Cuu1bCditee5fQ/JJHqqGN+lBUfzjkEONvY2Cf+B2aTDsMetQjVq+PvC dpIehhxxxoxsweajjK80+RE1FczU+IVB+ZANoc9m/D0zMYsBkqPBV6M0fWkF8/zoE1Pz CDJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=iTkQ6Jb4WrLeAgUr+Vf/sozFeJu+MQffDjogyjmLZS8=; b=EtXN7ykjL/irAfkwr83u6yGoVeaOPPBaLjxs9iX6OyM13xFzRehiG1q9rPLmosKd4b VACZHMblSXqVa4Mmy3ZMgH+FpUmU2xZq6ZzyIhQTd9umSK851yKzCt8USzjdywI4m4yL 62gut7tFGXCk17+pX2v5+/cZu2KTOVzmwDBZUPoK/5OuJyxVNJ8MS0B/8DMLYGynDs3o ZhsQr4u9XLVGXT5hlp9TwQV+WXiNBdgXEzplguc/HcQbRuP9hTBIHTXf56z++aUuq3KK pT9w9Ino9t6HTgeJ095lm05+oMwGUXHlIRlmsn7XXCM4PzkQ25ppuOrd83Neo+zJ11RN uEPQ== X-Gm-Message-State: AGRZ1gJxZyWXuBpL4It0RQ9BpzP6xVDCUa++YH6zjYryWiHzxqIqTDeB igFsClMoO2qasJRvtt2hlb3rhWgC X-Google-Smtp-Source: AJdET5eU4clxScarTq9rfWfrPC/kxBg0woeu8KQdzLCYbxLWh6FVnuGMeaSVjpsU+5SrljzzapEFmA== X-Received: by 2002:a1c:7d8e:: with SMTP id y136-v6mr6057522wmc.140.1541423028596; Mon, 05 Nov 2018 05:03:48 -0800 (PST) Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id y2-v6sm6849158wrh.53.2018.11.05.05.03.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 05:03:47 -0800 (PST) To: Harald Alvestrand Cc: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , RTCWeb IETF References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> From: Sergio Garcia Murillo Message-ID: Date: Mon, 5 Nov 2018 14:07:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 13:03:53 -0000 On 05/11/2018 12:45, Harald Alvestrand wrote: > I do fear that simulcast will continue to affect parts of the spec that > we don't expect it to. But we don't have the luxury of specifying it > halfway; either we rip it out altogether, or we specify it in enough > detail for interoperable implementation. I agree to that. If we are able to find an "easy" (i.e. not introducing too many changes) I would not have any issues adding support to that. Something like: - Browser adds a track via addTrack - Browser call SRD with a recv simulcast m-line offer - The transceiver is created with one send encoding per rid offered by the SFU with default values and all send encodings except first one with active=false (this would be the only required change) ----- browser encodes/sends a single rtp stream, same as if the remote offer was a non simulcast stream-- -Browser calls sender.getParameters(), modifies the desired send encoding parameters ( scaleResolutionDownBy,  maxFramerate, maxBitrate, etc) and enables them by setting active=true Would this approach fulfill the requirements? Best regards Sergio From nobody Mon Nov 5 05:14:56 2018 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 D525D129C6A for ; Mon, 5 Nov 2018 05:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxN_7L0hLYFn for ; Mon, 5 Nov 2018 05:14:53 -0800 (PST) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 CF5EA12426A for ; Mon, 5 Nov 2018 05:14:52 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id s9so5034619vsk.7 for ; Mon, 05 Nov 2018 05:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sZno3Ge1xzbHnnD6YLbbB6oOfTYeIB2f/iwZvDNOY94=; b=Ev1hl6aCx0rzvu6tAgZhfL11gClGLKy0BAInYytMNSlbrvIuGCjh7ueGhQ/dUlE2y6 vySQSQrbxaK0PDBAqkDyP2/XB1WpZ3PncBkU2Kr8L3XWip+qaa7w6C5pL9HbPld/Y7+n 4uPpsoALmzqoah0WEwKuq7RjQtUFnzih2TSQGg/C6rtovZcMfNOUGaT+57VzUshCZQTm L2Ra+XgL0F/9BC5uMl04uWNQd7Z7a73XLzjCzsVA7n6Zf2Xp91kjsK3DrZOQuShh6LDR 9Dumq3jjw9vWPZZ0Cif7xutOo1VI8bIVnXRn85WF8p7rJ34mgGL671zCpivFpRFwPdOh KqEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sZno3Ge1xzbHnnD6YLbbB6oOfTYeIB2f/iwZvDNOY94=; b=q5eRlwptabc/X/cCY+sq4vaRU38BAyakpcWEDGyRh0B0jXwhJ+/pSSWLb4lSkTqE5f OgewVQWjIPXzR7K8x010rxv7tcxlS7A0MAupx625o+TcIugmJPd29vC/Orlhsl6bfcrM ibTGymmZPoZpYcR4nUsSUcFTy7GUZpZ5kaLuGWUnUI8yQ4G2cjdS2/5t8Kzcl+/4U/rP ZaDcAyfLwdGViL1ulRlLnr1JEC/BkNb8+RdAxPbs+NSEI5rPLhsGzU4dU9CZwbtSihxg U9u6tNoCEX5k7teYcPvJ6Kb3mmmdaYdXeI5nfN6/V5C5uDbQycXBo3Le0qSz5r4YKjma Ouow== X-Gm-Message-State: AGRZ1gJWofepDM8p+PLqoD2uhDDj6Zh+bjFF3c/OZ4fRHznJTfENO+O7 xA57HJlij/J18YzWimFS1fmb70RTX1hkBnc5mYgy6Q== X-Google-Smtp-Source: AJdET5e3qHV1c38QO9IOkr29XxX5cFugUzwo4gn+LL6/HemrqYHvFzvCHrwQ+6Z4kL13KKV7jRdKHfIaD8uys1kKDIU= X-Received: by 2002:a67:3edc:: with SMTP id a89mr5043109vsi.136.1541423691486; Mon, 05 Nov 2018 05:14:51 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 14:14:39 +0100 Message-ID: To: Sergio Garcia Murillo Cc: Harald Alvestrand , rtcweb@ietf.org Content-Type: multipart/alternative; boundary="000000000000946aad0579eaab7f" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 13:14:55 -0000 --000000000000946aad0579eaab7f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As Harlad said before, sender.getParameters() should not return more times than the number of encodings the browser supports, so of the remote offer has more than those, we have an API problem. El lun., 5 nov. 2018 14:03, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> escribi=C3=B3: > On 05/11/2018 12:45, Harald Alvestrand wrote: > > I do fear that simulcast will continue to affect parts of the spec that > > we don't expect it to. But we don't have the luxury of specifying it > > halfway; either we rip it out altogether, or we specify it in enough > > detail for interoperable implementation. > > I agree to that. If we are able to find an "easy" (i.e. not introducing > too many changes) I would not have any issues adding support to that. > > Something like: > > - Browser adds a track via addTrack > > - Browser call SRD with a recv simulcast m-line offer > > - The transceiver is created with one send encoding per rid offered by > the SFU with default values and all send encodings except first one with > active=3Dfalse (this would be the only required change) > > ----- browser encodes/sends a single rtp stream, same as if the remote > offer was a non simulcast stream-- > > -Browser calls sender.getParameters(), modifies the desired send > encoding parameters ( scaleResolutionDownBy, maxFramerate, maxBitrate, > etc) and enables them by setting active=3Dtrue > > Would this approach fulfill the requirements? > > Best regards > > Sergio > > > --000000000000946aad0579eaab7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As Harlad said before, sender.getParameters() should not = return more times than the number of encodings the browser supports, so of = the remote offer has more than those, we have an API problem.

El lun., 5 nov. 2018 14:03, Sergio = Garcia Murillo <sergi= o.garcia.murillo@gmail.com> escribi=C3=B3:
On 05/11/2018 12:45, Harald Alvestrand wrote:
> I do fear that simulcast will continue to affect parts of the spec tha= t
> we don't expect it to. But we don't have the luxury of specify= ing it
> halfway; either we rip it out altogether, or we specify it in enough > detail for interoperable implementation.

I agree to that. If we are able to find an "easy" (i.e. not intro= ducing
too many changes) I would not have any issues adding support to that.

Something like:

- Browser adds a track via addTrack

- Browser call SRD with a recv simulcast m-line offer

- The transceiver is created with one send encoding per rid offered by
the SFU with default values and all send encodings except first one with active=3Dfalse (this would be the only required change)

----- browser encodes/sends a single rtp stream, same as if the remote
offer was a non simulcast stream--

-Browser calls sender.getParameters(), modifies the desired send
encoding parameters ( scaleResolutionDownBy,=C2=A0 maxFramerate, maxBitrate= ,
etc) and enables them by setting active=3Dtrue

Would this approach fulfill the requirements?

Best regards

Sergio


--000000000000946aad0579eaab7f-- From nobody Mon Nov 5 05:17:22 2018 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 7F27712F1A2 for ; Mon, 5 Nov 2018 05:17:21 -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 w-lwkDqmmued for ; Mon, 5 Nov 2018 05:17:18 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 41F81129C6A for ; Mon, 5 Nov 2018 05:17:18 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id z16-v6so9506413wrv.2 for ; Mon, 05 Nov 2018 05:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8vbM3KJvrCLoJ3aqAyMWfYitINjf/iLDvuRCsZ8wG8o=; b=F3jLLqMoMRj5uNqIUkdoCvPmxvPZx7Qu2Qoxmo9b9CnZ86xGl2NJXatHBg+0RVe63e NnTUu/p1oSL3LBXd/slqsBiFfVcbOYukYdeMjZuEuUBd5QbgTrNb+t1I3rZ+lHUrO8gd S57Ak7klLCjgzfYEgFKlglODxZ9EpiC0aUcwcKBsUNCZCKHQ65XU7weB+Objd+TCkHTw TWX08yCP3n43ARRDvx92wyIPY0c7AhKmvnlYtfMD0oQ57udP5Oh+2uRU3EEb5aWidfXT QIDlTm9ONCHo4Ze6nJcB3OiC1zO7ZQzSfk7rB6HA/FSckmNYh56xr9yWcq7sQ3iYI3um o1IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8vbM3KJvrCLoJ3aqAyMWfYitINjf/iLDvuRCsZ8wG8o=; b=Ea/UJAUtz5QFocuphkj3HyII8OBooVdrtHiUQ6Kw3Fi+JcLboVl6FDArJPyLIikun7 gW6MrQFIBv8yjOwhrLL2XNu0+872+0fDmDbIJbL7sYw4Lw7niKN1/amBKd7zVZga2h7F G9FjbJLyiiBN2iFjSuQtU9IeJ9QB5oaveAQGwX3rZ7UOcO88Y702qWDo3Qn2nQOL7trh 1ng/jDPv5uYVUO9iSM9vNA4q1wVq+1B63CWoFc5rDdy8cmPVu4EWrUdGR6Xm7su39JUQ eexa9i9QvK5GBbTh1ez5sXLDdsAal/K9hW4dPd9IgXcngO3WbUVMHe8JqYDHyeCws9wO wzlQ== X-Gm-Message-State: AGRZ1gLs3uPfzKqQsT5xa/KwHWeFX3UanKpOl31jxYbGK/5EEmkzB8/7 f5d+TgtlROB81E8EUUKUSbYLTS0eLlqHtgPGQgfXQw== X-Google-Smtp-Source: AJdET5dnfup5u4q1s11wZBzOXoSDayQVAgqjk4MYC87TVlpECQNEgnlKnT59uUC/jlvD7ySqm7EWdDVXFymx4y7d0M4= X-Received: by 2002:adf:e14b:: with SMTP id f11-v6mr18690748wri.42.1541423836672; Mon, 05 Nov 2018 05:17:16 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> In-Reply-To: From: Sergio Garcia Murillo Date: Mon, 5 Nov 2018 14:17:04 +0100 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Harald Alvestrand , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000003bb6f60579eab4ec" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 13:17:21 -0000 --0000000000003bb6f60579eab4ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable if remote offer has more rids than what the browser support then the m line should be rejected. El lun., 5 nov. 2018 14:14, I=C3=B1aki Baz Castillo escribi= =C3=B3: > As Harlad said before, sender.getParameters() should not return more time= s > than the number of encodings the browser supports, so of the remote offer > has more than those, we have an API problem. > > El lun., 5 nov. 2018 14:03, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> escribi=C3=B3: > >> On 05/11/2018 12:45, Harald Alvestrand wrote: >> > I do fear that simulcast will continue to affect parts of the spec tha= t >> > we don't expect it to. But we don't have the luxury of specifying it >> > halfway; either we rip it out altogether, or we specify it in enough >> > detail for interoperable implementation. >> >> I agree to that. If we are able to find an "easy" (i.e. not introducing >> too many changes) I would not have any issues adding support to that. >> >> Something like: >> >> - Browser adds a track via addTrack >> >> - Browser call SRD with a recv simulcast m-line offer >> >> - The transceiver is created with one send encoding per rid offered by >> the SFU with default values and all send encodings except first one with >> active=3Dfalse (this would be the only required change) >> >> ----- browser encodes/sends a single rtp stream, same as if the remote >> offer was a non simulcast stream-- >> >> -Browser calls sender.getParameters(), modifies the desired send >> encoding parameters ( scaleResolutionDownBy, maxFramerate, maxBitrate, >> etc) and enables them by setting active=3Dtrue >> >> Would this approach fulfill the requirements? >> >> Best regards >> >> Sergio >> >> >> --0000000000003bb6f60579eab4ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
if remote offer has more rids than what the browser suppo= rt then the m line should be rejected.=C2=A0


El lun., 5 nov. 2018 14:= 14, I=C3=B1aki Baz Castillo <ibc@aliax.= net> escribi=C3=B3:
As Harlad said before, sender.getParameters() should not return m= ore times than the number of encodings the browser supports, so of the remo= te offer has more than those, we have an API problem.

El lun., 5 nov. 2018 14:03, Sergio Garcia= Murillo <sergio.garcia.murillo@gmail.com> escribi= =C3=B3:
On 05/11/2018 12:45, Harald= Alvestrand wrote:
> I do fear that simulcast will continue to affect parts of the spec tha= t
> we don't expect it to. But we don't have the luxury of specify= ing it
> halfway; either we rip it out altogether, or we specify it in enough > detail for interoperable implementation.

I agree to that. If we are able to find an "easy" (i.e. not intro= ducing
too many changes) I would not have any issues adding support to that.

Something like:

- Browser adds a track via addTrack

- Browser call SRD with a recv simulcast m-line offer

- The transceiver is created with one send encoding per rid offered by
the SFU with default values and all send encodings except first one with active=3Dfalse (this would be the only required change)

----- browser encodes/sends a single rtp stream, same as if the remote
offer was a non simulcast stream--

-Browser calls sender.getParameters(), modifies the desired send
encoding parameters ( scaleResolutionDownBy,=C2=A0 maxFramerate, maxBitrate= ,
etc) and enables them by setting active=3Dtrue

Would this approach fulfill the requirements?

Best regards

Sergio


--0000000000003bb6f60579eab4ec-- From nobody Mon Nov 5 05:23:14 2018 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 CA93612D4E8 for ; Mon, 5 Nov 2018 05:23:11 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_8NItsVC7SB for ; Mon, 5 Nov 2018 05:23:07 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 99EBC1298C5 for ; Mon, 5 Nov 2018 05:23:07 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id v205so5068403vsc.3 for ; Mon, 05 Nov 2018 05:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vToioPivPVy7pVCRzQzSH/SnlPp3R3gwi6APhSPUrZM=; b=QazsxnMSEQdUhz4cPsXoi/lB6ZfwBSzYbwOZEz4TIuONkTTAWlkfzSljf06sbhqC// 8MDIa64CcWQ/rTNor7u8yUJyfq/Rv8RClIoDAaSDMb8jqeVGVrouw/gHWIxdqkGp0vcr heUJUvsNV8AvWb+AmVuUQQbUAM+jTsYAiziiLJFADjWe2noreI3Vkf1anuJQx88W/Gqg 37TbIv5YtjiOgz7b8MgrHtrbW98tgeObFHkg6y/v1aSJi7+pysn2jjIOHWsZYBx6g5oe CRICkdCPdYzdMrovLqd5YtDWp72hsdGDVfGxPXScpuQhfmIXDpcz3hMsD9w3VpIcHKaw S0sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vToioPivPVy7pVCRzQzSH/SnlPp3R3gwi6APhSPUrZM=; b=PqQUiQ/iA0j6sj7gApMzFDVpR05bgHqLDNpndBhf2dV+Mby57OSf55PVw00IJ2fNSl XsSUk029fwBtJc4+dU59T+BVLDZqGPnIWMj36IeaA/P81DKq/1UKdU2FypF72UDm9MJR omO6MAoo7H6oMxvDK4BzWIgyC7d6U2/kVqYqv4e/39u4TmzurojJRWoLP4NqjVYUuqe0 RS4bSvvPYSYkxBK2xFWdyUwtc5cauDyud5QKbTt59y8sLBN0HK8zZ7Zr37jPJgHnm+H8 +yL5xrZA8ijhxnhnM5sxdoS/f4E7/4QnXgdfu7/6wIAbF1QQT60A4hBqsf3HWbmRzfJ0 2NnA== X-Gm-Message-State: AGRZ1gIghnHycz3Zpg2Rg3hTwBF8RV1/CRAg/MdO37O9ZltBoPbIFnV6 vsk6lconWAMH7nEhG+/W2AmKbey8SvdJW2S82WIRI0QY X-Google-Smtp-Source: AJdET5fydruL3/6G591khDiMf0FBFbbDjIgeUJx34kgLPzjiVVSmM4YHvfpywYTs4//CmLvfTfiHAOu1qoZAD6dQ/B0= X-Received: by 2002:a67:6346:: with SMTP id x67mr8993238vsb.114.1541424186323; Mon, 05 Nov 2018 05:23:06 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 14:22:54 +0100 Message-ID: To: Sergio Garcia Murillo Cc: Harald Alvestrand , rtcweb@ietf.org Content-Type: multipart/alternative; boundary="0000000000001311cf0579eac96f" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 13:23:12 -0000 --0000000000001311cf0579eac96f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable May be, but without knowing in advance the limit in different devices/browsers, how many rids do you expect those SFUs will place in the offer? It would be the "lowest common denominator" which would not satisfy to anyone. El lun., 5 nov. 2018 14:17, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> escribi=C3=B3: > if remote offer has more rids than what the browser support then the m > line should be rejected. > > > El lun., 5 nov. 2018 14:14, I=C3=B1aki Baz Castillo escri= bi=C3=B3: > >> As Harlad said before, sender.getParameters() should not return more >> times than the number of encodings the browser supports, so of the remot= e >> offer has more than those, we have an API problem. >> >> El lun., 5 nov. 2018 14:03, Sergio Garcia Murillo < >> sergio.garcia.murillo@gmail.com> escribi=C3=B3: >> >>> On 05/11/2018 12:45, Harald Alvestrand wrote: >>> > I do fear that simulcast will continue to affect parts of the spec th= at >>> > we don't expect it to. But we don't have the luxury of specifying it >>> > halfway; either we rip it out altogether, or we specify it in enough >>> > detail for interoperable implementation. >>> >>> I agree to that. If we are able to find an "easy" (i.e. not introducing >>> too many changes) I would not have any issues adding support to that. >>> >>> Something like: >>> >>> - Browser adds a track via addTrack >>> >>> - Browser call SRD with a recv simulcast m-line offer >>> >>> - The transceiver is created with one send encoding per rid offered by >>> the SFU with default values and all send encodings except first one wit= h >>> active=3Dfalse (this would be the only required change) >>> >>> ----- browser encodes/sends a single rtp stream, same as if the remote >>> offer was a non simulcast stream-- >>> >>> -Browser calls sender.getParameters(), modifies the desired send >>> encoding parameters ( scaleResolutionDownBy, maxFramerate, maxBitrate, >>> etc) and enables them by setting active=3Dtrue >>> >>> Would this approach fulfill the requirements? >>> >>> Best regards >>> >>> Sergio >>> >>> >>> --0000000000001311cf0579eac96f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
May be, but without knowing in advance the limit in diffe= rent devices/browsers, how many rids do you expect those SFUs will place in= the offer? It would be the "lowest common denominator" which wou= ld not satisfy to anyone.

El lun., 5 nov. 2018 14:17, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> e= scribi=C3=B3:
if = remote offer has more rids than what the browser support then the m line sh= ould be rejected.=C2=A0


El lun., 5 nov. 2018 14:14, I=C3=B1aki Baz Ca= stillo <ibc@aliax.net> escribi=C3=B3:
As Harlad said before, sender.getParameters() sho= uld not return more times than the number of encodings the browser supports= , so of the remote offer has more than those, we have an API problem.
=
El lun., 5 nov. 2018 14:03,= Sergio Garcia Murillo <sergio.garcia.murillo@gm= ail.com> escribi=C3=B3:
On 0= 5/11/2018 12:45, Harald Alvestrand wrote:
> I do fear that simulcast will continue to affect parts of the spec tha= t
> we don't expect it to. But we don't have the luxury of specify= ing it
> halfway; either we rip it out altogether, or we specify it in enough > detail for interoperable implementation.

I agree to that. If we are able to find an "easy" (i.e. not intro= ducing
too many changes) I would not have any issues adding support to that.

Something like:

- Browser adds a track via addTrack

- Browser call SRD with a recv simulcast m-line offer

- The transceiver is created with one send encoding per rid offered by
the SFU with default values and all send encodings except first one with active=3Dfalse (this would be the only required change)

----- browser encodes/sends a single rtp stream, same as if the remote
offer was a non simulcast stream--

-Browser calls sender.getParameters(), modifies the desired send
encoding parameters ( scaleResolutionDownBy,=C2=A0 maxFramerate, maxBitrate= ,
etc) and enables them by setting active=3Dtrue

Would this approach fulfill the requirements?

Best regards

Sergio


--0000000000001311cf0579eac96f-- From nobody Mon Nov 5 06:21:08 2018 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 32CC2128BCC for ; Mon, 5 Nov 2018 06:21:05 -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 4xNjScyCudyL for ; Mon, 5 Nov 2018 06:21:02 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 394DB12870E for ; Mon, 5 Nov 2018 06:21:02 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id k15-v6so6749928wre.12 for ; Mon, 05 Nov 2018 06:21:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=L7VEaAmcBK+S9PB3f80XvCfZ+acsqxceZ/IX2bNMvR8=; b=AevPncb/DpBVgW9I5U8GAXTYm183PK576miEBf7dkF/hWVX/M3YuEFxhBjxlMLAQ7+ b8Sui+B50GQDou3cUfSHPUYXz2qvMCTO6L/lBv4pbPYUxEteavpyu+AsEfUAazpBoNEF DvTj6gzsoWzBI1VxsdmMi2CNl5CN09a3IUQEvAbdi3nw83HyQWX/1HjQOIlaHkyy49pC zHigcqxJ+Dl4IqiqqXdko3mLofGdlNATwnS6izIT607UqRFehnPuOL+La7FqNjrYrwoF t9AUUwPc9NzCPNx7a5GyzLKMy/EJ9+s7vp+wEAXahjvLcI3cN2fPOADZnoIvhoOzWyS9 VzCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=L7VEaAmcBK+S9PB3f80XvCfZ+acsqxceZ/IX2bNMvR8=; b=aRb09OS9m1PhvHME09+UFS3pJw2WAJjW8iFFnJRgUMn1SyrFq8UVcwiMhq7iW1ZXYB wd7sWbKR6bF0l8dQi4hz7T8ldknD5xHuWp0uH3bofr0m6Bm3k6HtKHdYG97ZNZTeUctY ykLEWjiA501EIKzoS4mN60kDX84Lr3L6P1j9Y2vsVJW3NGiKb7tTHAlSqqibv4t6xv6r 3WA9xpQRikEjGExPdR2SY8mG32Ms9A5MlMq0gIPKsYbP0qfeYFcQaO5nS9B5o5AWBVT9 HUk5rBXsblJO/2alL6LqonxnZxYr2q/Z2kxp2fnCogwzTiCmYO6gUKoKi42uSqsAGlki kHEg== X-Gm-Message-State: AGRZ1gKimdfvR4qVPZTVCci9iayvDwzHj29jB+PnjLPYpLpWnbkYuGwP 9DuyWNb4kpSmQDa/HBl/7Wnv+SIR X-Google-Smtp-Source: AJdET5fctly2wPxfz0cESL5E1ECWfcpPEzaf2oogZoBnl+nmN+t2Zo3w1J4gOyt/1rMZBOnjKxGjZA== X-Received: by 2002:adf:a512:: with SMTP id i18-v6mr21197204wrb.220.1541427660472; Mon, 05 Nov 2018 06:21:00 -0800 (PST) Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id 65-v6sm10442936wmj.1.2018.11.05.06.20.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 06:20:59 -0800 (PST) To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= Cc: Harald Alvestrand , rtcweb@ietf.org References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> From: Sergio Garcia Murillo Message-ID: Date: Mon, 5 Nov 2018 15:24:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4B5EB36C994B21240CACF4A2" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 14:21:05 -0000 This is a multi-part message in MIME format. --------------4B5EB36C994B21240CACF4A2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit By the way, according to the simulcast draft that should not be a problem at all: An answerer that receives an offer with simulcast that lists a number of simulcast streams, MAY reduce the number of simulcast streams in the answer, but MUST NOT add simulcast streams. On 05/11/2018 14:22, Iñaki Baz Castillo wrote: > May be, but without knowing in advance the limit in different > devices/browsers, how many rids do you expect those SFUs will place in > the offer? It would be the "lowest common denominator" which would not > satisfy to anyone. > > El lun., 5 nov. 2018 14:17, Sergio Garcia Murillo > > escribió: > > if remote offer has more rids than what the browser support then > the m line should be rejected. > > > El lun., 5 nov. 2018 14:14, Iñaki Baz Castillo > escribió: > > As Harlad said before, sender.getParameters() should not > return more times than the number of encodings the browser > supports, so of the remote offer has more than those, we have > an API problem. > > El lun., 5 nov. 2018 14:03, Sergio Garcia Murillo > > escribió: > > On 05/11/2018 12:45, Harald Alvestrand wrote: > > I do fear that simulcast will continue to affect parts > of the spec that > > we don't expect it to. But we don't have the luxury of > specifying it > > halfway; either we rip it out altogether, or we specify > it in enough > > detail for interoperable implementation. > > I agree to that. If we are able to find an "easy" (i.e. > not introducing > too many changes) I would not have any issues adding > support to that. > > Something like: > > - Browser adds a track via addTrack > > - Browser call SRD with a recv simulcast m-line offer > > - The transceiver is created with one send encoding per > rid offered by > the SFU with default values and all send encodings except > first one with > active=false (this would be the only required change) > > ----- browser encodes/sends a single rtp stream, same as > if the remote > offer was a non simulcast stream-- > > -Browser calls sender.getParameters(), modifies the > desired send > encoding parameters ( scaleResolutionDownBy, maxFramerate, > maxBitrate, > etc) and enables them by setting active=true > > Would this approach fulfill the requirements? > > Best regards > > Sergio > > --------------4B5EB36C994B21240CACF4A2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
By the way, according to the simulcast draft that should not be a problem at all:

   An answerer that receives an offer with simulcast that lists a number
   of simulcast streams, MAY reduce the number of simulcast streams in
   the answer, but MUST NOT add simulcast streams.

On 05/11/2018 14:22, Iñaki Baz Castillo wrote:
May be, but without knowing in advance the limit in different devices/browsers, how many rids do you expect those SFUs will place in the offer? It would be the "lowest common denominator" which would not satisfy to anyone.

El lun., 5 nov. 2018 14:17, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> escribió:
if remote offer has more rids than what the browser support then the m line should be rejected. 


El lun., 5 nov. 2018 14:14, Iñaki Baz Castillo <ibc@aliax.net> escribió:
As Harlad said before, sender.getParameters() should not return more times than the number of encodings the browser supports, so of the remote offer has more than those, we have an API problem.

El lun., 5 nov. 2018 14:03, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> escribió:
On 05/11/2018 12:45, Harald Alvestrand wrote:
> I do fear that simulcast will continue to affect parts of the spec that
> we don't expect it to. But we don't have the luxury of specifying it
> halfway; either we rip it out altogether, or we specify it in enough
> detail for interoperable implementation.

I agree to that. If we are able to find an "easy" (i.e. not introducing
too many changes) I would not have any issues adding support to that.

Something like:

- Browser adds a track via addTrack

- Browser call SRD with a recv simulcast m-line offer

- The transceiver is created with one send encoding per rid offered by
the SFU with default values and all send encodings except first one with
active=false (this would be the only required change)

----- browser encodes/sends a single rtp stream, same as if the remote
offer was a non simulcast stream--

-Browser calls sender.getParameters(), modifies the desired send
encoding parameters ( scaleResolutionDownBy,  maxFramerate, maxBitrate,
etc) and enables them by setting active=true

Would this approach fulfill the requirements?

Best regards

Sergio



--------------4B5EB36C994B21240CACF4A2-- From nobody Mon Nov 5 06:33:42 2018 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 25CD9128BCC for ; Mon, 5 Nov 2018 06:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhpIyLZJMfat for ; Mon, 5 Nov 2018 06:33:39 -0800 (PST) Received: from mail-vk1-xa43.google.com (mail-vk1-xa43.google.com [IPv6:2607:f8b0:4864:20::a43]) (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 5EEA31277BB for ; Mon, 5 Nov 2018 06:33:39 -0800 (PST) Received: by mail-vk1-xa43.google.com with SMTP id l186so2057808vke.0 for ; Mon, 05 Nov 2018 06:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wCGSSi3EIAaH+QKaPTDH5kiDAWQPK+TvliOTUn9TxPI=; b=nPa6gk7qrhxxYdfEinckgboS9UcNdw3rLsiYW/mmI1aSuIEynGq5NJY9uTCv6WIWP6 VBuONOrbyG9jgOwmV++gcNba//NRTlNlYpDkClOSYMtQI45X56SemMIHOkuOwyEfQVXF FJMgyaIMAg8xSCXZwVkOPclB15z1OXvrjYsHnqbXc9Tyx0Oa+aVLvmY3NIJKRgbMJsnR o9cBwhgT4Vm9uLzahTGWVif3iwYcwxkvnd9VAlYd6fkqxp228UNh9DKBazBLGLOshbu4 fznq2KCzljXmNj4RLDLbbQwAOGfL1+oeqPKxuxly06ItP8bWIFtSb3wFKCwOwpxosN7J ecJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wCGSSi3EIAaH+QKaPTDH5kiDAWQPK+TvliOTUn9TxPI=; b=K++mguGjAlXS+VwqDhfL6DPjBDWoY+Iq7npfpquFJtksorBNoJMFflMfwIWU8MtgQR W1xRw5EirLysaW39/2oE7rmVg2HGApEgmQuezv3qvgKTDkoQ7ULCTSZ8mxXq6T1qhIGm Hmgk9e5alxewlu/gzV+rejBEpp6gmCEdn2+xYlQrcWrUsa26nPXqTqacGml1d5+sJ0t6 2ldn9tZnoonQuGFGruRhtYCQEUMQQPEko1gD+UCKvSnkpyFMkGVDCXjOzZOpUBvrAnxG ERSsHb1ajoRmF8HpTKCsv26H9phhcgIOaFEcTrkpafX3CDKgXDIl7+9oICaQVqneFpDV y9yA== X-Gm-Message-State: AGRZ1gKXESqPTWboBmbarBhL7xAwFXEt0eQOvaawNsVpOnU6DiLHVqKZ JhucxN+/lyxgYBubSuX24VcaowmWln3cUUb77HLNAw== X-Google-Smtp-Source: AJdET5fuUFvfntS/gm+gr6UtYmPzugtNnrYyd/tTxQuP/Z9wBOeWoBmASQxW0lbLSmbZOs2cqFn4rpMKJjP/KKZZ2cg= X-Received: by 2002:a1f:accf:: with SMTP id v198-v6mr9761892vke.3.1541428418083; Mon, 05 Nov 2018 06:33:38 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 15:33:26 +0100 Message-ID: To: Sergio Garcia Murillo Cc: Harald Alvestrand , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 14:33:41 -0000 On Mon, 5 Nov 2018 at 15:21, Sergio Garcia Murillo wrote: > > By the way, according to the simulcast draft that should not be a problem= at all: > > An answerer that receives an offer with simulcast that lists a number > of simulcast streams, MAY reduce the number of simulcast streams in > the answer, but MUST NOT add simulcast streams. Not sure if that also covers "recv" simulcast items in the offer. Probably yes, so ok. However still useless IMHO. Imagine an SFU that wants to receive, at least those bitrates (because somehow it knows that all devices can handle at least 3 simulcast streams): - 150kbps - 400kbps - 1000kbps Imagine there are also some devices supporting up to 5 streams, so the SFU produces this simulcast settings in the offer for receiving: - 150kbps - 120kbps - 400kbps - 750kbps - 1000kbps If a device that just supports 3 simulcast streams receives such an offer, it would discard 2. Which ones? ok, the SDP can include info about the desired max-bitrate per rid, and we may think: oh, we can get the list of rids and bitrates after pc.setRemoteDescription() by calling pc.getTransceivers()[1].receiver.getParameters().encodings, so the app can decide which ones to enable. But that's not true since receiver.getParameters() should not contain more rids than those supported by the device. Well, this constraint is really about sender.getParameters(). So you may say: ok we somehow read the maximum simulcast streams that our browser/device can send and then choose the appropriate ones from the receiver can call transceiver.sender.setParameters() with them.. Error! there is no API for knowing the max number of simulcast streams the browser can produce. Too many assumptions and non existing features in this text to make this scenario really possible. --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 5 09:24:15 2018 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 3A9A7130E5B for ; Mon, 5 Nov 2018 09:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF-cxSvURGs4 for ; Mon, 5 Nov 2018 09:24:04 -0800 (PST) Received: from mail-vk1-xa41.google.com (mail-vk1-xa41.google.com [IPv6:2607:f8b0:4864:20::a41]) (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 3BB81130E00 for ; Mon, 5 Nov 2018 09:24:04 -0800 (PST) Received: by mail-vk1-xa41.google.com with SMTP id u62so2203181vkb.3 for ; Mon, 05 Nov 2018 09:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+WVXoN7+NLA/EHLSUUFquJbKKkKJa+nGnfG27yHP5hk=; b=zQMWr7MwVN1mvVCggr2P0WrOUIVHRk7rf3FVyBSNzBAVzH7BY7GVBt4g4KA18Gyxkb 0IVQt7LJuuw6rX0hCM7ecu92vzMkxk4n8xD2zF4Sbo3tzgYclnmMqgxOWys7lMKDGKNC u7DRXpxp0V7pk9BER1tTYEXgmafTdKni+uaC2tRCvAxay0A77URNgj8jmcLazpyqc0B4 vzLEHE30Bx6Sf6DnaL3M9VcO3/jjcnbIA9G4CHR+ujDySBVL03uVelH3wJGOGHDXAUAT tcrlzPsghO11gXK31yXnHccI/WSnHvRk4pNetzvGrZgi6DUYBI6iSd66YBOMWss151EB kASw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+WVXoN7+NLA/EHLSUUFquJbKKkKJa+nGnfG27yHP5hk=; b=DzMK6dg7Kt3J7OqUHgIZzNCPMeWSAebIay9L8pfbgFauKAvQnuXlyuJHSKIcWhhiZD pkT/4P4xFlaxDw3OUE3qbxkZoo7MWxAHPrI58oBh0NUiFYRomj83h40scNL25yzVY3VA 2FSFiYZPjZA+xBNxzboQMJlQscqwLs7aypQACKDcqGPMW8JKJRcb81o2yahxIBDfhNy7 qU2E/6Tr2YxgzJ3VtN2kB00kMk+GWw4lSUu5MqqFa3Q5lJbdC9c6+JY5l31kW3kIjcoH OpeHqf9SNwElqoj/FOdc10bQNgAdf+hn35KQjl+MbAD8nm9ZiAMLmX10VnpFnryifGmy Fnpg== X-Gm-Message-State: AGRZ1gImveb+hfZPIPmS/89dTcvFoNs3A1mgNaorSG4YIFkJQm3+hCDS oCIJEijgGcmCd4KH4VrNsMlLW3GSPFpIKqMqYyefCI2b X-Google-Smtp-Source: AJdET5flxhlBQHrCBrlsbrmPvK4BHOpHTbL5bM9jl27VvFe47rng/fcmbLbcyqYZqSPjiRsOxopIWfCg8Vn5UZuL6zU= X-Received: by 2002:a1f:accf:: with SMTP id v198-v6mr10047785vke.3.1541438642948; Mon, 05 Nov 2018 09:24:02 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 18:23:50 +0100 Message-ID: To: Sergio Garcia Murillo Cc: Harald Alvestrand , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 17:24:13 -0000 Please, forget my comment about transceiver.receiver.getParameters(), they are just wrong here. On Mon, 5 Nov 2018 at 15:33, I=C3=B1aki Baz Castillo wrote: > > On Mon, 5 Nov 2018 at 15:21, Sergio Garcia Murillo > wrote: > > > > By the way, according to the simulcast draft that should not be a probl= em at all: > > > > An answerer that receives an offer with simulcast that lists a numbe= r > > of simulcast streams, MAY reduce the number of simulcast streams in > > the answer, but MUST NOT add simulcast streams. > > Not sure if that also covers "recv" simulcast items in the offer. > Probably yes, so ok. > > However still useless IMHO. Imagine an SFU that wants to receive, at > least those bitrates (because somehow it knows that all devices can > handle at least 3 simulcast streams): > > - 150kbps > - 400kbps > - 1000kbps > > Imagine there are also some devices supporting up to 5 streams, so the > SFU produces this simulcast settings in the offer for receiving: > > - 150kbps > - 120kbps > - 400kbps > - 750kbps > - 1000kbps > > If a device that just supports 3 simulcast streams receives such an > offer, it would discard 2. Which ones? ok, the SDP can include info > about the desired max-bitrate per rid, and we may think: oh, we can > get the list of rids and bitrates after pc.setRemoteDescription() by > calling pc.getTransceivers()[1].receiver.getParameters().encodings, so > the app can decide which ones to enable. > > But that's not true since receiver.getParameters() should not contain > more rids than those supported by the device. Well, this constraint is > really about sender.getParameters(). So you may say: ok we somehow > read the maximum simulcast streams that our browser/device can send > and then choose the appropriate ones from the receiver can call > transceiver.sender.setParameters() with them.. Error! there is no API > for knowing the max number of simulcast streams the browser can > produce. > > Too many assumptions and non existing features in this text to make > this scenario really possible. > > -- > I=C3=B1aki Baz Castillo > --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 5 10:56:23 2018 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 52AFE130E09 for ; Mon, 5 Nov 2018 10:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 m47pSq5JTYHc for ; Mon, 5 Nov 2018 10:56:19 -0800 (PST) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 16E4B1294D7 for ; Mon, 5 Nov 2018 10:56:19 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id f1-v6so7050145wmg.1 for ; Mon, 05 Nov 2018 10:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TBQbV3Emr6ioXpt4EodO1vtF0fsx2RYtF0ndtxbk4gw=; b=mJ2gOWFz3dny2IgXbZ2RbtPncyk7MfM+pwkcTBBf7vc5pgSBzGCkwvAPSfRQpW3bwJ 3al0n140OWCZZaufalzYMzdVxCMJPm4o22gsndwBEh1HIWB5DRZGfFTg3nBLO5G6TK3w gPYnwmQs1568H3ermWi+1gHgCNCZCkFOyzjj0uZn+enASRkZ7E3mvDVY+LXDAsmjZKZU pFDoLcvlII9cupXtPN1nCPJ45ZCsQG40bM9exeVxcFqhQsapBAaOynlkRNyhZ2sW9PND oYxFJ/CnUA4xOs8jwOeRco7dgkWRs9bc9tge02GTFr8wbPKvoK3EtHgfzCGNNQDV7FKP mpYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TBQbV3Emr6ioXpt4EodO1vtF0fsx2RYtF0ndtxbk4gw=; b=jrCCAVLA9pNVf8wFlRzLOza82Sbrc6Fg96QhDNVXMdRTPqxlRgbbnbahwtRp9CuZxI n6jEB6vamJIC7Ggu7g5fEB9zacvYfPdirO67HPUC7qHpEf1N+HA8kpMY1EElswJiUa51 HtvWIIZIOoE3ru1TQLaDRCmZYsyKM9algEngBuc67xO8g7DFg910bRbl7XE67Td1C12p IcFE5USpGbZzlaec7+O6p5tBcj/JDDRszi8kNlJwLTA7d9B+EOxYRIq1h4njpcgjEvWE 0jeBj3jBo3ZVd1Pe96QkGUn+O9WijTnyXz8Se3i68vVBq0M4V1/LYVoWA6m/6PNe8QJq 1moA== X-Gm-Message-State: AGRZ1gJOdk858yl5dGqPkEOEn0SwL44qN6Sy+7+b1CPIVMPv+xiOvXym cFvf9BTBM2PABomh6fQC44td7PzC01sS+PNFoOoZXQ== X-Google-Smtp-Source: AJdET5evV0X0+0F5HdcrjUCVY275l7Ydy92XJSueuo48STTqtE2rWV3K4Bns7clMF2WX0PxRU//joSCf17P4wNnupLA= X-Received: by 2002:a1c:9f01:: with SMTP id i1-v6mr7066299wme.8.1541444176977; Mon, 05 Nov 2018 10:56:16 -0800 (PST) MIME-Version: 1.0 References: <9FB4DA1B-B45C-41A0-85FF-A7E09199F380@apple.com> In-Reply-To: <9FB4DA1B-B45C-41A0-85FF-A7E09199F380@apple.com> From: Peter Thatcher Date: Mon, 5 Nov 2018 10:56:04 -0800 Message-ID: To: Tommy Pauly Cc: rtcweb@ietf.org, TAPS WG IETF list Content-Type: multipart/alternative; boundary="0000000000009cf3e40579ef7024" Archived-At: Subject: Re: [rtcweb] Discussing WebRTC API mappings in TAPS X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 18:56:21 -0000 --0000000000009cf3e40579ef7024 Content-Type: text/plain; charset="UTF-8" FYI, the rtcweb WG has not been involved in the discussion around the WebRTC API for QUIC. It's only been discussed in the W3C. Naturally, some people are in both groups, but as a group, this WG has not discussed QUIC before (as far as I know). It might make more sense to reach out to the W3C WebRTC WG. However, if you want to talk to people in person IETF 103 might be a good opportunity to find people. And since we're discussing TAPS and RTCWEB here, there is an area that the experience of the RTCWEB WG can probably help the TAPS WG: the use of ICE. I recently read through the TAPS documents and it seems that TAPS is attempting to make an API that includes the use of ICE (it's basically a superset of ICE, much like the combination the WebRTC protocols). In the context of the web, that can lead to some tricky issues. If you wish to extend TAPS to the web, one issue you will run into is the same that RTCWEB did around the IP privacy handling of ICE (and the subsequent use of mDNS). Another is consent freshness. There may be others that I can't recall. But you'll probably want to learn how the RTCWEB WG solved these problems (for some definition of solved :) rather than retreading them. On Sun, Nov 4, 2018 at 4:20 PM Tommy Pauly wrote: > Hello rtcweb, > > Based on recent proposals for WebRTC APIs to run over QUIC, the Transport > Services (TAPS) working group will be spending some time this week looking > at the usefulness and applicability of our flexible transport APIs for use > in WebRTC. One of the main goals is providing an API surface that will work > well across protocols and require minimal application effort to adopt, as > well as being able to dynamically use newer protocols. We'd like to get > input and feedback on how well such a model can serve the WebRTC use case. > > Please join us in our discussion if you're interested! > > Wednesday, November 7 > 1540-1710 Afternoon Session II > Transport Services WG > Room: Meeting 2 > > Thanks, > Tommy > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000009cf3e40579ef7024 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI, the rtcweb WG has not been involved in the discussion= around the WebRTC API for QUIC.=C2=A0 It's only been discussed in the = W3C.=C2=A0 Naturally, some people are in both groups, but as a group, this = WG has not discussed QUIC before (as far as I know).=C2=A0 It might make mo= re sense to reach out to the W3C WebRTC WG.=C2=A0 However, if you want to t= alk to people in person IETF 103 might be a good opportunity to find people= .=C2=A0

And since we're discussing TAPS and RTC= WEB here, there is an area that the experience of the RTCWEB WG can probabl= y help the TAPS WG: the use of ICE.=C2=A0 I recently read through the TAPS = documents and it seems that TAPS is attempting to make an API that includes= the use of ICE (it's basically a superset of ICE, much like the combin= ation the WebRTC protocols).=C2=A0 In the context of the web, that can lead= to some tricky issues.

If you wish to extend TAPS= to the web, one issue you will run into is the same that RTCWEB did around= the IP privacy handling of ICE (and the subsequent use of mDNS).=C2=A0 =C2= =A0 Another is consent freshness.=C2=A0 There may be others that I can'= t recall.=C2=A0 But you'll probably want to learn how the RTCWEB WG sol= ved these problems (for some definition of solved :) rather than retreading= them.=C2=A0=C2=A0


On Sun, Nov 4, 2018 at 4:20 PM Tommy Pauly <tpauly@apple.com> wrote:
Hello rtcweb,

Based on recent proposals for WebRTC APIs to run over QUIC, the Transport S= ervices (TAPS) working group will be spending some time this week looking a= t the usefulness and applicability of our flexible transport APIs for use i= n WebRTC. One of the main goals is providing an API surface that will work = well across protocols and require minimal application effort to adopt, as w= ell as being able to dynamically use newer protocols. We'd like to get = input and feedback on how well such a model can serve the WebRTC use case.<= br>
Please join us in our discussion if you're interested!

Wednesday, November 7
1540-1710=C2=A0 Afternoon Session II
Transport Services WG
Room: Meeting 2

Thanks,
Tommy

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000009cf3e40579ef7024-- From nobody Mon Nov 5 11:31:24 2018 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 E60051277D2 for ; Mon, 5 Nov 2018 11:31:22 -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 LNPs_ha6X04y for ; Mon, 5 Nov 2018 11:31:20 -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 1CAE4130E10 for ; Mon, 5 Nov 2018 11:31:19 -0800 (PST) Received: from [192.168.1.230] (cADFE653E.dhcp.as2116.net [62.101.254.173]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id wA5JVRRE018124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 5 Nov 2018 20:31:29 +0100 To: rtcweb@ietf.org From: Philipp Hancke Message-ID: <7b6e7b96-c83d-a019-f2c3-f859ce1c14fe@goodadvice.pages.de> Date: Mon, 5 Nov 2018 20:31:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] JSEP question: dealing with entities that do not support a=msid X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 19:31:23 -0000 I just filed https://github.com/rtcweb-wg/jsep/issues/856 after noticing an issue with remote offers from something that does not support a=msid. It seems that for the seemingly simple case of a single audio and video track (which might be all a non-webrtc entity ever wants to send) both JSEP and w3c-pc specify a behaviour which differs from current implementations. Is that ok to change/break or are there ways to deal with this in a backward compatible manner? From nobody Mon Nov 5 12:36:51 2018 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 818A7130DCA; Mon, 5 Nov 2018 12:36:41 -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 3f1lo5uFGBrQ; Mon, 5 Nov 2018 12:36:38 -0800 (PST) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 5DCD612D4E7; Mon, 5 Nov 2018 12:36:38 -0800 (PST) Received: by mail-ua1-x931.google.com with SMTP id v24so3691105uap.13; Mon, 05 Nov 2018 12:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e3qkNPAZldqZuJyP5QktMvJhA5AQH9PNH+OdsYTG1/U=; b=bB4lE4aqI1bRcDOvE4iBKAF4DZrDaKBxqXF3BPJTEmshiJujPTvz1W3A5PpyIi5IdL q21W7SdD0K6m1t/Q3SfJ3s1DsPBRHBoxTNYmlHFKSvNNu95CFCK9q/RH/uSnCaSozeI3 wnCpbiew+mS2nlnQEUuc4O2K4N3MKJ+mw1MOOkUnP2Dqa97Kksrr8/0jF9EbDh1Kp483 hIP4uDwo1XRstxM8TnkfTTW2kCaU30GjYYJMCoS+DkMPtuBEePj6RLaCstnNi+6QyX7d sKZAJrF3oQKVpj0/BG9FJRZuiUz/usbVoMcZt7Pt9uIGMPe7pv32GaFH+rWySnKcqkcr tuxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e3qkNPAZldqZuJyP5QktMvJhA5AQH9PNH+OdsYTG1/U=; b=nc0Ks37UrsoT+SoPM9oqPCWNgpupkseKgPrV7zoRSs043G3rVHxlnPCRukcUuXnDO6 IIaO0JyFhnRiyz7MdTxnUlHA9/DlyUuXFDG8EJFORD2wU8D06PnOS4LaEgbJW37V11wJ ToQnjIb8ofRLgtb+DU/AzM1Mpr/RTCG0pQXTjXL/JkeL/pggHpVUya1HGdHcXzxxHpPu B9KyN8uk/p+Be+LQsenLpqExAM03HYPFsJOoyDSjUmBVCJsNh/KoGelvnT3jH54lZ/U/ uvLmoQrv4nO/XFEWjkS4bWmyJ+hUGj1dr69UYkdd5c2VLLNsxa6tJ9WICb0j2vqDjlMC 1T4Q== X-Gm-Message-State: AGRZ1gI5FO4aPELDJ6hYCCO+Jq5WeN/pnKsGtAap0cAGqTp7Qr/JPlgM 3uyzQ8CAcx64aw0yJNG9KCHsmSnGFoKQgefog4Q= X-Google-Smtp-Source: AJdET5cRpRS97bTDIhzcJZKkN9nXqUqXHv07yOyPepw5hXxPBZX6sV6XPXuP1mBfPlrGl8ZTg3vV2Q821TsAMSPui2s= X-Received: by 2002:ab0:465:: with SMTP id 92mr7761389uav.28.1541450197016; Mon, 05 Nov 2018 12:36:37 -0800 (PST) MIME-Version: 1.0 References: <9FB4DA1B-B45C-41A0-85FF-A7E09199F380@apple.com> In-Reply-To: From: Bernard Aboba Date: Mon, 5 Nov 2018 15:36:25 -0500 Message-ID: To: Peter Thatcher Cc: tpauly@apple.com, RTCWeb IETF , taps@ietf.org Content-Type: multipart/alternative; boundary="0000000000006eb1ac0579f0d70b" Archived-At: Subject: Re: [rtcweb] Discussing WebRTC API mappings in TAPS X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 20:36:42 -0000 --0000000000006eb1ac0579f0d70b Content-Type: text/plain; charset="UTF-8" In terms of background, there are some things to understand about WebRTC-QUIC which may help provide context: 1. The current draft is focussed on peer-to-peer data exchange use cases, based on an RTCQuicTransport object (which models QUIC connections) and an RTCQuicStream object (which models QUIC streams). The RTCQuicTransport object takes after the RTCDtlsTransport object which was originally developed in the ORTC Community Group (see: http://draft.ortc.org) and later integrated in WebRTC (see: https://rawgit.com/w3c/webrtc-pc/master/webrtc.html), so it has been relatively stable. The RTCQuicStream object has undergone quite a few changes in order to evolve along with the IETF QUIC Transport draft (see: https://tools.ietf.org/html/draft-ietf-quic-transport ), and during the latest WEBRTC WG meetings, additional changes were discussed, in order to better align WebRTC-QUIC with the WHAT WG Streams API. On Mon, Nov 5, 2018 at 1:56 PM Peter Thatcher wrote: > FYI, the rtcweb WG has not been involved in the discussion around the > WebRTC API for QUIC. It's only been discussed in the W3C. Naturally, some > people are in both groups, but as a group, this WG has not discussed QUIC > before (as far as I know). It might make more sense to reach out to the > W3C WebRTC WG. However, if you want to talk to people in person IETF 103 > might be a good opportunity to find people.. > > And since we're discussing TAPS and RTCWEB here, there is an area that the > experience of the RTCWEB WG can probably help the TAPS WG: the use of ICE. > I recently read through the TAPS documents and it seems that TAPS is > attempting to make an API that includes the use of ICE (it's basically a > superset of ICE, much like the combination the WebRTC protocols). In the > context of the web, that can lead to some tricky issues. > > If you wish to extend TAPS to the web, one issue you will run into is the > same that RTCWEB did around the IP privacy handling of ICE (and the > subsequent use of mDNS). Another is consent freshness. There may be > others that I can't recall. But you'll probably want to learn how the > RTCWEB WG solved these problems (for some definition of solved :) rather > than retreading them. > > > On Sun, Nov 4, 2018 at 4:20 PM Tommy Pauly wrote: > >> Hello rtcweb, >> >> Based on recent proposals for WebRTC APIs to run over QUIC, the Transport >> Services (TAPS) working group will be spending some time this week looking >> at the usefulness and applicability of our flexible transport APIs for use >> in WebRTC. One of the main goals is providing an API surface that will work >> well across protocols and require minimal application effort to adopt, as >> well as being able to dynamically use newer protocols. We'd like to get >> input and feedback on how well such a model can serve the WebRTC use case. >> >> Please join us in our discussion if you're interested! >> >> Wednesday, November 7 >> 1540-1710 Afternoon Session II >> Transport Services WG >> Room: Meeting 2 >> >> Thanks, >> Tommy >> >> _______________________________________________ >> 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 > --0000000000006eb1ac0579f0d70b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In terms of background, = there are some things to understand about WebRTC-QUIC which may help provid= e context:

1. The current = draft is focussed on peer-to-peer data exchange use cases, based on an RTCQ= uicTransport object (which models QUIC connections) and an RTCQuicStream ob= ject (which models QUIC streams).=C2=A0=C2=A0
The RTC= QuicTransport object takes after the RTCDtlsTransport object which was orig= inally developed in the ORTC Community Group (see:=C2=A0 http://draft.ortc.org) and later integrated in WebRTC (= see: https:= //rawgit.com/w3c/webrtc-pc/master/webrtc.html), so it has been relative= ly stable.=C2=A0 The RTCQuicStream object has undergone quite a few changes= in order to evolve along with the IETF QUIC Transport draft (see:=C2=A0https://tool= s.ietf.org/html/draft-ietf-quic-transport ), and during the latest WEBR= TC WG meetings, additional changes were discussed, in order to better align= WebRTC-QUIC with the WHAT WG Streams API.=C2=A0

On Mon, Nov 5, 2018 at 1:56 PM Peter= Thatcher <pthatcher=3D40= google.com@dmarc.ietf.org> wrote:
FYI, the rtcweb WG has not been involved in the disc= ussion around the WebRTC API for QUIC.=C2=A0 It's only been discussed i= n the W3C.=C2=A0 Naturally, some people are in both groups, but as a group,= this WG has not discussed QUIC before (as far as I know).=C2=A0 It might m= ake more sense to reach out to the W3C WebRTC WG.=C2=A0 However, if you wan= t to talk to people in person IETF 103 might be a good opportunity to find = people..=C2=A0

And since we're discussing TAPS = and RTCWEB here, there is an area that the experience of the RTCWEB WG can = probably help the TAPS WG: the use of ICE.=C2=A0 I recently read through th= e TAPS documents and it seems that TAPS is attempting to make an API that i= ncludes the use of ICE (it's basically a superset of ICE, much like the= combination the WebRTC protocols).=C2=A0 In the context of the web, that c= an lead to some tricky issues.

If you wish to exte= nd TAPS to the web, one issue you will run into is the same that RTCWEB did= around the IP privacy handling of ICE (and the subsequent use of mDNS).=C2= =A0 =C2=A0 Another is consent freshness.=C2=A0 There may be others that I c= an't recall.=C2=A0 But you'll probably want to learn how the RTCWEB= WG solved these problems (for some definition of solved :) rather than ret= reading them.=C2=A0=C2=A0


On Sun, Nov 4, 2018 at 4:20 PM Tommy Pauly <= ;tpauly@apple.com= > wrote:
Hello rtcweb,

Based on recent proposals for WebRTC APIs to run over QUIC, the Transport S= ervices (TAPS) working group will be spending some time this week looking a= t the usefulness and applicability of our flexible transport APIs for use i= n WebRTC. One of the main goals is providing an API surface that will work = well across protocols and require minimal application effort to adopt, as w= ell as being able to dynamically use newer protocols. We'd like to get = input and feedback on how well such a model can serve the WebRTC use case.<= br>
Please join us in our discussion if you're interested!

Wednesday, November 7
1540-1710=C2=A0 Afternoon Session II
Transport Services WG
Room: Meeting 2

Thanks,
Tommy

_______________________________________________
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
--0000000000006eb1ac0579f0d70b-- From nobody Mon Nov 5 12:46:38 2018 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 5331C12D4ED for ; Mon, 5 Nov 2018 12:46:36 -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 PahTqR5TCdU7 for ; Mon, 5 Nov 2018 12:46:33 -0800 (PST) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 317EC1286E7 for ; Mon, 5 Nov 2018 12:46:33 -0800 (PST) Received: by mail-ua1-x935.google.com with SMTP id o17so3708794uad.8 for ; Mon, 05 Nov 2018 12:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zNDYiHTfxgpN3DbnFU6B8qolXEbVe8oABG6NqmIgGq8=; b=YuER9SFed7YBQz07pt0yYwykkuYvbPtDq0leWygyy7xxTtTrCSk9ptaqR7I+CUoijZ zYrtdfA/snYq0KWqocvNtmi87+shJXMIeW45dl3vx7x2us2DW2XP2gVMHHYeBJwBkPnP a0dfzo90XZcGyIEGL2OzV2Vmx4PLWL9qfevFzoO664po7dfHlaLkOeg8DBvPoySskOaz XmRkjbw+XOaiwtPGfAQnkPBhBVEcN3UjV3p3Fsft5RLTumby7C6dknBLF+kWXSCuqqcB 1v+deZvXSiokvcLSvVpfi1JTSynUT4kcXxFxeMV4OhgD1WEcLeHnGGYlCfV655/4V52W AABQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zNDYiHTfxgpN3DbnFU6B8qolXEbVe8oABG6NqmIgGq8=; b=E3ui3in6ZhJiEEDVfU1f4cwYxmLN0JRhPfEYpuZBhgs2oSRvA5pyoMZcHIoU5iYWRJ dtr5u1sBTx5mD1OeiFeuhc2ddBfKxbHDHhRppQPd6hJuHkPo+L3S0Cnr0dZIYtr4uGaP LgJoDiHi0S5NhlGGConSoj1x/a4iMrtk896jJg0V7G7JMkwHuHK9UA0zWwXBbHa3KqEW LUz2K7dgxd1HWEJKjUKJ/6mrzrqzIBZjCM2y3TRs5gjgBTud1sHb5xsh4MiRuUVltBg8 h1V5N5BbwLBsry5rWPk7cwlGm1OPDPD5G5HgMvIuMOgbNSNumQrgKGbjWw5bPYtNw1wQ OSSQ== X-Gm-Message-State: AGRZ1gIOv5jpnzukixh5kCSc9xs8S8Hkg7hIEbAtW9JFICWcCLAOWqwt EQVoX1NplmMaF5mhGQq0Uzq1MdfBmsXh2uLaoj4= X-Google-Smtp-Source: AJdET5e1NBPUA0kEJQBMECgRdnDy21Sg8omYHQmTQI7eSFus/q82p0T0hM1c60C4MylmvqwWD/c89ip7BmlDG+O/f0Y= X-Received: by 2002:ab0:60da:: with SMTP id g26mr5057280uam.104.1541450792009; Mon, 05 Nov 2018 12:46:32 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> In-Reply-To: From: Bernard Aboba Date: Mon, 5 Nov 2018 15:46:20 -0500 Message-ID: To: Sergio Garcia Murillo Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000e5863d0579f0fafe" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 20:46:37 -0000 --000000000000e5863d0579f0fafe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sergio said: "here could be a way to overcome this by setting all the send encodings active flag to false when receiving a simulcast offer. Then app can do a getParameters, get layer num and rids, configure the settings and enable the desired ones by setting active to true." [BA] Yes, this makes sense, and from Nil's note, it appears that this is the way things work now in Firefox. On Sun, Nov 4, 2018 at 7:37 PM Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > there could be a way to overcome this by setting all the send encodings > active flag to false when receiving a simulcast offer. Then app can do a > getParameters, get layer num and rids, configure the settings and enable > the desired ones by setting active to true. > > Best regards > Sergio > > El lun., 5 nov. 2018 1:26, I=C3=B1aki Baz Castillo escrib= i=C3=B3: > >> (On Mon, 5 Nov 2018 at 01:21, Nils Ohlmeier >> wrote: >> > >> > Here is a fiddle which demonstrates that just putting simulcast into >> the offer, but not calling setEncodings() does not activate simulcast: >> https://jsfiddle.net/x6qgab87/ >> > So the other side can=E2=80=99t force simulcast on the browser. If you= provide >> me with a demo which shows that it is possible, then that is a bug I=E2= =80=99ll >> happily fix for you. >> >> Ok, that's new. I remember many months ago when I reported this (I was >> in fact producing simulcast based on remote SDP offer) and it was not >> necessary to call sender.setParameters({ encodings }) after sRD and >> before createOffer. >> >> Ok, this behavior makes more sense. BUT: it's not feasible because you >> need to use hardcoded/fixed rid values (or manually do SDP parsing). >> >> >> -- >> I=C3=B1aki Baz Castillo >> >> >> _______________________________________________ >> 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 > --000000000000e5863d0579f0fafe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sergio said:=C2=A0

"here could be = a way to overcome this by setting all the send encodings active flag to fal= se when receiving a simulcast offer. Then app can do a getParameters, get l= ayer num and rids, configure the settings and enable the desired ones by se= tting active to true."

[BA] Yes, this makes s= ense, and from Nil's note, it appears that this is the way things work = now in Firefox.=C2=A0

On Sun, Nov 4, 2018 at 7:37 PM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com&= gt; wrote:
there could be a way to overcome this by setting all the send e= ncodings active flag to false when receiving a simulcast offer. Then app ca= n do a getParameters, get layer num and rids, configure the settings and en= able the desired ones by setting active to true.

Best regards
Sergio
El lun., 5 nov. 2018 1:26, I= =C3=B1aki Baz Castillo <ibc@aliax.net> escribi=C3=B3:
(On Mon, 5 Nov 2018 at 01:21, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
>
> Here is a fiddle which demonstrates that just putting simulcast into t= he offer, but not calling setEncodings() does not activate simulcast: https://jsfiddle.net/x6qgab87/
> So the other side can=E2=80=99t force simulcast on the browser. If you= provide me with a demo which shows that it is possible, then that is a bug= I=E2=80=99ll happily fix for you.

Ok, that's new. I remember many months ago when I reported this (I was<= br> in fact producing simulcast based on remote SDP offer) and it was not
necessary to call sender.setParameters({ encodings }) after sRD and
before createOffer.

Ok, this behavior makes more sense. BUT: it's not feasible because you<= br> need to use hardcoded/fixed rid values (or manually do SDP parsing).


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listi= nfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000e5863d0579f0fafe-- From nobody Mon Nov 5 13:30:48 2018 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 AA16C1252B7 for ; Mon, 5 Nov 2018 13:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 16CwF_98JWCk for ; Mon, 5 Nov 2018 13:30:43 -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 E7A6E124D68 for ; Mon, 5 Nov 2018 13:30:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 061C47C0C76; Mon, 5 Nov 2018 22:30: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 hPiVZ4R6z_hd; Mon, 5 Nov 2018 22:30:38 +0100 (CET) Received: from [IPv6:2001:67c:1232:144:e6a7:a0ff:fe0b:6b0c] (unknown [IPv6:2001:67c:1232:144:e6a7:a0ff:fe0b:6b0c]) by mork.alvestrand.no (Postfix) with ESMTPSA id ADEC97C078E; Mon, 5 Nov 2018 22:30:36 +0100 (CET) To: Sergio Garcia Murillo Cc: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , RTCWeb IETF References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no> Date: Mon, 5 Nov 2018 22:30:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 21:30:47 -0000 On 11/05/2018 02:07 PM, Sergio Garcia Murillo wrote: > On 05/11/2018 12:45, Harald Alvestrand wrote: >> I do fear that simulcast will continue to affect parts of the spec that >> we don't expect it to. But we don't have the luxury of specifying it >> halfway; either we rip it out altogether, or we specify it in enough >> detail for interoperable implementation. > > I agree to that. If we are able to find an "easy" (i.e. not > introducing too many changes) I would not have any issues adding > support to that. > > Something like: > > - Browser adds a track via addTrack > > - Browser call SRD with a recv simulcast m-line offer > > - The transceiver is created with one send encoding per rid offered by > the SFU with default values and all send encodings except first one > with active=false (this would be the only required change) > > ----- browser encodes/sends a single rtp stream, same as if the remote > offer was a non simulcast stream-- > > -Browser calls sender.getParameters(), modifies the desired send > encoding parameters ( scaleResolutionDownBy,  maxFramerate, > maxBitrate, etc) and enables them by setting active=true > > Would this approach fulfill the requirements? Yes, I believe so. This is also precisely what I was proposing, except for the requirement to call addTrack. Note that our current spec text says that when addTrack is called, a transceiver is created with the max number of simulcast encodings set to 1, and that this number cannot be increased. This would have to change. From nobody Mon Nov 5 13:33:46 2018 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 044AC130DC0 for ; Mon, 5 Nov 2018 13:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 y11qQrnFNLOW for ; Mon, 5 Nov 2018 13:33:43 -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 C9EA91252B7 for ; Mon, 5 Nov 2018 13:33:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 27DC17C0C76; Mon, 5 Nov 2018 22:33:41 +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 jA-hRyC5WbfZ; Mon, 5 Nov 2018 22:33:40 +0100 (CET) Received: from [IPv6:2001:67c:1232:144:e6a7:a0ff:fe0b:6b0c] (unknown [IPv6:2001:67c:1232:144:e6a7:a0ff:fe0b:6b0c]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4F9757C078E; Mon, 5 Nov 2018 22:33:37 +0100 (CET) To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , Sergio Garcia Murillo Cc: rtcweb@ietf.org References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: Date: Mon, 5 Nov 2018 22:33:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 21:33:45 -0000 On 11/05/2018 03:33 PM, Iñaki Baz Castillo wrote: > On Mon, 5 Nov 2018 at 15:21, Sergio Garcia Murillo > wrote: >> By the way, according to the simulcast draft that should not be a problem at all: >> >> An answerer that receives an offer with simulcast that lists a number >> of simulcast streams, MAY reduce the number of simulcast streams in >> the answer, but MUST NOT add simulcast streams. > Not sure if that also covers "recv" simulcast items in the offer. > Probably yes, so ok. > > However still useless IMHO. Imagine an SFU that wants to receive, at > least those bitrates (because somehow it knows that all devices can > handle at least 3 simulcast streams): > > - 150kbps > - 400kbps > - 1000kbps > > Imagine there are also some devices supporting up to 5 streams, so the > SFU produces this simulcast settings in the offer for receiving: > > - 150kbps > - 120kbps > - 400kbps > - 750kbps > - 1000kbps > > If a device that just supports 3 simulcast streams receives such an > offer, it would discard 2. Which ones? ok, the SDP can include info > about the desired max-bitrate per rid, and we may think: oh, we can > get the list of rids and bitrates after pc.setRemoteDescription() by > calling pc.getTransceivers()[1].receiver.getParameters().encodings, so > the app can decide which ones to enable. > > But that's not true since receiver.getParameters() should not contain > more rids than those supported by the device. Well, this constraint is > really about sender.getParameters(). So you may say: ok we somehow > read the maximum simulcast streams that our browser/device can send > and then choose the appropriate ones from the receiver can call > transceiver.sender.setParameters() with them.. Error! there is no API > for knowing the max number of simulcast streams the browser can > produce. > > Too many assumptions and non existing features in this text to make > this scenario really possible. I think the text would have to say that we discard encodings from either the beginning or the end of the list (I'd suggest the end). Sorting is going to make some of the people unhappy, some of the time. -- Surveillance is pervasive. Go Dark. From nobody Mon Nov 5 13:35:22 2018 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 D4D371252B7 for ; Mon, 5 Nov 2018 13:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4nd8JP2di0K for ; Mon, 5 Nov 2018 13:35:18 -0800 (PST) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 28BB2124D68 for ; Mon, 5 Nov 2018 13:35:18 -0800 (PST) Received: by mail-ua1-x92f.google.com with SMTP id v24so3753636uap.13 for ; Mon, 05 Nov 2018 13:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OWzl9L/Z9Y2HkMngfA0x4uKAwrUkvJ8cDgCttHIIy3E=; b=lhGTa/MQCRK69O1eBTm9dzVXjWYKWVFd9BIDI7jPnxJ3a00nJxNf4NPsvEqP8Qk6/R QmcMkXCIAUN27J0E43WgIjcm8/F2Mb9/jXD+EQyjlS77RbfMO78/EIx+gYtwg6+ZYi+C 3Zm8PqcEwP/jCY6+tGy9UJXsXPuJxBSzTtVIay9i+lDg7ekyC6/2txKUP2EV17DK/5EK cb7pxrYCEhA2FxN+0vXlyI4VS3bOEz/jbn630rZKbamqrtLuykY3pYNH90C/9f0+Nu3i LH4jtp0yEv+tuHpZUoE4G5SzMEEQTZJ0SZQfK9ij7KAh3Qt3vK5yNnfSEiskMkldc4Ny vHXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OWzl9L/Z9Y2HkMngfA0x4uKAwrUkvJ8cDgCttHIIy3E=; b=ncw6sUAXlF6WNeppUl7in2g3Pblhd3TtZHaLq6Vo3zTpHV/zny0jdg+tKXkzzCfrCB jKAaxq57AqgEPTzUSlLuzugLCXr26p+x8F1xWGDn7JdcTTFfdYJ9H+s+aNPlz7TAZNfn op8Ekh8irNFhEzU91y01jFdllmTD02u2nM6LB9/6B8StzSMi+sLFMwc7BQJVM//MzwDV MzhvmVk8LdqxFkdtZI3Twfb1tfh0q9qF/qzGWV+N40U5RDjs5FKTBGZZfg1qnUNya1kk uDL4W4UOm4fIToz9TVUhzU6kdIKo30ayACU4LzsWlr6e5mXtRXyeQNvZ8g3c352A5SWC lcZA== X-Gm-Message-State: AGRZ1gJsHJ2VsYmMDFJct0TL/yfIn72vjP5zpWSTmDWmz7vVv9SjVPHd TSJsrxhM9UkM2e+l4V68d58JCsXSOIcNzODC/8QGzg== X-Google-Smtp-Source: AJdET5eIGk5ZaZXL0oSE9tZhTUwZTojPTx+UTvqzD1lC/NmDm0m4IiORzL8z/9jyLz3e1NiUgGEeDiXckpcJ++FpQsc= X-Received: by 2002:ab0:3392:: with SMTP id y18mr10918783uap.117.1541453717134; Mon, 05 Nov 2018 13:35:17 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no> In-Reply-To: <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 22:35:05 +0100 Message-ID: To: Harald Alvestrand Cc: Sergio Garcia Murillo , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 21:35:21 -0000 On Mon, 5 Nov 2018 at 22:30, Harald Alvestrand wrote= : > Yes, I believe so. This is also precisely what I was proposing, except > for the requirement to call addTrack. > > Note that our current spec text says that when addTrack is called, a > transceiver is created with the max number of simulcast encodings set to > 1, and that this number cannot be increased. This would have to change. Is it not possible to call sender.setParameters(N encodings) after calling pc.addTrack(track)? why? --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 5 13:37:54 2018 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 6279D1252B7 for ; Mon, 5 Nov 2018 13:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbz1WB5BTIZW for ; Mon, 5 Nov 2018 13:37:51 -0800 (PST) Received: from mail-vk1-xa44.google.com (mail-vk1-xa44.google.com [IPv6:2607:f8b0:4864:20::a44]) (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 ECFCE124D68 for ; Mon, 5 Nov 2018 13:37:50 -0800 (PST) Received: by mail-vk1-xa44.google.com with SMTP id 197so2391921vkf.4 for ; Mon, 05 Nov 2018 13:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eS6Q938m2JdwBzaJWlW9rHhz0m7nSqyVrZ5aF6nEH9Y=; b=y+C1tu4qRtdOQNoT5QNDgwtc3dd9RtqZHT65PkIClWIt44BQDBCMCT+zB1wY1e+Nhy ZclxAeexE8bWWuXq8FJIZEAK2JpnfOrk93Hy320O8oXeFO50UpHp/OJ1NMn8jQAXxGcf n1X24lIIAqGi42udTAQTExrNdY5huxkmJAEOmql369f9yfjy/laYh2ClsTONnvliZGYe wjgmqVWF6Zukxte+s+xXrxav5ogjDdPQ9FL3hdenEkNAxRfbxSgVZUnrsl9mT/Q3GD+V eQ7tsT9EOo2RMaqpeejv1TlIHOXepQhn34DnQJ3nVEvRVAtO5qZJofNZRhpGC2e89oja eXqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eS6Q938m2JdwBzaJWlW9rHhz0m7nSqyVrZ5aF6nEH9Y=; b=gB4tYmgGvZZgG3F6v33CHHysxcvsX6cJ6lsyqr2v102cwhaa5NLZ1/tNhHXQwfJMJg 9MoKxMyhShSOSmVbEa/XSIu6eRULFszGDdXrOhp5KEn/5/bVZKh3qkiwgPkvEfCCxTGp miUf2br3oUHcn3CiJVBI8hBNGJcSDAIo5+Z0L1FqCUQxy3nO+IRqcZbbn8awEJOq5mkA T0gnRus41tl6U5Ciryfi293Wfj1Ol7MmfTj3B6TW44SlPieb5qQ8rcl2vTRXPoVBrwkf lz/eDNJesprl6xBaf0N2JFYSN5Akhmz35B2onbx9pqJQISyLyq205J6P53HMqLbwkeUt 7ouw== X-Gm-Message-State: AGRZ1gJ8LisbndSJlIi8fEjdR2JcrqxolYj2GMfAgQqkRM9BLUWWew02 DEYqJb7csxS/E5tZ22t94vYENXoF17uGmCYgjeebNA== X-Google-Smtp-Source: AJdET5fQluYUjKENvKD92SytSu0toZ6Qhgmv3T1HJg2Ui6n9wGRt/OSTkztqfL76+axH4ZaS0gv8uhc6Gt94/J45GgA= X-Received: by 2002:a1f:ed86:: with SMTP id l128mr10285857vkh.21.1541453869979; Mon, 05 Nov 2018 13:37:49 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 22:37:37 +0100 Message-ID: To: Harald Alvestrand Cc: Sergio Garcia Murillo , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 21:37:53 -0000 > I think the text would have to say that we discard encodings from either the beginning or the end of the list (I'd suggest the end). Sorting is going to make some of the people unhappy, some of the time. If in my example above the browser discards encodings at the beginning, those would remain: - 400kbps - 750kbps - 1000kbps which are not good for common simulcast usage. If in my example above the browser discards encodings at the end, those would remain: - 150kbps - 120kbps - 400kbps which are not good for common simulcast usage. :) On Mon, 5 Nov 2018 at 22:33, Harald Alvestrand wrote= : > > On 11/05/2018 03:33 PM, I=C3=B1aki Baz Castillo wrote: > > On Mon, 5 Nov 2018 at 15:21, Sergio Garcia Murillo > > wrote: > >> By the way, according to the simulcast draft that should not be a prob= lem at all: > >> > >> An answerer that receives an offer with simulcast that lists a numb= er > >> of simulcast streams, MAY reduce the number of simulcast streams in > >> the answer, but MUST NOT add simulcast streams. > > Not sure if that also covers "recv" simulcast items in the offer. > > Probably yes, so ok. > > > > However still useless IMHO. Imagine an SFU that wants to receive, at > > least those bitrates (because somehow it knows that all devices can > > handle at least 3 simulcast streams): > > > > - 150kbps > > - 400kbps > > - 1000kbps > > > > Imagine there are also some devices supporting up to 5 streams, so the > > SFU produces this simulcast settings in the offer for receiving: > > > > - 150kbps > > - 120kbps > > - 400kbps > > - 750kbps > > - 1000kbps > > > > If a device that just supports 3 simulcast streams receives such an > > offer, it would discard 2. Which ones? ok, the SDP can include info > > about the desired max-bitrate per rid, and we may think: oh, we can > > get the list of rids and bitrates after pc.setRemoteDescription() by > > calling pc.getTransceivers()[1].receiver.getParameters().encodings, so > > the app can decide which ones to enable. > > > > But that's not true since receiver.getParameters() should not contain > > more rids than those supported by the device. Well, this constraint is > > really about sender.getParameters(). So you may say: ok we somehow > > read the maximum simulcast streams that our browser/device can send > > and then choose the appropriate ones from the receiver can call > > transceiver.sender.setParameters() with them.. Error! there is no API > > for knowing the max number of simulcast streams the browser can > > produce. > > > > Too many assumptions and non existing features in this text to make > > this scenario really possible. > > I think the text would have to say that we discard encodings from either > the beginning or the end of the list (I'd suggest the end). > Sorting is going to make some of the people unhappy, some of the time. > > > -- > Surveillance is pervasive. Go Dark. > --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 5 13:40:42 2018 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 2CD7F1252B7 for ; Mon, 5 Nov 2018 13:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 LATX4RBxMDde for ; Mon, 5 Nov 2018 13:40:38 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 3135A124D68 for ; Mon, 5 Nov 2018 13:40:38 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id k15-v6so8218396wre.12 for ; Mon, 05 Nov 2018 13:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=/CXyxTDPX7uijtSq7KrUlxjCcYPu4bp2Gj/TzzxCqkY=; b=eVVSpZdqoiNeyyF9uKCGEcAyde5BzcDbV1LQtSQE0nw8W1COYphKMWLcFlQTCgoqQH 9LforahGruQjsLiTYzXg3tpLfbuws1KPl9+2L9+zSR5luIGPagutHKwcrvic1ylEM1D6 vjahclkqn9W9wExv5vva0rkzGnm6atqSCXu/S9ij1fRO0vtKhZaeuWRiE3gMZnSmbshK PNkAyAHmN+LLmJwvPfMXqao7GjRNe74qZrsJrJMg3eM2VrkyGs8F6ekOYH3HymU+lQ2c IwyJXomdPXym0asKBKO7bO17IibWHdsnB37H0g/vt6SQ1yALrOtugUq3jXdOl9O02ZsI e9eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=/CXyxTDPX7uijtSq7KrUlxjCcYPu4bp2Gj/TzzxCqkY=; b=tqUcGQI7hMBTz5qb0Rrxl0ljOnCMkT/cga4Dur4fwEZJElt9tlqoGlmEOv92glwT9k kgWzEuPPVcznHdooddDK/BXjqyTE+VwZArWoDnvslqKwa3q5TiXx5b36nEZCjCxYyC9i 3mgfHgg8dYL8u2CshaIHJ5rFMOYq8Lr/n7p7oh4RPd0mNP570gpgrs787A0OXYQbBNsl tiRkAC6Hkb2h6NrGIr+NIil0AVRRo8noIVvJYSVH6T4QHCmhNwAnPGILR8LlrkEFERv/ tdLgGURAHLJu8nJV3/qZx/oWw3/FvF08efjdFKIlqssJRoWVAumcjX574n2zLUGxbeuq x/ww== X-Gm-Message-State: AGRZ1gJFnwYk8GD7VhzvqK4inqqpzejq9JfzsBepSsrgUh7GscjrhVqm JhOi55WVtNKjqyhO+SLZfQcbgjm0 X-Google-Smtp-Source: AJdET5d1Nh9T5ht4MihoAcJFfnqkpS0x4StXuOj9RqfQHWz7L5BWuXcRxq9G43mQ2OAAY8GllzWPQA== X-Received: by 2002:adf:f181:: with SMTP id h1-v6mr16230210wro.79.1541454036569; Mon, 05 Nov 2018 13:40:36 -0800 (PST) Received: from [192.168.0.11] (89.141.9.215.dyn.user.ono.com. [89.141.9.215]) by smtp.googlemail.com with ESMTPSA id 137-v6sm9403282wmo.43.2018.11.05.13.40.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 13:40:35 -0800 (PST) To: Harald Alvestrand Cc: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , RTCWeb IETF References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no> From: Sergio Garcia Murillo Message-ID: <90a5ce17-8b65-2a29-0b6a-20e66298a87c@gmail.com> Date: Mon, 5 Nov 2018 22:43:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no> Content-Type: multipart/alternative; boundary="------------0B803B734C992389A5D3EF5A" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 21:40:40 -0000 This is a multi-part message in MIME format. --------------0B803B734C992389A5D3EF5A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 05/11/2018 22:30, Harald Alvestrand wrote: >> Would this approach fulfill the requirements? > Yes, I believe so. This is also precisely what I was proposing, except > for the requirement to call addTrack. It would be also possible, to not call addTrack before SLD and use replaceTrack on the transceiver once the remote offer is set. > Note that our current spec text says that when addTrack is called, a > transceiver is created with the max number of simulcast encodings set to > 1, and that this number cannot be increased. This would have to change. Yes, it would have to be changed also. Best regards Sergio --------------0B803B734C992389A5D3EF5A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 05/11/2018 22:30, Harald Alvestrand wrote:
Would this approach fulfill the requirements?

Yes, I believe so. This is also precisely what I was proposing, except
for the requirement to call addTrack.
It would be also possible, to not call addTrack before SLD and use replaceTrack on the transceiver once the remote offer is set.
Note that our current spec text says that when addTrack is called, a
transceiver is created with the max number of simulcast encodings set to
1, and that this number cannot be increased. This would have to change.
Yes, it would have to be changed also.

Best regards
Sergio
--------------0B803B734C992389A5D3EF5A-- From nobody Mon Nov 5 14:16:45 2018 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 82D771286D9 for ; Mon, 5 Nov 2018 14:16:43 -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 z78mEmTkNUUr for ; Mon, 5 Nov 2018 14:16:41 -0800 (PST) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 347E2124D68 for ; Mon, 5 Nov 2018 14:16:41 -0800 (PST) Received: by mail-vk1-xa35.google.com with SMTP id o10-v6so2406491vki.6 for ; Mon, 05 Nov 2018 14:16:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DNc9U4JA8OETlUK+MbkXDqPqvkH4EVUkwIuSMPgMdjA=; b=ZZsK4EL0oDy+qmu48G70TMcUGUfpB9RZ6zM8dx/eojDOAmQWsqj4u7xGg/tVFvkPv6 StgoslSlKJb47dRLnfyzLFea55d+3S4BPeSI0NHmIhQSaralKoc2MhbKGdZ00RQl+fVZ Xw1t9Ne2aIxhHbOTH2meMIyDW8SpbWrO97SqEqRLb/LGBGkDo2t3C5eSMsS54Mob+6xJ GIiVjWDkErSRytQLI5ZkSYAr28gI4mCtLiqLOAX09MLLBjAkiKima8oyywPBtZTHUKNs e5wbFBtFB8dBp0QgmhGGKxf0Th6/K+cat2YQIfIYfN4nu9rcV1qfvMxavHydydBMbFuz NxAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DNc9U4JA8OETlUK+MbkXDqPqvkH4EVUkwIuSMPgMdjA=; b=o2eTw2S9Ny6X/QENabJ5yzQ1VK0rAUCzA3FOvS7nCa+hAAIuKuwLbuLwBSUu7j/hE6 bi8gfWnX8fo3Tl5BYnbBMiC5ratHbRHDE2Rz0CajHXOix5Ula23TlH4v+Z5UZ9ioGpql ZdgHRUfiJyYBdfXh/LPvjxl7Otdx5Wjg9S3TdttFPr+PykcI0LWqBPXUfuLa91NzYB7n RIIltmZ4bLIb0Xtrj2w0+k7AWSVqiMDR9T1RjVcX42MwsHpcCvGjH7oxM5Z0PV0wsp6f G6S4SWVZzQGh0ggmp1c/iq7MRAoV4+Pbdlt6pkGaFrolaPR2R9wQ/yTRq1iPRPdlrnEU sTJg== X-Gm-Message-State: AGRZ1gI3y49CIjey2QpeDT9c0jKn1XDuXEtol7rHS5sQ2aOWfuj10BLS rmNWwt2u+Su06Yhxlc4bn5v4pv9iFVaMP6wg1oA= X-Google-Smtp-Source: AJdET5fwqmdn/Sm7XxEA/1NLMukM2EsxPiexLcxm9zSTrVEhiRlYamV9TARtA6X3/qMf01nVZey1RcyEpCF9goYAPMY= X-Received: by 2002:a1f:5a01:: with SMTP id o1mr5216926vkb.4.1541456199887; Mon, 05 Nov 2018 14:16:39 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no> In-Reply-To: <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no> From: Bernard Aboba Date: Mon, 5 Nov 2018 17:16:26 -0500 Message-ID: To: Harald Alvestrand Cc: Sergio Garcia Murillo , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000003b32240579f23d0d" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 22:16:43 -0000 --0000000000003b32240579f23d0d Content-Type: text/plain; charset="UTF-8" Harald said: "Note that our current spec text says that when addTrack is called, a transceiver is created with the max number of simulcast encodings set to 1, and that this number cannot be increased. This would have to change." [BA] Most of the code examples I have seen that use addTrack for simulcast call setParameters prior to createOffer(). To allow this, we might consider saying that when addTrack returns, the encodings are initially null, and so can be set by setParameters(). On Mon, Nov 5, 2018 at 4:30 PM Harald Alvestrand wrote: > On 11/05/2018 02:07 PM, Sergio Garcia Murillo wrote: > > On 05/11/2018 12:45, Harald Alvestrand wrote: > >> I do fear that simulcast will continue to affect parts of the spec that > >> we don't expect it to. But we don't have the luxury of specifying it > >> halfway; either we rip it out altogether, or we specify it in enough > >> detail for interoperable implementation. > > > > I agree to that. If we are able to find an "easy" (i.e. not > > introducing too many changes) I would not have any issues adding > > support to that. > > > > Something like: > > > > - Browser adds a track via addTrack > > > > - Browser call SRD with a recv simulcast m-line offer > > > > - The transceiver is created with one send encoding per rid offered by > > the SFU with default values and all send encodings except first one > > with active=false (this would be the only required change) > > > > ----- browser encodes/sends a single rtp stream, same as if the remote > > offer was a non simulcast stream-- > > > > -Browser calls sender.getParameters(), modifies the desired send > > encoding parameters ( scaleResolutionDownBy, maxFramerate, > > maxBitrate, etc) and enables them by setting active=true > > > > Would this approach fulfill the requirements? > > Yes, I believe so. This is also precisely what I was proposing, except > for the requirement to call addTrack. > > Note that our current spec text says that when addTrack is called, a > transceiver is created with the max number of simulcast encodings set to > 1, and that this number cannot be increased. This would have to change. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000003b32240579f23d0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Harald said:=C2=A0

"Note that our = current spec text says that when addTrack is called, a
transceiver is = created with the max number of simulcast encodings set to
1, and th= at this number cannot be increased. This would have to change."
<= div>
[BA] Most of the code examples I have seen that use addT= rack for simulcast call setParameters prior to createOffer().=C2=A0 To allo= w this, we might consider saying that when addTrack returns, the encodings = are initially null, and so can be set by setParameters().=C2=A0=C2=A0
=
On Mon, Nov 5, 2018 a= t 4:30 PM Harald Alvestrand <har= ald@alvestrand.no> wrote:
On= 11/05/2018 02:07 PM, Sergio Garcia Murillo wrote:
> On 05/11/2018 12:45, Harald Alvestrand wrote:
>> I do fear that simulcast will continue to affect parts of the spec= that
>> we don't expect it to. But we don't have the luxury of spe= cifying it
>> halfway; either we rip it out altogether, or we specify it in enou= gh
>> detail for interoperable implementation.
>
> I agree to that. If we are able to find an "easy" (i.e. not<= br> > introducing too many changes) I would not have any issues adding
> support to that.
>
> Something like:
>
> - Browser adds a track via addTrack
>
> - Browser call SRD with a recv simulcast m-line offer
>
> - The transceiver is created with one send encoding per rid offered by=
> the SFU with default values and all send encodings except first one > with active=3Dfalse (this would be the only required change)
>
> ----- browser encodes/sends a single rtp stream, same as if the remote=
> offer was a non simulcast stream--
>
> -Browser calls sender.getParameters(), modifies the desired send
> encoding parameters ( scaleResolutionDownBy,=C2=A0 maxFramerate,
> maxBitrate, etc) and enables them by setting active=3Dtrue
>
> Would this approach fulfill the requirements?

Yes, I believe so. This is also precisely what I was proposing, except
for the requirement to call addTrack.

Note that our current spec text says that when addTrack is called, a
transceiver is created with the max number of simulcast encodings set to 1, and that this number cannot be increased. This would have to change.


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000003b32240579f23d0d-- From nobody Mon Nov 5 14:20:13 2018 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 D43271286D9 for ; Mon, 5 Nov 2018 14:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bhi2xhkUX4PK for ; Mon, 5 Nov 2018 14:20:09 -0800 (PST) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 9B2141252B7 for ; Mon, 5 Nov 2018 14:20:09 -0800 (PST) Received: by mail-vk1-xa35.google.com with SMTP id h128so2406635vkg.11 for ; Mon, 05 Nov 2018 14:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tsKZj8UF6siuRsa3sEODyMfz1kZyIRbO413hrla2Tdc=; b=JhDO14mZgUnN+SUWNwZZtS0SDcmvYcRLXxqLfFdpmgetBhRzOazOAWqEadg5oE40Ej 7YlxSU3HSEFU8fIjcTDigTZDLeGrYiLynqM4aVjcNMRDj2sj9wwWOMLPwvKGXH5bZ1pH 0Abzpw1Y6YiJFjvLLZhs3wprbeOF5Cx/zqW33chxTc4Ss1/xQkzNiOn23GbE1MnedlIT JQHjTifeNwAFQxrPDPGGdJ3wkER2UTiORVes++TU3WXSg8XXo+fBpw0tSe8QUmQVHft5 FBaOQxICnw8RKmyT+HuCt9YDcGNSJvBrg03uwz5M8cqVBzkvctTQ9LnfGScYGl4U2ecY Q/QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tsKZj8UF6siuRsa3sEODyMfz1kZyIRbO413hrla2Tdc=; b=Pg2uNAPP6X9INaK59iPWAzKFSDkocyS05M1XJY/mwcCPv/WYnaeCKSG1dhbfAB81Bx tIgT1hzT8R38Hr1q0moS2wSy2W4r22DY4ooeEYMhiken9gQ2yKokx4ltB/3d9IdTWHEX NAoyX5/CweJcZH5TuSO0rbIGz3LLu3pAf40qjiLSo/YCxAA34c2jVQ9ImGg5hDsNzN6r rcZoICIMWthcoVY8NvrD+ujYO4Cna/oZf4Y54EM72ZBEov2g5W4jjFpu8kVrEdQEtIlE Zwghz8r8xA+3uZIYLsL1GyQfXJ97R72o15aait5R1k2F8z0fTyB8/rV5ff2YACl2EqGV 0vCg== X-Gm-Message-State: AGRZ1gKO392EaQYHCfriKu+S701i/HsB6TcSWeIfLpzsCFTLRfnRrL7X AnLNuw7FBVprV/FmT1fYxhHzMqEXJfZRmpOYMgXcC2Ub X-Google-Smtp-Source: AJdET5fJUcu6djxZQCrePGuSc2bYCbVBWoJ6mY8LY9B8j1l9xbpfx4bOlQCXeY7we2P+neYsMIyWpx5e1scE9GJtxEA= X-Received: by 2002:a1f:ed86:: with SMTP id l128mr10347848vkh.21.1541456408598; Mon, 05 Nov 2018 14:20:08 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 23:19:56 +0100 Message-ID: To: Bernard Aboba Cc: Harald Alvestrand , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 22:20:12 -0000 On Mon, 5 Nov 2018 at 23:16, Bernard Aboba wrote: > [BA] Most of the code examples I have seen that use addTrack for simulcas= t call setParameters prior to createOffer(). To allow this, we might consi= der saying that when addTrack returns, the encodings are initially null, an= d so can be set by setParameters(). I'm lost. I've enabled simulcast in Firefox using sender.setParameters() after both pc.addTrack() and pc.addTransceiver(), and before pc.createOffer(). So I'm not aware of such a limitation in addTrack that "produces just 1 encoding that cannot be increased". Why not? Why should it work with addTransceiver() and not with addTrack()? --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 5 14:37:17 2018 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 82CC3124D68 for ; Mon, 5 Nov 2018 14:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Yv8aRD6WQukS for ; Mon, 5 Nov 2018 14:37:14 -0800 (PST) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 CCBD6124C04 for ; Mon, 5 Nov 2018 14:37:13 -0800 (PST) Received: by mail-vk1-xa2f.google.com with SMTP id u62so2429585vkb.3 for ; Mon, 05 Nov 2018 14:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p55rPfcJbbD86Wxz+jT2ru96a0zhCxQQq+gvyPesKSg=; b=uUwzXIiJugddSneUtxgl+qSOiBpHH+r7untGbc47ChKiUk4gAUuC+2LRbyGzh2Kurj ARNdHMpylmbCQWGoUhx6jSWD3hDRf3qDyGkCyH6aI2WWsJsYESgN+/pBTQ99tw8Y7NaE SbmOfAiUANfC6/Od2m+vhYN1eFf/ZCF9H/Omi47L9PI0ZaO3hCtbZhAPz3H0XSjBWaTG CFmGylWjvjfGbip5MRqH82NovWkdUxW1Pn9LuOjg+yYbHlrj1K+LNcxoqSEy8NhS14ph Y7QP69+psMsUs5aKf+CkhYv4B5glBmyZsXDvysCwN/aYZ004jyaVs8GkwQC2JaWSUWhE auww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p55rPfcJbbD86Wxz+jT2ru96a0zhCxQQq+gvyPesKSg=; b=UFoBWn/wfZaAh5RTAw/xBFddykfVcg7FBCyLlcMtGzlvzv6QuF/Vt3MIj7VfPTT5EA WVVTdTjUVBXb0wjE0hJI59QxMhCilJjzqJlIia5TI3NQU8db57X7hwp32achE71P4Kjo OMkCgUphn0MwM9Gt0V1beKwnZ2CXhUumB6RztF5fCw0TbBYJ1oRLeTgFQlxvkZrtomBI wRDbiCp8TfAphDlVpY4ETheqSBwNk16czGMHJE4F6Wpa02GOzhjO1yxximyVESpOQyE2 jlFxwEOyD1jVf/lZ1X60fqXPRRfsa3++ASwwScHMMpg61bREIWH5xTlM0cZsnGNmldxb hRGg== X-Gm-Message-State: AGRZ1gKt6ueVaacvKW+eO+DBMo1IP77aKhYx1mV6IX5nt/JSyHv2h75e 3PAfnfqQrsO+LB10zykKfQI25bBB7lhAfpk9Rjes3g== X-Google-Smtp-Source: AJdET5eOtBC0lvBMFX+PVxjXSRczgt1rOrI80c5lNy49cH3xw/NuHHkP54hwCO37wfsQvNlEHDTM/4+ruqX8vunTIlc= X-Received: by 2002:a1f:346:: with SMTP id 67mr4104615vkd.10.1541457432578; Mon, 05 Nov 2018 14:37:12 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no> In-Reply-To: From: Bernard Aboba Date: Mon, 5 Nov 2018 17:37:01 -0500 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Harald Alvestrand , rtcweb@ietf.org Content-Type: multipart/alternative; boundary="000000000000b490210579f286db" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 22:37:16 -0000 --000000000000b490210579f286db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 5, 2018 at 5:20 PM I=C3=B1aki Baz Castillo wrot= e: > On Mon, 5 Nov 2018 at 23:16, Bernard Aboba > wrote: > > I'm lost. I've enabled simulcast in Firefox using > sender.setParameters() after both pc.addTrack() and > pc.addTransceiver(), and before pc.createOffer(). > > So I'm not aware of such a limitation in addTrack that "produces just > 1 encoding that cannot be increased". Why not? Why should it work with > addTransceiver() and not with addTrack() [BA] It works today. But currently the specification implies that setParameters() should fail to set multiple encodings after addTrack. IMHO, the spec is wrong - it should be allowed at least once before createOffer(). Should not be too hard to fix. > > --000000000000b490210579f286db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 5, 2018 at 5:20 PM I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
On Mon, 5 Nov 2018 at 23:16= , Bernard Aboba <bernard.aboba@gmail.com> wrote:

I'm lost. I've enabled simulcast in Firefox using
sender.setParameters() after both pc.addTrack() and
pc.addTransceiver(), and before pc.createOffer().

So I'm not aware of such a limitation in addTrack that "produces j= ust
1 encoding that cannot be increased". Why not? Why should it work with=
addTransceiver() and not with addTrack()

=
[BA] It works today. But currently the specificatio= n implies that setParameters() should fail to set multiple encodings after = addTrack. IMHO, the spec is wrong - it should be allowed at least once befo= re createOffer(). Should not be too hard to fix.

--000000000000b490210579f286db-- From nobody Mon Nov 5 14:54:44 2018 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 948EA130DCA for ; Mon, 5 Nov 2018 14:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 76EYrK69iXYB for ; Mon, 5 Nov 2018 14:54:40 -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 9C3B1128CE4 for ; Mon, 5 Nov 2018 14:54:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 127307C0C76; Mon, 5 Nov 2018 23:54:38 +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 iv2v1sKDGh82; Mon, 5 Nov 2018 23:54:36 +0100 (CET) Received: from [IPv6:2001:67c:1232:144:e6a7:a0ff:fe0b:6b0c] (unknown [IPv6:2001:67c:1232:144:e6a7:a0ff:fe0b:6b0c]) by mork.alvestrand.no (Postfix) with ESMTPSA id 366567C078E; Mon, 5 Nov 2018 23:54:34 +0100 (CET) To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= Cc: Sergio Garcia Murillo , rtcweb@ietf.org References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: Date: Mon, 5 Nov 2018 23:54:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 22:54:42 -0000 On 11/05/2018 10:37 PM, Iñaki Baz Castillo wrote: >> I think the text would have to say that we discard encodings from either > the beginning or the end of the list (I'd suggest the end). > Sorting is going to make some of the people unhappy, some of the time. > > If in my example above the browser discards encodings at the > beginning, those would remain: > > - 400kbps > - 750kbps > - 1000kbps > > which are not good for common simulcast usage. > > If in my example above the browser discards encodings at the end, > those would remain: > > - 150kbps > - 120kbps > - 400kbps > > which are not good for common simulcast usage. If in your example, the writer of the SDP knew that the browser would discard encodings at the end, it would send - 150kbps - 400kbps - 1000kbps - 120kbps - 750kbps That's predictable. If it thought "biggest and smallest are most important", it could also choose to send - 120kbps - 1000kbps - 400kbps - 150kbps - 750kbps If it thought "most clients are 400kbps, or 1000kbps, the 120kbps client is only seen occasionally, and handles 3 streams anyway", it could send - 400kbps - 1000kbps - 120kbps - 150kbps - 750kbps If the behavior of the responder is predictable, the initiator can achieve the result it wants. > > :) > > > On Mon, 5 Nov 2018 at 22:33, Harald Alvestrand wrote: >> On 11/05/2018 03:33 PM, Iñaki Baz Castillo wrote: >>> On Mon, 5 Nov 2018 at 15:21, Sergio Garcia Murillo >>> wrote: >>>> By the way, according to the simulcast draft that should not be a problem at all: >>>> >>>> An answerer that receives an offer with simulcast that lists a number >>>> of simulcast streams, MAY reduce the number of simulcast streams in >>>> the answer, but MUST NOT add simulcast streams. >>> Not sure if that also covers "recv" simulcast items in the offer. >>> Probably yes, so ok. >>> >>> However still useless IMHO. Imagine an SFU that wants to receive, at >>> least those bitrates (because somehow it knows that all devices can >>> handle at least 3 simulcast streams): >>> >>> - 150kbps >>> - 400kbps >>> - 1000kbps >>> >>> Imagine there are also some devices supporting up to 5 streams, so the >>> SFU produces this simulcast settings in the offer for receiving: >>> >>> - 150kbps >>> - 120kbps >>> - 400kbps >>> - 750kbps >>> - 1000kbps >>> >>> If a device that just supports 3 simulcast streams receives such an >>> offer, it would discard 2. Which ones? ok, the SDP can include info >>> about the desired max-bitrate per rid, and we may think: oh, we can >>> get the list of rids and bitrates after pc.setRemoteDescription() by >>> calling pc.getTransceivers()[1].receiver.getParameters().encodings, so >>> the app can decide which ones to enable. >>> >>> But that's not true since receiver.getParameters() should not contain >>> more rids than those supported by the device. Well, this constraint is >>> really about sender.getParameters(). So you may say: ok we somehow >>> read the maximum simulcast streams that our browser/device can send >>> and then choose the appropriate ones from the receiver can call >>> transceiver.sender.setParameters() with them.. Error! there is no API >>> for knowing the max number of simulcast streams the browser can >>> produce. >>> >>> Too many assumptions and non existing features in this text to make >>> this scenario really possible. >> I think the text would have to say that we discard encodings from either >> the beginning or the end of the list (I'd suggest the end). >> Sorting is going to make some of the people unhappy, some of the time. >> >> >> -- >> Surveillance is pervasive. Go Dark. >> > -- Surveillance is pervasive. Go Dark. From nobody Mon Nov 5 14:57:51 2018 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 AFC45130DC7 for ; Mon, 5 Nov 2018 14:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORhTvF_jrNgn for ; Mon, 5 Nov 2018 14:57:48 -0800 (PST) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 9E783128CE4 for ; Mon, 5 Nov 2018 14:57:48 -0800 (PST) Received: by mail-vk1-xa2f.google.com with SMTP id n126so2226120vke.12 for ; Mon, 05 Nov 2018 14:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tVIEwfKcYDxD46meOmGZXDGAcc0cITOPeHQ1rNUdm5c=; b=EtVrs6GIAWKREMdsc2KWhp7H7ue73P9GW+3/CHwzS+ktH+TI2ALKOOHEmAE7/ac+SR sAg6lka07RpV17N2kn+fT643k6URFKk9ykDYmYv7XjsWaocCsBx57GLjCzVo9lxulo4m mLD2+37R5MhzXffmWdBKz1ZjHX3mz+Fwgzw7Wa9tGpkzRqTU6tacalXHXvTAcBfv6lHO 8sCAzWh0ycVHJknFpxCS7mpjaqD5v9LpIXo2jTRrTWMRagFWKPvu19quIlIbOsc+xwsJ tPxjj8OZ65GxlfEnbmhEufcfG19EM7Kr90zc9UPbZ3YFZX0Vt8qtuYpucNQLRJUIMc78 hRzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tVIEwfKcYDxD46meOmGZXDGAcc0cITOPeHQ1rNUdm5c=; b=W8Bih4uqN90OCW/5EUjq9vZRNNum226ZT+rYt0wxSWJuCf22PHV4w7mUFUL7OjSEJA zf1gpes/pX12a4lLhsxxyBfalP2BvKQ4gOt6g5WQTC4Ql6/H1vb+VeHxzQUEHqB9FnsU S0uRQHd3SBp6DAFk//74v/tpjWv0CYsbNqK6JVrlGWlPDz7TBr2iY0BK79A9+tkycRG6 iKp87vgnnEhBEI1oDJOhcW8oyjGNbfIFNhACy1iSlUPKX9rNiq0L6+fLLKG8smd1405h /PKICL8PT0gts2EpOgFvsCg0T6EWLpccVHy0XMIhvTgZRNGAeqlT3S6s6IHotsGCt39d 71qA== X-Gm-Message-State: AGRZ1gJ+Ery+8eTSnAf0vFrZpirbZLCf8dyM52mC09i0QuvuZnluPu7b AvSgE76sAAHrtnOLogTSnfw4w+qUQsUevIMDOo/ukg== X-Google-Smtp-Source: AJdET5e3qvZ8b2xfA3BHRn7UvWg1y8dEaj2APer2Y79RvsB3j+VJy+P2wuNKin8GhZCwM5581lUVLFQmlpvN9Hek2N0= X-Received: by 2002:a1f:8b48:: with SMTP id n69mr2496531vkd.12.1541458667637; Mon, 05 Nov 2018 14:57:47 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 5 Nov 2018 23:57:35 +0100 Message-ID: To: Harald Alvestrand Cc: Sergio Garcia Murillo , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 22:57:51 -0000 On Mon, 5 Nov 2018 at 23:54, Harald Alvestrand wrote= : > If in your example, the writer of the SDP knew that the browser would > discard encodings at the end, it would send > > - 150kbps > - 400kbps > - 1000kbps > - 120kbps > - 750kbps > > That's predictable. > > If it thought "biggest and smallest are most important", it could also > choose to send > > - 120kbps > - 1000kbps > - 400kbps > - 150kbps > - 750kbps > > If it thought "most clients are 400kbps, or 1000kbps, the 120kbps client > is only seen occasionally, and handles 3 streams anyway", > it could send > > - 400kbps > - 1000kbps > - 120kbps > - 150kbps > - 750kbps > > If the behavior of the responder is predictable, the initiator can > achieve the result it wants. Right, my fault. In my mind bitrates had to be ordered. --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 5 15:50:45 2018 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 BCF11126DBF for ; Mon, 5 Nov 2018 15:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 6efKs8dVMRlb for ; Mon, 5 Nov 2018 15:50:40 -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 5E736128CE4 for ; Mon, 5 Nov 2018 15:50:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 78E257C0C76; Tue, 6 Nov 2018 00:50:38 +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 1J_euPDi7ezp; Tue, 6 Nov 2018 00:50:36 +0100 (CET) Received: from [IPv6:2001:67c:1232:144:e6a7:a0ff:fe0b:6b0c] (unknown [IPv6:2001:67c:1232:144:e6a7:a0ff:fe0b:6b0c]) by mork.alvestrand.no (Postfix) with ESMTPSA id D9A0D7C078E; Tue, 6 Nov 2018 00:50:34 +0100 (CET) To: Bernard Aboba Cc: Sergio Garcia Murillo , RTCWeb IETF References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: Date: Tue, 6 Nov 2018 00:50:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7D60C1EBDE2B8EFB90DFFAEC" Content-Language: en-GB Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 23:50:44 -0000 This is a multi-part message in MIME format. --------------7D60C1EBDE2B8EFB90DFFAEC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 11/05/2018 11:16 PM, Bernard Aboba wrote: > Harald said:  > > "Note that our current spec text says that when addTrack is called, a > transceiver is created with the max number of simulcast encodings set to > 1, and that this number cannot be increased. This would have to change." > > [BA] Most of the code examples I have seen that use addTrack for > simulcast call setParameters prior to createOffer().  To allow this, > we might consider saying that when addTrack returns, the encodings are > initially null, and so can be set by setParameters().  We could also allow the number of encodings to be changed in general, with the proviso that if you increase the number, you have to inspect the result to see how many you got (browser would drop extra elements). But this is now deep in API-land, and has wandered far from the original point: That JSEP doesn't allow configuring simulcast from an incoming offer. I think that if JSEP did not make this statement, it would be OK - since we would then be able to obey the rules in -simulcast (if the browser supported it), and leave the rest of the discussion to the API documents. > > On Mon, Nov 5, 2018 at 4:30 PM Harald Alvestrand > wrote: > > On 11/05/2018 02:07 PM, Sergio Garcia Murillo wrote: > > On 05/11/2018 12:45, Harald Alvestrand wrote: > >> I do fear that simulcast will continue to affect parts of the > spec that > >> we don't expect it to. But we don't have the luxury of > specifying it > >> halfway; either we rip it out altogether, or we specify it in > enough > >> detail for interoperable implementation. > > > > I agree to that. If we are able to find an "easy" (i.e. not > > introducing too many changes) I would not have any issues adding > > support to that. > > > > Something like: > > > > - Browser adds a track via addTrack > > > > - Browser call SRD with a recv simulcast m-line offer > > > > - The transceiver is created with one send encoding per rid > offered by > > the SFU with default values and all send encodings except first one > > with active=false (this would be the only required change) > > > > ----- browser encodes/sends a single rtp stream, same as if the > remote > > offer was a non simulcast stream-- > > > > -Browser calls sender.getParameters(), modifies the desired send > > encoding parameters ( scaleResolutionDownBy,  maxFramerate, > > maxBitrate, etc) and enables them by setting active=true > > > > Would this approach fulfill the requirements? > > Yes, I believe so. This is also precisely what I was proposing, except > for the requirement to call addTrack. > > Note that our current spec text says that when addTrack is called, a > transceiver is created with the max number of simulcast encodings > set to > 1, and that this number cannot be increased. This would have to > change. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Surveillance is pervasive. Go Dark. --------------7D60C1EBDE2B8EFB90DFFAEC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/05/2018 11:16 PM, Bernard Aboba wrote:
Harald said: 

"Note that our current spec text says that when addTrack is called, a
transceiver is created with the max number of simulcast encodings set to
1, and that this number cannot be increased. This would have to change."

[BA] Most of the code examples I have seen that use addTrack for simulcast call setParameters prior to createOffer().  To allow this, we might consider saying that when addTrack returns, the encodings are initially null, and so can be set by setParameters(). 

We could also allow the number of encodings to be changed in general, with the proviso that if you increase the number, you have to inspect the result to see how many you got (browser would drop extra elements).

But this is now deep in API-land, and has wandered far from the original point: That JSEP doesn't allow configuring simulcast from an incoming offer.

I think that if JSEP did not make this statement, it would be OK - since we would then be able to obey the rules in -simulcast (if the browser supported it), and leave the rest of the discussion to the API documents.


On Mon, Nov 5, 2018 at 4:30 PM Harald Alvestrand <harald@alvestrand.no> wrote:
On 11/05/2018 02:07 PM, Sergio Garcia Murillo wrote:
> On 05/11/2018 12:45, Harald Alvestrand wrote:
>> I do fear that simulcast will continue to affect parts of the spec that
>> we don't expect it to. But we don't have the luxury of specifying it
>> halfway; either we rip it out altogether, or we specify it in enough
>> detail for interoperable implementation.
>
> I agree to that. If we are able to find an "easy" (i.e. not
> introducing too many changes) I would not have any issues adding
> support to that.
>
> Something like:
>
> - Browser adds a track via addTrack
>
> - Browser call SRD with a recv simulcast m-line offer
>
> - The transceiver is created with one send encoding per rid offered by
> the SFU with default values and all send encodings except first one
> with active=false (this would be the only required change)
>
> ----- browser encodes/sends a single rtp stream, same as if the remote
> offer was a non simulcast stream--
>
> -Browser calls sender.getParameters(), modifies the desired send
> encoding parameters ( scaleResolutionDownBy,  maxFramerate,
> maxBitrate, etc) and enables them by setting active=true
>
> Would this approach fulfill the requirements?

Yes, I believe so. This is also precisely what I was proposing, except
for the requirement to call addTrack.

Note that our current spec text says that when addTrack is called, a
transceiver is created with the max number of simulcast encodings set to
1, and that this number cannot be increased. This would have to change.


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


-- 
Surveillance is pervasive. Go Dark.
--------------7D60C1EBDE2B8EFB90DFFAEC-- From nobody Mon Nov 5 15:55:54 2018 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 AED48128D09 for ; Mon, 5 Nov 2018 15:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WG2x3ek5hx_J for ; Mon, 5 Nov 2018 15:55:51 -0800 (PST) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 DFC84126DBF for ; Mon, 5 Nov 2018 15:55:50 -0800 (PST) Received: by mail-ua1-x930.google.com with SMTP id u19so2828940uae.4 for ; Mon, 05 Nov 2018 15:55:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2b56qXiD26imokbJBdBcuakU4DZ0dxrBzinL7MkvXeM=; b=QAyNOW8HbHCXpHjMQuEwfGOX5lDAheU8kwQrpI+jaI0oYyQS+rIXWRv7aSNut2AR1p LibaLA0lvMRHa7cstCSAM8AQMAKxpmb5mfkdwOzeWHqwlP3K24j16HqrHCDqlylhH4Rz DNze9mSE4oXU5aTYd2t20TWWq+IDHu69WXFLLlrdvcIhYA6vbIXwbKfSOF16+qxrcXsX bqRXMgbXSYunTBW1weutgnfduSwknfLIyhw6Z1QkWuV803zUGjSW2YmVJFumEL8s2nbs 637ipnRv7a+ZvTF/LX6HRjsh1FMBRjoHb8Y13keqfXqKp7rHjeMSsm5vGpS1EB2h6JWC yjuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2b56qXiD26imokbJBdBcuakU4DZ0dxrBzinL7MkvXeM=; b=RjyRi5IcYOwlXTUVmOVdh9efbk/cJOiIaUdL46caDJ9PLhht98azWxRqaFhRZ1cMpe eTTlsnq/sNlTAVhyW2hp9Dq8QCmC2DF3Ru4da3KzsiOdtPKRCbvFu6+Jj+WNJ9fGI0Yh FtAWXPhohJRZXPRwIITtGE92cVw3l8G7/nQsGmbNkSPNCSb3/hzvHrpMQc7FZfXMzRkV 6c4xWAN57zVXA/FG8xFe4C0CvjRDk8gB7JTuEl+bMuw58uwa1HO5cL9ncxw4UyywqhI7 uQHPIsUCWD39nXqt7QG/o8Fc0ysr69mNWNFQTOSF048K9dvyFRZ5jZIkm/VC68H06jRM 4Zyw== X-Gm-Message-State: AGRZ1gKK8hasJa01KuW9q+N2AXAn6x/NxHr71LjrmeCkY3fVTSkjQOZ7 Z10QePhvWfdsusFN6xxg4Y6RbL3AMbrZTltOFHojEg== X-Google-Smtp-Source: AJdET5eeRLGk0mhlq5SsukPq6jalYnCxWq+/cnjYue6NPT1JHp7fJQ8d8VBdOQ1qadvm6pm5LGsTYrG8RJc9IPU0c3k= X-Received: by 2002:ab0:5a4d:: with SMTP id m13mr10565161uad.65.1541462149839; Mon, 05 Nov 2018 15:55:49 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 6 Nov 2018 00:55:38 +0100 Message-ID: To: Harald Alvestrand Cc: Bernard Aboba , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2018 23:55:53 -0000 On Tue, 6 Nov 2018 at 00:50, Harald Alvestrand wrote= : > But this is now deep in API-land, and has wandered far from the original = point: That JSEP doesn't allow configuring simulcast from an incoming offer= . > > I think that if JSEP did not make this statement, it would be OK - since = we would then be able to obey the rules in -simulcast (if the browser suppo= rted it), and leave the rest of the discussion to the API documents. Can I say that it does make any sense that JSEP draft exists? Why should a separate document *also* specify, for example, the PeerConnection setRemoteDescription() or addTransceiver() methods? --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 5 16:59:40 2018 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 989A9126DBF for ; Mon, 5 Nov 2018 16:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 GP9BQwExqhHF for ; Mon, 5 Nov 2018 16:59:38 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 040731293FB for ; Mon, 5 Nov 2018 16:59:38 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id p2-v6so9790096wmc.2 for ; Mon, 05 Nov 2018 16:59:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=lWhVVRtxdLx9CBRQlhPwelKdt6NGFyvlUY+YPkU4vSk=; b=gR1iJKQiUOX8QcG9zTezyYsqD8IJHMIv+oBwhOQXtfheW3DQe5QN/DJBAonkotmp/e vAu3XXjHrVBDINMJ7+gqtwUJqJ2YHOJWY4OfL3Ux6MB64F2FNsCkjYzNZkhaFsUWSdnI tNtp5WrYvu2pq85PWTs9ueaZU64KGZ4sk6Hrhzog7AjtUW+3nc2ot8Ta7VFp7ODGNR2l UB2i9kzsspVTuAAGWSFehVw2FfBmTtarVgnMINqS2glwqpQwqD+psvZA4qKR2SKbfUqA eCW6l4kHZYe+SKqnNst55RxDHLU8+w0m1YB3cldVWrTuOikCEOU8f6vO5kOHNx2qKZ9R 4ECQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=lWhVVRtxdLx9CBRQlhPwelKdt6NGFyvlUY+YPkU4vSk=; b=PbF0PlIs24n3uPV7TrX+yy4VYNWzOfnUoJyAvafWCOSjMlb4hz5559UCJa2+/tJ6Os OP/Hzg9FmD8fpH/nbRNgbNonTg6OeueimVCioyiTDeZ3+c7fbcAiHVmuA7gZ5ZhDE6if 85B0nxqMUy/DxewgUamkekWGhQrLrGII21ola47FzVF7yuKNIfHIZq4HuN1hyAlRYDVn 8Buw0r7Q6BmHOPBPK+vVxdQ/+9oFW2ytFrrHtzVS+ukMK3OHL9WF3+9oWyh4LPytsjlQ DN+fS9eksjppYOScZNqUWTday6dNYgT4NehPYRXs8FxG1k2DVBpxxtt7ccOjvzNa67sC qXkw== X-Gm-Message-State: AGRZ1gK034WHFiEPNdBynpVLSvGrmM1OBlBR+u4aFB67+AFnFwSAjONx bChNGuL8x6R5CRGKE9nmY3upg7gV X-Google-Smtp-Source: AJdET5fh5f6NX4YTSF/j6IkJfkJALYNqtCPkJLZ1+ZfDbqgg8t52zr79e0/GoSnRXMLccOvOFDE+ww== X-Received: by 2002:a1c:9f01:: with SMTP id i1-v6mr291313wme.8.1541465976373; Mon, 05 Nov 2018 16:59:36 -0800 (PST) Received: from [192.168.0.11] (89.141.9.215.dyn.user.ono.com. [89.141.9.215]) by smtp.googlemail.com with ESMTPSA id g10-v6sm33440648wru.39.2018.11.05.16.59.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 16:59:35 -0800 (PST) To: Harald Alvestrand , Bernard Aboba Cc: RTCWeb IETF References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no> From: Sergio Garcia Murillo Message-ID: <50f7f9d1-5259-57d0-4d49-093e98164961@gmail.com> Date: Tue, 6 Nov 2018 02:02:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2018 00:59:40 -0000 On 06/11/2018 0:50, Harald Alvestrand wrote: >> [BA] Most of the code examples I have seen that use addTrack for >> simulcast call setParameters prior to createOffer().  To allow this, >> we might consider saying that when addTrack returns, the encodings >> are initially null, and so can be set by setParameters(). > > We could also allow the number of encodings to be changed in general, > with the proviso that if you increase the number, you have to inspect > the result to see how many you got (browser would drop extra elements). IMHO the number of encodings should be allowed to be changed by setParameters (either for a transceiver started via addTrack or addTransceiver) until the corresponding m-line is negotiated by an SDP O/A (until it has a mid value?). Changing the number of encodings after that, I don't think it is allowed by the simulcast draft. Best regards Sergio From nobody Mon Nov 5 17:10:32 2018 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 50BB012F295 for ; Mon, 5 Nov 2018 17:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 LLWXzWRBz3mT for ; Mon, 5 Nov 2018 17:10:28 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 16B72126DBF for ; Mon, 5 Nov 2018 17:10:28 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id y15-v6so11582913wru.9 for ; Mon, 05 Nov 2018 17:10:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=euyh7wRYq1Yf7oxftp+8CwfETr4OXTpp3kpYidqKVXM=; b=Rl9Uiq2l1tdZAcH9GoSRe/CBjSUU2CIr9WXAIn7UxjxgBAxTvvQtddUZsL03wQVQ+n 50wQT40QpEYH3PgDnKXuJpGF4AWu0WH5H773ps5tEAZaQcTe3xXnDbpB3tNPh9DCX4kU PDXax72qScIT3LTUKBhwtygRHG5T0FrTjIY6piZeZc9UuglHol5Zh3INFrf7vrILgKzq X5ArgVsYomSKPr/t9QeWo238MWhlU6cejkNwhLuU1hA0CiaTy/Fe2bwqfHBjJIuYXxbg rQHad83xPuW+0sWrbOQhgZP3DKk9baavPMnuV5iQdBdOVEvw/a5rkj4BrCFU073T1cm3 eAVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=euyh7wRYq1Yf7oxftp+8CwfETr4OXTpp3kpYidqKVXM=; b=p9nM1jGFGVJXByFmDmpFdVSK7ePH0pD8XWC6WbHvE115REom1DgTLreP75ag0a7NJo OJ7Zc4oTiyP03sDlG2KGROxdDvkMJ3JhqNNdd2OdHpd/NhCmbV9+YnF+9uMNzhtQh9Jw onQZ6wMJvQv4Rp1wXF2yMksZ4uy9wtnH5ARHZ+t/LnLjOeFQuGweGMyWwtffIapC1z/a rnFxGgcEElbOl4Wj9GggWsayYH06ItlCXDid3fVf8F4sc1mLnnVcu/sPbpy7lHWTlqvu SOigF7cesfeDYSPixZvHs5Up9uqAepZdBYl6McTEPrx2BckDGUxwC0nG0d7XuA+sw1nL ZMag== X-Gm-Message-State: AGRZ1gJxBaZw8wRnPzqf76/G1BLn3JNUKwDS8fv+LqeiSBHdP6qtT4u8 sHJA6PdAtlXsoojvYQ34R2BTJL7waPcJdlwKTlw= X-Google-Smtp-Source: AJdET5fVBMJNeOknWy9GHMvPTQXhXN/3lqUw7MtmEovKCHAP4HFeUaeouLIP95m68dJkWuVmudU6TXcHwyu/syV8kho= X-Received: by 2002:adf:9170:: with SMTP id j103-v6mr17424278wrj.217.1541466626574; Mon, 05 Nov 2018 17:10:26 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no> <50f7f9d1-5259-57d0-4d49-093e98164961@gmail.com> In-Reply-To: <50f7f9d1-5259-57d0-4d49-093e98164961@gmail.com> From: Sergio Garcia Murillo Date: Tue, 6 Nov 2018 02:10:14 +0100 Message-ID: To: Harald Alvestrand , Bernard Aboba Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000b5cccd0579f4aa7c" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2018 01:10:31 -0000 --000000000000b5cccd0579f4aa7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable changed my mind, as there is a corner case: addTrack setParameters with multiple encodings SRD with a simulcast recv offer with imcompatible rids than the one in the transceiver what will happen then? El mar., 6 nov. 2018 1:59, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> escribi=C3=B3: > On 06/11/2018 0:50, Harald Alvestrand wrote: > >> [BA] Most of the code examples I have seen that use addTrack for > >> simulcast call setParameters prior to createOffer(). To allow this, > >> we might consider saying that when addTrack returns, the encodings > >> are initially null, and so can be set by setParameters(). > > > > We could also allow the number of encodings to be changed in general, > > with the proviso that if you increase the number, you have to inspect > > the result to see how many you got (browser would drop extra elements). > > IMHO the number of encodings should be allowed to be changed by > setParameters (either for a transceiver started via addTrack or > addTransceiver) until the corresponding m-line is negotiated by an SDP > O/A (until it has a mid value?). Changing the number of encodings after > that, I don't think it is allowed by the simulcast draft. > > Best regards > > Sergio > > --000000000000b5cccd0579f4aa7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
changed my mind, as there is a corner case:

addTrack
setParamete= rs with multiple encodings
SRD with a simulcast recv= offer with imcompatible rids than the one in the transceiver

what will happen then?=C2=A0


El mar., 6 nov. 2018 1:59, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> es= cribi=C3=B3:
On 06/11/2018 0:50, Ha= rald Alvestrand wrote:
>> [BA] Most of the code examples I have seen that use addTrack for <= br> >> simulcast call setParameters prior to createOffer().=C2=A0 To allo= w this,
>> we might consider saying that when addTrack returns, the encodings=
>> are initially null, and so can be set by setParameters().
>
> We could also allow the number of encodings to be changed in general, =
> with the proviso that if you increase the number, you have to inspect =
> the result to see how many you got (browser would drop extra elements)= .

IMHO the number of encodings should be allowed to be changed by
setParameters (either for a transceiver started via addTrack or
addTransceiver) until the corresponding m-line is negotiated by an SDP
O/A (until it has a mid value?). Changing the number of encodings after that, I don't think it is allowed by the simulcast draft.

Best regards

Sergio

--000000000000b5cccd0579f4aa7c-- From nobody Mon Nov 5 17:21:33 2018 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 1CA5D128766 for ; Mon, 5 Nov 2018 17:21:25 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQjSlwtNBFzu for ; Mon, 5 Nov 2018 17:21:22 -0800 (PST) Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (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 93B3212D4EA for ; Mon, 5 Nov 2018 17:21:22 -0800 (PST) Received: by mail-vs1-xe44.google.com with SMTP id g68so3023877vsd.11 for ; Mon, 05 Nov 2018 17:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=VsMswNZ8avdRf5Yb6WwCDAYS3L+NM1P/iDM1bb9j0/Q=; b=CGUGtrWmd/QFV+HlYUoo4+4+TlcVz4NM92yFUBge4mGkp5UeeHU6p7uCG1PU2bHiVf tHSpyEtNsMXyta045hvkkiDkB/39KE8MTjViYtKEOSS95eNig2gJUkKoV3aWtRH/KNkx VKrpsaSd2xPKc9od/VdtQ2hxpP1IkWNsQ2wsy4OXfVX8qZ/rE0wETAna4JL+tEJc6pN2 GNc232vDRp8Tvj8s+z63TUrchg4jjsWXy0jlVgE1ngXUf2knBWRczpEg6+DbvNe6N+8H Ad3Bxif3GFxqGllXaLT6zJZBsKzr5OpWMTKHP8bXgONho5k7mquarXCL36+JThXL4Wf1 43aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=VsMswNZ8avdRf5Yb6WwCDAYS3L+NM1P/iDM1bb9j0/Q=; b=H8H277/heFgTuE+MI9YptWflfBt0ziIJjayEQ7WqLlkH05ALbjtveolvfrrPnJrjuT WVgyAIfnZXoQLTUTqjwjWHRBO/xIYMWrIeya5Nuo5C2yvbv8RMtQw09TN3OKEb440zad jyZ8NoK6bfu7+BTSQmJlrSaxJYWgNl6Q7CT4pvgvj09jqbeCuY/Bhdqk94htHtczTol4 09qvP+X//j92E0sKgwSpyHkrlSrtXrhWZJ/SIGQRYuAgE7PZ6+tG/aPAA89iY5LVjEj2 g4PE8Wwj1nzZiHZlB/U+ownkAhpKTJuy0orf+kIAvqpDX6vf97wGvx8hshNTu4pFj5/b Vz7Q== X-Gm-Message-State: AGRZ1gJESGxgaqV0JOJDl5dmOcCed+thX/0qbdBcUQd0YcwE8xRldWf8 bzZPbvCRwaYvONHLFB3akUhcB1YpuvuP2IGvkt7Neg== X-Google-Smtp-Source: AJdET5eiY8u+v8F/Gt9sV9O4oUxRiOH5+ya0CAsPpcvJyipEN2tkdmPD+meavHXnqSgWqFRGevu+E0Z2H42YGbJduig= X-Received: by 2002:a67:6281:: with SMTP id w123-v6mr10556808vsb.68.1541467281605; Mon, 05 Nov 2018 17:21:21 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <31fb92c1-2934-c33f-a3cf-552f027eacda@alvestrand.no> <5db76ada-b896-7eba-b42e-85b2e239dc42@alvestrand.no> <150c76b7-64eb-2e75-c9e0-2f503e705e4b@alvestrand.no> <50f7f9d1-5259-57d0-4d49-093e98164961@gmail.com> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 6 Nov 2018 02:21:09 +0100 Message-ID: To: Sergio Garcia Murillo Cc: Harald Alvestrand , Bernard Aboba , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2018 01:21:25 -0000 On Tue, 6 Nov 2018 at 02:10, Sergio Garcia Murillo wrote: > changed my mind, as there is a corner case: > > addTrack > setParameters with multiple encodings > SRD with a simulcast recv offer with imcompatible rids than the one in th= e transceiver > > what will happen then? For me this is like if you play by setting different parameters into a RtpSender before creating an offer (or even before applying it with sLD). If you set sending simulcast parameters but do not apply it, and later you call sRD, then settings generated by sRD should override your non-applied settings. --=20 I=C3=B1aki Baz Castillo From nobody Tue Nov 6 18:15:08 2018 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 B5E1F126DBF for ; Tue, 6 Nov 2018 18:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 TZzdam0v7mPb for ; Tue, 6 Nov 2018 18:15:05 -0800 (PST) Received: from smtp89.ord1c.emailsrvr.com (smtp89.ord1c.emailsrvr.com [108.166.43.89]) (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 4E711126CB6 for ; Tue, 6 Nov 2018 18:15:05 -0800 (PST) Received: from smtp12.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp12.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 99ADEC02C1; Tue, 6 Nov 2018 21:15:03 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp12.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 8DC1EC021A; Tue, 6 Nov 2018 21:14:29 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.68.213.148] ([UNAVAILABLE]. [173.39.121.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.7.12); Tue, 06 Nov 2018 21:15:03 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_34A9BDA7-3A09-4D60-9BAE-F1F1D186159B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Wed, 7 Nov 2018 09:14:15 +0700 Cc: Bernard Aboba , RTCWeb IETF Message-Id: References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <5FB0A50F-DAF3-47C4-A5F5-8DA20586C9E2@iii.ca> To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 02:15:07 -0000 --Apple-Mail=_34A9BDA7-3A09-4D60-9BAE-F1F1D186159B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 5, 2018, at 7:14 PM, I=C3=B1aki Baz Castillo = wrote: >=20 > If you excluded the word "interop" from any rationale, life would be > much better, specially here where such an interop: >=20 > 1) does not exist > 2) is not needed >=20 > To be clear: No app in the world is or will be NEVER ready to enable > simulcast auto-magically just because it eventually receives a > different SDP offer from the remote. The app developers would already > figured out different ways to enable simulcast that would just not > allow such an auto-magic "upgrade". >=20 Let me put this as politely and straight forward as I can. You are = wrong.=20 --Apple-Mail=_34A9BDA7-3A09-4D60-9BAE-F1F1D186159B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On = Nov 5, 2018, at 7:14 PM, I=C3=B1aki Baz Castillo <ibc@aliax.net> = wrote:

If you excluded the word "interop" from any = rationale, life would be
much better, specially here where such an = interop:

1) does not = exist
2) is not needed

To be clear: No app in the world is or will be = NEVER ready to enable
simulcast auto-magically just because it = eventually receives a
different SDP offer from the remote. The = app developers would already
figured out different ways to enable = simulcast that would just not
allow such an auto-magic = "upgrade".



Let me put this as politely = and straight forward as I can. You are wrong. 



= --Apple-Mail=_34A9BDA7-3A09-4D60-9BAE-F1F1D186159B-- From nobody Tue Nov 6 18:56:15 2018 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 83CA8127332 for ; Tue, 6 Nov 2018 18:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bu3vcAvU_MiR for ; Tue, 6 Nov 2018 18:56:11 -0800 (PST) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 E8186126CB6 for ; Tue, 6 Nov 2018 18:56:10 -0800 (PST) Received: by mail-vs1-xe2e.google.com with SMTP id y27so6808542vsi.1 for ; Tue, 06 Nov 2018 18:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=diH48zxE1jXlKd4RTpZievTuGDiGfkLUeX0SQI7glaU=; b=OSfrRf8z5+Qmh+OZQzH+tt9+tgaCct/GiZmsgD1bgHbWgRCxpWytsry6DFW+5gXOUJ 6l0RrMCUjP1PWYOe8Bx3apajm+AOghp2pb8zDOeKl27TpnEx+Sq7Nu/ihL3vMKMk82xv y2l4wxglLvE2aNp7/sl/uIqwe2xrGq5JwxkCZTBjyvgAUJ85QzdSBIZxTx6IVJh164lR rKfUjco+3+XCOkE9OSYF8U+co63c7po7LfDkG6pvZOQqoQP23kQTKPKMVYiaFZXKxweV 0SACkPEkAIouwdjy0+zJu4u2HOhOasMO24KNDa3Z2nCMhFmDfVUzxhikbjSHp82Vxs0O VqQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=diH48zxE1jXlKd4RTpZievTuGDiGfkLUeX0SQI7glaU=; b=JgtCBk0cuY6lxh6LQxlW6xa8C6Hpx7Voy958uVg+uJNGF3GImqDO3VsmwdUmZ1tXjL xm2CqOy5qK3/BkxuVVKzs85yNNTL8q9/uwOCuFYmEUe7j6nIop43gA0WE//sVJnms63M Y3b2KX0JDJrJCkUyzf5TK1nIHDrbzuIvIwJ3XVKc9AqYYyVt10H48tyoGZNercVD+BXP 7fekJSRfjcUWmXJlwNtNMo3vMRubc453FIMrk1Z4Qslap6QiXgKQHdzO9947/R7V3xCh rGVgPjbAdP9zWJOYqhP7hgjqBj8dYIOBEcgbN2UAR0KRo3A8tLF5ian/ZvqBsff8ndGp Ns+Q== X-Gm-Message-State: AGRZ1gKki4wUpe394QbaOkPJt4XyI09UgGD7IQsxdmGOcvHYhEmkoEnm JJKVNqhDu2olupvOZ1e5wVKd8YRPeISLDLmVFDnkqg== X-Google-Smtp-Source: AJdET5dwh9sqSvHe43TDzLSLz21CQbW9Nw+xPZE4CN/1nDAcy2188/K2xEF/SErN4E+TErMMnMWdDjolJ2ZiR8YippM= X-Received: by 2002:a67:3659:: with SMTP id d86mr46095vsa.17.1541559369906; Tue, 06 Nov 2018 18:56:09 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <5FB0A50F-DAF3-47C4-A5F5-8DA20586C9E2@iii.ca> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 7 Nov 2018 03:55:58 +0100 Message-ID: To: Cullen Jennings Cc: Bernard Aboba , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 02:56:14 -0000 On Wed, 7 Nov 2018 at 03:15, Cullen Jennings wrote: > > > On Nov 5, 2018, at 7:14 PM, I=C3=B1aki Baz Castillo wrote= : > > If you excluded the word "interop" from any rationale, life would be > much better, specially here where such an interop: > > 1) does not exist > 2) is not needed > > To be clear: No app in the world is or will be NEVER ready to enable > simulcast auto-magically just because it eventually receives a > different SDP offer from the remote. The app developers would already > figured out different ways to enable simulcast that would just not > allow such an auto-magic "upgrade". > > > > Let me put this as politely and straight forward as I can. You are wrong. May be. But all proposals here about enabling local simulcast upon receipt of a remote SDP offer require app/JS interaction. The local app must be able to decide whether send simulcast or not given the current CPU/battery usage or network conditions. It does not make any sense that just because the app receives a remote blob, it starts sending 2-3 video layers without app consent. That's why, as the discussion has been evolving, the winning proposal is that in which, upon receipt of the remote SDP offer, the app must enable simulcast by itself. --=20 I=C3=B1aki Baz Castillo From nobody Tue Nov 6 19:09:23 2018 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 240FC128CE4 for ; Tue, 6 Nov 2018 19:09:21 -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 nJ7PBl_qP8oj for ; Tue, 6 Nov 2018 19:09:19 -0800 (PST) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (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 5392B130DC7 for ; Tue, 6 Nov 2018 19:09:19 -0800 (PST) Received: by mail-vk1-xa31.google.com with SMTP id o10-v6so3394277vki.6 for ; Tue, 06 Nov 2018 19:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DA4c/thwcUvTh5XtTYzUFBFi0tNuw9Ck7KUHuaoqps8=; b=MBYUIhwHzTMDdrcWmKyohyEDiLy8hgoFUPCp8qxitELWaVRYVYgvSSkhaBDHxM+bCV nysAYJ2QmIY3cjLTwOxBhs+8AhdCnQjiyg/8JgVIjTw5vOT9q8U12YK8/Ur7ZckTkpVn qWLfyH8DGzkq62TYoh6SqxySEUIqzcdnda8lZYmjYuDZLH0Cb4RPxeKz4sVbnxp6sKIS wyziKj3ZHw9yYh/qDUy7HnDfnyw/cdqIdN+kVPCSUOO07CY5bG519vXa2IdJOay8bthN jDWOtkx5lpj/Eo7qUGrTz0LFRtdP48NlnQR7mcgzFgTvRQ/XlzcZo4pIUz4t1I0+cLVG 6Pcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DA4c/thwcUvTh5XtTYzUFBFi0tNuw9Ck7KUHuaoqps8=; b=frhBvSSjS+Ilq7/EWQn1UoMsIP7I3aykQ8axkqPIexUOFa8GHNmy2WJ6IE1l3oOWG9 j1nlSAzFMIdNwiO6VUbsWo7yXG51MWn7yWGtClI9Np9c1h9/Y4QEVmZDJybNq3QH27EL aMDY2+09eNG89d2CzXzOGgE6VZd5wo20c98hksiY3PUzAwYzgZeO1ZmQpakVgf1JOBy6 HYhyGca8K7Mk0oL1HiO1sMd00Tut5nR29SmDRk5toZ8r3BH1O3zctOA4mCDnEvTQZ3LS mMIhjz7gvDusZB9LLVqiaRtjYwAakb2jg2Eg1NwqgKHwNqleZsnNLkB1hD0TkjbUFbvu 34lw== X-Gm-Message-State: AGRZ1gK6i883hqc7+pWWsMniFT5dcqv3obJj37v2yKzbNgY/1MKeaKoS 1nqFPFY7eJuiaBttoDyBjl71tMw1cAHAehMmAmew+g== X-Google-Smtp-Source: AJdET5c8CIwxRwgpm1HcuEv59rZ47Ekl8MGowUM1c2njOEfX14OGcwqiwOP3XjujJy+KGf5krXaCep7WS2J4V8xrnTg= X-Received: by 2002:a1f:2ed7:: with SMTP id u206mr59783vku.72.1541560158166; Tue, 06 Nov 2018 19:09:18 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <5FB0A50F-DAF3-47C4-A5F5-8DA20586C9E2@iii.ca> In-Reply-To: From: Bernard Aboba Date: Tue, 6 Nov 2018 22:09:06 -0500 Message-ID: To: Cullen Jennings Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000a0a2f2057a0a717e" Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 03:09:21 -0000 --000000000000a0a2f2057a0a717e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cullen said: "Let me put this as politely and straight forward as I can. You are wrong.= " [BA] I would agree that API interoperability is needed for simulcast, even if it doesn't yet exist because we're still ironing out the Issues. The interest in implementation appears to be quite high, so once we figure these things out (assuming we make the specification clear enough to avoid further confusion), we stand a chance of interoperablity in both APIs and protocols, which is after all, the point of developing a standard. In that respect, I would prefer if JSEP would include some guidance we could cite in WebRTC-PC, rather than having to provide clarifications within the API document itself. On Tue, Nov 6, 2018 at 9:15 PM Cullen Jennings wrote: > > On Nov 5, 2018, at 7:14 PM, I=C3=B1aki Baz Castillo wrote= : > > If you excluded the word "interop" from any rationale, life would be > much better, specially here where such an interop: > > 1) does not exist > 2) is not needed > > To be clear: No app in the world is or will be NEVER ready to enable > simulcast auto-magically just because it eventually receives a > different SDP offer from the remote. The app developers would already > figured out different ways to enable simulcast that would just not > allow such an auto-magic "upgrade". > > > > Let me put this as politely and straight forward as I can. You are wrong. > > > > --000000000000a0a2f2057a0a717e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Cullen said:=C2=A0

"Let me put thi= s as politely and straight forward as I can.=C2=A0 You are wrong."

[BA] I would agree that API interoperability is neede= d for simulcast, even if it doesn't yet exist because we're still i= roning out the Issues.=C2=A0 The interest in implementation appears to be q= uite high, so once we figure these things out (assuming we make the specifi= cation clear enough to avoid further confusion), we stand a chance of inter= operablity in both APIs and protocols, which is after all, the point of dev= eloping a standard.=C2=A0

In that respect, I would= prefer if JSEP would include some guidance we could cite in WebRTC-PC, rat= her than having to provide clarifications within the API document itself.

On Tue, Nov 6, 20= 18 at 9:15 PM Cullen Jennings <fluffy@i= ii.ca> wrote:

On Nov 5, 2018, at 7:14 PM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:

If you excluded the word "interop" from any = rationale, life would be
much bet= ter, specially here where such an interop:

1) does not exist
2) is = not needed

To be clear: No app in = the world is or will be NEVER ready to enable
simulcast auto-magically just because it eventually receives a=
different SDP offer from the rem= ote. The app developers would already
figured out different ways to enable simulcast that would just not
allow such an auto-magic "upgra= de".



Let me put t= his as politely and straight forward as I can. You are wrong.=C2=A0



--000000000000a0a2f2057a0a717e-- From nobody Tue Nov 6 23:40:08 2018 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 8FBC5129BBF for ; Tue, 6 Nov 2018 23:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.792 X-Spam-Level: X-Spam-Status: No, score=-3.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=dK6Luv54; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Y29K5u6i 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 1bK5gkypSj50 for ; Tue, 6 Nov 2018 23:40:04 -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 CD263127333 for ; Tue, 6 Nov 2018 23:40:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541576401; x=1544168401; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GUN58M6fhWBmoyw8pZYxqcPr+MaVeBIR1Emn8wlb7u0=; b=dK6Luv54RVzfLlBYBDYKG8+3mE0TglNFLlUOSBrDCZnFtHvJoGMx+1UHpJsvvZ1Q yiuN5JEG/hgkEuoPPWzfQlzJqilv3PKOYX4X+9sSZ5/hG24tmLK4RCcyqUtDcmek KGdfWwC4+xzaNfg0tk12OSyJ8AZDAL1RqLCe4jU6aRQ=; X-AuditID: c1b4fb3a-477ff70000002747-eb-5be296d19137 Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BA.D8.10055.1D692EB5; Wed, 7 Nov 2018 08:40:01 +0100 (CET) Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESSMB503.ericsson.se (153.88.183.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 7 Nov 2018 08:40:01 +0100 Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMR505.ericsson.se (153.88.183.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 7 Nov 2018 08:40:01 +0100 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 7 Nov 2018 08:40:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GUN58M6fhWBmoyw8pZYxqcPr+MaVeBIR1Emn8wlb7u0=; b=Y29K5u6iBQ0CvWLx0h6P9qt5EgHxmsG+zOxfm7AQIMXNR7OdMigYKgTrB7WgTu/pCHIiqb5WCH1fMIcWe25cMOnMDz6BT86amOhfj6hsDXNFb7DjcQTk0zg1i32MCB522ROSd2g38Z34rFe0dLjlmF5i6WzzmVOU4dzOmR9Qaj4= Received: from HE1PR0702MB3803.eurprd07.prod.outlook.com (52.133.7.21) by HE1PR0702MB3834.eurprd07.prod.outlook.com (52.133.7.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.15; Wed, 7 Nov 2018 07:40:00 +0000 Received: from HE1PR0702MB3803.eurprd07.prod.outlook.com ([fe80::39af:5668:c1c0:d0b5]) by HE1PR0702MB3803.eurprd07.prod.outlook.com ([fe80::39af:5668:c1c0:d0b5%4]) with mapi id 15.20.1294.034; Wed, 7 Nov 2018 07:39:59 +0000 From: =?utf-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= To: "bernard.aboba@gmail.com" , "fluffy@iii.ca" CC: "rtcweb@ietf.org" Thread-Topic: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? Thread-Index: AQHUdBZUTg0cJIWSI0uXT0gq1ZU2QaU/SkGAgADuQYCAAAF8AIAAa0GAgAB0wICAAnz9gIAAD1MAgABLr4A= Date: Wed, 7 Nov 2018 07:39:59 +0000 Message-ID: <1541576399.5384.7.camel@ericsson.com> References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <5FB0A50F-DAF3-47C4-A5F5-8DA20586C9E2@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.18.5.2-0ubuntu3.2 x-originating-ip: [192.176.1.83] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3834; 6:sQirBbHGxumUvEc6c70Ui5hTQt+Lmj9Dxy2MVRUVL7dCdtgh08BVIU8SnwzkjmVfH4eHWc2UbRZhPSphLzuYEvUkhwkRJsesqyk6Nfx1OFODP1HuNCCo1a/Qz5glrLzKtfibuYQVK/Vs78ejpXCz6dF0yQ7IQeT3ipiaRq+f3CHBdPVSJlkHaSBmV2yuWmjVJYwl+aHH3Fq6z1nAMqy5a5Ys97KAT9+lZBxztQ7muVGTN8ySvWoeTCNJNGaYNh1qXrMTP9sJ/WDRsfFGHkBLSD6kJcFZJNKCjZuQYhvHXWs8Juxihng2dtCnfjsq3bnoc44ie7St0DeCh/8a/ls03pvfia5v93P0+j7UzzX1zXqBlqJnb64CSSQYxOn6DZwIQUzrNXys5Hk9h7Chbx3bDn6Ry2em+TwLIbyveOXC+SDdxI4Y0m6KrL9kAZHs/4GA+DmcGXiv6bo9lPHRApdDTg==; 5:dkNt8hGHBfSyxO3Jad9ioYRf5NVjlhXNjFnk6Ost1CePUbHYOCwNlv6UOHLywvYMdb2NnnEfW8utUjFUAo9efgqGFxbaRQdnlBPdz9rNiK3gi/JPLqlwAxfO6Wz77J2zoeolXWyZCDgjSRqR1fQY9+RHvwZIQQbKamsJ4zI/mR4=; 7:9nqaU07BB6gZr6rp7hEhPV3JL9SrKIu1SkdtFPDcILghWwwGnZAkkNlXWctrTXaKksDs3jc7Upcpnb9YzbE3HTSsext1SVx1NaolTbRxq1n8kLJPMm4wxbHEKvKHPYYJypUeOUSnGXBgpadyXmrRIg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 6dc4f392-92ca-4edb-1782-08d6448438d5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR0702MB3834; x-ms-traffictypediagnostic: HE1PR0702MB3834: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stefan.lk.hakansson@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1PR0702MB3834; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0702MB3834; x-forefront-prvs: 08497C3D99 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(366004)(346002)(376002)(39860400002)(199004)(189003)(6506007)(66574009)(478600001)(71190400001)(2906002)(68736007)(93886005)(6436002)(53546011)(7736002)(39060400002)(305945005)(71200400001)(229853002)(2501003)(5660300001)(76176011)(25786009)(110136005)(6306002)(6512007)(99286004)(6486002)(103116003)(6246003)(316002)(8936002)(26005)(8676002)(97736004)(446003)(476003)(36756003)(81166006)(81156014)(50226002)(11346002)(102836004)(53936002)(4326008)(106356001)(486006)(85202003)(186003)(6116002)(105586002)(2900100001)(3846002)(2616005)(85182001)(14454004)(14444005)(966005)(66066001)(256004)(86362001)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3834; H:HE1PR0702MB3803.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: m8lPfaT99BQPqBAtWHkubFCovOkK9cYF2eeHfUsTfTxGWVzjmla+8o3aBfDyqnZFX/ebmwxtPX+dFPj5bKjroeunxFdSfF6xdlTwGyc8rBa+FXbI9Nbx6UnMmkX7zhxlkEwn4kvK5H0OK1XWGBe6wW78/SiPD5vhfHPOsVap3COuvoFwbT/GWZHKW3KyGZAijDPUd42FpO9jy5KL/0xva4KM/2eoguVQ+6eXuxcF7Jip5DuHfmpnY2be8oy6bW0+JM9LC7/qNzxO/vg2+j/HaUk3kP50SGES6kVctehR5v9tWNuqxZb+2Z81S4cTSlD/NmQTJp/yOuCIudT+L4eLkrdicFoQ/Wj1p1WHPG3bJcA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4197DAB50BB655409E44652C68E365A7@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6dc4f392-92ca-4edb-1782-08d6448438d5 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2018 07:39:59.8115 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3834 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee69266jwdPSPGpJjcqMfBt+WCllQbYPhb0RoWJOd6cj39q1 kYEpgmZKMMtZW5nhTMW3WYhpiqFZoElaUphM3EzLiMqB4nKlud1Fffv9z/mfc54/PDQpvsfz p9VZuYwmS5Eh4Qspw7kneSFvqmYSwvusUll73xopWzA7kKx19ZoghpR3G6cE8rq6n4R8fNSO TpDxwmglk6HWMpqwA8nC9MVeGy9nzP+ydcYiKEQOvzLkRQOOhKmVClSGhLQYDyJwvHrH48QS gvpSwz9Rahny2EwEdDs/kC5BYR0JFWXNAq5zk4D7v+wkJ+YQmF9aKdcZPj4NY4YSwsXeOB5m fi/zXEziILCYXq9P0/QmnABd09GcJRGm7WY+xynwo+2Omym8Az7Z5gQuFmEpWHVrnsMOEnSd te6dXvgklDhG3IzwZlgebiG4W74wOVtDcLEx1PWOkhz7wJePqzyOd4O+vwVxvA0s+lYBx1vh bU25Oz/gCT7MNVZ7FoXAgl7vWXQcnKYXFGcaQnDL2eCZ3gsPu/SEKyXCqXC7OJYrZ0N7z3dK hyKN/73PuO4icTCYn4ZxZTlU2J9THG+HynKbwOjOvxGGDLPUA8RrQj4sw7KZaVJpKKNRp7Js dlZoFpP7GK3/mf4O5/4u1P/50ADCNJJsENmLZxLEPIWWzcscQECTEm+RM3m9JFIq8q4wmuzz mksZDDuAAmhK4is6rJLFi3GaIpe5wDA5jOZvl6C9/AsR2dO8oN3ZONKYpCvK0SrPqL7GLi6q jhx8pJxSxd0Qv4/LlGUItO1nDSaJpu1ZpC3g6sVBvvGoNakmr/PY3YiVff5B8/XhtQ1L40RB 0RZ5VBW7GJN6SjoZ5a2SXJ+sTElOrA4sGjHNWdTf2vKbLLuqA1tJv+CE/PmCtolJ5XCHhGLT FRF7SA2r+AMpiv48LwMAAA== Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 07:40:07 -0000 SWYgbWVtb3J5IHNlcnZlcywgd2Ugb3JpZ2luYWxseSBoYWQgdGhlIG1vZGVsIHRoYXQgdGhlIGF1 dGhvciBvZiB0aGUNCndlYiBhcHAgYW5kIHRoZSBkZXZlbG9wZXIgb2YgdGhlIHJlY2VpdmVyIG9m IHNpbXVsY2FzdCB3b3VsZCBjb29wZXJhdGUsDQppbiBvdGhlciB3b3JkcyB0aGUgc2ltdWxjYXN0 IHJlY2VpdmVyIHdvdWxkIHNlbmQgZW5vdWdoIGluZm8gKGluIGZvcm0NCm9mIHdoYXRldmVyKSBm b3IgdGhlIHdlYiBhcHAgdG8gY29ycmVjdGx5IHNldCB1cCBzaW11bGNhc3QgdXNpbmcgdGhlDQph dmFpbGFibGUgQVBJcyBhbmQgdGhlbiBzZW5kIGFuIG9mZmVyIFNEUC4gSSB0aGluayB0aGlzIGlz IHdoYXQgSW5ha2kNCmlzIHNheWluZy4NCg0KSWYgdGhpcyBub3cgaGFzIGNoYW5nZWQsIGFuZCB3 ZSBjYW4gaGF2ZSB0aGUgc2ltdWxjYXN0IHJlY2VpdmVyIHNlbmQgYW4NClNEUCBvZmZlciB0aGF0 IGlzIGFwcGxpZWQgaW4gdGhlIGJyb3dzZXIgYW5kIHRoaW5ncyB3b3JrIChwZXJoYXBzIHdpdGgN CnNvbWUgd2ViIGFwcCBpbnRlcnZlbnRpb24pLCBhbmQgd2UgaGF2ZSBwZW9wbGUgaW50ZXJlc3Rl ZCBpbg0KaW1wbGVtZW50aW5nIHRoaXMsIEkgcGVyc29uYWxseSBzZWUgbm8gcmVhc29uIHdoeSB0 aGF0IHNob3VsZCBub3QgYmUNCnB1cnN1ZWQuDQoNCkJyLCBTdGVmYW4NCg0KT24gdGlzLCAyMDE4 LTExLTA2IGF0IDIyOjA5IC0wNTAwLCBCZXJuYXJkIEFib2JhIHdyb3RlOg0KPiBDdWxsZW4gc2Fp ZDrCoA0KPiANCj4gIkxldCBtZSBwdXQgdGhpcyBhcyBwb2xpdGVseSBhbmQgc3RyYWlnaHQgZm9y d2FyZCBhcyBJIGNhbi7CoCBZb3UgYXJlDQo+IHdyb25nLiINCj4gDQo+IFtCQV0gSSB3b3VsZCBh Z3JlZSB0aGF0IEFQSSBpbnRlcm9wZXJhYmlsaXR5IGlzIG5lZWRlZCBmb3Igc2ltdWxjYXN0LA0K PiBldmVuIGlmIGl0IGRvZXNuJ3QgeWV0IGV4aXN0IGJlY2F1c2Ugd2UncmUgc3RpbGwgaXJvbmlu ZyBvdXQgdGhlDQo+IElzc3Vlcy7CoCBUaGUgaW50ZXJlc3QgaW4gaW1wbGVtZW50YXRpb24gYXBw ZWFycyB0byBiZSBxdWl0ZSBoaWdoLCBzbw0KPiBvbmNlIHdlIGZpZ3VyZSB0aGVzZSB0aGluZ3Mg b3V0IChhc3N1bWluZyB3ZSBtYWtlIHRoZSBzcGVjaWZpY2F0aW9uDQo+IGNsZWFyIGVub3VnaCB0 byBhdm9pZCBmdXJ0aGVyIGNvbmZ1c2lvbiksIHdlIHN0YW5kIGEgY2hhbmNlIG9mDQo+IGludGVy b3BlcmFibGl0eSBpbiBib3RoIEFQSXMgYW5kIHByb3RvY29scywgd2hpY2ggaXMgYWZ0ZXIgYWxs LCB0aGUNCj4gcG9pbnQgb2YgZGV2ZWxvcGluZyBhIHN0YW5kYXJkLsKgDQo+IA0KPiBJbiB0aGF0 IHJlc3BlY3QsIEkgd291bGQgcHJlZmVyIGlmIEpTRVAgd291bGQgaW5jbHVkZSBzb21lIGd1aWRh bmNlDQo+IHdlIGNvdWxkIGNpdGUgaW4gV2ViUlRDLVBDLCByYXRoZXIgdGhhbiBoYXZpbmcgdG8g cHJvdmlkZQ0KPiBjbGFyaWZpY2F0aW9ucyB3aXRoaW4gdGhlIEFQSSBkb2N1bWVudCBpdHNlbGYu DQo+IA0KPiBPbiBUdWUsIE5vdiA2LCAyMDE4IGF0IDk6MTUgUE0gQ3VsbGVuIEplbm5pbmdzIDxm bHVmZnlAaWlpLmNhPiB3cm90ZToNCj4gPiANCj4gPiA+IE9uIE5vdiA1LCAyMDE4LCBhdCA3OjE0 IFBNLCBJw7Fha2kgQmF6IENhc3RpbGxvIDxpYmNAYWxpYXgubmV0Pg0KPiA+ID4gd3JvdGU6DQo+ ID4gPiANCj4gPiA+IElmIHlvdSBleGNsdWRlZCB0aGUgd29yZCAiaW50ZXJvcCIgZnJvbSBhbnkg cmF0aW9uYWxlLCBsaWZlIHdvdWxkDQo+ID4gPiBiZQ0KPiA+ID4gbXVjaCBiZXR0ZXIsIHNwZWNp YWxseSBoZXJlIHdoZXJlIHN1Y2ggYW4gaW50ZXJvcDoNCj4gPiA+IA0KPiA+ID4gMSkgZG9lcyBu b3QgZXhpc3QNCj4gPiA+IDIpIGlzIG5vdCBuZWVkZWQNCj4gPiA+IA0KPiA+ID4gVG8gYmUgY2xl YXI6IE5vIGFwcCBpbiB0aGUgd29ybGQgaXMgb3Igd2lsbCBiZSBORVZFUiByZWFkeSB0bw0KPiA+ ID4gZW5hYmxlDQo+ID4gPiBzaW11bGNhc3QgYXV0by1tYWdpY2FsbHkganVzdCBiZWNhdXNlIGl0 IGV2ZW50dWFsbHkgcmVjZWl2ZXMgYQ0KPiA+ID4gZGlmZmVyZW50IFNEUCBvZmZlciBmcm9tIHRo ZSByZW1vdGUuIFRoZSBhcHAgZGV2ZWxvcGVycyB3b3VsZA0KPiA+ID4gYWxyZWFkeQ0KPiA+ID4g ZmlndXJlZCBvdXQgZGlmZmVyZW50IHdheXMgdG8gZW5hYmxlIHNpbXVsY2FzdCB0aGF0IHdvdWxk IGp1c3QNCj4gPiA+IG5vdA0KPiA+ID4gYWxsb3cgc3VjaCBhbiBhdXRvLW1hZ2ljICJ1cGdyYWRl Ii4NCj4gPiA+IA0KPiA+IA0KPiA+IExldCBtZSBwdXQgdGhpcyBhcyBwb2xpdGVseSBhbmQgc3Ry YWlnaHQgZm9yd2FyZCBhcyBJIGNhbi4gWW91IGFyZQ0KPiA+IHdyb25nLsKgDQo+ID4gDQo+ID4g DQo+ID4gDQo+ID4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4gcnRjd2ViQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2Vi From nobody Wed Nov 7 02:37:05 2018 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 A027E129619 for ; Wed, 7 Nov 2018 02:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 R5DA6n-Rf323 for ; Wed, 7 Nov 2018 02:37:01 -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 D69D1129BBF for ; Wed, 7 Nov 2018 02:37:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 433147C0954 for ; Wed, 7 Nov 2018 11:36:59 +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 GOxvHf-b4Nw3 for ; Wed, 7 Nov 2018 11:36:57 +0100 (CET) Received: from [IPv6:2001:67c:1232:144:e6a7:a0ff:fe0b:6b0c] (unknown [IPv6:2001:67c:1232:144:e6a7:a0ff:fe0b:6b0c]) by mork.alvestrand.no (Postfix) with ESMTPSA id A61097C0930 for ; Wed, 7 Nov 2018 11:36:55 +0100 (CET) To: rtcweb@ietf.org References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <5FB0A50F-DAF3-47C4-A5F5-8DA20586C9E2@iii.ca> <1541576399.5384.7.camel@ericsson.com> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <4de0a6ce-5942-0808-817f-1494b52987a5@alvestrand.no> Date: Wed, 7 Nov 2018 11:36:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1541576399.5384.7.camel@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 10:37:04 -0000 On 11/07/2018 08:39 AM, Stefan Håkansson LK wrote: > If memory serves, we originally had the model that the author of the > web app and the developer of the receiver of simulcast would cooperate, > in other words the simulcast receiver would send enough info (in form > of whatever) for the web app to correctly set up simulcast using the > available APIs and then send an offer SDP. I think this is what Inaki > is saying. This works as long as the initial offer is generated by the browser. > > If this now has changed, and we can have the simulcast receiver send an > SDP offer that is applied in the browser and things work (perhaps with > some web app intervention), and we have people interested in > implementing this, I personally see no reason why that should not be > pursued. Yes, there appears to be strong interest. > > Br, Stefan > > On tis, 2018-11-06 at 22:09 -0500, Bernard Aboba wrote: >> Cullen said:  >> >> "Let me put this as politely and straight forward as I can.  You are >> wrong." >> >> [BA] I would agree that API interoperability is needed for simulcast, >> even if it doesn't yet exist because we're still ironing out the >> Issues.  The interest in implementation appears to be quite high, so >> once we figure these things out (assuming we make the specification >> clear enough to avoid further confusion), we stand a chance of >> interoperablity in both APIs and protocols, which is after all, the >> point of developing a standard.  >> >> In that respect, I would prefer if JSEP would include some guidance >> we could cite in WebRTC-PC, rather than having to provide >> clarifications within the API document itself. >> >> On Tue, Nov 6, 2018 at 9:15 PM Cullen Jennings wrote: >>>> On Nov 5, 2018, at 7:14 PM, Iñaki Baz Castillo >>>> wrote: >>>> >>>> If you excluded the word "interop" from any rationale, life would >>>> be >>>> much better, specially here where such an interop: >>>> >>>> 1) does not exist >>>> 2) is not needed >>>> >>>> To be clear: No app in the world is or will be NEVER ready to >>>> enable >>>> simulcast auto-magically just because it eventually receives a >>>> different SDP offer from the remote. The app developers would >>>> already >>>> figured out different ways to enable simulcast that would just >>>> not >>>> allow such an auto-magic "upgrade". >>>> >>> Let me put this as politely and straight forward as I can. You are >>> wrong.  >>> >>> >>> >>> >> _______________________________________________ >> 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. From nobody Wed Nov 7 03:34:52 2018 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 4741F129619 for ; Wed, 7 Nov 2018 03:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fWviV3vWKvM for ; Wed, 7 Nov 2018 03:34:48 -0800 (PST) Received: from mail-ua1-x944.google.com (mail-ua1-x944.google.com [IPv6:2607:f8b0:4864:20::944]) (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 83B8612785F for ; Wed, 7 Nov 2018 03:34:48 -0800 (PST) Received: by mail-ua1-x944.google.com with SMTP id k10so5704641ual.6 for ; Wed, 07 Nov 2018 03:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JRQadDBRNs/bxGaK0MxpEOEWtcVYzrKNHqgj7rQ7a+o=; b=uwkqLJBrampyi9AbYdRKr/wTCFT7JRBhPtgOeRZe7iNFfVe3X81NgRohGVike2VZza kN6UsDZp+5WSwuFTaerxeQmUoVQotXEpRlfqPSwua09OZYviLsG0kKPFPCC6ddYs3wJ5 SVTJlZQNLpi+bAsZGXopMk2iXO587i/WewE45xQ6mWICq0CmGy8f9aztXzHj751DPbXC 3zpbMr1LcsB2xyjxAiQfylTr3IIlEbnUmAYLwOKPNjQ68havKbPUVsTGg9xkxhYskyBf iheFV1J3Gkm+cZ2SVfEWrNKnQuEHOk3dwHg0uooGcqCZKX0yIcTI79Ep7QIgzYykZQO2 sQMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JRQadDBRNs/bxGaK0MxpEOEWtcVYzrKNHqgj7rQ7a+o=; b=kizbvlYoGVGc2yMgZpfp0lJf3hOo0c9KoKjgkRvysQqGLbSVyhTfjNNX3VlGKTpGhq HQtgfxmgYqVjCnKcJVX0pA+Zu4Y34XJTvxMGjyVbgWg1tCXO6AykGF2SmayK7GGbtr5G ozfvlxHRXliuKVtU2RTSCIO9pMVfH5Y/1SjP0agWKFPgmoGLuSpx0BzRtX5z+LPnH9VD 6vQvK6BV4Bou8WREEapupzHsxkL7u0nyDnQK/cxtm4Mq3jcD/jSJQvoV0Gkjzi4zp4UD fudZ2+5vS5NDcdr2UAEnQ42kNGoveYz0V7nBxUE3ZUYIFljbu+exXsR7z+0qdCjQuJ2y vOKg== X-Gm-Message-State: AGRZ1gI8YhAoCoRpbYZS50F/9+c0CmmF2oIN0jdks1b/c/elXQT2L7d8 7zmOvxMZUREjlbMhTYz302xjtehqSIs/lcOOzptySw== X-Google-Smtp-Source: AJdET5eajX/x+HfE/AlecuXcL/N3sHpEMMJHr8AH19AlLCfaf5uOU2zu7d/gUiwR6GlVErXsFgKYfBMXCT6umRKfol0= X-Received: by 2002:ab0:526:: with SMTP id 35mr602732uax.84.1541590487531; Wed, 07 Nov 2018 03:34:47 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <5FB0A50F-DAF3-47C4-A5F5-8DA20586C9E2@iii.ca> <1541576399.5384.7.camel@ericsson.com> In-Reply-To: <1541576399.5384.7.camel@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 7 Nov 2018 12:34:36 +0100 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Cc: Bernard Aboba , Cullen Jennings , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 11:34:51 -0000 On Wed, 7 Nov 2018 at 08:40, Stefan H=C3=A5kansson LK wrote: > If this now has changed, and we can have the simulcast receiver send an > SDP offer that is applied in the browser and things work (perhaps with > some web app intervention), and we have people interested in > implementing this, I personally see no reason why that should not be > pursued. On of the problems in SDP O/A is the fact that the remote can decide what the local side should send or stop sending by just sending a blob to it (a SDP offer or answer), a blob that, due its nature, cannot be "intercepted" by the JS in the local app to anticipate what it involves (it's the other way around: first apply whichever unknown blob you have received from the remote, then realize of what happened via inspection or via contextless events). This model is typically argued as a way to get interoperability in codecs and RTP parameters. But this discussion is going further, since here we are saying that the remote can send us a blob (that the app does not know in advance what it means) and enable simulcast in local side. In ORTC the remote does NEVER decide what we can send or how we send it. Assuming capabilities have been exchanged, it's up to the custom app logic to decide what a peer sends and how it sends that. If you want to stop receiving the remote video you send a custom JSON to the server or remote app requesting that. That's friendly. Sending a secret blob which cannot be managed via JS by the receiver is not friendly. So, I want to assume that WebRTC NG will drop SDP and, if so, IMHO it does not make sense that efforts are spent now in a feature that makes the dependency on SDP O/A even stronger. --=20 I=C3=B1aki Baz Castillo From nobody Wed Nov 7 03:48:49 2018 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 2174D1277C8 for ; Wed, 7 Nov 2018 03:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.792 X-Spam-Level: X-Spam-Status: No, score=-3.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=QXu+JWwl; dkim=pass (1024-bit key) header.d=ericsson.com header.b=FnCL4w/Q 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 gSP8X7iJkR6V for ; Wed, 7 Nov 2018 03:48:45 -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 225F6127133 for ; Wed, 7 Nov 2018 03:48:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541591323; x=1544183323; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0fdj1Vliitr79hGTSTUa7yyaRgBUDz9+T2UVvMmJGJU=; b=QXu+JWwlP/4hmxn2Vr1Jr1KflYjBVcEgPUyymg8ZQ9B3XR7wQQrukTBc1pz+yDqQ Gz2OV8MU3UlbLDMKSokFaax/POawakauNzt+aP2rqUuEARKP+AQi1CTmgFKTNfI0 syFqYa9ApGpAtPYqtR6CBEv/bwgl4OpdtCnBAZE999M=; X-AuditID: c1b4fb30-f2dff700000043c4-e2-5be2d11b6b46 Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 10.8A.17348.B11D2EB5; Wed, 7 Nov 2018 12:48:43 +0100 (CET) Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 7 Nov 2018 12:48:43 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 7 Nov 2018 12:48:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0fdj1Vliitr79hGTSTUa7yyaRgBUDz9+T2UVvMmJGJU=; b=FnCL4w/QqlIO2m0plIS3p9YFoOoc3o9PYrxMr/wbcRULoBSLMvGuzO9s9ENPpKOmP+xi4o7sfDLpnxCFxjzTjDYiAHkbR6H5J1Kdh+Or9tlklXgVjUDZWqKCElQiJuB7tRJ1H9lUVM9ViHeB+SBa7FbQqkWzMcftKw6igCYyEWU= Received: from HE1PR0702MB3803.eurprd07.prod.outlook.com (52.133.7.21) by HE1PR0702MB3562.eurprd07.prod.outlook.com (52.133.5.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Wed, 7 Nov 2018 11:48:41 +0000 Received: from HE1PR0702MB3803.eurprd07.prod.outlook.com ([fe80::39af:5668:c1c0:d0b5]) by HE1PR0702MB3803.eurprd07.prod.outlook.com ([fe80::39af:5668:c1c0:d0b5%4]) with mapi id 15.20.1294.034; Wed, 7 Nov 2018 11:48:41 +0000 From: =?utf-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= To: "ibc@aliax.net" CC: "bernard.aboba@gmail.com" , "fluffy@iii.ca" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? Thread-Index: AQHUdBZUTg0cJIWSI0uXT0gq1ZU2QaU/SkGAgADuQYCAAAF8AIAAa0GAgAB0wICAAnz9gIAAD1MAgABLr4CAAEGOAIAAA+4A Date: Wed, 7 Nov 2018 11:48:41 +0000 Message-ID: <1541591320.5597.5.camel@ericsson.com> References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <5FB0A50F-DAF3-47C4-A5F5-8DA20586C9E2@iii.ca> <1541576399.5384.7.camel@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.18.5.2-0ubuntu3.2 x-originating-ip: [192.176.1.83] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3562; 6:PascevdtG/lU+crwpOdCA2VN3JXxx4AqfhJjOXcjrCTXK/U8xX9jggO9Pm7H5hQT0aU1tkkk8nW5wKIrhRs1QuCHAjZlgdxe1SlFxscVRBWH6Sq5yu5CSEtpvZiJnNowR4sChApe6tnlV/sp7mqcDswrJmlEGYyJtjVjOX0A+MHvE3YMGK+g31frDse0oXmWqgDwOGLrQmTWzU4pf4jHqC6i6VvXFehejpbpEwAzmLCIROQfUQp1fDxbiCOMDfKHgUdLDuMm0IgTWEHnbqmfVzYoicEOBOlwCrMBifjJkCdAnZH1VMOm8dvat4pljvO+dZawPmSJjttLaUbSbYsssb6BZP6ah2YwUysL53zeOkXyfhADMDTk5Vz9+oya5l7B4rjFk908UM2TrDWaWzNk+XPBgZC7srhkABINE2sF2nwR0TlyShgui19qU9+uVuUOfxlwwKcNA7vLlwAqdyJlhg==; 5:FBBx//kNwHl6XTTWV7Mv9lLMHycDWYoZvuFQFwbZIvxJgTkap+8unXyp+jckdpQckzbfo0yebmCl+GJuWUS92Ojbi+fp2IpHFX5MDFI65Y/DfiqsV7x8vKecaq5iLJaiK8QqWxT1J3zTstxXts9bq8TgroD/LhqKkxVt7clOW9o=; 7:UQin77ANtgbfBMAOlsBLnOkJTLwU+nFWXQewZDesn8H+4h42VfxE0l4BDtF7feA8waQ0GJNrRpqQw4Ha5PytAoYS76+LDz0+LZQnRBWgaaIgdGdUwKNVNGy9REeRZVGnYBZul0lkuCbd414sSTC2fw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 324f7ea0-b01f-42e9-c0d2-08d644a6f6b0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0702MB3562; x-ms-traffictypediagnostic: HE1PR0702MB3562: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(248295561703944)(37575265505322); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231382)(944501410)(52105095)(10201501046)(148016)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:HE1PR0702MB3562; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0702MB3562; x-forefront-prvs: 08497C3D99 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(396003)(366004)(376002)(39860400002)(199004)(189003)(51444003)(8676002)(478600001)(2616005)(66574009)(71200400001)(1730700003)(71190400001)(53936002)(6246003)(6486002)(229853002)(6346003)(6116002)(76176011)(25786009)(316002)(105586002)(2351001)(5660300001)(5640700003)(66066001)(6436002)(6512007)(106356001)(54906003)(186003)(68736007)(2900100001)(11346002)(2501003)(97736004)(102836004)(99286004)(85202003)(14454004)(3846002)(26005)(86362001)(93886005)(446003)(486006)(305945005)(6506007)(7736002)(256004)(8936002)(6916009)(50226002)(39060400002)(4326008)(85182001)(2906002)(103116003)(36756003)(81166006)(81156014)(476003)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3562; H:HE1PR0702MB3803.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=stefan.lk.hakansson@ericsson.com; x-microsoft-antispam-message-info: 0OF5CDR4Cf/Esu+MbySUPacbodlCszbSTBqfl0CIHmJpJfWb6Y6UlMnojwI63J2I/UvLBjOhr9KYeJVh4IvNmG1TnlLNrBE3HyhL9oNnOn8P/ZdbOQNU2wd5AiyJ+UNlEXZYDReTJwiewkzqjypSiroeL39sqbgHRy0O85PCu7V5dN6jAK+PyijHWa9NkwnLqsTt4sGrasq7mvvYGq30fL4O7MB4hJOp977UKykhqyhfqKIJ8Z7z2Ot81xRwOc9Z/tzTw/TbB9pjdvSDDzTGyXB3dR9tnHWvSCg/J3Ppcbja44RadqESl02JjA4KNTo8w3M2gc/fK7/ujSb1fADs1KD6/b8aRAZCZgcQRjv/qaU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <105384125173244CB072D86523F21F6F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 324f7ea0-b01f-42e9-c0d2-08d644a6f6b0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2018 11:48:41.2136 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3562 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHeXbvtuty9LTUHZWiZtELTs38MEQkP1SDMIqiwvXiyouKutmu SRakEWrOXOKatqVYOkLmbGKB00TYKMwhWRn4nmkTU4k01ou9aNvugr79/ud/zvk/HB6KEDVz I6hsVQGtUSlzJTwBaTzVqZFGvp5RxOmcwbL23jVCtmT7gWR1vUmyttVy/j5S/rLkM1/eZZrk y83mFY58aHAZHSHTBEkZdG52Ia2JTU4XZJV5Koj836LLeuM8rwT1iLSIogAnwOpIuhYJKBF+ hqDMtcDRoiCv+OoVzljWaOaAw9rA9wkSVxPgMA3zWUfPAa2ujcOKWQRPh9cI3zwPH4NXxjL/ rhAcBX8ezHF9TOBiaBrt5vmyN2IF2KeS2JbTMLVs47Gsgm+m6/5REm8DR12ln4U4HsrtAzw2 a4GEJqfOvzMIHwW9/pM/F+Ew+O6yctgsMYy5G/0MGIO5Z5BgORTmP6xyWd4JBocVsbwFJgxt fJY3wZvGSuQLAzzCgxp9B8kaUlgyGAKLUmHR1cdhm/oRvLBNBjZFg1VbEWA1eFxDAT4EfdWO AG8GS9U0WY32mv57rMl7GALvAlt3LFuWg65plmR5K9ypnOab/MfYAP1GN3kfcS0olKGZ83mZ 8fExtCb7AsOoVTEquqADeb+O48mvODuan0txIkwhSbDwRP+MQsRVFjJFeU4EFCEJEVa1ekvC DGXRFVqjPqe5lEszThRJkRKxUHb4cZoIZyoL6Byazqc1/1wOFRRRggos6uSureIb7xNbasWW 1FtjH6Xu2pb2nKUD620rqvqi4wkHSxuyeXPFoyffhTkkE3j8nuVaYqSYvu0uHIru7NxxNWVd 9/OzXKmnviGqcWSlfmXgZgXXM3cxPL3xzM9HrtHWIQsh2R/eUqqwmyfcU3ebSt4ufrHWbB+v G7c8LM6VkEyWcs9uQsMo/wIpXTcMNgMAAA== Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 11:48:47 -0000 T24gb25zLCAyMDE4LTExLTA3IGF0IDEyOjM0ICswMTAwLCBJw7Fha2kgQmF6IENhc3RpbGxvIHdy b3RlOg0KPiBPbiBXZWQsIDcgTm92IDIwMTggYXQgMDg6NDAsIFN0ZWZhbiBIw6VrYW5zc29uIExL DQo+IDxzdGVmYW4ubGsuaGFrYW5zc29uQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+ID4gDQo+ID4g SWYgdGhpcyBub3cgaGFzIGNoYW5nZWQsIGFuZCB3ZSBjYW4gaGF2ZSB0aGUgc2ltdWxjYXN0IHJl Y2VpdmVyDQo+ID4gc2VuZCBhbg0KPiA+IFNEUCBvZmZlciB0aGF0IGlzIGFwcGxpZWQgaW4gdGhl IGJyb3dzZXIgYW5kIHRoaW5ncyB3b3JrIChwZXJoYXBzDQo+ID4gd2l0aA0KPiA+IHNvbWUgd2Vi IGFwcCBpbnRlcnZlbnRpb24pLCBhbmQgd2UgaGF2ZSBwZW9wbGUgaW50ZXJlc3RlZCBpbg0KPiA+ IGltcGxlbWVudGluZyB0aGlzLCBJIHBlcnNvbmFsbHkgc2VlIG5vIHJlYXNvbiB3aHkgdGhhdCBz aG91bGQgbm90DQo+ID4gYmUNCj4gPiBwdXJzdWVkLg0KPiBPbiBvZiB0aGUgcHJvYmxlbXMgaW4g U0RQIE8vQSBpcyB0aGUgZmFjdCB0aGF0IHRoZSByZW1vdGUgY2FuIGRlY2lkZQ0KPiB3aGF0IHRo ZSBsb2NhbCBzaWRlIHNob3VsZCBzZW5kIG9yIHN0b3Agc2VuZGluZyBieSBqdXN0IHNlbmRpbmcg YQ0KPiBibG9iDQo+IHRvIGl0IChhIFNEUCBvZmZlciBvciBhbnN3ZXIpLCBhIGJsb2IgdGhhdCwg ZHVlIGl0cyBuYXR1cmUsIGNhbm5vdCBiZQ0KPiAiaW50ZXJjZXB0ZWQiIGJ5IHRoZSBKUyBpbiB0 aGUgbG9jYWwgYXBwIHRvIGFudGljaXBhdGUgd2hhdCBpdA0KPiBpbnZvbHZlcyAoaXQncyB0aGUg b3RoZXIgd2F5IGFyb3VuZDogZmlyc3QgYXBwbHkgd2hpY2hldmVyIHVua25vd24NCj4gYmxvYiB5 b3UgaGF2ZSByZWNlaXZlZCBmcm9tIHRoZSByZW1vdGUsIHRoZW4gcmVhbGl6ZSBvZiB3aGF0IGhh cHBlbmVkDQo+IHZpYSBpbnNwZWN0aW9uIG9yIHZpYSBjb250ZXh0bGVzcyBldmVudHMpLg0KPiAN Cj4gVGhpcyBtb2RlbCBpcyB0eXBpY2FsbHkgYXJndWVkIGFzIGEgd2F5IHRvIGdldCBpbnRlcm9w ZXJhYmlsaXR5IGluDQo+IGNvZGVjcyBhbmQgUlRQIHBhcmFtZXRlcnMuIEJ1dCB0aGlzIGRpc2N1 c3Npb24gaXMgZ29pbmcgZnVydGhlciwNCj4gc2luY2UNCj4gaGVyZSB3ZSBhcmUgc2F5aW5nIHRo YXQgdGhlIHJlbW90ZSBjYW4gc2VuZCB1cyBhIGJsb2IgKHRoYXQgdGhlIGFwcA0KPiBkb2VzIG5v dCBrbm93IGluIGFkdmFuY2Ugd2hhdCBpdCBtZWFucykgYW5kIGVuYWJsZSBzaW11bGNhc3QgaW4g bG9jYWwNCj4gc2lkZS4NCj4gSW4gT1JUQyB0aGUgcmVtb3RlIGRvZXMgTkVWRVIgZGVjaWRlIHdo YXQgd2UgY2FuIHNlbmQgb3IgaG93IHdlIHNlbmQNCj4gaXQuIA0KDQpJIHdpbGwgbm90IGRlZmVu ZCBTRFAgaW4gYW55IHdheSwgYnV0IEkgdGhpbmsgdGhhdCBldmVuIGluIDEuMCB0aGUNCnJlbW90 ZSBlbmQgaGFzIG5vIGNvbnRyb2wgb24gX3doYXRfIGlzIHNlbnQgLSBpdCdzIHRoZSBsb2NhbCBh cHAgYW5kDQp1c2VyIChhbmQgdXNlciBhZ2VudCkgdGhhdCBjb250cm9scyB3aGF0IGlucHV0IHNv dXJjZXMgdG8gdXNlIGZvciB0cmFjaw0KZGF0YSwgYW5kIHdoYXQgdHJhY2tzIHRvIHNlbmQuwqAN Cg0KQW4gbm9uIGluc3BlY3RlZCBTRFAgb2ZmZXIvYW5zd2VyIGNhbiBpbmZsdWVuY2UgX2hvd18g aXQgaXMgc2VudCwgYnV0IEkNCnRoaW5rIHRoYXQgaXMgcGVyIGRlc2lnbiAtIG5vIHBvaW50IGlu IGVuY29kaW5nIHdpdGggYW4gZW5jb2RlciB0aGF0DQp0aGUgcmVtb3RlIGNhbid0IGRlY29kZSBl dGMuDQo= From nobody Wed Nov 7 04:00:59 2018 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 F0DCF1277C8 for ; Wed, 7 Nov 2018 04:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joZ7mDYIMJ8f for ; Wed, 7 Nov 2018 04:00:55 -0800 (PST) Received: from mail-vk1-xa43.google.com (mail-vk1-xa43.google.com [IPv6:2607:f8b0:4864:20::a43]) (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 25F2A127133 for ; Wed, 7 Nov 2018 04:00:54 -0800 (PST) Received: by mail-vk1-xa43.google.com with SMTP id d201so1043119vka.0 for ; Wed, 07 Nov 2018 04:00:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=c+9lLt6LvO7SZih3zGm/5O1IvmpRzIPoBs6RtEwTzsk=; b=IZBInVfxLWxE3c+iUncWgdGGXrXb7+9GWORjui0NtmWiDd4GqxXBD1prX13aMHKYzJ 8MPDOad2WEXhNgFwqVeCKf4vKUw3961I1I8/xuPMFb7oJ3K9WywMH8WswmJecjLx1if+ ewzMMmHQxllzudjaZm1AW4uL3G45EmAidsip6h8jRJXLRJpCDN///NNaECwa0visEZil +pkJJOH1uELelleuko061Ig5gUxuJGEaqm1i27SFCDqX79gnwq7oKQEgGDEc2TtfNV7Q CdVkLfCnHA5JDZe6594xye2+C50mBn3Dmp2dxpyvdjgo4d/cAskkcvGgu01nUl86f5LV L2Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=c+9lLt6LvO7SZih3zGm/5O1IvmpRzIPoBs6RtEwTzsk=; b=Z6IpWo9jamcqyE6Go4yCBkzSTcrJMHM50E3JyblaBt4Q9m2eDvqaIYJ8ybtgicAkkL /jtGNIy/2BEA/ld8qOi8+mgFjvCMGHkTDRVVpYNrb6W0ffObkq8CJpnQS+FRui9ItIHf sMFxQ38nlYNWQEkm1ClRMn246QnS4HhhddJCtJL1rowYYWGSKdAqTNgpropaPhZ3GGbZ 8N+9yZnyG9B0TrLWKudmBZhGtetGabnUfVjSLZ6C1dfXk9PWGx0kVwM48cgFg9MpmHx4 Uk6vNnLkHM703Hs40d0gn3fBs8o8zwlWiw67dOnr/6YwUYQdc0FxRn76vf8e91VWe1hx yPYw== X-Gm-Message-State: AGRZ1gKOEB3KOdH94pDkJbj26LhUO20VXNvzp/xvrbX1+3N6ytjP76kx //Z+gdjjaNOYN0Ms3jpRDBZsNXgY6/REvAzyAJHq4w== X-Google-Smtp-Source: AJdET5c8Lw2nNl28oIgs4eYBSLVU4cT01HtY551uXYhkdw1Ev9exH9OBahNv8HRyvjkopTuTieQI4ySFO+HNsaYorPM= X-Received: by 2002:a1f:9042:: with SMTP id s63mr578295vkd.17.1541592053782; Wed, 07 Nov 2018 04:00:53 -0800 (PST) MIME-Version: 1.0 References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <5FB0A50F-DAF3-47C4-A5F5-8DA20586C9E2@iii.ca> <1541576399.5384.7.camel@ericsson.com> <1541591320.5597.5.camel@ericsson.com> In-Reply-To: <1541591320.5597.5.camel@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 7 Nov 2018 13:00:42 +0100 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Cc: Bernard Aboba , Cullen Jennings , rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 12:00:57 -0000 On Wed, 7 Nov 2018 at 12:48, Stefan H=C3=A5kansson LK wrote: > An non inspected SDP offer/answer can influence _how_ it is sent, but I > think that is per design - no point in encoding with an encoder that > the remote can't decode etc. I can buy that argument when it comes to just that: codec and RTCP interoperability. Ok, WebRTC 1.0 assumes that app developers cannot correlate capabilities in JS so the browser does it auto-magically. But here we are talking about simulcast, which consumes resources and requires more network uplink. And I want to control what my app sends (and its max bitrate) because sending 3 streams instead of just 1 means more CPU usage, battery and bandwidth (money). A received UFO should not change that. --=20 I=C3=B1aki Baz Castillo From nobody Wed Nov 7 16:59:03 2018 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 A082E130DCC for ; Wed, 7 Nov 2018 16:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TFia_e4XHyft for ; Wed, 7 Nov 2018 16:59:00 -0800 (PST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 8B7961286E7 for ; Wed, 7 Nov 2018 16:59:00 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id w19-v6so15008666eds.1 for ; Wed, 07 Nov 2018 16:59:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=l0u2oMFtbXWKombmcYRmb0hEs/ZK0tc+5x98GpdlszI=; b=RPD5MNgNocGH5DjarvZzA5w4Y2KhwCK7d55rpTA7UjZZaFqdHhFgeU4ElgADfMIi6g +mnl5Q8mnGGVlBvzHPEk5rb5+vkF47gCQpQJzFmlNkON0tzXhN1fzIifqlch3qhOflyo coQb6f3v8Ea8oyyWVNKYP9noF4RKeUApFYtRc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=l0u2oMFtbXWKombmcYRmb0hEs/ZK0tc+5x98GpdlszI=; b=ZInTWWHW6aDG7Wtye4fRf7qhRYWYIEi2gBJ/mC0BumhbrcCt9I0T+03bVwL8H0Kmy9 bRUmSuXOw5Lwh6lszl0RVEh2o2y48zCBj9CpcNgLfuByhspOz2t8r2Zh8uIYWeunsgSh cMWv12B3rxJEZYtDjmcu09Z8FOnNt+B9S7pAT2Hs3uYuTu0mK8Xj+2V+oq7B0mqctidw YtPQHGMVA6tfN/P3bX4QKTdlZ2m3DyE+OwmP6YrDcy69RIYrE72JPetz33MgpSjpBZiN bvaSKY7gclenC5e4WFVaAPxlu9IUxFPPgxjLLqMqyfjD/CRT/YVlo2OOcJVthWJ3Vscm yBSA== X-Gm-Message-State: AGRZ1gI46FVGNRTqTJm/6ewS8u0pFHE8UrayfPxXVaW5XoOX4oXYphN0 ezhZ6Fhr3uKipFHZrS69b9TyLq8lWiQiAQ== X-Google-Smtp-Source: AJdET5fWmV+AAnDfNKZwM6pS0iQZ0qmdZipT94Ihaj9GD6NpaQ4lC2wqZjgyoexw4g9LrUBonQ8MEg== X-Received: by 2002:a17:906:7d52:: with SMTP id l18-v6mr1488160ejp.95.1541638738842; Wed, 07 Nov 2018 16:58:58 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:80b2:17c1:eeb6:af31? ([2001:67c:1232:144:80b2:17c1:eeb6:af31]) by smtp.gmail.com with ESMTPSA id u25-v6sm695009edm.90.2018.11.07.16.58.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 16:58:58 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 8 Nov 2018 07:58:51 +0700 References: <103FEA6D-629A-42F9-9ACA-5518A2063B4E@sn3rd.com> To: RTCWeb IETF In-Reply-To: <103FEA6D-629A-42F9-9ACA-5518A2063B4E@sn3rd.com> Message-Id: <12589D94-F813-4597-AA6E-F5745F280ECB@sn3rd.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] RTCWEB@IETF103 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 00:59:03 -0000 Uploaded revised: - chairs=E2=80=99 slides: = https://datatracker.ietf.org/meeting/103/materials/slides-103-rtcweb-ietf-= 103-rtcweb-wg-chair-slides-as-well-as-jsep-changes-01 - Adam=E2=80=99s sec-draft slides: = https://datatracker.ietf.org/meeting/103/materials/slides-103-rtcweb-ad-co= mments-on-rtcweb-security-drafts-00 -mDNS ICE Candidate slides: = https://datatracker.ietf.org/meeting/103/materials/slides-103-rtcweb-mdns-= ice-candidates-00 spt > On Oct 31, 2018, at 08:08, Sean Turner wrote: >=20 > The RTCWEB WG will be meeting at IETF 103. Our session is scheduled = for: 16:10-18:10 Thursday in the "Meeting 2=E2=80=9D room; all times = UTC+7. The agenda can be found here: >=20 > = https://datatracker.ietf.org/meeting/103/materials/agenda-103-rtcweb-00 >=20 > The chair=E2=80=99s slides as well as the JSEP changes we will be = discussing are here: >=20 > = https://datatracker.ietf.org/meeting/103/materials/slides-103-rtcweb-ietf-= 103-rtcweb-wg-chair-slides-as-well-as-jsep-changes-00 >=20 > Remote participation information can be found here: >=20 > https://www.meetecho.com/ietf103/rtcweb/ >=20 > Cheers, >=20 > spt From nobody Thu Nov 8 01:46:23 2018 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 524191293FB for ; Thu, 8 Nov 2018 01:46:22 -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, URIBL_BLOCKED=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 zDHy0dJjIzjK for ; Thu, 8 Nov 2018 01:46:20 -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 AEB95128B14 for ; Thu, 8 Nov 2018 01:46:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id DB5B67C0B70 for ; Thu, 8 Nov 2018 10:46:17 +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 a2rci5jKsjaO for ; Thu, 8 Nov 2018 10:46:16 +0100 (CET) Received: from [IPv6:2001:67c:370:128:e6a7:a0ff:fe0b:6b0c] (unknown [IPv6:2001:67c:370:128:e6a7:a0ff:fe0b:6b0c]) by mork.alvestrand.no (Postfix) with ESMTPSA id 752E47C078D for ; Thu, 8 Nov 2018 10:46:15 +0100 (CET) To: rtcweb@ietf.org References: <185c8d1d-3971-ad09-eee0-a26bed446a96@alvestrand.no> <5FB0A50F-DAF3-47C4-A5F5-8DA20586C9E2@iii.ca> <1541576399.5384.7.camel@ericsson.com> <1541591320.5597.5.camel@ericsson.com> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <1d08beaa-4829-0f89-71f3-dc9e6d779bf9@alvestrand.no> Date: Thu, 8 Nov 2018 10:46:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [rtcweb] JSEP question: How to set up simulcast for server-originated calls? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 09:46:23 -0000 On 11/07/2018 01:00 PM, Iñaki Baz Castillo wrote: > On Wed, 7 Nov 2018 at 12:48, Stefan Håkansson LK > wrote: >> An non inspected SDP offer/answer can influence _how_ it is sent, but I >> think that is per design - no point in encoding with an encoder that >> the remote can't decode etc. > I can buy that argument when it comes to just that: codec and RTCP > interoperability. Ok, WebRTC 1.0 assumes that app developers cannot > correlate capabilities in JS so the browser does it auto-magically. > > But here we are talking about simulcast, which consumes resources and > requires more network uplink. And I want to control what my app sends > (and its max bitrate) because sending 3 streams instead of just 1 > means more CPU usage, battery and bandwidth (money). > > A received UFO should not change that. Inaki, you're attacking a proposal that has not been made. We have long ago defined the API that lets the local application control *exactly* what simulcast can be sent. What the SDP controls is telling the local browser (and application) what the other end is willing to accept. > > -- Surveillance is pervasive. Go Dark. From nobody Thu Nov 8 03:01:19 2018 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 5CA8F123FFD for ; Thu, 8 Nov 2018 03:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 INhQK45LNB_O for ; Thu, 8 Nov 2018 03:01:16 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09818128CF3 for ; Thu, 8 Nov 2018 03:01:16 -0800 (PST) Received: from dhcp-8111.meeting.ietf.org (dhcp-8111.meeting.ietf.org [31.133.129.17]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA8B1BIc011949 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 8 Nov 2018 05:01:14 -0600 (CST) (envelope-from adam@nostrum.com) To: "rtcweb@ietf.org" From: Adam Roach Message-ID: Date: Thu, 8 Nov 2018 18:01:10 +0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [rtcweb] Percent Encoding Issue from Today's Discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 11:01:18 -0000 Based on the discussion in today's session about percent encoding of the user portion of identities, I have made the following PR, which I believe reflects the outcome of that conversation: https://github.com/rtcweb-wg/security-arch/pull/81 /a From nobody Thu Nov 8 03:42:10 2018 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 16358130E6C for ; Thu, 8 Nov 2018 03:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 zUbymiJ_RcYa for ; Thu, 8 Nov 2018 03:42:06 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 9FDBA128CB7 for ; Thu, 8 Nov 2018 03:42:05 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id o15-v6so17265685wrv.4 for ; Thu, 08 Nov 2018 03:42:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jU8sM0pf5qXvenQwdGyEutP7Lxh5RG4rS1uOpjr0TRk=; b=EqtdFeITOZEMiNqH7Aq9QHzeVJuVD1A9QpkKF6vrLGvA/HlzvlHJSQqwNxOSJgyE9Y ELqBRTHxeor9JwoBZVNzlu5m8DxSFkUqtmM8F5+uFpkM4IU4AdIbHAWsozcKOpBekBAa VFbq2ysazWVP0URcZBfUZ1lePP6c1kY9ihc+H27Bn+qgRe+ZU1UCY6T/SX/LFEIeOGdO VGyeBb2eANGd1fn0g1Xzm0asGMziulyyi1hIGAWOKp3J69flPtTpCHbFG6BJtTnKcvDH JPCO614jHSoompMXSnikDvpRU4Xa0f7b+mG0UltVXa0TWqskSTj5qEtlbWO+PQRnb4QX TPXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=jU8sM0pf5qXvenQwdGyEutP7Lxh5RG4rS1uOpjr0TRk=; b=D1azRDe6jaxdGpwT8ZTERS38LAjCCfk+51ZGGpkbYvxnvxLdXxRGnv4ch8nHTcnlP4 1OBmOyue+D5s9CgKjV+miw/DA4q70ZmVvHdeuwh+LD3U7U4TUIs20rg+Wp+Kvj5V15f/ F4974Ty23hqefSVFXepYKkTJ6v4Dl18fDmIf2ATAgfZkH+lPKznQcZP1L/t/Ba9k+7f/ oUs6ZSpiyRazwunQgygIDvlgRSR05U9nRlp/RVlbV6GxsrZI/4BZ5WKj0tDWTX9z6EHu x8h/PC8YZMuJeG4uyBEzOgVreniGWETQEMQkPpBsrAm4XQ/76adgPAmCB1D4Rp2auEL8 R7aw== X-Gm-Message-State: AGRZ1gIWEk6bWcb9BjeNv3LcCifLm9rNxdAjA68+C4Em5PbtRlq9nfiD Ue/kuyG++1FqpLU0oGNA4Hg69t/u X-Google-Smtp-Source: AJdET5eyc+3/zjX+6cjPEJytzQs6aJIJVXDzokB2WDX0dAoDozqKKkwuQ/GvbKGZbVlSMCz+ADyznA== X-Received: by 2002:a5d:6901:: with SMTP id t1-v6mr3946426wru.210.1541677323774; Thu, 08 Nov 2018 03:42:03 -0800 (PST) Received: from [10.26.2.1] ([31.10.151.172]) by smtp.gmail.com with ESMTPSA id l186-v6sm7821246wma.13.2018.11.08.03.42.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Nov 2018 03:42:03 -0800 (PST) To: rtcweb@ietf.org References: From: Lennart Grahl Openpgp: preference=signencrypt Autocrypt: addr=lennart.grahl@gmail.com; prefer-encrypt=mutual; keydata= xsBNBFMHjy4BCADZR/nHk6jzDsEA2+dPG13NiXyBl34TtChDsZekZyO5jBgwslLgHVksQxlS 79n1lvVH0MxcI8SFifwLAAIjMfukNLGPAjEyJEQhQVpfXxkJXyZgncM2Wq+nlVCDZTiZLg/E 6jJP1zx9vB7sf5dWaB/Dt0YDHLM86EcDChQur9lrJk9K0Jiwt27Oo3B4FFfIOaVNUXgnRPbr Vw1/+O2jLg87Fsib9LP7Ghyv0Z2/VV7wJ4NLsLmIu60vcZVDYDOvcQRH4FZ76VBvlmlO+2TL 5L6yZLGgXS9GZyF3QXKAwhYqu5ouWEOUgXHch5deryjbENanimj4ntZQmF1nkxSZayk9ABEB AAHNJ0xlbm5hcnQgR3JhaGwgPGxlbm5hcnQuZ3JhaGxAZ21haWwuY29tPsLAfwQTAQIAKQUC UwePLgIbIwUJCWYBgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEPmPvtEEgqumkk0H /2dMGPa9VmgR0kmr2inGODWuCy4WXNUxeEMfY/Hob/8Ou50os6iK35TQI9WtvvlAq23aIvoJ +1OjnqekgKmavPoQ0Uf1h2LegiQNKpDGC6/S33SLitQoQyELyJCU5Ato9lIL0AzpLvr+8UaF plWbPB4Z0GfZGBQSyp0Dmdeb00sld378m9qXHByJfHjPGiDFY+el1talbCuxS87+SvwIvM05 5m1/ceJbZDjx3trvgzbSQOHMT82/Hva7cSyVAch7mJc/lIq2Q0hjoZlD9nqS6gVJ9PQnEW8z dAXXVvBoy9DtomH18jimq+xUxeBwiFRB64gZx3Yyo1CKgULzeWaQ/qfOwE0EUwePLgEIAKP+ Dw5Ow5QuITKcI+ooXZAOBCBOitdsAGrGAEORjv1VyYU1jvjNb07UlRWmpjtaZsQoC2DwfEJy OaBphhErkOVEHCvetfBq8aJ718on4A49XwyQZeyh521BvLQUj0VY5D1iTYzgNVr4Ic39duH/ 00b489Wf9sM7TwzONJOCR5pSKUzYfGUIfQIJRc4tbzOM+bzSknLwbYAWRraOstbRjf2+V3pf 46mzv8tteLnsMm91qshFUwiBfeMNZiKAM3eid80ghlEbQo5J07FOrqK1GxqMi8LQT/oA5lpu +BB6UzGP5nQ5fip95zAq3vu+Iasz1DWj6F1HkHDEHfdtVpTAN70AEQEAAcLAZQQYAQIADwUC UwePLgIbDAUJCWYBgAAKCRD5j77RBIKrpihiCACQq7ARCPSzDrtUcq3uTdP+fMHp8YCYD4UD fdt3vcw4a5JESaknUcWi7CbQrdcLT7iIFYa3pk5I8w4n2lH29uUTWwt9boDtdYkBY5a4Rg+m Z9ndsLh0fHdZM6BXv/6gWMMdGbV5+xcV0FDcXZIlHLZIriDgeZQR3cDEa9lFWUYrI9KKmdoq ngaND7jPZaMCyvn9VDOAGBWxg49gQV/x1d+DiIyMbF9J+ya4YqaSZtu2y/H03eVCawmI6SMH UzdOo+Yqen3Udcdur0KnWMUOP3FIdjgxaPoIEKfFTBy7n8rlzrrTzyrv5Gouusxj0JHMwvuh ixK1bmVy/XYqoG0TVwBt Message-ID: <996451f7-a863-14cd-6899-45e1c9bb9e2b@gmail.com> Date: Thu, 8 Nov 2018 12:42:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: [rtcweb] IP handling and mDNS: The issue with obtaining consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 11:42:08 -0000 Hi everyone, since we were running out of time in the meeting, a supplement comment regarding the rtcweb-mdns-ice-candidates draft and the plans for IP handling in general: I want to endorse the mDNS extension draft as I believe it is a significant step towards getting WebRTC out of the blocklist of all those privacy plugins for browsers. The draft states that the IP hiding technique should be applied to use cases where no consent has been requested and that obviously affects those use cases in a negative way. This is the first extension to the IP handling draft but it shows a direction which makes it reasonable to assume that "consent" vs. "no consent" will diverge further for privacy reasons. And that is something I *would* generally encourage... However, it's only fair to take a step back to ensure that all use cases can request user consent appropriately in order to escape those restrictions. I don't think we can ignore that this hasn't happened so far in browsers which all rely on the use of getUserMedia. That is not appropriate for media receive only or pure data use cases. Thus, I would like the IP handling document (or the extension draft) to require implementations to allow for consent requests in a neutral way. Cheers Lennart From nobody Fri Nov 9 15:22:43 2018 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 AEB6E1277CC for ; Fri, 9 Nov 2018 15:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 iGZ67Ex6CQXv for ; Fri, 9 Nov 2018 15:22:40 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 873A91274D0 for ; Fri, 9 Nov 2018 15:22:40 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id r7-v6so2345300iog.7 for ; Fri, 09 Nov 2018 15:22:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ySn776mEUoy4xUU+yfxY+AbGmaV3m5XxrE/Trt3Bwhk=; b=kntFsEMjTP6m/PrRVRBSsqzuvf1PS1PH7T26iCaCyWh4K2FQFI7/buLWqNF6Fenj+5 WBTteEwG8xXi4GwUxM2mzPhNBiXESZ3VpglMEA7qJGy4nRqHpzqXDXlKfu5p4oDqAtot 8JHmVDHHhPDRHP5aCgrcBKNNYbGQ+HYKDHwoRJgAsv+f9gBjuNDXoNZNTBGfOAV8TcDO J2HSbpdUilu49X+tlyKkJIg4lpSkv5Th66HBuJ4HtTQnVEB2YfjMi1yKEgX23QOCq+hH ACtIV+R6M8+DZ4zu07OhlHqTVY1z5rFnoq0Ow1hB/IwOwbSAZMA42sWXqeMRT6djLvT8 0m8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ySn776mEUoy4xUU+yfxY+AbGmaV3m5XxrE/Trt3Bwhk=; b=a8KE3tOfJ9riQJRnLE12o/y7yHpNkh/FjtBEW2bU0vKnqyftj09r8JvTngiMHID43a v07TQb/FPz9x2Q+r/Z712lBReARTE8ucyGoC2da0yubcYXIss6qRKH/YYEy32myia28F wQT7k65StkNCAo5VtUpxfr3Nxfyj3nWMvM6hCoEix1RThA6ealUltiqelozgOCFfy4Th Q8B/WOyiQr+DKsLsEhMTi1Ic0sQGY/5JLoyVbuL5r39KfX07S8mCPAOTUFr8xpHlCecx RQQc47djpfVYpWyUpqpxvF/LTMbv8BcvPXj60CG4w8tivqsjxx1Zv8sNGxK3nukW5YNS FU5g== X-Gm-Message-State: AGRZ1gL/BuDzc4lNv1ZEXGBa4McDh8t9jontp3Zs6yPC8O7tjS7McA3A Ij9UBW0A+UIhdpK0Y8Y7uN+AQkGghgXhKg8JcY1Aug== X-Google-Smtp-Source: AJdET5f68B+zRq0+QMz/fHB1YTS4YvtIQ9YXT6lBXl0UlEkCuAmQclSsmValNUQTfne0ZOaB9g15srJg3l9legSnR7o= X-Received: by 2002:a5e:980f:: with SMTP id s15-v6mr8449064ioj.87.1541805759388; Fri, 09 Nov 2018 15:22:39 -0800 (PST) MIME-Version: 1.0 References: <996451f7-a863-14cd-6899-45e1c9bb9e2b@gmail.com> In-Reply-To: <996451f7-a863-14cd-6899-45e1c9bb9e2b@gmail.com> From: Justin Uberti Date: Fri, 9 Nov 2018 15:22:28 -0800 Message-ID: To: Lennart Grahl Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000009a66c3057a43a0d0" Archived-At: Subject: Re: [rtcweb] IP handling and mDNS: The issue with obtaining consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2018 23:22:43 -0000 --0000000000009a66c3057a43a0d0 Content-Type: text/plain; charset="UTF-8" I understand the sentiment here, but we're a standards body that designs protocols, and our ability to impose vague requirements on implementation user interfaces is limited at best. I prefer to maintain the current text in the document regarding consent, which was the result of extensive WG discussions. On Thu, Nov 8, 2018 at 3:42 AM Lennart Grahl wrote: > Hi everyone, > > since we were running out of time in the meeting, a supplement comment > regarding the rtcweb-mdns-ice-candidates draft and the plans for IP > handling in general: > > I want to endorse the mDNS extension draft as I believe it is a > significant step towards getting WebRTC out of the blocklist of all > those privacy plugins for browsers. > > The draft states that the IP hiding technique should be applied to use > cases where no consent has been requested and that obviously affects > those use cases in a negative way. This is the first extension to the IP > handling draft but it shows a direction which makes it reasonable to > assume that "consent" vs. "no consent" will diverge further for privacy > reasons. And that is something I *would* generally encourage... > > However, it's only fair to take a step back to ensure that all use cases > can request user consent appropriately in order to escape those > restrictions. I don't think we can ignore that this hasn't happened so > far in browsers which all rely on the use of getUserMedia. That is not > appropriate for media receive only or pure data use cases. Thus, I would > like the IP handling document (or the extension draft) to require > implementations to allow for consent requests in a neutral way. > > Cheers > Lennart > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000009a66c3057a43a0d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I understand the sentiment here, but we're a standards= body that designs protocols, and our ability to impose vague requirements = on implementation user interfaces is limited at best.

I = prefer to maintain the current text in the document regarding consent, whic= h was the result of extensive WG discussions.

On Thu, Nov 8, 2018 at 3:42 AM Lennart Grahl = <lennart.grahl@gmail.com&= gt; wrote:
Hi everyone,

since we were running out of time in the meeting, a supplement comment
regarding the rtcweb-mdns-ice-candidates draft and the plans for IP
handling in general:

I want to endorse the mDNS extension draft as I believe it is a
significant step towards getting WebRTC out of the blocklist of all
those privacy plugins for browsers.

The draft states that the IP hiding technique should be applied to use
cases where no consent has been requested and that obviously affects
those use cases in a negative way. This is the first extension to the IP handling draft but it shows a direction which makes it reasonable to
assume that "consent" vs. "no consent" will diverge fur= ther for privacy
reasons. And that is something I *would* generally encourage...

However, it's only fair to take a step back to ensure that all use case= s
can request user consent appropriately in order to escape those
restrictions. I don't think we can ignore that this hasn't happened= so
far in browsers which all rely on the use of getUserMedia. That is not
appropriate for media receive only or pure data use cases. Thus, I would like the IP handling document (or the extension draft) to require
implementations to allow for consent requests in a neutral way.

Cheers
Lennart

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000009a66c3057a43a0d0-- From nobody Fri Nov 9 15:48:58 2018 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 4A0501286E3 for ; Fri, 9 Nov 2018 15:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 wsOjiipJIwEu for ; Fri, 9 Nov 2018 15:48:55 -0800 (PST) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 DE2531277CC for ; Fri, 9 Nov 2018 15:48:54 -0800 (PST) Received: by mail-ua1-x92d.google.com with SMTP id d8so1237239ual.2 for ; Fri, 09 Nov 2018 15:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jsOYYXrj+Rtd8ZlsXYRnQrfmeSlObURBO6moCArU+9Y=; b=qoMGHfrYZzZ55JcUwd00FdX5yarMFbhZD/QJnwc6FxfW1h3t3fjEYOhQzs7xyM68jg /9sr3/LweGhl3Vd1OHSUdHBk6B2ILxz0Q0+DYFTfvzEt2fLMBi+TCjaeE50hZgFqvJEX ftYugKArsx5LbWBZA3s5p+TYtvRAXX4QKDOjqmgv6yD43FE5Vye04eYyp+Eq7yUgCyeE fxU8iBfXlcFJLH0zRBFZW+hdiUBy6APv1Sn6yijUWIiErF/XAVdECbVfziKWLRvFxLbc 2C8CJLmDBjoaf0x2KpFAoHX47UbccNmXYNyjANDr4xU8ABrbgaKpyaMIG3Xwwc9R0kGn lWzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jsOYYXrj+Rtd8ZlsXYRnQrfmeSlObURBO6moCArU+9Y=; b=HxjaygEDn8oIBvXhh75bHdj8oNPbKmgQ0hLfCmnei/xLvfFVktHLhy9zxRfOa9FWoD 5J4FhMFC3s+WCk+yIKE1P4d+QD7ISP/DoAJa4N9TjEn5TU4rfBG4f75LUuWmCYnYD6Rm zUiRe2wnYcOKo9V7SgbFjSPl2IDpKOU8PBf2LKt0JN6GNh0OUAfLd0ichfwaalSpXPKj eM1y3n6u/Big0N4J3JFDLM8BE8SXhzAK77R//YkxFsQC5DkRga2YIdFVsMru7gXR3V31 mTQRi1xh2j99DRjW9JNb8xRtT0FC7piCMlsYZVYbnnBCu3aJjnXWRusa0nPd17MBTCLh YV0Q== X-Gm-Message-State: AGRZ1gILK1LllD4zw7wHHityYTp2SueoC4LYjtGS69bZjCSwR1tQLg2+ 2EzE6pPm5iCPUG4s7NUmYixtnhGC7Z/1jq3I4b0= X-Google-Smtp-Source: AJdET5eWdTH0wmvGk0B3SN5bf+OMOW/jKYX8Kn7dR2aL6aXU4FBr2KCI4gEDvWkwfZeLKLZ3/AvNZqmYsFnxiOJL3Fo= X-Received: by 2002:ab0:60da:: with SMTP id g26mr4838625uam.104.1541807333651; Fri, 09 Nov 2018 15:48:53 -0800 (PST) MIME-Version: 1.0 References: <996451f7-a863-14cd-6899-45e1c9bb9e2b@gmail.com> In-Reply-To: From: Bernard Aboba Date: Fri, 9 Nov 2018 18:48:42 -0500 Message-ID: To: Justin Uberti Cc: Lennart Grahl , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000006f3b05057a43fe0d" Archived-At: Subject: Re: [rtcweb] IP handling and mDNS: The issue with obtaining consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2018 23:48:57 -0000 --0000000000006f3b05057a43fe0d Content-Type: text/plain; charset="UTF-8" Agree with Justin. The IETF is not the appropriate SDO to deal with permissions. On Fri, Nov 9, 2018 at 6:22 PM Justin Uberti wrote: > I understand the sentiment here, but we're a standards body that designs > protocols, and our ability to impose vague requirements on implementation > user interfaces is limited at best. > > I prefer to maintain the current text in the document regarding consent, > which was the result of extensive WG discussions. > > On Thu, Nov 8, 2018 at 3:42 AM Lennart Grahl > wrote: > >> Hi everyone, >> >> since we were running out of time in the meeting, a supplement comment >> regarding the rtcweb-mdns-ice-candidates draft and the plans for IP >> handling in general: >> >> I want to endorse the mDNS extension draft as I believe it is a >> significant step towards getting WebRTC out of the blocklist of all >> those privacy plugins for browsers. >> >> The draft states that the IP hiding technique should be applied to use >> cases where no consent has been requested and that obviously affects >> those use cases in a negative way. This is the first extension to the IP >> handling draft but it shows a direction which makes it reasonable to >> assume that "consent" vs. "no consent" will diverge further for privacy >> reasons. And that is something I *would* generally encourage... >> >> However, it's only fair to take a step back to ensure that all use cases >> can request user consent appropriately in order to escape those >> restrictions. I don't think we can ignore that this hasn't happened so >> far in browsers which all rely on the use of getUserMedia. That is not >> appropriate for media receive only or pure data use cases. Thus, I would >> like the IP handling document (or the extension draft) to require >> implementations to allow for consent requests in a neutral way. >> >> Cheers >> Lennart >> >> _______________________________________________ >> 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 > --0000000000006f3b05057a43fe0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree with Justin.=C2=A0 The IETF is not the appropriate S= DO to deal with permissions.=C2=A0

On Fri, Nov 9, 2018 at 6:22 PM Justin Uberti <juberti=3D40google.com@dmarc.ietf.org= > wrote:
I unde= rstand the sentiment here, but we're a standards body that designs prot= ocols, and our ability to impose vague requirements on implementation user = interfaces is limited at best.

I prefer to maintain the = current text in the document regarding consent, which was the result of ext= ensive WG discussions.

On Thu, Nov 8, 2018 at 3:42 AM Lennart Grahl <lennart.grahl@gmail.com>= wrote:
Hi everyone,

since we were running out of time in the meeting, a supplement comment
regarding the rtcweb-mdns-ice-candidates draft and the plans for IP
handling in general:

I want to endorse the mDNS extension draft as I believe it is a
significant step towards getting WebRTC out of the blocklist of all
those privacy plugins for browsers.

The draft states that the IP hiding technique should be applied to use
cases where no consent has been requested and that obviously affects
those use cases in a negative way. This is the first extension to the IP handling draft but it shows a direction which makes it reasonable to
assume that "consent" vs. "no consent" will diverge fur= ther for privacy
reasons. And that is something I *would* generally encourage...

However, it's only fair to take a step back to ensure that all use case= s
can request user consent appropriately in order to escape those
restrictions. I don't think we can ignore that this hasn't happened= so
far in browsers which all rely on the use of getUserMedia. That is not
appropriate for media receive only or pure data use cases. Thus, I would like the IP handling document (or the extension draft) to require
implementations to allow for consent requests in a neutral way.

Cheers
Lennart

_______________________________________________
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
--0000000000006f3b05057a43fe0d-- From nobody Sun Nov 11 02:20:37 2018 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 64D2812F1AB for ; Sun, 11 Nov 2018 02:20:35 -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=unavailable 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 5mpCnzRE9__R for ; Sun, 11 Nov 2018 02:20:33 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 03B1D1274D0 for ; Sun, 11 Nov 2018 02:20:33 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id z13so4180131lfe.11 for ; Sun, 11 Nov 2018 02:20:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HxRoQ6PWzJg6SbD6pQXH2KXAFvNtuZQ4Hsr9Gjligpk=; b=oVusFp0V8Hq+sg6ZUA5MmWgHonwIjUd6RX/amUZb3ribgur4Yiri3vI5fa+N4y3IfW 25Nzb70B1+AFPp6CK90fKZqhz1dJFKF+XPzgXIlh4PQseNqIsUSUZk3o7eOZepwZO6j+ LgzEjXBrhaCbh8bWFXaTN8wORh9/IgNDHp5GSQCE9oB/TeA9YGTjk+/iWty8liR31wf8 lE+ZSTOBpWuJVZWLW1Jki5f7m4gV5PXqmwrNyZNjI61pP4efv2AIIGt3Xyoig75qLo2t mJY4S+kw+p7/VkFjP9GN8k2Vygzj3RObUqbMBIxKWGZydjjetyN9roZdA/kShG4vjsuX hjrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HxRoQ6PWzJg6SbD6pQXH2KXAFvNtuZQ4Hsr9Gjligpk=; b=tBYDZnBLG6nnnmvZCgZcP1t1LMiVGzVzH3lvmNR+0FejzCW+NDyL2cS1YJAFTNngBV nyDFr7ngLbkj2O5U66lmSSjoshleJZgUPUze5GIuYnadEp0tdJoiszgmqWe1C7Dsj5pK 3EOIcnV+HkR4EmPp3uU4E2Vx8KN10KWoANunkrh31TUD1TkDjiMGvGInms3lkw2ipBUA RM6B/PopkVzsUhJnGGq/0bqzzcXEF8gVhUE+3jp6M8PqpxzdGearmlV9x/lrM3WlLpiJ R2Nr2Urxc8hBHb+FVCwUdIvTMinLkU0sbfy1lQSI89ylGB5asklfulLVJhd4VKukK+yN l5gA== X-Gm-Message-State: AGRZ1gJ2P0egxlb/ivnYeQ+CKzogygDF6aHP0vhS93S/g50hWdenegdp cFjOr7lB1RbZ5xYXzc/iRKoaGnJvw6kEvzDQJ0tpD05v X-Google-Smtp-Source: AJdET5fl9IdYn1AMNLSz4hTR+Jwdu/Dg7z0CTx8gWRJxQFmNH8K1FtAyZR7I8tiJsA2D0dyP8p5rILOVR79pO+fD8n0= X-Received: by 2002:a19:2752:: with SMTP id n79mr9643269lfn.11.1541931631110; Sun, 11 Nov 2018 02:20:31 -0800 (PST) MIME-Version: 1.0 References: <996451f7-a863-14cd-6899-45e1c9bb9e2b@gmail.com> In-Reply-To: From: Alexandre GOUAILLARD Date: Sun, 11 Nov 2018 17:20:58 +0700 Message-ID: To: Bernard Aboba Cc: juberti=40google.com@dmarc.ietf.org, RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000023ef8f057a60ef89" Archived-At: Subject: Re: [rtcweb] IP handling and mDNS: The issue with obtaining consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 11 Nov 2018 10:20:35 -0000 --00000000000023ef8f057a60ef89 Content-Type: text/plain; charset="UTF-8" +1 with justin. On Sat, Nov 10, 2018 at 6:49 AM Bernard Aboba wrote: > Agree with Justin. The IETF is not the appropriate SDO to deal with > permissions. > > On Fri, Nov 9, 2018 at 6:22 PM Justin Uberti 40google.com@dmarc.ietf.org> wrote: > >> I understand the sentiment here, but we're a standards body that designs >> protocols, and our ability to impose vague requirements on implementation >> user interfaces is limited at best. >> >> I prefer to maintain the current text in the document regarding consent, >> which was the result of extensive WG discussions. >> >> On Thu, Nov 8, 2018 at 3:42 AM Lennart Grahl >> wrote: >> >>> Hi everyone, >>> >>> since we were running out of time in the meeting, a supplement comment >>> regarding the rtcweb-mdns-ice-candidates draft and the plans for IP >>> handling in general: >>> >>> I want to endorse the mDNS extension draft as I believe it is a >>> significant step towards getting WebRTC out of the blocklist of all >>> those privacy plugins for browsers. >>> >>> The draft states that the IP hiding technique should be applied to use >>> cases where no consent has been requested and that obviously affects >>> those use cases in a negative way. This is the first extension to the IP >>> handling draft but it shows a direction which makes it reasonable to >>> assume that "consent" vs. "no consent" will diverge further for privacy >>> reasons. And that is something I *would* generally encourage... >>> >>> However, it's only fair to take a step back to ensure that all use cases >>> can request user consent appropriately in order to escape those >>> restrictions. I don't think we can ignore that this hasn't happened so >>> far in browsers which all rely on the use of getUserMedia. That is not >>> appropriate for media receive only or pure data use cases. Thus, I would >>> like the IP handling document (or the extension draft) to require >>> implementations to allow for consent requests in a neutral way. >>> >>> Cheers >>> Lennart >>> >>> _______________________________________________ >>> 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 > -- Alex. Gouaillard, PhD, PhD, MBA ------------------------------------------------------------------------------------ President - CoSMo Software Consulting, Singapore ------------------------------------------------------------------------------------ sg.linkedin.com/agouaillard - --00000000000023ef8f057a60ef89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 with justin.

On Sat, Nov 10, 2018 at 6:49 AM Bernard Aboba <bernard.aboba@gmail.com> wrote:
=
Agree with Justin.=C2= =A0 The IETF is not the appropriate SDO to deal with permissions.=C2=A0
On Fri, Nov 9, 2018 at 6:= 22 PM Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:
I understand the sentiment= here, but we're a standards body that designs protocols, and our abili= ty to impose vague requirements on implementation user interfaces is limite= d at best.

I prefer to maintain the current text in the = document regarding consent, which was the result of extensive WG discussion= s.

On Thu, Nov 8= , 2018 at 3:42 AM Lennart Grahl <lennart.grahl@gmail.com> wrote:
Hi everyone,

since we were running out of time in the meeting, a supplement comment
regarding the rtcweb-mdns-ice-candidates draft and the plans for IP
handling in general:

I want to endorse the mDNS extension draft as I believe it is a
significant step towards getting WebRTC out of the blocklist of all
those privacy plugins for browsers.

The draft states that the IP hiding technique should be applied to use
cases where no consent has been requested and that obviously affects
those use cases in a negative way. This is the first extension to the IP handling draft but it shows a direction which makes it reasonable to
assume that "consent" vs. "no consent" will diverge fur= ther for privacy
reasons. And that is something I *would* generally encourage...

However, it's only fair to take a step back to ensure that all use case= s
can request user consent appropriately in order to escape those
restrictions. I don't think we can ignore that this hasn't happened= so
far in browsers which all rely on the use of getUserMedia. That is not
appropriate for media receive only or pure data use cases. Thus, I would like the IP handling document (or the extension draft) to require
implementations to allow for consent requests in a neutral way.

Cheers
Lennart

_______________________________________________
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


--
Alex. Gouaillar= d, PhD, PhD, MBA
------------------------------------------------------= ------------------------------
President - CoSMo Software Consult= ing, Singapore
--------------------------------------------------= ----------------------------------

--00000000000023ef8f057a60ef89-- From nobody Fri Nov 16 21:59:58 2018 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 C2F88126CB6 for ; Fri, 16 Nov 2018 21:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 zkl2sFwo2qu0 for ; Fri, 16 Nov 2018 21:59:53 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 80D0F128CF2 for ; Fri, 16 Nov 2018 21:59:53 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id d135so40998201qkc.12 for ; Fri, 16 Nov 2018 21:59:53 -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:cc :content-transfer-encoding:message-id:references:to; bh=ht5X9ui6lnZcEH3ZYid8oDICLtJm30737KSz43EnN8U=; b=LT6bYyAMjwazx9VgLimKqYRl9Nd5oQ2SqW6UGattUUOea/9IbKxgvfJNltEkbhV9iG c8opLjd0tb/LRtA2b1c0cmmmGxxGWhz98nw8kWWgbb5qkHM+duPyG7UP9GJKVhIHcV69 JUloJP6ivwfra9EPJJuBCazCBmzl6+WWDspeY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ht5X9ui6lnZcEH3ZYid8oDICLtJm30737KSz43EnN8U=; b=mhoOaSSl4cpXK4Lzm49xpyc06vaxqWcIGY0kuZviw5pySQYiUEYLLnPigUlB5KCRLf ywwjdOVSZsOYxsZsg48PDTVph7PM3PnEHoOAko4PifiL/VsOdeKlVM+pDQco1t5FlzXx rLM1oyxlNQ2ZtH8qV1cFy2nQmjUJTtdPkiY7j5mHF0x/16bVSpM8tPVIT02j+r6ggcog /SK/u3T4+9pxAV20xzsjr0xbthI2ds4+MUC5bXJ0MoNnvMj93ZIF3fmftGRcs28ESafA WFT8w8PiUqFSil5I8W8VfA6y9r88MnJlBH7X8OgZ3BHOd0E/q235M93EJCIj6tVXXbuO w4Tw== X-Gm-Message-State: AGRZ1gIPBOrZXknBGhLTAFGpfAleC8v6Mf7wtSLU1vTCaHb23Z7KHWsX F7/YUb0y8WtDiwGYzNoro4NclrDNzKc= X-Google-Smtp-Source: AJdET5dUwbpPJ9RylkWVlVtQQRvCJQJeel5SkM1ytjoYx5XyGywDPzfQgCAhcNU8lB/Q2Q4jUZRbZg== X-Received: by 2002:aed:3907:: with SMTP id l7mr13066903qte.65.1542434392344; Fri, 16 Nov 2018 21:59:52 -0800 (PST) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id r24sm21793941qtr.2.2018.11.16.21.59.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Nov 2018 21:59:51 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Sean Turner In-Reply-To: <5a2ed698-e353-4cb9-9c33-6450a843aefe@nostrum.com> Date: Sat, 17 Nov 2018 00:59:50 -0500 Cc: draft-ietf-rtcweb-security.all@ietf.org, "rtcweb@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6E8D1D20-A2B9-4466-AECC-CF9D15032BD3@sn3rd.com> References: <5a2ed698-e353-4cb9-9c33-6450a843aefe@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [rtcweb] AD Review: draft-ietf-rtcweb-security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 17 Nov 2018 05:59:57 -0000 > On Nov 1, 2018, at 20:36, Adam Roach wrote: >=20 > This is my AD review for draft-ietf-rtcweb-security. I think this = document is > ready to go into IETF last call, modulo the ICE citation issue. I plan = to > issue last call for this document at the same time as > draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-ip-handling, so = it will > wait for those to become ready. >=20 > I'm marking the document as "revised ID needed" pending the ICE = reference > update. >=20 > I also have a number of non-blocking comments that should be treated = the > same as IETF last-call comments. >=20 > /a >=20 > = --------------------------------------------------------------------------= - >=20 > ID Nits reports: >=20 > =3D=3D The document seems to contain a disclaimer for pre-RFC5378 = work, but was > first submitted on or after 10 November 2008. The disclaimer is = usually > necessary only for documents that revise or obsolete older RFCs, = and that > take significant amounts of text from those RFCs. If you can = contact all > authors of the source material and they are willing to grant the = BCP78 > rights to the IETF Trust, you can and should remove the = disclaimer. > Otherwise, the disclaimer is needed and you can ignore this = comment. > (See the Legal Provisions document at > https://trustee.ietf.org/license-info for more information.) I suspect the answer here is the same as for -security-arch, i.e., we = can=E2=80=99t really get away with removing the disclaimer. > -- Obsolete informational reference (is this intentional?): RFC 6222 > (Obsoleted by RFC 7022) It is there intentionally. The paragraph talks about both 6222 and = 7022. > = --------------------------------------------------------------------------= - >=20 > [DISCUSS] >=20 > Per the discussion around Cluster 238 dependencies, please reference = RFC 8445 > instead of RFC 5245. PR: https://github.com/rtcweb-wg/security/pull/8 > = --------------------------------------------------------------------------= - >=20 > =C2=A71: >=20 > > The Real-Time Communications on the Web (RTCWEB) working group is > > tasked with standardizing protocols for real-time communications > > between Web browsers, generally called "WebRTC" >=20 > I plan to close RTCWEB as soon as Cluster 238 is published, at which = point > this text will be out of date. Consider rephrasing in a way that will = survive > the passage of time better. PR (the nits PR): https://github.com/rtcweb-wg/security/pull/10 > = --------------------------------------------------------------------------= - >=20 > =C2=A71: >=20 > > In the system shown in Figure 1, Alice and Bob both have WebRTC > > enabled browsers... >=20 > Please add Alice and Bob to Figure 1. >=20 > Nit: "WebRTC-emabled=E2=80=9D See nits PR. > = --------------------------------------------------------------------------= - >=20 > =C2=A72: >=20 > Please update to match the RFC 8174 boilerplate. See nits PR. > Regardless of whether this update is made, there seem to be some = ambiguous > uses of RFC 2119 language (e.g. =C2=A74.3: "This service must be = provided for both > data and voice/video") that need a bit of auditing. >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A73.1: >=20 > > While the browser has access to local resources such as keying > > material, files, the camera and the microphone, >=20 > Consider adding an Oxford comma. See nits PR. > = --------------------------------------------------------------------------= - >=20 > =C2=A73.1: >=20 > > [Note: in many cases browsers are explicitly designed to avoid > > dialogs with the semantics of "click here to screw yourself", as >=20 > I hate to be a wet blanket, but this phrasing seems out of character = for an > RFC. Consider something less colloquial (and perhaps with less rough > connotations) than "screw" here. I changed it to: "click here to bypass security checks=E2=80=9D though I think the previous wording was about right ;) See nits PR. > = --------------------------------------------------------------------------= - >=20 > > 3.2. Same Origin Policy >=20 > Nit: "Same-Origin=E2=80=9D See nits PR. > = --------------------------------------------------------------------------= - >=20 > =C2=A73.2: >=20 > > Many other resources are accessible but isolated. For instance, > > while scripts are allowed to make HTTP requests via the > > XMLHttpRequest() API >=20 > Consider informatively citing https://xhr.spec.whatwg.org/ (or = something > better if you can find it). I just pointed to the WhatWG doc. See nits PR. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.1.2.2: >=20 > > to avoid the users just clicking through. Note also that the user > > interface chrome must clearly display elements showing that the = call >=20 > Consider defining the term "chrome" for those readers who may not be = familiar > with it. I stole something from a W3C doc. See nits PR. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.1.3: >=20 > > target. Callee-oriented consent provided by the calling site not > > work well because a malicious site can claim that the user is = calling >=20 > Nit: "...does not work well..." (or "...would not work well=E2=80=A6") I went with =E2=80=9Cwould=E2=80=9D. > > cryptographically established identity. While not suitable for all >=20 > Nit: "cryptographically-established=E2=80=9D See nits PR. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.1.4: >=20 > > Even if calls are only possible from HTTPS [RFC2818] sites, if the > > site embeds active content (e.g., JavaScript) that is fetched over > > HTTP or from an untrusted site, because that JavaScript is executed > > in the security context of the page [finer-grained]. >=20 > I can't parse this sentence. Consider reworking. I was not sure what to do with this one so I submitted an issue: https://github.com/rtcweb-wg/security/issues/9 > = --------------------------------------------------------------------------= - >=20 > =C2=A74.2.3: >=20 > > o Use or RTCP as an implicit reachability check. >=20 > Nit: "Use of=E2=80=A6" See nits PR. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.2.4: >=20 > > In addition, either side may wish to hide their location entirely = by > > forcing all traffic through a TURN server. >=20 > Suggested improvement: "...hide their location from the other..." (to = avoid > implying that this hides their location from either the web server or = the STUN > server) See nits PR. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.3: >=20 > > However, we must examine this > > technology to the WebRTC context, where the threat model is = somewhat > > different. >=20 > Nit: "...in the WebRTC context=E2=80=A6" See nits PR. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.3: >=20 > > MITM attack or by diverting them entirely. (Note that this attack >=20 > Please expand "MITM" on first use. MITM is in the RFC abbreviations list: https://www.rfc-editor.org/materials/abbrev.expansion.txt not incorporated ;) > = --------------------------------------------------------------------------= - >=20 > =C2=A74.3.2.1: >=20 > > All the calling service needs to do to avoid > > triggering a key continuity warning is to tell the browser that = "this > > is a call to user Y" where Y is close to X. >=20 > I read the meaning of the term "close" here to mean "confusable with = X," > although it took some work to arrive at that conclusion. If = "confusable" is > the intention, I would suggest phrasing it in that way. See nits PR. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.3.2.2: >=20 > > simply ignore such indicators even in the rather more dire case of > > mixed content warnings. >=20 > Nit: "mixed-content=E2=80=9D See nits PR. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.3.2.3: >=20 > > However, a new generation of Web-based identity > > providers (BrowserID, Federated Google Login, Facebook Connect, > > OAuth, OpenID, WebFinger), has recently been developed >=20 > Consider adding informative citations for at least BrowserID, OAuth, = OpenID, > and Webfinger [RFC7033], if not the other systems. I hate XML. I added informative references for OAuth, OpenID, and Webfinger. See nits PR. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.3.2.4: >=20 > > I.e., I must be able to verify that > > the person I am calling has engaged a secure media mode. >=20 > Is this possible in the general case? For non-browser endpoints (or = for > modified browswers), this verification seems to be impossible (unless = I've > missed some mechanism in the system that can guarantee this property). >=20 > Clearly I'm not asking for a change in design, but it seems that this > statement needs to be caveated to indicate that it requires trust in = the > remote endpoint to enforce the indicated policy, and that this trust = cannot be > verified; at least, not as WebRTC is designed today. >=20 > A simple forward citation to =C2=A74.3.3 might serve the purpose. I added the forward reference. See nits PR. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.4.1: >=20 > > While persistent endpoint identifiers can be a useful security > > feature (see Section 4.3.2.1 they can also represent a privacy = threat >=20 > Nit: missing a closing paren. See nits PR. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.2.2: >=20 > Consider citing https://www.w3.org/TR/fingerprinting-guidance/ for = further > information. See nits PR. From nobody Sat Nov 17 14:47:05 2018 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 5130C1292AD; Sat, 17 Nov 2018 14:47:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <154249482426.15964.1160448693280999498@ietfa.amsl.com> Date: Sat, 17 Nov 2018 14:47:04 -0800 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-17.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 17 Nov 2018 22:47:04 -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 WG of the IETF. Title : WebRTC Security Architecture Author : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-17.txt Pages : 42 Date : 2018-11-17 Abstract: This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-17 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-security-arch-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-arch-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 19 10:04:38 2018 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 4ECA7130DC7 for ; Mon, 19 Nov 2018 10:04:36 -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 WFT7w-Up7NLu for ; Mon, 19 Nov 2018 10:04:33 -0800 (PST) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 0BA1512D4E9 for ; Mon, 19 Nov 2018 10:04:33 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id u16so28184250otk.8 for ; Mon, 19 Nov 2018 10:04:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=lpgnR34EpRTxSbhNZXVJsIizGwYcwei15Cq95HQkpJ8=; b=sGsoWFE2H1YtlVlmPcXpdfzapejlAcJqAtYOZYoJssiQ85KRZUQnBTS0efQcdY7aFB fegpzhb7T9cSAapaE/3OxUxos74572IMxdHSobrZ7ugJpgemdnvhV+kYRcT1Q9twkoTq CEYgxt7teP2J0V1d4vA8kL2fiNT1aMPC2WHMXNjRiTxFx2ZuAq0/fSS/QQDHboeDmCeq RIjllZ9/ugxORCfDyBxuudwAQXx0laa/zFm5y5j6kijTZh/z2awEr6DkZHanGT7mpW13 H8e6F5o+6DEW1Hx+meBgahA/urc2DrYdhA5i2gveb8+JrfznSmtkINWoD6o0w6wxB4Y4 SZFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lpgnR34EpRTxSbhNZXVJsIizGwYcwei15Cq95HQkpJ8=; b=iy8x0CKVei4iBij6J7fJc5RXRvn/3GNvGQeP4hJJ7HyNm8pUSpTMJkdwsrUkX6gF1F E2yWaY6sfQu/4FmVNkgBQ37V7w/9LehXIFuJC0+fSvhbgYVKmWX6u5ZUaNjbrthIIqtN uJXFaDGZCpHJeCe+uNF+lB7I3IRn4r+cQlpFzkVQ+/hqI6UdqIkikSs6Tlqke3LtowkW 5Kgs8Bl3Q7EejyvY06w4L5H+zW2QDznGTAOYG2BcfEzTa0vPSteXQJGLEzdB15sR36m/ 6zn5B3EbloctjI5Y1n+S1iuW3sK0Plr9vcqvYq0Pdc5MScwFMqwUAN2QVKqANGsikvLG jCbg== X-Gm-Message-State: AGRZ1gJ9V9ZoIlmJ9/KVsPbcEKsODKtWED00LBjq3Trs1TlrMn69z3zI mq2E7JwsF0zElF+iTEfnrOIvvVXRze0xYY/vIAbvsw== X-Google-Smtp-Source: AJdET5ciG7A/TqY0TcTr2/XHoSA3SyumTwmbZ4Popqcbj1cC1x0Nd3FuO7bJiTExpQ3m8dgHt5VS7QKz0piNKcy6sp8= X-Received: by 2002:a9d:72a:: with SMTP id 39mr14909487ote.134.1542650671925; Mon, 19 Nov 2018 10:04:31 -0800 (PST) MIME-Version: 1.0 From: Ted Hardie Date: Mon, 19 Nov 2018 10:04:04 -0800 Message-ID: To: RTCWeb IETF , Sean Turner Content-Type: multipart/mixed; boundary="000000000000502b52057b0859eb" Archived-At: Subject: [rtcweb] Draft Minutes X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 18:04:36 -0000 --000000000000502b52057b0859eb Content-Type: multipart/alternative; boundary="000000000000502b50057b0859e9" --000000000000502b50057b0859e9 Content-Type: text/plain; charset="UTF-8" Attached are the draft minutes from the IETF 103 meeting; thanks to Jonathan Lennox for taking the notes. Please review and provide corrections to the list. thanks, Ted, Sean, (and it feels odd not have a third name here) --000000000000502b50057b0859e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Attached are the draft minutes from the IETF 103 meet= ing; thanks to Jonathan Lennox for taking the notes.=C2=A0
<= br>
Please review and provide corrections to the list.
=
thanks,

Ted, Sean, (and it feels od= d not have a third name here)
--000000000000502b50057b0859e9-- --000000000000502b52057b0859eb Content-Type: text/plain; charset="UTF-8"; name="RTCWEB Agenda, IETF 103.txt" Content-Disposition: attachment; filename="RTCWEB Agenda, IETF 103.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_joomcoqu0 77u/UlRDV0VCIEFnZW5kYSwgSUVURiAxMDMNCkNoYWlyczogQ3VsbGVuIEplbm5pbmdzLCBTZWFu IFR1cm5lciwgVGVkIEhhcmRpZQ0KUmVzcG9uc2libGUgQUQ6IEFkYW0gUm9hY2gNCg0KDQpOb3Rl IHRha2VyOiBKb25hdGhhbiBMZW5ub3gNCg0KDQpBZG1pbmlzdHJpdmlhDQoNCg0KTm90ZSB3ZWxs IHByZXNlbnRlZC4gIFRoaXMgbm90ZSB0YWtlciBjbGFpbWVkIChmYWxzZWx5KSBuZXZlciB0byBo YXZlIHNlZW4gaXQgYmVmb3JlLg0KDQoNCkN1bGxlbiBzdGVwcGluZyBkb3duIGFzIGNoYWlyLiAg UHJlc2VudGVkIHdpdGggZmluZSBhbmQgbGVzcyBmaW5lIHdoaXNrZXkuDQoNCg0KDQoNCklzc3Vl cyByYWlzZWQgZHVyaW5nIEFEIHJldmlldyBvZiBzZHAsIHNlY3VyaXR5LCBzZWN1cml0eQ0KYXJj aGl0ZWN0dXJlLCBhbmQgSVAgaGFuZGxpbmcgZHJhZnRzIChBZGFtIFJvYWNoKQ0KDQoNClNlY3Vy aXR5LWFyY2gNCg0KDQpJbnZhbGlkIGlkZW50aXR5IGluIGluaXRpYWwgYW5zd2VyOg0KUHJvcG9z YWw6IFRlYXIgZG93biBzZXNzaW9uLiAgTm8gb2JqZWN0aW9uLg0KDQoNCkludmFsaWQgaWRlbnRp dHkgaW4gdXBkYXRlZCBvZmZlcjoNCk1hcnRpbjogaXMgdGhpcyBpZiB0aGVyZSBwcmV2aW91c2x5 IHdhcyBpZGVudGl0eSwgb3Igbm90Pw0KQWRhbTogTm90IHN1cmUNCk1hcnRpbjogSSB0aGluayBp dCBzYXlzIGluIHRoZSBXM0MgZG9jDQpBZGFtOiBXZSBzaG91bGQgYmUgY29uc2lzdGVudCB3aXRo IHRoYXQsIHJlcGxpY2F0ZSBpdHMgZG9jdW1lbnQNCg0KDQpNYXJ0aW4gY2hlY2tzIFczQyBkb2Mu ICBJdCBzYXlzIGl0IHRyaWdnZXJzIGFuIGVycm9yLg0KDQoNCkludmFsaWQgaWRlbnRpdHkgaW4g dXBkYXRlZCBhbnN3ZXI6DQouLi4NCg0KDQpDb25jbHVzaW9uOiB0cmVhdCBldmVyeSBpbnZhbGlk IG9mZmVyL2Fuc3dlciB0aGUgc2FtZSB3YXkuICBTZXRSZW1vdGVEZXNjcmlwdGlvbiBmYWlscy4g IFVwIHRvIHdlYiBhcHAgYXMgdG8gd2hhdCB0byBkbyBuZXh0LiAgRGVmYXVsdCBpcyB0byByZW1h aW4gaW4gcHJldmlvdXMgc3RhdGUuDQoNCg0KQ2hyaXN0ZXI6IGlmIHlvdSBwcmV2aW91c2x5IGhh ZCBpZGVudGl0eSBhbmQgdGhlbiB5b3UgZG9uJ3QsIHdoYXQgaGFwcGVucz8NCk1hcnRpbjogSWRl bnRpdHkgc2F5cyBpdCdzIHVwIHRvIHRoZSBhcHAuICBXM0MgZG9jIHNheXMgaXQncyBhIGZhdGFs IGVycm9yLg0KDQoNCkVLUjogV2hhdCBteSBkb2Mgc2F5cyBpcyB0aGF0IGludmFsaWQgb2ZmZXIg aXMgcmVqZWN0ZWQsIGludmFsaWQgYW5zd2VyIGlzIHRlYXIgZG93bi4NCk1hcnRpbjogVGhhdCdz IG5vdCB3aGF0IFczQyBkb2Mgc2F5cw0KRUtSOiBUaGVuIHRoZXkncmUgd3JvbmcNCk5pbHM6IFRo YXQncyBkaWZmZXJlbnQgdGhhbiBldmVyeSBvdGhlciBTRFAgZXJyb3INCkhhcmFsZDogSXQgd291 bGQgYmUgcXVpdGUgbmV3IHRvIGhhdmUgZXJyb3JzIGNhdXNlIGEgdHJhbnNpdGlvbiB0byBjbG9z ZTsgZXZlcnkgb3RoZXIgZ2FyYmFnZSBzaG92ZWQgaW50byBzZXRSZW1vdGVEZXNjcmlwdGlvbiBj YXVzZXMgaXQgdG8gZG8gbm90aGluZy4NCkVLUiAob3IgWmFuemliYXIgQnVjay1CdWNrIE1jRmF0 ZSk6IFRoZW4gdGhlIGFuc3dlciB0byBxdWVzdGlvbiAxIGlzIGFsc28gc3RheSBpbiBpbml0aWFs T2ZmZXIgc3RhdGU/DQpBZGFtOiBUaGUgcHJvYmxlbSBpcyB3ZSdyZSB0cnlpbmcgdG8gdXNlIDMy NjQtc3R5bGUgaGFuZGxpbmcgaGVyZSwgYnV0IHRoZSAzMjY0IGhhbmRsaW5nIGlzIGluIHRoZSBK YXZhU2NyaXB0Lg0KUHJvcG9zYWw6IElmIHRoZSBpZGVudGl0eSBpcyBpbnZhbGlkLCBpdCdzIHRy ZWF0ZWQgbGlrZSBhbnkgb3RoZXIgaW52YWxpZCBTRFAuDQpbYWdyZWVtZW50XQ0KDQoNCkRUTFMg TVRJIFZlcnNpb246DQpEaWZmZXJlbnQgZG9jcyBzYXkgTVVTVCwgU0hPVUxEIE5PVCwgTVVTVCBO T1QgZG8gRFRMUyAxLjAuDQpNYXJ0aW46IHdlIHNob3VsZCBtYW5kYXRlIERUTFMgMS4yLCBkb24n dCBtZW50aW9uIGFueXRoaW5nIGVsc2UuDQpUZWQ6IFNob3VsZCB3ZSByZWZlcmVuY2Ugb2xkdmVy c2lvbnMtZGVwcmVjYXRlPw0KTWFydGluOiBOby4gRG9uJ3QgcHVsbCBhbnl0aGluZyBlbHNlIGlu dG8gQ2x1c3RlciAyMzguDQpFS1I6IFR3byBwb3NzaWJpbGl0aWVzOiBNYW5kYXRlIG5vIDEuMCBv dXJzZWx2ZXMsIG9yIGVsc2UgbGV0IG9sZHZlcnNpb25zLWRlcHJlY2F0ZSBkbyBpdC4NClRlZDog QW55IG9iamVjdGlvbiB0byBkZXByZWNhdGluZyAxLjAgb3Vyc2VsdmVzLCB3aXRob3V0IHJlZmVy ZW5jZSB0byBvbGR2ZXJzaW9ucy1kZXByZWNhdGUNCkJlcm5hcmQ6IEEgdmVyeSBsYXJnZSB1c2Vy IG9mIGEgZm9ya2VkIHZlcnNpb24gb2YgYW4gb2xkIGxpYndlYnJ0YyBoYXMgYmVlbiB1c2luZyBE VExTIDEuMCBmb3IgYSBsb25nIHRpbWUuICAoVGhlIHdvcmxkJ3MgbGFyZ2VzdCBwcm92aWRlciBv ZiB3ZWJydGMgc2VydmljZXMpLiAgQXMgb2YgdGhlIGxhc3QgdGllbSBJIGxvb2tlZCB0aGV5IGhh ZG4ndCBtb3ZlZCB0byBEVExTIDEuMi4NCk1hcnRpbjogSSBkb24ndCBleHBlY3QgYnJvd3NlcnMg dG8gdHVybiB0aGlzIG9mZiB0b21vcnJvdywgYnV0IEkgdGhpbmsgdGhpcyB3b3JraW5nIGdyb3Vw IGNhbiBjcmVhdGUgdGhlaXIgb3duIHNpZ25hbCB0aGF0IHdlIG5vIGxvbmdlciBjb25zaWRlciB0 aGlzIGdvb2QuICBXZSBjYW4gZ2l2ZSBsYXJnZSBkZXBsb3ltZW50cyBlbmNvdXJhZ2VtZW50Lg0K Q3VsbGVuIChmcm9tIHRoZSBmbG9vcik6IERvbid0IGNvbmZ1c2UgTVRJIHdpdGggd2hhdCdzIGRl cHJlY2F0ZWQuICBJIGNhbiBjZXJ0YWlubHkgaW1hZ2luZSBvdXIgTVRJIGlzIDEuMiwgYnV0IHRo ZXJlIGFyZSAqc2V2ZXJhbCogbGFyZ2UgZGVwbG95bWVudHMgb2YgMS4wLg0KRUtSOiBCcmVhayB0 aGlzIHVwIGludG8gcGllY2VzLiAgRmlyc3QsIG1ha2UgMS4yIE1USS4NClRlZDogQW55IG9iamVj dGlvbnMgdG8gdGhpcz8NCkN1bGxlbjogQWRkaW5nIDEuMiB0byBNVEkgbGlzdCwgb3IgdGhlIG9u bHkgTVRJPw0KVGVkOiBJIGRvbid0IHdhbnQgYW55b25lIG5ldyB0byBpbXBsZW1lbnQgMS4wDQpF S1I6IEN1cnJlbnRseSwgZG9jIGhhcyB0d28gcGFydHMsIE1VU1QgMS4wLCBTSE9VTEQgMS4yLiAg QW55b25lIG9iamVjdCB0byBNVVNUIDEuMj8NCltObyBvYmplY3Rpb25zXQ0KRUtSOiBUaHJlZSBw b3NzaWJpbGl0aWVzLiBNVVNUIDEuMDsgU0hPVUxEIE5PVC9NVVNUIE5PVCAxLjA7IHNheSBub3Ro aW5nLg0KVGVkOiBXaGVuIGRvIHdlIGV4cGVjdCBvbGR2ZXJzaW9ucy1kZXByZWNhdGU/DQpFS1I6 IHNpeCBtb250aHMgdG8gYSB5ZWFyLg0KQ3VsbGVuOiB3ZSBuZWVkIHRvIHJlY29nbml6ZSB0aGF0 IHRha2luZyBvdXIgbGFyZ2VzdCBkZXBsb3ltZW50cyBhbmQgbWFraW5nIHRoZW0gbm90IGNvbXBs aWFudCB3aXRoIG91ciBzcGVjIHdvdWxkIGJlIGJhZC4NCkFkYW06IFdvdWxkIGp1c3Qgc2F5aW5n IG5vdGhpbmcgYmUgZW5vdWdoPw0KQ3VsbGVuOiBJdCdzIGEgYml0IHVuZm9ydHVuYXRlLCBidXQg SSBjb3VsZCBsaXZlIHdpdGggaXQuICBCcm93c2VycyB3aWxsIGRvIHdoYXRldmVyIHRoZXkgZG8g cmVnYXJkbGVzcyBvZiB0aGUgc3BlY3MuDQpCZXJuYXJkOiBUaGVzZSBkZXBsb3ltZW50cyBoYXZl IGJlZW4gdmVyeSBzbG93IHRvIHVwZ3JhZGUgaW4gYSBsb3Qgb2Ygd2F5cy4gIEkgcHJvYmFibHkg YWdyZWUgd2l0aCBFS1IgdG8gc2F5IG5vdGhpbmcsIGFuZCBsZXQgaW5kaXZpZHVhbCBicm93c2Vy IHZlbmRvcnMgZGVjaWRlIHdoYXQgdG8gZG8uDQpNYXJ0aW46IFdlJ3JlIG5vdCBnb2luZyB0byBw dWxsIHRoZSBwbHVnIHJpZ2h0IGF3YXkuDQpFS1I6IEFsbCB0aGUgYnJvd3NlcnMgZG8gbWVhc3Vy ZW1lbnRzIG9mIHdoYXQgdGhlIHdvcmxkIGxvb2tzIGxpa2UsIHdlJ3JlIG5vdCBnb2luZyB0byB0 dXJuIGl0IG9mZiB1bnRpbCBpdCdzIHRpbWUuICBUd28gdGhpbmdzIHdlIHdhbnQgdG8gZG86IGVu Y291cmFnZSBwZW9wbGUgd2hhdCB3ZSB3YW50IHRoZW0gdG8gZG8sIGFuZCBsZXQgdGhlbSBrbm93 IHdoYXQgdGhleSBuZWVkIGZvciBpbnRlcm9wLiAgSW5jbHVkZSBub24tbm9ybWF0aXZlIHRleHQg dG8gc2F5IHdoYXQgdGhleSBuZWVkIHRvIHRhbGsgdG8gZXhpc3RpbmcgZGVwbG95bWVudHMuICBM ZXQgb2xkdmVyc2lvbnMtZGVwcmVjYXRlIHVwZGF0ZSB0aGlzIGRvYyB0byBmb3JiaWQgMS4wLg0K DQoNCkh1bTogU2F5IG5vdGhpbmcsIG9yIGdpdmUgZGVwbG95bWVudCBhZHZpY2U/DQpSZXN1bHQ6 IFJvdWdoIGNvbnNlbnN1cyB0byBpbmNsdWRlIGltcGxlbWVudGF0aW9uIGFkdmljZS4NCg0KDQoN Cg0KSWRlbnRpdHk6IEEtbGFiZWwgb3IgVS1sYWJlbCBpbiBJZGVudGl0aWVzPw0KQWRhbTogVS1s YWJlbCBpcyBwcm9iYWJseSBlYXNpZXIgdG8gZGVidWcNClRlZDogQS1sYWJlbCBpcyBndWFyYW50 ZWVkIHRvIGhhdmUgcGFzc2VkIHRocm91Z2ggcHVueWNvZGUgdmFsaWRhdGlvbiwgcmVtb3Zpbmcg aW52YWxpZCBjaGFyYWN0ZXJzICh1bmxlc3Mgc29tZW9uZSBjb25zdHJ1Y3RzIG9uZSBieSBoYW5k KS4NCkFkYW06IFRoZXNlIHRoaW5ncyBhcmUgdXNlZCBmb3IgZGlzcGxheSwgdGhpcyBpZGVudGl0 eSBoYXMgYmVlbiB2b3VjaGVkIGZvciBieSB0aGlzIGF1dGhvcml0eQ0KVGVkIChub3cgYXQgdGhl IGZsb29yIG1pYyk6IFRoZXJlIGFyZSBhIGJ1bmNoIG9mIHRoaW5ncyB0aGF0IGNhbiBoYXBwZW4g aWYgc29tZW9uZSB0cmllcyB0byBjb25zdHJ1Y3QgYSBkb21haW4gcG9ydGlvbiBvZiBhbiBpZGVu dGl0eS4gIFUtbGFiZWxzIGFsc28gaW4gdGhlIHJlYWxtIG9mIGNvbmZ1c2FiaWxlcy4gIEEtbGFi ZWwgbWF0Y2hpbmcgaXMgZWFzaWVyLg0KQWRhbTogVGhpcyB3aWxsIGJlIGhhbmRsZWQgdG8gdGhl IEphdmFzY3JpcHQgZm9yIGRpc3BsYXkgdG8gdGhlIHVzZXIuDQpUZWQ6IEphdnNjcmlwdCBhbHJl YWR5IGhhcyB0byB0cmFuc2xhdGUgZnJvbSBQdW55Y29kZSBmb3IgYW55IElETiBuYW1lIGFscmVh ZHkuDQpNYXJ0aW46IFdlJ3JlIGp1c3QgY29tcGFyaW5nIHRoaXMgd2l0aCBsYWJlbHMgd2UgZ2V0 IGVsc2V3aGVyZS4NCkhhcmFsZDogU2xpZ2h0IHByZWZlcmVuY2UgZm9yIFUtbGFiZWxzOyBBLWxh YmVscyBhcmUgYSBoYWNrIHRvIGdldCBhcm91bmQgdGhlIGxpbWl0YXRpb25zIG9mIGRvbWFpbiBu YW1lIHN5c3RlbXMuICBJZiB3ZSBoYXZlIHN5c3RlbXMgdGhhdCBoYW5kbGUgVS1sYWJlbHMgd2Ug c2hvdWxkIGp1c3QgdXNlIHRoYXQuICBJZiB5b3UgcmVxdWlyZSB0aGF0IHRoZXkncmUgdmFsaWQg VS1sYWJlbHMgdGhlbiBhbnl0aGluZyB0aGF0J3Mgbm90IGEgdmFsaWQgVS1sYWJlbCBpcyBpbnZh bGlkIGFueXdheS4NCkFkYW06IEl0J3MgZ29pbmcgdG8gYmUgY29tcGFyZWQgd2l0aCB0aGUgZG9t YWluIGFueXdheS4NCkhhcmFsZDogQnJvd3NlcnMgZG8gaW50ZXJlc3RpbmcgdGhpbmdzIHdpdGgg SUROcy4NCkJlcm5hcmQ6IExvb2tpbmcgYXQgdGhlIFdlYlJUQyBpZGVudGl0eSBzcGVjLCBhbmQg aXQncyBkaXN0dXJibGluZ2x5IHZhZ3VlLg0KDQoNClRlZCBhcyBjaGFpcjogSWYgeW91IHRoaW5r IHlvdSB1bmRlcnN0YW5kIHRoaXMgcHJvYmxlbSwgcHV0IHlvdXIgaGFuZCB1cCBub3cuIFtObyBv bmVdDQpUZWQ6IElmIHlvdSB1bmRlcnN0YW5kIHRoaXMgcHJvYmxlbSBlbm91Z2ggdG8gYmUgYWZy YWlkIG9mIGl0LCBwdXQgeW91ciBoYW5kIHVwLiBbTG90c10NCkN1bGxlbjogQWx0ZXJuYXRpdmUg ZGlzcHV0ZSBtZWNoYW5pc20uLi4NCg0KDQpIdW06IGlmIHlvdSB3b3VsZCBwcmVmZXIgQS1sYWJl bHMsIGh1bSBub3cgW2hhcmRseSBhbnlvbmVdDQpJZiB5b3Ugd291bGQgcHJlZmVyIFUtbGFiZWxz LCBodW0gbm93IFtoYXJkbHkgYW55b25lXQ0KRUtSOiBSb3VnaCBub24tY29uc2Vuc3VzLg0KDQoN CkVLUjogU3VnZ2VzdGlvbiB0aGF0IFRlZCBIYXJkaWUgZGVjaWRlcy4NClRlZDogU3VnZ2VzdCBh c2tpbmcgaW1wbGVtZW50b3JzIHdoYXQgdGhleSBoYXZlLg0KTWFydGluOiBJIGJlbGlldmUgaXQn cyBVLWxhYmVscy4gIEJ1dCBpdCdzIGJlZW4gdGhyZWUgeWVhcnMuDQpBZGFtOiBZb3UgcHJvYmFi bHkgZGlkbid0IHRlc3QgYWdhaW5zdCBJRE5zLg0KTWFydGluOiBuby4NCg0KDQpUZWQ6IFN1Z2dl c3Rpb24sIFUtbGFiZWxzIHVubGVzcyBzb21lb25lIHRlbGxzIHVzIHdoeS4NCkh1bTogY29uc2Vu c3VzLg0KDQoNCklkZW50aXR5IFVzZXIgUG9ydGlvbiBFc2NhcGluZzoNClNheXMgQCBzaWducyBt dXN0IGJlIGVzY2FwZWQsIGRvZXMgbm90IHNheSBob3cuICBFeGFtcGxlIGltcGxpZXMgcGVyY2Vu dC1lc2NhcGluZy4gIFN1Z2dlc3Rpb246IHNheSB3ZSBtZWFuIHRoYXQuDQpNYXJ0aW46IGl0J3Mg bm90IHRoYXQgc2ltcGxlLiAgQ29uZnVzYWJpbGl0eS4gIElmIHRoZXkgY2FuIHB1dCBhbiBAIGlu IHRoZWlyIHVzZXIgbmFtZXNwYWNlLCB0aGVuIGV4YW1wbGUuY29tIGNhbiBtYWtlIGFuIGFzc2Vy dGlvbiBhYm91dCBhZGFtQG5vc3RydW0uY29tLg0KQWRhbTogVGhhdCdzIHZlcnkgdXNlci1ob3N0 aWxlLiBGaXJlZm94LmNvbSBrbm93cyBtZSBhcyBhZGFtQG5vc3RydW0uY29tLiAgUHJlc2VudGlu ZyBhZGFtJTQwbm9zdHJ1bS5jb20gdG8gYSBub24tdGVjaG5pY2FsIHVzZXIgaXMgdXNlci1ob3N0 aWxlLg0KTWFydGluOiBCdXQgYW55IG90aGVyIGRvbWFpbiBjYW4gY2xhaW0gYWRhbUBub3N0cnVt LmNvbSBhbHNvLg0KQWRhbTogU3VnZ2VzdCBtYWtpbmcgaXQgY2xlYXIgaW4gdGhlIFVYIHRoYXQg RmlyZWZveC5jb20gaXMgY2xhaW1pbmcgSSBhbSBhZGFtQG5vc3RydW0uY29tLg0KTWFydGluOiBJ IHdhbnQgdG8gYmUgdXNlci1ob3N0aWxlLCBJJ2QgcmF0aGVyIHRoYXQgb25seSBub3N0cnVtLmNv bSBjYW4gY2xhaW0gdGhhdC4NCkFkYW06IFRoYXQncyBub3QgaG93IGxvdHMgb2Ygc2VydmljZXMg d29yay4NCg0KDQpIdW06IHBlcmNlbnQtZW5jb2Rpbmcgb3IgaW1wbGVtZW50YXRpb24tZGVwZW5k ZW50IHRyYW5zZm9ybT8NCltWZXJ5IHNsaWdodCBodW0gZm9yIGZpcnN0IG9wdGlvbiwgbm9uZSBm b3IgdGhlIHNlY29uZF0NClRlZDogVGFrZSBpdCB0byB0aGUgbGlzdD8NCkVLUjogUHJlcGFyZSBh IFBSIGZvciBvcHRpb24gMSwgYW5kIGJpa2VzaGVkIGl0IG9uIHRoZSBsaXN0Lg0KU2VhbjogQ2Fu IHdlIHN0YXJ0IElFVEYgbGFzdCBjYWxsLCBhbmQgbm90ZSB0aGF0IHdlIGhhdmUgYSBwdWxsIHJl cXVlc3Qgb24gaXQ/DQpBZGFtOiBJJ2QgcmF0aGVyIG5vdC4NCkN1bGxlbjogV2hhdCBkb2VzIFNU SVIgc2F5Pw0KQWRhbTogU1RJUiBkb2Vzbid0IGhhdmUgdGhpcyBwcm9ibGVtLg0KDQoNCkVLUjog TWFydGluIGFuZCBJIGhhdmUgcHJlcGFyZWQgUFJzIGZvciBhbGwgdGhyZWUgaXNzdWVzLg0KDQoN Cg0KDQpMYXRlIEpTRVAgQ2hhbmdlcyAoSnVzdGluIFViZXJ0aSBDdWxsZW4gSmVubmluZ3MpDQpT ZWUgZ2l0aHViIFBScyA4NDksIDg1MCwgYW5kIDg1MQ0KDQoNCklDRS0+SUNFYmlzLiBObyBvYmpl Y3Rpb24uDQoNCg0KU3RvcCB1c2luZyBhcHBkYXRhLiAgVzNDIGlzIHJlbW92aW5nIGl0Lg0KSGFy YWxkOiBNU0lEIGRyYWZ0IHNheXMgeW91IHB1dCB0aGUgdHJhY2sgSUQgaW4uICBEbyB3ZSBuZWVk IHRvIHB1bGwgTVNJRCBkcmFmdD8gIFB1dCBpbiB0ZXh0IHRvIHNheSBnZW5lcmF0ZSByYW5kb20g dHJhY2sgSUQuDQpDdWxsZW46IE1TSUQgaXMgSUVTRyBhcHByb3ZlZD8NCkhhcmFsZDogeWVzLiAg SXQncyBqdXN0IGEgbWF0dGVyIG9mIGNvbnNpc3RlbmN5LiAgSlNFUCBhbHJlYWR5IHNheXMgdGhp cy4NClRlZDogTVNJRCBpcyBhbiBNTVVTSUMgZG9jdW1lbnQuDQpGbGVtbWluZyAoTU1VU0lDIGNo YWlyKTogSWYgSGFyYWxkIGlzIHdpbGxpbmcgdG8gZG8gdGhlIHdvcmsgYW5kIHRoZSBBRHMgZG9u J3QgbWluZCwgd2UncmUgaGFwcHkgdG8gZG8gd2hhdGV2ZXIgUlRDV2ViIG5lZWRzLg0KVGVkOiBJ ZiBNTVVTSUMgcHJvY2VzcyBydW5zIHRvIGNvbXBsZXRpb24sIGRvZXMgYW55b25lIG9iamVjdCB0 byB0aGlzPyAgKE5vLikNCg0KDQpSZWplY3QgYWxsIHNlY3Rpb25zIGluIGEgQlVORExFIGdyb3Vw IGlmIHlvdSByZWplY3QgdGhlIG9mZmVyZXIgdGFnZ2VkIG09IHNlY3Rpb24uDQpFS1I6IFRoaXMg ZG9lc24ndCByZWZsZWN0IG15IHVuZGVyc3RhbmRpbmcgb2YgaG93IEJVTkRMRSB3b3Jrcy4NCkJl cm5hcmQ6IE5vLCBDdWxsZW4gaXMgcmlnaHQuICBJZiB5b3UgcmVqZWN0IHRoZSBmaXJzdCBvbmUg eW91IGRvbid0IGtub3cgd2hhdCB0byB0YWtlLg0KRUtSOiBidW5kbGUtb25seSBoYXMgdGhpcyBw cm9wZXJ0eSwgYnV0IG5vdCBvdGhlcndpc2U/DQpbQXR0ZW1wdCB0byByZWFkIHdoYXQgYnVuZGxl IHNheXNdDQpFS1I6IEkgdGhpbmsgdGhpcyBpcyBhIG1pc3Rha2UgaW4gYnVuZGxlLg0KVGVkOiBT dWdnZXN0IG1pbmktbWVldGluZywgZ2V0IGEgUFIgaW4gbGF0ZSBuZXh0IHdlZWsuDQpIYXJhbGQ6 IHBsZWFzZSB3cml0ZSB0ZXN0cyBmb3IgdGhpcz8NCk5pbHM6IG5vdCBzdXJlIGhvdw0KVGVkOiBB bnN3ZXIgaXMgaW4gQ2hyaXN0ZXIsIEVLUiwgYW5kIFRheWxvcidzIGhhbmRzLg0KDQoNCkNoYW5n ZSA0OiBjb250cmFkaWN0YXJ5IGFkdmljZSBvbiB3aGV0aGVyIHN1YnNlcXVlbnQgb2ZmZXJzIHNw ZWNpZnkgcHJvdG8gZmllbGQgSUNFIHNlbGVjdGVkDQpFS1I6IFRoaXMgY2FtZSBvdXQgb2YgQkZD UCBvdmVycmlkaW5nIElDRSBtYXNoaW5nIFNEUCBwcm90byBmaWVsZC4NCldlIHNob3VsZCBzYXkg dGhhdCBKU0VQIG92ZXJyaWRlcyBpY2Utc2lwLXNkcA0KDQoNCg0KDQpTZXNzaW9uIGFuZCB2ZXJz aW9uIGZpZWxkcyBpbiBTRFANCk5pbHM6IFNlc3Npb24gc2hvdWxkIGJlIGF0IG1vc3QgMl42MyBz aW5jZSBpdCdzIHN0YWJsZSwgdmVyc2lvbiBhdCBtb3N0IDJeNjIgc2luY2UgaXQgaW5jcmVtZW50 cy4NClNlYW46IENhbiB5b3UgcHJvZHVjZSBhIFBSPw0KTmlsczogU3VyZQ0KDQoNCkJlcm5hcmQ6 IEhhcmFsZCByYWlzZWQgYW4gaXNzdWUgYWJvdXQgb2ZmZXIgdG8gcmVjZWl2ZSBzaW11bGNhc3QN CkhhcmFsZDogVGV4dCBpbiBKU0VQIGN1cnJlbnRseSBzYXlzIG9mZmVyZXIgY2FuJ3QgaW5jbHVk ZSBhbnl0aGluZyBhYm91dCB3aGF0IHNpbXVsY2FzdCBpdCBhY2NlcHRzIGluIGFuIG9mZmVyLiAg VGhpcyBpcyBzaWxseSwgc2hvdWxkIGJlIHJlbW92ZWQuDQpUZWQ6IEFyZSB5b3Ugdm9sdW50ZWVy aW5nIHRvIHdyaXRlIGEgUFI/DQpIYXJhbGQ6IFllcy4NCg0KDQpUZWQ6IEkgYmVsaWV2ZSBvbmNl IHRoZXNlIFBScyBhcmUgbWVyZ2VkIHdlIHJ1biB0aHJvdWdoIGFub3RoZXIgV0dMQyBhbmQgSUVU RiBMQywgYW5kIHlvdSBkZWNpZGUgd2hhdCB0byBkbyB3aXRoIGl0Pw0KQWRhbTogWWVzLCBhbmQg SSBwbGFuIHRvIHB1dCBpdCBpbiBmcm9udCBvZiB0aGUgSUVTRyBhZ2Fpbi4NCg0KDQoNCg0KDQoN CmRyYWZ0LWlldGYtcnRjd2ViLW1kbnMtaWNlLWNhbmRpZGF0ZXMgKFlvdWVubiBGYWJsZXQpDQoN Cg0KU3R1YXJ0IENoZXNoaXJlOiBZb3Ugb25seSBoYXZlIHRvIG1ETlMsIGFuZCBJIGFwcGVhciBp biB0aGUgbWVldGluZy4gIERvIHlvdSBtZWFuIC5sb2NhbCwgb3IgYSBzZXJ2aWNlPw0KWW91ZW5u OiBBIC5sb2NhbA0KRGF2aWQgU2NoZW5hemk6IFdoYXQgZG8geW91IG1lYW4gYnkgIm1ETlMgc3Vj Y2VlZHMiPw0KWW91ZW5uOiBZb3UgaGF2ZSBubyBtdWx0aWNhc3QtY2FwYWJsZSBpbnRlcmZhY2Vz PyAgRGVsaWJlcmF0ZWx5IG5vdCBzcGVjaWZpZWQuDQoNCg0KW1doZW4gdG8gdXNlIG1ETlMgZm9y IEhvc3QgQ2FuZGlkYXRlcyAtIGluY2x1ZGUgaG9zdCBjYW5kaWRhdGUgaWYgcHVibGljIGFjY29y ZGluZyB0byBTVFVOIHNlcnZlcl0NCk5pbHM6IFNUVU4gc2VydmVyIG1pZ2h0IGJlIGluc2lkZSB5 b3VyIG5ldHdvcmsNCllvdWVubjogSW4gdGhlIGNhc2Ugd2hlbiB5b3UgbWlnaHQgd2FudCB0byBk byB0aGlzLCB0aGVyZSB3aWxsIGJlIG5vIGxvY2FsIG5ldHdvcmsgc3R1biBzZXJ2ZXIuDQpDdWxs ZW46IGxvY2FsIG5ldHdvcmsgc3R1biBzZXJ2ZXJzIGFyZSBxdWl0ZSBjb21tb24NCg0KDQptRE5T IG5hbWVzIHNob3VsZCBiZSBsaW1pdGVkIGJ5IG9yaWdpbi9saWZlIG9mIHdlYiBwYWdlDQo/Pzog V2h5IFNIT1VMRCBub3QgTVVTVD8NCllvdWVubjogSW4gYSBicm93c2VyLCBNVVNULiAgT3RoZXJ3 aXNlLCBtYXkgbm90IGJlLg0KPz86IElzbid0IGRyYWZ0IGNvbmNlcm5pbmcgb25seSB3ZWIgcGFn ZXMNClllcnVubj8/ICAoR29vZ2xlLCBjby1hdXRob3IpOiANClRlZDogV2hhdCBpZiBJIGhhdmUg dGhlIHNhbWUgcGFnZSBvcGVuIHR3aWNlIChzYXkgb25jZSBpbmNvZ25pdG8sIG9uZSBub3QpOiBp cyBvcmlnaW4gc2NvcGUgZW5vdWdoPw0KWW91ZW5uOiBTSG91bGQgYmUNCkN1bGxlbjogSW4gbmV0 d29ya3Mgd2hlcmUgeW91IGhhdmUgcmVsYXlzLCBldGMuIC0tIGhvdyBxdWlja2x5IGNhbiB5b3Ug ZGVsZXRlIHRoZXNlIG5hbWVzPw0KU3R1YXJ0OiBUaHJlZSBxdWFydGVycyBvZiBzZWNvbmQgZGVs YXkgb24gYW5ub3VuY2luZyBhIG5hbWUuDQpZb3Vlbm46IEluIHByYWN0aWNlIHdlJ3ZlIG9ic2Vy dmVkIG5vIGRlbGF5DQpTdHVhcnQ6IFdpdGggd2hhdCBzb2Z0d2FyZT8NCllvdWVubjogbWFjT1MN ClN0dWFydDogWW91IGNhbiBza2lwIHRoZSBjaGVjayBmb3IgdW5pcXVlbmVzcywgYnV0IGluIHBy aW5jaXBsZSB5b3UgbWlnaHQgc3RvbXAgb24gc29tZW9uZS4NCllvdWVubjogV2l0aCBVVUlEdjQg dGhhdCdzIHZlcnkgdW5saWtlbHkNClN0dWFydDogWW91IGNvdWxkIHVzZSBhIGRpZmZlcmVudCBy ZWNvcmQgdHlwZSwgc2luY2Ugbm8gb25lJ3MgZXhwZWN0aW5nIHRvIHNzaCB0byBpdC4gIFlvdSBj b3VsZCB1c2UgdGhlIF9pY2Ugc2VydmljZSwgdG8gYXZvaWQgc3RvbXBpbmcgb24gYW55b25lIGVs c2UuDQpZb3Vlbm46IEludGVyZXN0aW5nLg0KU3R1YXJ0OiBPbiBjbGVhbnVwLCBhcyBzb29uIGFz IHlvdSBzdG9wIHVzaW5nIGl0LCBtYWNoaW5lIHNlbmRzIGFubm91bmNlbWVudCB3aXRoIFRUTCAw LCBjbGVhbmluZyB1cC4NCg0KDQpNYXJ0aW46IEkgdGhpbmsgd2Ugd2FudCBzY29wZSBvbiBjb21t dW5pY2F0aW9uIHBlZXI7IGluIGJyb3dzZXIgdGhpcyBtYXRjaGVzIG9yaWdpbi4gIFR3byBlbnRp dGllcyB3ZSB3YW50IHRvIGNvbmNlYWwgaWRlbnRpdHkgZnJvbSwgd2ViIGFwcCBhbmQgYXBwbGlj YXRpb24gcGVlci4NCg0KDQpEYXZpZCBTY2hpbmF6aSAoY2hhaXIgb2YgRE5TLVNEKTogQ2FuIHlv dSBwbGVhc2UgcG9zdCB5b3VyIGRyYWZ0IG9uIEROUy1TRCBtYWlsaW5nIGxpc3Q/DQpZb3Vlbm46 IHN1cmUNCg0KDQpUaW0gUGFudG9uOiBJIGRvbid0IHNlZSBhbnkgZG93bnNpZGUgdG8gbWFraW5n IHNjb3BlIHRvIHBlZXIgY29ubmVjdGlvbiBpbnN0YW5jZS4NCk1hcnRpbiBUaG9tc29uOiBJIGFn cmVlLg0KWW91ZW5uOiBQYWdlIGNhbiBvcGVuIHRlbnMgb2YgdGhvdXNhbmRzIG9mIHBlZXIgY29u bmVjdGlvbnMuICBXb3VsZCBmbG9vZCBtRE5TLg0KTWFydGluOiBXZSBhbHJlYWR5IGhhdmUgdGhp cyBwcm9ibGVtIHdpdGggU1RVTi9UVVJOLCBJIHdvdWxkIHRocm93IHRoaXMgaW4gdGhlIHNhbWUg cmF0ZSBsaW1pdCBidWNrZXQuDQoNCg0KTWFydGluOiBEbyB5b3UgaGF2ZSB0byBhbm5vdW5jZSB0 aGF0IHlvdSBoYXZlIGEgbmFtZSwgb3IgY291bGQgeW91IGp1c3QgcmVzcG9uZCB0byBxdWVyaWVz Pw0KU3R1YXJ0OiBJbiB0aGVvcnkgeW91IGNvdWxkLCBidXQgd291bGQgcmVxdWlyZSBjaGFuZ2Vz IHRvIEFQSXMuDQoNCg0KRUtSOiBBZ3JlZSB0aGVzZSBzaG91bGQgYmUgc2NvcGVkIHRvIFBDLg0K Q3VsbGVuOiBJIHRoaW5rIHdlIHNob3VsZCBkaXNjdXNzIHRoZSByYXRlIGxpbWl0aW5nLg0KWW91 ZW5uOiBtRE5TIGltcGxlbWVudGF0aW9uIHJhdGUgbGltaXRzIGl0Lg0KQ3VsbGVuOiBXaGF0IGlz IGl0PyAgSSB0aGluayBtRE5TIHdhcyBub3Qgd3JpdHRlbiB3aXRoIHRoZSBhc3N1bXB0aW9uIHRo YXQgaG9zdGlsZSBkcml2ZS1ieSB3ZWIgcGFnZXMgd291bGQgYmUgZG9pbmcgdGhpcy4NCkNocmlz dGVyOiBJIHRob3VnaHQgeW91IHNhaWQgbGltaXQgb2Ygb25lIHBlciBwYWdlLCBidXQgd291bGQg bmVlZCB0d28gZm9yIElQdjQvSVB2Ni4NCllvdWVubjogWWVzLCBvbmUgcGVyIElQIGFkZHJlc3Mu DQpNYXJ0aW46IFJhdGUgbGltaXRpbmcgaXMgYW5hbG9nb3VzIHRvIFNUVU4NCkN1bGxlbjogTm8s IFNUVU4gaXNuJ3QgbXVsdGljYXN0DQpZZXJ1bm4/PyAyIChHb29nbGUpOiBUaG91Z2h0IG9mIGNy ZWF0aW5nIHBvb2wgb2YgdGhlc2UNCkN1bGxlbjogV2UgYWxyZWFkeSBoYXZlIHNpbWlsYXIgcG9v bCBmb3IgU1RVTg0KRUtSOiBJIGRvbid0IHNlZSBob3cgdGhpcyBmaXhlcyByYXRlIGxpbWl0aW5n DQpZb3Vlbm46IExpbWl0ZWQgcGVyIHRvcCBvcmlnaW4NCkVLUjogSSdsbCBqdXN0IG5hdi4gIFJl Z2lzdGVyIGRvbWFpbnMgMS1vbmUgYmlsbGlvbi5leGFtcGxlLmNvbS4gIFdlYiBzZWN1cml0eSdz IGhhcmQuICBSZXF1aXJlcyBtb3JlIHRoaW5raW5nIHRoYW4gSSdtIGdldHRpbmcgZnJvbSB0aGlz IGRvYy4NCk1hcnRpbjogSSdsbCBvcGVuIGFuIGlzc3VlIG9uIG5vdCBicm9hZGNhc3RpbmcgdGhl IG5hbWUuICBNaWdodCBoZWxwIG9uIG5vdCBzdHJlc3NpbmcgdGhlIG5ldHdvcmsuDQpDdWxsZW46 IE5vLCBkb2Vzbid0IGhlbHANCg0KDQpUaW0gUGFudG9uOiBJcyAubG9jYWwgZnVsbHkgc3RhbmRh cmRpemVkPw0KU3R1YXJ0OiBSRkMgNjc2MiwgcmVjb3JkZWQgaW4gSUFOQSBzcGVjaWFsIHVzZSBk b21haW4gcmVnaXN0cnkuICBBbHNvLCBuZXR3b3JrcyBkb24ndCBzdXBwb3J0IG1ETlM7IG5ldHdv cmtzIHN1cHBvcnQgbXVsdGljYXN0Lg0KQWRhbTogSXNzdWVzIHdpdGggdGhpcyB3b3VsZCBhcmlz ZSBpbiBlbnRlcnByaXNlLCB3aG8gdHVybiBvZmYgdGVsZW1ldHJ5LCBub3QgY2xlYXIgaG93IG11 Y2ggd2UgY291bGQgdGVsbCB0aGlzDQpOaWxzOiBPbmUgbUROUyBwZXIgd2hlcmUgeW91IGZldGNo ZWQgeW91ciB3ZWJwYWdlIGZyb20uICBTaG91bGRuJ3QgYmUgdGhhdCBoaWdoLCBidXQgbWF5IGJl Lg0KQ3VsbGVuOiBXZSBzaG91bGQgZG8gZmxvb2RpbmcgYW5hbHlzaXMgYW5kIGRhdGEgYmVmb3Jl IHdlIHN0YXJ0IGV4cGVyaW1lbnRpbmcgb24gbGFyZ2UgY29ycG9yYXRlIG5ldHdvcmtzLCB0aGlz IGlzIGEgY29uZ2VzdGlvbiBjb250cm9sIGlzc3VlLg0KU3R1YXJ0OiBJJ20gbm90IHN1cmUgd2h5 IHlvdSdyZSBjb25jZXJuZWQgYWJvdXQgcGlja2luZyBvbmUgYWRkcmVzcy4gIEV2ZXJ5IG1hYyBo ZXJlIGhhcyBvbmUgLmxvY2FsIG5hbWUgZm9yIGFsbCBpdHMgaW50ZXJmYWNlcy4gIEFsc28sIGFu bm91bmNlbWVudHMgcmVkdWNlIA0KDQoNClllcnVubj8/OiBJbXBsZW1lbnRlZCBpbiBDaHJvbWUg Q2FuYXJ5LCB3aWxsIGxhbmQgdG9kYXkNCg0KDQpUZWQ6IFdvdWxkIGxpa2UgdG8gY2xvc2UgdGhl IHdvcmtpbmcgZ3JvdXAuICBQbGVhc2UgbGV0J3MgZ2V0IENsdXN0ZXIgMjM4IHRvIEhlYXRoZXIg YXMgc29vbiBhcyBwb3NzaWJsZS4NCg0KDQpUaW1lbGluZSBmb3IgY2xvc2luZyB0aGUgd29ya2lu ZyBncm91cC4= --000000000000502b52057b0859eb-- From nobody Mon Nov 19 10:28:46 2018 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 562EB130DE3 for ; Mon, 19 Nov 2018 10:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7fd76q-Y1KN for ; Mon, 19 Nov 2018 10:28:38 -0800 (PST) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 81058130E48 for ; Mon, 19 Nov 2018 10:28:36 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id u6so2790428pfh.11 for ; Mon, 19 Nov 2018 10:28:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=nRypopvRlXySpyyaqY0sIiJYKISpucuoAr0RKxxy8tI=; b=Ft0QaSVDIW7URVmHFkPnPQVvKTo0ao4UvIRGo5G5K+n2rGOY5E6rpVXiIlooBj49RV 6+Snb8iHNVg+VB0lDdTXsZeRgnied4yGFfd2VOQ8lPKMpDcbN7VX2khRwx1y8qfYvQ0p oYmYiXbjgkzI3KElyLO0NXZyULPhgC/76L+DjmeEdaraEt1jjwgT9NfFFxWK/faTHWWw OXaP41fbg9+jrK6SIRB6s+dQUQ9dYhc/HtHZVLwToJSdvKkmkUWKn9iC8n1/bs4TW78n bzh+XQzMLOpBlUGGUeba8dSvjDlv8QbpZV9+Zuebwyj+5eCZ1U6btHOxtnvlYPuhVk8G 8uWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=nRypopvRlXySpyyaqY0sIiJYKISpucuoAr0RKxxy8tI=; b=uEgGL4bNx7l9B866xNVVuXtLSYKdPuRwtG5Hx+yIzYkHbZCIewGHkDTlJw7nbifNfk CjtsqKOCO5Qxdmsful7UrV1+4W0AWz4DWBUBN0CVfauGL+Xr2t7QbRzowlbC7mdoREuZ NB1DOu0xc00nGnAX8CLe7FPGUcTFqiIncpICcWrsdSeAtOwlCPRmooy2lHJ1fKibRV8v Gy7nt7PiMJhgN3USgCaDCLaSI9PsEwhhF4dMMxoKttlrlOo7IiaZyvjCv6obLWJCTxzs TUZZknOx7XsHA1DHI+cmlnei4I1o7wUP557eqA3owxzY9rZkH+Cil3aDKw7vPQMiMvfi PlsA== X-Gm-Message-State: AGRZ1gLrsvpUNT5gEr9WaJxqbdfPBijDHWMkYFbyygO3m7m6hOY0WKUJ kUKWwvAoXRG248m4rXUY4xRibErVM68= X-Google-Smtp-Source: AJdET5ejDRyTRH8BANY/gdwSZCfAnynwPMYeyH+LgERzWZ+IZwQxQDcDJZwTJk8tlYEjXXW5JsvMNw== X-Received: by 2002:a63:9749:: with SMTP id d9mr20670830pgo.415.1542652115837; Mon, 19 Nov 2018 10:28:35 -0800 (PST) Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com. [209.85.215.172]) by smtp.gmail.com with ESMTPSA id u76-v6sm60016442pfa.176.2018.11.19.10.28.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 10:28:35 -0800 (PST) Received: by mail-pg1-f172.google.com with SMTP id w6so1934040pgl.6; Mon, 19 Nov 2018 10:28:34 -0800 (PST) X-Received: by 2002:a62:83ce:: with SMTP id h197mr11805586pfe.187.1542652114640; Mon, 19 Nov 2018 10:28:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 19 Nov 2018 13:28:23 -0500 X-Gmail-Original-Message-ID: Message-ID: To: RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="0000000000004e246e057b08af5f" Archived-At: Subject: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 18:28:40 -0000 --0000000000004e246e057b08af5f Content-Type: text/plain; charset="UTF-8" Hi All, The current language in JSEP makes it incompatible with any ICE implementation, either existing or the future ones compliant with ice-sip-sdp draft. You can, of course, overwrite ice-sip-sdp, but this will mean JSEP will be a completely incompatible system. The problem is that JSEP proposes to use UDP protocol in the m= line and at the same time update address and port to the currently selected candidate. Based on ice-sip-sdp, if protocol of the current selected candidate does not match protocol in the m= line, this will mean either ICE mismatch or additional candidate with protocol, address, and port form m= and c= line. Second, ice-sip-sdp treats SDP during ICE restart, when multiple candidates are present different from SDP when ICE is not restarted (single candidate). According to ice-sip-sdp, when only a single candidate is present, this candidate protocol, address and port are set in m= and c= line. JSEP proposes to put original UDP protocol and address and port from the single candidate. To be specific, it is not the fact that protocol in m= line is not updated is an issue. It is that protocol in not updated but address and port in m= and c= line are updated. In the ice-sip-sdp draft there is a solution for this issue -- set address to IN IP4 0.0.0.0 and port to 9. This is specifically supposed to be ignored and not cause the ICE mismatch or extra candidates. If JSEP wants to overwrite ice-sip-sdp, it can specify that m- line protocol should always be set to UDP based protocol, c= line address should be set to IN IP4 0.0.0.0 and m= line port set to 9. In case of an ICE only system where c= and m= line address information is irrelevant, this makes implementation simpler since m= and c= line address information can stay constant for the duration of the session. Regards, _____________ Roman Shpount --0000000000004e246e057b08af5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

The current language in JSEP ma= kes it incompatible with any ICE implementation, either existing or the fut= ure ones compliant with ice-sip-sdp draft. You can, of course, overwrite ic= e-sip-sdp, but this will mean JSEP will be a completely incompatible system= .

The problem is that JSEP proposes to use UDP pro= tocol in the m=3D line and at the same time update address and port to the = currently selected candidate. Based on ice-sip-sdp, if protocol of the curr= ent selected candidate does not match protocol in the m=3D line, this will = mean either ICE mismatch or additional candidate with protocol, address, an= d port form m=3D and c=3D line.

Second, ice-sip-sd= p treats SDP during ICE restart, when multiple candidates are present diffe= rent from SDP when ICE is not restarted (single candidate). According to ic= e-sip-sdp, when only a single candidate is present, this candidate protocol= , address and port are set in m=3D and c=3D line. JSEP proposes to put orig= inal UDP protocol and address and port from the single candidate.

To be specific, it is not the fact that protocol in m=3D li= ne is not updated is an issue. It is that protocol in not updated but addre= ss and port in m=3D and c=3D line are updated. In the ice-sip-sdp draft the= re is a solution for this issue -- set address to IN IP4 0.0.0.0 and port t= o 9. This is specifically supposed to be ignored and not cause the ICE mism= atch or extra candidates. If JSEP wants to overwrite ice-sip-sdp, it can sp= ecify that m- line protocol should always be set to UDP based protocol, c= =3D line address should be set to=C2=A0 =C2=A0IN IP4 0.0.0.0 and m=3D line port set to 9. In case of an ICE only sy= stem where c=3D and m=3D line address information is irrelevant, this makes= implementation simpler since m=3D and c=3D line address information can st= ay constant for the duration of the session.

Regar= ds,
_____________
Roman Shpount
--0000000000004e246e057b08af5f-- From nobody Mon Nov 19 10:35:16 2018 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 B2F73130DED for ; Mon, 19 Nov 2018 10:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 s8IfVGatCoTw for ; Mon, 19 Nov 2018 10:35:05 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 E49DD130DDA for ; Mon, 19 Nov 2018 10:35:04 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id v11so8999008itj.0 for ; Mon, 19 Nov 2018 10:35:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=57OGVqd2vPNy10zz28LFXN3FQP+tTv9yzKd78YLuUXU=; b=MC0P2TQHQN/qiEIvXJrRWF+NsYyk90+1zKm6waxkNE+KRwhMBE70KhpwwAsoJtfiob eiGM4LPSPH3KCasymTkySIMrV86qvys9/fv/jr5AdyvfRZpGeDYU4JdaMFH2BIRBkWoj Sya9f1plL0Ls4L8h+lIQm63KQ3/RBGv8GhbbOkdC0AkFIFSDHfWyoWAwp3Ihs9JrJEk5 uMxZgvFB0hC3i6AHrRALcKvsTP7lyu/fGXaOI6AraL784re84072tSNUpYoyt7VBOrIP kBQtlBSV8FH/1X8aSpxRDMQaXj/aV4BZE9YaqDVS8hepIWFOdKDWpJqv+DNvINsxYgcX r+LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=57OGVqd2vPNy10zz28LFXN3FQP+tTv9yzKd78YLuUXU=; b=K0xf7HfEWSofU7lbtxs3X/jlMddDp2t/9cSv8gIGyN8dt2WM4Tj//EnHUqNLbhT4an UbC7yyy0DFGkelluQ1ep1ZbyU1XxC8ZqaQGUnDcQMpzftzyHa5Ir4kUKdKUTRghV4lVM 7pRQuOuSsU/FPzprTC5GIXi6ZzwuZPkzqDlDvByRytj522Ul6x8+j9vwfe+WtLwcb53o k5EX046zHRBxsDCQ7Xs+kOs74ilFm4wVJLo5/z51xkhZIhLtKOjKRfydpcdGX2Wq58Au xDiwrbdUwp8ziBCGucccywxW1CorlQuhvQKrXrhxaJOghIyQRt5qNws3bLzw25Ntwn/m +k9g== X-Gm-Message-State: AGRZ1gLohpQgTwapQJRBjaiiOCtrHidnLJkLJxJcXrT+nKxAV3QC/Mbg 5JG7VWJ3wOWQYQ6M5+9ZO7eyC/mWcCew6dsd+tY90w== X-Google-Smtp-Source: AJdET5fa4HDz1yRBCNmtkGIWvVOCePuug4F7m52UjSOX2q227xhD53yf25D+RcilTCOxSJpAFVDwUyCCaIm31Rs46kA= X-Received: by 2002:a24:738f:: with SMTP id y137mr7872577itb.136.1542652503916; Mon, 19 Nov 2018 10:35:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Mon, 19 Nov 2018 10:34:51 -0800 Message-ID: To: Roman Shpount Cc: RTCWeb IETF , mmusic@ietf.org Content-Type: multipart/alternative; boundary="000000000000826c7b057b08c6fd" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 18:35:10 -0000 --000000000000826c7b057b08c6fd Content-Type: text/plain; charset="UTF-8" IIRC, one reason JSEP chose the behavior described is because 5245-compliant implementations would declare an ICE mismatch if we used a bogus address/port in the c=/m= lines. Is this not a problem? On Mon, Nov 19, 2018 at 10:28 AM Roman Shpount wrote: > Hi All, > > The current language in JSEP makes it incompatible with any ICE > implementation, either existing or the future ones compliant with > ice-sip-sdp draft. You can, of course, overwrite ice-sip-sdp, but this will > mean JSEP will be a completely incompatible system.. > > The problem is that JSEP proposes to use UDP protocol in the m= line and > at the same time update address and port to the currently selected > candidate. Based on ice-sip-sdp, if protocol of the current selected > candidate does not match protocol in the m= line, this will mean either ICE > mismatch or additional candidate with protocol, address, and port form m= > and c= line. > > Second, ice-sip-sdp treats SDP during ICE restart, when multiple > candidates are present different from SDP when ICE is not restarted (single > candidate). According to ice-sip-sdp, when only a single candidate is > present, this candidate protocol, address and port are set in m= and c= > line. JSEP proposes to put original UDP protocol and address and port from > the single candidate. > > To be specific, it is not the fact that protocol in m= line is not updated > is an issue. It is that protocol in not updated but address and port in m= > and c= line are updated. In the ice-sip-sdp draft there is a solution for > this issue -- set address to IN IP4 0.0.0.0 and port to 9. This is > specifically supposed to be ignored and not cause the ICE mismatch or extra > candidates. If JSEP wants to overwrite ice-sip-sdp, it can specify that m- > line protocol should always be set to UDP based protocol, c= line address > should be set to IN IP4 0.0.0.0 and m= line port set to 9. In case of an > ICE only system where c= and m= line address information is irrelevant, > this makes implementation simpler since m= and c= line address information > can stay constant for the duration of the session. > > Regards, > _____________ > Roman Shpount > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --000000000000826c7b057b08c6fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IIRC, one reason JSEP chose the behavior described is beca= use 5245-compliant implementations would declare an ICE mismatch if we used= a bogus address/port in the c=3D/m=3D lines. Is this not a problem?
<= br>
On Mon, Nov 19, 2018 at 10:2= 8 AM Roman Shpount <roman@telurix.c= om> wrote:
= Hi All,

The current language in JSEP makes it incompatib= le with any ICE implementation, either existing or the future ones complian= t with ice-sip-sdp draft. You can, of course, overwrite ice-sip-sdp, but th= is will mean JSEP will be a completely incompatible system..

=
The problem is that JSEP proposes to use UDP protocol in the m= =3D line and at the same time update address and port to the currently sele= cted candidate. Based on ice-sip-sdp, if protocol of the current selected c= andidate does not match protocol in the m=3D line, this will mean either IC= E mismatch or additional candidate with protocol, address, and port form m= =3D and c=3D line.

Second, ice-sip-sdp treats SDP = during ICE restart, when multiple candidates are present different from SDP= when ICE is not restarted (single candidate). According to ice-sip-sdp, wh= en only a single candidate is present, this candidate protocol, address and= port are set in m=3D and c=3D line. JSEP proposes to put original UDP prot= ocol and address and port from the single candidate.

To be specific, it is not the fact that protocol in m=3D line is not upd= ated is an issue. It is that protocol in not updated but address and port i= n m=3D and c=3D line are updated. In the ice-sip-sdp draft there is a solut= ion for this issue -- set address to IN IP4 0.0.0.0 and port to 9. This is = specifically supposed to be ignored and not cause the ICE mismatch or extra= candidates. If JSEP wants to overwrite ice-sip-sdp, it can specify that m-= line protocol should always be set to UDP based protocol, c=3D line addres= s should be set to=C2=A0 =C2=A0IN IP4 0.0.0.0 and m=3D line port set to 9. In case of an ICE only sy= stem where c=3D and m=3D line address information is irrelevant, this makes= implementation simpler since m=3D and c=3D line address information can st= ay constant for the duration of the session.

Regar= ds,
_____________
Roman S= hpount
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--000000000000826c7b057b08c6fd-- From nobody Mon Nov 19 11:31:09 2018 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 BF4051292F1 for ; Mon, 19 Nov 2018 11:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChMaammINEz7 for ; Mon, 19 Nov 2018 11:31:00 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 3F08D130DED for ; Mon, 19 Nov 2018 11:30:59 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id a14so10445313plm.12 for ; Mon, 19 Nov 2018 11:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pLdIaVyIJHM79C49feJxjYKe6UnBUKcZOx2JZFif84Y=; b=DjSm4nRXEfEBf6/tK4UABoI2osCPhWc7XJkcHpcIKh44QwRww+MjG8uHjwA14U7KeB 90ErHlMKEaKJavgG4Lydh3PjkC8ON69D3fANrPpeMc+HUimJAtn0xVwtUuBh7g84x1V5 PLOrv9ChC4BWGTqs17Ldahlyi99lq6S88h9XNGbTm0YkYlv25QPiYWssYL5uvV5IkCtr tep/p3F1efou8xAIiUlabEBnt3hcOwJf3DqaxttKeEGr93ksnz3O2VtvgtHAm5fuxfRe PC63I4eKBbeFFTtvjfDtRzZucgsY0cKp94aAPmongFAgTQuA1zqYepeUS7X3U6id1DKS GlMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pLdIaVyIJHM79C49feJxjYKe6UnBUKcZOx2JZFif84Y=; b=KEl1nLQVWLOkWPCxtyyKVDLUNM1e2pfLmA4hXtftmCWvihFmxJIYFXOVVBM/sspDJq iXABCljwmI/+zib1NWc0EQFk2ABIqH8rtt8+YtQOZn4cu0txMy6lUzhqSa0PP8/EmCVT psLQkUS0B3fJlw/UxX2EG7AEJu4b+znaQvqTYzwg2jfbQEO8RKa4yDuv7nPR2XwpgY/0 AljbZkJfnvHNngVVIamSCexG/xrY479Ve9tYTT4NVNApRoN68HEeqplPWWracrdEy82q OpEo+WNLlM/iZ5CBzxL4ObDonOwqY7sPlTToE0lbv4q2zJEhmnZKhoTOZzofBbpUAsUz JXuQ== X-Gm-Message-State: AGRZ1gL7k/UbhYut1brRaIVI1W1ZAz3UHoln1X2TcBLIRDFo5YeHI1xj L11z0aq1o3mqqh4upUs004x2El5yt98= X-Google-Smtp-Source: AJdET5eOGbmMVFF1dJB9npxmjz5lnj8NjbqMS8xbphoh8ghWA/sDXtj5swqKq2DMkQH+KzSuuHHU4w== X-Received: by 2002:a17:902:868b:: with SMTP id g11-v6mr20696429plo.96.1542655858579; Mon, 19 Nov 2018 11:30:58 -0800 (PST) Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com. [209.85.210.176]) by smtp.gmail.com with ESMTPSA id b2sm55729977pfm.3.2018.11.19.11.30.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 11:30:57 -0800 (PST) Received: by mail-pf1-f176.google.com with SMTP id 64so10849325pfr.9; Mon, 19 Nov 2018 11:30:57 -0800 (PST) X-Received: by 2002:a62:1b50:: with SMTP id b77mr24339172pfb.36.1542655857615; Mon, 19 Nov 2018 11:30:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 19 Nov 2018 14:30:52 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="000000000000676ab2057b098ec5" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 19:31:03 -0000 --000000000000676ab2057b098ec5 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 19, 2018 at 1:35 PM Justin Uberti wrote: > IIRC, one reason JSEP chose the behavior described is because > 5245-compliant implementations would declare an ICE mismatch if we used a > bogus address/port in the c=/m= lines. Is this not a problem? > RFC 5245 compatibility is a problem, but I assume we were past this point and was trying to propose something that at least is going to be compatible with ice-sip-sdp. BTW, Edge browser with RTCPeerConnection-shim is already putting 0.0.0.0 and port 9 in all session descriptions: v=0 o=thisisadapterortc 3331475186201587 0 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE mzxjdusv69 a=ice-options:trickle m=audio 9 UDP/TLS/RTP/SAVPF 104 102 0 8 103 97 13 118 101 c=IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0 (codec parameters removed for clarity) a=maxptime:100 a=rtcp-mux a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:3 http://skype.com/experiments/rtp-hdrext/fast_bandwidth_feedback#version_2 a=ice-ufrag:x+3s a=ice-pwd:Re8NpJqQfXVtpbOg7oBgmoHL a=setup:actpass a=fingerprint:sha-256 14:B5:2D:3D:0E:CE:E9:F1:F7:E3:56:A6:55:DD:23:BD:1A:65:F0:FE:64:B5:78:30:FA:64:06:9B:F0:8B:D2:3D a=mid:mzxjdusv69 a=sendrecv a=msid:6E374666-5BBB-43E9-B1C2-89312C920723 BD9F838A-5483-42E5-99A7-A861999D5C0A a=ssrc:1001 msid:6E374666-5BBB-43E9-B1C2-89312C920723 BD9F838A-5483-42E5-99A7-A861999D5C0A a=ssrc:1001 cname:m4gynh3dc1 a=rtcp-rsize a=candidate:1 1 UDP 2130706431 172.129.12.1 63862 typ host ufrag x+3s a=candidate:2 1 UDP 2130705919 10.7.18.135 55458 typ host ufrag x+3s a=candidate:3 1 TCP 1684798463 172.129.12.1 63862 typ srflx raddr 172.29.182.1 rport 63862 tcptype active ufrag x+3s a=end-of-candidates If RFC 5245 compatibility is required, it means offer/answer exchange with no trickle, session refresh after nomination completion, and using default candidate protocol, address and port in c= and m= line. No trickle and session refresh can be achieved through existing API. Setting protocol, address, and port in c= and m= line is harder and will require SDP mangling. When ICE-SIP-SDP and related protocols were discussed in mmusic, in order to be RFC 5245 compatible, the plan was to: 1. Use protocol, address, and port of the default candidate in c= and m= lines 2. In order to avoid protocol mismatch during offer/answer, require in specific protocol specifications, such as sctp-sdp, that end points should implement UDP based transport and use it as default transport during ICE restart in both offer and answer 3. In subsequent offers, where only a single candidate is present, use protocol, address and port of this candidate in c= and m= lines This means the same protocol should always be used for the specific m= line during offer/answer, but it can change between offer/answer exchanges. For instance, m= line which was UDP/DTLS/SCTP during the initial exchange, can become TCP/DTLS/SCTP in subsequent exchange, and then change back to UDP/DTLS/SCTP when ICE restart is initiated. It was assumed that it should not be a problem but JSEP is currently trying to overwrite this. I understand this is ugly, but this was the only thing we came up with to keep things compatible with existing implementations. Regards, _____________ Roman Shpount --000000000000676ab2057b098ec5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 19, 2018 at 1:35 PM Justin Uberti = <juberti@google.= com> wrote:
IIRC, one reason JSEP = chose the behavior described is because 5245-compliant implementations woul= d declare an ICE mismatch if we used a bogus address/port in the c=3D/m=3D = lines. Is this not a problem?
=C2=A0
RFC 5= 245 compatibility is a problem, but I assume we were past this point and wa= s trying to propose something that at least is going to be compatible with = ice-sip-sdp. BTW, Edge browser with RTCPeerConnection-shim is already putti= ng 0.0.0.0 and port 9 in all session descriptions:

v=3D0 o=3Dthisisadapterortc 3331475186201587 0 IN IP4 127.0.0.1 s=3D- t=3D0 0 a=3Dgroup:BUNDLE mzxjdusv69 a=3Dice-options:trickle m=3Daudio 9 UDP/TLS/RTP/SAVPF 104 102 0 8 103 97 13 118 101 c=3DIN IP4 0.0.0.0 a=3Drtcp:9 IN IP4 0.0.0.0 (codec parameters removed for clarity)
a=3Dmaxptime:100 a=3Drtcp-mux a=3Dextmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=3Dextmap:3 http://skype.com/experiments/rtp-hdrext/fast_bandw= idth_feedback#version_2 a=3Dice-ufrag:x+3s a=3Dice-pwd:Re8NpJqQfXVtpbOg7oBgmoHL a=3Dsetup:actpass a=3Dfingerprint:sha-256 14:B5:2D:3D:0E:CE:E9:F1:F7:E3:56:A6:55:DD:23:BD= :1A:65:F0:FE:64:B5:78:30:FA:64:06:9B:F0:8B:D2:3D a=3Dmid:mzxjdusv69 a=3Dsendrecv a=3Dmsid:6E374666-5BBB-43E9-B1C2-89312C920723 BD9F838A-5483-42E5-99A7-A8619= 99D5C0A a=3Dssrc:1001 msid:6E374666-5BBB-43E9-B1C2-89312C920723 BD9F838A-5483-42E5-= 99A7-A861999D5C0A a=3Dssrc:1001 cname:m4gynh3dc1 a=3Drtcp-rsize a=3Dcandidate:1 1 UDP 2130706431 172.129.12.1 63862 typ host ufrag x+3s a=3Dcandidate:2 1 UDP 2130705919 10.7.18.135 55458 typ host ufrag x+3s a=3Dcandidate:3 1 TCP 1684798463 172.129.12.1 63862 typ srflx raddr 172.29.= 182.1 rport 63862 tcptype active ufrag x+3s a=3Dend-of-candidates

If RFC 5245 compatibility is required, it mea= ns offer/answer exchange with no trickle, session refresh after nomination = completion, and using default candidate protocol, address and port in c=3D = and m=3D line. No trickle and session refresh can be achieved through exist= ing API. Setting protocol, address, and port in c=3D and m=3D line is harde= r and will require SDP mangling.

When ICE-SIP-SDP = and related protocols were discussed in mmusic, in order to be RFC 5245 com= patible, the plan was to:
1. Use protocol, address, and port of t= he default candidate in c=3D and m=3D lines
2. In order to avoid = protocol mismatch during offer/answer, require in specific protocol specifi= cations, such as sctp-sdp, that end points should implement UDP based trans= port and use it as default transport during ICE restart in both offer and a= nswer
3. In subsequent offers, where only a single candidate is p= resent, use protocol, address and port of this candidate in c=3D and m=3D l= ines

This means the same protocol should always be= used for the specific m=3D line during offer/answer, but it can change bet= ween offer/answer exchanges. For instance, m=3D line which was UDP/DTLS/SCT= P during the initial exchange, can become TCP/DTLS/SCTP in subsequent excha= nge, and then change back to UDP/DTLS/SCTP when ICE restart is initiated. I= t was assumed that it should not be a problem but JSEP is currently trying = to overwrite this. I understand this is ugly, but this was the only thing w= e came up with to keep things compatible with existing implementations.

Regards,
_____________
Roman Shpount
=C2= =A0
--000000000000676ab2057b098ec5-- From nobody Mon Nov 19 11:36:40 2018 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 1EE171292F1 for ; Mon, 19 Nov 2018 11:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LF1ZvfVRq0UZ for ; Mon, 19 Nov 2018 11:36:31 -0800 (PST) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 4F1C712F1AB for ; Mon, 19 Nov 2018 11:36:31 -0800 (PST) Received: by mail-vs1-xe35.google.com with SMTP id h18so18484514vsj.4 for ; Mon, 19 Nov 2018 11:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Uud4FYV7B57nMs0K+lQDk+D8q0YNHSFxzU5tyWD66Ww=; b=N0AWUGBd+iCsg4rc+Jx8tdTp2B0DegVfVLSweaOH7XaeLJ4mcM73QGJqKN/eZnIFsi Lp5V7roqYMLpSf52jDsWa3ot441pI8mCw36W7BgYiHDmgX+QxBblhh2wM6bfzhvh/kxd vaGUdU3Vf9/RKFZmOxOySbjav4F7gClgRHxFfPPNhhiCE81HuOYBQMG7NeBnvJTfrL0R zeymzAqUz3ArQsXgZV/I2DW7khyujfcvApe9zk2rATFKlM3eUadO3qzffSROLMwZEpFO SBsq5XN94p7U1ENg5Wi6qOhjLKx3t8SLQ4rUjm6miaA+RL/kGWoEl4EgpcF/j73vu2To PRQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Uud4FYV7B57nMs0K+lQDk+D8q0YNHSFxzU5tyWD66Ww=; b=EibC7r1ebKdb0zENI4FzRuN+r2kncY2sqYrUEF7Ed66F83HUb7k66+JSQsMvY2c42A nuW5OUmjQY2x0ub9DIT+9Dc4EdVG3gN0O6wwLEHndpCYXahAnECUeTDvzY88aAENZCmk 6wj24eMAdnXlNRRMA4uBdcUO1DNEqJkSefxrFcyjbRNs7sFgvcSD9fiER7sBiwcsKqtY ZzBToTIxILV6YuJxEzjpySlNf1p7R3Kd/YHWnGyHmtA2T8diZCqPg+kcjvjmMc9AHJ7n drmebqMXZ21hmFNIE4RMGSgLmehmdgGLtVwULSOs4EWa5fcKyHzambVo1LSvVb+AUR3s i1kA== X-Gm-Message-State: AGRZ1gKi8/H2h50cKKI22lLNAh048N2PKH67b89kY7bKgAEhZZFFLh+S nfqLI1ZdLTGojOvTeW+GmE9IQ+DBa5L/IQ0RXKuzw3aptXQ= X-Google-Smtp-Source: AJdET5eZjXK9rG9rzsUrJD4EcqbRr8+h9+UFZHrw4I/05qQDzN13kzr97rVEqNmfLP16W1ZWXmXl7lRqL07Z5gpCZ8I= X-Received: by 2002:a67:3659:: with SMTP id d86mr9907547vsa.17.1542656190209; Mon, 19 Nov 2018 11:36:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 19 Nov 2018 20:36:18 +0100 Message-ID: To: Roman Shpount Cc: rtcweb@ietf.org, mmusic@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 19:36:34 -0000 On Mon, 19 Nov 2018 at 19:28, Roman Shpount wrote: > The problem is that JSEP proposes to use UDP protocol in the m=3D line an= d at the same time update address and port to the currently selected candid= ate. Based on ice-sip-sdp, if protocol of the current selected candidate do= es not match protocol in the m=3D line, this will mean either ICE mismatch = or additional candidate with protocol, address, and port form m=3D and c=3D= line. We could just assume that no WebRTC capable endpoint will (absolutely never) rely on the content of the c=3D line or the proto indicated in the m=3D line (no matter it indicates "CHICKEN" as proto). --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 19 11:49:24 2018 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 ED2DE130DE2 for ; Mon, 19 Nov 2018 11:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 mXP23wyrzR4G for ; Mon, 19 Nov 2018 11:49:19 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (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 694C4126CC7 for ; Mon, 19 Nov 2018 11:49:19 -0800 (PST) Received: (qmail 12440 invoked from network); 19 Nov 2018 19:49:17 -0000 X-APM-Authkey: 255286/0(159927/0) 2047 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 19 Nov 2018 19:49:17 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 8DA1118A0D29; Mon, 19 Nov 2018 19:49:17 +0000 (GMT) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id khjFWZliEoTX; Mon, 19 Nov 2018 19:49:17 +0000 (GMT) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 5843718A06BA; Mon, 19 Nov 2018 19:49:17 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: T H Panton In-Reply-To: Date: Mon, 19 Nov 2018 19:49:16 +0000 Cc: Roman Shpount , rtcweb@ietf.org, mmusic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2C5B190C-21F3-4E93-9D50-691C1D8A65EA@westhawk.co.uk> References: To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 19:49:22 -0000 > On 19 Nov 2018, at 19:36, I=C3=B1aki Baz Castillo = wrote: >=20 > On Mon, 19 Nov 2018 at 19:28, Roman Shpount wrote: >> The problem is that JSEP proposes to use UDP protocol in the m=3D = line and at the same time update address and port to the currently = selected candidate. Based on ice-sip-sdp, if protocol of the current = selected candidate does not match protocol in the m=3D line, this will = mean either ICE mismatch or additional candidate with protocol, address, = and port form m=3D and c=3D line. >=20 > We could just assume that no WebRTC capable endpoint will (absolutely > never) rely on the content of the c=3D line or the proto indicated in > the m=3D line (no matter it indicates "CHICKEN" as proto). or QUIC ? From nobody Mon Nov 19 12:02:32 2018 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 790A21292F1 for ; Mon, 19 Nov 2018 12:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JU0mDV1gvacw for ; Mon, 19 Nov 2018 12:02:24 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 F0C47130DE2 for ; Mon, 19 Nov 2018 12:02:20 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id b5-v6so15089349pla.6 for ; Mon, 19 Nov 2018 12:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6v77w3tGrBVBALZz/62k4WNzrMIgOOSzq9vPDj1ovaE=; b=XqYH46Lz0A3isDrjLoPPipz4D5J9vyaZq4cATisI1VMtfz4/UsCm+rUZR6DDp+CWGg 1w7/sKv+Sbu+mklVRxW2azCTn6AWOXlLeCVkv6vwSKhaMZqcLCW82dlnqEIeNwfYMjW2 PvwouUQL8vJhfOgp0uDiZut9OB1pKjuhBsnEcLfGdaCjVO3EAOx7SqRaFANt6/ItR7VM wmPrHRURgV6dPo40KYJ/nrJ/cjWWvgY+Z7G8cCEU6kXcr8PbugUi+5AKX0hG5gRyRzR4 5WBjbStT2DXUVMgp0ZgUaeHgcpZIjk4c6PhuaC7cf7khTORhxW7KU3XaI0lxFfw8lGhG kzAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6v77w3tGrBVBALZz/62k4WNzrMIgOOSzq9vPDj1ovaE=; b=iwk1praK/UxPvkhmQz15KtpWEz6S4Tej+JdZY7if8wATOkcnHG8v62XFNyR5NeDnzX ejKvda1J6jeEdXZKUjy+9Ny9nvfyO1h84uLeMoZmGur/P14nE99+DRSJBmLmM9iVK1L1 No0JZWj7gTHqnmouR41S36Nug+Ayxuv/o9aPKcfX4ZyUsiUIsd8Xrt8R4tSAMIHw4Xiy JnB9N3WkaFWlLy3xTSgAar+WEr8SPjOPooHcYFP7oALBgNdeOomtjqICN48woZ25FDa4 2lRTbs7JMaUwspyuehgOL5EA8n4al2eAIzC5x0KAUazi8F/Mze6H4P4rf2FAsUFhjN/Q DoMQ== X-Gm-Message-State: AGRZ1gKf0lYAOzoFqH2XCZqXogQc2moVNRu79Nk6X10fXcATQx/Yk7ho WjJo9kDFRlkwx3IZrb//Hf9xC1/Qp6o= X-Google-Smtp-Source: AJdET5fKKuCM5NkCYYSTg/JWm407BOO1OYeeNuFzJUJlFbthxUpAV/OTFDl3ngslwhMZJrUiw/RTJg== X-Received: by 2002:a17:902:ba89:: with SMTP id k9mr18539756pls.189.1542657740372; Mon, 19 Nov 2018 12:02:20 -0800 (PST) Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com. [209.85.215.176]) by smtp.gmail.com with ESMTPSA id s2-v6sm87553572pfk.133.2018.11.19.12.02.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 12:02:20 -0800 (PST) Received: by mail-pg1-f176.google.com with SMTP id y4so14291109pgc.12; Mon, 19 Nov 2018 12:02:19 -0800 (PST) X-Received: by 2002:a63:5357:: with SMTP id t23-v6mr21730266pgl.40.1542657739254; Mon, 19 Nov 2018 12:02:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 19 Nov 2018 15:02:08 -0500 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="0000000000008ef335057b09fe19" Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 20:02:25 -0000 --0000000000008ef335057b09fe19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 19, 2018 at 2:36 PM I=C3=B1aki Baz Castillo wro= te: > On Mon, 19 Nov 2018 at 19:28, Roman Shpount wrote: > > The problem is that JSEP proposes to use UDP protocol in the m=3D line = and > at the same time update address and port to the currently selected > candidate. Based on ice-sip-sdp, if protocol of the current selected > candidate does not match protocol in the m=3D line, this will mean either= ICE > mismatch or additional candidate with protocol, address, and port form m= =3D > and c=3D line. > > We could just assume that no WebRTC capable endpoint will (absolutely > never) rely on the content of the c=3D line or the proto indicated in > the m=3D line (no matter it indicates "CHICKEN" as proto). > This is incorrect. Only the transport part of the proto line does not matter since it is overwritten by the ICE candidate. The rest of the proto is needed to know if this m=3D line is audio, video, or data channel. In any case, this is about interop with existing (and already WebRTC compatible) implementations. At this point, I would be happy, if either c= =3D and m=3D line were populated by some constant data or modified based on rul= es which serve some purpose like legacy interop. I would actually greatly prefer former, but if someone still cares about RFC 5245 interop will be fine with the later. Right now JSEP requires to change the c=3D and m=3D li= ne but does not achieve the interop. Regards, _____________ Roman Shpount --0000000000008ef335057b09fe19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 19, 2018 at 2:36 PM I=C3=B1aki Baz Cas= tillo <ibc@aliax.net> wrote:
=
On Mo= n, 19 Nov 2018 at 19:28, Roman Shpount <roman@telurix.com> wrote:
> The problem is that JSEP proposes to use UDP protocol in the m=3D line= and at the same time update address and port to the currently selected can= didate. Based on ice-sip-sdp, if protocol of the current selected candidate= does not match protocol in the m=3D line, this will mean either ICE mismat= ch or additional candidate with protocol, address, and port form m=3D and c= =3D line.

We could just assume that no WebRTC capable endpoint will (absolutely
never) rely on the content of the c=3D line or the proto indicated in
the m=3D line (no matter it indicates "CHICKEN" as proto).

This is incorrect. Only the transport part of= the proto line does not matter since it is overwritten by the ICE candidat= e. The rest of the proto is needed to know if this m=3D line is audio, vide= o, or data channel.=C2=A0

In any case, this is abo= ut interop with existing (and already WebRTC compatible) implementations. A= t this point, I would be happy, if either c=3D and m=3D line were populated= by some constant data or modified based on rules which serve some purpose = like legacy interop. I would actually greatly prefer former, but if someone= still cares about RFC 5245 interop will be fine with the later. Right now = JSEP requires to change the c=3D and m=3D line but does not achieve the int= erop.

Regards,
_____________
Roman Shpount=
=C2=A0
--0000000000008ef335057b09fe19-- From nobody Mon Nov 19 12:09:06 2018 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 E39C8130DE2 for ; Mon, 19 Nov 2018 12:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7w8EJTtBl92 for ; Mon, 19 Nov 2018 12:09:03 -0800 (PST) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 32FC01292F1 for ; Mon, 19 Nov 2018 12:09:03 -0800 (PST) Received: by mail-vs1-xe2b.google.com with SMTP id e7so18552545vsc.2 for ; Mon, 19 Nov 2018 12:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1hLCtoimb8ovhqCv6C0c8u1SNyWBh72D7RHqtj/keTQ=; b=enL9vXPDMlaxemIbKQG69jELKJNV3SKqqy++5tWEY52KjAQNbKfTLYIstK0NgSpP8l 7wF2IFMVlCV/rQHZ1G3Ke+nWrHmoh3xvhNscAmlOTGzpBKKIF8fEQv+833hCq6JJqybq Zd3FihYyqgYi4DufdQPfppyjXaw0bzxmcMtMv8cM27QxBG1bMYSpOIEVO06J0dYYudSl HP074YyhMRIFcqvNevT/an0TeM3VEXIQ6gyV2z3Q7KBDO/FhvrptU64iJ0ajA0z48NP6 gNp95MNOQTxkKiClzuDF/beonMgPgIQERwY1Y9752R9YuACuEEgyy4R4I8dC2rrykMCQ K9sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1hLCtoimb8ovhqCv6C0c8u1SNyWBh72D7RHqtj/keTQ=; b=g/DYmwtV6iW2sEgy3IlHbwtGP2gnJCpmAYnXrtYCavvwBBAbljpxGTig+qICK1fr+s NFyigAZE7NW7J8H/NoiAIkc6IiVYimVfaJQwuVQrSdqg6ddrUMkSEy31uBQ53yUw4WnR XRRKauJPWW8oods6OjAMFWpAVXPpfshZZogFce8O6B1ZK3xr8tzKhtykf6pttXwQaQPO WAzuDjb2xONhD2XopdSgjeqfXjca0Jl1qOcqv5EMSUX89sXT6ytrw4M3gTAxU4d1K8Dv ZlnrtSBh3MG7VVh++nXXxAzwxxPwRvbWY5yKR/kB59SsC7zu/VApvP/+XXB7eniULlVc oPtA== X-Gm-Message-State: AGRZ1gKVIaoflGrEiHjJIjz2jI+Bpokw87rR7uAmLDoRAhofTShs9Q8d XmqWxMK+IDqJHzUlz3A7hy9rCaMKM3Nne06lveBb2A== X-Google-Smtp-Source: AJdET5co2YONHmuymQOYfUtFJzXvQ1X+xvBzOCSOiAfX9bNh/iW2/f63oCiHnAr6taBc4G9LnzOEyQs6g+Zi2yXkDdk= X-Received: by 2002:a67:7106:: with SMTP id m6mr9669607vsc.67.1542658141919; Mon, 19 Nov 2018 12:09:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 19 Nov 2018 21:08:50 +0100 Message-ID: To: Roman Shpount Cc: rtcweb@ietf.org, mmusic@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 20:09:05 -0000 On Mon, 19 Nov 2018 at 21:02, Roman Shpount wrote: > > On Mon, Nov 19, 2018 at 2:36 PM I=C3=B1aki Baz Castillo w= rote: >> We could just assume that no WebRTC capable endpoint will (absolutely >> never) rely on the content of the c=3D line or the proto indicated in >> the m=3D line (no matter it indicates "CHICKEN" as proto). > > This is incorrect. Only the transport part of the proto line does not mat= ter since it is overwritten by the ICE candidate. The rest of the proto is = needed to know if this m=3D line is audio, video, or data channel. Yes, I just meant the "proto" component. > In any case, this is about interop with existing (and already WebRTC comp= atible) implementations. At this point, I would be happy, if either c=3D an= d m=3D line were populated by some constant data If it's an already WebRTC compatible device, then it does not need to read the IP in c=3D nor the proto in m=3D. > or modified based on rules which serve some purpose like legacy interop. Which interop? If a peer is WebRTC compatible then it MUST use ICE, so whatever is written in the c=3D line and whatever the m=3D protoo is, it won't need to read it. And if the other party is "legacy" and does not implement WebRTC, then they both just can not communicate. So this is just cosmetic and has zero value. And there are endless discussions about this topic for the last 3-4 years just because those fields exist in the SDP. --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 19 12:21:15 2018 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 21309124D68 for ; Mon, 19 Nov 2018 12:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pS_hbBk6pUIU for ; Mon, 19 Nov 2018 12:21:08 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 84A9B1292F1 for ; Mon, 19 Nov 2018 12:21:05 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id u3-v6so12704603pfm.4 for ; Mon, 19 Nov 2018 12:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i55mqN5/aXsnLL+srsQG9GYjondiOH4zeCN+3x8PPk8=; b=v6fyP1gRxXg5gTAVSdyOyThAUmrXndFq+RrgVY9v2PGIKingnFS9K5uUOTDgviyZc8 Jgp4P1mck3EwMs/ueUvP9Bkriuiwcmz9+3xbW2mF7C7oUsIGgv4f/Y+b5jDgeRRZgzzJ bXIWf4K50Z1PIyV9u9ACv0YYsD55f7/M5oCBJtFh2G1aH7wWNbgqgWRtE1+mJmQZlSyO nygu6ObkebTtSwsfxjJXisgYoAd35ywhCtLFT3pcXzi4ZzFqOpxdE+8IsG1iu71glYaD AtKMRiYAJHnipw3+PrRyX+d5JeekgnAxevP4yFRNwU4l9py3vxVUoolaX5lpn4irQJIX Gu2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i55mqN5/aXsnLL+srsQG9GYjondiOH4zeCN+3x8PPk8=; b=gSiK/39XWYuZR/AdjjGN2yP6e0FrkEyqa1010XG3ibLxdgxbKjW5ktCgH9KUzm8k3R pOZ/vssM9x6RNIun7Tcs0iFDSC+FoClz5Qcggq9m0XhHxErK668Y8X4Oz5TV5+x+4FGE HUUOcm3Sa9kOA87LJTyVZDHLu3pYLvRNQQ9rZuG27tnzrik35ivT3TjT7yuipE1FjfGg nGhf+zsCZo0CSOMqxd0hiZGAfiL2tVAdWHr6scq8lmmPdOML6b4Cy50ep3JMZdidwuWD JqUvVpEePOTfMgamqov1E2dDhSccWGACKQkTfL1cEb47v4GOYX7z4o+viCYwi/6J1oQ/ doCA== X-Gm-Message-State: AGRZ1gIInuD4kueq8MyJiu6oAORkjfWAG5vaHuwbk609BnK/jF5HaYoW VpXS/EwXwSUGLXlAMc4mThNpbwsbf6A= X-Google-Smtp-Source: AJdET5fvfZktVnnKq1cXmEbWQaikSe2N/rKbPEZtXql9+opjoAvokxJwgWjr4a/dRWVK3Uor72TPIw== X-Received: by 2002:a62:6085:: with SMTP id u127-v6mr22607457pfb.147.1542658864980; Mon, 19 Nov 2018 12:21:04 -0800 (PST) Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com. [209.85.210.182]) by smtp.gmail.com with ESMTPSA id j185sm16004295pge.72.2018.11.19.12.21.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 12:21:04 -0800 (PST) Received: by mail-pf1-f182.google.com with SMTP id 64so10907581pfr.9; Mon, 19 Nov 2018 12:21:04 -0800 (PST) X-Received: by 2002:a62:9f42:: with SMTP id g63-v6mr24249345pfe.144.1542658863884; Mon, 19 Nov 2018 12:21:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 19 Nov 2018 15:20:53 -0500 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="000000000000977085057b0a4191" Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 20:21:10 -0000 --000000000000977085057b0a4191 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 19, 2018 at 3:09 PM I=C3=B1aki Baz Castillo wro= te: > Which interop? If a peer is WebRTC compatible then it MUST use ICE, so > whatever is written in the c=3D line and whatever the m=3D protoo is, it > won't need to read it. And if the other party is "legacy" and does not > implement WebRTC, then they both just can not communicate. > > So this is just cosmetic and has zero value. And there are endless > discussions about this topic for the last 3-4 years just because those > fields exist in the SDP. > > ICE specifications (both RFC 5245 and ice-sip-sdp) are saying that these fields are not cosmetic. All I am asking is to put values in these fields that indicate that they are cosmetic instead of creating some rules on how these fields should change which would cause potential interop issues. BTW, there are plenty of VoIP phones which use ICE and support Opus (or G.711). They will also produce ICE mismatch since they implement RFC 5245. So, these end points are WebRTC compatible except for this specific issue. Regards, _____________ Roman Shpount --000000000000977085057b0a4191 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 19, 2018 at 3:09 PM I=C3=B1aki Baz Cas= tillo <ibc@aliax.net> wrote:
=
Which= interop? If a peer is WebRTC compatible then it MUST use ICE, so
whatever is written in the c=3D line and whatever the m=3D protoo is, it won't need to read it. And if the other party is "legacy" and= does not
implement WebRTC, then they both just can not communicate.

So this is just cosmetic and has zero value. And there are endless
discussions about this topic for the last 3-4 years just because those
fields exist in the SDP.

ICE specifications (both = RFC 5245 and ice-sip-sdp) are saying that these fields are not cosmetic. Al= l I am asking is to put values in these fields that indicate that they are = cosmetic instead of creating some rules on how these fields should change w= hich would cause potential interop issues.

BTW, th= ere are plenty of VoIP phones which use ICE and support Opus (or G.711). Th= ey will also produce ICE mismatch since they implement RFC 5245. So, these = end points are WebRTC compatible except for this specific issue.
=
Regards,
_____________
Roman Shpount
=C2=A0
--000000000000977085057b0a4191-- From nobody Mon Nov 19 12:31:41 2018 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 BBD4B126DBF for ; Mon, 19 Nov 2018 12:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVQ-GlT_jDU1 for ; Mon, 19 Nov 2018 12:31:28 -0800 (PST) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 6C3AB130DDB for ; Mon, 19 Nov 2018 12:31:26 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id p74so18615659vsc.0 for ; Mon, 19 Nov 2018 12:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oNXU85uPzVbJAyLn5tqksM4AmfLLeUdlhUN9wxooodM=; b=D5B5fDX9xuAPg4PmBbaynWwbEfnCuk9NfyGH913VpLGEhjLZZja+BxmfAGwB3mY9q0 Xd6X0eAZ2/5tC1Ce2kynZW+CgOZKzmJ9lFpM0cVKZ+FWn4zqIVli7LhnNSRXcbxKwryo hqh8GE04qgn1tYryaNuyJ+UncsRj407duL75Pps28dKvIw7AER5nmXXJhJA0cXVx3Rp6 wCois63kOrN5xaUQQHn+miLh4UsyxGBYfFNhKOnDxbbQfqtHTkwNTRNKXRJ8lYeq/3Pw WGvxGqgjnPxIlut0Hm2Q9Lu01AEjewGeLFsOLNo8Eq/2s3I0kBUr5xSSKRhu/+38pg12 UNlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oNXU85uPzVbJAyLn5tqksM4AmfLLeUdlhUN9wxooodM=; b=Mx0ddbNidv/a322k48lYo2fE4Qb7eYZZ5KXbW0v7zAKcenWna68WqcHrdMCOu+VGQX ELc97OSZRWVP0yBP48l7EQjl3djU4Jk2sUZ6hVDE9x3i2Pruf/okcP058nMuMf7askOg n6W5lszlMIerBhxmf/D2i4KMvHMCzRanCYCKawXVePk85Npvi0UkQXzNPcJ0hOU8oQO/ 7ICwPeVyB2htZo8XWpmLH5DR6KLfBTJbI2PD1vBtXdyAQvvWKZQmhah8882zBFBnOJvJ sJeTGdALogAeJjfnmAyPpHPI+EKl0UnsDwiqddtfbmJW4IdzO3N2RS/Xia+rxnUkUDBp ioEQ== X-Gm-Message-State: AGRZ1gLcukEuKTmCw92oD4p34bIa8fxshjKSnkqbm5c9hYDRehC1M3xY E4rWa8TkHjjTiR/dSZm14OYKJmJtfnU6Rv8I+gKWhA== X-Google-Smtp-Source: AJdET5cNf5KifUg/OeaaHNn1zr3RNypjVITS8g9E/p03ERLbqj2C3L6CO77CD+5Lq8kQdO2qteURk8kHSlkezf4G8tE= X-Received: by 2002:a67:7106:: with SMTP id m6mr9705481vsc.67.1542659485098; Mon, 19 Nov 2018 12:31:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 19 Nov 2018 21:31:13 +0100 Message-ID: To: Roman Shpount Cc: rtcweb@ietf.org, mmusic@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 20:31:31 -0000 On Mon, 19 Nov 2018 at 21:21, Roman Shpount wrote: > ICE specifications (both RFC 5245 and ice-sip-sdp) are saying that these = fields are not cosmetic. All I am asking is to put values in these fields t= hat indicate that they are cosmetic instead of creating some rules on how t= hese fields should change which would cause potential interop issues. I suggest: m=3DKIND 9 ICE [codec PTs] > BTW, there are plenty of VoIP phones which use ICE and support Opus (or G= .711). They will also produce ICE mismatch since they implement RFC 5245. S= o, these end points are WebRTC compatible except for this specific issue. If those phones already implement ICE (and let's assume also DTLS-SRTP), how will a wrong or "invalid" c=3D or m=3D content affect them? Browsers won't complain no matter what the SDP re-offer contains in those lines, so the phone can put whatever it wishes. And the phone should not read them in received SDP re-offers, so I don't fully understand what the problem is. --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 19 12:48:07 2018 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 CF98A130DDB for ; Mon, 19 Nov 2018 12:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xcgj2L8ekInY for ; Mon, 19 Nov 2018 12:47:57 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 3BB90130DE2 for ; Mon, 19 Nov 2018 12:47:57 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id e5so5104017plb.5 for ; Mon, 19 Nov 2018 12:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZVIk13PfmlxzwMjNNVCXUj9S/0ufb0bo5r4vhGRtEU4=; b=yvC3kiyt1d+0QkXkc0xcr46HaMq0nFkVZW4MYFsZiPBhu3x/P0Jr+CeO+WzQP/n5HQ YPV0jazabl3dVcP8+q5lU8g9lRg32HNCR2axA5AQavAROmWtrrH8ioXsRzK56sYSMk01 YpnUBorlI7xAHZzB5wFDST75HySeZrCNiE0cUbM4zQLNvZ/Nk5EnpPiIzL8nTby6S6ON 3w5YEgRrs9FyH5RXSochzG2IAK3VSlEp0PF0A0ztw1Rul21PcV0YvFzeZ7IcYxPyCF1e yGKxDblS5RVrtKO75f+XX/8R3XkCnuTCWqG50ssyc7X+iKqUk19gmg0ZEPx5AsR9ouTb aFPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZVIk13PfmlxzwMjNNVCXUj9S/0ufb0bo5r4vhGRtEU4=; b=slnWXpxTLL/dt2O6XT6p5MGNp281ytuBQrbYXmiYyrU8YCkC51MTYWAWmhHgk6ET7b DmZPU3gZ51vbVKhI002Bqq++4Y+V0L2VFIvvfiZUFps5DYlBVZB58MP+gWM6I6ivTLOo tqQaX/EudQcWnT7JN+8B3ZNyKzA1kOi8bhQqBSh5F21HsLeb2Xl4PvHYW9Cb3Vr3keGr uDQcY8sWQVGZ6r3WLGho2VxM/vEAXvjJmWKJayXuQxtNwNkrHHhGsLzFbqfxm/CRqVHQ NlZO6CmIWvkFaQObIq+SoyPQ9qlkLQZ+kWXFgGNoH4lYmuj4oy4SRG6a2zcz48rj1QjS Ygtg== X-Gm-Message-State: AA+aEWbmN6yC0nOtjocPGLfwsZFIP+mLs9MPhBIvhmGlmQkfPFk0lONJ UAr27xttHKAaXdM+vWgmZ7evTLzJrd4= X-Google-Smtp-Source: AFSGD/XTwNXiJrqye/LSsz9W5VhWyx97jRW2GQYYFIdI0BkOxOgOLJEDPOL2heeW/NlC7FPFk2bmMw== X-Received: by 2002:a17:902:3283:: with SMTP id z3mr4086315plb.76.1542660476673; Mon, 19 Nov 2018 12:47:56 -0800 (PST) Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com. [209.85.210.173]) by smtp.gmail.com with ESMTPSA id m11sm28022520pgh.51.2018.11.19.12.47.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 12:47:56 -0800 (PST) Received: by mail-pf1-f173.google.com with SMTP id u3-v6so12734274pfm.4; Mon, 19 Nov 2018 12:47:56 -0800 (PST) X-Received: by 2002:a62:9f42:: with SMTP id g63-v6mr24340706pfe.144.1542660475819; Mon, 19 Nov 2018 12:47:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 19 Nov 2018 15:47:44 -0500 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="000000000000ab9c12057b0aa1ba" Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 20:48:00 -0000 --000000000000ab9c12057b0aa1ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 19, 2018 at 3:31 PM I=C3=B1aki Baz Castillo wro= te: > On Mon, 19 Nov 2018 at 21:21, Roman Shpount wrote: > > ICE specifications (both RFC 5245 and ice-sip-sdp) are saying that thes= e > fields are not cosmetic. All I am asking is to put values in these fields > that indicate that they are cosmetic instead of creating some rules on ho= w > these fields should change which would cause potential interop issues. > > I suggest: > > m=3DKIND 9 ICE [codec PTs] > If you are re-inventing the protocol, why would you build SDP or m=3D lines= ? If you are using an existing protocol, why do you modify it in the way it is not compatible with anything in existence? I am suggesting always doing something like: m=3Daudio 9 UDP/TLS/RTP/SAVPF [codec PTs] c=3DIN IP4 0.0.0.0 Do you see any issues with this except being aesthetically offended? > BTW, there are plenty of VoIP phones which use ICE and support Opus (or > G.711). They will also produce ICE mismatch since they implement RFC 5245= . > So, these end points are WebRTC compatible except for this specific issue= . > > If those phones already implement ICE (and let's assume also > DTLS-SRTP), how will a wrong or "invalid" c=3D or m=3D content affect > them? Browsers won't complain no matter what the SDP re-offer contains > in those lines, so the phone can put whatever it wishes. And the phone > should not read them in received SDP re-offers, so I don't fully > understand what the problem is. > Please read https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.2.5 Some people for some reason insist on following specifications. If you propose to do two opposite things, random things start being implemented. Regards, _____________ Roman Shpount --000000000000ab9c12057b0aa1ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 19, 2018 at 3:31 PM I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
On = Mon, 19 Nov 2018 at 21:21, Roman Shpount <roman@telurix.com> wrote:
> ICE specifications (both RFC 5245 and ice-sip-sdp) are saying that the= se fields are not cosmetic. All I am asking is to put values in these field= s that indicate that they are cosmetic instead of creating some rules on ho= w these fields should change which would cause potential interop issues.
I suggest:

m=3DKIND 9 ICE [codec PTs]
=C2=A0
If you are= re-inventing the protocol, why would you build SDP or m=3D lines? If you a= re using an existing protocol, why do you modify it in the way it is not co= mpatible with anything in existence?

I am suggesti= ng always doing something like:

m=3Daudio 9 UDP/TLS/RTP= /SAVPF [codec PTs]
c=3DIN IP4 0.0.0.0 =C2= =A0

Do= you see any issues with this except being aesthetically offended?

> BTW, there are plenty of VoIP phones which use ICE and support Opus= (or G.711). They will also produce ICE mismatch since they implement RFC 5= 245. So, these end points are WebRTC compatible except for this specific is= sue.

If those phones already implement ICE (and let's assume also
DTLS-SRTP), how will a wrong or "invalid" c=3D or m=3D content af= fect
them? Browsers won't complain no matter what the SDP re-offer contains<= br> in those lines, so the phone can put whatever it wishes. And the phone
should not read them in received SDP re-offers, so I don't fully
understand what the problem is.

Some people for some reason insist on follow= ing specifications. If you propose to do two opposite things, random things= start being implemented.

Regards,
__________= ___
Roman Shpount
=C2= =A0
--000000000000ab9c12057b0aa1ba-- From nobody Mon Nov 19 12:53:58 2018 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 3ED5D126F72 for ; Mon, 19 Nov 2018 12:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxTDEUZ27-7M for ; Mon, 19 Nov 2018 12:53:48 -0800 (PST) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 7F7A4128D0C for ; Mon, 19 Nov 2018 12:53:48 -0800 (PST) Received: by mail-vk1-xa30.google.com with SMTP id u62so7105288vkb.3 for ; Mon, 19 Nov 2018 12:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NOPx7fSJy4voHpgEpc17FEFA0jFU1agPgHrW1WS+71I=; b=eU6MP8PEzxSjAmYQ3KDIKp8s0kwYC4FUg2AN0A8GUMqP0xzhsQhz78rHulwjSlAB5E VksSCUN7gcwO4W3oYxd4hPujyhMi8m9UaR5e+pyHbQE5NaWBlXqMngEDD3ouweORnwdJ HOAdxYnUhyGVI7RRKnI8wSbDKvy7p3lE2RwWl/K56AWhwLucKM2Ki1QDKbMxHDCG2iTP 21fgF3a0xKRG206qakYKewA3BXjBSwdPYurhBfq/DBJwFFUg9E76MPZ1a8GNQe4ZQusE P4uPwyJTuSMcW2IFdKBn0WPiDg6kyW9VTUrWUaxYvr8goyfjZp3xnHfLEqtPIkGbb4il jXaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NOPx7fSJy4voHpgEpc17FEFA0jFU1agPgHrW1WS+71I=; b=aOI0nnZPJdFYFiXQvEbeDAAf52uH2pLz9onXGgzT7YU1Q1yv/jIx45NtqoG+9hCFhk RObQXMVNfNhWLXQXQwa27S+YpYTT89scY/KyaaVk8Wjp1fqJE35Bk4qEAHKe7cMQcIHT M1TTUXElq6nX5aQt75bhHJ738HZV7y5iaDIqAOMeIGdVQhGeyI+vRYGC4g5aGAJzV5Nm 9H/QgdI4+io777zXgq06ofEDILtlnpM36sagODA5WCuJWlwxNWpYQkrkpBHG5zl4jDY5 bG3SlL0Vo4S/aIBap+03YhJsnuUN0Hpb3LHx0hA9h+kLE1W2nyOpby/Fo4UJJynmS9Vf ujYw== X-Gm-Message-State: AGRZ1gKOjL2OsOmuFIskPf05GniludDZqAF2GCBmOu4pZx3P+VlWS4uo tHAABQ9itixV8/S0Z4jpuuW+rZpQWnHEsuymKg9JIA== X-Google-Smtp-Source: AJdET5dmoLwy0wSsTfDmphCN4xdJ8vZaTKBP2dCUEqZIdnnPXfsFdAZIkEt2WMT2uGyMx8JCrHqmX7tMb+rRmHpl7NM= X-Received: by 2002:a1f:3202:: with SMTP id y2mr9961529vky.3.1542660827382; Mon, 19 Nov 2018 12:53:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 19 Nov 2018 21:53:36 +0100 Message-ID: To: Roman Shpount Cc: rtcweb@ietf.org, mmusic@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 20:53:51 -0000 On Mon, 19 Nov 2018 at 21:47, Roman Shpount wrote: > > On Mon, Nov 19, 2018 at 3:31 PM I=C3=B1aki Baz Castillo w= rote: >> I suggest: >> >> m=3DKIND 9 ICE [codec PTs] > > > If you are re-inventing the protocol, why would you build SDP or m=3D lin= es? If you are using an existing protocol, why do you modify it in the way = it is not compatible with anything in existence? Why is proto=3D"ICE" not compatible? ICE represents a virtual path that does not correspond to a specific 5-tuple (such a tuple may dynamically change without requiring any new SDP O/A). > Please read https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#= section-3.2.5 > Some people for some reason insist on following specifications. If you pr= opose to do two opposite things, random things start being implemented. So, that spec is completely making it imposible to enable ICE trickle because it mandates that the value in c=3D and m=3D must already match an existing a=3Dcandidate line in the same SDP. This is not true when using Trickle ICE since candidates may be sent later that the SDP: https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-18 --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 19 13:08:45 2018 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 73BEA130DE5 for ; Mon, 19 Nov 2018 13:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzXwYy6Bo5nM for ; Mon, 19 Nov 2018 13:08:35 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 B9CCC130DE8 for ; Mon, 19 Nov 2018 13:08:35 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id n2so7196114pgm.3 for ; Mon, 19 Nov 2018 13:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/Tmik5UtYoAQ39jUilcmo/6XOfzC+DKbVTNAzsX/Txw=; b=svJRCaEOAfqRrEAGDW6AIuWE/LgSDSoXFJG4MBvQYXR5d2RcU8va1IntZSsAYITIKO h0V/h4W4Kdj+q1xi23lYagEnnOZFEhohAENpuLkaByVr4vTmBTnE5ZCTT9orDxiXYDIq WjtqxYDLtz1q1huquXxnMTQBuBcVoa77jF1QfXX62CD+OJGLUreTujJE9LkPBKtVu3tQ yjIufieocVeTuDHp1oPB0uHpjzXxJLREvpjn9D5ToeXfH6VjtB2l2Kb9/LgZPGSRo7qT MYuMJFC7aAiwDx272YYd4611bB7/+OopLgVxm5c+VT1Y2DlgBc82lYZcu20hrqvMuUPO Lf8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/Tmik5UtYoAQ39jUilcmo/6XOfzC+DKbVTNAzsX/Txw=; b=PdVgYFE1iJf2CafipK3u/m7Tk/Lai/eByZgPDY7GPpdF9Nmj8ULoQ2cZMTO9VC9qsQ yKXxKOnOyTbSqLS21n6kBI/ymKHOsZKHoVVjeTtCvry/M16DD7tqWoQseiZJPltIGQDD DW7NpgYpd+8jZFl+cwzi36cXg1Nkvrj3OxDZb4jqeKXqsC5UwPacGqlrfctuLKzML2rs uxMw5TpO2KPFhJjBEOW1LfGcJHsX0TPVmTpknTckpzm1znjIv7v4BoGZmhueg0Z12P9R Rx9xqiTnRr+GuIc0+tXgroNwDe9JA2H6LE5+FavBEW8rstZfQaf44E0b+xre/9wwTlLS +ULA== X-Gm-Message-State: AGRZ1gKccBmcExIQcZEVcM7RdtaHrx7hblbA8eenqynb4uu5Jl3lFs1a CTb/zXra3A76l7hPNmLONzucmRGt3Cs= X-Google-Smtp-Source: AJdET5cT8sv0yGIGo7StWKrBQeuivfDjuvJYxwooOE0ZF40+OJIr14pk4wc0ad3UqaAo4hnkDfIMHg== X-Received: by 2002:a63:f901:: with SMTP id h1mr21619635pgi.154.1542661715103; Mon, 19 Nov 2018 13:08:35 -0800 (PST) Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com. [209.85.214.181]) by smtp.gmail.com with ESMTPSA id t66sm16485447pfd.54.2018.11.19.13.08.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 13:08:34 -0800 (PST) Received: by mail-pl1-f181.google.com with SMTP id x21-v6so12432578pln.9; Mon, 19 Nov 2018 13:08:34 -0800 (PST) X-Received: by 2002:a17:902:8b88:: with SMTP id ay8mr13737510plb.55.1542661713725; Mon, 19 Nov 2018 13:08:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 19 Nov 2018 16:08:22 -0500 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="000000000000748fbd057b0aeb3f" Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 21:08:38 -0000 --000000000000748fbd057b0aeb3f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 19, 2018 at 3:53 PM I=C3=B1aki Baz Castillo wro= te: > On Mon, 19 Nov 2018 at 21:47, Roman Shpount wrote: > > > > On Mon, Nov 19, 2018 at 3:31 PM I=C3=B1aki Baz Castillo > wrote: > > >> I suggest: > >> > >> m=3DKIND 9 ICE [codec PTs] > > > > > > If you are re-inventing the protocol, why would you build SDP or m=3D > lines? If you are using an existing protocol, why do you modify it in the > way it is not compatible with anything in existence? > > Why is proto=3D"ICE" not compatible? ICE represents a virtual path that > does not correspond to a specific 5-tuple (such a tuple may > dynamically change without requiring any new SDP O/A). > There are differences between AVP/SAVP/SAVPF even when ICE is used. You quietly discarded them which can cause issues. If anybody ever implements data channels over QUICK vs SCTP, proto is the place to specify this. ICE candidates will only tell the end point that UDP vs TCP,. Kind only tells the type of stream. If there is more then one way to transport this data (SCTP vs QUICK), proto is required. Also, you ignored the question that I asked you. What is the issue that you see with: m=3Daudio 9 UDP/TLS/RTP/SAVPF [codec PTs] c=3DIN IP4 0.0.0.0 > Please read > https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.2.= 5 > > Some people for some reason insist on following specifications. If you > propose to do two opposite things, random things start being implemented. > > So, that spec is completely making it imposible to enable ICE trickle > because it mandates that the value in c=3D and m=3D must already match an > existing a=3Dcandidate line in the same SDP. This is not true when using > Trickle ICE since candidates may be sent later that the SDP: > > https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-18 > > ICE trickle is supported. Please read second bullet point of https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.2.5 Regards, _____________ Roman Shpount --000000000000748fbd057b0aeb3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 19, 2018 at 3:53 PM I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
On = Mon, 19 Nov 2018 at 21:47, Roman Shpount <roman@telurix.com> wrote:
>
> On Mon, Nov 19, 2018 at 3:31 PM I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:

>> I suggest:
>>
>> m=3DKIND 9 ICE [codec PTs]
>
>
> If you are re-inventing the protocol, why would you build SDP or m=3D = lines? If you are using an existing protocol, why do you modify it in the w= ay it is not compatible with anything in existence?

Why is proto=3D"ICE" not compatible? ICE represents a virtual pat= h that
does not correspond to a specific 5-tuple (such a tuple may
dynamically change without requiring any new SDP O/A).
=C2=A0
There are differences between AVP/SAVP/SAVPF even when IC= E is used. You quietly discarded them which can cause issues.
If anybody ever implements data channels over QUICK vs SCTP, pr= oto is the place to specify this. ICE candidates will only tell the end poi= nt that UDP vs TCP,. Kind only tells the type of stream. If there is more t= hen one way to transport this data (SCTP vs QUICK), proto is required.

Also, you ignored the question that I asked you. What = is the issue that you see with:
m=3Daudio 9 UDP/TLS/RTP/SAVPF [codec PTs]
c=3DIN IP4 0.0.0.0=C2=A0

&= gt; Please read https://to= ols.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.2.5
> Some people for some reason insist on following specifications. If you= propose to do two opposite things, random things start being implemented.<= br>
So, that spec is completely making it imposible to enable ICE trickle
because it mandates that the value in c=3D and m=3D must already match an existing a=3Dcandidate line in the same SDP. This is not true when using Trickle ICE since candidates may be sent later that the SDP:

https://tools.ietf.org/html/draft-ie= tf-mmusic-trickle-ice-sip-18


IC= E trickle is supported. Please read=C2=A0 second bullet point of=C2=A0https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section= -3.2.5

Regards,
_____________
<= div>Roman Shpount
--000000000000748fbd057b0aeb3f-- From nobody Mon Nov 19 13:17:11 2018 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 04FEB130DE5 for ; Mon, 19 Nov 2018 13:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-EuDZvw4MoJ for ; Mon, 19 Nov 2018 13:17:08 -0800 (PST) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 E6FBB130DE8 for ; Mon, 19 Nov 2018 13:17:07 -0800 (PST) Received: by mail-vk1-xa2d.google.com with SMTP id n126so7106007vke.12 for ; Mon, 19 Nov 2018 13:17:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2uVAY0zEpnoWt0c28GfJglKDTw9zYUypq+ouETrIedA=; b=ZKJ6KbBFfTcHWcc3rYWwafzWtUTlRMEdgSmM/ME9uAGWTz7QVKGHSlYtN9IfjD7kPk ETi0nmVAl/5zrRrYI03m29cSd1VNQJ068/Kwd3ow9aPq4gN5tDWqklps/2ryZ9Wzk7IT 3A2ZUnyEYTi9tMOSur0FDZah9ps1HGgd9zL3MChmJfrqJuOpXRL6uZXF9+/n6rqM9fxR VfVB4BUaXMeH8myG6Wwy2Ez31nn12fAZyli+J4SNsVGdnFLbatq0N2lMXU0zPH5whsWK Z8G8tu2Ggnyyz8ZFDIM88uNrfxHSzCvHyrjKNiHnfIKv3f4dOTUzIpT5qKtMc3lKj20a OKlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2uVAY0zEpnoWt0c28GfJglKDTw9zYUypq+ouETrIedA=; b=QEDoTrwFn6WfqDx4WxDD1JttQE+Ptvc4LNGBxUDkkZFa9GbISDVsrnYBkIuV3mqdCT cQ3jXZM51H3GOwMdvYQQn2297ce0BjlsAJw4xM/BVp6QbI84C62pv6spkDfJFf1M9yY7 lo1Jjp3CIJw3GRvd4OjgZ/AH8m9aNFnqdRgOW0WMj9zQjCl7PCtsZWi2DC3DaBYz1CCG OdNDY81bCnHt8WX/JH0+X6Ms/kHNjBvhk4CTauLzU+gxWn+a0o8JZgP3EOKb5u2ZudB2 dcSNZ3zeFaNtuPl/WtNwM0I11BC07p3IotHAFci2EKgFCcS1EQHK0HnMM2ilf25K1TFq ArQg== X-Gm-Message-State: AGRZ1gJL0SliYpBoUrAhg0XReLtJVffw3yTJ0tnq0Nr9lF8hiB8SU0dp gXNDNRSXaMnlp+Q4tX4pDVk8+8AgHROi4iPfB0Vp3Q== X-Google-Smtp-Source: AJdET5dnMg5BHWOUlsMbzbSMkQwWoBIntKB2NGVN38EWNviQET9xLEKvpFjxW5Obij5y6LqZMqBQE5egj0BpcC3H0dc= X-Received: by 2002:a1f:9042:: with SMTP id s63mr9552151vkd.17.1542662226630; Mon, 19 Nov 2018 13:17:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 19 Nov 2018 22:16:54 +0100 Message-ID: To: Roman Shpount Cc: rtcweb@ietf.org, mmusic@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 21:17:10 -0000 On Mon, 19 Nov 2018 at 22:08, Roman Shpount wrote: > If anybody ever implements data channels over QUICK vs SCTP, proto is the= place to specify this. ICE candidates will only tell the end point that UD= P vs TCP,. Kind only tells the type of stream. If there is more then one wa= y to transport this data (SCTP vs QUICK), proto is required. I understand your points, and you are right in all of them. I just don't believe that this is gonna happen in SIP world within next 25 years. I mean: in order to explain this you have moved to DataChannels, which will never exist in SIP-land (BFCP already exists which is implemented by 2-3 devices). > Also, you ignored the question that I asked you. What is the issue that y= ou see with: > m=3Daudio 9 UDP/TLS/RTP/SAVPF [codec PTs] > c=3DIN IP4 0.0.0.0 No problem other than announcing UDP while the effective candidate pair may use TCP. If that's not a problem, then ok. >> > Please read https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-= 24#section-3.2.5 >> > Some people for some reason insist on following specifications. If you= propose to do two opposite things, random things start being implemented. >> >> So, that spec is completely making it imposible to enable ICE trickle >> because it mandates that the value in c=3D and m=3D must already match a= n >> existing a=3Dcandidate line in the same SDP. This is not true when using >> Trickle ICE since candidates may be sent later that the SDP: >> >> https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-18 >> > > ICE trickle is supported. Please read second bullet point of https://too= ls.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.2.5 Didn't know that. Thanks. --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 19 13:21:05 2018 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 BAC39130DF6 for ; Mon, 19 Nov 2018 13:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qr_jfTruhLl for ; Mon, 19 Nov 2018 13:21:01 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 DE364130DE5 for ; Mon, 19 Nov 2018 13:21:01 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id b22-v6so9729223pls.7 for ; Mon, 19 Nov 2018 13:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1kFedqBjw1q87B3nWocG0ELPLDbQf0PWVcdtAsnUfIk=; b=SD00JNHNrK4dAeWS2vTrxEGPgnmMd3qwbQmDy0/yxTzr/X30GoUIfadEhoNsoYqUV3 YKSj11GhLVBFEBKRfzN25Ls4z1myw4A1tlueEnk4qinwlPABtyMuZLB6qV8ljOjf6TRi iW2SMTeCHmICSNCDOeJerGCA6wDnrVyy8xAe1THDhCQizuFYG8VXYb+SolYVx8mn94QG OlLiAs4NwBFZwgytzU9N4eB2rrA38pzPQ3sKny4VXK1fNTrU9Lxe8J96VcBUZ3MZB5G2 AI5djXkQSr21NILV5BXcPROPXvHo76tUDnY+DSN+es3qm/eagMdgYXalaKrX1x9vpWL8 2LEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1kFedqBjw1q87B3nWocG0ELPLDbQf0PWVcdtAsnUfIk=; b=VgBn3kWIKHb92HLNyr++QeayvycvzuVVLkwLrnV0kGUGfok3aZUkzisgAfWIaQzOqY 6KDiFTFxCpb2s9EOUbBuPjN8n2wSv/SqKxrm3ad/jkcZNjhPdwgm69SyAATyuouEJZor 1e5LaHz7R10lWkdiRsurvJDoQ/sWGRgIfjL2IbeS1TCq8k9iDB5KSUeAFmRrLjAfPhod Eic+jfAWb7Do24z8m1ptN+a68hrJnztnIUokGWnIaAjqBxRHWUA6PLmZB90DXi0ZmNhs J3U4E6sYV8obfA6HVwduglESE181Xj+2Fmf5bQ6jQkg5Zee27CYgCUFgDLmP0jIT9HhD Xnww== X-Gm-Message-State: AGRZ1gIgBZY4kW7d7HwS7OkeeMqd46Cb04wyGBYhrOY2Qn9er1FXwodz NjbUD2NdaAWXR+SEJBCvaq4W0lD0KNM= X-Google-Smtp-Source: AJdET5dGnHEsQIfR9fWHQNx2RSqNB9ACxqhxkxfHRlCTK3ceGAsw14V/RZEyeRMyBSU2PF8L4wl/ag== X-Received: by 2002:a17:902:1e3:: with SMTP id b90-v6mr23794062plb.117.1542662461348; Mon, 19 Nov 2018 13:21:01 -0800 (PST) Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com. [209.85.210.177]) by smtp.gmail.com with ESMTPSA id t21sm33610492pgg.24.2018.11.19.13.21.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 13:21:00 -0800 (PST) Received: by mail-pf1-f177.google.com with SMTP id v68-v6so15461129pfk.0; Mon, 19 Nov 2018 13:21:00 -0800 (PST) X-Received: by 2002:a63:b4c:: with SMTP id a12mr21895065pgl.131.1542662460459; Mon, 19 Nov 2018 13:21:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 19 Nov 2018 16:20:49 -0500 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="000000000000f6d65d057b0b1715" Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 21:21:04 -0000 --000000000000f6d65d057b0b1715 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 19, 2018 at 4:17 PM I=C3=B1aki Baz Castillo wro= te: > On Mon, 19 Nov 2018 at 22:08, Roman Shpount wrote: > > > If anybody ever implements data channels over QUICK vs SCTP, proto is > the place to specify this. ICE candidates will only tell the end point th= at > UDP vs TCP,. Kind only tells the type of stream. If there is more then on= e > way to transport this data (SCTP vs QUICK), proto is required. > > I understand your points, and you are right in all of them. I just > don't believe that this is gonna happen in SIP world within next 25 > years. I mean: in order to explain this you have moved to > DataChannels, which will never exist in SIP-land (BFCP already exists > which is implemented by 2-3 devices). > > In SIP land it is the the difference between RTP/AVP, RTP/SAVP, and UDP/TLS/RTP/SAVP which is the problem. In first case no encryption is allowed, in second case SDES-SRTP is required, and in third case DTLS-SRTP is required. Then there are AVP vs AVPF differences. Regards, _____________ Roman Shpount --000000000000f6d65d057b0b1715 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 19, 2018 at 4:17 PM I=C3=B1aki Baz Cas= tillo <ibc@aliax.net> wrote:
=
On Mo= n, 19 Nov 2018 at 22:08, Roman Shpount <roman@telurix.com> wrote:

> If anybody ever implements data channels over QUICK vs SCTP, proto is = the place to specify this. ICE candidates will only tell the end point that= UDP vs TCP,. Kind only tells the type of stream. If there is more then one= way to transport this data (SCTP vs QUICK), proto is required.

I understand your points, and you are right in all of them. I just
don't believe that this is gonna happen in SIP world within next 25
years. I mean: in order to explain this you have moved to
DataChannels, which will never exist in SIP-land (BFCP already exists
which is implemented by 2-3 devices).


In= SIP land it is the the difference between RTP/AVP, RTP/SAVP, and UDP/TLS/R= TP/SAVP which is the problem. In first case no encryption is allowed, in se= cond case SDES-SRTP is required, and in third case DTLS-SRTP is required. T= hen there are AVP vs AVPF differences.

=
Regards,
_= ____________
Roman Shpount
=
=C2=A0
--000000000000f6d65d057b0b1715-- From nobody Mon Nov 19 13:24:37 2018 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 34EAB130DF4 for ; Mon, 19 Nov 2018 13:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFv8lAVuoysf for ; Mon, 19 Nov 2018 13:24:34 -0800 (PST) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 B8AFF130DE5 for ; Mon, 19 Nov 2018 13:24:34 -0800 (PST) Received: by mail-vs1-xe36.google.com with SMTP id h78so18665892vsi.6 for ; Mon, 19 Nov 2018 13:24:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0pyaIca5mDWKXl6scXCvPBwitM4inLk0y053vrPW3bw=; b=0DHXNg1jwuz4coBVmyaShrx/mRl3dXCAMn2/QJCeNiM6oiFTukeKy0AcOs8M+TtZVv fLo7noR56aAdeDiAkfEodpFAPRQUrWWtu6rAT26Ojwc9izr4HVYhflPJ0YxodZmPWQ8J /hYVRhkuHgzIZxwbx9OF0m4IOvQOXAMs+/Gtg0pmv5D8gN1OEegxD0cJr/j1NIIOG6Gm eZGn88knRH1I6p9j+I5c3i6jt1R30HyGJdt/R5NlZdUM3q5beOGNj+K61PHRLUysB0Wo qUt36e1RiQ9b15qcz4ak+LedgZ2I1wEdNYFMMKVFmNsDTpRb+kiA0cVbDALnbjIJ4o5+ NmNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0pyaIca5mDWKXl6scXCvPBwitM4inLk0y053vrPW3bw=; b=CpYeMORAXeNd7HCzXl6suRA9/Uc+c0BvUqdRPbP2izXQIY5pxtatDkK8XSoEoAD5Iq TkQwqyZM8LYpFfLtj7zj/cCmSdZ6kNEpm/Ayb99rKx+wqbCH5U88EQmy9pxzGRs1ynEK Bl1Bvt4nCZ3kYP6fDGpBtRBOUniazmLyRkoeakRRa1/FYOvPmm4ktVG1la1gPLM4YqfA FJWQ/f2FcMJ0kBhMkcPLM6DNV4KR+v0MigI2E4bt0H07vwuluupnn6zWwQCuLI4ECesJ fJ2aNBW8mnTzJUBIgZmBiUKtbWgHkPuCsQtK/YRqZAzQR7t/8ZRL042SJmHBxy4cArcd Hgbg== X-Gm-Message-State: AGRZ1gIAAgRW0LyO3wuFHl7TLkoeYl0iUBG9EhqwRpNid4MGjjb+cKJf Bx1iLfzVSuMtFN//8jWfy9jNTVI1iSZuaNPvJMGgZEzUof4= X-Google-Smtp-Source: AJdET5dIWBsdAMz/v4zn0D7pDB9UTld7aLVkCkpvjBfdQPmjLeYtXT9XU+PWjJDBCsOSA1aCKENzrQZaJZOrOndRIZ0= X-Received: by 2002:a67:3edc:: with SMTP id a89mr9956964vsi.136.1542662673510; Mon, 19 Nov 2018 13:24:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 19 Nov 2018 22:24:22 +0100 Message-ID: To: Roman Shpount Cc: rtcweb@ietf.org, mmusic@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 21:24:36 -0000 On Mon, 19 Nov 2018 at 22:21, Roman Shpount wrote: > In SIP land it is the the difference between RTP/AVP, RTP/SAVP, and UDP/T= LS/RTP/SAVP which is the problem. In first case no encryption is allowed, i= n second case SDES-SRTP is required, and in third case DTLS-SRTP is require= d. Then there are AVP vs AVPF differences. Instead of UDP/TLS/RTP/SAVP, I still suggest ICE/TLS/RTP/SAVP, so everything covered. ICE itself handles UDP or TCP, so no need to specify it in the m=3D proto. --=20 I=C3=B1aki Baz Castillo From nobody Mon Nov 19 15:09:06 2018 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 67FC8130DF6 for ; Mon, 19 Nov 2018 15:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 K9jJVKuZCjKX for ; Mon, 19 Nov 2018 15:08:51 -0800 (PST) Received: from mail-it1-x12a.google.com (mail-it1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 228FC127598 for ; Mon, 19 Nov 2018 15:08:51 -0800 (PST) Received: by mail-it1-x12a.google.com with SMTP id o19so645765itg.5 for ; Mon, 19 Nov 2018 15:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r+7dZ3hdCZ/aoe/AoBePuHtA73U8DB7H3YzhcZXb+Ho=; b=J/fk3mmRwi0yN2z6+6fse2zRN76GNAUIsEgr1Xw/rqVriXeLGxoR1Y+5VnqkzesXH7 6SoP0UzuN58kctqE8RvZqqZHxIiE/STLbvi2DgA0KSTN/Ub8YXGfPvAKwK62U+mJYCcW 1HXZyU/l2EHxLmhER1AQY4ksMzN6nE0z59nNTMAe1YEiPLfFsEyJcCoTes/E0owWGhGh I8T4RHWI8RS+XnnfA9ZoLL4SLHheUUgGlx+klgH5MeZ8uZifp/TXDuMKMt7ESsGPBAHb E2T10XZszjd1MJeuUV/txTR+2hXnH8Z1HpcKFit10aVF+R8heTqUKRsd1WC6aW0EuaqQ IxaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r+7dZ3hdCZ/aoe/AoBePuHtA73U8DB7H3YzhcZXb+Ho=; b=DeVk6bS91HOgBlQKehoI7xYsCCA6njS7FseC/mDjSXhbQzIDJqGK8Ii3J9ewaRAf4w 9Yt8V/pzhD3fzJiWQo/3h89sf8/QiFMR6buqFdjjkTrCZnCX1DrkSnFFepGobcLcfCFt PTVTLbCCoUG2R38fBSz3q708AODnvlIEn0uTCMFnDlmo8xzHgoIDCbXRLMnweoc0+Q4m DmVZw5QnYiO0ZwhUSUJmXOhRTnP7cJnX6PTFTB5kO+JvITamJcAJedde6Xns9mpaa1QQ Dt6pazGO5MzOTxalrB7qRq51HGsEaVlNVPiYaLeA4rpdoLs4Ze7OgxJ430KEOlNQd/dU PMYA== X-Gm-Message-State: AA+aEWZucJPlvoEMdkiIs4ZN/FJe7U/9eVUK1Z+BHf9jlEaRhfmerkIH BrWkmePhqLDDn+oUnh6doiC7H7doJ0uMG0wjFXgVlw== X-Google-Smtp-Source: AFSGD/WPjxmmpRsjNhR3TXjpSMF0YJiUQsXSR94lYes1RpfS0ZJTC2IcNsfnSOkIhLfHjFa+Uh5GcI6RDt4Z8F3VRo0= X-Received: by 2002:a24:e50d:: with SMTP id g13-v6mr114503iti.8.1542668930090; Mon, 19 Nov 2018 15:08:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Mon, 19 Nov 2018 15:08:38 -0800 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Roman Shpount , RTCWeb IETF , mmusic@ietf.org Content-Type: multipart/alternative; boundary="000000000000960f7e057b0c9970" Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 23:08:54 -0000 --000000000000960f7e057b0c9970 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Pretty clear that the 0.0.0.0/9 behavior being proposed violates 5245 : The agent will proceed with the ICE procedures defined in this specification if, for each media stream in the SDP it received, the default destination for each component of that media stream appears in a candidate attribute. For example, in the case of RTP, the IP address and port in the c and m lines, respectively, appear in a candidate attribute and the value in the rtcp attribute appears in a candidate attribute. Ergo, I don't think this proposal will fly. Of the three options being considered (below), only #1 avoids violating 5245 while simultaneously minimizing busywork. 1) (current) Match IP and port, but stipulate an exact proto value 2) Match IP, port and proto 3) Set IP, port, and proto to fixed values If we think avoiding ice-mismatch when interacting with 5245 endpoints is not important, that point needs to be made clearly. Otherwise, I think the easiest path is to update ice-sip-sdp to permit #1 as a legacy interop behavior (and it can continue to recommend #3 for interop with 8445 clients). On Mon, Nov 19, 2018 at 1:24 PM I=C3=B1aki Baz Castillo wro= te: > On Mon, 19 Nov 2018 at 22:21, Roman Shpount wrote: > > In SIP land it is the the difference between RTP/AVP, RTP/SAVP, and > UDP/TLS/RTP/SAVP which is the problem. In first case no encryption is > allowed, in second case SDES-SRTP is required, and in third case DTLS-SRT= P > is required. Then there are AVP vs AVPF differences. > > Instead of UDP/TLS/RTP/SAVP, I still suggest ICE/TLS/RTP/SAVP, so > everything covered. ICE itself handles UDP or TCP, so no need to > specify it in the m=3D proto. > > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000960f7e057b0c9970 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Pretty clear that the 0.0.0.0/9 behavior being proposed violates = 5245:

=C2=A0 =C2=A0The agent will proceed wi= th the ICE procedures defined in this
=C2=A0 =C2=A0specification = if, for each media stream in the SDP it received, the
=C2=A0 =C2= =A0default destination for each component of that media stream appears
=C2=A0 =C2=A0in a candidate attribute.=C2=A0 For example, in the case= of RTP, the IP
=C2=A0 =C2=A0address and port in the c and m line= s, respectively, appear in a
=C2=A0 =C2=A0candidate attribute and= the value in the rtcp attribute appears in a
=C2=A0 =C2=A0candid= ate attribute.

Ergo, I don't think this = proposal will fly. Of the three options being considered (below), only #1 a= voids violating 5245 while simultaneously minimizing busywork.=C2=A0
<= div>
1) (current) Match IP and port, but stipulate an exact p= roto value
2) Match IP, port and proto
3) Set IP, port,= and proto to fixed values

If we think avoiding ic= e-mismatch when interacting with 5245 endpoints is not important, that poin= t needs to be made clearly. Otherwise, I think the easiest path is to updat= e ice-sip-sdp to permit #1 as a legacy interop behavior (and it can continu= e to recommend #3 for interop with 8445 clients).

On Mon, Nov 19, 2018 at 1:24 PM I= =C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
On = Mon, 19 Nov 2018 at 22:21, Roman Shpount <roman@telurix.com> wrote:
> In SIP land it is the the difference between RTP/AVP, RTP/SAVP, and UD= P/TLS/RTP/SAVP which is the problem. In first case no encryption is allowed= , in second case SDES-SRTP is required, and in third case DTLS-SRTP is requ= ired. Then there are AVP vs AVPF differences.

Instead of UDP/TLS/RTP/SAVP, I still suggest ICE/TLS/RTP/SAVP, so
everything covered. ICE itself handles UDP or TCP, so no need to
specify it in the m=3D proto.


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>= ;

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000960f7e057b0c9970-- From nobody Mon Nov 19 16:16:37 2018 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 6D204124C04 for ; Mon, 19 Nov 2018 16:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JlwUVYTucK3 for ; Mon, 19 Nov 2018 16:16:28 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 DC1B3127598 for ; Mon, 19 Nov 2018 16:16:27 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id u6so61934plm.8 for ; Mon, 19 Nov 2018 16:16:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wgvcnAYKUPd0C5L3OekyTwVDqIbEbdca/D/eRoIgPrk=; b=dXPTjb+lx9/HKOJpWW2TgEJS+iVkhgR9a/yplDrykQEsw7onwg4DXYCf1aBTY43KyS 8toFkzqEw2pGcQgvVYoKa2ajs6KPCTGGZDOkUqU2CZxfSAwpESex2KoTOCZMStga7tG+ BOLBn9wIVFGDsH7pnvGOEnFe9RsM3AFP1ZZqBxHuVDUDMhGvrcX59VrJU7LjUgE0SxFk /2gsQ9BTjb1mAivtXPgkhu/DJZCCK5q6T9JeN18XCEDSVB3q9FOuZ5tDeXnMZEbTE3oV Wq38ZaFtfz6ff6B0xKm5/ECg+Agbyqn4tvOZmdwt9/SvG+UZ14WDwB2sSr8Ex0/Vicmx G0cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wgvcnAYKUPd0C5L3OekyTwVDqIbEbdca/D/eRoIgPrk=; b=TFTB+Dp+AYlVzuGimTFtXaaFV7yxAjiMKIH/mOsf5U0Mr9o7wK4LsbvqLSigoNOUtM ritHootYj3h96BThkQcxwPU3bGMSfOI7skaOvqIvNn5BOqSkpURwCSe8Ab7N5dUX6mID h0DVuM5165NbEQ1aIcHwTzgHY7w9cr+Kt0g17YLkNfVUWA5f6PRintKDZF56I+z0bWT9 l/FeA6yV3cSqJltFMiVtHLXjiPcNex1c6bbwvowEjLBaLeliwwiJaUUkPkVYDO6SDjMg oaxVxRHM5uXCewhLCh47U2WudvLg/OjHyZtcNBnrbV3N/FtpCg3kd23B3j1s/ZRPDjAE SPsA== X-Gm-Message-State: AGRZ1gK9HDrIROZA8Hzt3vweaiO0w+Arx7SoQCB0YWVZsyuqagGvjYja jcmIic4OkhDosfV1RDyD9X/2Dl5Wo0M= X-Google-Smtp-Source: AJdET5ckCvKTPW04WmhuMduDVKfio0pdpLqHeUy3xgoQf8i3u62Gb6oMYTizYHW6iX3vcMEX9XkJMQ== X-Received: by 2002:a17:902:1124:: with SMTP id d33-v6mr25509393pla.125.1542672987239; Mon, 19 Nov 2018 16:16:27 -0800 (PST) Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com. [209.85.215.182]) by smtp.gmail.com with ESMTPSA id g123-v6sm59488108pfc.155.2018.11.19.16.16.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 16:16:26 -0800 (PST) Received: by mail-pg1-f182.google.com with SMTP id z11so76310pgu.0; Mon, 19 Nov 2018 16:16:26 -0800 (PST) X-Received: by 2002:a62:4bc2:: with SMTP id d63-v6mr26491352pfj.170.1542672986339; Mon, 19 Nov 2018 16:16:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 19 Nov 2018 19:16:15 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="0000000000005b0092057b0d8b6e" Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 00:16:30 -0000 --0000000000005b0092057b0d8b6e Content-Type: text/plain; charset="UTF-8" On Mon, Nov 19, 2018 at 6:08 PM Justin Uberti wrote: > Pretty clear that the 0.0.0.0/9 behavior being proposed violates 5245 > : > > The agent will proceed with the ICE procedures defined in this > specification if, for each media stream in the SDP it received, the > default destination for each component of that media stream appears > in a candidate attribute. For example, in the case of RTP, the IP > address and port in the c and m lines, respectively, appear in a > candidate attribute and the value in the rtcp attribute appears in a > candidate attribute. > > Ergo, I don't think this proposal will fly. Of the three options being > considered (below), only #1 avoids violating 5245 while simultaneously > minimizing busywork. > > 1) (current) Match IP and port, but stipulate an exact proto value > 2) Match IP, port and proto > 3) Set IP, port, and proto to fixed values > > If we think avoiding ice-mismatch when interacting with 5245 endpoints is > not important, that point needs to be made clearly. Otherwise, I think the > easiest path is to update ice-sip-sdp to permit #1 as a legacy interop > behavior (and it can continue to recommend #3 for interop with 8445 > clients). > The RFC 5245 does not define any candidate transports except UDP, so it does not seem to mention protocol in most of the examples. I believe that language in 5245 that you are quoting actually specifies that default address, port and protocol foundation in c= and m= line must match. Specifically it says that "for each media stream in the SDP it received, the default destination for each component of that media stream appears in a candidate attribute." If we look the term definitions,in https://tools.ietf.org/html/rfc5245#section-3 it says: Default Destination/Candidate: *The default destination for a component of a media stream is the transport address that would be used by an agent that is not ICE aware. *For the RTP component, the default IP address is in the c line of the SDP, and the port is in the m line. For the RTCP component, it is in the rtcp attribute when present, and when not present, the IP address is in the c line and 1 plus the port is in the m line. A default candidate for a component is one whose transport address matches the default destination for that component. Transport Address: The combination of an IP address and transport protocol (such as UDP or TCP) port. >From this it looks like the document simply assumes that port has type which is UDP or TCP and in order for port to match both its value and type must match. Furthermore, without protocol foundation candidate default destination is ambiguous and cannot be used without ICE. So, 1, as proposed will likely to cause ICE mismatch with existing implementations and will not be RFC 5245 compatible. 2 is the only RFC 5245 compatible option. Regards, _____________ Roman Shpount --0000000000005b0092057b0d8b6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 19, 2018 at 6:08 PM Justin= Uberti <juberti@google.com>= ; wrote:
Pretty clear that the 0.0.0.0/9 behavior being proposed violates 5245= :

=C2=A0 =C2=A0The agent will proceed with the = ICE procedures defined in this
=C2=A0 =C2=A0specification if, for= each media stream in the SDP it received, the
=C2=A0 =C2=A0defau= lt destination for each component of that media stream appears
= =C2=A0 =C2=A0in a candidate attribute.=C2=A0 For example, in the case of RT= P, the IP
=C2=A0 =C2=A0address and port in the c and m lines, res= pectively, appear in a
=C2=A0 =C2=A0candidate attribute and the v= alue in the rtcp attribute appears in a
=C2=A0 =C2=A0candidate at= tribute.

Ergo, I don't think this propos= al will fly. Of the three options being considered (below), only #1 avoids = violating 5245 while simultaneously minimizing busywork.=C2=A0
1) (current) Match IP and port, but stipulate an exact proto v= alue
2) Match IP, port and proto
3) Set IP, port, and p= roto to fixed values

If we think avoiding ice-mism= atch when interacting with 5245 endpoints is not important, that point need= s to be made clearly. Otherwise, I think the easiest path is to update ice-= sip-sdp to permit #1 as a legacy interop behavior (and it can continue to r= ecommend #3 for interop with 8445 clients).
<= div>=C2=A0
The RFC 5245 does not define any candidate transports excep= t UDP, so it does not seem to mention protocol in most of the examples. I b= elieve that language in 5245 that you are quoting actually specifies that d= efault address, port and protocol foundation in c=3D and m=3D line must mat= ch.

Sp= ecifically it says that=C2=A0 "for each media stream in the SDP it rec= eived, the default destination for each component of that media stream appe= ars in a candidate attribute."

If we look the term definitions,in https://tools.ietf.org/html= /rfc5245#section-3 it says:

Default Des= tination/Candidate: The default destination for a component of a media s= tream is the transport address that would be used by an agent that is not I= CE aware. For the RTP component, the default IP address is in the c lin= e of the SDP, and the port is in the m line. For the RTCP component, it is = in the rtcp attribute when present, and when not present, the IP address is= in the c line and 1 plus the port is in the m line. A default candidate fo= r a component is one whose transport address matches the default destinatio= n for that component.

Transport Address: Th= e combination of an IP address and transport protocol (such as UDP or TCP) = port.

From this=C2=A0 it l= ooks like the document simply assumes that port has type which is UDP or TC= P and in order for port to match both its value and type must match.
<= div dir=3D"ltr">=C2=A0=C2=A0
Furthermore, without protocol foundation candidate default destination is = ambiguous and cannot be used without ICE.=C2=A0 So, 1, as proposed will lik= ely to cause ICE mismatch with existing implementations and will not be RFC= 5245 compatible.

2 is the only RFC 5245 compatible option.

Regards,
<= div>
_____________
Roman Shpou= nt

=C2=A0
--0000000000005b0092057b0d8b6e-- From nobody Mon Nov 19 20:41:44 2018 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 0D3D9128766 for ; Mon, 19 Nov 2018 20:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 oVpAJBmSvuYj for ; Mon, 19 Nov 2018 20:41:40 -0800 (PST) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 F3C15128C65 for ; Mon, 19 Nov 2018 20:41:39 -0800 (PST) Received: by mail-it1-x12f.google.com with SMTP id m15so1604603itl.4 for ; Mon, 19 Nov 2018 20:41:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DsKpbsf2AmMJZt+PDtqP1HKhVKdJ0ikrQ/VFOC5q3sc=; b=qKFni3L2mTOW/cnyes3zTqsHv7WzefRBbmQetjiMmG0t1u6L6i9rH4JpQrmM5+NGHo pkPfGTtfL8TeCCv6vR77yMGNbO8nBpM7fBpguEH1+jDKr8+kO2Ad4nysJT3nddV5gRcJ Yr/wOpMz/O/u7bGPd7XvhVZf8/FzLrrc5V3D+USzLRSgaxknkaZVe0wkZj8jx1BTvhzo 3PIvS8qSnuce39wkc6mxt7NFnO4fdd8CrGdodiK9xnCFKIj7cDvQIrV7R0es21dDQ3kT mHEr23G3++vhd8wwAX0jipC66Hsr4rdEzjZgY+MjCufc6topOli6CBpvPXCeHY65aYei DwmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DsKpbsf2AmMJZt+PDtqP1HKhVKdJ0ikrQ/VFOC5q3sc=; b=k6IpZ8R38L2JNJwVvLp10/dLvDgFlM82SVY2sKLgwvOxADTvReKxyjdS7cSsO4wWj8 JcT4EOGKPq00OESV5eeq2MARFA/70dX7aEdsQ9FH7ndyBZKZo1p2fFIsZ/G8c961oUwU X4Frf3PqRBcinB6lqGdvABbDjMFr8nKm97J2vHG1egtEaaqBqYNeTp7uN97ujJDmU13E 1AX8cWPUmLq6+d7ENdznRFMye3WTZfE9FoxYKTWE7Sa5bCSRkCgjMP9pH2uHPrRS39E1 wj8yGe1//YPHbppvhQx1KvhLypc28gPKrvsfALCkPQIpy4zueqoQ3Xbu7r2fMtPXRQgV 6YGg== X-Gm-Message-State: AA+aEWZsWx25BVognE7e79PZHYAqoIdzyA647ihZt/y0X0y9lsK6Tu3T Eml8CSg6FkSzqrEUSMEE8bkSR6rY/uKVWrciT54RnpEeD6k= X-Google-Smtp-Source: AFSGD/Xm2+YTfwvep+IS94DtVQhULmfN6BjzHbDBDiSrZxxe2SfuJ4cV6v7G6OOFTN7KLXTJvkzUHxd1MlfU1KZ2df0= X-Received: by 2002:a24:e1ce:: with SMTP id n197mr841360ith.123.1542688898928; Mon, 19 Nov 2018 20:41:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Mon, 19 Nov 2018 20:41:24 -0800 Message-ID: To: Roman Shpount Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , RTCWeb IETF , mmusic@ietf.org Content-Type: multipart/alternative; boundary="000000000000d24e94057b113f78" Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 04:41:43 -0000 --000000000000d24e94057b113f78 Content-Type: text/plain; charset="UTF-8" Are you aware of any implementations that will trigger ICE mismatch if the proto does not match? Also, this would only happen in situations where the client offers *only* TCP candidates, which would require manual filtering by the client and is clearly a corner case. On Mon, Nov 19, 2018 at 4:16 PM Roman Shpount wrote: > On Mon, Nov 19, 2018 at 6:08 PM Justin Uberti wrote: > >> Pretty clear that the 0.0.0.0/9 behavior being proposed violates 5245 >> : >> >> The agent will proceed with the ICE procedures defined in this >> specification if, for each media stream in the SDP it received, the >> default destination for each component of that media stream appears >> in a candidate attribute. For example, in the case of RTP, the IP >> address and port in the c and m lines, respectively, appear in a >> candidate attribute and the value in the rtcp attribute appears in a >> candidate attribute. >> >> Ergo, I don't think this proposal will fly. Of the three options being >> considered (below), only #1 avoids violating 5245 while simultaneously >> minimizing busywork. >> >> 1) (current) Match IP and port, but stipulate an exact proto value >> 2) Match IP, port and proto >> 3) Set IP, port, and proto to fixed values >> >> If we think avoiding ice-mismatch when interacting with 5245 endpoints is >> not important, that point needs to be made clearly. Otherwise, I think the >> easiest path is to update ice-sip-sdp to permit #1 as a legacy interop >> behavior (and it can continue to recommend #3 for interop with 8445 >> clients). >> > > The RFC 5245 does not define any candidate transports except UDP, so it > does not seem to mention protocol in most of the examples. I believe that > language in 5245 that you are quoting actually specifies that default > address, port and protocol foundation in c= and m= line must match. > > Specifically it says that "for each media stream in the SDP it received, > the default destination for each component of that media stream appears in > a candidate attribute." > > If we look the term definitions,in > https://tools.ietf.org/html/rfc5245#section-3 it says: > > Default Destination/Candidate: *The default destination for a component > of a media stream is the transport address that would be used by an agent > that is not ICE aware. *For the RTP component, the default IP address is > in the c line of the SDP, and the port is in the m line. For the RTCP > component, it is in the rtcp attribute when present, and when not present, > the IP address is in the c line and 1 plus the port is in the m line. A > default candidate for a component is one whose transport address matches > the default destination for that component. > > Transport Address: The combination of an IP address and transport protocol > (such as UDP or TCP) port. > > From this it looks like the document simply assumes that port has type > which is UDP or TCP and in order for port to match both its value and type > must match. > > Furthermore, without protocol foundation candidate default destination is > ambiguous and cannot be used without ICE. So, 1, as proposed will likely > to cause ICE mismatch with existing implementations and will not be RFC > 5245 compatible. > > 2 is the only RFC 5245 compatible option. > > Regards, > _____________ > Roman Shpount > > > --000000000000d24e94057b113f78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Are you aware of any implementations that will trigger ICE= mismatch if the proto does not match? Also, this would only happen in situ= ations where the client offers *only* TCP candidates, which would require m= anual filtering by the client and is clearly a corner case.

<= /div>
On Mon, Nov 19, 2018 a= t 4:16 PM Roman Shpount <roman@telu= rix.com> wrote:
On Mon, Nov 19, 2018 at 6:08 PM Justin Uberti <= juberti@google.com<= /a>> wrote:
<= div dir=3D"ltr">
Pretty clear that the 0.0.0.0/9 behavior being proposed violates <= a href=3D"https://tools.ietf.org/html/rfc5245#section-5.1" target=3D"_blank= ">5245:

=C2=A0 =C2=A0The agent will proceed wit= h the ICE procedures defined in this
=C2=A0 =C2=A0specification i= f, for each media stream in the SDP it received, the
=C2=A0 =C2= =A0default destination for each component of that media stream appears
=C2=A0 =C2=A0in a candidate attribute.=C2=A0 For example, in the case= of RTP, the IP
=C2=A0 =C2=A0address and port in the c and m line= s, respectively, appear in a
=C2=A0 =C2=A0candidate attribute and= the value in the rtcp attribute appears in a
=C2=A0 =C2=A0candid= ate attribute.

Ergo, I don't think this = proposal will fly. Of the three options being considered (below), only #1 a= voids violating 5245 while simultaneously minimizing busywork.=C2=A0
<= div>
1) (current) Match IP and port, but stipulate an exact p= roto value
2) Match IP, port and proto
3) Set IP, port,= and proto to fixed values

If we think avoiding ic= e-mismatch when interacting with 5245 endpoints is not important, that poin= t needs to be made clearly. Otherwise, I think the easiest path is to updat= e ice-sip-sdp to permit #1 as a legacy interop behavior (and it can continu= e to recommend #3 for interop with 8445 clients).
=C2=A0
The RFC 5245 does not define any candidate transports= except UDP, so it does not seem to mention protocol in most of the example= s. I believe that language in 5245 that you are quoting actually specifies = that default address, port and protocol foundation in c=3D and m=3D line mu= st match.

Specifically it says that=C2=A0 "for each media stream in the SDP = it received, the default destination for each component of that media strea= m appears in a candidate attribute."
<= br>
If we look the term definitions,in htt= ps://tools.ietf.org/html/rfc5245#section-3 it says:

Default Destination/Candidate: The default destination for = a component of a media stream is the transport address that would be used b= y an agent that is not ICE aware. For the RTP component, the default IP= address is in the c line of the SDP, and the port is in the m line. For th= e RTCP component, it is in the rtcp attribute when present, and when not pr= esent, the IP address is in the c line and 1 plus the port is in the m line= . A default candidate for a component is one whose transport address matche= s the default destination for that component.

Transport Address: The combination of an IP address and transport protoc= ol (such as UDP or TCP) port.

From this=C2=A0 it looks like the document simply assumes that port has= type which is UDP or TCP and in order for port to match both its value and= type must match.
=C2=A0=C2=A0
Furthermore, without protocol foundation candidate= default destination is ambiguous and cannot be used without ICE.=C2=A0 So,= 1, as proposed will likely to cause ICE mismatch with existing implementat= ions and will not be RFC 5245 compatible.
<= br>
2 is the only RFC 5245 compatible optio= n.

Reg= ards,
_____________
Roman Shpount

=C2=A0
--000000000000d24e94057b113f78-- From nobody Mon Nov 19 21:31:26 2018 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 07B63127332 for ; Mon, 19 Nov 2018 21:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lomad9KuBvPm for ; Mon, 19 Nov 2018 21:31:19 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 607131293FB for ; Mon, 19 Nov 2018 21:31:17 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id gn14so407201plb.10 for ; Mon, 19 Nov 2018 21:31:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P7zCR/SdVEA1VTuQ2W8NsiEyXjx/sG977jhbkAG6ejI=; b=rB3pt5saN4LSCCTyqTHh3cIGmmqhmPmzimAD/XLQH6e7rcQeB299ZnfzfuMZ2U0EZs xfKfIynQkaByu9mppI4h5eeo83NBlxfFN5pySGZSRrJCwPUw3VueccuIt3kM1w+QabwS YpbwUwTpvI2LPnu3zuAPvnlNh96pwRRkrSfPRyBkDX38qHz0IF7ZUJxCp9OIauquU5v+ iO0Fyutf5obEmWMtb29aKDu2rdDDwnYsNXgYV4PWJkktW8MPMTEV55J+iZ+oJ8EPMp5P Lb9M8oVQwRmyG7Nx8o0A7ltM0xMNBTsM8oydn1vxHiZIGMsWqsJdLmRIQtSqJFyXw+Ag qZVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P7zCR/SdVEA1VTuQ2W8NsiEyXjx/sG977jhbkAG6ejI=; b=ph1sovQtoFauKqVdAH7VdDfMIPzKLcOaTi6Q4yHKKZaR4ZuT1uLS0NCx1fzFpY28oa VDkWHVq0tsCLLhFF55iWMjQsQzjNMyI/WLBX0m+YocIfv+ZMcfNKbN/0TKwN9OKkS+d/ DUL9a9E63/LeDPLAzwcCPUOjdZ3ndZ92a04bJsi1EJ9yS7Z6/Mz9BVG/1ijdx4gqKPV5 eDqFKfpd0+3gwEoE0P8sYtKrjzuAKnp7+68AYXF2jQQ8TLxJA4//lh03iMD5pfy+vbce 6U5lkNU/corlrJov8sPSvD8NtK6raQzi63jd+5IWBbCJlk/31hfwVkBMegFSBLS8W25A mkpg== X-Gm-Message-State: AA+aEWZ46w6OK56frlg5XoBCBqbLkm2B/WZy3L5qBXW6GXXTrw8Gs1Re wj3cQo49XWexdJe2QlSblLHcpPx5INo= X-Google-Smtp-Source: AFSGD/WduKWCvgwsXKL2f7NGbxIK7r/W73+7jCl5Qlj3tNpc5OG0p3iklz5Pif7olouBTORf4YYkHA== X-Received: by 2002:a17:902:2006:: with SMTP id n6-v6mr761096pla.131.1542691875300; Mon, 19 Nov 2018 21:31:15 -0800 (PST) Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com. [209.85.215.173]) by smtp.gmail.com with ESMTPSA id a73-v6sm49828698pfj.38.2018.11.19.21.31.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 21:31:14 -0800 (PST) Received: by mail-pg1-f173.google.com with SMTP id s198so388423pgs.2; Mon, 19 Nov 2018 21:31:14 -0800 (PST) X-Received: by 2002:a63:b4c:: with SMTP id a12mr659276pgl.131.1542691873731; Mon, 19 Nov 2018 21:31:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Tue, 20 Nov 2018 00:31:02 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="00000000000021b8e3057b11f187" Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 05:31:20 -0000 --00000000000021b8e3057b11f187 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 19, 2018 at 11:41 PM Justin Uberti wrote: > Are you aware of any implementations that will trigger ICE mismatch if the > proto does not match? Also, this would only happen in situations where the > client offers *only* TCP candidates, which would require manual filtering > by the client and is clearly a corner case. > I think a couple of popular hardware VoIP phones and one widely used SIP based business communication/messaging product will trigger a mismatch in case of incorrect protocol (non UDP if UDP candidates are present and non TCP, if only TCP candidates are present according to their ICE implementation document). I have to say, that these things do have a tendency to change between product updates and I have not tested this product for a while. Our own products currently match the protocol to default candidate, so we did not need to retest this issue. TCP based transport will happen for any subsequent offer/answer exchange when TCP candidate is nominated. Only a single TCP ICE candidate will be present in the session description, so that protocol in m= line will have to be TCP. In case of the above mentioned product, their ICE protocol implementation document says that call must be terminated, if in subsequent offer, protocol in the m= line does not match the protocol in the ICE candidate. Regards, _____________ Roman Shpount --00000000000021b8e3057b11f187 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 19, 2018 at 11:41 PM Justin Uberti <= ;juberti@google.com> wrote:
Are you aware of any implementations that will trigger ICE mis= match if the proto does not match? Also, this would only happen in situatio= ns where the client offers *only* TCP candidates, which would require manua= l filtering by the client and is clearly a corner case.
<= div>
I think a couple of popular hardware VoIP phones and one= =C2=A0widely used SIP based business communication/messaging product will t= rigger a mismatch in case of incorrect protocol (non UDP if UDP candidates = are present and non TCP, if only TCP candidates are present according to th= eir ICE implementation document). I have to say, that these things do have = a tendency to change between product updates and I have not tested this pro= duct for a while. Our own products currently match the protocol to default = candidate, so we did not need to retest this issue.

TCP based transport will happen for any subsequent offer/answer exchange = when TCP candidate is nominated. Only a single TCP ICE candidate will be pr= esent in the session description, so that protocol in m=3D line will have t= o be TCP. In case of the above mentioned product, their ICE protocol implem= entation document says that call must be terminated, if in subsequent offer= , protocol in the m=3D line does not match the protocol in the ICE candidat= e.

Regards,
_____________
Roman Shpount
=C2=A0
--00000000000021b8e3057b11f187-- From nobody Mon Nov 19 21:58:06 2018 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 AB2B71292AD for ; Mon, 19 Nov 2018 21:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 MdwHwVEkiRjw for ; Mon, 19 Nov 2018 21:58:03 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 387F5127332 for ; Mon, 19 Nov 2018 21:58:03 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id x6so521425ioa.9 for ; Mon, 19 Nov 2018 21:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LLoT8/owmum7C3OU0Xceo2sRO8oeIu4Gv9SofZ8byvc=; b=NC+/Me7Ow1A+w4oR/y1+5G9AeZ2LJwPpDXBzMIrkAdY/TmeH4Ur4FudkUwfUSZMwwG lYxYypf5v7hmwV5FvIgMswBL0Q71R4u39n9o0Gm0nD9vAVTa57sbjVlJglQmabzWBJIq JgEgN1jnxWZcloy4VtQDY9TQXFOWcml9fkqjvZAZnat+j8tQooAWnJo7LM8CEYfQDtDU REjdbNCEsRtWBW1f1asY7WgadlGi87bYe1b/rEEoZAPlrfbyyAJfpKV9PWlkiq0wLXR8 7Y3+Vy2Gr4dwmASro4UtKeCmqT2prfjIfrkTol6xAAXx2bBJ6JP/VR32KuBIUsgq3qMa TVyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LLoT8/owmum7C3OU0Xceo2sRO8oeIu4Gv9SofZ8byvc=; b=JMiKciJpykr/uHnPXZPuJUa8FKMDP4ep4tn6M+RrQruPfMxejVdHvx60gOLnmgAsY2 ztqsCeghfbKYyg5vxWRZ0rr+SuZC+a348JICcckrMY+AZEwnl9WiQP0gSdvyTWoW39BT SZWFvp4HdMnbMQN+CIO0QHWLQwGY4LF+n6Mtv1ko3wGzgvX1eMh6t6JNVusorA69Stn1 dHf1WBsVtmeXBohOtjti7G/vJ2mqYz0p83/7eRe7pAPT9Ahvr5eVxDnTsbIEQCxeV3hD 7Ii9zcK9ii5qei3KWkOzPMqBmg5zkyCWa8avT6PwTY70m/lkgcGK3X4IeSI1Zz3EzHeW UBAg== X-Gm-Message-State: AA+aEWbAJCP4PzTz9NG2H2bhoXFSowdYStlD8m88WisPmqWyTfjgvbX/ YhNylft3KaPdXzNeBbt3UK5j2CHEZvCkWct+81lNSA== X-Google-Smtp-Source: AFSGD/WbWYJBEnzQg3Fq7OZX+uXAzGJCBUlln99vQmym7vLEF5/GiQyQiTofKuUuANF3bS6LrB5OgjyESqftui2OTo4= X-Received: by 2002:a5e:9609:: with SMTP id a9-v6mr463875ioq.95.1542693482074; Mon, 19 Nov 2018 21:58:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Mon, 19 Nov 2018 21:57:47 -0800 Message-ID: To: Roman Shpount Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , RTCWeb IETF , mmusic@ietf.org Content-Type: multipart/alternative; boundary="000000000000ffcc31057b125063" Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 05:58:05 -0000 --000000000000ffcc31057b125063 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 19, 2018 at 9:31 PM Roman Shpount wrote: > On Mon, Nov 19, 2018 at 11:41 PM Justin Uberti wrote: > >> Are you aware of any implementations that will trigger ICE mismatch if >> the proto does not match? Also, this would only happen in situations where >> the client offers *only* TCP candidates, which would require manual >> filtering by the client and is clearly a corner case. >> > > I think a couple of popular hardware VoIP phones and one widely used SIP > based business communication/messaging product will trigger a mismatch in > case of incorrect protocol (non UDP if UDP candidates are present and non > TCP, if only TCP candidates are present according to their ICE > implementation document). I have to say, that these things do have a > tendency to change between product updates and I have not tested this > product for a while. Our own products currently match the protocol to > default candidate, so we did not need to retest this issue. > > TCP based transport will happen for any subsequent offer/answer exchange > when TCP candidate is nominated. Only a single TCP ICE candidate will be > present in the session description, so that protocol in m= line will have > to be TCP. In case of the above mentioned product, their ICE protocol > implementation document says that call must be terminated, if in subsequent > offer, protocol in the m= line does not match the protocol in the ICE > candidate. > VoIP phones will almost certainly never receive TCP ICE candidates from a WebRTC implementation, which only gather active TCP candidates. Anyway, we have the 3 choices listed below. We differ on which is the most pragmatic solution. If the WG has enough voices in support of #2 or #3 to overturn the consensus of #1 from IETF 103, I will write it up accordingly. > --000000000000ffcc31057b125063 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Nov 19, 2018 at 9:31 PM Roman Shpount <roman@telurix.com> wrote:
On Mon, Nov 19, 2018 at = 11:41 PM Justin Uberti <juberti@google.com> wrote:
Are you aware of a= ny implementations that will trigger ICE mismatch if the proto does not mat= ch? Also, this would only happen in situations where the client offers *onl= y* TCP candidates, which would require manual filtering by the client and i= s clearly a corner case.

I think a co= uple of popular hardware VoIP phones and one=C2=A0widely used SIP based bus= iness communication/messaging product will trigger a mismatch in case of in= correct protocol (non UDP if UDP candidates are present and non TCP, if onl= y TCP candidates are present according to their ICE implementation document= ). I have to say, that these things do have a tendency to change between pr= oduct updates and I have not tested this product for a while. Our own produ= cts currently match the protocol to default candidate, so we did not need t= o retest this issue.

TCP based transport will happ= en for any subsequent offer/answer exchange when TCP candidate is nominated= . Only a single TCP ICE candidate will be present in the session descriptio= n, so that protocol in m=3D line will have to be TCP. In case of the above = mentioned product, their ICE protocol implementation document says that cal= l must be terminated, if in subsequent offer, protocol in the m=3D line doe= s not match the protocol in the ICE candidate.

VoIP phones will almost certainly never receive TCP I= CE candidates from a WebRTC implementation, which only gather active TCP ca= ndidates.

Anyway, we have the 3 choices listed bel= ow. We differ on which is the most pragmatic solution. If the WG has enough= voices in support of #2 or #3 to overturn the consensus of #1 from IETF 10= 3, I will write it up accordingly.
--000000000000ffcc31057b125063-- From nobody Mon Nov 19 22:16:11 2018 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 BA64D1277D2 for ; Mon, 19 Nov 2018 22:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zrBEikLfTju for ; Mon, 19 Nov 2018 22:16:02 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 77F2212870E for ; Mon, 19 Nov 2018 22:16:02 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id z9so487409pfi.2 for ; Mon, 19 Nov 2018 22:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ASXxn7Tj4LE3U4OmVLVqUg9rluquMSJ5YaE1dwr5z9o=; b=HdiFkF5pgugjKVzBH5iHLHggbhpzK8S0nU3rwAtWfQVuUKLolNfUanTkY3w2RqyqUV RAlDMZJmEIhxIt4cJMltOjCPRrNvw0bihKkoA1pkNSKu1aoWqsU/F3IwtT1zGXvDDwNu RNerp81TPHQ0dYnhSrek9Kzfs6EcWdVEBKS6WzVXayM/wg3islwrYrHnvllYEZcex1Ph G6pzQCK8Te2f5bc5y3VosTPpQ0npZgzR4Qs3xtdET72HIVJT/CNF1Sn71Vz+3950wUbQ O51oaz87j5qmJkjwQe3XJsen9u3rycccH2u81uSCxCue1i8n6Hn21MvosV/U6NQGFA2e WE7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ASXxn7Tj4LE3U4OmVLVqUg9rluquMSJ5YaE1dwr5z9o=; b=oJvtlCVer+6sNkhH8LJwM+84yqpQ9YIrzabx68R9OyoOQWF2+OqUihICt+TeXPZcnw r8X7zx0yxR7phLP+CX+CNJhgzotqcBQu7DTyI2ayd2074Qp+1Hqdr96RgtMLd2JLk06E XtKUI61i+IWgNJemct71jJ6qbiAzwycF7V3FsjdexGL1PUBl1AHPYwzgMAYO4RklXqSZ 965rTDKLDXqCYDz+1QXNgL9R0dPrq/Tioje0JueBj6KwJy1LGa7e3GLc0IHBV3RefW3d 8OUfA7SVwIHVilOcHQxUVoZW4+DABFAdtw3VweJe92/oCoxLBYOiSW7ip3B8uO0d1wg5 WjUA== X-Gm-Message-State: AA+aEWboLUZHSdHipvZdu7aLT2HVlJhJSP8M0vw3JBmNttIh+3VkweHo FgdZROTbr5WfVVfPwYhJEVosg/WVrnQ= X-Google-Smtp-Source: AFSGD/Ve4DdIBJz+vtTdOqfw8cGQDjEvZHBQGAQx+OAkK/4MEnr3mAh8O/tQUVEI0eXc3c+mWxf9xQ== X-Received: by 2002:a63:504d:: with SMTP id q13mr743352pgl.319.1542694561855; Mon, 19 Nov 2018 22:16:01 -0800 (PST) Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com. [209.85.210.181]) by smtp.gmail.com with ESMTPSA id g136sm27111503pfb.154.2018.11.19.22.16.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 22:16:01 -0800 (PST) Received: by mail-pf1-f181.google.com with SMTP id i12so477234pfo.7; Mon, 19 Nov 2018 22:16:00 -0800 (PST) X-Received: by 2002:a62:1b50:: with SMTP id b77mr920986pfb.36.1542694560687; Mon, 19 Nov 2018 22:16:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Tue, 20 Nov 2018 01:15:49 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="000000000000496a33057b12918b" Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 06:16:05 -0000 --000000000000496a33057b12918b Content-Type: text/plain; charset="UTF-8" On Tue, Nov 20, 2018 at 12:58 AM Justin Uberti wrote: > Anyway, we have the 3 choices listed below. We differ on which is the most > pragmatic solution. If the WG has enough voices in support of #2 or #3 to > overturn the consensus of #1 from IETF 103, I will write it up accordingly. > So the 3 choices are: 1) (current) Match IP and port, but stipulate an exact proto value -- This choice is not compliant with either RFC 5245 or draft ice-sip-sdp. If this is selected, ice-sip-sdp will need to be updated 2) Match IP, port and proto -- Compliant with both RFC 5245 and ice-sip-sdp 3) Set IP, port, and proto to fixed values -- Compliant with only ice-sip-sdp but not with RFC 5245 Regards, _____________ Roman Shpount --000000000000496a33057b12918b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 20, 2018 at 12:58 AM Justin Uberti <= ;juberti@google.com> wrote:
Anyway, we have the 3 choices = listed below. We differ on which is the most pragmatic solution. If the WG = has enough voices in support of #2 or #3 to overturn the consensus of #1 fr= om IETF 103, I will write it up accordingly.
=

So the 3 choices are:

1) (current) Match IP and port, but stipulate an exact p= roto value -- This choice=C2=A0is not c= ompliant with either RFC 5245 or draft ice-sip-sdp. If this is selected, ic= e-sip-sdp will need to be updated
2) Match IP, port and proto -- Compliant with both=C2=A0RFC 5245 and ice-sip-sdp
3) Set IP, port, and proto to fixed values -- Compliant with = only ice-sip-sdp but not with=C2=A0RFC = 5245

Regards,
_____________Roman Shpount
--000000000000496a33057b12918b-- From nobody Mon Nov 19 22:26:51 2018 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 02097123FFD for ; Mon, 19 Nov 2018 22:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nL1X4QZeFyVM for ; Mon, 19 Nov 2018 22:26:42 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 061E81277D2 for ; Mon, 19 Nov 2018 22:26:42 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id b7so488690pfi.8 for ; Mon, 19 Nov 2018 22:26:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kvPVxsFNi9N4iKFQuJHCCBd8DN3b/qn/+/6U74xGhLE=; b=BYpEKztwtCI8P2bJelZIXBjCBiju2syeTDt1Fp7j0G+BfQEeWH3kxI3jFOnfWOuvpV OayjJFCuE3Z3BtD6o1UHY+8XRngM6Rrb9wfiVjgPmnP2zW/pNvhbRFze/XosIEF2PWu0 b8b83L/i2VdeGD4vtRHAeExea/uU39ps2SSPk0OZjzPDXx6OacSgOm/veZ0mGwRGdUcj ovwWED2xS4k/zic/48S4DWnGvdv7djWzNJzPEq+HGHEseuw9LY2476IdOnsAnYZYUl37 QQTwozRKl6wiV3qHN/LbDU0lDYTLi9LD9YjCGRy2ifP6LkEG4HQtdxUhvE1YsLJSQwBF XVPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kvPVxsFNi9N4iKFQuJHCCBd8DN3b/qn/+/6U74xGhLE=; b=bQmISv/HDQzvGTAJ8z4okXFXjK9k4HfMdk6CPk58lfCCwuCXYRSq6EFLhPmy1JSLoy hBQKEvgqMiOexY0ZizF5/S9So5DEVtzTcMMBqm3gH5Dlh+Yl8gqoqDDHfgBa9b2y4pX4 FGY9NOySPo+FnsDYSCRv2iyAZMaVZ4okCxG5XqpQUbeA21a0fcYezB/p24ibuMvwyllJ uP2ST2Wjk6F/ivPC1jBYG+0S7eLmtd5JfXJSk7D8FteUlVjQyce7KCStKU5K35U54JOm 7HquIrlRNf/cUPkCqKubsvBnqcpsNFFibQPEFRsubjrLySHRWEmbkswCiUXdOoOUvJIL paRg== X-Gm-Message-State: AA+aEWYnyZN5UcXBZ3PFg6GfUJqj0eSPNxOi+2ovMcTUiEWlckv+rL+q anKUfC46Rp4pUlq3oyP/tfk30y7YHZQ= X-Google-Smtp-Source: AFSGD/UKOZCNpKhD0/K6A1Dn0j0vfQjeXOw3/r1xgQaSpeUIjuT8SQ5hGtS8NEW3EoHS7nx6o/erIw== X-Received: by 2002:a63:5664:: with SMTP id g36mr750315pgm.313.1542695201411; Mon, 19 Nov 2018 22:26:41 -0800 (PST) Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com. [209.85.215.170]) by smtp.gmail.com with ESMTPSA id t78-v6sm75975800pfk.59.2018.11.19.22.26.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 22:26:40 -0800 (PST) Received: by mail-pg1-f170.google.com with SMTP id g189so445652pgc.5; Mon, 19 Nov 2018 22:26:40 -0800 (PST) X-Received: by 2002:a62:380e:: with SMTP id f14-v6mr881506pfa.203.1542695200406; Mon, 19 Nov 2018 22:26:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Tue, 20 Nov 2018 01:26:28 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="0000000000006ac251057b12b73e" Archived-At: Subject: Re: [rtcweb] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 06:26:44 -0000 --0000000000006ac251057b12b73e Content-Type: text/plain; charset="UTF-8" On Tue, Nov 20, 2018 at 1:15 AM Roman Shpount wrote: > On Tue, Nov 20, 2018 at 12:58 AM Justin Uberti wrote: > >> Anyway, we have the 3 choices listed below. We differ on which is the >> most pragmatic solution. If the WG has enough voices in support of #2 or #3 >> to overturn the consensus of #1 from IETF 103, I will write it up >> accordingly. >> > > So the 3 choices are: > > 1) (current) Match IP and port, but stipulate an exact proto value -- This > choice is not compliant with either RFC 5245 or draft ice-sip-sdp. If > this is selected, ice-sip-sdp will need to be updated > 2) Match IP, port and proto -- Compliant with both RFC 5245 and > ice-sip-sdp > 3) Set IP, port, and proto to fixed values -- Compliant with only > ice-sip-sdp but not with RFC 5245 > P.S. There is a compromise option 4) Proto is fixed (UDP). If default candidate is UDP, address and port should match the candidate. If default candidate is TCP, set address to IN IP4 0.0.0.0 and port to 9. This is compliant with both RFC 5245 and ice-sip-sdp for UDP default candidates, but only compliant with ice-sip-sdp for TCP default candidates. Regards, _____________ Roman Shpount --0000000000006ac251057b12b73e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 20, 2018 at 1:15 AM Roman Shpount <= roman@telurix.com> wrote:
On Tue, Nov 20, 2018 at 12:58 AM Ju= stin Uberti <jub= erti@google.com> wrote:
Anyway, we have the 3 choices listed below. We differ on which is the mo= st pragmatic solution. If the WG has enough voices in support of #2 or #3 t= o overturn the consensus of #1 from IETF 103, I will write it up accordingl= y.

So the 3 choices are:<= /div>

1) (current) Match IP a= nd port, but stipulate an exact proto value -- This choice=C2=A0is not compliant with either RFC 5245 or draft ice= -sip-sdp. If this is selected, ice-sip-sdp will need to be updated
2) Match IP, port and proto -- Complian= t with both=C2=A0RFC 5245 and ice-sip-s= dp
3) Set IP, port, and proto t= o fixed values -- Compliant with only ice-sip-sdp but not with=C2=A0RFC 5245
=

P.S. There is a compromise option 4) Proto is fixed (UD= P).=C2=A0 If default candidate is UDP, address and port should match the ca= ndidate. If default candidate is TCP, set address to IN IP4 0.0.0.0 and por= t to 9. This is compliant with both RFC 5245 and ice-sip-sdp for UDP defaul= t candidates, but only compliant with ice-sip-sdp for TCP default candidate= s.

Regards,
_____________
Roman Shp= ount
=C2=A0
--0000000000006ac251057b12b73e-- From nobody Tue Nov 20 16:10:24 2018 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 1F5E9130E9C for ; Tue, 20 Nov 2018 16:10:17 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoQBnBXK3QqG for ; Tue, 20 Nov 2018 16:10:16 -0800 (PST) Received: from smtp97.iad3b.emailsrvr.com (smtp97.iad3b.emailsrvr.com [146.20.161.97]) (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 DDBFC130E76 for ; Tue, 20 Nov 2018 16:10:12 -0800 (PST) Received: from smtp13.relay.iad3b.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.iad3b.emailsrvr.com (SMTP Server) with ESMTP id 0A24260318; Tue, 20 Nov 2018 19:10:12 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp13.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 7D844602A6; Tue, 20 Nov 2018 19:10:11 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Tue, 20 Nov 2018 19:10:12 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_4007E742-3BC0-468F-967A-EB1132A8BA24" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Cullen Jennings In-Reply-To: Date: Tue, 20 Nov 2018 17:10:09 -0700 Cc: RTCWeb IETF , mmusic WG Message-Id: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> References: To: Roman Shpount X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 00:10:17 -0000 --Apple-Mail=_4007E742-3BC0-468F-967A-EB1132A8BA24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sounds like the ice-sip-sdp draft has not concerned itself much with = working with the existing deployed endpoint which treat 0.0.0.0 as a = hold indicator. I think the JSEP solution will work much better in = practice.=20 This is discussed a bit in=20 https://tools.ietf.org/html/rfc6337#section-5.4 = > On Nov 19, 2018, at 11:28 AM, Roman Shpount wrote: >=20 > Hi All, >=20 > The current language in JSEP makes it incompatible with any ICE = implementation, either existing or the future ones compliant with = ice-sip-sdp draft. You can, of course, overwrite ice-sip-sdp, but this = will mean JSEP will be a completely incompatible system.. >=20 > The problem is that JSEP proposes to use UDP protocol in the m=3D line = and at the same time update address and port to the currently selected = candidate. Based on ice-sip-sdp, if protocol of the current selected = candidate does not match protocol in the m=3D line, this will mean = either ICE mismatch or additional candidate with protocol, address, and = port form m=3D and c=3D line. >=20 > Second, ice-sip-sdp treats SDP during ICE restart, when multiple = candidates are present different from SDP when ICE is not restarted = (single candidate). According to ice-sip-sdp, when only a single = candidate is present, this candidate protocol, address and port are set = in m=3D and c=3D line. JSEP proposes to put original UDP protocol and = address and port from the single candidate. >=20 > To be specific, it is not the fact that protocol in m=3D line is not = updated is an issue. It is that protocol in not updated but address and = port in m=3D and c=3D line are updated. In the ice-sip-sdp draft there = is a solution for this issue -- set address to IN IP4 0.0.0.0 and port = to 9. This is specifically supposed to be ignored and not cause the ICE = mismatch or extra candidates. If JSEP wants to overwrite ice-sip-sdp, it = can specify that m- line protocol should always be set to UDP based = protocol, c=3D line address should be set to IN IP4 0.0.0.0 and m=3D = line port set to 9. In case of an ICE only system where c=3D and m=3D = line address information is irrelevant, this makes implementation = simpler since m=3D and c=3D line address information can stay constant = for the duration of the session. >=20 > Regards, > _____________ > Roman Shpount > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail=_4007E742-3BC0-468F-967A-EB1132A8BA24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Sounds like the ice-sip-sdp draft has = not concerned itself much with working with the existing deployed = endpoint which treat 0.0.0.0 as a hold indicator. I think the JSEP = solution will work much better in practice. 

This is discussed a bit = in 
https://tools.ietf.org/html/rfc6337#section-5.4


On Nov 19, 2018, at 11:28 AM, Roman Shpount = <roman@telurix.com> wrote:

Hi All,

The= current language in JSEP makes it incompatible with any ICE = implementation, either existing or the future ones compliant with = ice-sip-sdp draft. You can, of course, overwrite ice-sip-sdp, but this = will mean JSEP will be a completely incompatible system..

The problem is that JSEP = proposes to use UDP protocol in the m=3D line and at the same time = update address and port to the currently selected candidate. Based on = ice-sip-sdp, if protocol of the current selected candidate does not = match protocol in the m=3D line, this will mean either ICE mismatch or = additional candidate with protocol, address, and port form m=3D and c=3D = line.

Second, = ice-sip-sdp treats SDP during ICE restart, when multiple candidates are = present different from SDP when ICE is not restarted (single candidate). = According to ice-sip-sdp, when only a single candidate is present, this = candidate protocol, address and port are set in m=3D and c=3D line. JSEP = proposes to put original UDP protocol and address and port from the = single candidate.

To be specific, it is not the fact that protocol in m=3D line = is not updated is an issue. It is that protocol in not updated but = address and port in m=3D and c=3D line are updated. In the ice-sip-sdp = draft there is a solution for this issue -- set address to IN IP4 = 0.0.0.0 and port to 9. This is specifically supposed to be ignored and = not cause the ICE mismatch or extra candidates. If JSEP wants to = overwrite ice-sip-sdp, it can specify that m- line protocol should = always be set to UDP based protocol, c=3D line address should be set = to   IN IP4 0.0.0.0 and m=3D line port set to 9. In case of an ICE only = system where c=3D and m=3D line address information is irrelevant, this = makes implementation simpler since m=3D and c=3D line address = information can stay constant for the duration of the session.

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

= --Apple-Mail=_4007E742-3BC0-468F-967A-EB1132A8BA24-- From nobody Tue Nov 20 17:25:32 2018 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 E046412896A for ; Tue, 20 Nov 2018 17:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqBNnMhzGqTN for ; Tue, 20 Nov 2018 17:25:23 -0800 (PST) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 86379130E11 for ; Tue, 20 Nov 2018 17:25:23 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id x21-v6so2924939pln.9 for ; Tue, 20 Nov 2018 17:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ip5GKlJK+Tvv3UFKISb/OTXCKx3eEfj7KBfBZfJCGzE=; b=B1JY3cSS4gMDA2Myv2lUAQh1habtsQdvDbD2Xm+KyiOc3Hxv1IRZSU1/Zt/oHv7frp I9N+LYesi5CFTvlEKtQgKHzpBB3ELE+TX2pCXArvhjq9FM1oc5x2fDLeWRF/jxIn+ukJ wb4dpO0OzIRGhkQx/djoFTkAHN9r+Xq4PhypAmqK+iOQkAcEA994rxe85fXtlTqp3umh 8+WMKIUyzXBpoVWl6onirK4t/qnnHbXaIv+rOg2up/3U0RpXoLIxmdIhMTpTQ6ZjU6Vc tUN0B0f5tm3V6HrNu8qU7jlEhrgTEergCYRuT+Q7WTXCkw6mVoQ72VmWDH62PUavV8lV +P2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ip5GKlJK+Tvv3UFKISb/OTXCKx3eEfj7KBfBZfJCGzE=; b=qk3xKZmhDre6xAAyd3P1DAkFgA921uQc8ojHpTHkuChgVWsvZem9z1Wrg8XPfpaWb/ FUiVBBoa6zUFcw/B/xjUOMWQ2T10H/CT+14JdNYP+jEG9OXEPfEZRXAvKgpyiua6rCsC 6sd8xpexU/oXhoLHp67m1pebJzL/y3ID4QrYhE0cpMI3QcPOImsVGef3yg94qjgeHs+a MbZlb+LNkTDOhL4unH7iCqnDLn01rrQH+6zUMQMZHjQTsAJVRKo0siSzMwezSiTrv9As i93IwNnI84I8sNRyfYjKH8AaUsD9SnRPOBbdjcIyICorKqRcjPwoR2wj/u1iXJc5DbB2 CMOw== X-Gm-Message-State: AA+aEWZUVOw/uDxYRSwWVa78U70h5uYmJ2lGfChSKo7fcW2gUunPqOcT N0Ih/Uc4jdykeUa9In4AJsDEpjGcUS4= X-Google-Smtp-Source: AFSGD/Ujp0vqjxzAohXxrA/0uq/LrBHwfarxOxfJxlVkI/JUpRI+HfB43WdmeolaXw4QyMlFPzpM3w== X-Received: by 2002:a63:8c2:: with SMTP id 185mr4177162pgi.26.1542763522887; Tue, 20 Nov 2018 17:25:22 -0800 (PST) Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com. [209.85.214.181]) by smtp.gmail.com with ESMTPSA id l3sm50711091pga.92.2018.11.20.17.25.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Nov 2018 17:25:21 -0800 (PST) Received: by mail-pl1-f181.google.com with SMTP id gn14so2932853plb.10; Tue, 20 Nov 2018 17:25:21 -0800 (PST) X-Received: by 2002:a17:902:2f03:: with SMTP id s3mr4206945plb.277.1542763521468; Tue, 20 Nov 2018 17:25:21 -0800 (PST) MIME-Version: 1.0 References: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> In-Reply-To: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> From: Roman Shpount Date: Tue, 20 Nov 2018 20:25:11 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="000000000000ab6d8a057b229f8c" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 01:25:26 -0000 --000000000000ab6d8a057b229f8c Content-Type: text/plain; charset="UTF-8" On Tue, Nov 20, 2018 at 7:10 PM Cullen Jennings wrote: > > Sounds like the ice-sip-sdp draft has not concerned itself much with > working with the existing deployed endpoint which treat 0.0.0.0 as a hold > indicator. I think the JSEP solution will work much better in practice. > > This is discussed a bit in > https://tools.ietf.org/html/rfc6337#section-5.4 > > I am familiar with IP4 0.0.0.0 hold and issues it has with ICE, DTLS-SRTP, and recently trickle ICE. The ice-sip-sdp draft did not break anything new. All of this was broken in RFC 5245. None of these new protocols work with endpoints which treat 0.0.0.0 as a hold indicator since all of them need media addresses of both endpoints in order to work. End point cannot use 0.0.0.0 to create a send only stream. Both addresses are still needed to creat it. All of these new protocols assume that endpoints use a=sendonly/a=inactive instead of 0.0.0.0. This is not a major problem in practice, since end points which use 0.0.0.0 hold, do not use ICE or DTLS-SRTP at the same time. These end points will put 0.0.0.0 and will not put candidate or fingerprint attributes for this m= line, which avoids the conflict. If we are being pedantic, it was trickle ICE that decided to re-use 0.0.0.0 hold for other purposes. The ice-sip-sdp simply added that if default candidate is set to 0.0.0.0 and UDP port 9, ICE mismatch is never triggered, which has no effect on using 0.0.0.0 for hold. This language was added to make ice-sip-sdp implementations to be compatible with future trickle ICE implementations. Also, if you are concerned with breaking changes, sdp-bundle changed using port 0 for disabled m= lines, which will likely break a lot of B2BUA, since B2BUA often drop all the attributes from disabled ports. Regards, _____________ Roman Shpount --000000000000ab6d8a057b229f8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 20, 2018 at 7:10 PM Cullen Jennings <fluffy@iii.ca> wrote:

Sounds like the ice-sip-sdp = draft has not concerned itself much with working with the existing deployed= endpoint which treat 0.0.0.0 as a hold indicator. I think the JSEP solutio= n will work much better in practice.=C2=A0

This is discu= ssed a bit in=C2=A0


I am f= amiliar with IP4 0.0.0.0 hold and issues it has with ICE, DTLS-SRTP, and re= cently trickle ICE. The ice-sip-sdp draft did not break anything new. All o= f this was broken in RFC 5245. None of these new protocols work with endpoi= nts which treat 0.0.0.0 as a hold indicator since all of them need media ad= dresses of both endpoints in order to work. End point cannot use 0.0.0.0 to= create a send only stream. Both addresses are still needed to creat it. Al= l of these new protocols assume that endpoints use a=3Dsendonly/a=3Dinactiv= e instead of 0.0.0.0. This is not a major problem in practice, since end po= ints which use 0.0.0.0 hold, do not use ICE or DTLS-SRTP at the same time. = These end points will put 0.0.0.0 and will not put candidate or fingerprint= attributes for this m=3D line, which avoids the conflict.
If we are being pedantic, it was trickle ICE that decided to r= e-use 0.0.0.0 hold for other purposes. The ice-sip-sdp simply added that if= default candidate is set to 0.0.0.0 and UDP port 9, ICE mismatch is never = triggered, which has no effect on using 0.0.0.0 for hold. This language was= added to make ice-sip-sdp implementations to be compatible with future tri= ckle ICE implementations.

Also, if you are concern= ed with breaking changes, sdp-bundle changed using port 0 for disabled m=3D= lines, which will likely break a lot of B2BUA, since B2BUA often drop all = the attributes from disabled ports.

Regards,
= _____________
Roman Shpount
=C2=A0
--000000000000ab6d8a057b229f8c-- From nobody Wed Nov 21 09:54:24 2018 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 ECD2F130DC1 for ; Wed, 21 Nov 2018 09:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 eNz-DHuRmV-h for ; Wed, 21 Nov 2018 09:54:17 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 E633B12426E for ; Wed, 21 Nov 2018 09:54:15 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id n21so4758567qtl.6 for ; Wed, 21 Nov 2018 09:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=FyBOZio50C8y2Nce4D8Xxc5nlSPV76xIBQcIO1yQS4s=; b=J3Ru/vE/zCi7JHJjanqAhT5v2CXq1aokkzfgfJoJtATEvMISVBJMrED4kVEF8no4q/ 9XSrkzRwgt6Ig/1HOjMxA5fdlXa1JdwW5S9sWAE3Werzi4Dep3xLqDFEQwkgpHoB6G+M BnIbfsEm5SYcEF31BTjWDk+0vTgIFNvZpQuvU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=FyBOZio50C8y2Nce4D8Xxc5nlSPV76xIBQcIO1yQS4s=; b=SEUbe6X6/8qW1xouRZtIEVJKy03KS4QB0qeDsUrVeJUAjF/nljLyUDfm8jYUe8JhML wNNWzC9dnzPjIb/NC+Fh2ZX7/OGcoS33tNn9t42/mJ82c3s3269XITm93roOi5hZ9+Lo M/F6wfL//KGqVgFW49irZl/wM8duDWk83XIjsZITyRpqBzFcgB4Z1xPvkMOsRvX6P1vy fPFxolZkJfcgIZ82FWT1tARUp8EfI3PcLD431rz8znwJbJEEbiBIoeuuGMTTBXf3WMGE bkZLhAX35bHNGkzPV/5kCiYh5CdCYmGB19B5DxsDrQHVJ/WTU7IZJLyL4T3pqo+a3hBJ Qv3A== X-Gm-Message-State: AGRZ1gLVHADRxQ+5deun7P+jlxynYo/xfTV+F9qqtfs0yCYXk2VHNDlz amXngoVudJ6YwVye1y7E941r04c5nTE= X-Google-Smtp-Source: AJdET5cPqLP2CgUia1xYy1fYTgGUqGQwF3CtnVs9Qj0PkRa1keMGjxfXKZC/3dHFc2TsQHc8sO6LWQ== X-Received: by 2002:ac8:728f:: with SMTP id v15mr6777458qto.260.1542822854841; Wed, 21 Nov 2018 09:54:14 -0800 (PST) Received: from [172.16.0.18] ([96.231.221.42]) by smtp.gmail.com with ESMTPSA id v50sm31170210qtc.7.2018.11.21.09.54.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 09:54:14 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Message-Id: <0293CF6D-9B4F-4680-BBB9-833C33D03013@sn3rd.com> Date: Wed, 21 Nov 2018 12:54:13 -0500 To: RTCWeb IETF X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: [rtcweb] status: draft-ietf-rtcweb-security-arch X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 17:54:19 -0000 Hi! We are getting to the point where we be able to move = draft-ietf-rtcweb-security-arch (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/) to = our AD for IETF LC. ekr has noted in PR that follows that false start should be prohibited: https://github.com/rtcweb-wg/security-arch/issues/82 If there is any concerns with merging addressing this issue please speak = up. Cheers, stp= From nobody Tue Nov 27 15:14:21 2018 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 9ADF912F1A2; Tue, 27 Nov 2018 15:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.959 X-Spam-Level: X-Spam-Status: No, score=-15.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mhr7_E8PhBX; Tue, 27 Nov 2018 15:14:16 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3259128CFD; Tue, 27 Nov 2018 15:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7422; q=dns/txt; s=iport; t=1543360455; x=1544570055; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=GFBoQiEeK+kSobmGX7EodhKee4s/F+KxPHsWB5p22TA=; b=IIIxRtwNaE+RN87hGqiBoEXKIrkT53YIwkxIiW2r4CxkWpyPuFNvaqh9 8a2lxxNkm9ZGnqsa8Zg0vsRXkP8dNZFnY4Ae4nkMWpLglaLWnKgv9a1ud v/1Y03AtdduGIOyepzJFVrhvHjT6IpOIRcQDEdbIVFkHCm+eHyIPGcYLL U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAABBz/1b/5hdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBggNmgQIng3mUIIINiR2IT4VUgXoNGAE?= =?us-ascii?q?KhANGAoMYIjYHDQEDAQECAQECbRwMhT0BAQEDAQEhSwsQCxgnAwICJx8RBgE?= =?us-ascii?q?MBgIBAReDBgGBdA0PpkWBLx+FIYR0BYwNF4FAP4ERJ4Jrgx4BAQIBhGKCVwK?= =?us-ascii?q?PYzSPdQmGfIMthwEGGIlihymNRopxgU0KJ4FVTSMVO4JsgicXiF6FXSEDMAG?= =?us-ascii?q?LPweCRgEB?= X-IronPort-AV: E=Sophos;i="5.56,288,1539648000"; d="scan'208,217";a="488756962" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Nov 2018 23:14:07 +0000 Received: from [10.155.85.220] (dhcp-10-155-85-220.cisco.com [10.155.85.220]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id wARNE6HZ010362; Tue, 27 Nov 2018 23:14:07 GMT To: Roman Shpount , Cullen Jennings Cc: RTCWeb IETF , mmusic WG References: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> From: Flemming Andreasen Message-ID: <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> Date: Tue, 27 Nov 2018 18:14:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EB4E3FDEE473874975C8865F" Content-Language: en-US X-Outbound-SMTP-Client: 10.155.85.220, dhcp-10-155-85-220.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 27 Nov 2018 23:14:19 -0000 This is a multi-part message in MIME format. --------------EB4E3FDEE473874975C8865F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit It doesn't seem like this thread has reached any conclusion - how do people suggest moving forward here ? Thanks -- Flemming (with MMUSIC co-chair hat on) On 11/20/18 8:25 PM, Roman Shpount wrote: > On Tue, Nov 20, 2018 at 7:10 PM Cullen Jennings > wrote: > > > Sounds like the ice-sip-sdp draft has not concerned itself much > with working with the existing deployed endpoint which treat > 0.0.0.0 as a hold indicator. I think the JSEP solution will work > much better in practice. > > This is discussed a bit in > https://tools.ietf.org/html/rfc6337#section-5.4 > > > I am familiar with IP4 0.0.0.0 hold and issues it has with ICE, > DTLS-SRTP, and recently trickle ICE. The ice-sip-sdp draft did not > break anything new. All of this was broken in RFC 5245. None of these > new protocols work with endpoints which treat 0.0.0.0 as a hold > indicator since all of them need media addresses of both endpoints in > order to work. End point cannot use 0.0.0.0 to create a send only > stream. Both addresses are still needed to creat it. All of these new > protocols assume that endpoints use a=sendonly/a=inactive instead of > 0.0.0.0. This is not a major problem in practice, since end points > which use 0.0.0.0 hold, do not use ICE or DTLS-SRTP at the same time. > These end points will put 0.0.0.0 and will not put candidate or > fingerprint attributes for this m= line, which avoids the conflict. > > If we are being pedantic, it was trickle ICE that decided to re-use > 0.0.0.0 hold for other purposes. The ice-sip-sdp simply added that if > default candidate is set to 0.0.0.0 and UDP port 9, ICE mismatch is > never triggered, which has no effect on using 0.0.0.0 for hold. This > language was added to make ice-sip-sdp implementations to be > compatible with future trickle ICE implementations. > > Also, if you are concerned with breaking changes, sdp-bundle changed > using port 0 for disabled m= lines, which will likely break a lot of > B2BUA, since B2BUA often drop all the attributes from disabled ports. > > Regards, > _____________ > Roman Shpount > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------EB4E3FDEE473874975C8865F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit It doesn't seem like this thread has reached any conclusion - how do people suggest moving forward here ?

Thanks

-- Flemming (with MMUSIC co-chair hat on)



On 11/20/18 8:25 PM, Roman Shpount wrote:
On Tue, Nov 20, 2018 at 7:10 PM Cullen Jennings <fluffy@iii.ca> wrote:

Sounds like the ice-sip-sdp draft has not concerned itself much with working with the existing deployed endpoint which treat 0.0.0.0 as a hold indicator. I think the JSEP solution will work much better in practice. 

This is discussed a bit in 


I am familiar with IP4 0.0.0.0 hold and issues it has with ICE, DTLS-SRTP, and recently trickle ICE. The ice-sip-sdp draft did not break anything new. All of this was broken in RFC 5245. None of these new protocols work with endpoints which treat 0.0.0.0 as a hold indicator since all of them need media addresses of both endpoints in order to work. End point cannot use 0.0.0.0 to create a send only stream. Both addresses are still needed to creat it. All of these new protocols assume that endpoints use a=sendonly/a=inactive instead of 0.0.0.0. This is not a major problem in practice, since end points which use 0.0.0.0 hold, do not use ICE or DTLS-SRTP at the same time. These end points will put 0.0.0.0 and will not put candidate or fingerprint attributes for this m= line, which avoids the conflict.

If we are being pedantic, it was trickle ICE that decided to re-use 0.0.0.0 hold for other purposes. The ice-sip-sdp simply added that if default candidate is set to 0.0.0.0 and UDP port 9, ICE mismatch is never triggered, which has no effect on using 0.0.0.0 for hold. This language was added to make ice-sip-sdp implementations to be compatible with future trickle ICE implementations.

Also, if you are concerned with breaking changes, sdp-bundle changed using port 0 for disabled m= lines, which will likely break a lot of B2BUA, since B2BUA often drop all the attributes from disabled ports.

Regards,
_____________
Roman Shpount
 


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

--------------EB4E3FDEE473874975C8865F-- From nobody Tue Nov 27 15:46:13 2018 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 9212D12F18C; Tue, 27 Nov 2018 15:46:10 -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 w9RT2sgvuAOX; Tue, 27 Nov 2018 15:46:07 -0800 (PST) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::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 AF9FD129C6B; Tue, 27 Nov 2018 15:46:07 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id w13so20957463oiw.9; Tue, 27 Nov 2018 15:46:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bBUDFahBRS8VtMI/9Ic09i/vSR4gw7dQD1aLMyiY5FU=; b=Hq8q/M2uVYgu181NJavNIEWzl7vARPaXdOfUgsff9qN+bDwRv6Nx0NbvSRg/Hhbsex LF3LlZLaelvz1bjQq3+0dL0XfRBXf/uS7kuZ5FzJdAjoyar/R+pB5q8looG5OWX2fvDd yfM5qv7/0S+nRKQFM8INeIrfaUyVQ65CSBqUjfmGbF2RXOnzN0ahaF5lG3kquPrb5bTy XSsqxOLdyds8gfrofE4YCuWWZ8j9v0tCU1jLecVgwJq7huCIiQAGl+aOstQOW3vtBq+z BCiyZaSc7bwIF9dRsbB9PiXquQVb1CkWG3ioGfIR0lpFW6NC7P45wzHZoHP55ZYNGKXO Dexg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bBUDFahBRS8VtMI/9Ic09i/vSR4gw7dQD1aLMyiY5FU=; b=mvT5flhAT3xzXVWGuR+0kklEsr0bUFlW5n1CGZ583Gxka90nBYPKSa0CyqoLyotaTY zBhy+kUDAaKiSJMpBOgzGPdYtrYobPiTqDJM8gKLb/Eei0YnIRBD6v5XR5XLqEeNxVUg LDdSf3cz/ZpUbSrDPoKf0MKxSmt6OA+PzQMDolcqvtWWTzK+gq+c/PKQLWSNLXacjQTy YK6tia8mGE3foHcJz0NpDzpwcCKvdR4f+aWoVRM8yms6+S6s3vvV9ZV3jhFraDkrv1kt WVsenflWzLxq4KWCIgRbNCqKyPwZFNd7jelaHyzWJuGRBQvOewYcA2NqZjA2Ddt3nQhk 3q9w== X-Gm-Message-State: AA+aEWb3LdVTuqSf8uHy1uHWqpGWWRFHw/DD/d80A2ApD96Y9caJdUa6 gqHYGhuK5X14bUp82yq8Zz3rSOr4lAFChU09oaQ= X-Google-Smtp-Source: AFSGD/V/zzKyJHs0bI9/gdi6mMaxEZ6dn3lf1DgUAzzvqaQq8SOiqJmM9Vw+ygGY1QX0sAOiuXuK8JcxD8lCWZSUFNE= X-Received: by 2002:aca:60c1:: with SMTP id u184mr1783283oib.45.1543362366571; Tue, 27 Nov 2018 15:46:06 -0800 (PST) MIME-Version: 1.0 References: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> In-Reply-To: <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> From: Ted Hardie Date: Tue, 27 Nov 2018 15:45:39 -0800 Message-ID: To: Flemming Andreasen , Adam Roach Cc: Roman Shpount , Cullen Jennings , RTCWeb IETF , mmusic@ietf.org Content-Type: multipart/alternative; boundary="0000000000009e893f057bae0d92" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 27 Nov 2018 23:46:11 -0000 --0000000000009e893f057bae0d92 Content-Type: text/plain; charset="UTF-8" >From the RTCWEB perspective, allowing the current JSEP behavior to remain and making adjustments to draft-ice-sip-sdp is preferable. I've cc'ed Adam on this message, because I believe he may ultimately need to weigh in on the way forward. Ted On Tue, Nov 27, 2018 at 3:14 PM Flemming Andreasen wrote: > It doesn't seem like this thread has reached any conclusion - how do > people suggest moving forward here ? > > Thanks > > -- Flemming (with MMUSIC co-chair hat on) > > > > On 11/20/18 8:25 PM, Roman Shpount wrote: > > On Tue, Nov 20, 2018 at 7:10 PM Cullen Jennings wrote: > >> >> Sounds like the ice-sip-sdp draft has not concerned itself much with >> working with the existing deployed endpoint which treat 0.0.0.0 as a hold >> indicator. I think the JSEP solution will work much better in practice. >> >> This is discussed a bit in >> https://tools.ietf.org/html/rfc6337#section-5.4 >> >> > I am familiar with IP4 0.0.0.0 hold and issues it has with ICE, DTLS-SRTP, > and recently trickle ICE. The ice-sip-sdp draft did not break anything new. > All of this was broken in RFC 5245. None of these new protocols work with > endpoints which treat 0.0.0.0 as a hold indicator since all of them need > media addresses of both endpoints in order to work. End point cannot use > 0.0.0.0 to create a send only stream. Both addresses are still needed to > creat it. All of these new protocols assume that endpoints use > a=sendonly/a=inactive instead of 0.0.0.0. This is not a major problem in > practice, since end points which use 0.0.0.0 hold, do not use ICE or > DTLS-SRTP at the same time. These end points will put 0.0.0.0 and will not > put candidate or fingerprint attributes for this m= line, which avoids the > conflict. > > If we are being pedantic, it was trickle ICE that decided to re-use > 0.0.0.0 hold for other purposes. The ice-sip-sdp simply added that if > default candidate is set to 0.0.0.0 and UDP port 9, ICE mismatch is never > triggered, which has no effect on using 0.0.0.0 for hold. This language was > added to make ice-sip-sdp implementations to be compatible with future > trickle ICE implementations. > > Also, if you are concerned with breaking changes, sdp-bundle changed using > port 0 for disabled m= lines, which will likely break a lot of B2BUA, since > B2BUA often drop all the attributes from disabled ports. > > Regards, > _____________ > Roman Shpount > > > > _______________________________________________ > mmusic mailing listmmusic@ietf.orghttps://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000009e893f057bae0d92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
From the RTCWEB perspective, allowing the current JSE= P behavior to remain and making adjustments to draft-ice-sip-sdp is preferable. I've = cc'ed Adam on this message, because I believe he may ultimately need to= weigh in on the way forward.

Ted

On = Tue, Nov 27, 2018 at 3:14 PM Flemming Andreasen <fandreas@cisco.com> wrote:
=20 =20 =20
It doesn't seem like this thread has reached any conclusion - how d= o people suggest moving forward here ?

Thanks

-- Flemming (with MMUSIC co-chair hat on)



On 11/20/18 8:25 P= M, Roman Shpount wrote:
=20
On Tue, Nov 20, 2018 at 7:10 PM Cullen Jennings <fluffy@iii.ca> wrote:

Sounds like the ice-sip-sdp draft has not concerned itself much with working with the existing deployed endpoint which treat 0.0.0.0 as a hold indicator. I think the JSEP solution will work much better in practice.=C2=A0

This is discussed a bit in=C2=A0


I am familiar with IP4 0.0.0.0 hold and issues it has with ICE, DTLS-SRTP, and recently trickle ICE. The ice-sip-sdp draft did not break anything new. All of this was broken in RFC 5245. None of these new protocols work with endpoints which treat 0.0.0.0 as a hold indicator since all of them need media addresses of both endpoints in order to work. End point cannot use 0.0.0.0 to create a send only stream. Both addresses are still needed to creat it. All of these new protocols assume that endpoints use a=3Dsendonly/a=3Dinactive instead of 0.0.0.0. This is not a major problem in practice, since end points which use 0.0.0.0 hold, do not use ICE or DTLS-SRTP at the same time. These end points will put 0.0.0.0 and will not put candidate or fingerprint attributes for this m=3D line, which avoids the conflict.

If we are being pedantic, it was trickle ICE that decided to re-use 0.0.0.0 hold for other purposes. The ice-sip-sdp simply added that if default candidate is set to 0.0.0.0 and UDP port 9, ICE mismatch is never triggered, which has no effect on using 0.0.0.0 for hold. This language was added to make ice-sip-sdp implementations to be compatible with future trickle ICE implementations.

Also, if you are concerned with breaking changes, sdp-bundle changed using port 0 for disabled m=3D lines, which will likely break a lot of B2BUA, since B2BUA often drop all the attributes from disabled ports.

Regards,
_____________
Roman Shpount
=C2=A0


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

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000009e893f057bae0d92-- From nobody Tue Nov 27 15:47:00 2018 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 21E13128CFD for ; Tue, 27 Nov 2018 15:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLKJ-BcT0uvf for ; Tue, 27 Nov 2018 15:46:39 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 776B7130DEE for ; Tue, 27 Nov 2018 15:46:39 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id w73so9182212pfk.10 for ; Tue, 27 Nov 2018 15:46:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E4nMhy4EruYfBN5dPyQhH6xzNxySodXrkKbvDFLr+Xc=; b=rdsfZWkfaCJmy/cqQcgq4nzFMS2Y223p76hOsStWC8NGPeNOKCiSJbWjJ82cO3Hfgf JnJHgvguwvLYXsFew6xl/Ckg2oVjJiujUfKvZGco0Lp+rTwI9xukmRosP2h/2soHHV8U h1JfgcjljI/Y0MIGg8Sg8zj3ApW1rOZeIosP/kfT/FHOBMCyMt5IMcNYNn8JUJYgI/iH pBiZwoNU4NxIb02d1tCxEyT0vLg2niv0lehYatiQQ3cQ66HkC8oleA110AnXU8XIh65t UfYsHXCIdZWBDUmN4u8Hz8VFBPXcCkt1MAVWwz4cy1lkSoe42fP1wO4KX1xUSdipRyIs fqyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E4nMhy4EruYfBN5dPyQhH6xzNxySodXrkKbvDFLr+Xc=; b=S50wc6k2Jdz1praXEZgGS1iEYhNyhULvq1gJncgy6AcUwb7y8QQbTU3nDBlxSoFCKz 9s4wv+cYZGvUxqU8mTJ1Z/DWg/FwWNVld64nAo7jsZobQ3LKOriPMTLMWAENgrNlPFQc BwJtuEDL/N4O5oTb+v+/xkmK6NdEj2WeTejGNdNHlOODAMMfBwxG8awnZ5s1vmFPoIaK Q9XxY/rP75Posm6fFYqH2emcT2cM6q+CR3PmoXgXsLecIStE9a8Yjo/rP+4GrLG2GwJF /yxR+F6noO381+G2Aj2MLBfZZqzz65xtmafRyBZ4U/QnJMppfUJ/ZaLenvhbi2IOsBHi ze3w== X-Gm-Message-State: AGRZ1gItLEUjfy8Bor9eD259Pm9RgugYh5PS6NPt3nRJpCBYF+ndc656 6x6ONg/g6UNc/4YN0pfEcFdr8tjNGPk= X-Google-Smtp-Source: AJdET5eTRjNWbsWGQndCYHkB+Evdyvh/hjGf94y2+50pMSrsxiqcAmFgpa6ndd/HTZEDvwXD1w5n/w== X-Received: by 2002:a62:19d5:: with SMTP id 204mr35159173pfz.33.1543362398836; Tue, 27 Nov 2018 15:46:38 -0800 (PST) Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com. [209.85.215.169]) by smtp.gmail.com with ESMTPSA id s84sm12112400pfi.15.2018.11.27.15.46.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 15:46:38 -0800 (PST) Received: by mail-pg1-f169.google.com with SMTP id w6so8597083pgl.6; Tue, 27 Nov 2018 15:46:38 -0800 (PST) X-Received: by 2002:a63:df13:: with SMTP id u19mr31304401pgg.294.1543362397940; Tue, 27 Nov 2018 15:46:37 -0800 (PST) MIME-Version: 1.0 References: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> In-Reply-To: <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> From: Roman Shpount Date: Tue, 27 Nov 2018 18:46:26 -0500 X-Gmail-Original-Message-ID: Message-ID: To: lemming Andreasen Cc: Cullen Jennings , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="0000000000007d35f3057bae0f4d" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 27 Nov 2018 23:46:52 -0000 --0000000000007d35f3057bae0f4d Content-Type: text/plain; charset="UTF-8" Hi Flemming, On Tue, Nov 27, 2018 at 6:14 PM Flemming Andreasen wrote: > It doesn't seem like this thread has reached any conclusion - how do > people suggest moving forward here ? > > During this discussion I had a chance to think about this issue quite a bit and I would suggest the following solution: As far as I can see, RFC 5245, ice-sip-sdp, jsep-25 section-5.2.2, sctp-sdp, rand fc4583bis all differentiate between initial offer/answer exchange which initiates ICE restart and subsequent offer/answer exchanges which do not. All these documents specify that UDP based m= line proto SHOULD be used during ICE restart and that proto MUST match the only ICE candidate present when not doing ICE restart. The only place that does not differentiate between the two is JSEP Section 5.1.2. This section tries to simplify things and apply the same rule to both exchanges saying that "UDP/TLS/RTP/SAVPF" proto MUST always be used. This is the root cause of the current issue. I suggest to update JSEP section 5.1.2 to match the rest of the documents to say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE restart. When ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto MUST be used if default (only) candidate is a UDP candidate and "TCP/TLS/RTP/SAVPF" proto MUST be used if default (only) candidate is TCP candidate. While discussing the current issue, I see that there is something that can be clarified in ice-sip-sdp and potentially in JSEP. Specifically it make sense to specify better what to do during ICE restart when UDP based proto is used in the m= line, as it is recommended, but the only candidates collected are TCP. This can happen in WebRTC implementations due to trickle ICE, if only TCP candidates are collected initially. Outside of WebRTC this can happen due to the client generating an answer being configured to collect only TCP based candidates (Microsoft ICE implementation guide lists such use case specifically). I think in such cases, if no ICE candidates match the proto in the m= line, then address IN IP4 0.0.0.0 should be used in the c= line and port 9 should be used in the m= line. This is consistent with current behavior of trickle ICE when no candidates have been collected. In any case, it looks to me that only JSEP section 5.1.2 needs to be modified to make all the current documents consistent. JSEP is already being modified to fix this issue, so I would suggest to modify it in a way that will cause the least disruption. If needed I can provide the pull request to fix this. Regards, _____________ Roman Shpount --0000000000007d35f3057bae0f4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Flemming,

On Tue, Nov 27, 2018 at 6:14 PM Flemming= Andreasen <fandreas@cisco.com= > wrote:
=20 =20 =20
It doesn't seem like this thread has reached any conclusion - how d= o people suggest moving forward here ?

During this discussion I had a chance to think about this issu= e quite a bit and I would suggest the following solution:

As far as I can see, RFC 5245, ice-sip-sdp, jsep-25 section-5.2.2, sctp-sdp, rand fc4583bis all differentiate between initi= al offer/answer exchange which initiates ICE restart and subsequent offer/a= nswer exchanges=C2=A0which do not. All these documents specify that UDP bas= ed m=3D line proto SHOULD be used during ICE restart and that proto MUST ma= tch the only ICE candidate present when not doing ICE restart. The only pla= ce that does not differentiate=C2=A0between the two is JSEP Section 5.1.2. = This section tries to simplify things and apply the same rule to both excha= nges saying that=C2=A0 "UDP/TLS/RTP/SAVPF" proto MUST a= lways be used. This is the root=C2=A0cause o= f the current issue. I suggest to update JSEP section 5.1.2 to match the re= st of the documents to say that=C2=A0"UDP/TLS/RTP/SAVPF" proto MUST be used during ICE restart. When= ICE restart is not in progress,=C2=A0"UDP/TLS/RTP/SAVPF" pr= oto MUST be used if default (only) candidate is a UDP candidate and=C2=A0"TCP/TLS/RTP/SAVPF"=C2=A0proto MUST be used if default (only) = candidate is TCP candidate.

While discussing the current issue, I see that there is something = that can be clarified in ice-sip-sdp and potentially in JSEP. Specifically = it make sense to specify better what to do during ICE restart when UDP base= d proto is used in the m=3D line, as it is recommended, but the only candid= ates collected are TCP. This can happen in WebRTC implementations due to tr= ickle ICE, if only TCP candidates are collected initially. Outside of WebRT= C this can happen due to the client generating an answer being configured t= o collect only TCP based candidates (Microsoft ICE implementation guide lis= ts such use case specifically). I think in such cases, if no ICE candidates= match the proto in the m=3D line, then address IN IP4 0.0.0.0 should be us= ed in the c=3D line and port 9 should be used in the m=3D line. This is con= sistent with current behavior of trickle ICE when no candidates have been c= ollected.

In any case, it looks to me that only JSEP section 5.1.2 needs t= o be modified to make all the current documents consistent. JSEP is already= being modified to fix this issue, so I would suggest to modify it in a way= that will cause the least disruption. If needed I can provide the pull req= uest to fix this.

Regards,
_____________
Roman= Shpount
=C2=A0
--0000000000007d35f3057bae0f4d-- From nobody Tue Nov 27 15:48:05 2018 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 ED0BC130DED for ; Tue, 27 Nov 2018 15:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqcbHuOXDffC for ; Tue, 27 Nov 2018 15:47:55 -0800 (PST) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 DA02A130DF3 for ; Tue, 27 Nov 2018 15:47:54 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id y126so1307831pfb.4 for ; Tue, 27 Nov 2018 15:47:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8TvRam3LvNXJ1sjwKvlSBuEf3QWkccFbbj06Ur5j94A=; b=iNabaCdYUizf8uElrE0mETcKMwCh/6in2oDtGYd0prUYigJHNhJePyzmdr7bvxVNQN CqPnkj5PZtr9BJ7EhDM1NALsqJRyg2SAIaUMI8Kc/Kd8ooddwPYR1bCyfinKIK70Re5L MZOP1n49Dm+Ww5/fVdHJeaBNZoTdrCle+h2tZZYyeTfK0t61Gdzccn2Q49A3qbMoREef +rjsMRm9nrhRS92H6QuXrgzbD2+shLwSr4gCrn9i10vMIcnWc0Z1Rp2pO3q+YjUchzvt UzxWErc89qSa47JhvvCR+Y7bPJJCbR0Bfou/kb4fukzmn2NE6N68mBx0GG1o12ZrtvmS JNPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8TvRam3LvNXJ1sjwKvlSBuEf3QWkccFbbj06Ur5j94A=; b=rrCFZQOGSLFlOaMi/4DhVx4BYnCUvu71qtDdYBzRbzqi+OWOgZmpXdTBktOqAsaXHM dVQzeKGOJa61br4lKIeXB00GTKHM+udQ4wqEkLSw4cK12y8Oj63nlJw7AWvvB6SvWHvX ZCiIVUI7w9i++wP4vXTxU6UNwh9C7wYUA5/U7bqkGUbyX9yATrzItfWfPYxJ1fzKcqj/ IG3YkwSCloNZNyX9fICO0GJynE23XSvdKBe0k54KnJWYCk0YTiqtW9miNHfS6Z9iC6yX iQSA0lCrKg26c5psh3MPDB+mzPuiSxQ0qOkFQeiUtpyg9VfrLLXxxfvB/9g1V9PNIuXu +cZQ== X-Gm-Message-State: AGRZ1gJOEDCmqQk+Hz9XLP+zbGDUMoxfFvnh21EB5hcy9gVhy7Oxl63N eJg1PQZZyoxt1Gdwfkvh99Osk/9ZeDQ= X-Google-Smtp-Source: AJdET5e9TjTq6+pjKakFOvjQXXIKzKbYqDplVT1aBrm1hjE/pnXLu8lLG65nE/tT/45f6Kr99ZQeEQ== X-Received: by 2002:a62:c683:: with SMTP id x3mr34475505pfk.10.1543362474406; Tue, 27 Nov 2018 15:47:54 -0800 (PST) Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com. [209.85.214.169]) by smtp.gmail.com with ESMTPSA id r130sm9062748pfr.48.2018.11.27.15.47.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 15:47:53 -0800 (PST) Received: by mail-pl1-f169.google.com with SMTP id gn14so16408198plb.10; Tue, 27 Nov 2018 15:47:53 -0800 (PST) X-Received: by 2002:a17:902:981:: with SMTP id 1mr20393833pln.142.1543362473462; Tue, 27 Nov 2018 15:47:53 -0800 (PST) MIME-Version: 1.0 References: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> In-Reply-To: From: Roman Shpount Date: Tue, 27 Nov 2018 18:47:41 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Ted Hardie Cc: lemming Andreasen , Adam Roach - SIPCORE Chair , Cullen Jennings , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="000000000000fd93e5057bae13cb" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 27 Nov 2018 23:47:57 -0000 --000000000000fd93e5057bae13cb Content-Type: text/plain; charset="UTF-8" On Tue, Nov 27, 2018 at 6:46 PM Ted Hardie wrote: > From the RTCWEB perspective, allowing the current JSEP behavior to remain > and making adjustments to draft-ice-sip-sdp is preferable. I've cc'ed > Adam on this message, because I believe he may ultimately need to weigh in > on the way forward. > >> >> Which one? JSEP-25 currently specifies two contradictory things in sections 5.1.2 and 5.2.2. Regards, _____________ Roman Shpount --000000000000fd93e5057bae13cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 27, 2018 at 6:46 PM Ted Hardie <ted.ietf@gmail.com> wrote:
From the RTCWEB perspective, allowing the current JSEP behavi= or to remain and making adjustments to draft-ice-sip-sdp is prefera= ble. I've cc'ed Adam on this message, because I believe he may ulti= mately need to weigh in on the way forward.

=

Which one? JSEP-25 currently specifies two= contradictory things in sections 5.1.2 and 5.2.2.

Regards,
_____________
Roman Shpount
=C2=A0
--000000000000fd93e5057bae13cb-- From nobody Wed Nov 28 08:38:54 2018 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 650671277C8 for ; Wed, 28 Nov 2018 08:38:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8y5kYdFr_r8a for ; Wed, 28 Nov 2018 08:38:45 -0800 (PST) Received: from smtp73.iad3b.emailsrvr.com (smtp73.iad3b.emailsrvr.com [146.20.161.73]) (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 D90FE1277BB for ; Wed, 28 Nov 2018 08:38:44 -0800 (PST) Received: from smtp10.relay.iad3b.emailsrvr.com (localhost [127.0.0.1]) by smtp10.relay.iad3b.emailsrvr.com (SMTP Server) with ESMTP id 7C99AE0638; Wed, 28 Nov 2018 11:38:43 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp10.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id D362EE0596; Wed, 28 Nov 2018 11:38:42 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Wed, 28 Nov 2018 11:38:43 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_622469F8-31C7-4146-AA04-F3992D2809D2" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Cullen Jennings In-Reply-To: Date: Wed, 28 Nov 2018 09:38:41 -0700 Cc: Flemming Andreasen , RTCWeb IETF , mmusic WG Message-Id: <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca> References: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> To: Roman Shpount X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 28 Nov 2018 16:38:48 -0000 --Apple-Mail=_622469F8-31C7-4146-AA04-F3992D2809D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 27, 2018, at 4:46 PM, Roman Shpount wrote: >=20 > I suggest to update JSEP section 5.1.2 to match the rest of the = documents to say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE = restart. When ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto = MUST be used if default (only) candidate is a UDP candidate and = "TCP/TLS/RTP/SAVPF" proto MUST be used if default (only) candidate is = TCP candidate. I don=E2=80=99t see any real befits to implementations to this change = and I don=E2=80=99t think the rtcweb consensus was around the currently = solution. Do you see some advantage to implementations to this?= --Apple-Mail=_622469F8-31C7-4146-AA04-F3992D2809D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 27, 2018, at 4:46 PM, Roman Shpount <roman@telurix.com> = wrote:

 I suggest to update JSEP = section 5.1.2 to match the rest of the documents to say = that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE = restart. When ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto = MUST be used if default (only) candidate is a UDP candidate = and "TCP/TLS/RTP/SAVPF" proto = MUST be used if default (only) candidate is TCP = candidate.

I= don=E2=80=99t see any real befits to implementations to this change and = I don=E2=80=99t think the rtcweb consensus was around the currently = solution. Do you see some advantage to implementations to = this?
= --Apple-Mail=_622469F8-31C7-4146-AA04-F3992D2809D2-- From nobody Wed Nov 28 08:57:30 2018 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 E527F130E88 for ; Wed, 28 Nov 2018 08:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.347 X-Spam-Level: X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxrGNO5TM4AG for ; Wed, 28 Nov 2018 08:57:26 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 9D1BB130E72 for ; Wed, 28 Nov 2018 08:57:26 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id d72so9744945pga.9 for ; Wed, 28 Nov 2018 08:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mSRpCMsmgdpyplRCPGUB0xBEmk2a7sdI7jIvTNkML1A=; b=PoHIqzIRo/Vz5EQnjJJD8at5U9Gw3ldGLLzXjLFNeJ9+XvC5xM1G+tO+Tj3ps9xT24 +EOM2AdC8qaZMLHMRMmkDkIsdFlF/HFNA1ZYf7H22mmOFA5bt30VyLzdcMylgQ1P3aHH zXYcEN0wZiksDWsZywm7bov8eh+0JYsZJ07OJcbZ5OJ0myAH4Dx6NDiN+Yx6w1JV03b4 Nf+NG+v8y2xp8VcZtkQpse+XvXyITKp/dV5vXRfBccy6BgAA87sizsMbjS8uESehWH2B rLRDqsD1C5yPxxvEt+2HgJidLhNdW8i9okmAILTQ2UC/6mDw2mSMK4BE7vvX2NIaGc7F a8og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mSRpCMsmgdpyplRCPGUB0xBEmk2a7sdI7jIvTNkML1A=; b=LbNsWECUYqpf0bxHlsYDRPE7ql8EOY9mmXcjCvqD+n22nzgxxsA1pkbiC1xz/KDk9d wqZV5S9sk1UZ/P8Eo+yyM8kAJbCwA0QwX1ldmtiiIOztOfFrXMSD3eaEU+qzaPa6L6jh 2bmdpBJA+RUAvO8Voel80DCZN2neq6Yc1J0JeDIKymPHbqbSS4GlcINuLKQRkPnciCaj qcFWhe+xlghQL4FZmWF5gyOwgiVT9EcUCGU/YnNiuO9tuVwA6YCdFg8RS2Iqt/itri3F wTfnHW4hdQBBCbtP4xTyC9O6GqkA2e78GYnq/xFvbQCmcrnSvKYkFl5DU1U8/tIdoQvn 7wlg== X-Gm-Message-State: AA+aEWYvPRzm/ExTyKCL7k0D7UWdp2iXinZAA7AwVz5pfUztbQwnx2lS lJ9LHkQSq0+A7WbRpVlPTWvmqaa859Q= X-Google-Smtp-Source: AFSGD/XDhQ3dwJAl0Y5VnoW8Qsd0HHgXtuLr5vQrJnIptxon7MqWh/2EpQY19kbX4hk41aTQ/ncEkQ== X-Received: by 2002:a62:6b85:: with SMTP id g127mr11107344pfc.42.1543424246150; Wed, 28 Nov 2018 08:57:26 -0800 (PST) Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com. [209.85.210.182]) by smtp.gmail.com with ESMTPSA id w11sm7309429pgk.16.2018.11.28.08.57.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Nov 2018 08:57:25 -0800 (PST) Received: by mail-pf1-f182.google.com with SMTP id c72so10448164pfc.6; Wed, 28 Nov 2018 08:57:24 -0800 (PST) X-Received: by 2002:a63:b4c:: with SMTP id a12mr34432396pgl.131.1543424244652; Wed, 28 Nov 2018 08:57:24 -0800 (PST) MIME-Version: 1.0 References: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca> In-Reply-To: <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca> From: Roman Shpount Date: Wed, 28 Nov 2018 11:57:13 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: lemming Andreasen , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="000000000000d72304057bbc75db" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 28 Nov 2018 16:57:29 -0000 --000000000000d72304057bbc75db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings wrote: > On Nov 27, 2018, at 4:46 PM, Roman Shpount wrote: > > I suggest to update JSEP section 5.1.2 to match the rest of the > documents to say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE > restart. When ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto > MUST be used if default (only) candidate is a UDP candidate and > "TCP/TLS/RTP/SAVPF" proto MUST be used if default (only) candidate is TCP > candidate. > > > I don=E2=80=99t see any real befits to implementations to this change and= I don=E2=80=99t > think the rtcweb consensus was around the currently solution. Do you see > some advantage to implementations to this? > This is what every other document related to ICE, including JSEP section 5.2.2 currently specifies. It was also consensus in MMUSIC. I think RTCWEB need a really good reason why it needs to be different. Also, if we are not going to do this, then every ICE implementation for RTCWEB would be different from every other ICE implementation. For instance, without this change, when ICE TCP candidate is selected, WebRTC compliant implementation MUST use UDP/TLS/RTP/SAVPF in subsequent offer/answer exchanges, but it MUST use TCP/TLS/RTP/SAVPF in the same case when communicating with VoIP phone. It would be very hard to change this behavior in ice-sip-sdp, since it will make it incompatible with RFC5245m so this difference is likely to be permanent. Regards, _____________ Roman Shpount --000000000000d72304057bbc75db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings &= lt;fluffy@iii.ca> wrote:
<= /div>
On Nov 27, 2018, at 4:46 PM, Roman Shpount <roman@telurix.com> wrote:=

=C2=A0I suggest to update JSEP section 5.1.2 to match the rest of= the documents to say that=C2=A0"UDP/TLS/= RTP/SAVPF" proto MUST be used during ICE restart. When ICE restart is = not in progress,=C2=A0"UDP/TLS/RTP/SAVPF&= quot;=C2=A0proto MUST be used if default (only) candida= te is a UDP candidate and=C2=A0"TCP/TLS/R= TP/SAVPF"=C2=A0proto MUST be used if defa= ult (only) candidate is TCP candidate.

<= div>I don=E2=80=99t see any real befits to implementations to this change a= nd I don=E2=80=99t think the rtcweb consensus was around the currently solu= tion. Do you see some advantage to implementations to this?

This is what every other document related to I= CE, including JSEP section 5.2.2 currently specifies. It was also consensus= in MMUSIC. I think RTCWEB need a really good reason why it needs to be dif= ferent.

Also, if we are not going to do this, then= every ICE implementation for RTCWEB would be different from every other IC= E implementation. For instance, without this change, when ICE TCP candidate= is selected, WebRTC compliant implementation MUST use UDP/TLS/RTP/SAVPF in= subsequent offer/answer exchanges, but it MUST use TCP/TLS/RTP/SAVPF in th= e same case when communicating with VoIP phone. It would be very hard to ch= ange this behavior in ice-sip-sdp, since it will make it incompatible with = RFC5245m so this difference is likely to b= e permanent.

<= /div>
Regards,
______= _______
Roman Shpount
=C2=A0
--000000000000d72304057bbc75db-- From nobody Wed Nov 28 10:22:57 2018 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 AEDEE130E8B; Wed, 28 Nov 2018 10:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 tduxKwfoFCY5; Wed, 28 Nov 2018 10:22:54 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DDFF130E6E; Wed, 28 Nov 2018 10:22:54 -0800 (PST) Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wASIMoJM005405 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 28 Nov 2018 12:22:52 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at To: Roman Shpount , Cullen Jennings Cc: RTCWeb IETF , mmusic WG References: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca> From: Adam Roach Message-ID: <110dc822-b3be-7bc2-dcc5-9e6c8277e0d1@nostrum.com> Date: Wed, 28 Nov 2018 12:22:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------121809D2425E31FF0A2953BA" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 28 Nov 2018 18:22:56 -0000 This is a multi-part message in MIME format. --------------121809D2425E31FF0A2953BA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/28/18 10:57 AM, Roman Shpount wrote: > On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings > wrote: > >> On Nov 27, 2018, at 4:46 PM, Roman Shpount > > wrote: >> >> I suggest to update JSEP section 5.1.2 to match the rest of the >> documents to say that "UDP/TLS/RTP/SAVPF" proto MUST be used >> during ICE restart. When ICE restart is not in progress, >> "UDP/TLS/RTP/SAVPF"proto MUST be used if default (only) candidate >> is a UDP candidate and "TCP/TLS/RTP/SAVPF" proto MUST be used if >> default (only) candidate is TCP candidate. > > I don’t see any real befits to implementations to this change and > I don’t think the rtcweb consensus was around the currently > solution. Do you see some advantage to implementations to this? > > > This is what every other document related to ICE, including JSEP > section 5.2.2 currently specifies. It was also consensus in MMUSIC. I > think RTCWEB need a really good reason why it needs to be different. It would probably help clarify things if you quoted the parts of the document that you think are in conflict. I can't find any explicit field handling in 5.2.2. In terms of changing technical aspects of JSEP: the only reason the document is out of the RFC Editor's queue right now is to address issues arising from rationalizing the reference to RFC 8445 within Cluster 238. This is not an opportunity to re-litigate previously settled consensus decisions. Technical issues such as the one at hand should have been raised during WG development, WG last call, or -- in extremis, since you're a regular RTCWEB participant -- during IETF last call. It's up to the chairs what to allow, but I wouldn't expect anything other than catastrophic flaws to be open for change at this time. /a --------------121809D2425E31FF0A2953BA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 11/28/18 10:57 AM, Roman Shpount wrote:
On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings <fluffy@iii.ca> wrote:
On Nov 27, 2018, at 4:46 PM, Roman Shpount <roman@telurix.com> wrote:

 I suggest to update JSEP section 5.1.2 to match the rest of the documents to say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE restart. When ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto MUST be used if default (only) candidate is a UDP candidate and "TCP/TLS/RTP/SAVPF" proto MUST be used if default (only) candidate is TCP candidate.

I don’t see any real befits to implementations to this change and I don’t think the rtcweb consensus was around the currently solution. Do you see some advantage to implementations to this?

This is what every other document related to ICE, including JSEP section 5.2.2 currently specifies. It was also consensus in MMUSIC. I think RTCWEB need a really good reason why it needs to be different.


It would probably help clarify things if you quoted the parts of the document that you think are in conflict. I can't find any explicit <proto> field handling in 5.2.2.

In terms of changing technical aspects of JSEP: the only reason the document is out of the RFC Editor's queue right now is to address issues arising from rationalizing the reference to RFC 8445 within Cluster 238. This is not an opportunity to re-litigate previously settled consensus decisions. Technical issues such as the one at hand should have been raised during WG development, WG last call, or -- in extremis, since you're a regular RTCWEB participant -- during IETF last call. It's up to the chairs what to allow, but I wouldn't expect anything other than catastrophic flaws to be open for change at this time.

/a

--------------121809D2425E31FF0A2953BA-- From nobody Wed Nov 28 10:41:50 2018 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 17C8C130E6E for ; Wed, 28 Nov 2018 10:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.347 X-Spam-Level: X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OPWt-o3o0rk for ; Wed, 28 Nov 2018 10:41:46 -0800 (PST) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 62B31128A6E for ; Wed, 28 Nov 2018 10:41:46 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id 64so10580250pfr.9 for ; Wed, 28 Nov 2018 10:41:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R3hh6//wPHoinKxpPWYkR3cn2zANO0QrrSmXxKFJKtY=; b=jItogfNeet3Mk7jrbsvgzVEsc+Ao/EGkaiWGSL7raOxSipENtTSCrWq/YEXS4d4Hc+ KOODAhEHhIkhwNLA+SUhvjZn3Xefe9JGpPTgD6AioZiEkoTSQQpyaQNxmJoumztkVbau cgoZiBEhgK0j8xlIpbEr74gGqV0OOE38WeraBV+xsgD3WriVksBiv3wydjrJ2nG4OAKB Df+96Yu73w98Qh00TZLzSQaSa7KVSRAFgaLYnS7XfUiscGWl1ugUizFLsEzaFnA3bVEr qvxJOKILKPU+gpaFw7AV458dnfp/3bhiJ4B2FvqSaIwbwMNlpcAxWD9rFslpL2zah+yJ uTZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R3hh6//wPHoinKxpPWYkR3cn2zANO0QrrSmXxKFJKtY=; b=ZF3SQ/P0ub7UgqmNirFOpLFWzcZaOOwo6N4dtctL/ZgiDP8gNsHgirLRxqZ2Uf7WH+ KvcoNOL2umJA5HwIvR7VGjQJs4y+vKw/lzA3jKy+fErRmLF5JFmOUodpxCPB8IPfuYy6 nsK37qeQqBybRSG2/0ncNEmDQKhkR/Ho8z1JFefq19WD//gp87YiZYoSL6e/OnxWJnrT Rgj0s7in2dEaP9FVi468vAeCO/t9Ol71M8hqzczYx8J5J/ATfnk8jOYZ+rins7sZN5K6 ZEcqsNhggWQx1muMZkpfGu4s26Ti2FX4fNmom+eTX64s1Tdb+QXlPPEdaeV3jmw6Pfgp US9Q== X-Gm-Message-State: AA+aEWbwACBZn9zJBMlUh1s0kkUIwInVw3WvMKHZGj+EtohD7Di8xwLi ZnAsd3QgLcOlyrH1a3+B/rRXLhOkabs= X-Google-Smtp-Source: AFSGD/Xf2tE0mxQpwyxJaab52Lo61DGu1k5oDDD2wolpmQM/C00jRK1rqq5NUYdMU34qpvnCloV6Ng== X-Received: by 2002:a63:d818:: with SMTP id b24mr33501512pgh.174.1543430505760; Wed, 28 Nov 2018 10:41:45 -0800 (PST) Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com. [209.85.210.172]) by smtp.gmail.com with ESMTPSA id q7sm7747760pgp.40.2018.11.28.10.41.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Nov 2018 10:41:44 -0800 (PST) Received: by mail-pf1-f172.google.com with SMTP id q1so10599647pfi.5; Wed, 28 Nov 2018 10:41:44 -0800 (PST) X-Received: by 2002:a62:4714:: with SMTP id u20mr4192641pfa.144.1543430504493; Wed, 28 Nov 2018 10:41:44 -0800 (PST) MIME-Version: 1.0 References: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca> <110dc822-b3be-7bc2-dcc5-9e6c8277e0d1@nostrum.com> In-Reply-To: <110dc822-b3be-7bc2-dcc5-9e6c8277e0d1@nostrum.com> From: Roman Shpount Date: Wed, 28 Nov 2018 13:41:33 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Adam Roach - SIPCORE Chair Cc: Cullen Jennings , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="000000000000f4b86f057bbdeac0" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 28 Nov 2018 18:41:49 -0000 --000000000000f4b86f057bbdeac0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adam, On Wed, Nov 28, 2018 at 1:22 PM Adam Roach wrote: > > On 11/28/18 10:57 AM, Roman Shpount wrote: > > On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings wrote: > >> On Nov 27, 2018, at 4:46 PM, Roman Shpount wrote: >> >> I suggest to update JSEP section 5.1.2 to match the rest of the >> documents to say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE >> restart. When ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto >> MUST be used if default (only) candidate is a UDP candidate and >> "TCP/TLS/RTP/SAVPF" proto MUST be used if default (only) candidate is >> TCP candidate. >> >> >> I don=E2=80=99t see any real befits to implementations to this change an= d I don=E2=80=99t >> think the rtcweb consensus was around the currently solution. Do you see >> some advantage to implementations to this? >> > > This is what every other document related to ICE, including JSEP section > 5.2.2 currently specifies. It was also consensus in MMUSIC. I think RTCWE= B > need a really good reason why it needs to be different. > > It would probably help clarify things if you quoted the parts of the > document that you think are in conflict. I can't find any explicit > field handling in 5.2.2. > I have mentioned this already in the previous message, but I guess this got lost in the traffic. JSEP-25 in section 5.2.2 says ( https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.2.2): Each "m=3D" and c=3D" line MUST be filled in with the port, *protocol*, and address of the default candidate for the m=3D section, as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2. At the same time section 5.1.2 says ( https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2): For media m=3D sections, JSEP implementations MUST support the "UDP/TLS/RTP/SAVPF" profile specified in [RFC5764], and MUST indicate this profile for each media m=3D line they produce in an offer. For data m=3D sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this profile for each data m=3D line they produce in an offer. So, section 5.2.2 says m=3D line should be filled with currently used protocol, which means "TCP/TLS/RTP/SAVPF" or "TCP/DTLS/SCTP" if default candidate is TCP based, but section 5.1.2 says it must be "UDP/TLS/RTP/SAVP= F" or "UDP/DTLS/SCTP", even if default candidate is TCP based. I thought that section 5.2.2, since it is more specific, overwrites 5.1.2, which I assumed only applies to ICE restart. Authors disagree and want to update the document. > In terms of changing technical aspects of JSEP: the only reason the > document is out of the RFC Editor's queue right now is to address issues > arising from rationalizing the reference to RFC 8445 within Cluster 238. > This is not an opportunity to re-litigate previously settled consensus > decisions. Technical issues such as the one at hand should have been rais= ed > during WG development, WG last call, or -- in extremis, since you're a > regular RTCWEB participant -- during IETF last call. It's up to the chair= s > what to allow, but I wouldn't expect anything other than catastrophic fla= ws > to be open for change at this time. > I am not the one who opened this can of worms. I am fine if the current draft version is not changed. This is why I did not comment during the WG last call. Draft authors are introducing the new change in https://github.com/rtcweb-wg/jsep/pull/857, which makes JSEP incompatible with ice-sip-sdp. I oppose this change. If the group considers that a change to clarify things is necessary, I would suggest that section 5.1.2 should be changed instead to that it only applies during ICE restart, so that JSEP is compatible with ice-sip-sdp. Regards, ______________ Roman Shpount --000000000000f4b86f057bbdeac0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<= div class=3D"gmail_signature">Hi Adam,

On Wed, Nov 28, 2018 at 1:22 PM Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20

On 11/28/18 1= 0:57 AM, Roman Shpount wrote:
=20
On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings <fluffy@iii.ca> wrote:
On Nov 27, 2018, at 4:46 PM, Roman Shpount <roman@telurix.com> wrote:

=C2=A0I sugg= est to update JSEP section 5.1.2 to match the rest of the documents to say that=C2=A0"UDP/TLS/RTP/SAVPF" proto MUST be used during ICE restart. When ICE restart is not in progress,=C2=A0"UDP/TLS/RTP/SAVPF"=C2=A0proto MUST be used if default (only) candidate is a UDP candidate and=C2=A0"= ;TCP/TLS/RTP/SAVPF"=C2=A0proto MUST be used if default (only) candidate is TCP candidate.

I don=E2=80=99t see any real befits to implementations t= o this change and I don=E2=80=99t think the rtcweb consensus = was around the currently solution. Do you see some advantage to implementations to this?

This is what every other document related to ICE, including JSEP section 5.2.2 currently specifies. It was also consensus in MMUSIC. I think RTCWEB need a really good reason why it needs to be different.

It would probably help clarify things if you quoted the parts of the document that you think are in conflict. I can't find any explicit <proto> field handling in 5.2.2.

=C2=A0I have mentioned this already in the previous message, but = I guess this got lost in the traffic.
Each "m=3D" and c=3D" line MUST be filled in with the= port, protocol, and address of the default candidate for the m=3D s= ection, as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2.
<= div>
For media m=3D sections, JSEP imp= lementations MUST support the "UDP/TLS/RTP/SAVPF" profile specifi= ed in [RFC5764], and MUST indicate this profile for each media m=3D line th= ey produce in an offer.=C2=A0For data m=3D sections, implementations= MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this = profile for each data m=3D line they produce in an offer.
<= br>
So, section 5.2.2 says m=3D line should be fill= ed with currently used protocol, which means "TCP/TLS/RTP/SAVPF" = or "TCP/DTLS/SCTP" if default candidate is TCP based, but section= 5.1.2 says it must be=C2=A0"UDP/TLS/= RTP/SAVPF" or=C2=A0"UDP/DTLS/SCTP", even if default c= andidate is TCP based. I thought that section 5.2.2, since it is more speci= fic, overwrites 5.1.2, which I assumed only applies to ICE restart. Authors= disagree and want to update the document.

In terms of changing technical aspects of JSEP: the only reason the document is out of the RFC Editor's queue right now is to address issues arising from rationalizing the reference to RFC 8445 within Cluster 238. This is not an opportunity to re-litigate previously settled consensus decisions. Technical issues such as the one at hand should have been raised during WG development, WG last call, or -- in extremis, since you're a regular RTCWEB participant -- during IETF last call. It's up to the chairs what to allow, but I wouldn't expect anything other than catastrophic flaws to be open for change at this time.

= I am not the one who opened this can of worms. I am fine if the current dra= ft version is not changed. This is why I did not comment during the WG last= call. Draft authors are introducing the new change in=C2=A0https://github.com/rtcweb-wg/jsep/p= ull/857, which makes JSEP incompatible with ice-sip-sdp. I oppose this = change.=C2=A0If the group considers that a change to clarify things is nece= ssary, I would suggest that section 5.1.2 should be changed instead to that= it only applies during ICE restart, so that JSEP is compatible with ice-si= p-sdp.

Regards,
______________
Roman Shpount
--000000000000f4b86f057bbdeac0-- From nobody Wed Nov 28 10:59:14 2018 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 43E27130F97 for ; Wed, 28 Nov 2018 10:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.958 X-Spam-Level: X-Spam-Status: No, score=-18.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 owZdZq9HO--p for ; Wed, 28 Nov 2018 10:59:08 -0800 (PST) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 ACD31130EBC for ; Wed, 28 Nov 2018 10:59:08 -0800 (PST) Received: by mail-it1-x129.google.com with SMTP id m123-v6so6106424ita.4 for ; Wed, 28 Nov 2018 10:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ydDp0/zLOurOHL+kCWyHqBS+4FovV1ip3U0FQG/ZpkU=; b=L/6AjEWSJnhJWnyjEAkjofn/qrrhglRnxAU0VTQnnGV8e1V2sWmpFUGM/zH1oEgIes 3Yfkv3tBMyc8SmSK4Sj8RnaJzkwExbpELqAho+RlNfVTaO9AS502od912dkjrfvioGbY azQ32NSFNv11XvXg56nGY4U7xyUPVZHQ+Ly0bK3yiPpcPy/2+HM8NxiordMmVu3yFaQK FtJPLx/Fn8Jy8gDO4i3/vr5dinuLlLno0yFB2jNyLzwtcCW7Hr0hudaZ+H91sHnuv4jh q1ye0Po7z1Iaw0BqoxzjFi8elnt/tCquB+Dzzyhk3sEAqCSe1GlIHRRfTi8a+OV9QlP7 DrRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ydDp0/zLOurOHL+kCWyHqBS+4FovV1ip3U0FQG/ZpkU=; b=GZkdh+ajhx/PlXUXWaIR08ZfvY0BlykhoFKk04SBCtEkfQbxRxuhXLq3FFKMdb962e 7nJci/b+68MQDtZodUbKUi9+AMk3mxUdAqKI/rzAnNY45Fr63GqSP8uqZCCeGPrjdluH QfGzBpj022CZSmQxx5ey9YvZseYb0SJ80f/pZMceJ6w5q4UnRZoabwuNoH55RIyGIZ+8 juxlc7huXj6l4UUogqtasj1BVlvTF+iP3gGrddsxjZlTZVXoYmxG4+kjYINaFGY7S4Yf TnevmfPxd1QMzY6cWrSi5gg9sY65gacw3dFaQDbpc7ob0Djq029il0t/T5NEfBcCMNDV Daqg== X-Gm-Message-State: AA+aEWaapfpbyuR2KoJeTSLgDYrunHcDHJdG9JruCFEhkcVfsoQdFbTn wkrNyVGNp3z0vDH2zWdsm3KrvFODJ7UW3ek9HBViYV4/NF1yrA== X-Google-Smtp-Source: AFSGD/X1RjICT8vqGYgSgDpEGnNF7M8+R4raP0nO+MgtL1RY/kcKPDwNV2k9GNQ5fcCyFFS2Fm5pudr0FwBV/88WBd4= X-Received: by 2002:a02:94eb:: with SMTP id x98mr10578185jah.88.1543431547504; Wed, 28 Nov 2018 10:59:07 -0800 (PST) MIME-Version: 1.0 References: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca> <110dc822-b3be-7bc2-dcc5-9e6c8277e0d1@nostrum.com> In-Reply-To: From: Justin Uberti Date: Wed, 28 Nov 2018 10:58:55 -0800 Message-ID: To: Roman Shpount Cc: Adam Roach , RTCWeb IETF , mmusic@ietf.org Content-Type: multipart/alternative; boundary="00000000000020412d057bbe290d" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 28 Nov 2018 18:59:12 -0000 --00000000000020412d057bbe290d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Regarding the current conflict between 5.1.2 and 5.2.2, this is discussed in https://github.com/rtcweb-wg/jsep/issues/854, and the editor team concluded that 5.2.2 should be brought in line with 5.1.2 by removing the need to match the protocol field. I think this change is important to make to avoid future confusion. This conclusion was a result of reviewing the prior discussion in https://mailarchive.ietf.org/arch/msg/mmusic/gR-dYY1GzN3fIA_XlHiX-bB6nLM, where this topic was previously litigated. That email thread concluded with the message in https://mailarchive.ietf.org/arch/msg/mmusic/p6AFDGqbNm57P6s1cN2ZOUUDj2U, where Roman seemed to be in agreement with the proposal. On Wed, Nov 28, 2018 at 10:41 AM Roman Shpount wrote: > > Hi Adam, > > On Wed, Nov 28, 2018 at 1:22 PM Adam Roach wrote: > >> >> On 11/28/18 10:57 AM, Roman Shpount wrote: >> >> On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings wrote: >> >>> On Nov 27, 2018, at 4:46 PM, Roman Shpount wrote: >>> >>> I suggest to update JSEP section 5.1.2 to match the rest of the >>> documents to say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE >>> restart. When ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto >>> MUST be used if default (only) candidate is a UDP candidate and >>> "TCP/TLS/RTP/SAVPF" proto MUST be used if default (only) candidate is >>> TCP candidate. >>> >>> >>> I don=E2=80=99t see any real befits to implementations to this change a= nd I >>> don=E2=80=99t think the rtcweb consensus was around the currently solut= ion. Do you >>> see some advantage to implementations to this? >>> >> >> This is what every other document related to ICE, including JSEP section >> 5.2.2 currently specifies. It was also consensus in MMUSIC. I think RTCW= EB >> need a really good reason why it needs to be different. >> >> It would probably help clarify things if you quoted the parts of the >> document that you think are in conflict. I can't find any explicit >> field handling in 5.2.2. >> > I have mentioned this already in the previous message, but I guess this > got lost in the traffic. > > JSEP-25 in section 5.2.2 says ( > https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.2.2): > > Each "m=3D" and c=3D" line MUST be filled in with the port, *protocol*, a= nd > address of the default candidate for the m=3D section, as described in > [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2. > > > At the same time section 5.1.2 says ( > https://tools..ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2 > ): > > For media m=3D sections, JSEP implementations MUST support the > "UDP/TLS/RTP/SAVPF" profile specified in [RFC5764], and MUST indicate thi= s > profile for each media m=3D line they produce in an offer. For data m=3D > sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MU= ST > indicate this profile for each data m=3D line they produce in an offer. > > So, section 5.2.2 says m=3D line should be filled with currently used > protocol, which means "TCP/TLS/RTP/SAVPF" or "TCP/DTLS/SCTP" if default > candidate is TCP based, but section 5.1.2 says it must be "UDP/TLS/RTP/SA= VPF" > or "UDP/DTLS/SCTP", even if default candidate is TCP based. I thought > that section 5.2.2, since it is more specific, overwrites 5.1.2, which I > assumed only applies to ICE restart. Authors disagree and want to update > the document. > >> In terms of changing technical aspects of JSEP: the only reason the >> document is out of the RFC Editor's queue right now is to address issues >> arising from rationalizing the reference to RFC 8445 within Cluster 238. >> This is not an opportunity to re-litigate previously settled consensus >> decisions. Technical issues such as the one at hand should have been rai= sed >> during WG development, WG last call, or -- in extremis, since you're a >> regular RTCWEB participant -- during IETF last call. It's up to the chai= rs >> what to allow, but I wouldn't expect anything other than catastrophic fl= aws >> to be open for change at this time. >> > I am not the one who opened this can of worms. I am fine if the current > draft version is not changed. This is why I did not comment during the WG > last call. Draft authors are introducing the new change in > https://github.com/rtcweb-wg/jsep/pull/857, which makes JSEP incompatible > with ice-sip-sdp. I oppose this change. If the group considers that a > change to clarify things is necessary, I would suggest that section 5.1.2 > should be changed instead to that it only applies during ICE restart, so > that JSEP is compatible with ice-sip-sdp. > > Regards, > ______________ > Roman Shpount > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00000000000020412d057bbe290d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Regardi= ng the current conflict between 5.1.2 and 5.2.2, this is discussed in https://github.com/rtcw= eb-wg/jsep/issues/854, and the editor team concluded that 5.2.2 should = be brought in line with 5.1.2 by removing the need to match the protocol fi= eld. I think this change is important to make to avoid future confusion.
This conclusion was a result of reviewing the prior discus= sion in https://mailarchive.ietf.org/arch/msg/mmusic/gR-dYY1GzN3f= IA_XlHiX-bB6nLM, where this topic was previously litigated. That email = thread concluded with the message in https://mailarchive.ietf.org= /arch/msg/mmusic/p6AFDGqbNm57P6s1cN2ZOUUDj2U, where Roman seemed to be = in agreement with the proposal.


On Wed, Nov 28, 2018 at 10= :41 AM Roman Shpount <roman@telurix= .com> wrote:

Hi Adam,

On Wed, Nov 28, 2018 at 1:22 PM Adam Roach <= ;adam@nostrum.com= > wrote:
=20 =20 =20

On 11/28/18 10:57 AM, Roman Shpount wrote:
=20
On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings <fluffy@iii.ca> wrote:
On Nov 27, 2018, at 4:46 PM, Roman Shpount <roman@telurix.com> wrote:

"UDP/TLS/RTP/SAVPF" proto MUST be used during ICE restart. When ICE restart is not in progress,=C2=A0"UDP/TLS/RTP/SAVPF"=C2= =A0proto MUST be used if default (only) candidate is a UDP candidate and=C2=A0"= ;TCP/TLS/RTP/SAVPF"=C2=A0proto MUST be used if default (only) candidate is TCP candidate.

I don=E2=80=99t see any real befits to implementations t= o this change and I don=E2=80=99t think the rtcweb consensus = was around the currently solution. Do you see some advantage to implementations to this?

This is what every other document related to ICE, including JSEP section 5.2.2 currently specifies. It was also consensus in MMUSIC. I think RTCWEB need a really good reason why it needs to be different.

It would probably help clarify things if you quoted the parts of the document that you think are in conflict. I can't find any explicit <proto> field handling in 5.2.2.

=C2=A0I have mentioned this already in the previous message, but = I guess this got lost in the traffic.
Each "m=3D" and c=3D" line MUST be filled in with the= port, protocol, and address of the default candidate for the m=3D s= ection, as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2.
=
For media m=3D sections, JSEP im= plementations MUST support the "UDP/TLS/RTP/SAVPF" profile specif= ied in [RFC5764], and MUST indicate this profile for each media m=3D line t= hey produce in an offer.=C2=A0For data m=3D sections, implementation= s MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this= profile for each data m=3D line they produce in an offer.
=
So, section 5.2.2 says m=3D line should be fil= led with currently used protocol, which means "TCP/TLS/RTP/SAVPF"= or "TCP/DTLS/SCTP" if default candidate is TCP based, but sectio= n 5.1.2 says it must be=C2=A0"UDP/TLS= /RTP/SAVPF" or=C2=A0"UDP/DTLS/SCTP", even if default = candidate is TCP based. I thought that section 5.2.2, since it is more spec= ific, overwrites 5.1.2, which I assumed only applies to ICE restart. Author= s disagree and want to update the document.

In terms of changing technical aspects of JSEP: the only reason the document is out of the RFC Editor's queue right now is to address issues arising from rationalizing the reference to RFC 8445 within Cluster 238. This is not an opportunity to re-litigate previously settled consensus decisions. Technical issues such as the one at hand should have been raised during WG development, WG last call, or -- in extremis, since you're a regular RTCWEB participant -- during IETF last call. It's up to the chairs what to allow, but I wouldn't expect anything other than catastrophic flaws to be open for change at this time.

= I am not the one who opened this can of worms. I am fine if the current dra= ft version is not changed. This is why I did not comment during the WG last= call. Draft authors are introducing the new change in=C2=A0https://github.co= m/rtcweb-wg/jsep/pull/857, which makes JSEP incompatible with ice-sip-s= dp. I oppose this change.=C2=A0If the group considers that a change to clar= ify things is necessary, I would suggest that section 5.1.2 should be chang= ed instead to that it only applies during ICE restart, so that JSEP is comp= atible with ice-sip-sdp.

Regards,
______= ________
Roman Shpount
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--00000000000020412d057bbe290d-- From nobody Wed Nov 28 11:01:08 2018 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 BFA06128A6E; Wed, 28 Nov 2018 11:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 bUFIDJTZ8JBo; Wed, 28 Nov 2018 11:01:03 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::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 A73EB127B92; Wed, 28 Nov 2018 11:01:03 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id b141so23503017oii.12; Wed, 28 Nov 2018 11:01:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xTbutENY+aEjnfVb8OXvI7PRh4lR0mn90Hq8q++4Y+w=; b=rhcjRKqRp2Y415wBjyJt6RQhsAJJ4Y79OYBxWMDQ2UJ6weACSS5I9bZ+miwcVjY37l Y+ORaotgWujMLRrFKivx+6nAk1/F9lUd2Sl5ikVDUBoOx2J5EDFpNJhSPFEUpzzaoEen M9YQMfUYddnNAxAXellg//3gg/9ephMNrRyWzlTb30hYxAV6SpMUKDjTHZKJ9+PZ8VrW zS0Wm2M5uz5+v+w4mEBozI5iLga3ZtIKdpZzE+XoYYtwR93Vu/tH3QqtxadncvGk1KuK K/Fx+qmqGIbzNmyrxFXHtmeq/zb4NofXFZM6K9JZW/eG03vZxwb0tv99FFc0vaLsVfwM B/ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xTbutENY+aEjnfVb8OXvI7PRh4lR0mn90Hq8q++4Y+w=; b=a4oU+ShboLshye72QDk6SLPpZ/nlSadFduF/py/UBSK+RuUQ1+fmUSb+9+fiLEJM5y +0pwVrObad3N1KXJMVTPg4oBD2LInyAg5cqxXFI+EPdV6hARWMuB6Q1R0t3kjwsvlduX kKRq14cgcD5p/tlsZKx575eKr4jn6wT/5u17W3r097Edg2MuQ9SjidHzoCBDvG+VgsvL Z9qb696rj7jrgGJRDCW0AhFCTKmxnrZ1ox81wyZ1qQ8TluYuh8ky4VHg70cAtkVT6isX Vox1fHZYCifNh4fAujY1ZnxchZ23s7CaLeYuAcFpjWfVeqYNoVbQJD7Oy+wZ8iAPKZpO N2uw== X-Gm-Message-State: AGRZ1gINVJvfmHG7pA/w59W0QR0II2/2VYXl2chvhsP8HLiFjrdvDg7Y YgO1IISIA5CVO1RxFMbraajx01twj8l0DoJq2zCAD2cu X-Google-Smtp-Source: AJdET5dEG2XGPsiBxdcdpEnhjb9JtnmojiOx50bqfZ3zVc9Wtc8BEqvky068eFlH6mu8O2Z3j7iEfsolnlg780sanK8= X-Received: by 2002:aca:4ed8:: with SMTP id c207mr22066297oib.276.1543431662582; Wed, 28 Nov 2018 11:01:02 -0800 (PST) MIME-Version: 1.0 References: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca> <110dc822-b3be-7bc2-dcc5-9e6c8277e0d1@nostrum.com> In-Reply-To: From: Ted Hardie Date: Wed, 28 Nov 2018 11:00:34 -0800 Message-ID: To: Roman Shpount Cc: Adam Roach , RTCWeb IETF , mmusic@ietf.org Content-Type: multipart/alternative; boundary="000000000000fbc312057bbe2fbf" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 28 Nov 2018 19:01:07 -0000 --000000000000fbc312057bbe2fbf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roman, The current pull request resolves the 5.1.2 vs. 5.2.2 ambiguity in line with the discussion here: https://github.com/rtcweb-wg/jsep/issues/394 and then here: https://mailarchive.ietf.org/arch/msg/mmusic/gR-dYY1GzN3fIA_XlHiX-bB6nLM I understand from your comments on https://github.com/rtcweb-wg/jsep/issues/854 that you disagreed with that being the final consensus, and it has since been discussed on the list as Justin suggested in that issue. At the moment I continue to see only you objecting to the combination of the current pull and an update to ice-sip-sdp. Since ice-sip-sdp is in MMUSIC, not RTCWEB, it's not up to the RTCWEB chairs to call the final consensus here, but I believe my previous statement on the preference for RTCWEB remains true. regards, Ted On Wed, Nov 28, 2018 at 10:42 AM Roman Shpount wrote: > > Hi Adam, > > On Wed, Nov 28, 2018 at 1:22 PM Adam Roach wrote: > >> >> On 11/28/18 10:57 AM, Roman Shpount wrote: >> >> On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings wrote: >> >>> On Nov 27, 2018, at 4:46 PM, Roman Shpount wrote: >>> >>> I suggest to update JSEP section 5.1.2 to match the rest of the >>> documents to say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE >>> restart. When ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto >>> MUST be used if default (only) candidate is a UDP candidate and >>> "TCP/TLS/RTP/SAVPF" proto MUST be used if default (only) candidate is >>> TCP candidate. >>> >>> >>> I don=E2=80=99t see any real befits to implementations to this change a= nd I >>> don=E2=80=99t think the rtcweb consensus was around the currently solut= ion. Do you >>> see some advantage to implementations to this? >>> >> >> This is what every other document related to ICE, including JSEP section >> 5.2.2 currently specifies. It was also consensus in MMUSIC. I think RTCW= EB >> need a really good reason why it needs to be different. >> >> It would probably help clarify things if you quoted the parts of the >> document that you think are in conflict. I can't find any explicit >> field handling in 5.2.2. >> > I have mentioned this already in the previous message, but I guess this > got lost in the traffic. > > JSEP-25 in section 5.2.2 says ( > https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.2.2): > > Each "m=3D" and c=3D" line MUST be filled in with the port, *protocol*, a= nd > address of the default candidate for the m=3D section, as described in > [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2. > > > At the same time section 5.1.2 says ( > https://tools..ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2 > ): > > For media m=3D sections, JSEP implementations MUST support the > "UDP/TLS/RTP/SAVPF" profile specified in [RFC5764], and MUST indicate thi= s > profile for each media m=3D line they produce in an offer. For data m=3D > sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MU= ST > indicate this profile for each data m=3D line they produce in an offer. > > So, section 5.2.2 says m=3D line should be filled with currently used > protocol, which means "TCP/TLS/RTP/SAVPF" or "TCP/DTLS/SCTP" if default > candidate is TCP based, but section 5.1.2 says it must be "UDP/TLS/RTP/SA= VPF" > or "UDP/DTLS/SCTP", even if default candidate is TCP based. I thought > that section 5.2.2, since it is more specific, overwrites 5.1.2, which I > assumed only applies to ICE restart. Authors disagree and want to update > the document. > >> In terms of changing technical aspects of JSEP: the only reason the >> document is out of the RFC Editor's queue right now is to address issues >> arising from rationalizing the reference to RFC 8445 within Cluster 238. >> This is not an opportunity to re-litigate previously settled consensus >> decisions. Technical issues such as the one at hand should have been rai= sed >> during WG development, WG last call, or -- in extremis, since you're a >> regular RTCWEB participant -- during IETF last call. It's up to the chai= rs >> what to allow, but I wouldn't expect anything other than catastrophic fl= aws >> to be open for change at this time. >> > I am not the one who opened this can of worms. I am fine if the current > draft version is not changed. This is why I did not comment during the WG > last call. Draft authors are introducing the new change in > https://github.com/rtcweb-wg/jsep/pull/857, which makes JSEP incompatible > with ice-sip-sdp. I oppose this change. If the group considers that a > change to clarify things is necessary, I would suggest that section 5.1.2 > should be changed instead to that it only applies during ICE restart, so > that JSEP is compatible with ice-sip-sdp. > > Regards, > ______________ > Roman Shpount > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000fbc312057bbe2fbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi= Roman,

The current pull request resolves the 5.1.= 2 vs. 5.2.2 ambiguity in line with the discussion here:


and then here= :


I under= stand from your comments on https://github.com/rtcweb-wg/jsep/issues/854 that you disagre= ed with that being the final consensus, and it has since been discussed on = the list as Justin suggested in that issue.
=C2=A0
At t= he moment I continue to see only you objecting to the combination of the cu= rrent pull and an update to ice-sip-sdp. =C2=A0 Since ice-sip-= sdp is in MMUSIC, not RTCWEB, it's not up to the RTCWEB chairs to call = the final consensus here, but I believe my previous statement on the prefer= ence for RTCWEB remains true.

regards,=C2=A0

Ted



On Wed, Nov 28, 2018 at 10:42 AM Roman= Shpount <roman@telurix.com>= wrote:

Hi Adam,

On Wed, Nov 28, 2018 at 1:22 PM Adam Roach <adam@nostrum.com> wro= te:
=20 =20 =20

On 11/28/18 10:57 AM, Roman Shpount wrote:
=20
On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings <fluffy@iii.ca> wrote:
On Nov 27, 2018, at 4:46 PM, Roman Shpount <roman@telurix.com> wrote:

=C2=A0I suggest to update JSEP section 5.1.2 to match the rest of the documents to say that=C2=A0"UDP/TLS/RTP/SAVPF" proto MUST be used during ICE restart. When ICE restart is not in progress,=C2=A0"UDP/TLS/RTP/SAVPF"= =C2=A0proto MUST be used if default (only) candidate is a UDP candidate and=C2=A0"= ;TCP/TLS/RTP/SAVPF"=C2=A0proto MUST be used if default (only) candidate is TCP candidate.

I don=E2=80=99t see any real befits to implementations t= o this change and I don=E2=80=99t think the rtcweb consensus = was around the currently solution. Do you see some advantage to implementations to this?

This is what every other document related to ICE, including JSEP section 5.2.2 currently specifies. It was also consensus in MMUSIC. I think RTCWEB need a really good reason why it needs to be different.

It would probably help clarify things if you quoted the parts of the document that you think are in conflict. I can't find any explicit <proto> field handling in 5.2.2.

=C2=A0I have mentioned this already in the previous message, but = I guess this got lost in the traffic.
Each "m=3D" and c=3D" line MUST be filled in with the= port, protocol, and address of the default candidate for the m=3D s= ection, as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2.
=
For media m=3D sections, JSEP im= plementations MUST support the "UDP/TLS/RTP/SAVPF" profile specif= ied in [RFC5764], and MUST indicate this profile for each media m=3D line t= hey produce in an offer.=C2=A0For data m=3D sections, implementation= s MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this= profile for each data m=3D line they produce in an offer.
=
So, section 5.2.2 says m=3D line should be fil= led with currently used protocol, which means "TCP/TLS/RTP/SAVPF"= or "TCP/DTLS/SCTP" if default candidate is TCP based, but sectio= n 5.1.2 says it must be=C2=A0"UDP/TLS= /RTP/SAVPF" or=C2=A0"UDP/DTLS/SCTP", even if default = candidate is TCP based. I thought that section 5.2.2, since it is more spec= ific, overwrites 5.1.2, which I assumed only applies to ICE restart. Author= s disagree and want to update the document.

In terms of changing technical aspects of JSEP: the only reason the document is out of the RFC Editor's queue right now is to address issues arising from rationalizing the reference to RFC 8445 within Cluster 238. This is not an opportunity to re-litigate previously settled consensus decisions. Technical issues such as the one at hand should have been raised during WG development, WG last call, or -- in extremis, since you're a regular RTCWEB participant -- during IETF last call. It's up to the chairs what to allow, but I wouldn't expect anything other than catastrophic flaws to be open for change at this time.

= I am not the one who opened this can of worms. I am fine if the current dra= ft version is not changed. This is why I did not comment during the WG last= call. Draft authors are introducing the new change in=C2=A0https://github.co= m/rtcweb-wg/jsep/pull/857, which makes JSEP incompatible with ice-sip-s= dp. I oppose this change.=C2=A0If the group considers that a change to clar= ify things is necessary, I would suggest that section 5.1.2 should be chang= ed instead to that it only applies during ICE restart, so that JSEP is comp= atible with ice-sip-sdp.

Regards,
______= ________
Roman Shpount
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000fbc312057bbe2fbf-- From nobody Wed Nov 28 11:50:26 2018 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 27AF0130FC2 for ; Wed, 28 Nov 2018 11:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.347 X-Spam-Level: X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ImZ4LCSB7ss for ; Wed, 28 Nov 2018 11:50:22 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 95719130FBE for ; Wed, 28 Nov 2018 11:50:22 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id 17so9966162pgg.1 for ; Wed, 28 Nov 2018 11:50:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bP2dV194ccrdauawcnoCOgNqP0BSnGYDfpb0AuF8q2E=; b=CqJDvWvLGA3VPaNAbH7o529xXD5rEDzug70RqJYnKThW/FADV+FPwSX8GCQ5bX/Ymo Lrv1ESG0PLDuR9K17P23ijPA+msmjge0LroUhlhVg9eAjJ8ey0DUY+Fmahj36k6M0eZx C+TxPuU5sj8koAr7UE4HsY60epXyBW2aZlWHwmtp7RmmaIBHsyl4os2PEnbmFskn028d Zimjf2FW0zZEQXM+wWZXecNPbeEomMsu/jxhBSIoEuvroOcOcZ4CwAteBpeiW7StjZU+ HDQJLwX4DE4OFStTe4FsJHof0bo+Vd2VQzj5Wz2UH1QSyac0c1Kt0ZKdJRXpkuF+wDAr rghw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bP2dV194ccrdauawcnoCOgNqP0BSnGYDfpb0AuF8q2E=; b=Wt4jVOWlN5mOK/b1Bqg0Sp3d1lW8R48DyJO9t/AfhWheoISgs1Aig9JqNxXViMlQic zDonmPL8IuwJlRS8kke7AsLJNc90/LIviSdoHoDBavttQmWdNyIatpzSWEN23Ii7f+YI 0dc1UFElUNvFvTxFXv6b3b+YFcbtunxpM3UsiWq7SVSuXF3R7OZQ6I98vS+rROUTiFoH jeqflRhSJEf9YavJvkX33D/SHjsc6Qqzp/BudQEBDVz6Sq46NRygd+AYF5jZ1RUjQTqp tA3WhM1asHkvyz/XhZz7taUbjTxcSXbUi4/RQMWfDrh/BvdbZgKwXbHeNI7HttlXriwv YHVg== X-Gm-Message-State: AGRZ1gKTkd91mO3C6xVlknN62Umu0XOkiaLBnmV9QzY6q9f201iXUOA5 Te7mdZmoKvsmS1jHF/HpBJCDLWeSVuI= X-Google-Smtp-Source: AJdET5fTD7aZ8Y7dVBkVzrjK6eZRAXOuHeT1yQJWfrg+AO+jBbAZiAQnZ4uriPm0PCoWtfR6G+3OyQ== X-Received: by 2002:a62:2e46:: with SMTP id u67mr38214023pfu.3.1543434621853; Wed, 28 Nov 2018 11:50:21 -0800 (PST) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com. [209.85.214.173]) by smtp.gmail.com with ESMTPSA id 128sm13022642pfu.129.2018.11.28.11.50.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Nov 2018 11:50:20 -0800 (PST) Received: by mail-pl1-f173.google.com with SMTP id x21-v6so17875669pln.9; Wed, 28 Nov 2018 11:50:20 -0800 (PST) X-Received: by 2002:a17:902:8b88:: with SMTP id ay8mr38757038plb.55.1543434620502; Wed, 28 Nov 2018 11:50:20 -0800 (PST) MIME-Version: 1.0 References: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca> <110dc822-b3be-7bc2-dcc5-9e6c8277e0d1@nostrum.com> In-Reply-To: From: Roman Shpount Date: Wed, 28 Nov 2018 14:50:09 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Adam Roach - SIPCORE Chair , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="0000000000004a094f057bbee037" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 28 Nov 2018 19:50:25 -0000 --0000000000004a094f057bbee037 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 28, 2018 at 1:59 PM Justin Uberti wrote: > Regarding the current conflict between 5.1.2 and 5.2.2, this is discussed > in https://github.com/rtcweb-wg/jsep/issues/854, and the editor team > concluded that 5.2.2 should be brought in line with 5.1.2 by removing the > need to match the protocol field. I think this change is important to make > to avoid future confusion. > > This conclusion was a result of reviewing the prior discussion in > https://mailarchive.ietf.org/arch/msg/mmusic/gR-dYY1GzN3fIA_XlHiX-bB6nLM, > where this topic was previously litigated. That email thread concluded with > the message in > https://mailarchive.ietf.org/arch/msg/mmusic/p6AFDGqbNm57P6s1cN2ZOUUDj2U, > where Roman seemed to be in agreement with the proposal. > The discussion you are referring to was about the initial ICE offer/answer exchange. I agree that during offer/answer exchange which initiate ICE restart, only UDP based protocols should be used in the m= line. For me, this is what section 5.1.2 describes. When ice-sip-sdp and related documents (sctp-sdp and fc4583bis) were written, this logic was slightly "fine tuned" for offer/answer exchanges which do not initiate ICE restart. For these exchanges, it was decided to use the protocol of the only ICE candidate pair present. This was important for backwards compatibility with RFC 5245, especially when signaling agent monitors values in c= and m= lines and actually cares about the address and protocol used there. This is what JSEP section 5.2.2 is describing and what you want to change. I agree this is not extremely important for JSEP use cases, but unlikely to change in ice-sip-sdp, since it is important there. Because of this, we are going to end up with two specifications, and ICE implementations, which are slightly different for no reason. As an implementer, this is an extra "flag" I need to set when instantiating my ICE library. Second part of the problem for me are the values of address and port in the c= and m= line when no candidates in session description match the protocol in the m= line. I do not think it was discussed anywhere except during trickle ICE, where it was specified to set c= to IN IP4 0.0.0.0 and m= line port to 9 when no candidates are present. If this can be extended to the case when ICE candidates are present but do not match the proto in the m= line, I would be happy since this will prevent ICE mismatch with ice-sip-sdp compliant implementations. If you do not want to update JSEP to do this, it can be added in ice-sip-sdp. Just please do not put something in JSEP which will force it to update c= and m= line with address and port of mismatching candidate. Regards, _____________ Roman Shpount --0000000000004a094f057bbee037 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 28, 2018 at 1:59 PM Justin Uberti <= juberti@google.com> wrote:
=
Regarding th= e current conflict between 5.1.2 and 5.2.2, this is discussed in https://gi= thub.com/rtcweb-wg/jsep/issues/854, and the editor team concluded that = 5.2.2 should be brought in line with 5.1.2 by removing the need to match th= e protocol field. I think this change is important to make to avoid future = confusion.

This conclusion was a result of reviewing the= prior discussion in https://mailarchive.ietf.o= rg/arch/msg/mmusic/gR-dYY1GzN3fIA_XlHiX-bB6nLM, where this topic was pr= eviously litigated. That email thread concluded with the message in https://mailarchive.ietf.org/arch/msg/mmusic/p6AFDGqbN= m57P6s1cN2ZOUUDj2U, where Roman seemed to be in agreement with the prop= osal.

The dis= cussion you are referring to was about the initial ICE offer/answer exchang= e. I agree that during offer/answer exchange which initiate ICE restart, on= ly UDP based protocols should be used in the m=3D line. For me, this is wha= t section 5.1.2 describes. When ice-sip-sdp and related documents (sctp-sdp and fc4583bis)=C2=A0were written, this logic was sl= ightly "fine tuned" for offer/answer exchanges which do not initi= ate ICE restart. For these exchanges, it was decided to use the protocol of= the only ICE candidate pair present. This was important for backwards comp= atibility with RFC 5245, especially when signaling agent monitors values in= c=3D and m=3D lines and actually cares about the address and protocol used= there.=C2=A0 This is what JSEP section 5.2.2 is describing and what you wa= nt to change. I agree this is not extremely important for JSEP use cases, b= ut unlikely to change in ice-sip-sdp, since it is important there. Because = of this, we are going to end up with two specifications, and ICE implementa= tions, which are slightly different for no reason. As an implementer, this = is an extra "flag" I need to set when instantiating my ICE librar= y.

Second part of the problem for me are the value= s of address and port in the c=3D and m=3D line when no candidates in sessi= on description match the protocol in the m=3D line. I do not think it was d= iscussed anywhere except during trickle ICE, where it was specified to set = c=3D to IN IP4 0.0.0.0 and m=3D line port to 9 when no candidates are prese= nt. If this can be extended to the case when ICE candidates are present but= do not match the proto in the m=3D line, I would be happy since this will = prevent ICE mismatch with ice-sip-sdp compliant implementations. If you do = not want to update JSEP to do this, it can be added in ice-sip-sdp. Just pl= ease do not put something in JSEP which will force it to update c=3D and m= =3D line with address and port of mismatching candidate.

Regards,
_____________
Roman Shpount
=C2=A0
--0000000000004a094f057bbee037-- From nobody Wed Nov 28 11:54:51 2018 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 B56C9130FD9 for ; Wed, 28 Nov 2018 11:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.347 X-Spam-Level: X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1ixMTVZejFq for ; Wed, 28 Nov 2018 11:54:47 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 BDF2B130FD1 for ; Wed, 28 Nov 2018 11:54:47 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id i12so10680768pfo.7 for ; Wed, 28 Nov 2018 11:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/ySczJlkKH7dSavRCo7xHBAXdgqdSXkZD4zF+F+yk5M=; b=w5/oEuKf5AXulzvfdTzOPSkcehBY3/+BamWkC6n6MwrUX4ZWUuZ6dlJs9VDxNDCUr1 bqxocobgY5PsjI1dlyBxPuPQ74wOMAGfpp0jrxlrKSyitYVAmQJXi4vz1lMvuEXQ+QY9 X+0v/E5u1eh514DWj6yrjol6ZRh916V8rets3ue2rEgPzide6fZEZhGyFRLQ9tznQza8 eT58cHuRHIj1iXOZz7NE3gAYNV9PgadTQeP/6vUZxnLbs2edAWHZk6b0ZYGg76BMjVC7 /sX2NAOO22ORjuGpTJv0nTIHJvK89DEmmgWWfYPbL5voRpShlPNe4Gbv/UZb8uYyRx3i bybw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/ySczJlkKH7dSavRCo7xHBAXdgqdSXkZD4zF+F+yk5M=; b=Y4AAgDxpCRpwpuNwuyZ/++NXuwUJeMq6VFZSxWiGGUHDSDyKPyu3Diqlwm2Xwrg54B Ef+WnClOEn4Hojzo/7I2gYrpclzDoLc1YQ83WfQSGVKidYh6sWgW3C+4GdcO1A0vpjlV kNy19BnKc2z5eHkVqusBi4/YcKsN6r1Swd0LIZ/D+pVW2Fj4g1BpJOoln3fbJu7Nueke ylm7llFQzmsZ2wfj0wsRXPKOSJFkKlNdgOzMXoHSltFZfdG/JJsnkgZxkQjQnsMgDU1x PKu0qY/Gd4UWidWHQodt2xnHUoTcIb/Aw+3Ui2Rmhjd01AcP9HgEpU3NQ6kInQcdovSQ Ms0g== X-Gm-Message-State: AGRZ1gLMuz4pXLMu9g77roq/8N5AJHT1qh/CIXm+UCoPJBzIE3R4DWva aBjePIyGrX53Xw0jy4c42k6/Uns74Hg= X-Google-Smtp-Source: AJdET5fCnBf5/SoG4+jspmk4Z1//StK4Y/5jAWahsYcs3b30+RKcSp4c7DpgJ9KE18TSMuQCcVeIfA== X-Received: by 2002:a62:d0c1:: with SMTP id p184mr38422468pfg.245.1543434887265; Wed, 28 Nov 2018 11:54:47 -0800 (PST) Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com. [209.85.210.177]) by smtp.gmail.com with ESMTPSA id l85sm10111765pfg.161.2018.11.28.11.54.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Nov 2018 11:54:46 -0800 (PST) Received: by mail-pf1-f177.google.com with SMTP id c123so9988840pfb.0; Wed, 28 Nov 2018 11:54:46 -0800 (PST) X-Received: by 2002:a63:2e88:: with SMTP id u130mr34887823pgu.9.1543434886357; Wed, 28 Nov 2018 11:54:46 -0800 (PST) MIME-Version: 1.0 References: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca> <110dc822-b3be-7bc2-dcc5-9e6c8277e0d1@nostrum.com> In-Reply-To: From: Roman Shpount Date: Wed, 28 Nov 2018 14:54:35 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Ted Hardie Cc: Adam Roach - SIPCORE Chair , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="00000000000022a631057bbef0d5" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 28 Nov 2018 19:54:50 -0000 --00000000000022a631057bbef0d5 Content-Type: text/plain; charset="UTF-8" Hi Ted, On Wed, Nov 28, 2018 at 2:01 PM Ted Hardie wrote: > The current pull request resolves the 5.1.2 vs. 5.2.2 ambiguity in line > with the discussion here: > > https://github.com/rtcweb-wg/jsep/issues/394 > > and then here: > > https://mailarchive.ietf.org/arch/msg/mmusic/gR-dYY1GzN3fIA_XlHiX-bB6nLM > > I understand from your comments on > https://github.com/rtcweb-wg/jsep/issues/854 that you disagreed with that > being the final consensus, and it has since been discussed on the list as > Justin suggested in that issue. > > At the moment I continue to see only you objecting to the combination of > the current pull and an update to ice-sip-sdp. Since ice-sip-sdp is in > MMUSIC, not RTCWEB, it's not up to the RTCWEB chairs to call the final > consensus here, but I believe my previous statement on the preference for > RTCWEB remains true. > >> >> I think at this point it is up to the chairs to decide. Just please keep in mind that updating ice-sip-sdp and sctp-sdp to be inline with what JSEP is proposing would be difficult since this will cause backward compatibility issues with RFC 5245 outside of RTCWEB. Also, proposed change raises a new issue, which is what values should be set in c= and m= lines when protocol in m= line does not match the default candidate. Regards, _____________ Roman Shpount --00000000000022a631057bbef0d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ted,

On Wed, Nov 28, 2018 at 2:01 PM Ted Hard= ie <ted.ietf@gmail.com> wro= te:
The current pull request resolves= the 5.1.2 vs. 5.2.2 ambiguity in line with the discussion here:
<= div>

and then here:


I understand from your comments o= n https://github.com/rtcweb-wg/jsep/issues/854 that you disagreed with = that being the final consensus, and it has since been discussed on the list= as Justin suggested in that issue.
=C2=A0
At the momen= t I continue to see only you objecting to the combination of the current pu= ll and an update to ice-sip-sdp. =C2=A0 S= ince ice-sip-sdp is in MMUSIC, not RTCWEB, it's not up to the RTCWEB ch= airs to call the final consensus here, but I believe my previous statement = on the preference for RTCWEB remains true.
<= /div>


I think at this point it = is up to the chairs to decide. Just please keep in mind that updating ice-s= ip-sdp and=C2=A0sctp-sdp to be inline with what JSEP is proposing would be = difficult since this will cause backward compatibility=C2=A0issues with RFC= 5245 outside of RTCWEB.

Also, proposed c= hange raises a new issue, which is what values should be set in c=3D and m= =3D lines when protocol in m=3D line does not match the default candidate.<= /font>

<= font color=3D"#000000" style=3D"">Regards,
_____________
Rom= an Shpount
=C2=A0
--00000000000022a631057bbef0d5--