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

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Fri, 28 November 2014 13:44 UTC

Return-Path: <stefan.lk.hakansson@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E551A1B0A for <rtcweb@ietfa.amsl.com>; Fri, 28 Nov 2014 05:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ5yoOluP_BC for <rtcweb@ietfa.amsl.com>; Fri, 28 Nov 2014 05:44:34 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5B51A1B65 for <rtcweb@ietf.org>; Fri, 28 Nov 2014 05:44:34 -0800 (PST)
X-AuditID: c1b4fb30-f79d66d00000744c-5d-54787c40439c
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FD.1B.29772.04C78745; Fri, 28 Nov 2014 14:44:32 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 14:44:31 +0100
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
To: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>, "Justin Uberti" <juberti@google.com>
Thread-Topic: [rtcweb] JSEP: Why always offer actpass?
Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JA==
Date: Fri, 28 Nov 2014 13:44:30 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se>
References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <CAOJ7v-1ztXies0-W3B2=zWaydeLTuR8tU7v15nqyTw+MwGE+rw@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17828E63C45B@US70UWXCHMBA02.zam.alcatel-lucent.com> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17828E63C90D@US70UWXCHMBA02.zam.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.147]
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==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sfFKY9-TSbucAvcTM5pv8C-Cnmg
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] JSEP: Why always offer actpass?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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] https://tools.ietf.org/html/rfc4145#section-5.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] https://tools.ietf.org/html/rfc4145#section-5.1 "The default
> value of the connection attribute in both offers and answers is
> 'new'. "
>
> [3] https://tools.ietf.org/html/rfc4145#section-5.2
>
> "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 https://tools.ietf.org/html/rfc5763#section-5 " The
> endpoint MUST NOT use the connection attribute defined in
> [RFC4145]."
>
> [5] https://tools.ietf.org/html/rfc5763#section-6.6 "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
>