[rtcweb] Layers in draft-jesup-rtcweb-data-00

Hadriel Kaplan <HKaplan@acmepacket.com> Wed, 26 October 2011 20:28 UTC

Return-Path: <HKaplan@acmepacket.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 AC67E21F8B54 for <rtcweb@ietfa.amsl.com>; Wed, 26 Oct 2011 13:28:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.452
X-Spam-Level:
X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bL4KV3VnS7GW for <rtcweb@ietfa.amsl.com>; Wed, 26 Oct 2011 13:28:58 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id EF05B21F8B5A for <rtcweb@ietf.org>; Wed, 26 Oct 2011 13:28:53 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 26 Oct 2011 16:28:52 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 26 Oct 2011 16:28:53 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: Layers in draft-jesup-rtcweb-data-00
Thread-Index: AQHMlB3fbG1JmEkK/Ei1cwlsKo8CDg==
Date: Wed, 26 Oct 2011 20:28:51 +0000
Message-ID: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7B29662E6877774ABDEDAB6320CA7964@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Subject: [rtcweb] Layers in draft-jesup-rtcweb-data-00
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: Wed, 26 Oct 2011 20:28:58 -0000

Howdy,
Just to make sure I understand this right, the choice isn't really this:

        +------+                    +------+
        |WEBAPP|                    |WEBAPP|
        +------+                    +------+
        | DTLS |                    | SCTP |
 +-------------+             +-------------+
 | STUN | SCTP |             | STUN | DTLS |
 +-------------+             +-------------+
 |    UDP      |             |    UDP      |
 +-------------+             +-------------+

But rather this:

        +------+                        +------+
        |WEBAPP|                        |WEBAPP|
        +------+------+------+          +------+------+------+
        | DTLS | Audio| Video|          | SCTP | Audio| Video|
 +---------------------------+   +---------------------------+
 | STUN | SCTP |S/RTP |S/RTP |   | STUN | DTLS |S/RTP |S/RTP |
 +---------------------------+   +---------------------------+
 |         Mux/Demux         |   |         Mux/Demux         |
 +---------------------------+   +---------------------------+
 |            UDP            |   |            UDP            |
 +---------------------------+   +---------------------------+

[Note: "S/RTP" = SRTP/SRTCP or RTP/RTCP, "Mux/Demux" = tiny logic to mux/demux]

Because the audio/video streams may be using the same UDP port, right?

And the two "S/RTP" boxes may be just one box depending on how the MMUSIC multiplexing decision turns out.

So if we want to choose the left one, because we expect/want that someday the Operating System provides a SCTP/UDP stack in the kernel, and I think we do, could it do so while demuxing and letting STUN, RTP, and DTLS go up to the app layer?  (i.e., given a socket/BIO/FD model)  I have no idea about such things... just asking.

-hadriel