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

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

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.

> 
> 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.

Thanks
Raju