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

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Wed, 26 October 2011 20:45 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 E60E921F8B89 for <rtcweb@ietfa.amsl.com>; Wed, 26 Oct 2011 13:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.684
X-Spam-Level:
X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 GWq8KdjQDzn6 for <rtcweb@ietfa.amsl.com>; Wed, 26 Oct 2011 13:45:04 -0700 (PDT)
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 1F1AF21F8B88 for <rtcweb@ietf.org>; Wed, 26 Oct 2011 13:45:03 -0700 (PDT)
Received: from [192.168.1.200] (p508F9F31.dip.t-dialin.net [80.143.159.49]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A2F9D1C0B4622; Wed, 26 Oct 2011 22:45:01 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="us-ascii"
From: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com>
Date: Wed, 26 Oct 2011 22:45:00 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8624F864-AB28-4CE7-AB8D-8A55B08AD745@lurchi.franken.de>
References: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: rtcweb@ietf.org, Randall Stewart <rrs@lakerest.net>
Subject: Re: [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:45:05 -0000

On Oct 26, 2011, at 10:28 PM, Hadriel Kaplan wrote:

> 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.
This is not possible today. The demultiplexing seems to be specific to this scenario.
Not sure it fits. For demuxing you use the first byte to distinguish STUN from DTLS and SRTP.
The first byte us the high order byte of the source port. Once could require
SCTP to use source ports with the high order byte > 192. That might work.
However, you would need to get the Mux/Demux into the kernel. Could be done
using a socket option. But I'm not sure it really fits. Maybe Randy has an
opinion.

Best regards
Michael
> 
> -hadriel
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>