Re: [rtcweb] Proposal to break the ICE impasse

Ted Hardie <> Tue, 29 January 2019 01:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 471E4126DBF for <>; Mon, 28 Jan 2019 17:10:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SosTX8xEFezS for <>; Mon, 28 Jan 2019 17:10:17 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17A9312875B for <>; Mon, 28 Jan 2019 17:10:17 -0800 (PST)
Received: by with SMTP id x23so14797510oix.3 for <>; Mon, 28 Jan 2019 17:10:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=grnS0NyhB05vK2ZTZaziKZn0SyUiyuOq4AL10Yv05J4=; b=tWA2Tgaxn6z6ehQ+6LdnySLaKS99arMnxtNt4eYAXRDOpbaRk4nuJ8PlIRzm3usfs0 03vh9xH+UNtyEHbCjVBJtP+5NlZGcPnUzmBsLxv0M6T0b6GtkBDBP5WDFDMauoA/4ZOt JIT26ci5zpxMTEx8Sj9KDxLUAFfNyk48M1dgOqDqSmnF+UuDNE3qpTECjEvw+Moj8RsA PNGMtiqTdSTmEGJSSpycBPHHwmb510J9/BE9iDegLj0PDmRWB/jvlq9Ar9p8n2k7CR9k IGFn34PMLqQuPoYpJVhMiMlUPPn/JygISgAw0lR4e+a58Nk/CpKqnOq8BG/sAHCFU2T/ q/nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=grnS0NyhB05vK2ZTZaziKZn0SyUiyuOq4AL10Yv05J4=; b=V/dYOrSEqtHvhrGwurGdxTLsR26Zc5j4sIYSSZQRix3KBbdkudxzVhzUmwchiERUNO wt6FWFgxFhaphEsqY5FWjmM3ZoUbW4/8tp+BFy3lpIjxassqGzBK5sviWy9urdeicqji QswXSIyo5YCYRwW8u1ddcAdlO9QtJ6K6lk/6XhKFJe0L+JrYWmyteEOjbWXsJXNwfhCo 7Yw3465yZqRJkEmDigGiO1ySl0jlzpQrD0fZWlDrQZ6I2NkkL1xQb8upMRNpFo9NyZvZ /P4xTMrP+Afj6hw+g5POFH33kbCJgEzwTwfIE4yr3oh0rLCi4LUgBX1Am5daZA5O4nw3 O4JQ==
X-Gm-Message-State: AJcUukf/Y2OHBHgnak0zim013qLI1cVqM3V24fMns9SynKvaG54zfI8o z9yyX/SpyuswQJ0vvVtn5+fBRmWkpbkaRiCjrT0=
X-Google-Smtp-Source: ALg8bN6SYcXtB9jTld5TnoDyS9/MDbvxVUTdxTAmVpKU0Gzlre7rptv579GC6iSsaO1qALE+FMuK2MKKRO37vLFhI3E=
X-Received: by 2002:aca:1b0a:: with SMTP id b10mr7938546oib.192.1548724216096; Mon, 28 Jan 2019 17:10:16 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ted Hardie <>
Date: Tue, 29 Jan 2019 10:09:48 +0900
Message-ID: <>
To: Eric Rescorla <>
Cc: Justin Uberti <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000c16d5905808e74bf"
Archived-At: <>
Subject: Re: [rtcweb] Proposal to break the ICE impasse
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, 29 Jan 2019 01:10:20 -0000


On Tue, Jan 29, 2019 at 9:56 AM Eric Rescorla <> wrote:

> On Mon, Jan 28, 2019 at 4:47 PM Ted Hardie <> wrote:
>> On Tue, Jan 29, 2019 at 9:36 AM Eric Rescorla <> wrote:
>>> If we assume that this is a real problem as opposed to a specification
>>> problem, then I agree this is reasonable. However, so far nobody has shown
>>> me that this is a real problem, and until that this happens, I'm not in
>>> favor.
>> As a chair, I wish to confirm my understanding:  you have no technical
>> objection to this solution, but you do not wish to include this because you
>> have seen no evidence of the problem.  Is that correct?
> No. I object to it because it's unnecessary complexity and moves against
> the consensus direction that we had that this field was meaningless.
> That consensus was limited to JSEP; other related uses of SIP/SDP do not
treat it as meaningless.

The additional complexity added to a system is, of course, always a
concern.  But  I interpret your statement "If it's necessary, then I'm
willing to live with it." as agreeing that this solution will work if the
additional domain of interoperability which results is not empty.

Please correct me, if I have gotten this wrong.



>> On Mon, Jan 28, 2019 at 2:51 PM Justin Uberti <> wrote:
>>> Posted as a stab at a
>>> consensus. This basically says that the offerer fills in either UDP/TLS/foo
>>> or TCP/DTLS/foo based on the current default or selected candidate, in
>>> accordance with sip-sdp. As Adam mentioned before, this shouldn't have any
>>> impact on JSEP functionality.
>>> If this looks good, I'll polish it up.
>>> On Sun, Jan 27, 2019 at 3:22 AM Christer Holmberg <
>>>> wrote:
>>>> Hi,
>>>> > I'm not yet persuaded this is needed. The alleged need here is that
>>>> there are some ICE-implementing endpoints which will choke if
>>>> > they see a profile that doesn't match any actual candidate. I
>>>> recognize that this is required by 5245, but that doesn't mean anyone
>>>> > ever did it. Can you please point me to a client which would
>>>> interoperate with a WebRTC endpoint with this change that would not
>>>> > if you just always sent the same profile as JSEP currently requires.
>>>> I don't think it is ok to *specify* that discarding a MUST is ok as
>>>> long as nobody can show an implementation that would break by doing so.
>>>> Having said that, in order to prevent an RTCWEB shutdown I am generally
>>>> ok with Adam's approach. I would like my pull request comments to be
>>>> addressed, though, that is related to separation between the JSEP API and
>>>> an application using it: an application should be allowed to act according
>>>> to 5245/draft-ice-sdp and update the c/m line if it wishes to, but due to
>>>> the way the JSEP API works such applications might sometimes always include
>>>> the same value in the c/m- line.
>>>> I also think it shall be explicitly written that JSEP does not update
>>>> 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line.
>>>> Regards,
>>>> Christer
>>>> On Thu, Jan 24, 2019 at 11:12 AM Adam Roach <> wrote:
>>>> Based on conversations in MMUSIC, as well as several offline
>>>> conversations with interested parties, I've put together a proposed
>>>> change to JSEP that, if accepted, will allow publication of the Cluster
>>>> 238 documents to move forward.
>>>> Note that this new text has no impact on existing implementations (at
>>>> least, as far as I am able to discern), which do not currently have the
>>>> capability of producing media sections consisting of exclusively TCP
>>>> candidates. From that perspective, the change makes existing
>>>> implementations no less compliant with JSEP than they were before.
>>>> What this change does provide is both on-paper and in-the-future
>>>> compatibility between WebRTC implementations once they finalize TCP
>>>> candidate handling (and candidate handling in general for mid-session
>>>> offers).
>>>> The key insight here is that JSEP's use of ICE completely discards any
>>>> meaning associated with the transport parameter, while SIP's use of ICE
>>>> does not. The trivial change that I propose, which bears only on future
>>>> WebRTC implementations -- that is, which has no as-built specification
>>>> to point to -- allows JSEP to continue to ignore the value of the
>>>> transport parameter, while specifying that it says the right thing for
>>>> SIP implementations to function properly.
>>>> /a
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> _______________________________________________
>>>> rtcweb mailing list
>>> _______________________________________________
>> rtcweb mailing list