IETF Logo Mail Archive

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

Eric Rescorla <ekr@rtfm.com> Tue, 17 January 2017 00:21 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 4B1A81293F0 for <mmusic@ietfa.amsl.com>; Mon, 16 Jan 2017 16:21:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.876
X-Spam-Level:
X-Spam-Status: No, score=-0.876 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, URIBL_SBL=1.623, URIBL_SBL_A=0.1] 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 Pfe-oXiN6d55 for <mmusic@ietfa.amsl.com>; Mon, 16 Jan 2017 16:21:34 -0800 (PST)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 72EE4126579 for <mmusic@ietf.org>; Mon, 16 Jan 2017 16:21:34 -0800 (PST)
Received: by mail-yw0-x22e.google.com with SMTP id l19so78010726ywc.2 for <mmusic@ietf.org>; Mon, 16 Jan 2017 16:21:34 -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=7tfgnRS/scN0YbnQJ6Ie2mYXS6PnVGtskz+zrQQTq4I=; b=rkQJx/brEvY+4ioObZQ/8g8vGPEu+7RIAkRUIDcI1kUCSLo8/02swmMPSsF8A1kT/w 9wUmhGRj6/XDAbElB13MCZkrQ4Q0+u9mg47zsZTC2zvUT5JKblgwYeagVXJXrdgo1tSy PsljcL1nIDfw0y3694RFvSHhP7CpwwE9OleDKbRE2uSkgfy1e+eSkPoO64OvHV6FZeXK oRPVHqnW9JSAXhYN86R4tGWHehx/z/dL4Gf/0n2AIhtqz/RzWl7Byxv389P1KPFIdfyQ X6vv4O8oMpGUMD6EEvyrV0KkggvTenKdJSohxlhIJ0QRvQ7erODvr5bFI/gFA1kySH0/ jybg==
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=7tfgnRS/scN0YbnQJ6Ie2mYXS6PnVGtskz+zrQQTq4I=; b=d5KQ7I/p3nCM8Kj2HqUd30qehmYgrSoKC9Z1uJnTCBypWUpkO5XgKMYIMlqpBO5uuX /HCI42z7CoPD/BIq+zkvmj1z7zT7fy2+J14mAS/SaC/PSQg/YJ5tTFdBBHNqchTkuhbl etyazV2RZPHTqGP9SThnB9z4UJ0R/xykJvj5EmkMK48T4M/BaMxFNuZJUe3qykeA4cIa SJrqwwJHCRijDr/Acrm//yHbr9faWl+TdURhGIxLAHxjkcwJmuaPDusPjPztpeTPT5mn hgUKrL9ZieOW3/zcmKkxsHDjEwDpJlfc6i8959wvNCZ2XvuUG85G74W86MMEH4mbOG++ thjQ==
X-Gm-Message-State: AIkVDXLfAYi+JjLUY++miZyxztfbeolhCuuL6wsKP31TzYDOkHokvWb4JBqlbeuqbO0dP5g3jYnC6EJVTUIGYQ==
X-Received: by 10.129.73.139 with SMTP id w133mr26751483ywa.146.1484612493769; Mon, 16 Jan 2017 16:21:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.204.80 with HTTP; Mon, 16 Jan 2017 16:20:53 -0800 (PST)
In-Reply-To: <CAD5OKxuqBeE3VkpRp-Leyyf1nzh2wwPG0giwbtcFOwJ8AecG8w@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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 16 Jan 2017 16:20:53 -0800
Message-ID: <CABcZeBOrPzqKh2CWMqHCz8vFLvT20WDqL7_FK=SPnZ_PXn_P_A@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Content-Type: multipart/alternative; boundary="001a114dac0e5257b705463f481a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/3iWBeN73yEuZ7YAkmFvh_la23UI>
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:21:36 -0000

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

> On Mon, Jan 16, 2017 at 6:59 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>> On Mon, Jan 16, 2017 at 3:37 PM, Roman Shpount <roman@telurix.com> wrote:
>>
>>> For JSEP, is there a reason not to require UDP/TLS/RTP/SAVPF and
>>> UDP/DTLS/SCTP in both the offer and the answer?
>>>
>>>
>> As an answerer, you may get TCP/<blah> from non-JSEP endpoints and the
>> consensus was that echoing them was better
>>
>>
> Is there a reason why this would ever happen?
>

It's permitted behavior.



> You use ICE TCP to go through UDP firewalls when communicating with a
> server on a public IP. Why would you ever do only tcp candidates in offer
> or answer? This is inefficient and will work worse then offering both udp
> and tcp candidates. I am all for options, but they should have some reason
> for existence. I see no reason why TCP/anything would ever be used for JSEP
> offer/answer, unless ICE is complete and tcp candidate pair is selected.
>

Well, as I stated above, this isn't about what JSEP endpoints offer but
what they answer
when other endpoints send TCP/<blah>, however foolish you might think it is.


> BTW, we made UDP required protocol for default candidates for
> UDP/DTLS/SCTP. I see no reason not to do the same thing for
> UDP/TLS/RTP/SAVPF at least in JSEP. It will only make things interop with
> non JSEP endpoints better.
>

What's the evidence that answering TCP/TLS/RTP/SAVP with UDP/TLS/RTP/SAVPF
will improve interop?

-Ekr


> Regards,
> _____________
> Roman Shpount
>
>

v2.23.0 | Report a Bug | By Email