Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt

[Randell Jesup <[e-mail]>]

On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
> Richard,
>
> On 10/25/13 4:51 PM, Ejzak, Richard P (Richard) wrote:
>> Hi Harald,
>> You said: " I can't see a way to mix the two paradigms that 
>> guarantees this never happening."  The two paradigms being browser 
>> selection vs. application selection of data channel stream ids.

You can.  You just have to be careful.  For example, your application 
could define that pre-negotiated channels will use 100-110, and then 
specify those to both ends before association/offer/answer.  Later it 
could use data-protocol to add dynamic channels (using even-odd).  Since 
we've told both ends about 100-110, there's no problem here.  Even/odd 
is ONLY to avoid glare when both sides decide to open a channel "at the 
same time".  If you add a pre-negotiated channel after initial 
establishment, it's up to you to avoid colliding with any existing 
channels and to avoid colliding with any in-process-of-creation dynamic 
(data-protocol) channels.  There are a number of ways to avoid such a 
collision safely (never use dynamic channels; use the DTLS role or an 
existing dynamic channel id to determine even/odd, etc).

>> My proposal has three elements, which together can guarantee that 
>> there are no stream id allocation conflicts between peers:
>>     1. The browser and application select stream ids based on initial 
>> SDP offerer/answerer role rather than DTLS role (e.g., initial 
>> offerer uses even ids, initial answerer uses odd ids). With this 
>> rule, the offering application knows its role immediately without 
>> waiting for the DTLS or SDP handshake to occur.
>
> A similar issue has come up in the discussion of partial 
> offers/answers. (Regarding how to assign a=mid values.) And a similar 
> solution was proposed.
>
> It was then rejected on the basis that sometimes both "ends" think 
> they are offerers or answerers. This comes about as a result of 
> signaling-only B2BUAs that play games with O/A on two legs.

Exactly why we went with DTLS roles.

-- 
Randell Jesup -- rjesup a t mozilla d o t com