Re: [rtcweb] How to determine TLS roles?

Tim Panton <tim@phonefromhere.com> Tue, 11 February 2014 14:54 UTC

Return-Path: <tim@phonefromhere.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FAC1A0444 for <rtcweb@ietfa.amsl.com>; Tue, 11 Feb 2014 06:54:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPF7grC8DY-g for <rtcweb@ietfa.amsl.com>; Tue, 11 Feb 2014 06:54:09 -0800 (PST)
Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD9A1A0465 for <rtcweb@ietf.org>; Tue, 11 Feb 2014 06:54:07 -0800 (PST)
Received: (qmail 77036 invoked from network); 11 Feb 2014 14:54:05 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 10172
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 11 Feb 2014 14:54:05 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id C227018A0465; Tue, 11 Feb 2014 14:53:57 +0000 (GMT)
Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7620F18A0407; Tue, 11 Feb 2014 14:53:57 +0000 (GMT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1695A8@ESESSMB209.ericsson.se>
Date: Tue, 11 Feb 2014 14:53:48 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <03B88F25-D4A7-468F-B9CE-165A1E6E4D10@phonefromhere.com>
References: <7594FB04B1934943A5C02806D1A2204B1D1672FC@ESESSMB209.ericsson.se> <9ADA7473-1F36-4D96-A875-D2DC0762E9C2@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1673C4@ESESSMB209.ericsson.se> <54B6400D-3753-4285-96DB-08EDB23BD03F@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1674E9@ESESSMB209.ericsson.se>, <CABcZeBOyQeLSwYjKt7hNqn0WViHYhvLmsGecmwCWyGNgUdgSnA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D167825@ESESSMB209.ericsson.se> <8991EDBE-71F3-4456-A614-A9F4926F4955@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167CF8@ESESSMB209.ericsson.se> <1FC0C1C7-E5AB-4D4C-ABCC-8371457DCBF0@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D167EAC@ESESSMB209.ericsson.se> <FB2E27C9-EE06-4EC8-95DF-E0B18CCFC216@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B1D1695A8@ESESSMB209.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1827)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] How to determine TLS roles?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Feb 2014 14:54:11 -0000

On 11 Feb 2014, at 10:49, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> Hi,
> 
>>>>>> 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.
>>> 
>>> Not sure what this has to do with early media. You can have two browser based applications, using SDP O/A to negotiate the DTLS roles.
>> 
>> You only care about manipulating the DTLS roles if you want the side that _didn't_ initiate the call to initiate the media flow. The only instance where that happens is early media. 
>> Without early media there is no need to manipulate which end is client/server since the default or initiator is client makes sense - or am I missing something?
> 
> I don't really have a need to "manipulate" the roles. I just want my JS App to know what role its browser will take, so it can inform its peer (using whatever signaling protocol) about the role.

well - assuming you leave  a=setup as actpass (the default in the browser)  .
If you called createOffer, then you'll be DTLS client. 
If you called createAnswer you'll be DTLS server.
That's assuming no weirdness in the ICE implementation. So your JS can _deduce_ the role but neither influence it nor _know_ it directly.

However, signalling it over your high level signalling protocol is the wrong way to do it (IMHO). Your peer should deduce the appropriate DTLS role from the 'signalling' 
in the ICE packets, by looking at the ICE CONTROLLING flag. 

> 
> Regards,
> 
> Christer
> 
>