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

[Paul Kyzivat <[e-mail]>]

On 10/24/14 1:43 PM, Makaraju, Maridi Raju (Raju) wrote:
>
>> 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.

I'll comment there. I don't think so.

> Also, I think the new offer many times uses
> a new transport address (at least the port), which makes such a reuse easy.

It might, or not.

> </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 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.

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.

> 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.

> - 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.

	Thanks,
	Paul

> </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
>