Re: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel

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

> >> So ISTM that here the following ought to be valid:
> >>
> >> 1) offer with dcmap for channel C, subprotocol C1, label C1
> >> 2) use channel C, subprotocol C1
> >> 3) send reset on channel C
> >> 4) offer with dcmap for channel C, subprotocol C2, label C2
> >> 5) use channel C, subprotocol C2
> >
> > <Raju2>
> > What if the "SCTP reset" from step3 above arrives at the peer after step4
> SDP offer?
> > If DP arrives first then the data channel will later be closed when SCTP
> reset arrives,
> > which is not expected behavior.
> > There is no guarantee that reset arrives first. This is unless the local
> client waits for
> > data channel close indication (SCTP reset ack) from data channel stack and
> sends new SDP offer.
> 
> The offerer won't send data based on the new offer until it has sent the
> reset, so there will be no ambiguity regarding data sent by the offerer.
> If the answerer wants to send data based on the new offer before it has
> received a reset, it can send a reset.

<Raju3>
I also don't see any ambiguity wrt sending new data on either side.
The issue is what happens if the SDP offer arrives before SCTP reset?
Per comment below you seem to indicate that a new SDP offer which reuses
closed stream MUST happen only after SCTP reset seq is acknowledged.

</Raju3>

> 
> Also, I'm a little fuzzy on how the SCTP reset works with channels. Is
> it necessary for each end to send a reset? If so, that makes it simpler.

<Raju3>
You are right on the SCTP resets.
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section-6.7 says both 
incoming and outgoing streams are reset.

</Raju3>

> 
> > The problem with depending on such "close indication" is:
> > - PeerConnection draft does not clearly say if and when it invokes
> onclose() callback on the
> >    side which invokes close().
> >    Not sure if onclose() is called after SCTP reset is acknowledged or
> before?!
> 
> Then they should fix it.

<Raju3>
I checked http://w3c.github.io/webrtc-pc/#data-transport-closed 
It seems to indicate that if close() is called by client then onclose() won't be called.

" An RTCDataChannel object's underlying data transport may be torn down in a non-abrupt manner by running the closing procedure. When that happens the user agent must, unless the procedure was initiated by the close() method, queue a task that sets the object's readyState attribute to closing. This will eventually render the data transport closed."

I can discuss with w3c to "trigger onclose() for close() case as well and only when 
both SCTP incoming/outgoing streams are reset".

</Raju3>

> 
> > - Not sure if non-browser clients will have a way (API) to know when
> >    SCTP reset is acknowledged. This depends on data channel stack
> implementation.
> 
> Again, this may depend on whether reset must be sent independently in
> each direction. I suspect it must, since reset is an SCTP function and
> SCTP doesn't associate pairs of streams.

<Raju3>
non-browser data channel stack implementations must also inform the application
only when SCTP streams are reset in both the directions. If such notification
is available then a new SDP offer can be initiated to reuse a closed stream.

We can update the drafts to indicate a stream can only be reused after SCTP resets
are done in both the directions. If a data channel stack implementation (including browsers)
does not have such an API to inform the client then it can't reuse the streams
without an additional SDP offer/answer to close it first.

</Raju3>

Thanks
Raju