Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

On Apr 18, 2013, at 7:00 PM, Martin Thomson wrote:

> On 18 April 2013 09:51, Harald Alvestrand <harald@alvestrand.no> wrote:
>> Yep, "reset the stream" is probably the right terminology.
> 
> Note that I was using a very specific terminology, not making shit up
> (I know, it's hard to tell sometimes).  c.f.
> http://tools.ietf.org/html/rfc6525#section-4.2
> 
> Unfortunately, the "Incoming SSN Reset Request Parameter" doesn't
> include a way to signal that a particular reset is somehow different
> from a normal close.  Therefore, unless you look at the SACK chunks -
> which is probably not possible above the SCTP layer - you can't tell
> the difference between:
> - I got your data and I'm done with this channel now
> - The OPEN message got lost for long enough that I ran out of
> buffering time or space, so this channel is borked; nothing was
> delivered
What brings up a question, since I'm not really familiar with the JS API.

If I have a data channel dc and call close() on the data channel. Are
incoming messages still delivered, i.e. does onmessage still fire?

Best regards
Michael
> 
> This is where I think that Bernard was going with this.  It's not that simple.
> 
> I really don't want to get back to the point where we require
> application-level (read: browser-level) acknowledgement of OPEN
> messages to address this corner case.  But we have to acknowledge that
> it's a problem and deal with it somehow.  (HTTP/2.0 has an error
> message that it uses for this sort of case, maybe that could be a
> solution, assuming that the stream ID on the reverse path is
> available.)
> 
> --Martin
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 