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

[Paul Kyzivat <[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.

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

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

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

	Thanks,
	Paul