Re: [rtcweb] DRAFT Agenda for RTCWEB
Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Fri, 01 March 2013 17:58 UTC
Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 0A94E21F93C5 for <rtcweb@ietfa.amsl.com>; Fri, 1 Mar 2013 09:58:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599]
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 NkQrfjrfql3N for <rtcweb@ietfa.amsl.com>; Fri, 1 Mar 2013 09:58:40 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 260D021F8C45 for <rtcweb@ietf.org>; Fri, 1 Mar 2013 09:58:39 -0800 (PST)
Received: from [192.168.1.101] (p5481B99F.dip.t-dialin.net [84.129.185.159]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 5BBAC1C0C0BEA; Fri, 1 Mar 2013 18:58:37 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <201303011558.r21FwfGb2830347@shell01.TheWorld.com>
Date: Fri, 01 Mar 2013 18:58:35 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <5EB4AF68-2BB3-4243-B759-249065D8815F@lurchi.franken.de>
References: <CA+9kkMALouyyzN4dcGdF92TO2HGcBHbHR6fvHg7QC-x5ndCGjw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B10B717@ESESSMB209.ericsson.se> <03FBA798AC24E3498B74F47FD082A92F36EA7EAB@US70UWXCHMBA04.zam.alcatel-lucent.com> <201303011558.r21FwfGb2830347@shell01.TheWorld.com>
To: worley@ariadne.com
X-Mailer: Apple Mail (2.1283)
Cc: 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: Fri, 01 Mar 2013 17:58:41 -0000
On Mar 1, 2013, at 4:58 PM, Dale R. Worley wrote: >> From: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com> >> >> Since multiplexing of the data channel with RTP media has been shown >> as a desirable feature of BUNDLE (and most of its variants), I would >> suggest that this be treated as a significant advantage for BUNDLE >> (and similarly capable variants) over any proposal without it. >> Cullen's "Plan A" is preferred over Plan B precisely because it has >> an incremental muxing advantage. > > As far as I can tell from my analysis > (http://tools.ietf.org/html/draft-worley-sdp-bundle-04#section-8) > SCTP-over-DTLS can be demuxed from RTP and STUN quite easily. (This > comes from RFC 5764 section 5.1.2.) And SCTP can be demuxed from the 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? > rest as long as you control the range of SCTP ports used. (And since > the ports aren't actually to route the packets to the receiver (the > underlying UDP does that), you have freedom in choosing SCTP ports.) > > So I don't see anything blocking Plan A as compared to Plan B. Of > course, we have to *do* a bundle technique, but we've got a large > library of possibilities now and can look at the fundamental design > questions in context. > > Dale > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >
- [rtcweb] DRAFT Agenda for RTCWEB Ted Hardie
- Re: [rtcweb] DRAFT Agenda for RTCWEB Christer Holmberg
- Re: [rtcweb] DRAFT Agenda for RTCWEB Ejzak, Richard P (Richard)
- Re: [rtcweb] DRAFT Agenda for RTCWEB Justin Uberti
- Re: [rtcweb] DRAFT Agenda for RTCWEB Christer Holmberg
- Re: [rtcweb] DRAFT Agenda for RTCWEB Harald Alvestrand
- Re: [rtcweb] DRAFT Agenda for RTCWEB Christer Holmberg
- Re: [rtcweb] DRAFT Agenda for RTCWEB Dale R. Worley
- Re: [rtcweb] DRAFT Agenda for RTCWEB Martin Thomson
- Re: [rtcweb] DRAFT Agenda for RTCWEB Michael Tuexen
- Re: [rtcweb] DRAFT Agenda for RTCWEB Dan Wing
- Re: [rtcweb] DRAFT Agenda for RTCWEB Dale R. Worley
- Re: [rtcweb] DRAFT Agenda for RTCWEB Michael Tuexen
- Re: [rtcweb] DRAFT Agenda for RTCWEB Salvatore Loreto
- Re: [rtcweb] DRAFT Agenda for RTCWEB Bernard Aboba
- Re: [rtcweb] DRAFT Agenda for RTCWEB Bernard Aboba
- Re: [rtcweb] DRAFT Agenda for RTCWEB Harald Alvestrand
- Re: [rtcweb] DRAFT Agenda for RTCWEB Dale R. Worley
- [rtcweb] Time allocation for video codec MTI (Re:… Harald Alvestrand
- [rtcweb] Time division for codec discussion (Re: … Harald Alvestrand
- Re: [rtcweb] Time allocation for video codec MTI … Ted Hardie