Re: [bfcpbis] BFCP with ICE: MIT transport?

Paul Kyzivat <paul.kyzivat@comcast.net> Fri, 03 February 2017 17:18 UTC

Return-Path: <paul.kyzivat@comcast.net>
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 12321129484 for <bfcpbis@ietfa.amsl.com>; Fri, 3 Feb 2017 09:18:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.898
X-Spam-Level:
X-Spam-Status: No, score=-5.898 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 021WD1UfOZvV for <bfcpbis@ietfa.amsl.com>; Fri, 3 Feb 2017 09:18:50 -0800 (PST)
Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (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 9781E12945D for <bfcpbis@ietf.org>; Fri, 3 Feb 2017 09:18:50 -0800 (PST)
Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-06v.sys.comcast.net with SMTP id ZhTuccCFr1hmRZhVZc32cK; Fri, 03 Feb 2017 17:18:49 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1486142329; bh=v0N4w0zX01LlgeFeAikeyixC7ZmyasjVDMUnhEr4AbE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=GPHv4MPJsHziClQ0KgdMiEuN7AlPWENy5/zwpUP1/BpPHNXhu+WdSEor0rCYwNjdn Fw5bS9Bq7/+XLMv90aTTfvtFBxeG4GHuFpOoqeQGVNotSntzpXhy7xOR8QvdOoyru2 BfP0tMFz28HGK9LtVuN8TJszjkRQTH/9j4/YfQngZWv0iMftMEOtlKKu+liIcB/XUT syM8FJy/2bSpTenGw1Y/DiGDT3YrxoZoz75Q937BxI18mQ4AMzWA/1vzv/4JOkE8V2 /1YLsp5gz7uA6UXwSbUmdfmK66oNamXjehKF8nrnNpR93ZKQCHLQx9Z3Lcjv1moSft /D9EGidGhJG9A==
Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-15v.sys.comcast.net with SMTP id ZhVYc9HnI04HZZhVZcLiVI; Fri, 03 Feb 2017 17:18:49 +0000
To: bfcpbis@ietf.org
References: <D4BA5922.17639%christer.holmberg@ericsson.com>
From: Paul Kyzivat <paul.kyzivat@comcast.net>
Message-ID: <496d6961-9762-e227-a66e-a34c27b9d307@comcast.net>
Date: Fri, 03 Feb 2017 12:18:48 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <D4BA5922.17639%christer.holmberg@ericsson.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfFB5MFCX7/3y3YOJQpXXLJjTeNpnbdUh2tvi611PHGtK2XbDLohgeK6ZqTqMYFoiUlMyPzSabsgWqD+Rem/hldletzPi8CBvk55S7uODSEEK3zhQB6nE NESA47qiMbk7YXwGlUgKCo40eHQPGm98Ew9p9i0PicgljOSpZqowXiIQ9/hvLTew4J/fVYTtI8y7tw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/AB-tQGk-0n63A4GUm-HZe4VpdWY>
Subject: Re: [bfcpbis] BFCP with ICE: MIT transport?
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, 03 Feb 2017 17:18:52 -0000

On 2/3/17 8:56 AM, Christer Holmberg wrote:
>
> Hi,
>
> During the MMUSIC session in Seoul we discussed a number of issues
> related to ICE-SDP. We made some decisions, and I got action points to
> verify one of those on the list.
>
> One of those issues affect BFCP, when used with ICE.
>
> Example:
>
> BFCP client A supports both UDP and TCP, sends an SDP offer with UDP
> proto in the SDP m- line. The TCP option is given as an ICE candidate.
>
> BFCP server B only supports TCP.

When we talk about a BFCP implementation supporting TCP I think we mean 
the BFCP that runs directly over TCP.

But when talk about ICE over TCP I think we are talking about UDP 
packets framed over TCP. That is really something different that the 
BFCP implementation may or may not support.

Its important not to conflate these.

But I think that is mostly distinct from the question below.

	Thanks,
	Paul

> The problem is that, according to RFC 3264, the m- line proto value in
> the answer must match the value in the offer. But, server B does not
> support UDP.
>
> Two alternatives were discussed:
>
> ALT #1: Every protocol that supports ICE must define a MIT transport.
> That transport must always be reflected in the m- line proto (additional
> transports are provided as ICE candidates).
>
> ALT #2: Allow an m- line proto value in the answer even if the answerer
> does not support the associated transport – as long as the answerer
> provides a candidate with the supported transport.
>
>
> Based on the discussions, there was strong consensus to go for Alt#2,
> which was allowing a transport in the m- line of the answer even if the
> answerer doesn’t support it, as ICE candidates will be used to determine
> the transport.
>
>
> Having said that, that still does not prevent individual protocols to
> specify a MIT transport.
>
>
> So, my QUESTION is: should we specify a MIT transport for BFCP? Again,
> this only applies to usage with ICE.
>
>
> The associated slides from the meting can be found here:
>
>
>
> https://www.ietf.org/proceedings/97/slides/slides-97-mmusic-ice-sip-sdp-00.pdf
>
>
> (See slides 4-6)
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> bfcpbis mailing list
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis
>