Subject: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Feb 2014 13:18:29 +0000

Hi,

A few questions on  draft-ejzak-dispatch-webrtc-data-channel-sdpneg:

Q1:

Instead of defining a new SDP webrtc-DataChannel attribute, would it be possible to define the parameters as extension parameters to the SDP sctpmap attribute (yes, I know the ABNF currently does not allow that)?

Example:

a=sctpmap:1000 webrtc-datachannel 1;stream=6;subprotocol="CLUE"

I am not saying this would be good or bad - at this point I just want to understand whether it would work.

Q2:

Would it be possible, for subprotocol values, use the same IANA registry/values as for the WebRTC Data Channel Protocol?

Q3:

It would be good to clarify, if only one data channel is requested (or, even required), that the stream value must be the same in the Offer and Answer.

Q4:

I have issues with the max_retr, max_time and unordered parameters.

First, they seem to specify SENDING capabilities, rather than RECEIVING capabilities.

Second, they seem to describe characteristics associated with the subprotocol, in which case they could be specified in the associated subprotocol specification.

Regards,

Christer

---

From: Richard Ejzak <[email-masked]>
Date: Mon, 24 Feb 2014 08:07:47 -0600

On Mon, Feb 24, 2014 at 7:18 AM, Christer Holmberg <
[email-masked]> wrote:

> *Q1:*
> Instead of defining a new SDP webrtc-DataChannel attribute, would it be
> possible to define the parameters as extension parameters to the SDP
> sctpmap attribute (yes, I know the ABNF currently does not allow that)?
>
>
>
> Example:
>
>
>
> *a=sctpmap:1000 webrtc-datachannel 1;stream=6;subprotocol="CLUE"*
>
>
>

It might work, but you would still need a different mechanism to negotiate
multiple data channels.  Why bother with two different formats when one
will do?

>
>
>
>
> *Q2:*
>
>
>
> Would it be possible, for subprotocol values, use the same IANA
> registry/values as for the WebRTC Data Channel Protocol?
>

This is really more a question for the data channel design itself.  A
decision has been made to use the PPID for framing rather than protocol
identification.  There is some discussion of this in another thread.

>
>
>
>
> *Q3:*
>
>
>
> It would be good to clarify, if only one data channel is requested (or,
> even required), that the stream value must be the same in the Offer and
> Answer.
>

I thought this also came up in an earlier thread and that it is documented
(or should be documented) in the core data channel docs.  My understanding
is that the stream id is always the same in both directions for a
particular data channel.

> *Q4:*
> Second, they seem to describe characteristics associated with the
> subprotocol, in which case they could be specified in the associated
> subprotocol specification.
>

This should be a topic for discussion in London.  As it is currently
written, these parameters are of the "take it or leave it" variety, i.e.,
the answerer either accepts the options listed in the offer or rejects the
data channel outright.  This is true for the in-band control protocol
(please correct me if I am wrong on this), so we adopted the same approach
for the SDP-negotiated case.  Some have suggested that we should allow more
flexibility in negotiation of these parameters when using SDP.  If there is
general agreement that it should be done this way, I see no problem with
defining parameter negotiation rules for SDP in the next version of the
draft.

BR, Richard

>
>
> Regards,
>
>
>
> Christer
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Feb 2014 14:18:46 +0000

Hi,

> It might work, but you would still need a different mechanism to negotiate multiple data channels.  Why bother with two different formats when one will do?

I am sure the syntax could be defined so that you could define multiple channels. Or, you could use multiple sctpmap attributes.

Anyway, that is a syntax question, so we don't need to spend time on it now.
 
> This is really more a question for the data channel design itself.  A decision has been made to use the PPID for framing rather than protocol identification.  There is some discussion of this in another thread.

I am not talking about the PPID - I am talking about the Protocol field in the DATA_CHANNEL_OPEN message, which (afaik) specifies the same thing as the subprotocol parameter in your draft.

> I thought this also came up in an earlier thread and that it is documented (or should be documented) in the core data channel docs.  My understanding is that the stream id is always the same in both directions for a particular data channel.   

Correct. But, there should be an Offer/Answer procedure section in your draft, which shall say that the stream number must be the same. You can then reference to the data channel doc for justification.

