Re: [rtcweb] How to determine TLS roles?

[Tim Panton <[e-mail]>]

On 10 Feb 2014, at 20:03, Christer Holmberg <[e-mail]> wrote:

> Hi,
> 
>>>> This is defined in RFC 5763 S 5:
>>>> http://tools.ietf.org/html/rfc5763#section-5
>>>> 
>>>> Which points to:
>>>> http://tools.ietf.org/html/rfc4145
>>> 
>>> Ok. So, a few questions to for clarification:
>>> 
>>> Q1: This means that the JS App must set the setup attrbute value before passing an SDP to the browser?
>> No, peer-to-peer browser calls should 'do the right thing' - based on the initator/ice-controlling rule Both browsers set a=setup:act-pass meaning that we fall back to the old rules.
> 
> What "old rules"? :)
> 

Sorry that was unclear - As I read it, putting 
a=setup:actpass 
in the SDP indicates that the ice-controlling entity should act as DTLS client, and typically the ice-controlling entity is the initiator of the session. So it isn't a matter of O/A negotiation.

>>> Q2: If SDP O/A is not used on the wire, there needs to be another mechanism for the peers to negotiate/indicate who is "active" and who is "passive"?
>>> 
>> If you don't care, and are locally generating the SDP for a remote offer or answer, set a=setup:act-pass and the roles sort themselves out.
> 
> According to the "old rules", right? :)

Yeah, Ice controlling is the DTLS client. 

> 
>> If however you have a gateway initating a call to a browser, and it wants to do early media (it's an 800 number gateway for example) then it sets a=setup:active
>> in the SDP it sends (or you create on it's behalf).
> 
> There doesn't necessarily have to be a gateway. It may be a browser-to-browser call, using SIP and SDP O/A on the wire - meaning that the SDP setup attribute is used to determine the roles.

But there is no concept of early media on a peer-to-peer webRTC call, so there isn't any need to manage which side is the DTLS client or server.

> 
>>> Q3: If you have mulitple m- lines, all using the same DTLS association, the setup attribute value must be identical in all m- lines?
>>> 
>> 
>> Yes, I think so.
>> 
>>> Q4: The data channel (DTLS/SCTP) will have the same rule (e.g. using the setup attribute value) as DTLS/SRTP for determining the TLS role?
>> 
>> That's the way chrome seems to implement it - and presumably the way the spec is intended.
> 
> Ok.
> 
> Regards,
> 
> Christer