[rtcweb] Data Channel question: correlating streams with channels
Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 04 February 2014 16:07 UTC
Return-Path: <pkyzivat@alum.mit.edu>
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 7FE181A0100 for <rtcweb@ietfa.amsl.com>; Tue, 4 Feb 2014 08:07:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
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 paJ1Fcw4kJeL for <rtcweb@ietfa.amsl.com>; Tue, 4 Feb 2014 08:07:52 -0800 (PST)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBE81A0169 for <rtcweb@ietf.org>; Tue, 4 Feb 2014 08:07:52 -0800 (PST)
Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id NDos1n0051wpRvQ53G7sRr; Tue, 04 Feb 2014 16:07:52 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id NG7s1n0013ZTu2S3eG7sFK; Tue, 04 Feb 2014 16:07:52 +0000
Message-ID: <52F11057.8040708@alum.mit.edu>
Date: Tue, 04 Feb 2014 11:07:51 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391530072; bh=1gRy8Blf94ZSqtu8qbYexKhlk9A53IIM/rJfLc4SW0s=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kwio86+n3MFIHsgUDAotUMiGEw1A2fRh71iwz9pSF8h65dDsgkiNO0R8pE6AAyca6 R9BXxTeLn6nZ3FXhaanN6icq6EOOAbLZLC2pIWM3i0p8c7a8y5mqCIaGZSMzZKSIqP 4hW7s7FdB4fvBdFREILRQWg61dsDBJY05bgnQRw8LVADhvNXN4G4RMyHnXjRDQNKnL Yap8e7jPe0RVmL894K/N+vhTJVIFsJ9foJLABHGFnFpEnIYjHhjutmXMFvBQ2ef74A v68KFN96hdu67XELRy8ikYzjf0tbNzn/LgUAl4VdsLqd5tiqXpAxNQTV9QZdtASACn r40Hkv4aGho1Q==
Subject: [rtcweb] Data Channel question: correlating streams with channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 04 Feb 2014 16:07:56 -0000
Section 6.4 of draft-ietf-rtcweb-data-channel-06 says: The realization of a bidirectional Data Channel is a pair of one incoming stream and one outgoing SCTP stream. Note that there's no requirement for the SCTP streams used to create a bidirectional channel have the same number in each direction. How stream values are selected is protocol and implementation dependent. The note seems to be something of a cop-out. But I'll accept for the moment that this can be true when external negotiation is used to define the channels. But I've looked through draft-ietf-rtcweb-data-protocol-01, and I don't find any specification there of how the pairing is done. Section 4 of the protocol draft says: The data channel protocol uses a two way handshake to open a data channel. The side wanting to open a data channel selects an unused Stream and sends a DATA_CHANNEL_OPEN message. The peer responds with a DATA_CHANNEL_ACK message. Then the data channel is open. The side doing the OPEN chooses what will be its outgoing stream id. That then becomes the incoming stream id of the peer. I had always assumed that the same stream id would be used for the ACK. But I find no evidence to support that assumption. For it to be anything else I would think the ACK would need to carry more information to correlate back to the OPEN message. Thanks, Paul
- [rtcweb] Data Channel question: correlating strea… Paul Kyzivat
- Re: [rtcweb] Data Channel question: correlating s… Paul Kyzivat