> This should be a topic for discussion in London.  As it is currently written, these parameters are of the "take it or leave it" variety, i.e., the answerer either accepts the options listed
> in the offer or rejects the data channel outright.  This is true for the in-band control protocol (please correct me if I am wrong on this), so we adopted the same approach for the 
> SDP-negotiated case.  Some have suggested that we should allow more flexibility in negotiation of these parameters when using SDP.  If there is general agreement that it should be
> done this way, I see no problem with defining parameter negotiation rules for SDP in the next version of the draft.

The difference is that your draft is based on Offer/Answer, which is about indicating receiving capabilities (yes, I know we have broken that rule in the past).

Regards,

Christer

---

From: Richard Ejzak <[email-masked]>
Date: Mon, 24 Feb 2014 08:58:30 -0600

On Mon, Feb 24, 2014 at 8:18 AM, Christer Holmberg <
[email-masked]> wrote:

> I am not talking about the PPID - I am talking about the Protocol field in
> the DATA_CHANNEL_OPEN message, which (afaik) specifies the same thing as
> the subprotocol parameter in your draft.
>

This issue did come up in another thread, and the answer is yes.  It should
probably be documented in the core data channel specs and just referenced
here.

> > I thought this also came up in an earlier thread and that it is
> documented (or should be documented) in the core data channel docs.  My
> understanding is that the stream id is always the same in both directions
> for a particular data channel.
>
> Correct. But, there should be an Offer/Answer procedure section in your
> draft, which shall say that the stream number must be the same. You can
> then reference to the data channel doc for justification.
>

Since there is no disagreement over how it should work, we can clarify as
necessary in a subsequent draft.

> the answerer either accepts the options listed
> > in the offer or rejects the data channel outright.  This is true for the
> in-band control protocol (please correct me if I am wrong on this), so we
> adopted the same approach for the
> > SDP-negotiated case.  Some have suggested that we should allow more
> general agreement that it should be
> > done this way, I see no problem with defining parameter negotiation
> rules for SDP in the next version of the draft.
>
> The difference is that your draft is based on Offer/Answer, which is about
> indicating receiving capabilities (yes, I know we have broken that rule in
> the past).
>

There are many examples of attributes that use different negotiation models
than this.  The only requirement is that the semantics of the negotiation
be defined in the document defining the attribute.

BR, Richard

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Feb 2014 15:21:47 +0000

Hi,

> This issue did come up in another thread, and the answer is yes.  It should probably be documented in the core data channel specs and just referenced here.

Good. Sorry if I missed the previous discussion on the topic.

> Since there is no disagreement over how it should work, we can clarify as necessary in a subsequent draft.
 
Good.

> There are many examples of attributes that use different negotiation models than this.  The only requirement is that the semantics of the negotiation be defined in the document defining the attribute.

I still don't think the information belong to SDP - they define protocol characteristics. The protocol specification should define re-transmission timers etc.

Anyway, we can argue about it later. At this moment I think the focus should be on whether to move forward with the mechanism to begin with, and the main feature of the mechanism - which is about negotiating usage of channels :)

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 24 Feb 2014 19:16:03 +0000

> >> The difference is that your draft is based on Offer/Answer, which is
> about indicating receiving capabilities (yes, I know we have broken that
> rule in the past).
> >
> > There are many examples of attributes that use different negotiation
> models than this.  The only requirement is that the semantics of the
> negotiation be defined in the document defining the attribute.
> 
> I still don't think the information belong to SDP - they define protocol
> characteristics. The protocol specification should define re-transmission
> timers etc.
> 
> Anyway, we can argue about it later. At this moment I think the focus should
> be on whether to move forward with the mechanism to begin with, and the main
> feature of the mechanism - which is about negotiating usage of channels :)

[Raju] Sorry to continue this discussion here instead of London, which I won't be attending.

I also believe that we do need these max_retr, max_time and unordered in the SDP.
These map to the data channel init parameters specified in http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel . In case of DCP these are used by "5.1.  DATA_CHANNEL_OPEN Message" of http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-03 
Combination of these parameters will determine the type of 
DATA_CHANNEL_OPEN open that will be sent.

