Re: [rtcweb] Data Channel Negotiation and reopening of decisions

[Randell Jesup <[e-mail]>]

On 2/13/2013 5:58 PM, Martin Thomson wrote:
> On 13 February 2013 14:24, Cullen Jennings <[e-mail]> wrote:
>> To help this move quickly, could someone just draw out the various call flows and shows the pro's con's of them so that everyone is on the same page?
> I'm not sure that this will help, or even cover all the nuances effectively...

Thanks, this should help people.

> in-band negotiation only:
> http://www.websequencediagrams.com/?lz=dGl0bGUgZGF0YSBjaGFubmVsIHN0YXR1cyBxdW8KCkFsaWNlLT5Cb2I6IE9mZmVyCm5vdGUgcmlnaHQgb2YgABQFQm9iIHRoaW5rcyBhYm91dCBpdApCb2ItPgA5BTogQW5zdwAyCG92ZXIgAFEFADYGSUNFLCBEVExTLCBTQ1RQLCBldGMuLi4Aaw5wZW4gKCJsYWJlbCIsIHN0cmVhbSBYLACBKApldHRpbmdzKQCBBhhjYW4gcmVzcG9uZCBvbiBhbnkgYXZhaWxhYmxlAEkHAIElDU9wZW5SACsFc2UAaBJZKQCCCw1Mb2NrSXRJAIEZCgCBAAcAgVsQAIJYCGlzIHJlYWR5AIJQDWRhdGE&s=napkin
Adjusted and cleaned up.  Note one confusion was the assumption that 
there's label-glare-resolution; there isn't.  The response and ack 
messages carry the stream numbers (explicitly or implicitly), not 
labels.  Fixed.

http://www.websequencediagrams.com/?lz=dGl0bGUgZGF0YSBjaGFubmVsIHN0YXR1cyBxdW8KCkFsaWNlLT5Cb2I6IE9mZmVyCm5vdGUgcmlnaHQgb2YgABQFQm9iIHRoaW5rcyBhYm91dCBpdApCb2ItPgA5BTogQW5zdwAyCG92ZXIgAFEFADYGSUNFLCBEVExTLCBTQ1RQLCBldGMuLi4Aaw5wZW4gKCJsYWJlbCIsIHN0cmVhbSBYLACBKApldHRpbmdzKQCBBhhjYW4gcmVzcG9uZCBvbiBhbnkgYXZhaWxhYmxlAEkHAIElDU9wZW5SACsFc2UgKABnCgB0B1kAVBVvbkRhdGFDAIJABgCCLQ1Mb2NrSXRJbgBBCgCBIwdsZWYAgkIFAIIiB29ub3BlbiBldmVudACCbg1kYXRhAF0WACYLAIJnDGRhdGE&s=napkin


> SDP negotiation only:
> http://www.websequencediagrams.com/?lz=dGl0bGUgZGF0YSBjaGFubmVsIFNEUCBvbmx5Cgpub3RlIGxlZnQgb2YgQWxpY2U6AAEGIGNyZWF0ZXMALAgKABgFLT5Cb2I6IE9mZmVyADYGcmlnaAA4BQAUBUJvYiBnZXRzICdkYXRhAGgHJyBldmVudApCb2ItPgBcCG5zdwA7CG92ZXIAbgcAWQVJQ0UsIERUTFMsIFNDVFAsIGV0Yy4uLgB1DQCBSgUoc3RyZWFtIFgpAHgUABcGcyBhcmUgbGlua2VkIGJhc2VkIG9uIG5lZ290aWF0ZWQgbGFiZWwgaW4gc3RhdHVzIHF1bwCBHQ1tb3IAgjcHAGcIWSkAgXUYAII6D1RoaXMgbQCCHAV1c2UgdGhlIGV4aXN0aW5nAIMDDQCCBhQAgVQZUSk&s=napkin

Added onopen events, detail on second open

http://www.websequencediagrams.com/?lz=dGl0bGUgZGF0YSBjaGFubmVsIFNEUCBvbmx5Cgpub3RlIGxlZnQgb2YgQWxpY2U6IGNyZWF0ZURhdGFDACoGCgAUBS0-Qm9iOiBPZmZlcihsYWJlbCwgc3RyZWFtIFgsIHBhcmFtcykASwZyaWdoAE0FAC0Fb25kYXRhAHQIYW5kIG9ub3BlbiBldmVudHMKQm9iLT4AdQdBbnN3AE4RWQBQBwCBGQ8AOgwAgUMGb3ZlcgCBQAYAdAZJQ0UsIERUTFMsIFNDVFAsIGV0Yy4uLgCBQw0AghQFKACBQQgpAIEBDW1vcgCCMwcAGQgAdBcAghAjAIFURgCBZyIAgUMZUSk&s=napkin


