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

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 01 November 2011 14:10 UTC

Return-Path: <magnus.westerlund@ericsson.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 09E3621F9421 for <rtcweb@ietfa.amsl.com>; Tue, 1 Nov 2011 07:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.419
X-Spam-Level:
X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 eSQE4gu7wK0s for <rtcweb@ietfa.amsl.com>; Tue, 1 Nov 2011 07:10:47 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 28F1621F941E for <rtcweb@ietf.org>; Tue, 1 Nov 2011 07:10:46 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-24-4eaffdd262b1
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 36.41.13753.2DDFFAE4; Tue, 1 Nov 2011 15:10:26 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 1 Nov 2011 15:10:26 +0100
Message-ID: <4EAFFDD1.4000909@ericsson.com>
Date: Tue, 1 Nov 2011 15:10:25 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de>
References: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com> <8624F864-AB28-4CE7-AB8D-8A55B08AD745@lurchi.franken.de>
In-Reply-To: <8624F864-AB28-4CE7-AB8D-8A55B08AD745@lurchi.franken.de>
X-Enigmail-Version: 1.3.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <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: Tue, 01 Nov 2011 14:10:48 -0000

On 2011-10-26 22:45, Michael Tüxen wrote:
> 
> On Oct 26, 2011, at 10:28 PM, Hadriel Kaplan wrote:

>> 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.
> 

Michael,

I think one of the reasons there is discussion of use land
implementations of SCTP is so that you can do the above stack diagrams
with SCTP above UDP that is being shared for several purposes.

I would also like to correct Hadriel's picture slightly:

>>        +------+                        +------+
>>        |WEBAPP|                        |WEBAPP|
>>        +------+------+------+          +------+------+------+
>>        | DTLS |Audio & Video|          | SCTP |Audio & Video|
>> +---------------------------+   +---------------------------+
>> | STUN | SCTP | DTLS-SRTP   |   | STUN | DTLS | DTLS-SRTP   |
>> +---------------------------+   +---------------------------+
>> |         Mux/Demux         |   |         Mux/Demux         |
>> +---------------------------+   +---------------------------+
>> |            UDP            |   |            UDP            |
>> +---------------------------+   +---------------------------+

I think the above indicating that the common RTP session, potentially
being a DTLS-SRTP keyed RTP session that can co-exist on the same UDP flow.

To make the left one work, I think one has to have a source port where
the first byte value is 192-255 as the de-multiplexing table from
section 5.1.2 of RFC 5764 shows these to be the only available.

Thus I think the options are:

A. Left figure above. (source port must be in 49152-65535)

B. Right figure above

C. SCTP in its own UDP flow plus one UDP flow for each RTP session.

If we would pick SCTP then I think we must have either A+C or B+C working.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------