For non-DCP external negotiation use case, these values have to be communicated to the peer. Since we want to closely follow DCP, which allows only one set of these values to be negotiated for both the directions, SDP offer/answer will do that same. Receiving end should accept these values, give it to data channel stack and echo them back to the offerer.
This way in external negotiation case as well, similar to DCP, both the peers will have same set of data channel attributes (reliable or partial reliable, ordered or unordered, timed or # of retransmission).

We will make the following changes, if agreed by others, in the next draft:
1. Add a new "reliable/partial reliable" SDP attribute, which is missing now.
   This is needed to map to the exact data channel type using external negotiation.
2. Map these SDP attributes to relevant DCP and PeerConnection sections.
   Need to make updates to SDP whenever DCP and/or PeerConnection is changed.
3. Specify either max_retr (retransmit data channel) or max_time (timed data channel)   
   present, but NOT both.

Best Regards
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Feb 2014 20:15:35 +0000

Hi,

I don't see why an SDP based mechanism by default must provide the same capabilities as the DCP. If you need to communicate everything that DCP provides, then you use DCP. Otherwise you may use SDP (or whatever other external mechanism).

OR, you can define a mechanism to communicate low-level information (re-transmission timer values etc) within the protocol that you are going to transport on top of the data channel.

Anyway, can you give me an example of a case where you want to use SDP, and where you need to negotiate the re-transmission values etc?

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Makaraju, Maridi Raju (Raju) [mailto:[email-masked]] 
Lähetetty: 24. helmikuuta 2014 21:16
Vastaanottaja: Christer Holmberg; Richard Ejzak
Kopio: [email-masked]
Aihe: RE: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00

> >>>> First, they seem to specify SENDING capabilities, rather than 
> >>>> RECEIVING
> capabilities.
> >>>>
> written, these parameters are of the "take it or leave it" variety, 
> i.e., the answerer either accepts the options listed
> in-band control protocol (please correct me if I am wrong on this), so 
> we adopted the same approach for the
> flexibility in negotiation of these parameters when using SDP.  If 
> there is general agreement that it should be
> about indicating receiving capabilities (yes, I know we have broken 
> that rule in the past).
> >
> I still don't think the information belong to SDP - they define 
> protocol characteristics. The protocol specification should define 
> re-transmission timers etc.
> 
> Anyway, we can argue about it later. At this moment I think the focus 
> should be on whether to move forward with the mechanism to begin with, 
> and the main feature of the mechanism - which is about negotiating 
> usage of channels :)

I also believe that we do need these max_retr, max_time and unordered in the SDP.
These map to the data channel init parameters specified in http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel . In case of DCP these are used by "5.1.  DATA_CHANNEL_OPEN Message" of http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-03
Combination of these parameters will determine the type of DATA_CHANNEL_OPEN open that will be sent.

Best Regards
Raju

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 24 Feb 2014 20:38:19 +0000

Hi,

> Hi,
> 
> I don't see why an SDP based mechanism by default must provide the same
[Raju] Because, whether browser based or not each side will use a data channel stack. Independent of DCP used or not, the data channel stack has to have these attributes to do various order/unordered, reliab/unreliable, retransmit/timed modes.
With external negotiation, the same SDP will be used to negotiate these values (similar to what DCP data channel open does).
This way the only difference between external based negotiation vs. DCP is "DCP" itself, neither more nor less; rest of the attributes of data channel are exactly identical on both ends. This is what we want to achieve with external negotiation.

> capabilities as the DCP. If you need to communicate everything that DCP
> provides, then you use DCP. Otherwise you may use SDP (or whatever other
> external mechanism).

[Raju] Using DCP means the intermediate elements have no ("easy") visibility into what channels are being negotiated; such visibility is needed for various reasons like to have interworking functionality with other protocols, such as MSRP; or regulatory needs; or value added services with billing implications etc.

> 
> OR, you can define a mechanism to communicate low-level information (re-
> transmission timer values etc) within the protocol that you are going to
> transport on top of the data channel.
[Raju] On top of data channel standard IANA registered protocols, such as MSRP, will typically be used; so modifying such protocols for this use case is not an option.

> 
> Anyway, can you give me an example of a case where you want to use SDP, and
> where you need to negotiate the re-transmission values etc?

[Raju] A simple example would be 2 browsers talking thru an intermedia proxy, which wants to know what protocols are being negitiated and used as part of the session.
1. Calling client creates data channel (using http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel) with desired attributes and sets negotiated=true. So, calling browser saves the attributes for the data channel but won't use DCP.
2. These attributes are sent via SDP to peer client (via proxy).
3. Peer client sets these same attributes while creating data channel and sets negotiated=true but won't do DCP.
4. Peer client echo the same attributes back in SDP answer.

