Re: [clue] Comment on the signalling draft

On 3/21/14 2:50 PM, Christer Holmberg wrote:
> 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.

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

>> Based on that, here is a proposal:
>>
>> - SIP UAs that *support* CLUE MUST include one a=group:clue attribute
>>    in all SDP offers.
>
> 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.
>
>> - 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.
>
> See above.
>
>> - 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.
>
> Agree.
>
>> - 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.
>
> 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
>
>
>
>
>
>
>
>
> On 3/21/14 3:16 AM, Christer Holmberg wrote:
>> 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:Christian.Groves@nteczone.com]
>> Sent: 21. maaliskuuta 2014 8:03
>> To: Christer Holmberg; clue@ietf.org
>> Subject: Re: [clue] Comment on the signalling draft
>>
>> 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
>>
>> On 21/03/2014 4:16 PM, Christer Holmberg wrote:
>>> 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 <Christian.Groves@nteczone.com> wrote:
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> clue@ietf.org
>>> https://www.ietf.org/mailman/listinfo/clue
>>>
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>