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

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 23 Oct 2014 11:56:36 +0000

I have just posted an updated version of the MSRP document that gives one mapping for usage MSRP over draft-ejzak-mmusic-data-channel-sdpneg-01

The group (if any) that should handle this usage document is still as I went back and reread the dispatch minutes in regard to draft-ejzak-mmusic-data-channel-sdpneg and it is unclear to me whether one or both documents were dispatched to MMUSIC. I will try and get this clarified offline.

In any case, I have submitted it with an MMUSIC label as I think the MMUSIC folks are the next people who should be looking at it.

Regards

Keith

A new version of I-D, draft-ejzak-mmusic-msrp-usage-data-channel-00.txt
has been successfully submitted by Keith Drage and posted to the IETF repository.

Name:		draft-ejzak-mmusic-msrp-usage-data-channel
Revision:	00
Title:		MSRP over SCTP/DTLS data channels
Document date:	2014-10-23
Group:		Individual Submission
Pages:		11
URL:            http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-usage-data-channel-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage-data-channel/
Htmlized:       http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-channel-00

Abstract:
   This document specifies how the Message Session Relay Protocol (MSRP)
   can be instantiated as a data channel sub-protocol, using the the SDP
   offer/answer exchange-based external negotiation defined in
   [I-D.ejzak-mmusic-data-channel-sdpneg].  Two network configurations
   are documented: a WebRTC end-to-end configuration (connecting two
   MSRP over data channel endpoints), and a gateway configuration
   (connecting an MSRP over data channel endpoint with an MSRP over TCP
   endpoint).

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Oct 2014 12:30:44 -0400

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"

* 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???)

* 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?

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?

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

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

	Thanks,
	Paul

On 10/23/14 7:56 AM, DRAGE, Keith (Keith) wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 23 Oct 2014 20:11:42 +0000

Hi Paul,

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

> Instead of rewriting the transport rule from 4975, why not just extend

<Raju> 
Will change it.
</Raju>

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

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

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

> the media description" or "associated with the m-line".
<Raju>
Will change.
</Raju>

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Oct 2014 16:36:30 -0400

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

	Thanks,
	Paul

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 24 Oct 2014 15:26:37 +0000

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

If you agree I will update draft-ejzak-mmusic-data-channel-sdpneg and
draft-ejzak-mmusic-msrp-usage-data-channel with these clarifications.
</Raju>

BR
Raju

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Oct 2014 12:34:54 -0400

> using a new stream id, range is for which is large, without restarting underlying

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

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 24 Oct 2014 17:43:30 +0000

> you could simply send a new offer replacing the audio m-line with a T38

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

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

> (I think the above is what you are advocating.)

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

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Oct 2014 15:11:54 -0400

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

It might, or not.

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

>    Not sure if onclose() is called after SCTP reset is acknowledged or before?!

Then they should fix it.

>    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

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 24 Oct 2014 20:02:59 +0000

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

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

> >    Not sure if onclose() is called after SCTP reset is acknowledged or

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

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 26 Oct 2014 16:11:01 +0000

Hi,

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

I am not sure whether you need to say anything about this.

How to create the answer is a generic text, and there is already procedure text in section 5.1.1 draft-ejzak-mmusic-data-channel-sdpneg-01 for this.

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Sun, 26 Oct 2014 17:27:18 +0000

Hi Christer,

> 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.
> 
> How to create the answer is a generic text, and there is already procedure
> text in section 5.1.1 draft-ejzak-mmusic-data-channel-sdpneg-01 for this.

<Raju>
I agree that the procedural text belongs to draft-ejzak-mmusic-data-channel-sdpneg.
However, some clarifications are missing there as well. So, we will add it to that draft.
</Raju>

Thanks
Raju