Now, data channel stacks on both ends will use same attributes, similar to DCP use case, with the only difference being DCP is not used here.

Best Regards
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Feb 2014 09:08:47 +0000

Hi Raju,

>> Anyway, can you give me an example of a case where you want to use 
>> SDP, and where you need to negotiate the re-transmission values etc?
>
> [Raju] A simple example would be 2 browsers talking thru an intermedia proxy, which wants to know what protocols are
> being negitiated and used as part of the session.

Sure. I don't question the use-case/need for using SDP to negotiate channel usages.

> 1. Calling client creates data channel (using http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel) with desired
> attributes and sets negotiated=true. So, calling browser saves the attributes for the data channel but won't use DCP.

My question was regarding the re-transmission values etc. 

Why do the peers need to negotiate those? Why would an intermediary need to know about those? Why not simply define those in the protocol description, and each endpoint supporting the protocol will then know what values to use?

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 25 Feb 2014 15:52:38 +0000

Hi Crister,

Thanks.
Please see my comments inline.

> > [Raju] A simple example would be 2 browsers talking thru an intermedia
> proxy, which wants to know what protocols are
> > 1. Calling client creates data channel (using
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel)
> with desired
> > attributes and sets negotiated=true. So, calling browser saves the
> attributes for the data channel but won't use DCP.
> > Now, data channel stacks on both ends will use same attributes, similar to
> DCP use case, with the only difference being DCP is not used here.
> 
> Why do the peers need to negotiate those? Why would an intermediary need to
> know about those? Why not simply define those in the protocol description,
> and each endpoint supporting the protocol will then know what values to use?

[Raju] Peers need to negotiate those so that both ends of the data channel can use same timers (similar to DCP).
Intermediate entities pass these values to the peer in some cases and need to know these in other cases so that they can be passed down to data channel entity which is terminating the data channel (and interworking to other transports like TCP).
IMHO, these attributes are specific to data channel thus they should remain associated to data channel (DCP or external negotiation; making them part of other protocols is not only wrong but also causes unenecessary modifications adding overhead to these protocols.

Best Regards
Raju

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Feb 2014 11:56:52 -0500

Christer - comment at end

> Why do the peers need to negotiate those? Why would an intermediary need to know about those? Why not simply define those in the protocol description, and each endpoint supporting the protocol will…

IIUC, the webrtc people are "humoring* us by making provision for 
registered subprotocol names, and using SDP to negotiate channels. I 
suspect that for the most part they have no intention of using those. 
(The subprotocol name is *optional*.)

So these parameters are needed to properly initialize a channel when the 
subprotocol is not specified.

Also, we still have an open question about what attributes must be 
present in a subprotocol specification. It is at least possible that 
some subprotocols may work with a variety of settings of these attributes.

This draft should probably say more about this. It could say that:

* the SDP MUST be consistent with the attributes specified in the 
subprotocol definition, OR

* the SDP MUST NOT specify attributes specified in the subprotocol 
definition, OR

* attributes specified in the SDP override those specified in the 
subprotocol definition.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Feb 2014 17:51:35 +0000

Hi Paul,

>> Why do the peers need to negotiate those? Why would an intermediary need to know about 
>> those? Why not simply define those in the protocol description, and each endpoint supporting the >> protocol will then know what values to use?
>
> IIUC, the webrtc people are "humoring* us by making provision for registered subprotocol names, > and using SDP to negotiate channels. I suspect that for the most part they have no intention of 
> using those. 
> So these parameters are needed to properly initialize a channel when the subprotocol is not 
> specified.

Why would someone NOT specify the subprotocol?

Especially considering Richard's draft, I thought the whole idea was to be able to negotiate the subprotocol using SDP.

> Also, we still have an open question about what attributes must be present in a subprotocol 
> specification. It is at least possible that some subprotocols may work with a variety of settings of 
> these attributes.

Well, in that case the subprotocol specification should define the additional SDP attributes needed.

> * the SDP MUST be consistent with the attributes specified in the subprotocol definition, OR
>
> * the SDP MUST NOT specify attributes specified in the subprotocol definition, OR
>
> * attributes specified in the SDP override those specified in the subprotocol definition.

If people see a need for these attributes, fine. But, I still have not seen an example where it would be needed (e.g. the UDP RFC does not specify the timers for SIP - RFC 3261 does :)

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 25 Feb 2014 17:54:53 +0000

Hi Paul,

Please see comments inline.

> >> Now, data channel stacks on both ends will use same attributes, similar
> to DCP use case, with the only difference being DCP is not used here.
> >
> > Why do the peers need to negotiate those? Why would an intermediary need
> to know about those? Why not simply define those in the protocol
> description, and each endpoint supporting the protocol will then know what
> values to use?
> 

[Raju] If I understand correctly, these parameters simply define the 
data channel transport properties. Yes, they may have some correletion with 
subprotocol, but that's not a one-to-one mapping.
For example, a given subprotocol could run on a reliable or 
unreliable transport; depending on app needs it may use unreliable 
transport and deal with reliablity at subprotocol stack (or ignore it).

> some subprotocols may work with a variety of settings of these attributes.

[Raju] Right, this fits into my explanation above.

> * attributes specified in the SDP override those specified in the

[Raju] Good point. I like item 1 above; sure we can add it to this 
draft. Then individual subprotocol drafts 
(e.g. draft-ejzak-dispatch-msrp-data-channel-00) could get into the
details of what that consistency is.

Best Regards
Raju

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 25 Feb 2014 18:26:26 +0000

Hi Christer,

Please find my comments inline.

> 
> Especially considering Richard's draft, I thought the whole idea was to be
> able to negotiate the subprotocol using SDP.
> 
> If people see a need for these attributes, fine. But, I still have not seen
> an example where it would be needed (e.g. the UDP RFC does not specify the
> timers for SIP - RFC 3261 does :)

[Raju] Aren't the attributes we are talking here are data channel properties?
DCP explains the following type of data channel as:
      DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02):  The channel provides
         a partial reliable in-order bi-directional Communication
         channel.  User messages might not be transmitted or
         retransmitted after a specified life-time given in milli-
         seconds in the Reliability Parameter.  This life-time starts
         when providing the user message to the Javascript engine.

