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

Christer Holmberg <> Sun, 30 November 2014 15:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 563D31A0367 for <>; Sun, 30 Nov 2014 07:29:11 -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 NEfFNlc2LgA5 for <>; Sun, 30 Nov 2014 07:29:09 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A37C11A0362 for <>; Sun, 30 Nov 2014 07:29:08 -0800 (PST)
X-AuditID: c1b4fb30-f79d66d00000744c-db-547b37c2ae6d
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 41.00.29772.2C73B745; Sun, 30 Nov 2014 16:29:06 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 16:29:06 +0100
From: Christer Holmberg <>
To: Stefan Håkansson LK <>, "Makaraju, Maridi Raju (Raju)" <>, Roman Shpount <>
Thread-Topic: [rtcweb] JSEP: Why always offer actpass?
Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAEtdFdA
Date: Sun, 30 Nov 2014 15:29:05 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvje4h8+oQg5aL6hYNG6+wWsy4MJXZ Yu2/dnYHZo/WZ3tZPZYs+cnkcWtKQQBzFJdNSmpOZllqkb5dAlfG82N3GAu6dCt+d3xja2Dc o9LFyMkhIWAisenWBmYIW0ziwr31bCC2kMARRokzJ8y6GLmA7CWMEj//PWXvYuTgYBOwkOj+ pw0SFxHYySjxYccxFpAGZgF1iTuLz7GD2MICphLv5x4BGyoiYCax8OQERgjbSKK1ayoTiM0i oCrx6NlJsBpeAV+JhXNAekGWneKQWPLkC9hQTgE/iTN7r4FdxAh03fdTa5gglolL3Hoynwni agGJJXvOQ30gKvHy8T9WCFtJYsX2S4wQ9XoSN6ZOYYOwtSWWLXwNtVhQ4uTMJywTGMVmIRk7 C0nLLCQts5C0LGBkWcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGFMHt/w22MH48rnjIUYB DkYlHt4NP6pChFgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD o/hct6aUXS9OXEmo+HF517TVt3OO12v2cLAqeVvXzWo9rvhObLaGjLiYhIVAd76Z4sljc4Im bf38lrmwY4lPr6BaVYgSR9WX/XujXhZ/k3q7+U7E7X/7DPb/dmphWcZgYXt/xQzfzVXVZefU uwNlHXrvPWY1eKfetiHv9pWvT28JWealX3gnocRSnJFoqMVcVJwIAM1CKNCKAgAA
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 15:29:11 -0000


If some clarification regarding this is needed, I don't think it should be in the JSEP draft.

If it's related to SDP Offer/Answer in general, it should be in an MMUSIC spec, referenced by JSEP.



-----Original Message-----
From: Stefan Håkansson LK 
Sent: 30 November 2014 17:27
To: Makaraju, Maridi Raju (Raju); Christer Holmberg; Roman Shpount
Subject: Re: [rtcweb] JSEP: Why always offer actpass?

On 30/11/14 16:06, Makaraju, Maridi Raju (Raju) wrote:
>> 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.
> <Raju>
> Hi Stefan,
> Looks like, there is some misunderstanding here.

Probably my fault in that case :)

> My conclusion is to include
> actpass, but not the previously negotiated role, in all subsequent 
> offers, not just during ICE-restarts.

I think that is what the JSEP draft says - and my conclusion is that it _is_ correct.

My point was that the _answer_ should (when it is a subsequent answer) should say the same role as in previous answers (unless there is an ICE restart).

> This is to handle the scenario of answerer changing fingerprint, which 
> is allowed (i.e. not explicitly disallowed), in a more natural way by 
> renegotiating the roles. Entity which wants to change fingerprint may 
> also want to renegotiate the role even when transport parameters are not changed.
> Also, when ICE is not used answerer can change transport parameters 
> which needs renegotiation of roles.
> So, to have uniform rules for ICE (restart or not) and no ICE it is 
> better to send the role in subsequent offer as if it is an initial offer (i.e. actpass).

That is also my understanding (and what the JSEP draft says).

> </Raju>
> BR
> Raju