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

Justin Uberti <> Thu, 28 February 2013 22:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54BC921F8630 for <>; Thu, 28 Feb 2013 14:37:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.505
X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 46Zcf-bVhuvN for <>; Thu, 28 Feb 2013 14:37:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1638D21F8700 for <>; Thu, 28 Feb 2013 14:37:34 -0800 (PST)
Received: by with SMTP id 6so1893692qeb.28 for <>; Thu, 28 Feb 2013 14:37:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=2aE6Lr/ZxTELNu03Mo5I4BwA9UDcToqBtrlWbXbV9tY=; b=djmcLu5LH+ALbYJXbaC3joHQqpis9rUcYkvQ3o2qXP27wTZZyiVAMwBzpU9k9qZokz wNTyH10p8U0doYr1r81GBT417ZISod5G2zB6R62BGR08pt/yrR+/wofPsrfTKq6iXifL ailLHWtr8Em9zjWgY+gR3TCfQHm2S5wgGaNWbo1z17OR1DxJDSb8FZXG30HEI3uQSaqC y6vHXLmjow7y0NNLHrEuqbAQbIc5839YylVznseyRAcS4QWDU/B6OneOKHk6fUGbfB0U nSeOAYJRBo4nL1QUO/afymEoocKSBR0GimsD23fmpzyglGdTyN8ra3feVAe3Ii1jKqyU FO9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=2aE6Lr/ZxTELNu03Mo5I4BwA9UDcToqBtrlWbXbV9tY=; b=KTQK7g0AZ/M9FvnJHrNsTLQMiqE8xZpGKlqTph+scbHpFL8gry6PW7zML6hZn4f9kd sd1+wOq+HzRMtDmtbGRuQ622nuDatTaCgGhMbUpYX1hgee9mePUpxFlqPB9iiGNyiUTr QV/uWbTwHHYPE0TtRuNmdqcmr4TGZtvEf3ub7yI6w/D361yJ0WToF23mO9t2rWrBDZTN p9LXzJt644Y5HDR7yjmzu9Gx7zBEEP/Ksr6iHcNBMlWhLYDV66Z2TCuPeVnK+SxOvwbJ ZLec3BV5jLCTygJiBGIYcmgpm8zgGm7uc55A3KUOiVFELeYx3Xt4VKAfB9s+mbSGQ9Ng T5xA==
X-Received: by with SMTP id u14mr2866750qct.138.1362091054338; Thu, 28 Feb 2013 14:37:34 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 28 Feb 2013 14:37:14 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Justin Uberti <>
Date: Thu, 28 Feb 2013 14:37:14 -0800
Message-ID: <>
To: Christer Holmberg <>
Content-Type: multipart/alternative; boundary="00235452e6ec72680104d6d08984"
X-Gm-Message-State: ALoCoQlFrIDuBIqkrQWcegER5oKO1bz9vk/0IX93HctA9E1i3pJ+RkAH/g2Md5ZdsR0sA5P9hHbw/cwIAaQRAhojN2TJglIi6y2/slja4dcmmWDyQP+33QHLqSWmpfEL/fPQauPzJzkiP4b2hahKv9IO+caIN6RZtT7BlOZYwkDWCFaebim2aNYkltOw9dfTcZL7fCDqa9Ln
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 22:37:36 -0000

On Wed, Feb 27, 2013 at 10:57 PM, Christer Holmberg <> wrote:

> 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
>     ------ create offer ----------
>                                              -------- SDP Offer
> 1----------------->
>                                             <------- SDP Answer 1
> ----------------
>     ------ set pranswer ---------
>                                             <------- SDP Offer 2
> -------------------
>     ------ ??? ----------------------
> ------------------

Right. This is clearly a problem, but the reason it is a problem is because
the two sides don't agree on the state of the negotiation. In a forking
case, it would be handled via the mechanism I mentioned above. In a
non-forking case, this is not solvable even with cloning, because the two
sides are out of sync. The browser has to handle this case by rejecting 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.
> Ok.
> ------------------
> 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).

Can you explain the BUNDLE case you have in mind? The BUNDLE renegotiation
to a single port can't happen at this point in the negotiation, because the
caller may receive another answer that doesn't want to use BUNDLE.

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

The app should send a termination message to A when it accepts the pranswer
from B. Even if it didn'tm the STUN requests would be ignored by the impl,
and the ICE candidates would be ignored by the app, so I don't think there
is a problem.

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

The app can't keep the session alive simultaneously with both A and B. It
needs to pick one or the other. The last time this was discussed, this was
felt to be a reasonable solution. Perhaps this needs to be codified in the
JSEP draft.

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

I considered that in the past, but PRANSWER is not just for forking; it's
also useful in the non-forking case  to get media flowing as fast as
possible in a single O/A sequence.

The overall opinion of the WG was that PRANSWER solves the problem above
and provides a fairly good treatment of forking without introducing
significant complexity. Adding cloning would allow a more comprehensive
treatment of forking, but at the cost of significant additional complexity.
Also, I have yet to have any application builder ask me for cloning support.

> Regards,
> Christer