Subject: [clue] Comment on the signalling draft

From: Christian Groves <[email-masked]>
Date: Fri, 21 Mar 2014 12:44:15 +1100

With respect to clause 3.4/draft-kyzivat-clue-signaling:

A CLUE-enabled device that receives an initial SDP offer from a non-
    CLUE device with no CLUE data channel "m" line SHOULD include a new
    data channel "m" line in any subsequent offers it sends, to indicate
    that it is CLUE-enabled.

I think this is incorrect. The use of a m=line with DTLS/SCTP and a 
SCTPmap=WebRTC data channel only means that the device supports the data 
channel protocol. It does not mean indicate that the device is 
CLUE-enabled. Knowing that an endpoint wants to use CLUE only occurs 
when the data channel protocol is used to open a SCTP stream.

I think this is also a problem in section 3.1. A CLUE data channel is 
defined as: "CLUE Data Channel refers to a WebRTC Data Channel
    [I-D.ietf-rtcweb-data-channel], with a specific set of SCTP
    characteristics, and usage of the Data Channel Establishment Protocol
    (DCEP) [I-D.ietf-rtcweb-data-protocol] in order to open a WebRTC Data
    Channel for the purpose of transporting CLUE protocol
    [I-D.presta-clue-protocol] messages between two CLUE entities."

You cannot have the presence of the "CLUE data channel" in an SDP offer 
or answer because the "CLUE data channel" is a SET of characteristics 
including the DCEP (which is generic in a SCTPmap). You only know what 
it is for when an endpoint tries to do a DCEP open. All that the SDP 
offer/answer says with m= DTLS/SCTP and SCTPMAP=WebRTC datachannel is 
that the device wants to establish a DTLS/SCTP association with DCEP. It 
could use DCEP to establish protocol: "foo", "bar" or "CLUE". The 
association could be used for anything.

Of course the above is not an issue if 
draft-ejzak-mmusic-data-channel-sdpneg is used but my understanding this 
is not in scope of the draft.

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Mar 2014 05:16:52 +0000

Hi Christian,

I assume the signalling draft will simply reference the clue-datachannel draft in future versions.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Christian Groves <[email-masked]> wrote:

Regards, Christian

_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

---

From: Christian Groves <[email-masked]>
Date: Fri, 21 Mar 2014 17:02:40 +1100

Hello Christer,

I'm not sure that is enough.

I think ultimately that the use of CLUE will depend on:

1. Usage of the session attribute GROUP indicating CLUE.
2. Specification of m-line for DTLS/SCTP association
3. Specification of a=mid indicating that the above m-line is part of 
the CLUE group
4. Specification of a=sctpmap indication "WebRTC datachannel"
5. Establishment of the DTLS/SCTP association
6. A successful DCEP open indicating the use of CLUE.

So unless your draft specifies the use of the CLUE group then I don't 
think it is enough.

If an endpoint wants to signal its intention to use CLUE via an SDP 
Offer then it has to do steps 1 to 4.

You only have a "CLUE data channel" after steps 1-6.

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Mar 2014 07:16:30 +0000

Hi Christian,

Paul has commented that the clue-datachannel draft should specify the usage of the CLUE group to indicate which (if any) DTLS/SCTP association is associated with CLUE. I intend to do that in the next version of the draft.

Regards,

Christer

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: 21. maaliskuuta 2014 8:03
To: Christer Holmberg; [email-masked]
Subject: Re: [clue] Comment on the signalling draft

Hello Christer,

1. Usage of the session attribute GROUP indicating CLUE.
2. Specification of m-line for DTLS/SCTP association 3. Specification of a=mid indicating that the above m-line is part of the CLUE group 4. Specification of a=sctpmap indication "WebRTC datachannel"
5. Establishment of the DTLS/SCTP association 6. A successful DCEP open indicating the use of CLUE.

So unless your draft specifies the use of the CLUE group then I don't think it is enough.

If an endpoint wants to signal its intention to use CLUE via an SDP Offer then it has to do steps 1 to 4.

Regards, Christian

On 21/03/2014 4:16 PM, Christer Holmberg wrote:
> SCTPmap=WebRTC data channel only means that the device supports the 
> data channel protocol. It does not mean indicate that the device is 
> You cannot have the presence of the "CLUE data channel" in an SDP 
> offer or answer because the "CLUE data channel" is a SET of 
> characteristics including the DCEP (which is generic in a SCTPmap). 
> You only know what it is for when an endpoint tries to do a DCEP open. 
> All that the SDP offer/answer says with m= DTLS/SCTP and 
> SCTPMAP=WebRTC datachannel is that the device wants to establish a 
> DTLS/SCTP association with DCEP. It could use DCEP to establish 
> protocol: "foo", "bar" or "CLUE". The association could be used for anything.
>
> draft-ejzak-mmusic-data-channel-sdpneg is used but my understanding 
> this is not in scope of the draft.
>
> Regards, Christian
>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Mar 2014 07:19:20 +0000

(if many), that is

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 21. maaliskuuta 2014 9:17
To: Christian Groves; [email-masked]
Subject: Re: [clue] Comment on the signalling draft

Hi Christian,

