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

Christer Holmberg <> Thu, 28 February 2013 06:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0396C21F8B8D for <>; Wed, 27 Feb 2013 22:57:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hhQr8yJOnP42 for <>; Wed, 27 Feb 2013 22:57:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id F321421F8B88 for <>; Wed, 27 Feb 2013 22:57:47 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-f1-512effea8221
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 3B.6B.10459.AEFFE215; Thu, 28 Feb 2013 07:57:46 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Thu, 28 Feb 2013 07:57:46 +0100
From: Christer Holmberg <>
To: Justin Uberti <>
Thread-Topic: [rtcweb] JSEP-03: O/A state machine and trickle ICE with forking
Thread-Index: Ac4VKEWZ4cYZzPT+TXSns1oyaegaDgAGp8mAAA6+H/A=
Date: Thu, 28 Feb 2013 06:57:45 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvje6r/3qBBvu6LS22ThWyWPuvnd2B yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlvDx9hr3gk37Fn3WJDYxX9LoYOTkkBEwkvryd wAZhi0lcuLceyObiEBI4xCjx4uAbJghnMaPE1IcvgBwODjYBC4nuf9ogDSICahIPZ+1iBbGZ BdQl7iw+xw5iCwv4Stw8vJYJoiZA4kTLf1YI20ridecDsBoWAVWJ5+/XgS3mFfCWWPZzOdTi SYwSi9/uAWvgFAiU+Ll/OQuIzQh03fdTa5gglolL3HoynwniagGJJXvOM0PYohIvH/9jhbAV Ja5OXw52M7OApsT6XfoQrYoSU7ofskPsFZQ4OfMJywRGsVlIps5C6JiFpGMWko4FjCyrGNlz EzNz0ssNNzECY+Pglt+6OxhPnRM5xCjNwaIkzhvmeiFASCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA2O70nzjIp21OrL37L4u3VWrPu/v4ZscJ7boWOZGbzJ4tSz/c5bWxQPfRQo3XWt9FjK9 4P4CLfcDExb0f5YXOuP58P07n3MXDD+mti/8E3pQKj3mtP90sdCmmxbNpTd/BPk9f6J111CG 4ebGffaTvhoLzbA5W/tg0U6mKylTORcl8ouq+LkqHipQYinOSDTUYi4qTgQAjT5d4lsCAAA=
Cc: "" <>
Subject: Re: [rtcweb] JSEP-03: O/A state machine and trickle ICE with forking
X-Mailman-Version: 2.1.12
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: Thu, 28 Feb 2013 06:57:51 -0000

Hi Justin,

Thanks for your response!

Comments inline, with an additional state machine question (Q_OA_3).


>> 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.
> Section 3.5.2, paragraph 2, attempts to provide a workaround for this issue.  

Section 3.5.2 talks about parallel forking, and how it can be solved by creating a new PC, and then send an UPDATE to provide the new PC information to the remote entity.

But, my issues is when the remote entity sends an UPDATE, with a new offer. It's not even related to forking. See my example below:

BROWSER                         JS APP                                    REMOTE ENITTY

    ------ create offer ----------
                                             -------- SDP Offer 1----------------->
                                            <------- SDP Answer 1 ----------------
    ------ set pranswer ---------
                                            <------- SDP Offer 2 -------------------
    ------ ??? ----------------------


>>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.
> This should have said "previously sent "pranswer"", like the paragraph that follows it.  



Q_OA_3: When a pranswer has been set, the state machine does not allow creating a new local offer.

So, if the JS APP needs to send a new offer, e.g. because of BUNDLE, it would have to set answer first. But, that would again more or less prevent serial forking (at least on the same PeerConnection).


>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.
>Thanks for pointing this out. I discussed this at the IETF 83.5 interim, but forgot to put this into the draft. The answer is that when B's pranswer is applied, 
>and the received ICE credentials are different than the previous answer (as they would be in this case), the existing candidates are discarded.

But, A doesn't know that, so it may keep sending STUN requests, trickle ICE candidates etc.

But, assume that the JS APP discards whatever comes from A. Then, if the session will eventually be established with A (i.e. the SDP answer from A is provided to the browser as "answer"), A needs to be informed to re-send all trickle ICE candidates etc again,  because the previously sent ones were discarded (since the JS APP provided the SDP answer from B to the browser)...


I actually think that PeerConnection cloning would solve *ALL* of the issues above: there would be no need for pranswer, which means that the JSEP O/A procedures would be fully aligned with RFC 3264. And, ICE procedures could take place with multiple remote entities simultaneously.