Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel

[Paul Kyzivat <[e-mail]>]

I suspect we are not understanding one another.

On 2/28/14 4:46 PM, Makaraju, Maridi Raju (Raju) wrote:
> Hi Paul,
>
>
>>>> Isn't it enough to, in the data channel protocol spec, say that the
>> odd/even
>>>> rule applies unless the stream id is explicitly negotiated using some
>> other
>>>> mechanism?
>>>>
>>> [Raju] Yes, that is sufficient from DCP draft. draft-ejzak-mmusic-data-
>> channel-sdpneg should still need to say that "when both external and DCP are
>> used, even for DCP created streams the stream ids have to be specified and
>> managed by the application (else DCP stack will default to odd/even rule per
>> DTLS role which may conflict with SDP offer/answer rule)".
>>
>> Can we assume there must be a mechanism for using DCEP and still
>> controlling which channels are used?
>
> [Raju] Yes, we can assume that and it is already supported by :
> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-6.5
> and
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCDataChannel-id
> I believe it is safe to assume non-browser implementations of
> data channel stack gives an option for application to select
> stream ids independent of DCEP or external negotiation.
>
>
>>
>> It might help if the O/A negotiation also followed the even/odd rule.
> [Raju] May be I am missing something here. Richard's draft already has
> a specific even/odd rule for O/A. But the issue is TLS based rule may
> conflict with the O/A rule as TLS roles may change depending on a=setup.
>
>> But there are difficulties in knowing who is even and who is odd for the
>> first O/A.
>
> [Raju] Not related to first or subsequent O/A, but rather a conflict
> between TLS roles vs. O/A.

OK. I didn't state what I meant clearly, and I forgot Richard had an 
even/odd rule. For O/A there really isn't a need for one, since the only 
cases this will be a problem result in O/A glare, and that is then 
resolved via backoff.

What I meant was it might help if the O/A proposal and DCEP followed the 
*same* rule. I think that is what Richard wanted. But he showed why O/A 
can't use the existing DCEP rule, so *that* would be required to change.

>> If the offerer always creates the channel before sending the offer, then
>> that will prevent the two mechanisms from stepping on one another's
>> stream ids.
> [Raju]
> In some cases, initial offer may not have a data channel stream created.
> I don't know how this can prevent stepping on each other?!
> May be I am missing something here?! In most cases TLS role is
> determined after O/A is completed, but offerer creates a data
> channel before answer, then how does it know even/odd rule?
> So, trying to use TLS role for external negotiation is problematic.

For channels negotiated at the same time the SCTP association is 
negotiated the offerer can use *any* ids, since there can yet be no 
conflict.

Then, once the association is established, the channels declared in the 
SDP need to be "opened" (activated?), independently by both sides. They 
will then be reserved.

After that, if the application follows the DCEP even/odd rule, and 
creates the channel at its end before sending an offer, then that cannot 
conflict with channels dynamically allocated by DCEP. And both sides 
then understand who is even and who is odd, so there will be no 
conflicts by the two sides choosing the same channel.

	Thanks,
	Paul