Subject: [MMUSIC] SDPNEG: How to disable DCEP

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Apr 2019 08:37:15 +0000

Hi,

I had an off-line discussion with Bo regarding how to know whether to use SDPNEG or DCEP for a Data Channel.

Section 5 says:

   ”This section defines two new SDP media-level attributes that can be
   used together with the SDP Offer/Answer mechanism to negotiate data
   channel-specific and subprotocol-specific parameters without the
   usage of DCEP [I-D.ietf-rtcweb-data-protocol].”

Do we consider this clear enough that the presence of those attributes (well, only dcmap, since dcsa is optional) will “disable” usage of DCEP, or do we want to be more clear?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Apr 2019 18:25:02 -0400

On 4/24/19 4:37 AM, Christer Holmberg wrote:
> Do we consider this clear enough that the presence of those attributes 
> (well, only dcmap, since dcsa is optional) will “disable” usage of DCEP, 
> or do we want to be more clear?

The distribution of specs across multiple documents makes it really 
fuzzy what is normative for what.

Perhaps something should be said about the validity of using a 
webrtc-datachannel media stream for establishing data channels via SDP 
with dcmap and/or DCEP. I don't think this is said anywhere else.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Apr 2019 09:37:39 +0000

Hi Paul,

So, what is your suggestion? __

Regards,

Christer

On 25/04/2019, 1.25, "mmusic on behalf of Paul Kyzivat" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    	Thanks,
    	Paul
    
    _______________________________________________
    mmusic mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Apr 2019 11:15:52 -0400

> So, what is your suggestion? __

It looks to me like the 2nd paragraph of Appendix A is the right place 
for this:

    A WebRTC application creates a data channel by providing a number of
    setup parameters (subprotocol, label, maximal number of
    retransmissions, maximal retransmission time, order of delivery,
    priority).  The application also specifies if it wants to make use of
    the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if
    the application intends to negotiate data channels using the SDP
    offer/answer protocol.

I'm inclined to tweak the above as follows:

    ...
    the application intends to negotiate data channels using the SDP
    offer/answer protocol, or both.

And then, the note at the end of the section can be augmented:

    Note: The above SDP media description does not contain any channel-
    specific information. If data channels are to be negotiated using
    SDP, then the above will be supplemented as specified in Sections
    6.3 and 6.4.

But I'm not sure about "The application also specifies...". Is this 
referring to something specific in the webrtc API? If so, does it permit 
both? The presence of dcmap in the SDP will indicate the intent to use 
SDP negotiation, but must this first be enabled in the API?

	Thanks,
	Paul

---

From: "Roni Even (A)" <[email-masked]>
Date: Sun, 28 Apr 2019 06:21:41 +0000

Hi,
I think that sections 6.3 and 6.4 that discuss offer/answer say that dcmap is the indication of ruing non dcep.
The example in section 7 say that if dcmap is rejected dcep may be negotiated.
Maybe this line form section 7 should be in section 6.4?

Roni

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, April 26, 2019 6:16 PM
To: Christer Holmberg; [email-masked]
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP

> So, what is your suggestion? __

It looks to me like the 2nd paragraph of Appendix A is the right place for this:

    ...

But I'm not sure about "The application also specifies...". Is this referring to something specific in the webrtc API? If so, does it permit both? The presence of dcmap in the SDP will indicate the intent to use SDP negotiation, but must this first be enabled in the API?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 28 Apr 2019 11:57:43 +0000

Hi,

> I think that sections 6.3 and 6.4 that discuss offer/answer say that dcmap is the indication of ruing non dcep.

Section 6.3 and 6.4 describe how to use dcmap.

I think it would be useful to e.g., have an Applicability section in the beginning of the document, that explicitly indicates that the procedures in the document apply when a data channel is negotiated using the dcmap attribute, and that DCEP is then not used.

But, what if an offerer wants to negotiate a data channel, before deciding what exactly it is going to be used for, but still wants to indicate usage of SDPNEG. Including an empty dcmap attribute?

>    Maybe this line form section 7 should be in section 6.4?

Normative text should definitely not be in Section 7.

However, if the answerer does not want to use SDPNEG, I think it's up to the offerer to decide whether to continue the session establishment, or fallback to DCEP. 

Regards,

Christer

    -----Original Message-----
    From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
    Sent: Friday, April 26, 2019 6:16 PM
    To: Christer Holmberg; [email-masked]
    Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP

    

        ...

    
    
    	Thanks,
    	Paul

---

From: "Roni Even (A)" <[email-masked]>
Date: Sun, 28 Apr 2019 14:09:33 +0000

Inline
Roni

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Sunday, April 28, 2019 2:58 PM
To: Roni Even (A); Paul Kyzivat; [email-masked]
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP

Hi,

