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

Roman Shpount <> Wed, 28 November 2018 18:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17C8C130E6E for <>; Wed, 28 Nov 2018 10:41:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.347
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8OPWt-o3o0rk for <>; Wed, 28 Nov 2018 10:41:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 62B31128A6E for <>; Wed, 28 Nov 2018 10:41:46 -0800 (PST)
Received: by 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;; 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;; 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 ( []) by with ESMTPSA id q7sm7747760pgp.40.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Nov 2018 10:41:44 -0800 (PST)
Received: by 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: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
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-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

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

> 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.

Roman Shpount