Subject: [rtcweb] *MUST* DCEP?

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Mar 2014 11:03:04 +0000

Ted,

(I think this was open issue #8)

You closed discussion on this, saying that this should be specified in 
some rtcweb "system" document. IIUC, then I disagree.

This is important to others besides rtcweb. We want to use this 
mechanism, both with and without components that are implementing 
rtcweb. Certainly for non-browsers.

This ultimately comes down to what I can expect after having negotiated 
(in SDP) the establishment of an SCTP association. When doing so, I use 
a=sctpmap to negotiate the how the association will be used. If I intend 
to use data channels and DCEP then I want an assurance that the other 
end does too. (That is the purpose of the SDP negotiation.)

AFAIK, current when I specify 'a=sctpmap:webrtc-datachannel' (or 
'a=sctp-datachannel' depending on where I look), that means the other 
side supports data channels *and* guarantees support for DCEP. There is 
no means to indicate support for data channels *without* DCEP.

I don't see any urgent need to have data channels without DCEP, as long 
as *use* of DCEP is optional.

IMO things would be less confusing if the two documents were merged into 
one, that defines the *Data Channel Protocol* (that runs over SCTP). 
This protocol runs over pairs of SCTP streams, has a small number of 
messages (open, ack, string-payload, binary-payload, close), and encodes 
them in SCTP using SCTP messages with particular payloads and SCTP 
stream reset. The open and ack messages would be optional.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Tue, 4 Mar 2014 11:08:28 +0000

On 4 March 2014 11:03, Paul Kyzivat <[email-masked]> wrote:
>
> This is important to others besides rtcweb. We want to use this mechanism,
> both with and without components that are implementing rtcweb. Certainly for
> non-browsers.

if (need(DCEP)) {
  addStatementToMyDoc("MUST", DCEP)
}

---

From: Ted Hardie <[email-masked]>
Date: Tue, 4 Mar 2014 11:17:12 +0000

On Tue, Mar 4, 2014 at 11:03 AM, Paul Kyzivat <[email-masked]> wrote:

> both with and without components that are implementing rtcweb. Certainly
> for non-browsers.
>
>
Help me understand why it wouldn't then be in their systems documents?

Ted

> a=sctpmap to negotiate the how the association will be used. If I intend to
> use data channels and DCEP then I want an assurance that the other end does
> too. (That is the purpose of the SDP negotiation.)
>
> 'a=sctp-datachannel' depending on where I look), that means the other side
> supports data channels *and* guarantees support for DCEP. There is no means
> to indicate support for data channels *without* DCEP.
>
> I don't see any urgent need to have data channels without DCEP, as long as
> *use* of DCEP is optional.
>
> one, that defines the *Data Channel Protocol* (that runs over SCTP). This
> protocol runs over pairs of SCTP streams, has a small number of messages
> (open, ack, string-payload, binary-payload, close), and encodes them in
> SCTP using SCTP messages with particular payloads and SCTP stream reset.
> The open and ack messages would be optional.
>
>         Thanks,
>         Paul
>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 4 Mar 2014 12:08:18 +0000

While a=sctpmap assumes use of DCEP, indication of external negotiation (instead of DCEP) also requires subprotocol and it's parameters to be conveyed. This has to be done per data channel stream.
Are you looking at more than what is documented in [I-D.ejzak-mmusic-data-channel-sdpneg]?
Or are you looking for an indication of this (for all streams) directly in a=sctpmap?

How about item 3 of the following proposal?
http://www.ietf.org/mail-archive/web/mmusic/current/msg13155.html

-Raju

From: rtcweb [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Tuesday, March 04, 2014 5:17 AM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [rtcweb] *MUST* DCEP?

On Tue, Mar 4, 2014 at 11:03 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
Ted,

You closed discussion on this, saying that this should be specified in some rtcweb "system" document. IIUC, then I disagree.

This is important to others besides rtcweb. We want to use this mechanism, both with and without components that are implementing rtcweb. Certainly for non-browsers.

Ted

This ultimately comes down to what I can expect after having negotiated (in SDP) the establishment of an SCTP association. When doing so, I use a=sctpmap to negotiate the how the association will be used. If I intend to use data channels and DCEP then I want an assurance that the other end does too. (That is the purpose of the SDP negotiation.)

AFAIK, current when I specify 'a=sctpmap:webrtc-datachannel' (or 'a=sctp-datachannel' depending on where I look), that means the other side supports data channels *and* guarantees support for DCEP. There is no means to indicate support for data channels *without* DCEP.

I don't see any urgent need to have data channels without DCEP, as long as *use* of DCEP is optional.

IMO things would be less confusing if the two documents were merged into one, that defines the *Data Channel Protocol* (that runs over SCTP). This protocol runs over pairs of SCTP streams, has a small number of messages (open, ack, string-payload, binary-payload, close), and encodes them in SCTP using SCTP messages with particular payloads and SCTP stream reset. The open and ack messages would be optional.

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Mar 2014 14:50:56 +0000

IIUC rtcweb is predicated on the assumption that there is a single 
entity orchestrating the "system" including both of the endpoints of the 
sctp association. You therefore assume that you can a priori assume that 
both ends conform to your "systems document".

A sip endpoint doesn't have that. A major purpose of the signaling and 
the O/A exchange is to find out what we agree to. We won't know in 
advance if the other endpoint follows the CLUE "systems document".

ISTM that you are defining things so that we must use some mechanism to 
negotiate an application-specific agreement between the two ends about 
use of data channels *before* using any data channels.

With the ejzak draft we can use the O/A to negotiate a specific clue 
subprotocol, and then have a reasonable expectation that we can follow 
our own documentation of that protocol to go on.

Using DCEP would be more straightforward, especially for browser based 
endpoints. But if we can't even depend on support of DCEP when we have a 
data channel SCTP association, then DCEP is less useful.

	Thanks,
	Paul

On 3/4/14 11:17 AM, Ted Hardie wrote:
>     You closed discussion on this, saying that this should be specified
>     in some rtcweb "system" document. IIUC, then I disagree.
>
>     This ultimately comes down to what I can expect after having
>     negotiated (in SDP) the establishment of an SCTP association. When
>     doing so, I use a=sctpmap to negotiate the how the association will
>     be used. If I intend to use data channels and DCEP then I want an
>     assurance that the other end does too. (That is the purpose of the
>     SDP negotiation.)
>
>     'a=sctp-datachannel' depending on where I look), that means the
>     other side supports data channels *and* guarantees support for DCEP.
>     There is no means to indicate support for data channels *without* DCEP.
>
>     IMO things would be less confusing if the two documents were merged
>     into one, that defines the *Data Channel Protocol* (that runs over
>     SCTP). This protocol runs over pairs of SCTP streams, has a small
>     number of messages (open, ack, string-payload, binary-payload,
>     close), and encodes them in SCTP using SCTP messages with particular
>     payloads and SCTP stream reset. The open and ack messages would be
>     optional.
>
>              Thanks,
>              Paul
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Mar 2014 14:58:33 +0000

