Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE

Alan Ford <alan.ford@gmail.com> Fri, 18 November 2016 01:14 UTC

Return-Path: <alan.ford@gmail.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6E2129860; Thu, 17 Nov 2016 17:14:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 AEAplgJhpqxy; Thu, 17 Nov 2016 17:14:23 -0800 (PST)
Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 57FC7129859; Thu, 17 Nov 2016 17:14:18 -0800 (PST)
Received: by mail-pg0-x243.google.com with SMTP id x23so18965219pgx.3; Thu, 17 Nov 2016 17:14:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=XH3G2uhBWPIri1cT58DZd1RCccr5mQzeFHiuvaR5Brw=; b=movMiXpQCHl6nbQdAzGNTJ4R/d8fu3WvBlp3rI45wamesBZt9sCRsHUAG/dQcAZYz6 6EvkbMTMMS6SjxC875VAzXvOZT6a11EJ20wGcZo7230OGTAtJfL6Lf/vw3MkwhwXax4g j/Jbvv/W9IVlI9qNsIKNTx3TV14i7Z+E6qlLdsKKY6wsOJAGLjisGbj+lU8b/p1FA/6b 9soNXchPGP6PF2Od+2o21g8+/w7IEBEmeyRujo7F856wdXc9zB3oEaBwVT7umnSOdwSi 9ojPFIidr7y943EcX/o7zJR47wzXeZ/gcaM35EkU2z0YiFwkDjFp8cqwWzuXOw94+qyX VPsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=XH3G2uhBWPIri1cT58DZd1RCccr5mQzeFHiuvaR5Brw=; b=JDoQf3YSaA63BenhgLlRiEt0j/e46Mo7yfw3UHXloketN10DR6uphGXBrBHhdRoPoC e65ZXdgQh1rSXUT9yolJVfkk53KqYbFK69mEnEbUwYLj3OLsXf7hKDyW5mEcmB/0n2hH C3nojlaa4TMIUjbBeOZoGNewDlQc7kOIgafr233i4fMGgCU9k4me70XLwyuJrI9JhAI5 oOrSQ61amQ/XpK5hTzXmUFvO6tv5eHG7/hIDoN2YXxb+TIl909wWWVevtuUNVXZ88+6B HJZXeHcy4qSxhapF2TlEbELsQ0OHPk4FAUMcU9yz0LVomJp028/l0rU7dwahASshTFsU 5pCg==
X-Gm-Message-State: ABUngvd7SSFgwNMtchNMI66UtGm2rNWrSIvwU7Lofb1CCrHtUQL/s7dgal9B5bLAQtfn2Q==
X-Received: by 10.99.43.8 with SMTP id r8mr13118830pgr.83.1479431657265; Thu, 17 Nov 2016 17:14:17 -0800 (PST)
Received: from t2001067c03700128e1d8ba8f9f586209.v6.meeting.ietf.org ([2001:67c:370:128:e1d8:ba8f:9f58:6209]) by smtp.gmail.com with ESMTPSA id u23sm11235098pfg.86.2016.11.17.17.14.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Nov 2016 17:14:16 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_FCD11268-A7C3-4EED-8FFB-B12215DC4799"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <alan.ford@gmail.com>
In-Reply-To: <CAD5OKxu15YgYO0xyWMYXv7VTAVVQ71iJhH_txt31BV0CvCSjqg@mail.gmail.com>
Date: Fri, 18 Nov 2016 01:14:10 +0000
Message-Id: <F96AC385-2721-4652-98F5-1BF92F06214A@gmail.com>
References: <CAD5OKxuhvCz82+7JK8QrArtrYcjV9+b7vWMpWRnCjNbrL++srA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <CAD5OKxu15YgYO0xyWMYXv7VTAVVQ71iJhH_txt31BV0CvCSjqg@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/bqhYVR7t0MxD4JMoM4i28Xx0ldc>
Cc: bfcpbis@ietf.org, ice@ietf.org, "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Nov 2016 01:14:26 -0000

Adding bfcpbis.

You raise a good point Roman - there’s no definition of how to actually use ICE with BFCP at the protocol level - this only came up in some very late reviews of 4582bis. The initial suggestion was to use the same text as in draft-ietf-mmusic-sctp-sdp-19, but it then raised the point that, given BFCP does not have a MTI protocol, if the offerer supported both they would include their preferred option, but if the receiver supported the other variant, there’s no way to immediately negotiate that without a re-INVITE.

