Re: [rtcweb] Lower-overhead protocol variations

Salvatore Loreto <> Thu, 28 February 2013 08:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B1C221F89CE for <>; Thu, 28 Feb 2013 00:48:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.169
X-Spam-Status: No, score=-106.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xQAStCzLZuVd for <>; Thu, 28 Feb 2013 00:48:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E95D921F8518 for <>; Thu, 28 Feb 2013 00:48:07 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-77-512f19c6a5b4
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 78.FD.32353.6C91F215; Thu, 28 Feb 2013 09:48:06 +0100 (CET)
Received: from ( by ( with Microsoft SMTP Server id; Thu, 28 Feb 2013 09:48:06 +0100
Received: from ( []) by (Postfix) with ESMTP id 321382B29; Thu, 28 Feb 2013 10:48:06 +0200 (EET)
Received: from (localhost []) by (Postfix) with ESMTP id A4CEF5416F; Thu, 28 Feb 2013 10:48:03 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost []) by (Postfix) with ESMTP id CFEE5540FB; Thu, 28 Feb 2013 10:48:02 +0200 (EET)
Message-ID: <>
Date: Thu, 28 Feb 2013 10:48:03 +0200
From: Salvatore Loreto <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Michael Tuexen <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvje4xSf1Ag1nTrSxWvD7HbnGsr4vN 4mLTEkaLtf/a2R1YPK5MuMLqsWTJTyaPDS07mDwmP25jDmCJ4rJJSc3JLEst0rdL4Mr4PM2l 4JhcxfWt95gbGD+IdzFyckgImEhMudLHBmGLSVy4tx7MFhI4ySjReSavi5ELyN7AKPHn4Ex2 CGcXo8T6qR2sEM5aRokl/xZCOdsYJXa8uswE0s8roC3xfdk/FhCbRUBVYsPOE6wgNpuAmcTz h1uYQWxRgWSJf4+OMELUC0qcnPkErF5EwFTi4PJ5YDazQJxEb+8ZMFtYwELiYc8RJohlR5gl Ln69DDaIU8BV4sWlCWwQDbYSF+Zch2qWl9j+dg4zxHNqElfPbWKGeE5LovdsJ9MERtFZSHbP QtI+C0n7AkbmVYzsuYmZOenl5psYgRFycMtvgx2Mm+6LHWKU5mBREucNd70QICSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoFxVdjnQ718oVdECvROfBaRsv6z47DZ9KA70scXqhRccHaJnjp/ h+P7y6mr07OcT+0+OMfM5QyPBNdlCcO7G88zntlQt2HF7I6d9WuS/brFmSKeB8zdcV+zqPBb /G2ja5PO/lpVeFLzptlTRd23fcyTnBUcv925s+e1jayb6CP28oc/ZK+kpzQHKrEUZyQaajEX FScCAJhXR41eAgAA
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: Thu, 28 Feb 2013 08:48:09 -0000

On 2/27/13 8:32 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".
>>>>> OK. I was writing the statement based on how things are currently implemented
>>>>> in Firefox. Both side are the active side...
>>>>> Thanks for the clarification.
>>>> That confuses me ... do both sides send INIT (RFC 4960 section 5.1 step A)?
>>> Yes...
>>>> Collision is described in section 5.2.1 section B - I guess that if that's something that makes sense to provoke on a regular basis, "both active" can make sense.
>>> Yes, SCTP handles INIT collisions. In API terms: Bots call connect() (using the 1to1 style API).
>>> This is possible, since both sides know the port number of the peer.
>> thanks for the clarification Michael.
>> just to be clear before I do any changes in the The MMUSIC SCTP draft,
>> is this something always true? (i.e. implementation independent)
> No. It is how it is currently handled in Firefox. If i remember it correctly,
> ekr preferred a symmetric solution. So he hasn't to figure out which side
> is active and which side is passive. Could be related to the fact, the Firefox
> currently doesn't use SDP for the data channels (if I remember it correctly).
>> even if I haven't checked I am not sure it is true also for the "1 to many" model...
>> and that make me cautious on doing any changes unless we do not restrict the scope of
>> the draft to 1to1 style
> INIT collision is also handled by 1-to-1 style sockets.
thanks for the answer Michael,
so for the time being it seems that I don't need to do any modification 
to the draft-ietf-mmusic-sctp-sdp draft
about the active/passive role

however I would like to hear more comments from people on this aspect:
i.e. the Active/Passive role

> Best regards
> Michael
>> br
>> /Salvatore
>>> Best regards
>>> Michael
>>>> draft-ietf-mmusic-sctp-sdp needs to be updated with this possibility.
>>>>>> 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.
>>>>>>                    Harald

Salvatore Loreto, PhD