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

Roman Shpount <> Sun, 20 November 2016 23:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7037212953B for <>; Sun, 20 Nov 2016 15:23:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 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] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xYhuIXFwX9bO for <>; Sun, 20 Nov 2016 15:23:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1CC3812949F for <>; Sun, 20 Nov 2016 15:23:29 -0800 (PST)
Received: by with SMTP id w33so194087274qtc.3 for <>; Sun, 20 Nov 2016 15:23:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wWcatBvKhIDZCpN21sL7YRhc3RG13DReFcX3xrwFiAI=; b=tCQEhtfMuYUKywY7srOZLM8mUqrKO4JEpQdz0bS0CH9suMh3mshnyeVkct6upTbYeK 5GndiKzPgFrX2ehrq3MBTLkCqW25pNNRykSLnlY0AJYdHu1VIXs+RhfAmL5ZpO9ERH8Q 3xZ5xnwZ2XPieCI4iz4OvXj9hI4HVMhrHS+NPY0N7ETrW05bBBhMvcOkdHSjEFc9QCxL 3a22SFxnRG1apJLwuCEL6MQvOLpqysWCZmuH2zV6EJDCDmY7t8TLDAqBpRTUpBGrW7K7 bsqntv7CHsv+RPqw6PWKbwI62QJfDXp/Vltb0Nze8nECFjInyOlJZ6abwMzDOFU5kqoV Uk1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wWcatBvKhIDZCpN21sL7YRhc3RG13DReFcX3xrwFiAI=; b=kLce+ZGUlXxIq06PMeGOBITx1kJsia+B/4b3QwQ9bQfSh/BrqhoKgOdd/JVXUnDU4c brOTIuEmWGetrysJXdsoIdbeJI6531pcTCdevRXlPq3CbnAohTOSBdy1iFKapyvFOe9g IyKzY9ZarJWa0b51ncKv1C0zJVFxYI/6hqLYpUWlsI5L1selYz5hJH1MyALtTo7B1vbB mxEpIdAkrMgScBSBYJDE7vKnyySXjiUlz/aJZixLI5jA+ZUtwj8+pyIZXZNff0Lntm4u nwHnMwg26oz5Jbi7jyWUtAKjMc4nACwLaSV1NNEU2+j3YJnzepXEpahcIKsWP4dqR328 YRbA==
X-Gm-Message-State: AKaTC03BAijoeSn3fYRfN2cgIgJuUVdPesCwf5ZbecUCtZ+5UPInPOVCEpkjpZugwThQWQ==
X-Received: by with SMTP id m43mr6469104qtf.195.1479684208153; Sun, 20 Nov 2016 15:23:28 -0800 (PST)
Received: from ( []) by with ESMTPSA id f7sm7242223qtf.48.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Nov 2016 15:23:27 -0800 (PST)
Received: by with SMTP id c47so194303471qtc.2; Sun, 20 Nov 2016 15:23:27 -0800 (PST)
X-Received: by with SMTP id 34mr6254612qtn.273.1479684207450; Sun, 20 Nov 2016 15:23:27 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 20 Nov 2016 15:23:26 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: Roman Shpount <>
Date: Sun, 20 Nov 2016 18:23:26 -0500
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Alan Ford <>
Content-Type: multipart/alternative; boundary=001a11404b3290a43e0541c3d344
Archived-At: <>
Cc:,, "" <>, Christer Holmberg <>
Subject: Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: BFCPBIS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 20 Nov 2016 23:23:34 -0000

Hi All,

I just wanted to add to my previous email, that according to RFC
6544 protocols running over tcp candidates MUST use  RFC 4571 framing ( This means that BFCP
running over tcp candidate is not TCP/BFCP and will require a different
transport tag.


Roman Shpount

On Thu, Nov 17, 2016 at 9:13 PM, Roman Shpount <> wrote:

> Hi All,
> There are three comments I wanted to make regarding general nature of all
> existing protocols designed to work ICE
> 1. Protocols running on top of ICE assume that regardless what candidate
> pair is used, including tcp candidates, the underlying network transport is
> unordered and unreliable. During nomination, including continuous
> nomination, candidate pairs can switch, including switching from udp to tcp
> or from tcp to udp. This typically means that protocol re-transmit timers
> are operational, packets are re-ordered at the protocol level, and
>  UDP-friendly packet sizes are used even when packets are sent over tcp
> candidates. For instance DTLS and SCTP re-transmit timers, reordering, and
> fragmentation support are still running when tcp candidates are used.
> 2. Protocols do not assume that particular candidate network transport
> runs all the way from origination to final destination of the protocol
> packets. For instance there are SBC which only handle ICE. These SBC run
> the ICE state machine and then transmit the underlying protocol data to the
> final destination using public IP. Because of this, it is not unusual for
> RTP to run over tcp candidate until SBC and then run over UDP to the final
> destination. This is one more reason why re-transmit timers and other
> mechanisms used to deal with UDP are still running over tcp candidates.
> 3. I am not aware of any current protocol running over ICE tcp candidates
> which is not using RFC4571 framing. For instance DTLS could have been
> implemented using DTLS protocol framing without RFC4571 over tcp
> candidates, but this was not the case. This is partially done to simplify
> implementation of SBC which terminate ICE and transmit protocol data using
> UDP. By using RFC 4571 framing, SBC can packetize/de-packetize data
> transmitted over tcp candidates without knowing protocol details.
> To conclude, up until this point ICE tcp candidates were not treated as
> reliable transport and served simply as another way to transmit UDP packets
> through firewalls. Because of this, I would argue that BFCP running over
> tcp candidate is not the same as TCP/BFCP, in the same way as DTLS running
> over tcp candidate is not TLS.
> I would also argue that any protocol running over ICE is, in essence, a
> UDP based protocol, using tcp candidates only as a fall back mechanism for
> firewall traversal, same way as when data is relayed over TURN TCP, it is
> still considered sent over UDP at the protocol level.
> If ICE group agrees, I think this should be documented by saying that UDP
> is a MUST implement for any protocol using ICE and that default candidate
> should be UDP based.
> Regards,
> _____________
> Roman Shpount
> On Thu, Nov 17, 2016 at 8:14 PM, Alan Ford <> wrote:
>> 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 <> 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 <
>>> 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 [] *On Behalf Of *Roman
>>> Shpount
>>> *Sent:* 17 November 2016 00:52
>>> *To:*
>>> *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
>>> 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