IETF Logo Mail Archive

Re: [rtcweb] DRAFT Agenda for RTCWEB

Bernard Aboba <bernard_aboba@hotmail.com> Sat, 02 March 2013 07:06 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C700821F8DDC for <rtcweb@ietfa.amsl.com>; Fri, 1 Mar 2013 23:06:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.36
X-Spam-Level:
X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sDudAgHMkfI for <rtcweb@ietfa.amsl.com>; Fri, 1 Mar 2013 23:06:07 -0800 (PST)
Received: from blu0-omc3-s10.blu0.hotmail.com (blu0-omc3-s10.blu0.hotmail.com [65.55.116.85]) by ietfa.amsl.com (Postfix) with ESMTP id AA2AE21F8DCB for <rtcweb@ietf.org>; Fri, 1 Mar 2013 23:06:07 -0800 (PST)
Received: from BLU405-EAS402 ([65.55.116.73]) by blu0-omc3-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Mar 2013 23:06:07 -0800
X-EIP: [j7Dov//LC+M1u97f2lAJ54i2UvgTXpjF]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU405-EAS402EBCDAA66A8068EA75A0F93F80@phx.gbl>
Content-Type: multipart/alternative; boundary="_96b88778-77d3-43a5-a7a3-d698983d8866_"
MIME-Version: 1.0
To: "Dale R. Worley" <worley@ariadne.com>, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
From: Bernard Aboba <bernard_aboba@hotmail.com>
Date: Fri, 01 Mar 2013 23:06:04 -0800
X-OriginalArrivalTime: 02 Mar 2013 07:06:07.0680 (UTC) FILETIME=[697B5C00:01CE1714]
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Mar 2013 07:06:09 -0000

Why would we want unsecured SCTP either for the WebRTC data channel or CLUE signaling? Let's not invent problems when we have enough real ones.
________________________________
From: Dale R. Worley<mailto:worley@ariadne.com>
Sent: ‎3/‎1/‎2013 11:58 AM
To: Michael Tuexen<mailto:Michael.Tuexen@lurchi.franken.de>
Cc: rtcweb@ietf.org<mailto:rtcweb@ietf.org>
Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB

> From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>

> As far as I understand it is easy (based on the first byte) to demux
> DTLS from STUN and SRTP. SCTP is the only payload for DTLS, so there
> is no need for demuxing. So no need to control SCTP ports. Or am I
> missing something?

Controlling port numbers is needed if SCTP is *not* encapsulated in
DTLS and yet has to be distinguished from RTP et al.  (That would
become significant if encryption was applied to the bundle's packet
stream as a whole, rather than to the constituent streams
individually.)

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

v2.23.0 | Report a Bug | By Email