Re: [rtcweb] Default proto transport in JSEP

Roman Shpount <> Mon, 19 November 2018 20:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 790A21292F1 for <>; Mon, 19 Nov 2018 12:02:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.89
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JU0mDV1gvacw for <>; Mon, 19 Nov 2018 12:02:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0C47130DE2 for <>; Mon, 19 Nov 2018 12:02:20 -0800 (PST)
Received: by 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;; 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;; 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 ( []) by with ESMTPSA id s2-v6sm87553572pfk.133.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 12:02:20 -0800 (PST)
Received: by 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-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

On Mon, Nov 19, 2018 at 2:36 PM Iñaki Baz Castillo <> wrote:

> On Mon, 19 Nov 2018 at 19:28, Roman Shpount <> wrote:
> > 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.
> We could just assume that no WebRTC capable endpoint will (absolutely
> never) rely on the content of the c= line or the proto indicated in
> the m= 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= 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=
and m= 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= and m= line
but does not achieve the interop.

Roman Shpount