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

Stefan Håkansson LK <> Sun, 30 November 2014 14:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F03BD1A01F6 for <>; Sun, 30 Nov 2014 06:21:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4-3xvm4SnoeS for <>; Sun, 30 Nov 2014 06:21:00 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0D551A0108 for <>; Sun, 30 Nov 2014 06:20:59 -0800 (PST)
X-AuditID: c1b4fb2d-f79fc6d000001087-0a-547b27c9a152
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 8C.48.04231.9C72B745; Sun, 30 Nov 2014 15:20:57 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 15:20:57 +0100
From: Stefan Håkansson LK <>
To: "Makaraju, Maridi Raju (Raju)" <>, Christer Holmberg <>, Roman Shpount <>
Thread-Topic: [rtcweb] JSEP: Why always offer actpass?
Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JA==
Date: Sun, 30 Nov 2014 14:20:56 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje5J9eoQgz8/NS0aNl5htZhxYSqz xdp/7ewOzB6tz/ayeixZ8pPJ49aUggDmKC6blNSczLLUIn27BK6MffvusBTMUqhom/ORvYFx n1QXIweHhICJxJ+zhl2MnECmmMSFe+vZuhi5OIQEjjBKdC34yAzhLGGUuPLsCztIA5tAsETT XzeQuIjAAkaJdysXsoN0MwuoS9xZfA7MFhYwlZh0cRkTiC0iYCax8OQERghbT+LmlwssIDaL gKrEyZU9YHFeAV+JWd+esUMse88m0d10B6yIEeik76fWMEEsEJe49WQ+E8SpAhJL9pxnhrBF JV4+/scKYStJNC55wgpRbyDx/tx8ZghbW2LZwtfMEMsEJU7OfMIygVF0FpKxs5C0zELSMgtJ ywJGllWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgbFzcMtv3R2Mq187HmIU4GBU4uHd8KMq RIg1say4MvcQozQHi5I476Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MC5Qir6uK1Dp zrYm9JTK7+Y6NtEj8//85g/aIPXly7+khdXMH3In5XGcvRjn47jitdTtnueaapOXHfGseGFc uKI54+yEuXXHV/Da+R5xzjAIfzoviOPnrR1HPXrm6tX1eu/lKOc6ePLym5Sq9UWTaq9nnT57 1vXiXv8dKX85d77QD1I+1LD18jQlluKMREMt5qLiRAD1j3eEfgIAAA==
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: Sun, 30 Nov 2014 14:21:02 -0000

On 30/11/14 14:51, Makaraju, Maridi Raju (Raju) wrote:
>> Hi,
>>>> 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.
>>> I have struggled with this language quite a bit from the
>>> implementation
>> perspective. I think we need to explicitly state
>>> that endpoints MUST reuse the existing association if the key
>>> fingerprint
>> values and transport parameters indicated
>>> by each endpoint are unchanged.
>> We could take such general approach.
>> However, for ‘SCTP/DTLS’ (DTLS over SCTP), I assume that the DTLS
>> connection will also be re-established if the underlying SCTP
>> association is re- established - even if no transport parameters
>> etc are changed.
>> Also, RFC 6083 says:
>> “Each DTLS connection MUST be established and terminated within the
>> same SCTP association.”
>>> The way this language reads to me is that endpoints can reuse the
>>> existing
>> association if they want to, but they can create a new one if they
>> don't. Also, when this new
>>> association is created, it is unclear if old setup roles MUST be
>>> preserved
>> or if they MUST be selected based on the current offer/answer
>> exchange. It seems the current
>>> specification language is not strong or clear enough on this
>>> topic.
>> In my opinion, IF a new DTLS connection needs to be established
>> (for whatever reasons), the current roles should be used.
> <Raju> When ICE is NOT used, how does the offerer know that the
> answerer does not change the fingerprint and/or transport parameters?
> I guess it does not know. So, offerer has to be prepared for new DTLS
> association by offering actpass. When ICE is used, the answerer can't
> change transport parameter unless offerer does ICE restart (which
> changes offerer transport parameters); Ref [1] is very clear on this
> indicating "DTLS handshake procedure is repeated". However, even when
> ICE is used, I do not find any restriction about answerer not
> changing fingerprint. So, even without ICE restart answerer can
> trigger a DTLS renegotiation by changing its fingerprint.
> To conclude all this, IMO whether ICE is used or not, sending actpass
> for all new offers may be cover all possible scenarios.

That is also my conclusion based on the discussion so far.

I also think the JSEP draft as far as detailed out is correct, but info 
about how the implementation should behave for Subsequent answers is 
missing. Text saying that the role must be maintained (unless there is 
an ICE restart) should be put in there.