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

Harald Alvestrand <harald@alvestrand.no> Tue, 10 January 2017 16:12 UTC

Return-Path: <harald@alvestrand.no>
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 D0538129BC5 for <mmusic@ietfa.amsl.com>; Tue, 10 Jan 2017 08:12:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.399
X-Spam-Level:
X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
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 FIUJdnn0wxHi for <mmusic@ietfa.amsl.com>; Tue, 10 Jan 2017 08:12:34 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DAB71295DE for <mmusic@ietf.org>; Tue, 10 Jan 2017 08:12:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5986C7C4E13; Tue, 10 Jan 2017 17:12:32 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q68jdpCpu8wt; Tue, 10 Jan 2017 17:12:31 +0100 (CET)
Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 6A7A07C4E12; Tue, 10 Jan 2017 17:12:31 +0100 (CET)
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, mmusic@ietf.org
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>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <352cc52c-0c52-9332-a7ce-4533aed6c2fd@alvestrand.no>
Date: Tue, 10 Jan 2017 17:12:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/SytAkRS1qMJK5mJ0La8r97Oorjg>
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, 10 Jan 2017 16:12:37 -0000

Den 10. jan. 2017 16:44, skrev Magnus Westerlund:
> Den 2017-01-02 kl. 14:42, skrev Harald Alvestrand:
>> Den 22. des. 2016 18:30, skrev Eric Rescorla:
>>>      __
>>>
>>>     Okay, I agree that having any rules for what you should offer here
>>>     based on what the actual outcome is not the best idea here. I think
>>>     the rules should be based on capability and intent. So if you only
>>>     are going offer TCP candidates, then you clearly should use TCP/…,
>>>
>>>
>>> I'm going to push on this. If we've already agreed that mismatches are
>>> normal, why should we do that? Wouldn't it be better to just effectively
>>> deprecate this field?
>>>
>>
>> Concur with EKR.
>>
>> This field (the TCP/UDP part of the protocol field) was defined in a way
>> that makes its original purpose (to negotiate profiles) not only
>> impossible while using ICE, but actively harmful, because you end up
>> telling lies in very many cases, so people will have to accept things
>> that don't match reality.
>>
>> Make the world as simple for implementors as possible: Send a fixed
>> string, and accept all strings.
>>
> 
> Okay, can we please be precise with what is suggested here. Because what
> you write above, and what EKR proposed is not really the same thing. The
> issue proposed that it was fine to set either of the strings. You saying
> a fixed string. I want to ask you which UDP/... or TCP/..., or even
> ICE/DTLS/RTP/SAVPF?

The current JSEP language is:

5.1.3.  Profile Names and Interoperability

   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.
   For data m= sections, JSEP endpoints must support both the "UDP/DTLS/
   SCTP" and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two
   profiles for each data m= line they produce in an offer.  Because ICE
   can select either TCP or UDP transport depending on network
   conditions, both advertisements are consistent with ICE eventually
   selecting either either UDP or TCP.

The current proposal (as I interpret EKR) is to replace

        ....and MUST indicate one of these two
   profiles for each data m= line they produce in an offer.  Because ICE
   can select either TCP or UDP transport depending on network
   conditions, both advertisements are consistent with ICE eventually
   selecting either either UDP or TCP.

with

            ....and MUST indicate UDP/TLS/RTP/SAVPF for each data m= line
   they produce in an offer.  Because ICE
   can select either TCP or UDP transport depending on network
   conditions, this consistent with ICE eventually
   selecting either either UDP or TCP.

> 
> From a strict clarity issue using ICE/... would be my preferred. But,
> that is probably going to throw some implementations, especially
> gateways. It will also require us to actually go write the registration
> to explain what it is.

We lost clarity when ICE was introduced without redesigning the
"protocol" field. Trying to get it back is not helping anyone.

> 
> Using UDP is likely the most compatible and will only fail in gateway
> cases where there are no UDP candidates and the gateway fail to pick
> that up.
> 
> Using TCP when there are no TCP candidates are equally misleading to
> gateway cases.
> 
> The above is why I proposed that implementation capabilities and any
> configuration to limit what functions being used would be an appropriate
> choice.
> 
> I hope at least we can agree that an JSEP Answer MUST use the PROTO
> string of the OFFER?

We agreed on that long ago.

Section 5.3.1 of JSEP:

   o  The <proto> field MUST be set to exactly match the <proto> field
      for the corresponding m= line in the offer.