Re: [rtcweb] Data channel: Handling of packets on unknown channels

Taylor is correct. In that thread, we agreed that the PeerConnection doc
should say "tough luck".

On Thu, Jun 28, 2018 at 10:38 AM Taylor Brandstetter <deadbeef=
40google.com@dmarc.ietf.org> wrote:

> Note that I started a thread about this last month:
> https://mailarchive.ietf.org/arch/msg/rtcweb/lIuiu91_L2nOh935eAqifrs_ius
>
> On Thu, Jun 28, 2018 at 8:19 AM, Michael Tuexen <
> michael.tuexen@lurchi.franken.de> wrote:
>
>>
>>
>> > On 28. Jun 2018, at 17:01, Harald Alvestrand <harald@alvestrand.no>
>> wrote:
>> >
>> > Den 28. juni 2018 16:35, skrev Michael Tuexen:
>> >>> On 28. Jun 2018, at 16:22, Harald Alvestrand <harald@alvestrand.no>
>> wrote:
>> >>>
>> >>> Den 28. juni 2018 14:51, skrev Michael Tuexen:
>> >>>>> On 28. Jun 2018, at 13:30, Harald Alvestrand <harald@alvestrand.no>
>> wrote:
>> >>>>>
>> >>>>> In considering the datachannel API, we encountered one interesting
>> race
>> >>>>> condition:
>> >>>>>
>> >>>>> A: <configure for datachannel>
>> >>>>>
>> >>>>> A: CreateOffer(), SetLocalDescription(), send SDP
>> >>>>>
>> >>>>> B: SetRemoteDescription, CreateAnswer, SetLocalDescription, send SDP
>> >>>>>
>> >>>>> B: Configure an externally defined data channel, with #3249
>> >>>>>
>> >>>>> B: Send a message on #3249
>> >>>>>
>> >>>>> A: SetRemoteDescription
>> >>>>>
>> >>>>> A: Wait a while (THE PAUSE)
>> >>>>>
>> >>>>> A: Configure #3249
>> >>>>>
>> >>>>> Now, if a message comes in to A on #3249 during THE PAUSE, what is
>> the
>> >>>>> implementation to do?
>> >>>> Isn't that some kind or error condition?
>> >>>>
>> >>>> If that it true, one could apply:
>> >>>>
>> >>>>  If a message with an unsupported PPID is received or some error
>> >>>>  condition related to the received message is detected by the
>> receiver
>> >>>>  (for example, illegal ordering), the receiver SHOULD close the
>> >>>>  corresponding data channel.  This implies in particular that
>> >>>>  extensions using additional PPIDs can't be used without prior
>> >>>>  negotiation.
>> >>>
>> >>>
>> >>> The receiver can't close the datachannel if the datachannel doesn't
>> >>> exist yet, so this doesn't work for that case.
>> >> I was assuming that the SCTP receives a user message on a stream. When
>> >> this message is delivered to its upper layer, doesn't this layer know
>> >> that there is no data channel? I would assume that this layer triggers
>> >> the stream reset procedure. I'm not saying that the user (for example
>> >> via a JS API) is involved... I'm more talking about implementing this
>> >> iside the browser..
>> >
>> >
>> > Exactly, it could close the stream, but it can't close the data channel
>> > since it doesn't exist.
>> Well, I can run the procedure and the peer will get an indication that
>> something isn't working well.
>> >
>> > I think closing the stream would be a mistake, since that would make the
>> > outcome about whether you end up with the datachannel or not racy;
>> > discarding data will give you a working datachannel once A gets around
>> > to configuring it.
>> But if the user configures a reliable data channel, the user does not
>> get the service that was required...
>>
>> Best regards
>> Michael
>> >
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>