On 3/4/14 12:08 PM, Makaraju, Maridi Raju (Raju) wrote:
> While a=sctpmap assumes use of DCEP, indication of external negotiation
> (instead of DCEP) also requires subprotocol and it’s parameters to be
> conveyed. This has to be done per data channel stream.
>

I'm ok as things currently stand, though the documents are confusing.
The 'a=sctpmap:nnn websocket-datachannel' means that DCEP is supported.

My concern was a proposal I think I heard that would make support for 
DCEP to be optional. In that case, IMO it is important that the O/A 
exchange establish whether DCEP is supported or not.

	Thanks,
	Paul

> *From:*rtcweb [mailto:[email-masked]] *On Behalf Of *Ted Hardie
> *Sent:* Tuesday, March 04, 2014 5:17 AM
> *To:* Paul Kyzivat
> *Cc:* [email-masked]
> *Subject:* Re: [rtcweb] *MUST* DCEP?
>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 4 Mar 2014 15:39:54 +0000

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, March 04, 2014 8:59 AM
> > (instead of DCEP) also requires subprotocol and it's parameters to be

[Raju]
That's the reason why I proposed to add 'protocol' parameter to a=dcmap.
Having this parameter at a=sctmap level may not make that much sense due to:
sctpmap is for entire association and protocol defaults to DCEP. To make use of external negotiation, which is per data channel stream, one would need additional a= line(s) (e.g. ejzak's draft) to convey subprotocol info. IMO adding data channel protocol option to a=dcamp, which is per subprotocol, makes sense.
[/Raju] 

Best Regards
Raju

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Mar 2014 16:36:34 +0000

> sctpmap is for entire association and protocol defaults to DCEP. To make use of external negotiation, which is per data channel stream, one would need additional a= line(s) (e.g. ejzak's draft) to…

I have no problem with a=dcmap.

It is the 'app' parameter of the sctpmap attribute that I am talking about.

If I want to use DCEP, the dcmap attribute is irrelevant to me. What is 
it that tells me that DCEP is supported. The only datum available that 
could imply that is the 'app' parameter of sctpmap.

Right now, if app is webrtc-datachannel, that implies DCEP is MTI. That 
serves the purpose.

But as of today there was a suggestion that you could have cases where 
there is an SCTP association that supports Data Channels, but not DCEP. 
I don't know how the two would be distinguishable. Possibly by a 
different 'app' value.

A related question is what is the applicability of a=dcmap. Surely it 
doesn't apply for all uses of SCTP - those that don't use data channels 
at all. Do you propose to couple this to particular 'app' values? Or is 
support for this negotiated independently of a=sctpmap?

	Thanks,
	Paul

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 4 Mar 2014 19:43:28 +0000

> > sctpmap is for entire association and protocol defaults to DCEP. To make
> use of external negotiation, which is per data channel stream, one would
> need additional a= line(s) (e.g. ejzak's draft) to convey subprotocol info.
> IMO adding data channel protocol option to a=dcamp, which is per
> subprotocol, makes sense.
> > [/Raju]
> 

[Raju] 
Yes, one option is to define a new 'app'. 
Another option is to use 'webrtc-datachannel', but then convey your own
external data channel protocol via SDP and use it for all the streams.
When you say "not DCEP", you mean it is "external" or "a different flavor
of internal DCEP"? 

[/Raju]

> support for this negotiated independently of a=sctpmap?
[Raju] 
Correct. dcmap applies to SCTP data channels only. dcmap's 'protocol' parameter
allows you to override webrtc default DCEP per data channel stream.
When you are using dcmap it allows per data channel "interal(DCEP)" or 
"external(SDP based)" determination using 'protocol' parameter.
If there is a need we can allow the 'protocol' value to be extended (per IANA, may be?!
):
"internal-DCEP"
"external-SDP-based" (ejzak's draft)
"new-enhanced-internal-DCEP"
"pre-defined-stream-id-use-arrangement"

[/Raju]

Best Regards
Raju