[rtcweb] JSEP-03: O/A state machine and trickle ICE with forking

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 27 February 2013 20:23 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C9D5421F87FD for <rtcweb@ietfa.amsl.com>; Wed, 27 Feb 2013 12:23:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.252
X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VT1iQlCiqFRM for <rtcweb@ietfa.amsl.com>; Wed, 27 Feb 2013 12:23:18 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id DBD6821F85AF for <rtcweb@ietf.org>; Wed, 27 Feb 2013 12:23:17 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-4c-512e6b34038b
Received: from ESESSHC007.ericsson.se (Unknown_Domain []) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9E.BF.32353.43B6E215; Wed, 27 Feb 2013 21:23:16 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([]) by ESESSHC007.ericsson.se ([]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 21:23:16 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: JSEP-03: O/A state machine and trickle ICE with forking
Thread-Index: Ac4VKEWZ4cYZzPT+TXSns1oyaegaDg==
Date: Wed, 27 Feb 2013 20:23:16 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B10B6DE@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvja5Jtl6gwdEZlhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49CS62wF3/grTvziamA8ztPFyMkhIWAisW/WfWYIW0ziwr31 bF2MXBxCAocYJTb/+8UO4SxmlPj87SKQw8HBJmAh0f1PG6RBREBd4vLDC+wgtrCAg8TDe8+Z IOKuEvvXbGCHsPUkLl+9zQZiswioSuz5s4cZZAyvgLfE82O6IGFGoL3fT60Ba2UWEJe49WQ+ E8Q9AhJL9pyHuk1U4uXjf6wQtqLEx1f7GCHqdSQW7P7EBmFrSyxb+BqsnldAUOLkzCcsExiF ZyEZOwtJyywkLbOQtCxgZFnFyJ6bmJmTXm6+iREYwge3/DbYwbjpvtghRmkOFiVx3nDXCwFC AumJJanZqakFqUXxRaU5qcWHGJk4OKUaGLUmPrd3N/14p6P9uspuB2aBk0ZramdsZJ9oJO73 MuzPRfYPm6MNtFgt/tTf+RXk2LbgMYeVjKnAt101U5acWBojaXT/RuMktiaGw5b/ZfZ0tyuc UErN82UOmR7wtm3Vlp1loU3lsyr3fJWfqen0anOs5aYlBQpFf5zSXM5oGh9Q/S57xZHzgxJL cUaioRZzUXEiANaW9nwvAgAA
Subject: [rtcweb] JSEP-03: O/A state machine and trickle ICE with forking
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 27 Feb 2013 20:23:22 -0000


A could of questions on jsep-03, related to the O/A state machine, and the usage of trickle ICE with forking:

Q_OA_1: As I have commented earlier, the state machine does not support setting of remote offer when a remote pranswer has been set. A JS SIP app may e.g. receive an SDP answer in a reliable 18x response, call setPranswer, and then receive an UPDATE on the same leg with a new offer.

Q_OA_2: The text in section 4.2.3 says:

   "A description used as a "pranswer" may be applied as a response to an "offer", or an update to a previously sent "answer"."

I don't understand the "update to a previously sent answer" part. As the previously sent "answer" has freed any resources that are no longer needed, is a subsequent "preanswer" supposed to un-free those? Also, the state machine doesn't seem to support it, and there is text saying that once "answer" has been set, no more "answer"/"pranswer" can be set for that O/A transaction.


Assume the JS APP receives an SDP answer from remote entity A, and provides it to the browser as a pranswer. Then the JS APP receives an SDP answer from remote entity B, and provides it to the browser as a pranswer.

Then, the JS APP receives trickle ICE candidates from both entities A and B. What will happen to the trickle ICE candidates from remote entity A? The same question applies if the browser receives peer reflexive candidates from A. 

The draft says that trickle ICE candidates will be provided to the ICE Agent, that will then perform connectivity checks etc. But, does that mean that the ICE Agent will perform connectivity checks with both A and B.

This could of course be handled by always creating separate PeerConnections (and hence separate ICE agents) for A and B, even in the case of serial forking.

But, in any case I think the draft also needs to describe the ICE impacts of forking, because currently I don't think there is any text.