1017462 - Add data channel test with asymmetric negotiated channel

Status: NEW

(Core :: WebRTC: Networking, defect, P5)

Description

[Nils Ohlmeier [:drno]]

Add a test case to the data channel tests which utilizes and tests the negotiation feature of the data channels to create an asymmetric channel and verify that works as expected.

Comment 1

[Philipp Hancke]

I had a chat with jesup about negotiated data channels recently when I ran into an issue with the id attribute. Unlike chrome, the id only gets assigned once ice and sctp are up.
See http://hancke.name/tmp/dc_nego.html (modified from a chrome sample), in particular lines 113 and 186/187. 

TYMLTK

Comment 2

[Nils Ohlmeier [:drno]]

Thanks for letting me know.
Can you provide more details what the problem is?
Or is there another Bugzilla ticket for the problem which we could link here?

Comment 3

[Philipp Hancke]

quoting (with permission):
21:34 <jesup> yeah... We queue Opens if there's no pre-selected ID until SCTP is up
21:40 <jesup> I'm digging in a little more to give you a definitive answer
21:40 <fippo> thanks!
21:54 <jesup> http://dxr.mozilla.org/mozilla-central/source/netwerk/sctp/datachannel/DataChannel.cpp#2047 is where we queue opens to finish once SCTP
21:54 <jesup> We then re-call OpenFinish after the channel opens, and in the earlier mState == OPEN case before that is where we call FindFreeStream() to allocate an id
21:54 <jesup> So it's not valid until onopen (if you didn't specify)
21:54 <jesup> We can't allocate even/odd until SCTP_COMM_UP (in theory we could do it a little earlier, once DTLS is up where we call usrsctp_connect())
21:55 <jesup> What does the spec say?  (doesn't mean it's right, note.)  
21:56 <fippo> let me check... probably something that should be raised on the w3c list
21:56 <fippo> 'If id attribute is uninitialized (not set via the dictionary), initialize it to a value generated by the user agent, according to the WebRTC DataChannel Protocol specification, and skip to 
              the next step. Otherwise, if the value of the id attribute is taken by an existing RTCDataChannel, throw a ResourceInUse exception and abort these steps.
21:57 <fippo> http://dev.w3.org/2011/webrtc/editor/webrtc.html#attributes-5  bullet 7
22:00 <jesup> hmmmm.  Not really correct IMHO; You can't reliably allocated an id that the other side won't collide on until you know even/odd
22:01 <fippo> but you can decide odd/even based on role? I wonder what chrome does
22:04 <jesup> I suspect they hard-coded role based on "have we installed a remote description yet" - inferring if it's an answer or an offer.  Or more likely it's a bug and you're playing with fire if 
              both sides try to open channels where the browser selects the id (before the second side creates a channel with that id)
22:06 <jesup> i.e. on receiver side if you do CreateDataChannel("",{negotiated:true}); CreateDataChannel("",{id=from_other_side, negotiated=true}); you may get a collision.  In the other order you'd be 
              ok.  I'm guessing they just start at 0, or guess even until it's connected
22:07 <jesup> I'm betting on "just guess even" until connected, and count on the answerer installing pre-negotiated channels before trying to create a new one (which is likely, in fact)
22:12 <jesup> Either we need to mandate that client ordering, or state that an id isn't valid until onopen (which will complicate "allocate channels for me before setting up connection").  Of course, if 
              you're setting up channels before CreateOffer, and can ensure that the answerer will CreateDataChannel for their side before creating any automatic-id channels, then there's no need to not 
              hard-code the...
22:12 <jesup> ...ids (or just use a local counter)

Comment 4

[Bulk Bug Changes for mreavy's org]

Mass change P4->P5 to align with new Mozilla triage process.