Subject: [clue] RTCWEB data channel for CLUE?

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Jan 2014 13:55:52 +0000

Hi,

As those of you who attended the virtual meeting yesterday know, I presented a suggestion for using the rtcweb data channel for transporting the CLUE protocol messages.

We recognized that there ARE a few things that need to be sorted out and clarified (you may have seen the e-mails I've sent to the rtcweb- and mmusic lists), but in general I think we should decide (or, at least making a working assumption) whether we'll use the rtcweb mechanism.

Again, there are details that need to be sorted out, and we can always reverse any decision we make. But, I do NOT want to wait until London for making a decision in the first place. I want us to sort out details and open issues in London.

Personally I think that having interoperability with rtcweb is extremely valuable - unless, of course, it causes a great burden for CLUE, or unless the mechanism is technically unfeasible for CLUE. So far I have not heard any indication of either, and we also saw a demo showing that it is possible to use the mechanism.

I also don't think that, due to the dependency on rtcweb that such decision would create, there is a big risk of CLUE being delayed. In my opinion, the data channel mechanism is probably the most stable thing of the things rtcweb is currently working on.

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Wed, 29 Jan 2014 10:28:22 +1100

Hello Christer,

Are you asking that rtcweb data channel is the ONLY method for 
establishing a CLUE channel? or that it is one of the methods?

If CLUE is being used in the rtcweb context then it would appear to make 
sense to use the web data channel. However if rtcweb isn't being used 
then why couldn't we use draft-ietf-mmusic-sctp-sdp to set up the CLUE 
channels?

I don't think there's anything in the CLUE protocol/data model that 
would prevent either being used.

Regards, Christian

On 29/01/2014 12:55 AM, Christer Holmberg wrote:
>
> Hi,
>
> As those of you who attended the virtual meeting yesterday know, I 
> presented a suggestion for using the rtcweb data channel for 
> transporting the CLUE protocol messages.
>
> We recognized that there ARE a few things that need to be sorted out 
> and clarified (you may have seen the e-mails I’ve sent to the rtcweb- 
> and mmusic lists), but in general I think we should decide (or, at 
> least making a working assumption) whether we’ll use the rtcweb mechanism.
>
> Again, there are details that need to be sorted out, and we can always 
> reverse any decision we make. But, I do NOT want to wait until London 
> for making a decision in the first place. I want us to sort out 
> details and open issues in London.
>
> Personally I think that having interoperability with rtcweb is 
> extremely valuable – unless, of course, it causes a great burden for 
> CLUE, or unless the mechanism is technically unfeasible for CLUE. So 
> far I have not heard any indication of either, and we also saw a demo 
> showing that it is possible to use the mechanism.
>
> I also don’t think that, due to the dependency on rtcweb that such 
> decision would create, there is a big risk of CLUE being delayed. In 
> my opinion, the data channel mechanism is probably the most stable 
> thing of the things rtcweb is currently working on.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Jan 2014 06:45:31 +0000

Hi Christian,

Maybe I misunderstood what you said, but the idea is that we would always use draft-ietf-mmusic-sctp-sdp to negotiate and establish the DTLS/SCTP channel, and use the rtcweb data channel mechanism.

The rtcweb data channel mechanism then specifies the SCTP details, and the rtcweb data channel protocol (still TBD whether it's mandated) is used to open the channel, and indicate that it will be used for CLUE.

Regards,

Christer

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 29. tammikuuta 2014 1:28
To: [email-masked]
Subject: Re: [clue] RTCWEB data channel for CLUE?

Hello Christer,

Are you asking that rtcweb data channel is the ONLY method for establishing a CLUE channel? or that it is one of the methods?

If CLUE is being used in the rtcweb context then it would appear to make sense to use the web data channel. However if rtcweb isn't being used then why couldn't we use draft-ietf-mmusic-sctp-sdp to set up the CLUE channels?

I don't think there's anything in the CLUE protocol/data model that would prevent either being used.

Regards, Christian

On 29/01/2014 12:55 AM, Christer Holmberg wrote:
> and clarified (you may have seen the e-mails I've sent to the rtcweb- 
> least making a working assumption) whether we'll use the rtcweb mechanism.
>
> extremely valuable - unless, of course, it causes a great burden for 
> I also don't think that, due to the dependency on rtcweb that such

---

From: Christian Groves <[email-masked]>
Date: Wed, 29 Jan 2014 19:20:31 +1100

Hello Christer,

I guess CLUE has made the working assumption to use DTLS/SCTP transport. 
So I assume this means the use of ietf-mmusic-sctp-sdp.

Could we use this for CLUE without using the rtcweb data channel mechanism?

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Jan 2014 10:39:58 +0000

Hi Christian,

>I guess CLUE has made the working assumption to use DTLS/SCTP transport. 

Well, at least I haven't seen any other suggestions :)

>Could we use this for CLUE without using the rtcweb data channel mechanism?

If we want to have interoperability with rtcweb, we need to use the SCTP properties defined in the rtcweb data channel draft. I have not heard, or identified myself, any reason why that would be a problem for CLUE.

Now, as was clarified on the rtcweb list today, the usage of the rtcweb data channel PROTOCOL (DCP) is OPTIONAL, so we'd need to decide what to do for CLUE.

Simon, do you use the DCP in your demo?

Regards,

Christer

On 29/01/2014 5:45 PM, Christer Holmberg wrote:
>> Again, there are details that need to be sorted out, and we can 
>> always reverse any decision we make. But, I do NOT want to wait until 
>> London for making a decision in the first place. I want us to sort 
>> out details and open issues in London.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Jan 2014 11:01:47 -0500

> The rtcweb data channel mechanism then specifies the SCTP details, and the rtcweb data channel protocol (still TBD whether it's mandated) is used to open the channel, and indicate that it will be u…

What I have been thinking is that we would use 
draft-ietf-mmusic-sctp-sdp and 
draft-ejzak-dispatch-webrtc-data-channel-sdpneg to negotiate the data 
channel, thus avoiding the need to rely upon the rtcweb data channel 
protocol.

I guess either mechanism will work. Which is preferable depends on what 
you think will happen in the future for use of other data channel in a 
sip O/A environment.

For instance, if we wanted to also negotiate a hypothetical BFCP over 
data channel usage, either with or without clue.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Wed, 29 Jan 2014 10:03:25 -0600

> Well, at least I haven't seen any other suggestions :)

[MB] This was taken as a decision by the WG for which we had consensus. So,
we will not debate that decision unless someone else submits a more
complete alternative to the WG. [/MB]

> If we want to have interoperability with rtcweb, we need to use the SCTP
> properties defined in the rtcweb data channel draft. I have not heard, or
> identified myself, any reason why that would be a problem for CLUE.
>

[MB] I think the decision to be made by CLUE needs to more importantly
consider whether that approach works for CLUE without RTCWEB.  We discussed
on the call that the RTCWEB WG document (i.e.,
draft-ietf-rtcweb-data-channel/) could be viewed as providing a more
generic mechanism that can be used for applications beyond RTCWEB.

That all said, as an individual, I don't see it to be a tremendous amount
of work to write a  clue-data-channel document that uses identical
mechanisms but has content specific to CLUE.  For example, the generic
aspects in the RTCWEB seem to be primarily limited to section 5 (just over
3 pages of text).  Section 4 has some generic aspects, but also some of it
is RTCWEB specific. And, section 3 is totally specific to RTCWEB.  And, we
need to decide how much of section 6 applies to CLUE.So, personally, I
think CLUE could just write their own document (and perhaps mention that
procedures in section blah are identical to those for RTCWEB OR write a
general document that both CLUE and RTCWEB can reference (although the doc
would have more boiler plate than content.  Or perhaps, section 5 could be
folded into the tsvwg document (although I haven't looked at that in detail
to see if it would work). [/MB]

>
> Now, as was clarified on the rtcweb list today, the usage of the rtcweb
> data channel PROTOCOL (DCP) is OPTIONAL, so we'd need to decide what to do
> for CLUE.
>
> > Maybe I misunderstood what you said, but the idea is that we would
> always use draft-ietf-mmusic-sctp-sdp to negotiate and establish the
> DTLS/SCTP channel, and use the rtcweb data channel mechanism.
> >
> > The rtcweb data channel mechanism then specifies the SCTP details, and
> the rtcweb data channel protocol (still TBD whether it's mandated) is used
> to open the channel, and indicate that it will be used for CLUE.
> >
> > Regards,
> >
> > Christer
> >
> sense to use the web data channel. However if rtcweb isn't being used then
> why couldn't we use draft-ietf-mmusic-sctp-sdp to set up the CLUE channels?
> >

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 29 Jan 2014 17:18:50 +0100

Hi Christer,

> Simon, do you use the DCP in your demo?

In my demo I just make use of the 'plain' WebRTC API. Basically:

- the channel initiator does this (Note: pc is the available PeerConnection object):

sendChannel = pc.createDataChannel("sendDataChannel" , {reliable: true});

This results in the following SDP lines (note that "video" and "data channel" data are bundled together):

m=application 1 RTP/SAVPF 101
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:7Do/ydOMrH5lwzBn
a=ice-pwd:b3D+HG9L+SzimBRJcWUqZgti
a=ice-options:google-ice
a=fingerprint:sha-256 DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A:D5:3A:7D:6C:A1:00:6D
a=setup:actpass
a=mid:data
a=sendrecv
b=AS:30
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:1CFp/gR+88d3ig0EcgluA0yGumtiKI8gxOH2f/ug
a=rtpmap:101 google-data/90000
a=ssrc:1049470780 cname:l6fp7zYgy3DkXQDN
a=ssrc:1049470780 msid:sendDataChannel sendDataChannel
a=ssrc:1049470780 mslabel:sendDataChannel
a=ssrc:1049470780 label:sendDataChannel

- the channel receiver in turn, does the following:

pc.ondatachannel = gotReceiveChannel;

function gotReceiveChannel(event) {
	trace('Receive Channel Callback');
	receiveChannel = event.channel;
	receiveChannel.onmessage = handleMessage;
	receiveChannel.onopen = handleReceiveChannelStateChange;
	receiveChannel.onclose = handleReceiveChannelStateChange;
}

The following is an excerpt of the provided SDP answer:
m=application 1 RTP/SAVPF 101
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:d0/jsCoioZ5wIqQ1
a=ice-pwd:pGoZXkLiO6HN5JZYsy3cSAhH
a=fingerprint:sha-256 DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A:D5:3A:7D:6C:A1:00:6D
a=setup:active
a=mid:data
a=sendrecv
b=AS:30
a=rtcp-mux
a=rtpmap:101 google-data/90000
a=ssrc:1971010094 cname:icWWLWa/VsrZGHr3
a=ssrc:1971010094 msid:sendDataChannel sendDataChannel
a=ssrc:1971010094 mslabel:sendDataChannel
a=ssrc:1971010094 label:sendDataChannel

Hope this helps,
Simon

>>> thing of the things rtcweb is currently working on.

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Jan 2014 11:29:34 -0500

> channel" data are bundled together):

I don't see any bundle, or any video, just one m-line that makes no 
sense to me

> m=application 1 RTP/SAVPF 101

What is the above? Its not sctp, or anything I understand as valid.

	Thanks,
	Paul

>>> The rtcweb data channel mechanism then specifies the SCTP details,
>>> and the rtcweb data channel protocol (still TBD whether it's
>>> mandated) is used to open the channel, and indicate that it will be
>>> used for CLUE.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> To: [email-masked] <mailto:[email-masked]>
>>> If CLUE is being used in the rtcweb context then it would appear to
>>> make sense to use the web data channel. However if rtcweb isn't being
>>> used then why couldn't we use draft-ietf-mmusic-sctp-sdp to set up
>>> the CLUE channels?
>>>
>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>
>

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 29 Jan 2014 17:35:15 +0100

> I don't see any bundle, or any video, just one m-line that makes no sense to me

I copy-pasted just the relevant part, associated with the data channel m-line...

If you want a complete dump, here it is:

type: offer, sdp: v=0
o=- 5103351260166074998 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video data
a=msid-semantic: WMS HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz
m=video 1 RTP/SAVPF 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:Hokk+0T0UPC3dvNu
a=ice-pwd:T2IvRmr2GXiN1vQ3T5T1mp1/
a=ice-options:google-ice
a=fingerprint:sha-256 DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A:D5:3A:7D:6C:A1:00:6D
a=setup:actpass
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:okRaCzerNHngBK7koanqye5QR+zP6pzE81yj7uFA
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3100544884 cname:S+mwxWG9Y7xCa1i2
a=ssrc:3100544884 msid:HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz a35c161e-74ca-4ada-8b79-909e708b583b
a=ssrc:3100544884 mslabel:HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz
a=ssrc:3100544884 label:a35c161e-74ca-4ada-8b79-909e708b583b
m=application 1 RTP/SAVPF 101
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:Hokk+0T0UPC3dvNu
a=ice-pwd:T2IvRmr2GXiN1vQ3T5T1mp1/
a=ice-options:google-ice
a=fingerprint:sha-256 DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A:D5:3A:7D:6C:A1:00:6D
a=setup:actpass
a=mid:data
a=sendrecv
b=AS:30
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:okRaCzerNHngBK7koanqye5QR+zP6pzE81yj7uFA
a=rtpmap:101 google-data/90000
a=ssrc:1569838440 cname:gG2TR57LvWPMBVd3
a=ssrc:1569838440 msid:sendDataChannel sendDataChannel
a=ssrc:1569838440 mslabel:sendDataChannel
a=ssrc:1569838440 label:sendDataChannel

Simon

                     					       _\\|//_
                           				      ( O-O )

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Jan 2014 11:52:10 -0500

> If you want a complete dump, here it is:

Thanks. I see this is still a work in progress, and google-specific.
It isn't following draft-ietf-mmusic-sctp-sdp. (And I don't find any 
iana registration for mime type application/google-data.)

I trust this is just implementation getting ahead of the standards work.

	Thanks,
	Paul

> a=extmap:3http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
> a=sendrecv
> a=rtcp-mux
>>> a=fingerprint:sha-256
>>> DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A:D5:3A:7D:6C:A1:00:6D
>>> a=setup:actpass
>>> a=mid:data
>>> a=sendrecv
>>> b=AS:30
>>> a=rtcp-mux
>>> a=crypto:0 AES_CM_128_HMAC_SHA1_80
>>> inline:1CFp/gR+88d3ig0EcgluA0yGumtiKI8gxOH2f/ug
>>> a=fingerprint:sha-256
>>> DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A:D5:3A:7D:6C:A1:00:6D
>>> a=setup:active
>>> a=mid:data
>>> a=sendrecv
>>> b=AS:30
>>> a=rtcp-mux
>>>>> To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 29 Jan 2014 18:06:55 +0100

Hi Paul,

> It isn't following draft-ietf-mmusic-sctp-sdp. (And I don't find any iana registration for mime type application/google-data.)
> 

It actually is. I dumped  the SDP on the following browser (Chrome Canary): 

Version 34.0.1811.0 canary

If you want to have an idea of how this stuff looks like in Firefox (Nightly build, release 29.0a1), here is a similar dump:

*Note Well: here the data channel is negotiated like this (see end of the dump): m=application 58232 DTLS/SCTP 5000

sdp:"v=0
o=Mozilla-SIPUA-29.0a1 27617 0 IN IP4 0.0.0.0
s=SIP Call
t=0 0
a=ice-ufrag:e42fa2c1
a=ice-pwd:fb40d85ac9eb85690de66e4c58df2d55
a=fingerprint:sha-256 FE:AF:92:3D:29:3B:23:98:A2:24:3C:0B:35:A3:33:08:6A:FB:2F:59:F8:6D:82:AB:9F:53:C8:2F:D0:9B:80:E5
m=audio 56393 RTP/SAVPF 109 0 8 101
c=IN IP4 100.71.44.223
a=rtpmap:109 opus/48000/2
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=recvonly
a=setup:actpass
a=candidate:0 1 UDP 2130379007 143.225.28.167 53116 typ host
a=candidate:2 1 UDP 2130444543 100.71.44.223 56393 typ host
a=candidate:0 2 UDP 2130379006 143.225.28.167 57887 typ host
a=candidate:2 2 UDP 2130444542 100.71.44.223 57653 typ host
a=rtcp-mux
m=video 63084 RTP/SAVPF 120
c=IN IP4 100.71.44.223
a=rtpmap:120 VP8/90000
a=sendrecv
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=setup:actpass
a=candidate:0 1 UDP 2130379007 143.225.28.167 64657 typ host
a=candidate:2 1 UDP 2130444543 100.71.44.223 63084 typ host
a=candidate:0 2 UDP 2130379006 143.225.28.167 56287 typ host
a=candidate:2 2 UDP 2130444542 100.71.44.223 53824 typ host
a=rtcp-mux
m=application 58232 DTLS/SCTP 5000 
c=IN IP4 100.71.44.223
a=sctpmap:5000 webrtc-datachannel 16
a=setup:actpass

Hope this helps,

Simon

                     					       _\\|//_
                           				      ( O-O )

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 29 Jan 2014 17:52:58 +0000

One of the updates planned to draft-ejzak-dispatch-webrtc-data-channel-sdpneg before London is to generalise it so it can be used outside of rtcweb.

Regards

Keith 

> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 29 January 2014 16:02
> To: [email-masked]
> > Maybe I misunderstood what you said, but the idea is that 
> we would always use draft-ietf-mmusic-sctp-sdp to negotiate 
> and establish the DTLS/SCTP channel, and use the rtcweb data 
> channel mechanism.
> >
> > The rtcweb data channel mechanism then specifies the SCTP 
> details, and the rtcweb data channel protocol (still TBD 
> whether it's mandated) is used to open the channel, and 
> indicate that it will be used for CLUE.
> 
> draft-ejzak-dispatch-webrtc-data-channel-sdpneg to negotiate 
> the data channel, thus avoiding the need to rely upon the 
> rtcweb data channel protocol.
> 
> I guess either mechanism will work. Which is preferable 
> depends on what you think will happen in the future for use 
> of other data channel in a sip O/A environment.
> 
> For instance, if we wanted to also negotiate a hypothetical 
> BFCP over data channel usage, either with or without clue.
> 
> 	Thanks,
> 	Paul
> 
> > Regards,
> >
> > Christer
> >
> > Are you asking that rtcweb data channel is the ONLY method 
> for establishing a CLUE channel? or that it is one of the methods?
> >
> > If CLUE is being used in the rtcweb context then it would 
> appear to make sense to use the web data channel. However if 
> rtcweb isn't being used then why couldn't we use 
> draft-ietf-mmusic-sctp-sdp to set up the CLUE channels?
> >
> > I don't think there's anything in the CLUE protocol/data 
> model that would prevent either being used.
> >
> > Regards, Christian
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Jan 2014 14:11:23 -0500

> One of the updates planned to draft-ejzak-dispatch-webrtc-data-channel-sdpneg before London is to generalise it so it can be used outside of rtcweb.

Yeah. I asked Richard to do that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Jan 2014 07:34:37 +0000

Hi,

>> If we want to have interoperability with rtcweb, we need to use the SCTP properties defined in the rtcweb data channel draft. 
>> I have not heard, or identified myself, any reason why that would be a problem for CLUE.
>
> [MB] I think the decision to be made by CLUE needs to more importantly consider whether that approach works for CLUE without RTCWEB.  We 
> discussed on the call that the RTCWEB WG document (i.e., draft-ietf-rtcweb-data-channel/) could be viewed as providing a more generic mechanism 
> that can be used for applications beyond RTCWEB.

Yes. The rtcweb data channel is designed so that it works with JavaScript applications. But, as I said on the call, there is nothing JavaScript specific about. Not even all rtcweb applications will be JavaScript based.

> That all said, as an individual, I don't see it to be a tremendous amount of work to write a  clue-data-channel document that uses identical 
> mechanisms but has content specific to CLUE.  For example, the generic aspects in the RTCWEB seem to be primarily limited to 
> section 5 (just over 3 pages of text).  Section 4 has some generic aspects, but also some of it is RTCWEB specific. And, section 3 is totally specific 
> to RTCWEB.  And, we need to decide how much of section 6 applies to CLUE.So, personally, I think CLUE could just write their own document 
> (and perhaps mention that procedures in section blah are identical to those for RTCWEB OR write a general document that both CLUE and 
> RTCWEB can reference (although the doc would have more boiler plate than content.  Or perhaps, section 5 could be folded into the 
> tsvwg document (although I haven't looked at that in detail to see if it would work). [/MB] 

We could for sure write our own document, eventhough much would be copy/paste from the rtcweb document. 

However, even if we write our own document, assuming we want interoperability, we would STILL have a dependency on the rtcweb data channel, because that's where the SCTP PPID values are defined.

I can try to put something together.

Regards,

Christer

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 30 Jan 2014 09:14:03 +0100

Hello folks,

I might be perhaps too naif, but I have to admit I don't see the point of discussion here. In my view, the CLUE protocol is independent from the underlying transport means. One of the potential transports (the best current option, IMHO) is the RtcWeb/WebRTC data channel. I think we should keep on specifying CLUE protocol messages and state machines in the CLUE protocol document. We might then write a document illustrating how it is possible to seamlessly implement such a protocol on top of the RtcWeb data channel. I am actually working on an individual contribution which basically illustrates the above concepts, by also providing a couple of call flows. I also believe that Christer's proposal perfectly fits such an approach. Should the WG decide that this option is worth exploring, I would be glad to contribute.

Cheers,

Simon

                     					       _\\|//_
                           				      ( O-O )

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Jan 2014 08:30:41 +0000

Hi,

I agree that we shall try to keep the CLUE protocol and the CLUE protocol transport independent, and I never suggested that we should stop the work on the CLUE protocol while deciding on the transport :)

However, when we define the CLUE protocol state machine, we DO need to make some assumptions about the transport, e.g. whether it provides reliable transport, in-order transport etc. If not, such mechanisms need to be implemented in the CLUE protocol itself (similar to what is done in SIP with message re-transmission, usage of CSeq etc).

But, I strongly think that we shall decide on *A* transport mechanism for the CLUE protocol. Otherwise we won't even guarantee interoperability between CLUE entities.

Regards,

Christer

From: Simon Pietro Romano [mailto:[email-masked]]
Sent: 30. tammikuuta 2014 10:14
To: Christer Holmberg
Cc: Mary Barnes; Christian Groves; [email-masked]
Subject: Re: [clue] RTCWEB data channel for CLUE?

Hello folks,

Cheers,

Simon

Hi,

Regards,

Christer

                                                                          _\\|//_
                                                                ( O-O )
                                           e-mail: [email-masked]<mailto:[email-masked]>

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 30 Jan 2014 09:36:12 +0100

Hi Christer,

> However, when we define the CLUE protocol state machine, we DO need to make some assumptions about the transport, e.g. whether it provides reliable transport, in-order transport etc. If not, such m…

The CLUE protocol draft currently states the following:

CLUE Participants are connected by means of the CLUE signaling
   channel.  Such channel has been conceived as a DTLS/SCTP/UDP channel
   in [I-D.kyzivat-clue-signaling] and it is established as depicted in
   the same document.  CLUE protocol messages flow across such channel.

We assume the
   DTLS/SCTP/UDP channel is established and define the behiavior of the
   CLUE Participants communicating on it.  We discuss how the CLUE
   dialogue between them can be exploited to successfully setup the
   telepresence session according to the principles and concepts pointed
   out in in [I-D.ietf-clue-framework].

Isn't this already enough? If not, what other assumptions do you think we should make?

Thanks,

Simon

>  
> But, I strongly think that we shall decide on *A* transport mechanism for the CLUE protocol. Otherwise we won’t even guarantee interoperability between CLUE entities.
>  
> Regards,
>  
> Christer
>  

                     					       _\\|//_
                           				      ( O-O )

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Jan 2014 08:42:06 +0000

Hi,

We need to make assumptions on whether the transport provides reliability and in-order. When using "DTLS/SCTP/UDP", those features are optional, as far as I know.

Anyway, I am not saying that we haven't made such assumptions already - it was more a general comment when talking about the separation between protocol and transport.

Regards,

Christer

From: Simon Pietro Romano [mailto:[email-masked]]
Sent: 30. tammikuuta 2014 10:36
To: Christer Holmberg
Cc: Mary Barnes; Christian Groves; [email-masked]
Subject: Re: [clue] RTCWEB data channel for CLUE?

Hi Christer,

   in [I-D.kyzivat-clue-signaling<http://tools.ietf.org/html/draft-presta-clue-protocol-03#ref-I-D.kyzivat-clue-signaling>] and it is established as depicted in

We assume the

   out in in [I-D.ietf-clue-framework<http://tools.ietf.org/html/draft-presta-clue-protocol-03#ref-I-D.ietf-clue-framework>].

Thanks,

Simon

Regards,

Christer

From: Simon Pietro Romano [mailto:[email-masked]]
Sent: 30. tammikuuta 2014 10:14
To: Christer Holmberg
Cc: Mary Barnes; Christian Groves; [email-masked]<mailto:[email-masked]>
Subject: Re: [clue] RTCWEB data channel for CLUE?

Hello folks,

Cheers,

Simon

Hi,

Regards,

Christer

                                                                          _\\|//_
                                                                ( O-O )

                                                                          _\\|//_
                                                                ( O-O )

---

From: Christian Groves <[email-masked]>
Date: Thu, 30 Jan 2014 20:51:12 +1100

Hello,

I think we need something in CLUE which says how it works with SCTP. 
There will be things we still need to do like registering a 
media-subtype "CLUE" (if that is still part of the SCTP SDP draft) etc. 
I assume that wouldn't be done in RTCWEB.

Regards,
Christian

On 30/01/2014 7:42 PM, Christer Holmberg wrote:
>
> Hi,
>
> We need to make assumptions on whether the transport provides 
> reliability and in-order. When using “DTLS/SCTP/UDP”, those features 
> are optional, as far as I know.
>
> Anyway, I am not saying that we haven’t made such assumptions already 
> – it was more a general comment when talking about the separation 
> between protocol and transport.
>
> Regards,
>
> Christer
>
> *From:*Simon Pietro Romano [mailto:[email-masked]]
> *Sent:* 30. tammikuuta 2014 10:36
> *To:* Christer Holmberg
> *Cc:* Mary Barnes; Christian Groves; [email-masked]
> *Subject:* Re: [clue] RTCWEB data channel for CLUE?
>
> Hi Christer,
>
>     However, when we define the CLUE protocol state machine, we DO
>     need to make some assumptions about the transport, e.g. whether it
>     provides reliable transport, in-order transport etc. If not, such
>     mechanisms need to be implemented in the CLUE protocol itself
>     (similar to what is done in SIP with message re-transmission,
>     usage of CSeq etc).
>
>     in [I-D.kyzivat-clue-signaling  <http://tools.ietf.org/html/draft-presta-clue-protocol-03#ref-I-D.kyzivat-clue-signaling>] and it is established as depicted in
>     out in in [I-D.ietf-clue-framework  <http://tools.ietf.org/html/draft-presta-clue-protocol-03#ref-I-D.ietf-clue-framework>].
>
>     But, I strongly think that we shall decide on **A** transport
>     mechanism for the CLUE protocol. Otherwise we won’t even guarantee
>     interoperability between CLUE entities.
>
>     Regards,
>
>     Christer
>
>     *From:*Simon Pietro Romano [mailto:[email-masked]]
>     *Sent:*30. tammikuuta 2014 10:14
>     *To:*Christer Holmberg
>     *Cc:*Mary Barnes; Christian Groves; [email-masked]
>     <mailto:[email-masked]>
>     *Subject:*Re: [clue] RTCWEB data channel for CLUE?
>
>     Hello folks,
>
>     I might be perhaps too naif, but I have to admit I don't see the
>     point of discussion here. In my view, the CLUE protocol is
>     independent from the underlying transport means. One of the
>     potential transports (the best current option, IMHO) is the
>     RtcWeb/WebRTC data channel. I think we should keep on specifying
>     CLUE protocol messages and state machines in the CLUE protocol
>     document. We might then write a document illustrating how it is
>     possible to seamlessly implement such a protocol on top of the
>     RtcWeb data channel. I am actually working on an individual
>     contribution which basically illustrates the above concepts, by
>     also providing a couple of call flows. I also believe that
>     Christer's proposal perfectly fits such an approach. Should the WG
>     decide that this option is worth exploring, I would be glad to
>     contribute.
>
>     Cheers,
>
>     Simon
>
>             If we want to have interoperability with rtcweb, we need
>             to use the SCTP properties defined in the rtcweb data
>             channel draft.
>
>         [MB] I think the decision to be made by CLUE needs to more
>         importantly consider whether that approach works for CLUE
>         without RTCWEB. We
>
>         discussed on the call that the RTCWEB WG document (i.e.,
>         draft-ietf-rtcweb-data-channel/) could be viewed as providing
>         a more generic mechanism
>
>     Yes. The rtcweb data channel is designed so that it works with
>     JavaScript applications. But, as I said on the call, there is
>     nothing JavaScript specific about. Not even all rtcweb
>     applications will be JavaScript based.
>
>
>
>     That all said, as an individual, I don't see it to be a tremendous
>     amount of work to write a clue-data-channel document that uses
>     identical
>
>         mechanisms but has content specific to CLUE. For example, the
>         generic aspects in the RTCWEB seem to be primarily limited to
>
>         section 5 (just over 3 pages of text). Section 4 has some
>         generic aspects, but also some of it is RTCWEB specific. And,
>         section 3 is totally specific
>
>         to RTCWEB. And, we need to decide how much of section 6
>         applies to CLUE.So, personally, I think CLUE could just write
>         their own document
>
>         (and perhaps mention that procedures in section blah are
>         identical to those for RTCWEB OR write a general document that
>         both CLUE and
>
>         RTCWEB can reference (although the doc would have more boiler
>         plate than content. Or perhaps, section 5 could be folded into the
>
>     However, even if we write our own document, assuming we want
>     interoperability, we would STILL have a dependency on the rtcweb
>     data channel, because that's where the SCTP PPID values are defined.
>
>     e-mail:[email-masked] <mailto:[email-masked]>
>
> e-mail: [email-masked] <mailto:[email-masked]>
>

---

From: Mary Barnes <[email-masked]>
Date: Thu, 30 Jan 2014 08:13:21 -0600

I think part of the debate here is whether any of the SCTP related stuff
beyond what Simon has already noted is in the CLUE protocol document would
be in the CLUE protocol document.  I had envisioned that as Simon noted,
the CLUE protocol itself is designed to be independent of the transport.
 We could add a reference to a separate CLUE document that discusses the
specifics of how CLUE uses SCTP (and a note that other transports could
also be used).  That latter document could reference the RTCWEB and TSVWG
documents (or MMUSIC if that's what we decide).    And, we already have
that as a separate milestone.

I think it's very important to decouple the protocol from the transport.

Mary.

On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves <
[email-masked]> wrote:

> Hello,
>
> I think we need something in CLUE which says how it works with SCTP. There
> will be things we still need to do like registering a media-subtype "CLUE"
> (if that is still part of the SCTP SDP draft) etc. I assume that wouldn't
> be done in RTCWEB.
>
> Regards,
> Christian
>
>
>> We need to make assumptions on whether the transport provides reliability
>> and in-order. When using "DTLS/SCTP/UDP", those features are optional, as
>> far as I know.
>>
>> Anyway, I am not saying that we haven't made such assumptions already -
>> it was more a general comment when talking about the separation between
>> protocol and transport.
>>
>> Regards,
>>
>> Christer
>>
>>     in [I-D.kyzivat-clue-signaling  <http://tools.ietf.org/html/
>> draft-presta-clue-protocol-03#ref-I-D.kyzivat-clue-signaling>] and it is
>> established as depicted in
>>
>>     out in in [I-D.ietf-clue-framework  <http://tools.ietf.org/html/
>> draft-presta-clue-protocol-03#ref-I-D.ietf-clue-framework>].
>>
>>
>>     mechanism for the CLUE protocol. Otherwise we won't even guarantee

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Jan 2014 14:18:35 +0000

Hi,

I am sure we'll find a home for the text - the important thing now is to agree on the mechanism, and to get the text written.

Regards,

Christer

From: Mary Barnes [mailto:[email-masked]]
Sent: 30. tammikuuta 2014 16:13
To: Christian Groves
Cc: Christer Holmberg; Simon Pietro Romano; [email-masked]
Subject: Re: [clue] RTCWEB data channel for CLUE?

I think part of the debate here is whether any of the SCTP related stuff beyond what Simon has already noted is in the CLUE protocol document would be in the CLUE protocol document.  I had envisioned that as Simon noted, the CLUE protocol itself is designed to be independent of the transport.  We could add a reference to a separate CLUE document that discusses the specifics of how CLUE uses SCTP (and a note that other transports could also be used).  That latter document could reference the RTCWEB and TSVWG documents (or MMUSIC if that's what we decide).    And, we already have that as a separate milestone.

Mary.

On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

I think we need something in CLUE which says how it works with SCTP. There will be things we still need to do like registering a media-subtype "CLUE" (if that is still part of the SCTP SDP draft) etc. I assume that wouldn't be done in RTCWEB.

Regards,
Christian

Hi,

Regards,

Christer
*From:*Simon Pietro Romano [mailto:[email-masked]<mailto:[email-masked]>]
*Sent:* 30. tammikuuta 2014 10:36
*To:* Christer Holmberg
*Cc:* Mary Barnes; Christian Groves; [email-masked]<mailto:[email-masked]>
*Subject:* Re: [clue] RTCWEB data channel for CLUE?

Hi Christer,

We assume the

Thanks,

Simon

    Regards,

    Christer
    *From:*Simon Pietro Romano [mailto:[email-masked]<mailto:[email-masked]>]
    *Sent:*30. tammikuuta 2014 10:14
    *To:*Christer Holmberg
    *Cc:*Mary Barnes; Christian Groves; [email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>
    *Subject:*Re: [clue] RTCWEB data channel for CLUE?

    Hello folks,

    Cheers,

    Simon

    Hi,

            Could we use this for CLUE without using the rtcweb data
            channel mechanism?

            I have not heard, or identified myself, any reason why
            that would be a problem for CLUE.

        tsvwg document (although I haven't looked at that in detail to
        see if it would work). [/MB]

    We could for sure write our own document, eventhough much would be
    copy/paste from the rtcweb document.

    Regards,

    Christer

    _\\|//_

    ( O-O )

    Simon Pietro Romano

    Phone: +39 081 7683823<tel:%2B39%20081%207683823> -- Fax: +39 081 7683816<tel:%2B39%20081%207683816>
    e-mail:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

    oooO

    \ ( ( )

    \_) ) /

    (_/

_\\|//_

( O-O )

Simon Pietro Romano

Phone: +39 081 7683823<tel:%2B39%20081%207683823> -- Fax: +39 081 7683816<tel:%2B39%20081%207683816>
e-mail: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

oooO

\ ( ( )

\_) ) /

(_/

---

From: Mary Barnes <[email-masked]>
Date: Thu, 30 Jan 2014 10:12:31 -0600

Sure. But, it's very important to keep in mind what we are talking about
when referring to other documents.

I'm thinking the best way forward would be to put together a document that
list and evaluates all the alternatives versus diving in with the
assumption that we'll use the RTCWEB mechanism.   Just to be clear, I'm not
suggesting that's a document we progress, but I think it is important to
ensure that the WG considers all the options, pros/cons and applicability
of each before we start working out the details.

Mary.

On Thu, Jan 30, 2014 at 8:18 AM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,
>
>
>
> I am sure we'll find a home for the text - the important thing now is to
> agree on the mechanism, and to get the text written.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Mary Barnes [mailto:[email-masked]]
> *Sent:* 30. tammikuuta 2014 16:13
> *To:* Christian Groves
> *Cc:* Christer Holmberg; Simon Pietro Romano; [email-masked]
> Anyway, I am not saying that we haven't made such assumptions already - it
> was more a general comment when talking about the separation between
> protocol and transport.
>
> Regards,
>
> Christer
>
>     in [I-D.kyzivat-clue-signaling  <
> http://tools.ietf.org/html/draft-presta-clue-protocol-03#ref-I-D.kyzivat-clue-signaling>]
> and it is established as depicted in
>
>
>     out in in [I-D.ietf-clue-framework  <
> http://tools.ietf.org/html/draft-presta-clue-protocol-03#ref-I-D.ietf-clue-framework
> >].
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Jan 2014 11:21:01 -0500

I agree with both Christer and Mary here.

I think the *protocol* document should be independent of the specific 
transport. But it must make some requirements on the sort of transports 
it can work with. (Reliable, ordered, message oriented)

But we need for some other document (e.g. signaling) to fill in the 
rest, so we have all the pieces necessary for successful interoperation 
by two implementations. This must, at least, specify how this will work 
when the session is negotiated via SIP and SDP O/A.

And Christer is working on the latter.

A couple of pieces of the puzzle are:
- draft-ietf-mmusic-sctp-sdp
- draft-ietf-tsvwg-sctp-dtls-encaps

and the things they reference. But that only gives raw SCTP streams.

If we were doing this work without regard to RTCWEB, we might stop 
there, and just specify how we choose SCTP streams for our purpose.

But in order to give us a chance at interoperating with RTCWEB, we 
choose to also reuse draft-ietf-rtcweb-data-channel. This puts another 
layer of abstraction over SCTP, bonding pairs of unidirectional SCTP 
streams into bidirectional Data Channels, and making SCTP message 
attributes sticky for a channel.

We wouldn't necessarily *need* that, but RTCWEB broswer apps won't be 
able to directly access the lower layers, so we need to follow that 
abstraction if we want to make it *possible* for an rtcweb browser app 
to directly access our clue protocol.

I guess we *could* define clue directly on 
draft-ietf-rtcweb-data-channel, and simply be very careful to define it 
in a way that coincidentally is interoperable with how 
draft-ietf-rtcweb-data-channel uses SCTP. But IMO that is a dangerous 
approach - very difficult to maintain consistency.

So I think it is better that we reference draft-ietf-rtcweb-data-channel.

I agree that document has more rtcp-specifics than I would like. What 
are out options about that?
1) live with it
2) encourage the authors of that document to structure it so that
    the rtcweb specifics are clearly segregated from the more generic
    parts
3) work to factor that document into two separate documents,
    one generic and one rtcweb specific.

 From our perspective, (3) would probably be best. I don't know how 
feasible it is. We would probably need to volunteer to do it, though 
perhaps we could recruit Richard Ejzak.

Doing this *right* would probably mean moving the generic document to 
another wg. (tsvwg?) I suspect that rtcweb might object on the grounds 
that this would unnecessarily delay them.

In the interest of expediency, I can live with (2), or possibly even (1).

	Thanks,
	Paul

On 1/30/14 9:18 AM, Christer Holmberg wrote:
> Hi,
>
> I am sure we’ll find a home for the text – the important thing now is to
> *From:*Mary Barnes [mailto:[email-masked]]
> beyond what Simon has already noted is in the CLUE protocol document
> would be in the CLUE protocol document.  I had envisioned that as Simon
> noted, the CLUE protocol itself is designed to be independent of the
> transport.  We could add a reference to a separate CLUE document that
> discusses the specifics of how CLUE uses SCTP (and a note that other
> transports could also be used).  That latter document could reference
> the RTCWEB and TSVWG documents (or MMUSIC if that's what we decide).
>   And, we already have that as a separate milestone.
>
> On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> Hello,
>
>     Anyway, I am not saying that we haven’t made such assumptions
>     already – it was more a general comment when talking about the
>     separation between protocol and transport.
>
>     Regards,
>
>     Christer
>
>          in [I-D.kyzivat-clue-signaling
>       <http://tools.ietf.org/html/draft-presta-clue-protocol-03#ref-I-D.kyzivat-clue-signaling>] and it is established as depicted in
>
>
>          out in in [I-D.ietf-clue-framework
>       <http://tools.ietf.org/html/draft-presta-clue-protocol-03#ref-I-D.ietf-clue-framework>].
>
>
>
>          <mailto:[email-masked] <mailto:[email-masked]>>
>          Phone: +39 081 7683823 <tel:%2B39%20081%207683823> -- Fax: +39
>     081 7683816 <tel:%2B39%20081%207683816>
>
>     e-mail:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>
>
>
>     Phone: +39 081 7683823 <tel:%2B39%20081%207683823> -- Fax: +39 081
>     7683816 <tel:%2B39%20081%207683816>
>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Jan 2014 16:24:09 +0000

Hi,

As far as I know, the only alternatives we have identified are:

  1.
Whether or not to use the rtcweb data channel PROTOCOL
  2.
Whether or not to use Richard’s draft

Nobody has presented an alternative to the usage of the SCTP capabilities (PPID values, reliability, etc) defined the rtcweb data channel draft (whether we will use that draft as is, or write parts in our own document, is an editorial issue).

Regards,

Christer

Sent from Windows Mail

From: Mary Barnes<mailto:[email-masked]>
Sent: ‎Thursday‎, ‎January‎ ‎30‎, ‎2014 ‎6‎:‎12‎ ‎PM
To: Hans-Christer Holmberg<mailto:[email-masked]>
Cc: Christian Groves<mailto:[email-masked]>, Simon Pietro Romano<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Sure. But, it's very important to keep in mind what we are talking about when referring to other documents.

I'm thinking the best way forward would be to put together a document that list and evaluates all the alternatives versus diving in with the assumption that we'll use the RTCWEB mechanism.   Just to be clear, I'm not suggesting that's a document we progress, but I think it is important to ensure that the WG considers all the options, pros/cons and applicability of each before we start working out the details.

Mary.

On Thu, Jan 30, 2014 at 8:18 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I am sure we’ll find a home for the text – the important thing now is to agree on the mechanism, and to get the text written.

Regards,

Christer

From: Mary Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 30. tammikuuta 2014 16:13
To: Christian Groves
Cc: Christer Holmberg; Simon Pietro Romano; [email-masked]<mailto:[email-masked]>
Subject: Re: [clue] RTCWEB data channel for CLUE?

Mary.

Regards,
Christian

Hi,

We need to make assumptions on whether the transport provides reliability and in-order. When using “DTLS/SCTP/UDP”, those features are optional, as far as I know.

Anyway, I am not saying that we haven’t made such assumptions already – it was more a general comment when talking about the separation between protocol and transport.

Regards,

Christer

Hi Christer,

We assume the

Thanks,

Simon

    Regards,

    Christer

    Hello folks,

    Cheers,

    Simon

    Hi,

    Regards,

    Christer

    _\\|//_

    ( O-O )

    Simon Pietro Romano

    oooO

    \ ( ( )

    \_) ) /

    (_/

_\\|//_

( O-O )

Simon Pietro Romano

oooO

\ ( ( )

\_) ) /

(_/

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Jan 2014 16:30:21 +0000

Paul,

The “layer” that the RTCWEB data channel adds are basically SCTP characteristics  - things that we would have to define ANYWAY.

So, the question is whether we are ok with the SCTP characteristics, or whether we would need different ones. I have not seen any such indication.

The question is whether we see a need for the rtcweb data channel PROTOCOL or not. It has been confirmed that the usage is OPTIONAL, so it’s up to us to determine whether we need it or not.

Regards,

Christer

Sent from Windows Mail

From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎Thursday‎, ‎January‎ ‎30‎, ‎2014 ‎6‎:‎21‎ ‎PM
To: [email-masked]<mailto:[email-masked]>

 Thanks,
 Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Jan 2014 11:39:32 -0500

Yes, I didn't mention rtcweb data channel PROTOCOL in my earlier reply.

As I read things, it is *possible* to avoid use of that and still be 
compatible with rtcweb and browser apps. Two ways we could do that:
- standardize fixed channel assignments for clue. (Ugh!)
- use richard's draft to negotiate the channel with SDP

Since fixed channel assignment is a *really bad idea*, ISTM that 
practically speaking we can either:
- depend on richard's draft
- depend on the rtcweb data channel protocol draft

Pick your poison.

	Thanks,
	Paul

On 1/30/14 11:24 AM, Christer Holmberg wrote:
> Nobody has presented an alternative to the usage of the SCTP
> capabilities (PPID values, reliability, etc) defined the rtcweb data
> channel draft (whether we will use that draft as is, or write parts in
> our own document, is an editorial issue).
>
> Regards,
>
> Christer
>
> Sent from Windows Mail
>
> *From:* Mary Barnes <mailto:[email-masked]>
> *Sent:* ‎Thursday‎, ‎January‎ ‎30‎, ‎2014 ‎6‎:‎12‎ ‎PM
> *To:* Hans-Christer Holmberg <mailto:[email-masked]>
> *Cc:* Christian Groves <mailto:[email-masked]>, Simon
> Pietro Romano <mailto:[email-masked]>, [email-masked]
> <mailto:[email-masked]>
>
> I'm thinking the best way forward would be to put together a document
> that list and evaluates all the alternatives versus diving in with the
> assumption that we'll use the RTCWEB mechanism.   Just to be clear, I'm
> not suggesting that's a document we progress, but I think it is
> important to ensure that the WG considers all the options, pros/cons and
> applicability of each before we start working out the details.
>
> Mary.
>
>
> On Thu, Jan 30, 2014 at 8:18 AM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi,____
>
>     __ __
>
>     I am sure we’ll find a home for the text – the important thing now
>     is to agree on the mechanism, and to get the text written.____
>
>     __ __
>
>     Regards,____
>
>     __ __
>
>     Christer____
>
>     __ __
>
>     *From:*Mary Barnes [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Subject:* Re: [clue] RTCWEB data channel for CLUE?____
>
>     __ __
>
>     I think part of the debate here is whether any of the SCTP related
>     stuff beyond what Simon has already noted is in the CLUE protocol
>     document would be in the CLUE protocol document.  I had envisioned
>     that as Simon noted, the CLUE protocol itself is designed to be
>     independent of the transport.  We could add a reference to a
>     separate CLUE document that discusses the specifics of how CLUE uses
>     SCTP (and a note that other transports could also be used).  That
>     latter document could reference the RTCWEB and TSVWG documents (or
>     MMUSIC if that's what we decide).    And, we already have that as a
>     separate milestone. ____
>
>     __ __
>
>     I think it's very important to decouple the protocol from the
>     transport.____
>
>     __ __
>
>     Mary. ____
>
>     __ __
>
>     __ __
>
>     __ __
>
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:____
>
>     Hello,
>
>     media-subtype "CLUE" (if that is still part of the SCTP SDP draft)
>     etc. I assume that wouldn't be done in RTCWEB.
>
>     Regards,
>     Christian____
>
>
>
>     On 30/01/2014 7:42 PM, Christer Holmberg wrote:____
>
>
>         Hi,
>
>         reliability and in-order. When using “DTLS/SCTP/UDP”, those
>         features are optional, as far as I know.
>
>         Christer____
>         *Subject:* Re: [clue] RTCWEB data channel for CLUE?____
>
>
>
>         Hi Christer,
>
>              channel.  Such channel has been conceived as a
>         DTLS/SCTP/UDP channel____
>
>           <http://tools.ietf.org/html/draft-presta-clue-protocol-03#ref-I-D.kyzivat-clue-signaling>] and it is established as depicted in____
>
>
>              telepresence session according to the principles and
>         concepts pointed____
>
>           <http://tools.ietf.org/html/draft-presta-clue-protocol-03#ref-I-D.ietf-clue-framework>].____
>
>
>
>         Simon____
>              But, I strongly think that we shall decide on **A**
>         transport____
>
>
>              Christer____
>              *Subject:*Re: [clue] RTCWEB data channel for CLUE?____
>
>
>
>              Hello folks,
>
>              Phone: +39 081 7683823 <tel:%2B39%20081%207683823> -- Fax:
>         +39 081 7683816 <tel:%2B39%20081%207683816>____
>
>         <mailto:[email-masked] <mailto:[email-masked]>>____
>
>
>
>         081 7683816 <tel:%2B39%20081%207683816>____
>
>         <mailto:[email-masked] <mailto:[email-masked]>>____
>
>
>
>         (_/____
>     __ __
>     __ __

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Jan 2014 11:41:51 -0500

On 1/30/14 11:30 AM, Christer Holmberg wrote:
> Paul,
>
> The “layer” that the RTCWEB data channel adds are basically SCTP
> characteristics  - things that we would have to define ANYWAY.
>
> So, the question is whether we are ok with the SCTP characteristics, or
> whether we would need different ones. I have not seen any such indication.

AFAIK we need reliable ordered, an option no matter which way we go.

> The question is whether we see a need for the rtcweb data channel
> PROTOCOL or not. It has been confirmed that the usage is OPTIONAL, so
> it’s up to us to determine whether we need it or not.

I just commented on that.

	Paul

> Regards,
>
> Christer
>
> Sent from Windows Mail
>
> *From:* Paul Kyzivat <mailto:[email-masked]>
> *Sent:* ‎Thursday‎, ‎January‎ ‎30‎, ‎2014 ‎6‎:‎21‎ ‎PM
> *To:* [email-masked] <mailto:[email-masked]>
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 30 Jan 2014 17:47:24 +0000

A protocol based on "(Reliable, ordered, message oriented)" transport will be entirely different from one that is not.

Therefore we should agree those requirements as a starting point.

If we fail to do that, it means that every response that carries information will have to have its own response that does not carry data. We will need to build retransmission into the protocol with timeouts. Etc.

Regards

Keith

> Sent: 30 January 2014 16:21
> To: [email-masked]
> I think the *protocol* document should be independent of the 
> specific transport. But it must make some requirements on the 
> sort of transports it can work with. (Reliable, ordered, 
> message oriented)
> 
> But we need for some other document (e.g. signaling) to fill 
> in the rest, so we have all the pieces necessary for 
> successful interoperation by two implementations. This must, 
> at least, specify how this will work when the session is 
> negotiated via SIP and SDP O/A.
> 
> If we were doing this work without regard to RTCWEB, we might 
> stop there, and just specify how we choose SCTP streams for 
> our purpose.
> 
> But in order to give us a chance at interoperating with 
> RTCWEB, we choose to also reuse 
> draft-ietf-rtcweb-data-channel. This puts another layer of 
> abstraction over SCTP, bonding pairs of unidirectional SCTP 
> streams into bidirectional Data Channels, and making SCTP 
> message attributes sticky for a channel.
> 
> We wouldn't necessarily *need* that, but RTCWEB broswer apps 
> won't be able to directly access the lower layers, so we need 
> to follow that abstraction if we want to make it *possible* 
> for an rtcweb browser app to directly access our clue protocol.
> 
> draft-ietf-rtcweb-data-channel, and simply be very careful to 
> define it in a way that coincidentally is interoperable with 
> how draft-ietf-rtcweb-data-channel uses SCTP. But IMO that is 
> a dangerous approach - very difficult to maintain consistency.
> 
> I agree that document has more rtcp-specifics than I would 
> like. What are out options about that?
> 1) live with it
>  From our perspective, (3) would probably be best. I don't 
> know how feasible it is. We would probably need to volunteer 
> to do it, though perhaps we could recruit Richard Ejzak.
> 
> Doing this *right* would probably mean moving the generic 
> document to another wg. (tsvwg?) I suspect that rtcweb might 
> object on the grounds that this would unnecessarily delay them.
> 
> > I am sure we'll find a home for the text - the important 
> thing now is 
> > to agree on the mechanism, and to get the text written.
> >
> > Regards,
> >
> > Christer
> >
> > independent of the transport.  We could add a reference to 
> a separate 
> > CLUE document that discusses the specifics of how CLUE uses 
> SCTP (and 
> > a note that other transports could also be used).  That latter 
> > document could reference the RTCWEB and TSVWG documents (or 
> MMUSIC if that's what we decide).
> <mailto:[email-masked]>>
> > wrote:
> >
> > Hello,
> >
> >     reliability and in-order. When using "DTLS/SCTP/UDP", 
> those features
> >     Anyway, I am not saying that we haven't made such assumptions
> >     already - it was more a general comment when talking about the
> DTLS/SCTP/UDP
> >     channel
> <http://tools.ietf.org/html/draft-presta-clue-protocol-03#ref-I-D.kyzi
> > vat-clue-signaling>] and it is established as depicted in
> >
> >
> >          DTLS/SCTP/UDP channel is established and define 
> the behiavior
> >     of the
> >          telepresence session according to the principles 
> and concepts
> >     pointed
> >
> >              plate than content. Or perhaps, section 5 
> could be folded
> >     into the
> >

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 30 Jan 2014 17:47:25 +0000

I understand that Richard's document will need an additional set of additional requirements to that which he has written for MSRP - see

https://datatracker.ietf.org/doc/draft-ejzak-dispatch-msrp-data-channel/

Assuming we go that way, and I hope we do, it would be sensible to write those requirements into whatever document defines setting up the transport for the CLUE protocol.

I would envisage two documents: the CLUE protocol itself, and the document setting up the transport for the CLUE protocol.

regards

Keith

________________________________
From: clue [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 30 January 2014 16:24
To: Mary Barnes
Cc: [email-masked]
Subject: Re: [clue] RTCWEB data channel for CLUE?

Hi,

  1.

Regards,

Christer

Sent from Windows Mail

Mary.

Regards,

Christer

Mary.

Regards,
Christian

Hi,

Regards,

Christer

Hi Christer,

We assume the

Thanks,

Simon

    Regards,

    Christer

    Hello folks,

    Cheers,

    Simon

    Hi,

    Regards,

    Christer

    _\\|//_

    ( O-O )

    Simon Pietro Romano

    oooO

    \ ( ( )

    \_) ) /

    (_/

_\\|//_

( O-O )

Simon Pietro Romano

oooO

\ ( ( )

\_) ) /

(_/

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Jan 2014 18:59:58 +0000

...and, I did suggest such criteria (reliable etc) at the virtual interim.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

"DRAGE, Keith (Keith)" <[email-masked]> wrote:

Regards

Keith

---

From: Mary Barnes <[email-masked]>
Date: Thu, 30 Jan 2014 13:06:20 -0600

On Thu, Jan 30, 2014 at 11:47 AM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

>  I understand that Richard's document will need an additional set of
> additional requirements to that which he has written for MSRP - see
>
> Assuming we go that way, and I hope we do, it would be sensible to write
> those requirements into whatever document defines setting up the transport
> for the CLUE protocol.
>
> I would envisage two documents: the CLUE protocol itself, and the document
> setting up the transport for the CLUE protocol.
>
[MB] Yes. And, we already have two separate milestones to reflect this.
[/MB]

>
> regards
>
> Keith
>
>  ------------------------------
> *From:* clue [mailto:[email-masked]] * On Behalf Of *Christer
> Holmberg
> *Sent:* 30 January 2014 16:24
> *To:* Mary Barnes
> *Cc:* [email-masked]
>
>    1. Whether or not to use the rtcweb data channel PROTOCOL
>    2. Whether or not to use Richard's draft
>
>
> channel draft (whether we will use that draft as is, or write parts in our
> own document, is an editorial issue).
>
>  Regards,
>
>  Christer
>
>  Sent from Windows Mail
>
>  *From:* Mary Barnes <[email-masked]>
> *Sent:* Thursday, January 30, 2014 6:12 PM
> *To:* Hans-Christer Holmberg <[email-masked]>
> *Cc:* Christian Groves <[email-masked]>, Simon Pietro
> Romano <[email-masked]>, [email-masked]
>
>> There will be things we still need to do like registering a media-subtype
>> "CLUE" (if that is still part of the SCTP SDP draft) etc. I assume that
>> wouldn't be done in RTCWEB.
>>
>> Regards,
>> Christian
>>
>>
>>