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

Stefan Håkansson LK <> Fri, 28 November 2014 13:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 52E551A1B0A for <>; Fri, 28 Nov 2014 05:44: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 WQ5yoOluP_BC for <>; Fri, 28 Nov 2014 05:44:34 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B5B51A1B65 for <>; Fri, 28 Nov 2014 05:44:34 -0800 (PST)
X-AuditID: c1b4fb30-f79d66d00000744c-5d-54787c40439c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id FD.1B.29772.04C78745; Fri, 28 Nov 2014 14:44:32 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 14:44:31 +0100
From: Stefan Håkansson LK <>
To: "Makaraju, Maridi Raju (Raju)" <>, Justin Uberti <>
Thread-Topic: [rtcweb] JSEP: Why always offer actpass?
Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JA==
Date: Fri, 28 Nov 2014 13:44:30 +0000
Message-ID: <>
References: <> <> <> <> <> <>
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+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvja5DTUWIwZQ5shZbpwpZNGy8wmqx 9l87uwOzR+uzvaweCzaVeixZ8pMpgDmKyyYlNSezLLVI3y6BK2P3oU6Wgh0yFRO/dzA3MN4U 72Lk5JAQMJHY9+cyC4QtJnHh3nq2LkYuDiGBI4wShxsbWSGcJYwSU7p3gFWxCQRKbN23gA3E FhHIlZjXtxLMZhZQl7iz+Bw7iC0sYCox6eIyJogaM4mFJycwQth6Eje/XACaw8HBIqAq8WQS K0iYV8BXYsrMnVCLDzFL/JgyHWwOI9BF30+tYYKYLy5x68l8JohLBSSW7DnPDGGLSrx8/I8V ZKaEgJLEtK1pEOV6EjemToE6TVti2cLXzBC7BCVOznzCMoFRdBaSqbOQtMxC0jILScsCRpZV jKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIFxc3DLb4MdjC+fOx5iFOBgVOLhLZCtCBFiTSwr rsw9xCjNwaIkzrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwymdse77dhLL+mqbsy dMOTp8vufGazWnshRvoKxzv7gL3JG67euJ/2Mei4ebxTyY+qSj37OcnqboVPfoRXyirbbLg7 MVfs1rcHV1a5ZTiFO7+dp2ucpLZ/0gVxR/evJ2e9nCj9W2byurpIEc3eXRYdqRfCOl0Djimz nl21/KlFgNsrpuoHXwuVWIozEg21mIuKEwEdsXebfAIAAA==
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 13:44:36 -0000

Thanks for a good overview!

On 25/11/14 19:30, Makaraju, Maridi Raju (Raju) wrote:
>> Do you have an opinion on my main "topic": that subsequent offers
>> should offer the already negotiated role, rather than always
>> "actpass"?
> [Raju] For non DTLS-SRTP associations, I think the key attribute here
> is a=connection. If a subsequent offer has an explicit
> "a=connection:existing" then per the reference[1] a=setup (and other
> params) are ignored. Per [2] below, the default value for
> a=connection is "new" in offer and answer. So, if an explicit
> "a=connection:new" is present or "a=connection" is absent then, per
> [3],  the existing association is closed and a new association will
> be opened using new a=setup rules. Btw, I think section 7.3 of RFC
> 4145 is just an example showing previously negotiated setup values
> are used. But section 5.1 is normative and clearly says these
> attributes must be ignored for a=connection:existing.
> Reference [4] and [5] are for DTLS-SRTP which does not allow
> a=connection attribute and indicates new offer/answer compatibility
> with old as the criteria to reuse or close/open new one. It also
> notes that if a=setup changes then a new association is established.
> This latter part also have to consider the a=setup defaults, which
> may be different from previously negotiated values, if absent in new
> offer/answer.

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?

> [1]
> "If the connection value resulting from an offer/answer exchange is
> 'existing', the end-points continue using the existing connection.
> Consequently, the port numbers, IP addresses, and 'setup' attributes
> negotiated in the offer/answer exchange are ignored because there is
> no need to establish a new connection."
> [2] "The default
> value of the connection attribute in both offers and answers is
> 'new'. "
> [3]
> "If the connection value for an 'm' line resulting from an offer/
> answer exchange is 'new', the endpoints SHOULD establish a new TCP
> connection as indicated by the 'setup' attribute.  If a previous TCP
> connection is still up, the endpoints SHOULD close it as soon as the
> offer/answer exchange is completed.  It is up to the application to
> ensure proper data synchronization between the two TCP connections."
> [4] DTLS SRTP RFC " The
> endpoint MUST NOT use the connection attribute defined in
> [RFC4145]."
> [5] "The peers can
> reuse the existing associations if they are compatible (i.e., they
> have the same key fingerprints and transport parameters), or
> establish a new one following the same rules are for initial
> exchanges, tearing down the existing association as soon as the
> offer/answer exchange is completed.  Note that if the active/passive
> status of the endpoints changes, a new connection MUST be
> established."
> BR Raju