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

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

> On 10/24/14 11:26 AM, Makaraju, Maridi Raju (Raju) wrote:
> >>> Suppose the intent is to close one MSRP session and immediately open a
> >>>> new one. Is it permissible to simply update the SDP to describe the new
> >>>> MSRP session, reusing the channel number, without first doing an O/A to
> >>>> confirm the closure of the old one?
> >>> <Raju>
> >>> The intent is not to reuse a datachannel (same or a different
> subprotocol)
> >>> before close. We will clarify that such a reuse is not supported.
> >>> The problem with such reuse is, previous datachannel MUST be reset
> before
> >>> it is used for new subprotocol, else the data from previous data channel
> >> use
> >>> will interfere with the new data channel use.
> >>
> >> My question is: Can I just close it in-band (with a reset) and then send
> >> an offer for the new usage of the channel?
> >
> > <Raju>
> > No. To reuse a closed data channel, a new SDP offer/answer, to convey the
> > data channel closure (which excludes the corresponding a=dcmap and may
> include
> > other new data channels via new a=dcmaps), must be done. This can be done
> either
> > in a new offer initiated from this end or in an SDP answer this end
> generates.
> > The reason for this is to avoid various race conditions between SDP
> offer/answer
> > and SCTP reset arrival times.
> > Also, this is not a limiting thing as a new data channel can easily be
> created
> > using a new stream id, range is for which is large, without restarting
> underlying
> > SCTP/DTLS association.
> 
> ISTM there is a useful analogy here to reusing m-lines.
> It once was thought that if you had been using an m-line for one thing
> (say an audio session), and then you wanted to stop that and start using
> that m-line for something else (say T38), you first had to send an offer
> setting the port to zero on the audio line, and then in a later offer
> you could then reuse that rejected m-line for T38.
> 
> Eventually it was clarified that this was silly and unnecessary - that
> you could simply send a new offer replacing the audio m-line with a T38
> m-line.

<Raju2>
The above scenario is very well valid as there is no inband "SCTP Reset" equivalent 
procedure exists for RTP/UDP based media. Please see my further explanation below; the
SCTP reset makes such a reuse problematic. Also, I think the new offer many times uses
a new transport address (at least the port), which makes such a reuse easy.
</Raju2>

> 
> 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 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?!
- 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.
</Raju2>

> 
> The following also ought to be valid:
> 
> 1) offer with dcmap for channel C, subprotocol C1, label C1
> 2) use channel C, subprotocol C1
> 3a) offer lacking channel C
> 3b) send reset on channel C
> 4) offer with dcmap for channel C, subprotocol C2, label C2
> 5) use channel C, subprotocol C2
> 
> (I think the above is what you are advocating.)

<Raju2>
Correct. It is valid, allowed and is what we are advocating.
</Raju2>

> 
> The following should *not* be valid:
> 
> 1) offer with dcmap for channel C, subprotocol C1, label C1
> 2) use channel C, subprotocol C1
> 4) offer with different dcmap for channel C, subprotocol C2, label C2
> 5) use channel C, subprotocol C2

<Raju2>
Correct. It is not valid.
In the first scenario above, this is how it looks like to the peer 
if SCTP reset is not yet received at the time of this offer arrives.

We planned on updating the draft-ejzak-mmusic-data-channel-sdpneg with the following:
1. In a new SDP offer, if a=dcmap specifies same subprotocol and label as previous one
   then the updated subprotocol attributes (in a=dcsa lines) are handled per the 
   subprotocol semantics.

2. In a new SDP offer, if a=dcmap specifies a different subprotocol and/or label than
   the previous offer then the offer must be rejected entirely so that previous 
   SDP offer/answer is still valid.

Appreciate your comments on this as well.
</Raju2>

Thanks
Raju