Re: [rtcweb] Default proto transport in JSEP

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF98A130DDB for <>; Mon, 19 Nov 2018 12:47:59 -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 Xcgj2L8ekInY for <>; Mon, 19 Nov 2018 12:47:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BB90130DE2 for <>; Mon, 19 Nov 2018 12:47:57 -0800 (PST)
Received: by 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;; 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;; 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 ( []) by with ESMTPSA id m11sm28022520pgh.51.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 12:47:56 -0800 (PST)
Received: by 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-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

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

> 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
> that indicate that they are cosmetic instead of creating some rules on how
> these fields should change which would cause potential interop issues.
> I suggest:
> m=KIND 9 ICE [codec PTs]

If you are re-inventing the protocol, why would you build SDP or m= 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=audio 9 UDP/TLS/RTP/SAVPF [codec PTs]
c=IN IP4

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= or m= 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
Some people for some reason insist on following specifications. If you
propose to do two opposite things, random things start being implemented.

Roman Shpount