Re: [clue] Draft new version: draft-holmberg-clue-data-channel-04

[Christer Holmberg <[e-mail]>]

Hi,

>>>>> Section 4.3:
>>>>>
>>>>> This section (and maybe others) refers to "the offerer". I don't think
>>>>> this is very clear. I think it would be helpful to define a new term
>>>>> (role) (e.g. Master) that identifies which end of the session is
>>>>> responsible for maintaining the association. It could be the end that
>>>>> sends the first offer that mentions the SCTP m-line in the clue group,
>>>>> or it could be more complicated. But regardless, it is defined in one
>>>>> place, and other places just reference that term, rather than something
>>>>> confusing like "offerer".
>>>>
>>>> Well, comedia also talks about the offer and the answerer, for TCP.
>>>
>>> Does it do so when referring to some past o/a? I know it talks about the
>>> *current* offerer and answerer. That is fine. Its when talking about the
>>> roles from some past O/A cycle (especially when it might not even be the
>>> prior one) that it gets confusing.
>>
>> My understanding is that you are considered the offerer until another the other peer sends an offer. It may not be very clear in the spec, though.
>
> I don't know, though that seems plausible.
>
> But my understanding was that what you were talking about is the sender
> of the offer that first introduced the sctp m-line. And that this role
> wouldn't be changed by future offers coming in the other direction.
>
> Maybe that isn't what you meant. But if so then again it seems unclear
> to me.

The safest way could be to say that whoever detects the failure shall send a new offer. If both endpoints do it, the o/a race condition rules will take care of it.


-----------------


>>>>> I think it would be helpful to discuss the use of a=setup and
>>>>> a=connection here. (and in 5.5.) These may also provide a basis for
>>>>> defining which end takes future responsibility for maintaining the
>>>>> association.
>>>>
>>>> I actually think that both 5.4 and 5.5 belong to the sctp-sdp draft. There needs to be a common way for establishing the SCTPoDTLS assocation, and >>>> there is nothing CLUE specific in the text.
>>>
>>> Agree. But if we somehow can't get it put in there, then I think we should include it in our stuff.
>>
>> Section 6 of the sctp-sdp draft does talk about the setup and connection attributes (it basically referes to TCP), so we can reference that.
>>
>> 6.  The Setup and Connection Attributes and Association Management
>>
>>     The use of the 'setup' and 'connection' attributes in the context of
>>     an SCTP association is identical to the use of these attributes in
>>     the context of a TCP connection.  That is, SCTP endpoints MUST follow
>>     the rules in Sections 4 and 5 of RFC 4145 [RFC4145] when it comes to
>>     the use of the 'setup' and 'connection' attributes in offer/answer
>>     [RFC3264] exchanges.
>>
>>     The management of an SCTP association is identical to the management
>>     of a TCP connection.  That is, SCTP endpoints MUST follow the rules
>>     in Section 6 of RFC 4145 [RFC4145] to manage SCTP associations.
>>     Whether to use the SCTP ordered or unordered delivery service is up
>>     to the applications using the SCTP association.
>>
>> If we have comments on that text we should take it to MMUSIC :)
>
>Actually, I think the most difficult issues have to do with this and
>bundling. ISTM the implications need to be thought through, and then
>there *might* be a need to write something somewhere - not sure where.
>
>Here are a couple of issues that come to mind:
>
>- a bundle is created with some DTLS/RTP m-lines.
>   Later, there is desire to add the DTLS/SCTP to the bundle.
>   This will be a *new* SCTP association, but using the
>   *existing* DTLS connection. So what is the a=connection
>   attribute set to? And must it be the same for all the m-lines
>   in the bundle? (That currently seems to be required.)
>   If set to 'new', won't that force renegotiation of the DTLS,
>   including possibly a new IP address?

I don't think there is an existing DTLS connection. DTLS is only used for the RTP key exchange, isn't it?

In general, the SDP attribute considerations for BUNDLE shall be described in Suhas' draft.

> - if an error occurs on the SCTP association, but not on the DTLS
>   connection, what does one do to recover? One might want to
>   reinitialize the association, but how does one signal that?
>   Offering a=connection:new would be one way, but it has all the
>   same problems in the previous case.

I think this also belongs to the sdp-sctp draft.

Regards,

Christer