Fo example,'maxRetransmitTime' value specified by createDataChannel API (SDP's maxtime) here is realized by data channel stack, NOT by the application. The timer value given by the client may be a generic value rather than specific to a subprotocol. To draw comparision to TCP, Linux allows TCP_USER_TIMEOUT sockopt which allows application to specify max timer value for any unacknowledged data. 'maxRetransmitTime' is similar.
The SIP analogy mentioned above is for subprotocol level timers but not for transport level retransmissions timers. A subprotocol could have it's own retransmission timer for lack of response for a req. Lack of subprotocol response could still happen, if the peer application drops the request, even when data channel successfully sent the request. 

So, I think timers (parameters) at both data channel stack and subprotocol have clear semantics and mostly independent of each other.

Best Regards
Raju

---

From: Mary Barnes <[email-masked]>
Date: Tue, 25 Feb 2014 13:26:57 -0600

Why are we having this discussion on the RTCWEB mailing list rather than
the MMUSIC mailing list?   This document was dispatched to MMUSIC at
IETF-88: http://trac.tools.ietf.org/wg/dispatch/trac/wiki
And, the nifty datatracker tool tells us that this (expired) document has
been replaced by an individual draft that has been submitted to the MMUSIC
WG:
http://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-channel-sdpneg/

It seems there's a lot of interest in this document, so if folks want it to
be considered for adoption in the MMUSIC WG, PLEASE move the discussion to
the MMUSIC WG list.  The chairs need the discussion there in order to get a
sense of WG interest, so you might want to include a link to this thread of
discussion in a NEW email to the MMUSIC WG mailing list and point this
discussion to that thread. But, please do not crosspost.

Thanks,
Mary.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Feb 2014 17:22:48 -0500

> Why would someone NOT specify the subprotocol?

Because there is no defined subprotocol for what they are doing?

In the common webrtc use case with two browsers talking to the same web 
service, and the web service feeding the needed javascript to the 
browsers, they just "know" the protocol they are using. So they may just 
"make it up", and have nothing registered.

It is when they need to interoperate with something else that it becomes 
important to name and register the protocol.

> Especially considering Richard's draft, I thought the whole idea was to be able to negotiate the subprotocol using SDP.

That's for us, not them. :-)

They will be using DCEP.

> If people see a need for these attributes, fine. But, I still have not seen an example where it would be needed (e.g. the UDP RFC does not specify the timers for SIP - RFC 3261 does :)

I was talking in general. The answers may be different for each attribute.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Feb 2014 17:26:39 -0500

> transport and deal with reliablity at subprotocol stack (or ignore it).

In some cases. But in general it is easy and common to define a protocol 
that needs a reliable transport, and it won't work without one.

What if every application in the world that uses TCP had the option to 
specify if it was reliable or not? How many would screw it up?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Feb 2014 22:29:22 +0000

Hi,

>>> So these parameters are needed to properly initialize a channel when 
>>> the subprotocol is not specified.
>>
> In the common webrtc use case with two browsers talking to the same web service, and the web 
> service feeding the needed javascript to the browsers, they just "know" the protocol they are using. > So they may just "make it up", and have nothing registered.
>
> It is when they need to interoperate with something else that it becomes important to name and 
> register the protocol.
>

Sure, but my question is about the usage of the attributes in SDP (Richard's draft).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Feb 2014 17:41:27 -0500

> Sure, but my question is about the usage of the attributes in SDP (Richard's draft).

Are you then suggesting that the subprotocol MUST be supplied in the SDP?

I think we need some careful consideration of what rules are common to 
all data channels, and which ones can be different when using SDP rather 
than DCEP. That should consider how something first built using DCEP can 
be migrated to using SDP when it is discovered that it needs to 
interoperate with a sip server.

Unclear if that discussion should take place on rtcweb or mmusic.

	Thanks,
	Paul

---

From: Randell Jesup <[email-masked]>
Date: Tue, 25 Feb 2014 17:41:04 -0500

> Anyway, we can argue about it later. At this moment I think the focus should be on whether to move forward with the mechanism to begin with, and the main feature of the mechanism - which is about n…

This (whether to move forward) is my concern (in addition to Mary's 
about this being the wrong group - MMUSIC is where the SDP should be and 
has been).

The apparent justification for this document is "This document defines 
SDP-based out-of-band negotiation procedures to establish WebRTC data 
channels for transport of well-defined sub- protocols." This seems a 
pretty sparse justification.

We very purposely avoided using SDP for channel setup (after MUCH 
discussion at Boston and elsewhere).  That isn't to say that for 
non-webrtc usage, one could define an SDP used to externally-negotiate 
the settings for DataChannels, which this appears to be.  But I think 
there should a clearer statement as to "why" we should invest the time 
to standardize this now, not just that we "can".  For example, if CLUE 
really wants to use this instead of in-band opens, then maybe there's a 
reason to do so - but don't expect webrtc endpoints to implement this.  
And if so, it should be done in CLUE by request to MMUSIC.

At this point I don't see need to move forward with this, and certainly 
not here.  And I certainly don't want this to delay finalizing the stuff 
needed in MMUSIC for WebRTC use of DataChannels

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Feb 2014 22:55:16 +0000

Hi Randell,

I am not sure whether an WebRTC endpoint (e.g. a browser) would have to implement this. The JS Application can insert the information into the SDP before sending it out on the wire (in cases where SDP is used on the wire).

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Randell Jesup
Sent: 26 February 2014 00:41
To: [email-masked]
Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00

> and the main feature of the mechanism - which is about negotiating 

This (whether to move forward) is my concern (in addition to Mary's about this being the wrong group - MMUSIC is where the SDP should be and has been).

The apparent justification for this document is "This document defines SDP-based out-of-band negotiation procedures to establish WebRTC data channels for transport of well-defined sub- protocols." This seems a pretty sparse justification.

We very purposely avoided using SDP for channel setup (after MUCH discussion at Boston and elsewhere).  That isn't to say that for non-webrtc usage, one could define an SDP used to externally-negotiate the settings for DataChannels, which this appears to be.  But I think there should a clearer statement as to "why" we should invest the time to standardize this now, not just that we "can".  For example, if CLUE really wants to use this instead of in-band opens, then maybe there's a reason to do so - but don't expect webrtc endpoints to implement this.  
And if so, it should be done in CLUE by request to MMUSIC.

At this point I don't see need to move forward with this, and certainly not here.  And I certainly don't want this to delay finalizing the stuff needed in MMUSIC for WebRTC use of DataChannels

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Feb 2014 22:59:32 +0000

Anyhow, I agree we should move this discussion elsewhere.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Christer Holmberg <[email-masked]> wrote:

Hi Randell,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Feb 2014 14:38:25 -0500

Randell,

I agree that most of this discussion belongs elsewhere.
But there are a few bits that probably do belong here.

CLUE needs *something* that provides an e2e reliable channel. It could 
be a lot of things, e.g. TCP or TLS. We decided to go with the 
SCTP-based data channel that RTCWEB is defining so that we had the 
potential for a Webrtc endpoint to participate in CLUE without a gateway 
on the clue channel.

That means we will also be using the same stack between non-webrtc clue 
endpoints that are using SIP for signaling.

We are still undecided on whether to use DCEP or SDP O/A to negotiate 
the channel we use. If we use DCEP it will be straightforward for a 
webrtc endpoint. But that is a little unnatural for the sip endpoints. 
For them, the SDP O/A approach would be more natural.

It doesn't matter much if the *only* channel being used is the clue 
channel. It will start to matter if there is a desire to use other 
channels for features that can coexist with clue. E.g. BFCP. (But now we 
see a proposal to put BFCP over websocket, so maybe it won't ever be an 
issue for us.)

The important thing is that if clue decides to use SDP O/A for this, 
(the ejzak draft) then we must be confident that it will be feasible for 
a webrtc endpoint, via javascript, to participate in this negotiation 
and use it to set up the clue data channel. That is the part that 
belongs in rtcweb.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Feb 2014 20:02:40 +0000

Hi,

Let's also keep in mind that there has been suggestions to negotiate the channels using SDP, but in addition also use DCP (I assume that is what your DCEP abbreviation stands for :) to explicitly open the negotiated channels.

But, again, as long as JavaScript can access the information (stream id value etc), in order to add it to the SDP sent on the wire, and as long as the usage of DCP is optional (it was earlier indicated that it IS optional) I don't think there should be any impacts on WebRTC.

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 26 February 2014 21:38
To: [email-masked]
Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00

Randell,

CLUE needs *something* that provides an e2e reliable channel. It could be a lot of things, e.g. TCP or TLS. We decided to go with the SCTP-based data channel that RTCWEB is defining so that we had the potential for a Webrtc endpoint to participate in CLUE without a gateway on the clue channel.

That means we will also be using the same stack between non-webrtc clue endpoints that are using SIP for signaling.

We are still undecided on whether to use DCEP or SDP O/A to negotiate the channel we use. If we use DCEP it will be straightforward for a webrtc endpoint. But that is a little unnatural for the sip endpoints. 
For them, the SDP O/A approach would be more natural.

It doesn't matter much if the *only* channel being used is the clue channel. It will start to matter if there is a desire to use other channels for features that can coexist with clue. E.g. BFCP. (But now we see a proposal to put BFCP over websocket, so maybe it won't ever be an issue for us.)

The important thing is that if clue decides to use SDP O/A for this, (the ejzak draft) then we must be confident that it will be feasible for a webrtc endpoint, via javascript, to participate in this negotiation and use it to set up the clue data channel. That is the part that belongs in rtcweb.

	Thanks,
	Paul

On 2/25/14 5:41 PM, Randell Jesup wrote:
>> should be on whether to move forward with the mechanism to begin 
>> with, and the main feature of the mechanism - which is about 
>> negotiating usage of channels :)
>
> about this being the wrong group - MMUSIC is where the SDP should be 
> and has been).
>
> really wants to use this instead of in-band opens, then maybe there's 
> a reason to do so - but don't expect webrtc endpoints to implement this.
> At this point I don't see need to move forward with this, and 
> certainly not here.  And I certainly don't want this to delay 
> finalizing the stuff needed in MMUSIC for WebRTC use of DataChannels
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Feb 2014 20:12:13 -0500

> Let's also keep in mind that there has been suggestions to negotiate the channels using SDP, but in addition also use DCP (I assume that is what your DCEP abbreviation stands for :) to explicitly o…

DCEP is the *new* acronym, from the most recent version.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 26 Feb 2014 18:59:26 +0000

+ mmusic
- rtcweb (in bcc)

Hi Paul,
I wanted to close this email loop. Please see my inline comments.

> specify if it was reliable or not? How many would screw it up?
[Raju] 
Application subprotocol users need to know the transport needs for the protocol and select a single transport if multiple options exist. This is similar to how users select TCP or UDP when implementing any Layer5 protocol (e.g. SIP) on top of Layer 4.

If APIs abstract this subprotocol then the transport selection can be hidden under the API (if only one choice exists) and API user won't have to specify a transport. 

We really appreciate your time in providing valuable comments on these drafts!

Best Regards!
Raju