Re: [MMUSIC] SCTP question: Where does it multiplex?

<> Mon, 03 December 2012 09:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 353FB21F86D2 for <>; Mon, 3 Dec 2012 01:03:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HxIao3acVDBy for <>; Mon, 3 Dec 2012 01:03:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 83C1021F8661 for <>; Mon, 3 Dec 2012 01:03:23 -0800 (PST)
Received: from ( []) by (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB392jo4001514; Mon, 3 Dec 2012 11:02:46 +0200
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Dec 2012 11:02:45 +0200
Received: from ([]) by ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.02.0318.003; Mon, 3 Dec 2012 09:02:44 +0000
Thread-Topic: [MMUSIC] SCTP question: Where does it multiplex?
Thread-Index: AQHNz7N6WgV/cieAmkiYZjuifDh2VZgEB+uAgAA2wgCAAniGgIAAAgkAgAACugCAAAro0A==
Date: Mon, 03 Dec 2012 09:02:44 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Dec 2012 09:02:45.0357 (UTC) FILETIME=[F5A861D0:01CDD134]
X-Nokia-AV: Clean
Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Dec 2012 09:03:24 -0000


I agree that it would be useful to be able to run data channel on the same 5-tuple as RTP/RTCP, and even making it the default and must-implement way for the browsers.

QoS/prioritization comes to mind as the only potential drawback. The endpoint can naturally still give different priorities to the different components (audio, video, "data") it is sending. I assume SCTP also has TCP-style receiver window that can be used to throttle reception if needed. And presumably RMCAT will find solutions to congestion control in genenral. But from the network perspective there is only one flow, and the only(?) way to differentiate the components is to use DSCP. I don't think our QoS (or API) draft yet clearly explains how DSCP's are learned and set, or whether that is even going to be a realistic solution. 


>-----Original Message-----
>From: [] On
>Behalf Of ext Harald Alvestrand
>Sent: 03 December, 2012 10:11
>To: Christer Holmberg
>Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?
>On 12/03/2012 09:00 AM, Christer Holmberg wrote:
>> Hi,
>> I guess it would be nice to hear from the browser/endpoint people whether
>they see a need for covering non-RTP in BUNDLE.
>> If NOT, it would mean a minimum of two 5-tuples, instead of one (one for
>the bundled RTP media, and one for the data channel).
>Speaking with my browser implementor hat on, I want to avoid adding an
>extra 5-tuple for data channels.
>Our stats on improvement from the introduction of rtcp-mux were pretty
>compelling that the issue is real.
>> Regards,
>> Christer
>> -----Original Message-----
>> From: [] On
>> Behalf Of Harald Alvestrand
>> Sent: 3. joulukuuta 2012 9:54
>> To:
>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex?
>> On 12/01/2012 07:09 PM, Paul Kyzivat wrote:
>>> I must say that I am getting confused about what is being multiplexed
>>> here. We must be very careful to be precise.
>>> SCTP defines an *association*, which in simple cases is bound to a
>>> 5-tuple. (For now lets not talk about the cases where each end can
>>> have more than one address.)
>>> SCTP multiplexes multiple one-way *streams* over an association.
>>> (These are not RTP streams.)
>>> RTCWEB binds pairs of sctp-streams together into *channels*.
>> I'm not talking about any of these levels. I'm talking about the reuse of the
>RTP session's 5-tuple for the DTLS/SRTP 5-tuple, as described in RFC 5764
>section 5.1.2.
>> I said the same thing earlier on this thread (Nov 5), when you first
>> responded (thanks for being the first responder!)
>> You do make the point that the term "multiplex" is so over-used, it should
>probably be abandoned altogether - but that section talks about
>(de)multiplexing, so changing terminology is probably too late for that
>particular usage.
>>                 Harald
>> _______________________________________________
>> mmusic mailing list
>mmusic mailing list