Regards,

Christer

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: 21. maaliskuuta 2014 8:03
To: Christer Holmberg; [email-masked]
Subject: Re: [clue] Comment on the signalling draft

Hello Christer,

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Mar 2014 11:20:41 -0400

IMO (as individual) the a=group:clue is a better indication of clue 
support, because it is explicit to CLUE.

IIUC it is legal to have an a=group attribute without any 
identification-tags (mids), so we can use that to indicate *support* for 
CLUE even when not *using* CLUE.

Based on that, here is a proposal:

- SIP UAs that *support* CLUE MUST include one a=group:clue attribute
   in all SDP offers.
- when a SIP UA that *supports* CLUE receives an offer containing an
   a=group:clue attribute, it MUST include a=group:clue in the answer.
- SIP UAs that want to *use* CLUE SHOULD include a DTLS/SCTP m-line
   in offers, and reference it in the a=group:clue line.
- if a SIP UA that wants to *use* CLUE receives an offer with
   a DTLS/SCTP m-line referenced from an a=group:clue attribute,
   it SHOULD accept the DTLS/SCTP m-line.
- (more rules for using DCEP to set up the channel once the association
   is available)

I'm leaving a little wiggle room above with the SHOULDs. For instance, 
it would be possible to do the first O/A with DTLS/SCTP, or one could 
wait for an indication that the other side supports CLUE before offering 
the DTLS/SCTP.

A more interesting case: suppose the initial offer contained the clue 
group and offered the DTLS/SCTP, but the answer failed to indicate 
support for clue. Then subsequent offers could indicate clue support via 
the group, but not take the expense of offering the DTLS/SCTP. If, at 
some later time, a change occurs (e.g., a transfer) and a subsequent 
answer indicates support for clue, then another offer with the DTLS/SCTP 
can be made.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Mar 2014 18:50:12 +0000

Hi,

>IMO (as individual) the a=group:clue is a better indication of clue support, because it is explicit to >CLUE.
>
>IIUC it is legal to have an a=group attribute without any identification-tags (mids), so we can use >that to indicate *support* for CLUE even when not *using* CLUE.

While I agree that it's not forbidden to use an a=group attributes without mids, I STRONGLY think we shall define a media feature tag to indicate CLUE support. It also allows usage of caller prefs for reaching a CLUE device etc.

Such media feature tag can be defined in the signalling draft.

>- SIP UAs that *support* CLUE MUST include one a=group:clue attribute

Only if the UA wants to establish a CLUE session, in my opinion. For general indication of support, let's use a media feature tag.

>   a=group:clue attribute, it MUST include a=group:clue in the answer.

See above.

>   in offers, and reference it in the a=group:clue line.

Agree.

>I'm leaving a little wiggle room above with the SHOULDs. For instance, it would be possible to do the >first O/A with DTLS/SCTP, or one could wait for an indication that the other side supports CLUE >before offering the DTLS/SCTP.

I need to think a little more about this.

But, in any case, until you have established the data channel you don't have a CLUE session.

>A more interesting case: suppose the initial offer contained the clue group and offered the >DTLS/SCTP, but the answer failed to indicate support for clue. Then subsequent offers could >indicate clue support via the group, but not take the expense of offering the DTLS/SCTP. If, at some >later time, a change occurs (e.g., a transfer) and a subsequent answer indicates support for clue, >then another offer with the DTLS/SCTP can be made.

Again, I don't think we should use the a=group for general support indication.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Mar 2014 15:44:24 -0400

> Such media feature tag can be defined in the signalling draft.

I don't feel strongly about a feature tag. One advantage of using 
something in the SDP is that isn't limited to SIP.

But sure, we could rewrite the rules I gave, substituting the feature 
tag for the a=group and it would be fine. (Of course we still need to 
use a=group when *using* clue, or setting up to use it.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Mar 2014 19:50:56 +0000

Hi,

>>> IMO (as individual) the a=group:clue is a better indication of clue support, because it is explicit to >>CLUE.
>>>
>>> IIUC it is legal to have an a=group attribute without any identification-tags (mids), so we can use >>that to indicate *support* for CLUE even when not *using* CLUE.
>>
>> While I agree that it's not forbidden to use an a=group attributes without mids, I STRONGLY think >>we shall define a media feature tag to indicate CLUE support. It also allows usage of caller prefs for >>reaching a CLUE device etc.
>I don't feel strongly about a feature tag. One advantage of using something in the SDP is that isn't >limited to SIP.
>
>But sure, we could rewrite the rules I gave, substituting the feature tag for the a=group and it would >be fine. (Of course we still need to use a=group when *using* clue, or setting up to use it.

Yes.

Regards,

Christer

>>> I think this is also a problem in section 3.1. A CLUE data channel 
>>> is defined as: "CLUE Data Channel refers to a WebRTC Data Channel

---

From: Christian Groves <[email-masked]>
Date: Mon, 24 Mar 2014 09:51:52 +1100

>> But sure, we could rewrite the rules I gave, substituting the feature tag for the a=group and it would >be fine. (Of course we still need to use a=group when *using* clue, or setting up to use it.
Sounds OK to me.

Christian