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

Roman Shpount <> Fri, 28 November 2014 14:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 189031A1B6C for <>; Fri, 28 Nov 2014 06:34:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XHOxbBXAmI3K for <>; Fri, 28 Nov 2014 06:34:44 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5ED6F1A1A69 for <>; Fri, 28 Nov 2014 06:34:44 -0800 (PST)
Received: by with SMTP id n3so18708726wiv.17 for <>; Fri, 28 Nov 2014 06:34:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VhQwaZHWriJ41Hwa/ogCxbIvfsOnJ1+gLC/+rplKu+4=; b=V7EdsAxpF5pVCSnplV8U8OAlS1FHHF37Mawno9OzZdkUzPqhkFa7HOPByuim1bZSXx lNpOdgTGnRHN/ZHgwWIlpp4bwGFnuo6F+Ily3/jisEa0e0ZIcfj4vTZKoY7dTip6y6hJ pKm0VOBMtPrKVbIqYVZ5/eAI/dR3PFQLYOL8x+mtafGR5Eod3P9FnCrPa+3Rlvwe1rIC Wjh3ttpjyAeiqbVQ1j3repheYAv+88wzCAQAAN0wigL8xxpmfh7YVjGcqwdIxzx7Y7OV 5J0T7xM1dFzCNxG9CYno9PgTRVzplQj/4mWU9oUmukHiIB7HQN72Jc5qC0Y0m1T2DlEN yq1A==
X-Gm-Message-State: ALoCoQnly75jjn1IfdvuF+iC6OwB3wprDO+RXRstICqzfb+PQVgHHMa7ZQSwB6df/o9Va3LRC4ps
X-Received: by with SMTP id uo1mr68324427wjc.105.1417185282968; Fri, 28 Nov 2014 06:34:42 -0800 (PST)
Received: from ( []) by with ESMTPSA id vy7sm15250412wjc.27.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Nov 2014 06:34:41 -0800 (PST)
Received: by with SMTP id a1so8999393wgh.25 for <>; Fri, 28 Nov 2014 06:34:41 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id cl20mr71205490wjb.71.1417185281286; Fri, 28 Nov 2014 06:34:41 -0800 (PST)
Received: by with HTTP; Fri, 28 Nov 2014 06:34:41 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Fri, 28 Nov 2014 09:34:41 -0500
Message-ID: <>
From: Roman Shpount <>
To: Stefan Håkansson LK <>
Content-Type: multipart/alternative; boundary="047d7bd910c245a8e80508ec29bb"
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 14:34:46 -0000

On Fri, Nov 28, 2014 at 8:44 AM, Stefan Håkansson LK <> wrote:

> 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.
Roman Shpount