Re: [clue] Comment on the signalling draft

[Christer Holmberg <[e-mail]>]

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.

>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:[e-mail]]
> Sent: 21. maaliskuuta 2014 8:03
> To: Christer Holmberg; [e-mail]
> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue
>

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