Re: [rtcweb] JSEP: Why always offer actpass?

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Tue, 25 November 2014 16:28 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.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 9FF461ACD9A for <rtcweb@ietfa.amsl.com>; Tue, 25 Nov 2014 08:28:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.41
X-Spam-Level:
X-Spam-Status: No, score=-5.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 wWsjufu6JqNM for <rtcweb@ietfa.amsl.com>; Tue, 25 Nov 2014 08:28:31 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4701ACDA1 for <rtcweb@ietf.org>; Tue, 25 Nov 2014 08:28:26 -0800 (PST)
Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 1270917F36211; Tue, 25 Nov 2014 16:28:20 +0000 (GMT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id sAPGSMev030742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Nov 2014 11:28:22 -0500
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 11:28:22 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>, Justin Uberti <juberti@google.com>
Thread-Topic: [rtcweb] JSEP: Why always offer actpass?
Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAAz2pYg
Date: Tue, 25 Nov 2014 16:28:22 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17828E63C45B@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <CAOJ7v-1ztXies0-W3B2=zWaydeLTuR8tU7v15nqyTw+MwGE+rw@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se>
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.17]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JJy9rAEVd96Og6tqypjrCHSPGic
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] JSEP: Why always offer actpass?
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, 25 Nov 2014 16:28:33 -0000

> >     o  The endpoint MUST use the setup attribute defined in [RFC4145
> <https://tools.ietf.org/html/rfc4145>].
> >        The endpoint that is the offerer MUST use the setup attribute
> >        value of setup:actpass and be prepared to receive a client_hello
> >        before it receives the answer.  The answerer MUST use either a
> >        setup attribute value of setup:active or setup:passive.  Note that
> >        if the answerer uses setup:passive, then the DTLS handshake will
> >        not begin until the answerer is received, which adds additional
> >        latency. setup:active allows the answer and the DTLS handshake to
> >        occur in parallel.  Thus, setup:active is RECOMMENDED.  Whichever
> >        party is active MUST initiate a DTLS handshake by sending a
> >
> >        ClientHello over each flow (host/port quartet).
> 
> The section quoted seem to refer to the initial offer/answer, later in
> that document (section 6.6, with heading "Session Modification") there
> is wording that (to me at least) hints at keeping the established roles
> in subsequent offers.
> 
> A different question is the value of initially offering actpass when ICE
> is mandatory to use. ICE connectivity checks will happen before the DTLS
> handshake, so perhaps initially offering passive would make sense.
> (actpass is a MUST according to 5763, OTOH 5763 is only an informal ref
> to JSEP.)

<Raju>
Limiting it to "passive" would force the peer and/or intermediaries to support DTLS client functionality as well. IMHO, this may limit the success rate. If a peer or middlebox does not support DTLS client functionality then it can always return "passive", which may involve bit more delay in DTLS setup. But it is not that bad as the SDP offerer must wait for SDP answer (a=fingerprint is needed) before the DTLS can be setup successfully anyway.
</Raju>

BR
Raju