Re: [MMUSIC] JSEP Issue #394: What appears in m= lines.
Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 10 January 2017 15:44 UTC
Return-Path: <magnus.westerlund@ericsson.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 AD0A8129507 for <mmusic@ietfa.amsl.com>; Tue, 10 Jan 2017 07:44:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 tcIAm6V9xTs2 for <mmusic@ietfa.amsl.com>; Tue, 10 Jan 2017 07:44:26 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E621F129504 for <mmusic@ietf.org>; Tue, 10 Jan 2017 07:44:25 -0800 (PST)
X-AuditID: c1b4fb3a-46fff70000005d1c-e5-58750157b06e
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id A5.96.23836.75105785; Tue, 10 Jan 2017 16:44:24 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.319.2; Tue, 10 Jan 2017 16:44:23 +0100
To: Harald Alvestrand <harald@alvestrand.no>, mmusic@ietf.org
References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <CABcZeBPznLKNHek-SGE5Ly6QTOBL-j65sZBb5MbwQVkmBkpyFw@mail.gmail.com> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com>
Date: Tue, 10 Jan 2017 16:44:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM2K7pW4EY2mEwaJ2TotjfV1sFlOXP2Zx YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKmTlvPVLBRpKK5V6aBsVegi5GTQ0LAROL1 7t+MXYxcHEIC6xgltp+9ygSSEBJYzijxvbUUxBYWcJA4tnMtC4gtImAvMb9nOTtEw2lGiaO3 LzGCJNgELCRu/mhkA7F5gYp2ff0AFmcRUJV4deok2FBRgRiJt+tBmkFqBCVOznwCNpRTwFFi 95qzrF2MHBzMQL0PtpaBhJkF5CWat85mhrhHW6KhqYN1AiP/LCTdsxA6ZiHpWMDIvIpRtDi1 uDg33chIL7UoM7m4OD9PLy+1ZBMjMPQObvlttYPx4HPHQ4wCHIxKPLwfvpVECLEmlhVX5h5i lOBgVhLhjf0PFOJNSaysSi3Kjy8qzUktPsQozcGiJM5rtvJ+uJBAemJJanZqakFqEUyWiYNT qoFxbV54i0riJM281VL2vBZXNi24+CHtxh+OnS98p/4//su1aX/p0XNfD8+NclumOX2a2it5 y19xxkb/8+LU3jI5zbDI89mvdG3tjzRe0+O/8nx3sKyMSbEuecyjWMM1+4GT0kSp7JuNnx8/ n8pr6ltkc/veyt7OdZ949679suzH8kdzE5adtXCbq8RSnJFoqMVcVJwIAD/YoHw5AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/ObbhdMGHojLEMGcOTEXPldt2TVk>
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 15:44:27 -0000
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? 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. 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? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [MMUSIC] JSEP Issue #394: What appears in m= line… Eric Rescorla
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Magnus Westerlund
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Eric Rescorla
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Harald Alvestrand
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Magnus Westerlund
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Magnus Westerlund
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Harald Alvestrand
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Paul Kyzivat
- Re: [MMUSIC] [rtcweb] JSEP Issue #394: What appea… Jonathan Lennox
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Roman Shpount
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Paul Kyzivat
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Roman Shpount
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Paul Kyzivat
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Magnus Westerlund
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Eric Rescorla
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Christer Holmberg
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Eric Rescorla
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Christer Holmberg
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Roman Shpount
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Eric Rescorla
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Roman Shpount
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Eric Rescorla
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Roman Shpount
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Eric Rescorla
- Re: [MMUSIC] JSEP Issue #394: What appears in m= … Roman Shpount