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

Roman Shpount <roman@telurix.com> Tue, 17 January 2017 00:53 UTC

Return-Path: <roman@telurix.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 4925F12968D for <mmusic@ietfa.amsl.com>; Mon, 16 Jan 2017 16:53:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 AeNxllDSbyCJ for <mmusic@ietfa.amsl.com>; Mon, 16 Jan 2017 16:53:25 -0800 (PST)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 D1261129675 for <mmusic@ietf.org>; Mon, 16 Jan 2017 16:53:24 -0800 (PST)
Received: by mail-qt0-x230.google.com with SMTP id v23so130250226qtb.0 for <mmusic@ietf.org>; Mon, 16 Jan 2017 16:53:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/fGoS2KmAszwCzCyMti+AW3DMWFd8QGqnr4DOaDESD4=; b=QyHnc8eA2g2SkLVtiDDeFKg89fHgumoF0MyUB92jsMRxSvfIL0HnEnuAE249IQdwD4 Tn7UHBtlPGFW4MPmvz/3Oty/FxirWCWooYod7Blqy/DHzNaIfA4FbZFVZ1LoAtgl47FW 8Q91Bc7Q/l+9Vzqdv+tXqS0qPdUZ2aYDReFv0HsYC5kc0X0A2p8WuFS66sEHmANFd1Qe W5Re84MFKsi10v4hPPGsxrwrPNPnvSzaS0/TvCmI77vq+57NzkdRPmXixJEp3+/J7vxe IkHEVV/KSP11R+5LdHXDJfFbEO9x4zwgtYqT3EjdgYY4AvsLRn7VC0UcR3pkjrZtIbqk +bTA==
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=/fGoS2KmAszwCzCyMti+AW3DMWFd8QGqnr4DOaDESD4=; b=tEyXovZYPs6EjuHN2zTlRV++3podd6YP7+zxADQ6ba1bed0X364V0lozWbc/tIAorx LChnybRAGX8nIalzmkDtcasZzU72LwBSuqbm4BE44o7AePqn7xFl8zn8sfpU5MK7evgZ 39BX0AYPOwzfh7UGvDh6Wd25DxiyY2+gPRjhyq234ddSa7F8lgS6f3LHgebk3I4uav6N hWIx3G+erHDzP1kdEdMDAQRK/AI1FpM7afsHawF5gnVeM2wznKhXChrQb6tZ1/nnVjtO B3HJRucHHBzaReoXs9E7N3uCwvPsmLjCU/DrMsOTyH4NZylxkHF/mOPyfj2o68FFbJUz QPtw==
X-Gm-Message-State: AIkVDXKSg4bqbSMXMpmPKw636ohf1ofHrwwGvjCrc4mb2Bssc2lwlpsr2MBC/FqxnsDk9Q==
X-Received: by 10.55.152.69 with SMTP id a66mr33196897qke.172.1484614403859; Mon, 16 Jan 2017 16:53:23 -0800 (PST)
Received: from mail-qt0-f171.google.com (mail-qt0-f171.google.com. [209.85.216.171]) by smtp.gmail.com with ESMTPSA id w138sm17506064qka.27.2017.01.16.16.53.23 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 16:53:23 -0800 (PST)
Received: by mail-qt0-f171.google.com with SMTP id k15so130414621qtg.3 for <mmusic@ietf.org>; Mon, 16 Jan 2017 16:53:23 -0800 (PST)
X-Received: by 10.200.47.129 with SMTP id l1mr31095385qta.148.1484614403178; Mon, 16 Jan 2017 16:53:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.147.79 with HTTP; Mon, 16 Jan 2017 16:53:22 -0800 (PST)
In-Reply-To: <CABcZeBOrPzqKh2CWMqHCz8vFLvT20WDqL7_FK=SPnZ_PXn_P_A@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>
From: Roman Shpount <roman@telurix.com>
Date: Mon, 16 Jan 2017 19:53:22 -0500
X-Gmail-Original-Message-ID: <CAD5OKxtST7PN8v=K5G0JYoaK5yt+Fjdio=qJrGRbNOE4CAvSew@mail.gmail.com>
Message-ID: <CAD5OKxtST7PN8v=K5G0JYoaK5yt+Fjdio=qJrGRbNOE4CAvSew@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=001a113776f221612a05463fbaea
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/6FQa_FmwYfE6xZ2PdW5HrB_31LA>
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 00:53:26 -0000

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.

If JSEP end point receives an offer with UDP/DTLS/SCTP or
UDP/TLS/RTP/SAVPF, it MUST respond with the same proto and MUST include udp
candidates (and use udp as a default candidate if JSEP endpoint is
providing default candidates).

If JSEP end point receives an offer with TCP/DTLS/SCTP or
TCP/DTLS/RTP/SAVPF, it MUST respond with the same proto and MUST include
tcp candidates (and use tcp as a default candidate if JSEP endpoint is
providing default candidates).

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, or
does not match ICE candidates provided. I think this will improve interop
and can be satisfied by all existing implementations.

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