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

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Tue, 25 November 2014 18:30 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.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 2F02F1A8766 for <rtcweb@ietfa.amsl.com>; Tue, 25 Nov 2014 10:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.41
X-Spam-Level:
X-Spam-Status: No, score=-5.41 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_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 oFOOhdnkF9jM for <rtcweb@ietfa.amsl.com>; Tue, 25 Nov 2014 10:30:46 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACB01A8786 for <rtcweb@ietf.org>; Tue, 25 Nov 2014 10:30:07 -0800 (PST)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 4969456E03ED4; Tue, 25 Nov 2014 18:30:01 +0000 (GMT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id sAPIU3aS000711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Nov 2014 13:30:03 -0500
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 13:30:03 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Justin Uberti <juberti@google.com>
Thread-Topic: [rtcweb] JSEP: Why always offer actpass?
Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAA2/86w
Date: Tue, 25 Nov 2014 18:30:02 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17828E63C90D@US70UWXCHMBA02.zam.alcatel-lucent.com>
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>
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.17]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pweTq1Ul-kliw5-sOrc0CjNEMMk
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: Tue, 25 Nov 2014 18:30:48 -0000

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

[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