RE: section 5 "This section defines two new SDP media-level attributes that can be
   used together with the SDP Offer/Answer mechanism to negotiate data
   channel-specific and subprotocol-specific parameters without the
   usage of DCEP".  if dcmap is rejected in the answer, the offerer can try dcep ( see my answer bellow)

RE: I do not see what is the use case, it does not help with the decision about whether out of band case is supported or not.

RE: yes make sense to have it in section 6.5

Regards,

Christer

    -----Original Message-----
    From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
    Sent: Friday, April 26, 2019 6:16 PM
    To: Christer Holmberg; [email-masked]
    Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP

    

        ...

    
    
    	Thanks,
    	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 28 Apr 2019 11:54:41 -0400

Christer,

You seem to be suggesting that using dcmap is mutually exclusive with 
using DCEP to negotiate channels. While I guess it would be possible to 
make such a rule I don't see why it is necessary, or a good thing. Why 
not allow them to be used together? (E.g., use SDP to establish the SCTP 
association and negotiate some initial channels, and later use DCEP to 
negotiate some additional channels.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 28 Apr 2019 16:43:48 +0000

Hi,

>negotiate some additional channels.)

I agree they can be used together. dcmap is a media-level attribute, so any rule obviously only apply to a given m- line.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Apr 2019 12:54:03 +0000

Hi,

>negotiate some additional channels.)

You are right - one can use both SDPNEG and DCEP for the same SCEP association (read: same m- line).

But, if I establish the SCTP association - but do not negotiate some initial channels using SDPNEG - the peer won't know that I support SDPNEG, so I assume it will always try to use DCEP.

Having explicit support indicators, that are separate from the actual protocol indicators, is always good in my opinion.

But, perhaps we should have thought about that earlier. Let's make whatever clarifications are needed and ship the document :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Apr 2019 09:34:07 -0400

On 4/29/19 8:54 AM, Christer Holmberg wrote:
> But, if I establish the SCTP association - but do not negotiate some 
> initial channels using SDPNEG - the peer won't know that I support 
> SDPNEG, so I assume it will always try to use DCEP.
> 
> Having explicit support indicators, that are separate from the actual 
> protocol indicators, is always good in my opinion.
> 
> But, perhaps we should have thought about that earlier. Let's make 
> whatever clarifications are needed and ship the document :)

Yes, maybe this should have gotten more thinking up front, but that is 
water over the dam.

ISTM that for a particular use an application will likely be coded to 
negotiate a data channel via DCEP or SDPNEG, but not both. But at the 
same time it might be possible that different usages within the 
application *might* work differently in this regard. (E.g., the 
application might call a library that internally needs a data channel 
and negotiates it via DCEP.)

I don't think it is essential to know a priori which are supported. If 
lack of support is discovered via a failure to negotiate then so be it.

But I am interested to hear what others think.

	Thanks,
	Paul

---

From: "Makaraju, Raju (Nokia - US/Naperville)" <[email-masked]>
Date: Mon, 29 Apr 2019 16:31:51 +0000

>      with dcmap and/or DCEP. I don't think this is said anywhere else.

[Raju] Appendix A.2.2[1] already indicates streams can be managed by both DCEP and non-DCEP, but application has to manage and make sure ids don't overlap for either use.

> But, what if an offerer wants to negotiate a data channel, before deciding what exactly it is going to be used for, but still wants to indicate usage of SDPNEG. >Including an empty dcmap attribute?

[Raju]
ABF syntax[2]  does already allow a=dcmap without any optional parameters or even subprotocol to be empty quoted string.

[1] A.2.2.  Opening a Data Channel

   In the case of DCEP-less negotiation, the endpoint application has
   the option to fully control the stream identifier assignments.
   However these assignments have to coexist with the assignments
   controlled by the data channel stack for the DCEP negotiated data
   channels (if any).  It is the responsibility of the application to
   ensure consistent assignment of stream identifiers.

[2]
dcmap-value     = dcmap-stream-id
                    [ SP dcmap-opt *(";" dcmap-opt) ]
dcmap-opt       = ordering-opt / subprotocol-opt / label-opt 
			....
subprotocol-opt = "subprotocol=" quoted-string 
quoted-string   = DQUOTE *(quoted-char / escaped-char) DQUOTE

-----Original Message-----
From: mmusic <[email-masked]> On Behalf Of Roni Even (A)
Sent: Sunday, April 28, 2019 9:10 AM
To: Christer Holmberg <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP

Inline
Roni

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Sunday, April 28, 2019 2:58 PM
To: Roni Even (A); Paul Kyzivat; [email-masked]
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP

Hi,

Regards,

Christer

    -----Original Message-----
    From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
    Sent: Friday, April 26, 2019 6:16 PM
    To: Christer Holmberg; [email-masked]
    Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP

    

        ...

    
    
    	Thanks,
    	Paul