> Randell's 0RTT in-band option:
> http://www.websequencediagrams.com/?lz=dGl0bGUgZGF0YSBjaGFubmVsIGZhc3QgaW4tYmFuZAoKQWxpY2UtPkJvYjogT2ZmZXIKQm9iLT4AEgU6IEFuc3dlcgpub3RlIG92ZXIgACoFIAApBUlDRSwgRFRMUywgU0NUUCwgZXRjLi4uAEQOcGVuICgibGFiZWwiLCBzdHJlYW0gWCwAgQQJc2V0dGluZ3MpAHwNZGF0YQBvBnJpZ2h0IG9mAG0Gb25kYXRhAIFBCCsgb25vcGVuAAQFbWVzc2FnZSBldmVudHMAgTgNT3BlblJlc3BvbnNlAHsSWQBtDkxvY2tJdEkAgSwKKQo&s=napkin

Adjusted.  Same comment as in-band above

http://www.websequencediagrams.com/?lz=dGl0bGUgZGF0YSBjaGFubmVsIGZhc3QgaW4tYmFuZAoKQWxpY2UtPkJvYjogT2ZmZXIKQm9iLT4AEgU6IEFuc3dlcgpub3RlIG92ZXIgACoFIAApBUlDRSwgRFRMUywgU0NUUCwgZXRjLi4uAEQOcGVuICgibGFiZWwiLCBzdHJlYW0gWCwAgQQJc2V0dGluZ3MpAF4GbGVmdCBvZgBhBjogb25vcGVuIGV2ZW50AIEdDWRhdGEAgRAGcmlnaAAuBQCBPQVvbmRhdGEAgWIIKwA5CCsgb25tZXNzYWdlAEcGcwCBWQ1PcGVuUmVzcG9uc2UgKACBHwZYAIElCVkpAIIGDQB2BQCCKgxMb2NrSXRJbgAxCSkK&s=napkin

> No negotiation option:
> http://www.websequencediagrams.com/?lz=dGl0bGUgZGF0YSBjaGFubmVsIG5vIG5lZ290aWF0aW9uIG9wdGlvbgoKCkFsaWNlLT5Cb2I6IE9mZmVyCkJvYi0-ABIFOiBBbnN3ZXIKbm90ZSBvdmVyIAAqBSAAKQVJQ0UsIERUTFMsIFNDVFAsIGV0Yy4uLgBFDgCAfwUoc3RyZWFtIFgpAFANcmVwbHkAEQwAYgZsZWZ0IG9mAGUGOiBjcmVhdGVEYXRhQwCBRAcoWSkAShpZKQCBKAZyaWdoAEIFAIFVBTMgZXZlbnRzIG9uZGF0YQCCDQgrIG9ub3BlbgAEBW1lc3NhZ2UAgQgbAFQIAIF6EERyYXdiYWNrOiBCb2IgYW5kAIIgB20AgH8FaGF2ZSBkaWZmZXJlbnQgbGFiZWxzL3Byb3BlcnRpZXMAgkgWU29sdXRpb246AIMuCWUAg0QIcyBpZiB5b3UgY2FyZQCDBhZDb25zdHJhaW50OiAAgjAHcyB1c2UgdGhlIHNhbWUgAIMMB251bWJlciBvbiBib3RoIGVuZHMsIG5vAIEfCA&s=napkin

Not sure what's going on here with Stream X - is there a missing 
assumption of SDP negotiation of Stream X?  The strong exposure of 
Stream numbers here implies they're surfaced to the application, no?  Or 
is it totally dependent on ordering of opens, and in the glare case they 
get cross-connected as one DataChannel with no notification of this 
(neither side gets onDataChannel).

For StreamY from bob->alice (the "reply" direction): what are the 
properties?  This also implies that the JS API has to change to let you 
set transport properties on a channel that came from onDataChannel.

Obviously there's no way to know anything about an incoming 
"onDataChannel" event not due to SDP; I'm sure your comment would be "if 
that matters, negotiate it".   How does the application cause 
negotiation to happen?  (More JS API change I assume).

I think there are unexplored interactions between SDP negotiation (and 
stream number selection) and this (dynamic no-negotiation creation).  
You might need to fail SDP requests to open stream X if the answerer has 
opened a channel on Stream X before seeing the SDP, or have the answerer 
pick the stream (but that causes problems when data from the answerer 
arrives before the Answer).

> What we really have at the moment is both in-band + SDP.  I was
> proposing that we go to SDP only, and maybe also allow the zero
> negotiation option at the expense of consistency.  (Not just because
> eventual consistency is web-scale.)

I'm not sure exactly what the last statement here means.

-- 
Randell Jesup
[e-mail]