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

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

Hi Paul,

Thanks much for thorough comments.
Please see my inline responses.

> IMO this document is important even to those who don't care about MSRP,
> because it will set a precedent for how to map existing protocols on top
> of data channels.
> 
> A few comments:
> 
> * Section 4.3:
> 
> Instead of rewriting the transport rule from 4975, why not just extend
> it? I.e.,
> 
> 	transport =/ "dc"

<Raju> 
Will change it.
</Raju>

> 
> * Section 5.1.1.1
> 
> The following seems overly stringent:
> 
>     The SDP answer shall include the exact same attribute line to
>     indicate acceptance of the data channel instance.
> 
> This seems to require a byte-by-byte copy. That precludes independently
> generating an equivalent attribute. ISTM it is sufficient to require the
> attribute in the answer to meet the same requirements as that in the
> offer, and to have the same channel number. (And label???)

<Raju> 
Correct. In theory a simple answer of "a=dcamp:2" is sufficient (especially
since we are now going to make "subprotocol" as optional) to indicating 
acceptance of that particular data channel.
However, to make it consistent with rest of the SDP style, we will change 
the text to indicate subprotocol parameter MUST be included in answer with 
an optional label (matching or non-matching). They may appear in any order.

We need to remove '"stream=" streamidentifier' as it is now integrated with "dcmap:".
</Raju>

> 
> * Section 5.1.5
> 
>     ... Closing an MSRP
>     session should trigger an SDP negotiation where the SDP attributes
>     for each affected data channel are removed.
> 
> I don't know how to interpret this - what does the "should" mean? Is it
> SHOULD, MUST, MAY? What if it isn't done? Which end is responsible for
> initiating this O/A? Or does this just mean that the SDP should be
> updated to reflect the closure the next time there is need to do an O/A?
<Raju>
This section will be updated to align with http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-01#section-5.2.3

Above reference says that if a new SDP offer is used to close a data channel then
closing of data channel (which triggers SSN reset) can only be sent after
SDP offer/answer sequence is completed.
However, application may decide to close a data channel, without sending a new offer,
by just informing the local datachannel stack. Also per above reference,
a peer, upon getting close notification, SHOULD generate a new offer which excludes
the closed stream. This is to make sure the data channel close is communicated end to end
(useful in scenarios where middle boxes are involved and only one end may receive the
data channel close due to interworking with other transports).

Also the above reference needs to be further clarified about this optional SDP offer to
initiate closing of a datachannel.

</Raju>

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

</Raju>

> 
> * General
> 
> There are a couple of places that refer to an attribute "within the m
> line". That isn't quite right. A better way to say that would be "within
> the media description" or "associated with the m-line".
<Raju>
Will change.
</Raju>

> The inclusion of a=sctp-port in the examples throughout is an
> unnecessary distraction. It isn't necessary because it has a default. (I
> don't see *any* currently planned uses for webrtc-datachannel where
> there is need to specify the sctp port.)
<Raju>
You are right; I do not see any such non-default use cases either.
We will remove a=sctp-port lines.
</Raju>

Thanks
Raju