Re: [rtcweb] [MMUSIC] Default proto transport in JSEP

Justin Uberti <> Wed, 28 November 2018 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43E27130F97 for <>; Wed, 28 Nov 2018 10:59:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -18.958
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id owZdZq9HO--p for <>; Wed, 28 Nov 2018 10:59:08 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACD31130EBC for <>; Wed, 28 Nov 2018 10:59:08 -0800 (PST)
Received: by 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;; 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;; 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: <> <> <> <> <> <> <> <> <> <>
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 <>,
Content-Type: multipart/alternative; boundary="00000000000020412d057bbe290d"
Archived-At: <>
Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP
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

Regarding the current conflict between 5.1.2 and 5.2.2, this is discussed
in, 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,
where this topic was previously litigated. That email thread concluded with
the message in,
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’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.
>  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 (
> Each "m=" and c=" line MUST be filled in with the port, *protocol*, and
> address of the default candidate for the m= section, as described in
> [I-D.ietf-mmusic-ice-sip-sdp], Section
> At the same time section 5.1.2 says (
> <>):
> For media m= sections, JSEP implementations MUST support the
> "UDP/TLS/RTP/SAVPF" profile specified in [RFC5764], and MUST indicate this
> profile for each media m= line they produce in an offer. For data m=
> sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MUST
> indicate this profile for each data m= line they produce in an offer.
> So, section 5.2.2 says m= 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/SAVPF"
> 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 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
> 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
>, 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