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

Christer Holmberg <> Fri, 28 November 2014 15:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 103BE1A1A68 for <>; Fri, 28 Nov 2014 07:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_110=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6F-hteIwCgFE for <>; Fri, 28 Nov 2014 07:00:33 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F1C91A000B for <>; Fri, 28 Nov 2014 07:00:32 -0800 (PST)
X-AuditID: c1b4fb25-f791c6d00000617b-6f-54788e0f14c0
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 6F.86.24955.F0E88745; Fri, 28 Nov 2014 16:00:31 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 16:00:30 +0100
From: Christer Holmberg <>
To: Roman Shpount <>, Stefan Håkansson LK <>
Thread-Topic: [rtcweb] JSEP: Why always offer actpass?
Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JADE6FaAAAJOeiA=
Date: Fri, 28 Nov 2014 15:00:29 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+JvjS5/X0WIwcF1/BYzLkxltlj7r53d gcljyZKfTB63phQEMEVx2aSk5mSWpRbp2yVwZexte89SsEet4u2pI2wNjHtUuxg5OSQETCRW nDjEBGGLSVy4t56ti5GLQ0jgCKPEsgMrWCGcJYwSm4+2AzkcHGwCFhLd/7RBGkQESiQWt1xg AbGZBdQl7iw+xw5iCwuYSryfe4QZosZMYuHJCYwQtpXEnZ5fbCA2i4CqxMy7XWA2r4CvxKvN V6F2nWWR+HjlDzvILk6BQIk3O8RAahiBjvt+ag0TxC5xiVtP5kMdLSCxZM95ZghbVOLl43+s ELaSxI8Nl1hAxjALaEqs36UP0aooMaX7ITvEWkGJkzOfsExgFJuFZOoshI5ZSDpmIelYwMiy ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwcg5u+a26g/HyG8dDjAIcjEo8vAWyFSFCrIll xZW5hxilOViUxHkXnpsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFR7PSJv68WnvavkFqw 5Ob9zaqR05daSSYkidTKeqywf8Dz9eQ/juOpp++6Hj+yPsW/6/n/tc+ffOJgfDtj2sK/fyr4 T93sEK+KKpp8dp7zTMfaE34BO+KNPfpzqznrig7MzV4usuLj56JpArO6W2w2G8+Q0nGbfdrs 4hfePXLiB6XW1jmoGk24rsRSnJFoqMVcVJwIAIwcZ+Z9AgAA
Cc: "" <>
Subject: Re: [rtcweb] JSEP: Why always offer actpass?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Nov 2014 15:00:36 -0000


You may want to take a look at the new version of the SCTP-SDP draft, where I have added procedures (and some open issues) regarding the usage of a=setup and a=connection.

>In this context we're dealing only with DTLS-SRTP I guess.
>I read [5] as that subsequent offers should offer the negotiated role
>for existing connections (and not actpass), but I'm not sure. What is
>your interpretation?
> I actually have a more generic question: In what circumstances would new DTLS connection handshake be initiated if transport parameters and fingerprint did not change? 
> I assume new negotiation is required if subsequent offer contains active or passive role that does not match the current connection state. 
> What about actpass? Is getting an actpass in the subsequent offer should mean that the roles did not change and existing connection should continue to be re-used or does it mean new negotiation should be started?
> Should DTLS-SRTP endpoints be able to handle new DTLS handshake at any time, without any associated signaling exchange? I do not think any of the 
> current browser implementations support that, even though such support would be required for DTLS-SRTP rekey. If DTLS handshake 
> handling at any time is required, then end-points should only be forced to do a new handshake by signaling if their roles change. If one of the end-points 
> turns out to be overzealous and starts an unexpected handshake, it would be handled no differently then DTLS rekey, as long as roles stayed the same.
> There is also a consideration, that the newly generated offer is intended to be send to a completely new end-point and not to the existing connection. This would 
> most likely be known in advance for webrtc end points, since they will need to collect a new set of ICE candidates, but this can affect SIP end-points.
> Since we would probably want to avoid extra handshakes, and that we want to accommodate both offers intended for the existing and the new destinations, we can 
> state that in the subsequent offers, the end point should include the actpass setup attribute. In the answer, if DTLS connection is already setup, the end point should 
> respond with the currently negotiated role. If an end-point receives an offer with the non actpass setup attribute, it should only initiate a new DTLS handshake if the 
> specified attribute does not match the currently negotiated setup state.

RFC 7345 (UDPTL-DTLS) says the following:

	"Once an offer/answer exchange has been completed, either endpoint MAY
   	send a new offer in order to modify the session.  The endpoints can
   	reuse the existing DTLS association if the key fingerprint values and
   	transport parameters indicated by each endpoint are unchanged.
   	Otherwise, following the rules for the initial offer/answer exchange,
   	the endpoints can negotiate and create a new DTLS association and,
   	once created, delete the previous DTLS association, following the
   	same rules for the initial offer/answer exchange.  Each endpoint
   	needs to be prepared to receive data on both the new and old DTLS
   	associations as long as both are alive."

So, I guess that can be read in a way that the setup attribute as such does not impact previously negotiated TLS roles - unless the key fingerprint values and/or transport parameters are modified.

The SCTP-SDP draft currently says that a subsequent offer must not change the previously negotiated roles. But, I guess we could say something similar as in RFC 7345.