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

On Wed, Feb 27, 2013 at 12:23 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

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

Section 3.5.2, paragraph 2, attempts to provide a workaround for this
issue.

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

>
> Regards,
>
> Christer
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>