[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