Re: [MMUSIC] Transport tags

Roman Shpount <roman@telurix.com> Thu, 12 January 2017 21:28 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 68586129499 for <mmusic@ietfa.amsl.com>; Thu, 12 Jan 2017 13:28:01 -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 IR9mhddlAZVX for <mmusic@ietfa.amsl.com>; Thu, 12 Jan 2017 13:27:59 -0800 (PST)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 B31741289B0 for <mmusic@ietf.org>; Thu, 12 Jan 2017 13:27:59 -0800 (PST)
Received: by mail-qt0-x22b.google.com with SMTP id x49so30636965qtc.2 for <mmusic@ietf.org>; Thu, 12 Jan 2017 13:27:59 -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=UnI8YyRRWCGNQWHQQXqC+7rxViA8ZQZF+MNmj8TONp4=; b=o90t1sqpdg61otAxfsfZiZvDP3bQN3I1RU7rUYrb1sNU+QR65SHz/Y7rQ/ZptrsOCd QstbVEj9k7TlVH2P0obTNdwsmp9rKjBg3kNFf5Be+VZWtSZyPyUv89HLeRFcTJKxCPTp MIzk88jJ/d/cLeJYbA+kdrDDxtP33DUMvY0sJM/5TznObcHMGNYJjHoQYrzKg+OinjTq T8Rh1EYHWeQ/8FBS0Xs4+wpHaCrlPlq6z1XL9n47XUnMB9HHXTuufBxFF98vv281OaOx VhJegdQm3KdFoN8t+l/IRRXli/yfehgJa+LPoddFdCO8uLa1QHCYmUERS6algl3nA8wW dGaw==
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=UnI8YyRRWCGNQWHQQXqC+7rxViA8ZQZF+MNmj8TONp4=; b=hO3CeUz74W7KidKSID2XxW0CMkmh12equ3HeLrA71xlM71N2XJrlEXtYfh/Uc0vbpG LZauA4LiSbGng8egHe1tkwRd87AhkrNyiYWd82mp9P7wn86tyOictXVj0aF0+LpwYljz /v+jwwFO1OtMNqDtqc4F8aYP9rLzO08jlAweQ8zh5Wzl0hy1M5FZtCLg0T8eAdMvxFA3 MsgUU/Bp10XPzGXglK1+UaEOSmiFbYxBBHp71A4V/bZ0d6qXGFC1wjkOID8MbbIYJbjf WCl7/JOktqQ9ArboyHrFuNixfMHJ+W2rIVsQ8gPzX0r9m+8mz9U+5pq5nINrZIM/BKI5 D3tA==
X-Gm-Message-State: AIkVDXKcCqokUC3pjm6lEGmr+XqQ7qYHeNFdmlJVGumUYL25xVZALYOcB5PBtvyNVY6i0Q==
X-Received: by 10.200.51.134 with SMTP id c6mr14350194qtb.258.1484256478496; Thu, 12 Jan 2017 13:27:58 -0800 (PST)
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com. [209.85.220.180]) by smtp.gmail.com with ESMTPSA id e33sm7550752qtb.31.2017.01.12.13.27.57 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 13:27:58 -0800 (PST)
Received: by mail-qk0-f180.google.com with SMTP id s140so35167151qke.0 for <mmusic@ietf.org>; Thu, 12 Jan 2017 13:27:57 -0800 (PST)
X-Received: by 10.55.11.13 with SMTP id 13mr16827769qkl.201.1484256477705; Thu, 12 Jan 2017 13:27:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.147.79 with HTTP; Thu, 12 Jan 2017 13:27:57 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BF6F72C@ESESSMB209.ericsson.se>
References: <CAD5OKxvEqvah+ZJdPKJdGmKob84X8WaCqKQ2GEiatVbOSmEjDw@mail.gmail.com> <6A083F67-4ECB-4703-A881-EB2F074F309E@cisco.com> <CAD5OKxt9iVE8Sgax5rjzwyhNCupeXLCVDjz3iMU+A3eTjAnGoA@mail.gmail.com> <E0242B2A-4F7E-4915-8C73-ED68AC69846A@cisco.com> <7594FB04B1934943A5C02806D1A2204B4BF6F650@ESESSMB209.ericsson.se> <CAD5OKxu4nS4naza=f4Y0=TZJ3T5Cwc_XtsoVmP_WbxuFWiN0iA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4BF6F72C@ESESSMB209.ericsson.se>
From: Roman Shpount <roman@telurix.com>
Date: Thu, 12 Jan 2017 16:27:57 -0500
X-Gmail-Original-Message-ID: <CAD5OKxuyzJP_pFAWVnMMBDATakZOqPKE0ujyXgSSPXRjhASsuQ@mail.gmail.com>
Message-ID: <CAD5OKxuyzJP_pFAWVnMMBDATakZOqPKE0ujyXgSSPXRjhASsuQ@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="001a114d7c7a1c04e00545ec64ed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/QlKqIZ4kc1XjwpcFR3-UMobEKsg>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <paul.kyzivat@comcast.net>
Subject: Re: [MMUSIC] Transport tags
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: Thu, 12 Jan 2017 21:28:01 -0000

On Thu, Jan 12, 2017 at 4:08 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
>
>
> >Definition for TCP/DTLS/BFCP needs to be added in draft-ietf-bfcpbis-
> rfc4583bis.
>
> >
>
> >This is BFCP over DTLS over TCP with RFC 4571 framing.
>
>
>
> Correct.
>
>
>
> >UDP/DTLS/BFCP together with TCP/DTLS/BFCP will over ICE based on the
> mechanisms defined in draft-ietf-mmusic-dtls-sdp. Only UDP/DTLS/BFCP >in
> combination with TCP/DTLS/BFCP will support ICE. TCP/BFCP and TLS/BFCP will
> not support ICE and will have two run with at least one end point >on the
> public IP.
>
>
>
> I agree with all of that, but that was not my issue :)
>
>
>
> My issue was that it is not enough to simply change the proto value in
> 4583bis. You also need to define the usage of the RFC 4571 framing
> mechanism.
>
>
>
> And, if that is not backward compatible with RFC 4583 (which does NOT use
> 4571 framing), you need to add some text about that also.
>
>
>
I do not think TCP/DTLS/BFCP is defined anywhere, so it does not have to be
backwards compatible. We are not changing the proto value, we should define
a new one and explain how it works. This leaves TCP/BFCP and TLS/BFCP as
they were previously defined and simply states that these transports cannot
be used with ICE. Only UDP/DTLS/BFCP and TCP/DTLS/BFCP can be used with
ICE, with ICE not supported for all the other BFCP flavors.

Only issue I see here is that an offer of BFCP with ICE will not be
backwards compatible with RFC 4583 implementations, but considering that
RFC4583 did not define BFCP over DTLS at all, we should be fine here.

Regards,
_____________
Roman Shpount