Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447E71A028D for ; Thu, 3 Apr 2014 12:14:04 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 pwoWvt0QkC59 for ; Thu, 3 Apr 2014 12:13:58 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8E85B1A0116 for ; Thu, 3 Apr 2014 12:13:58 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id z2so8106537wiv.0 for ; Thu, 03 Apr 2014 12:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BEIHnT/ZupaykPCio/Nj1p5V4NiR7UuA8sKMJRkuVu0=; b=K9l4R0uV0qIGwL2Y1cIGEnDReDLXz6hF2qBd8FUKrhG1nZM9oPheCIwWSNvznE1C+k sLqZ4sVKRL/mo0a2SqA01930VJi+SEJAQwPhT9dzelk/4Osc4i52urof0YXnTZIEy6jH aI+OT4hxBbZTGEmOlGosQnUFPV6+ZxMHjnUHqmyWCqguyPV+MDs4QaMXJPSrcgqsAI+O d3K6IbEj+7ND2iHs+iTddu2jKNY2fa2gv9w8dF6hN589qAN9xVqJbjDw4Da2uQxaVSYg K6TSctBXKB0VCxWtHvplJNoCYKydynXEXz4+O3mEmPZYeSyVGZP3piioGQzOrBfpMBDr SLoQ== X-Received: by 10.180.11.36 with SMTP id n4mr14043999wib.4.1396552433655; Thu, 03 Apr 2014 12:13:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.102.130 with HTTP; Thu, 3 Apr 2014 12:13:33 -0700 (PDT) In-Reply-To: <533984DD.2020804@alvestrand.no> References: <5304829E.20809@ericsson.com> <5304FC27.807@alvestrand.no> <530C74A1.3000203@ericsson.com> <5338829B.3020505@alvestrand.no> <5339385D.6070006@ericsson.com> <53397036.5050104@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF82B7921@DEMUMBX005.nsn-intra.net> <533984DD.2020804@alvestrand.no> From: Bernard Aboba Date: Thu, 3 Apr 2014 12:13:33 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a11c258f0b7e70504f6283327 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lfFLlgpRr-kJxIAgbPTIIZDqJoE Cc: "rtcweb@ietf.org" , Harald Alvestrand Subject: Re: [rtcweb] Transport -03, bundling question (Re: Comments on draft-ietf-rtcweb-transports-02) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 19:14:04 -0000 --001a11c258f0b7e70504f6283327 Content-Type: text/plain; charset=ISO-8859-1 Harald said: "My memory was faulty; I had thought that the same conclusion had applied for TCP ICE candidates as for TURN ICE candidates. Version -04 will have this fixed." [BA] My memory was similarly faulty. But assuming the problem is with my memory as opposed to the minutes, the decision to require support for ICE TCP brings to mind other questions such as: a. Is support for RFC 4571 (framing of RTP/RTCP over connection oriented transport) also mandated? With respect to JSEP, what about RFC 4145 (TCP-based media transport in SDP )? b. Are there any implications for transport of DTLS/SRTP key management? (e.g. if ICE TCP is needed because UDP transport is blocked, wouldn't that also cause the DTLS/SRTP key exchange to fail?) c. Are there any implications for the data channel? (e.g. if UDP transport is blocked, wouldn't SCTP/DTLS/UDP also not work?) On Mon, Mar 31, 2014 at 8:08 AM, Harald Alvestrand wrote: > On 03/31/2014 03:54 PM, Rauschenbach, Uwe (NSN - DE/Munich) wrote: > > Hi Harald, > > The decision in London to make ICE-TCP a "MUST" has not been implemented in the -03 draft > (I have noticed you have reflected the related TURN-TCP discussion already). > > What are your plans for addressing the ICE-TCP decision? > > > Thanks! > > Checking the minutes, I find: > > > Chairs called a hum between the alternatives: > > 1) TCP ICE Candidates are MUST implement > 2) TCP ICE Candidates are SHOULD/MAY implement > 3) TCP ICE Candidates will not be discussed in document. > > The hum indicated very strong support for 1). > > > My memory was faulty; I had thought that the same conclusion had applied > for TCP ICE candidates as for TURN ICE candidates. Version -04 will have > this fixed. > > > > Kind regards, > Uwe > > > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org ] On Behalf Of ext Harald > Alvestrand > Sent: Monday, March 31, 2014 3:40 PM > To: Magnus Westerlund; rtcweb@ietf.org; Harald Alvestrand > Subject: [rtcweb] Transport -03, bundling question (Re: Comments on > draft-ietf-rtcweb-transports-02) > > Version -03 is now published. I hope you like it! > > New outstanding item: > > I added requirements for implementations to be able to generate both > fully bundled (one 5-tuple for everything) and fully unbundled (one > 5-tuple for each flow) configurations, and for implementations to be > able to tolerate being hit with any combination of bundling schemes. > > Is there a need to specify at MUST, SHOULD or MAY levels other > combinations? > > Harald > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c258f0b7e70504f6283327 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Harald said:=A0
"My memory was faulty; I had thought that the sa= me conclusion had applied for TCP ICE candidates as for TURN ICE candidates= . Version -04 will have this fixed."

[BA= ] =A0My memory was similarly faulty. But assuming the problem is with my me= mory as opposed to the minutes, the decision to require support for ICE TCP= brings to mind other questions such as:

a. = Is=A0sup= port for RFC 4571 (framing of RTP/RTCP over connection oriented transport) = =A0also mandated? =A0With respect to JSEP, what about RFC 4145 (TCP-based m= edia transport in SDP )?=A0
b. Are the= re any implications for transport of DTLS/SRTP key management? =A0(e.g. if = ICE TCP is needed because UDP transport is blocked, wouldn't that also = cause the DTLS/SRTP key exchange to fail?)
c. Are the= re any implications for the data channel? =A0(e.g. if UDP transport is bloc= ked, wouldn't SCTP/DTLS/UDP also not work?)


On Mon, Mar 31, 2014 at 8:08 AM, Harald = Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
On 03/31/2014 03:54 PM, Rauschenbach, Uwe (NSN - DE/Munich) wrote:
Hi Harald,

The decision in London to make ICE-TCP a "MUST" has not been impl=
emented in the -03 draft
(I have noticed you have reflected the related TURN-TCP discussion already)=
.

What are your plans for addressing the ICE-TCP decision?

Thanks!

Checking the minutes, I find:

=20 

Chairs called a hum between the alternatives:

1) TCP ICE Candidates are MUST implement
2) TCP ICE Candidates are SHOULD/MAY implement
3) TCP ICE Candidates will not be discussed in document.=20

The hum indicated very strong support for 1).=20

My memory was faulty; I had thought that the same conclusion had applied for TCP ICE candidates as for TURN ICE candidates. Version -04 will have this fixed.


Kind regards,
Uwe=20



-----Original Message-----
From: rtcweb [=
mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Harald
Alvestrand
Sent: Monday, March 31, 2014 3:40 PM
To: Magnus Westerlund; rtcweb@ietf.org; Harald Alvestrand
Subject: [rtcweb] Transport -03, bundling question (Re: Comments on
draft-ietf-rtcweb-transports-02)

Version -03 is now published. I hope you like it!

New outstanding item:

I added requirements for implementations to be able to generate both
fully bundled (one 5-tuple for everything) and fully unbundled (one
5-tuple for each flow) configurations, and for implementations to be
able to tolerate being hit with any combination of bundling schemes.

Is there a need to specify at MUST, SHOULD or MAY levels other
combinations?

Harald

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb



-=
-=20
Surveillance is pervasive. Go Dark.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--001a11c258f0b7e70504f6283327--