Re: [rtcweb] Lower-overhead protocol variations

Randell Jesup <> Mon, 25 February 2013 15:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56A8B21F9355 for <>; Mon, 25 Feb 2013 07:08:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cjfpFGiWCZEA for <>; Mon, 25 Feb 2013 07:08:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B7BF021F9352 for <>; Mon, 25 Feb 2013 07:08:47 -0800 (PST)
Received: from ([]:3147 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <>) id 1U9zfX-0007Of-PW for; Mon, 25 Feb 2013 09:08:43 -0600
Message-ID: <>
Date: Mon, 25 Feb 2013 10:06:14 -0500
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] Lower-overhead protocol variations
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Feb 2013 15:08:48 -0000

On 2/25/2013 7:28 AM, Harald Alvestrand wrote:
> On 02/21/2013 09:19 PM, Michael Tuexen wrote:
>> Not sure we can choose based on SCTP. The port numbers can be the 
>> same and we have no addresses
>> available. Maybe we can use the client/server identity from DTLS (the 
>> DTLS client uses even,
>> the DTLS server uses odd).
> The MMUSIC SCTP draft (draft-ietf-mmusic-sctp-sdp-03.txt) says:
> 6.  The Setup and Connection Attributes and Association Management
>    The use of the 'setup' and 'connection' attributes in the context of
>    an SCTP association is identical to the use of these attributes in
>    the context of a TCP connection.  That is, SCTP endpoints MUST follow
>    the rules in Sections 4 and 5 of RFC 4145 [RFC4145] when it comes to
>    the use of the 'setup' and 'connection' attributes in offer/answer
>    [RFC3264] exchanges.
> The relevant table from section 4 of RFC 4145 is:
>            Offer      Answer
>             ________________
>             active     passive / holdconn
>             passive    active / holdconn
>             actpass    active / passive / holdconn
>             holdconn   holdconn
> I think that based on RFC 4145, it would be reasonable to say that the 
> party in the "active" role uses the even channels and the party in the 
> "passive" role uses the odd channels, and that if the initiator uses 
> "actpass", no channel assignment can be made until the answer comes 
> back as either "active" or "passive".

We'd have to surface this to the usrsctp interface if it isn't already.  
Also this implies stream id's can't be assigned until the association is 
established (which makes sense, if it depends on the properties of the 
association or the DTLS connection.  This also pushes me in the 
direction of not exposing stream ids.

We don't want to make it depend on something that's easily mutable in 
SDP where some type of SBC between rtcweb endpoints might have to play 
games (like having it depend on offer or answer roles - in 3pcc 
scenarios, both sides might think they're answering for example).

> This, of course, implies that channel numbers are reassigned from a 
> blank slate if the connection goes down and is reestablished with new 
> values for active and passive. Probably one should say that if the 
> connection goes down, all channels go down too - that the data channel 
> system doesn't attempt to layer yet another layer of reconnection on 
> top of the already existing ones.

Agreed.  We already should be able to handle IP mobility without tearing 
down the higher layers.

Randell Jesup