Christer’s suggestion to relax the requirement that the m-line protocol in the answer matches one of the ICE candidates would support the case where the offerer supports both but prefers UDP, but the answerer only supports TCP. Although no implementations currently do ICE here, this relaxation would leave the door open to gaining this negotiation flexibility in bfcpbis implementations. There seems no reason to have this requirement applied to the answer in the first place.

I don’t understand the comment about SBCs; today, tcp candidates are used for media and data channels end-to-end in WebRTC, to name but one implementation.

Regards,
Alan

> On 17 Nov 2016, at 03:05, Roman Shpount <roman@telurix.com> wrote:
> 
> Adding ICE group to this message.
> 
> The approach always was that tcp candidates can potentially go only as far as SBC and then be terminated by UDP transport. Because of this everything transmitted over tcp candidate was still considered to be transmitted over the unreliable out-of-order transport. It is also assumed that candidates can switch from UDP to TCP based candidate during nomination. This is why, for instance, we run DTLS with RFC4571 framing over tcp candidates, not TLS. Because of this I always thought that ICE is UDP first with additional TCP transports for situation when UDP will not work. So, as a result, I think ICE-bis should specify that UDP MUST be supported and default candidate MUST be UDP. ICE SDP can reflect this, but I think this is the underlying protocol requirement.
> 
> I also wanted to add that BFCP needs to examine how ICE support is implemented by this protocol. I think it is not covered in the current drafts. I also think I do not think it is possible for TCP/BFCP to run over ICE. On the other hand UDP/DTLS/BFCP and TCP/DTLS/BFCP would trivial based on current DTLS work.
> 
> Regards,
> _____________
> Roman Shpount
> 
> On Wed, Nov 16, 2016 at 8:44 PM, Christer Holmberg <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com>> wrote:
> I have no problem with Roman’s must-support-UDP suggestion. I guess the question is whether the BFCP folks could accept that. Cullen did say that TCP-based BFCP deployments have been around for a decade. But, do they support ICE?
> 
>  
> 
> If we decide to move forward with such approach, we need to ask ourselves whether must-support-UDP should be an ICE requirement (in which case the suggestion should be brought to the ICE WG) or whether it should only be an ICE-using-SIP-SDP requirement.
> 
>  
> 
> Regards,
> 
>  
> 
> Christer
> 
>   <>
> From: mmusic [mailto:mmusic-bounces@ietf.org <mailto:mmusic-bounces@ietf.org>] On Behalf Of Roman Shpount
> Sent: 17 November 2016 00:52
> To: mmusic@ietf.org <mailto:mmusic@ietf.org>
> Subject: [MMUSIC] m= line protocol in case of ICE
> 
>  
> 
> Hi All,
> 
>  
> 
> I just wanted to return to the m= line protocol issue that Christer raised during the last MMUSIC session.
> 
>  
> 
> All the ICE implementations I've seen are primarily UDP based with support for tcp host candidates which are primarily used to connect to end points on public IP. If all ICE implementations are continue to be primarily UDP based, then the simplest solution would be to require UDP support when any given protocol is implemented over ICE. DTLS and RTP are already primarily UDP based so this is a non-requirement. Even more, all protocols that are implemented on top of ICE must assume that underling transports (including tcp candidates) are unreliable, since candidate pair can change at any time between reliable and unreliable transports, so this makes them different from protocols implemented on plain TCP or TLS.
> 
>  
> 
> So the first question I wanted to ask is anybody interested in TCP only ICE implementation where the protocol running on top of such implementation relies on the reliable delivery of underlying messages? By this I mean, does anybody wants implement TCP based ICE, with simultaneous open, reflexive and relay candidates in such a way that ICE implementation will run from behind NAT without ever needing a UDP candidate?
> 
>  
> 
> I understand that BFCP was used for a long time, but I do not think TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I think only UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE. 
> 
>  
> 
> I think both rfc4582bis and rfc4583bis need a careful review and additional sections that describe ICE considerations. I think the most obvious thing would be to specify that ICE can only be supported by UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will also mean in which case RFC4571 is used when tcp candidates are used. Furthermore, when tcp candidate is selected with UDP/BFCP transport, it is not the same thing as using TCP/BFCP and will need a different transport tag (something like TCP/UDP/BFCP). Alternatively we can require that only secure versions of BFCP are used with ICE and only allow ICE usage for UDP/DTLS/BFCP and TCP/DTLS/BFCP.
> 
>  
> 
> To conclude, I would argue that the simplest solution would be that for all protocols implemented on top of ICE, UDP MUST be supported and default candidates MUST be UDP based. This avoids building uncomfortable artificial constructs to avoid ICE mismatch and requires minimal changes to existing specifications.
> 
>  
> 
> Regards,
> 
> _____________
> Roman Shpount
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic