Re: [MMUSIC] JSEP Issue #394: What appears in m= lines.

Eric Rescorla <ekr@rtfm.com> Tue, 17 January 2017 01:15 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8B812994F for <mmusic@ietfa.amsl.com>; Mon, 16 Jan 2017 17:15:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUBrWJI3SApE for <mmusic@ietfa.amsl.com>; Mon, 16 Jan 2017 17:15:47 -0800 (PST)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549EF12994E for <mmusic@ietf.org>; Mon, 16 Jan 2017 17:15:47 -0800 (PST)
Received: by mail-yb0-x230.google.com with SMTP id j82so21832359ybg.1 for <mmusic@ietf.org>; Mon, 16 Jan 2017 17:15:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UY5zj/69JN/Ethnld32RAEimoahEYEBgaOIiHCxLpyw=; b=WJXS36BzfR6Bi/KYNzWob+Fkyg+k9loW6cQqGkpJhCcgUPTnq2ycjo7skXkTM6zq+C g0uuxLmpFFvg2Co9HtL4+rPmONGhGb0ygB1dhoUjOjXZt1jVGPdQ54U9FbTbl7kfvWyK k4XW4iMDzuuRDtLlriVRJdlWoNZPn0hOg19W8MX2/0jg57Ms56faCopaTyvvKrtJrHyh 3Pj+Zutwo3KFQHL1nlgIAuBDsjJA3xscVGX8OJRYnOoaTjALD85KdxUkLq8XTsPRnFQf bSsn9m7Y2YW1CqagITnHLAv+NI+l4mAzKibd2ButbSO31ZOm8e5L3/uJ5Tmb0V1ymjeD iKgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UY5zj/69JN/Ethnld32RAEimoahEYEBgaOIiHCxLpyw=; b=Ehm4yMUuk2+ci3/xSkdWicMN8EO5D2748GhHed4trHZCBzTQIXrNFCFPayjMCZFyFv gJL5k0tsLt43iyQ/NxSN9Kzj7r2gBWGYw59ZzQyTEWnBRsmXTNSrUEJUhQg16biw52Ks 8L/D55u3rF6UNFtx9PwAb5YwkzvCfC4nHSegNqw8aKeiW17WgbvMJqDljOEINdR9xg10 nc71cQrqhdot5UexJign9lyVxVdCrkROM+8PhcJ8GSTm0LstEnXPLvAhzJOeNAE+7FqE lINpA3RNvABxHfcxu0bRaJ/7rUJJsx6ea/CQktJX5YYK0rX7/BGj4XC3KPhgXEm28/xE syTQ==
X-Gm-Message-State: AIkVDXL9EOZzv/TTX4GtTIVovx7ssQq1IxbmdswJ6NlWB2ceI6xKgW7QX6zGgAbrIY3XnfpEoKMjCSDuvX2nSw==
X-Received: by 10.37.246.10 with SMTP id t10mr24590875ybd.107.1484615746608; Mon, 16 Jan 2017 17:15:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.204.80 with HTTP; Mon, 16 Jan 2017 17:15:06 -0800 (PST)
In-Reply-To: <CAD5OKxtST7PN8v=K5G0JYoaK5yt+Fjdio=qJrGRbNOE4CAvSew@mail.gmail.com>
References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <CABcZeBPznLKNHek-SGE5Ly6QTOBL-j65sZBb5MbwQVkmBkpyFw@mail.gmail.com> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> <CABcZeBPtMMR-xC_=pr1umBWY1CPkAm1J=T=Q_1F1bLNkZwtJkg@mail.gmail.com> <D4A2966B.15C88%christer.holmberg@ericsson.com> <CABcZeBOS+b_bdgaTnQfsNAhdf7g=fspyYON2r5=BoKvPD-32Rw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4BF78DE0@ESESSMB209.ericsson.se> <CAD5OKxtN=sHrGoQU9D=WLXWQwNpCqOT5P6ZwhkaS1945VnTT-Q@mail.gmail.com> <CABcZeBN+MGKD_opEq7bKeafb46o3=jKyMEKLDKQ-Mj8a5eezyg@mail.gmail.com> <CAD5OKxuqBeE3VkpRp-Leyyf1nzh2wwPG0giwbtcFOwJ8AecG8w@mail.gmail.com> <CABcZeBOrPzqKh2CWMqHCz8vFLvT20WDqL7_FK=SPnZ_PXn_P_A@mail.gmail.com> <CAD5OKxtST7PN8v=K5G0JYoaK5yt+Fjdio=qJrGRbNOE4CAvSew@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 16 Jan 2017 17:15:06 -0800
Message-ID: <CABcZeBMP4SdneHo6Bh6Y-gu2wLAhrKFGMyGW2wis9MqpaJG-Pg@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Content-Type: multipart/alternative; boundary=f403045dc8583490b10546400ad7
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/GNYlGOkrSnZg_sp5J19XrM4eupo>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, mmusic WG <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jan 2017 01:15:49 -0000

On Mon, Jan 16, 2017 at 4:53 PM, Roman Shpount <roman@telurix.com> wrote:

> For clarity, this is what I would suggest for JSEP:
>
> JSEP end point MUST send an offer with UDP/DTLS/SCTP and UDP/TLS/RTP/SAVPF.
>

Yes.


If JSEP end point receives an offer with UDP/DTLS/SCTP or
> UDP/TLS/RTP/SAVPF, it MUST respond with the same proto
>

Yes.



> and MUST include udp candidates (and use udp as a default candidate if
> JSEP endpoint is providing default candidates).
>

No, I don't agree with this. It should offer whatever candidates it wants
and/or are determined by policy. For example, if the implementation is set
to relay-only, it will be restricted to whatever the TURN relay will do.


If JSEP end point receives an offer with TCP/DTLS/SCTP or
> TCP/DTLS/RTP/SAVPF, it MUST respond with the same proto
>

Yes.



> and MUST include tcp candidates (and use tcp as a default candidate if
> JSEP endpoint is providing default candidates).
>

No, I don't agree for the reasons above.




If non JSEP end point responds with a protocol that does not match the
> offer, this is considered an error regardless of the ICE candidate supplied
> in the answer.
>
> So, what I want is for JSEP not to generate offers with TCP/blah and not
> to generate answers were protocol does not match the protocol in the offer,
>

Yes.



> or does not match ICE candidates provided. I think this will improve
> interop and can be satisfied by all existing implementations.
>

I don't think trying to match the candidates to the proto line is useful,
especially when you are doing trickle ICE.

-Ekr


Generic requirements for ICE outside of JSEP can be more complex since we
> need to explain what will happen when end point receives an offer with
> TCP/blah but does not support TCP candidates. Also, outside of JSEP, things
> like ICE mismatch come into play. This, of cause, can be discussed and
> decided elsewhere, not in JSEP.
>
> Regards,
> _____________
> Roman Shpount
>