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

Eric Rescorla <ekr@rtfm.com> Fri, 16 December 2016 17:06 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 9F7D4129874 for <mmusic@ietfa.amsl.com>; Fri, 16 Dec 2016 09:06:20 -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 JCqx5tCsbCVK for <mmusic@ietfa.amsl.com>; Fri, 16 Dec 2016 09:06:18 -0800 (PST)
Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 F33DD1299AB for <mmusic@ietf.org>; Fri, 16 Dec 2016 09:06:15 -0800 (PST)
Received: by mail-yb0-x233.google.com with SMTP id v78so40751277ybe.3 for <mmusic@ietf.org>; Fri, 16 Dec 2016 09:06:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=D2zmDjMhGjHyH8GpyDq61sV2LVNyOFrU7pz/z/iFZPY=; b=08eT/sRZQDILPVtNG2moS+GNCLkrWDQGkkT2LhcavelSvPwEiX9u+hIu5hgW9hbFUx Gm1L98gQd/IWJpgmnT+Q0SEla5rhZo6YCFOqRQ5EdfXQFb7tWPGj/DXQSCnbQWZSahqH 6tAWjtX0fi14JzWd/EDrJeS4pyLi/vRxdzTJEvQvzL+tLVQy0BL0S1XujKEAcy0AMGnr U843/oMsR4hFm4r0lGzkw3c+i9D7nlB7kt64IP+BV0l8l5gPIsDyrrySJh4YtFzgMvLq 9y2/lJXVV6dsQIv4DXlykSC3I5rMcxzrV+lIWNnjxCQ0w72d5TM+um6jQXx8RJrRcPRv 0YJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=D2zmDjMhGjHyH8GpyDq61sV2LVNyOFrU7pz/z/iFZPY=; b=GDlz5tGUS5f9zA3i3rJDxZVMk5YaY4lLd7f6OEgTd2kc6mDyK3jdEIjZ1BjK3VGFcn QmuVDTZbPiLCVAfhYwpBnmGnKd/8+tpWIn09FuI5ZQCY5t8bQC6QYS0Z1JfOTbzVc1a7 Nbypvb5ZF+6nLwVVa7P6p3PmW+5oZoGZKfTMCK06jKuBR36Hrn6S8/C54mOadRZrdJvr mjdNnFiikGZ8FgTPTXrItQhZMzSAY6gXkaOBvjEZ37cZfs+TMrpkgl+RY0CDjsXMTwxR Ta/eVkI5digFoYGLrIvd3kxPGV0OCKKXfAS5/+pgmVrvDPrQ5D7DO3J1mPjQlhiLOzI5 h/NA==
X-Gm-Message-State: AIkVDXJwT+7ImXsXoAUUHNMx3A//uZbQhDf8knfVFkhAdu0yQtSXz0bPBr1XzyPzKWNOLOVjOtGWyAjDrb714g==
X-Received: by 10.37.160.41 with SMTP id x38mr3089084ybh.64.1481907975177; Fri, 16 Dec 2016 09:06:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.164.210 with HTTP; Fri, 16 Dec 2016 09:05:34 -0800 (PST)
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 16 Dec 2016 09:05:34 -0800
Message-ID: <CABcZeBNt+Qua__vtxHWD3YNTkqxitZyokTXk7SfWty+2OOXpng@mail.gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c1a06507380480543c9966c
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/gR-dYY1GzN3fIA_XlHiX-bB6nLM>
Subject: [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: Fri, 16 Dec 2016 17:06:20 -0000

https://github.com/rtcweb-wg/jsep/issues/394

Magnus writes:
>
> >    For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/
> >    RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of
> >     these two profiles for each media m= line they produce in an offer.
>


> Do I understand this correct, we are requiring support for the
> "TCP/DTLS/RTP/SAVPF" proto so that in cases an endpoint supports the
> optional to support ICE TCP, they can indicate it, and any WebRTC endpoint
> will accept it, even if that is just one option? I do know that different
> profiles are a negotiation issue. But, wouldn't it be more reasonable in
> this case to use UDP/TLS/RTP/SAVPF in all cases where one offer any
> candidates that also use UDP? And only use TCP/DTLS/RTP/SAVPF in cases only
> TCP candidates are signalled, thus not forcing TCP/DTLS/RTP/SAVPF onto
> clients that doesn't support it?"


We could certainly do this, but it seems to perpetuate the idea that the
TCP/UDP distinction is

meaningful here, which seems like the opposite direction from the one we
are going in (see

the mmusic minutes around the topic Non-Supported Transport in m- line).
See also the note below in this paragraph about either profile being
consistent with either transport.


I think it would be fine to relax the requirement that implementations
*support* both UDP and TCP, but requiring them to conditionally use one or
the other depending on whether they have UDP candidates seems like it's
really going to impose a lot of pain on implementors for no good reason, in
part because you don't necessarily know at the time of offer generation
what you will have. Consider the case where you are only offering relayed
and srflx candidates. At the time of generation, you don't know if you will
be able to get a UDP candidate, because you might be behind a firewall that
blocks UDP and your TURN server might be down.


If we make any change, I think it should just be to relax the requirement
to support TCP and then tell people to ignore the first field here in favor
of the candidate lines.


-Ekr