<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
An interface switches addresses, so you send transport-info with generation X.<br>
<br>
The interface switches addresses back, so you then send transport-info with<br>
generation X+1.<br>
<br>
You receive transport-info with generation Y.<br>
<br>
Should you pair the generation Y candidates with generation X, or with<br>
generation X+1?  If you choose differently than the remote endpoint did,<br>
connectivity checking will fail, because your ufrag and password values will<br>
be wrong.<br></blockquote><div><br></div><div>I see two issues here:</div><ol><li>How we differentiate a response to X+0 from ICE restart from remote if<br>ufrag is already forgotten for X+0 on the local side<br></li><li>How a client should handle transport-info message with unknown ufrag</li></ol><div><br></div><div>I'll update the PR with next changes:</div><div><br></div><div>1.a. ICE restart MUST include "restart" attribute in transport-info message</div><div>1.b. If both sides are trying to do ICE restart in the same time (transport-info with <br></div><div>       restart already sent by both sides) session initiator will send tie-break iq error.</div><div>2. transport-info message without "restart" attribute but with unknown ufrag has</div><div>    to be silently dropped right after iq result because it's hard to say where it's<br>    an error or some outdated data.<br></div><div><div><div><br></div><div>Does it solve the problem?<br></div></div></div><div>  <br></div></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> пт, 13 мар. 2020 г., 0:48 Jonathan Lennox <<a href="mailto:lennox@cs.columbia.edu" target="_blank">lennox@cs.columbia.edu</a>>:<br>
> <br>
>     One major comment:<br>
> <br>
>     1. There is (and has always been) a semantic hole in ICE restart with<br>
>     Jingle, because transport-info is a unilateral message, unlike SDP<br>
>     offer/answer which is transactional.<br>
> <br>
>     Specifically, there's no way for a Jingle endpoint to know for certain<br>
>     which<br>
>     generation of its local candidates should be matched with a set of<br>
>     candidates received in a transport-info message.<br>
> <br>
>     Perhaps some sort of remote-generation attribute is necessary for<br>
>     candidates<br>
>     sent in response to a peer's candidates?<br>
> <br>
>     On Friday, March 13 2020, "Sergey Ilinykh" wrote to "XMPP Standards"<br>
>     saying:<br>
> <br>
>     > <a href="https://github.com/xsf/xeps/pull/905" rel="noreferrer" target="_blank">https://github.com/xsf/xeps/pull/905</a><br>
>     ><br>
>     > PR Changes:<br>
>     ><br>
>     >  1. RFC 5245 is replaced with RFC 8445<br>
>     >  2. Aggressive nomination is not supported anymore<br>
>     >  3. remote-candidate is now MUST to mimic ICE SDP RFC<br>
>     >  4. Now remote-candidate has to be send for all components at once when<br>
>     ICE for<br>
>     >     media stream has completed<br>
>     >  5. Namespace version was updated because of incompatible changes<br>
>     >  6. Wrong reference to RFC 6455 was replaced with correct one: RFC 6544<br>
>     ><br>
>     > Let's review / discuss / fix / merge.<br>
>     ><br>
>     > Best Regards,<br>
>     > Sergey<br>
>     > _______________________________________________<br>
>     > Standards mailing list<br>
>     > Info: <a href="https://mail.jabber.org/mailman/listinfo/standards" rel="noreferrer" target="_blank">https://mail.jabber.org/mailman/listinfo/standards</a><br>
>     > Unsubscribe: <a href="mailto:Standards-unsubscribe@xmpp.org" target="_blank">Standards-unsubscribe@xmpp.org</a><br>
>     > _______________________________________________<br>
> <br>
>     --<br>
>     Jonathan Lennox<br>
>     <a href="mailto:lennox@cs.columbia.edu" target="_blank">lennox@cs.columbia.edu</a><br>
>     _______________________________________________<br>
>     Standards mailing list<br>
>     Info: <a href="https://mail.jabber.org/mailman/listinfo/standards" rel="noreferrer" target="_blank">https://mail.jabber.org/mailman/listinfo/standards</a><br>
>     Unsubscribe: <a href="mailto:Standards-unsubscribe@xmpp.org" target="_blank">Standards-unsubscribe@xmpp.org</a><br>
>     _______________________________________________<br>
> <br>
> _______________________________________________<br>
> Standards mailing list<br>
> Info: <a href="https://mail.jabber.org/mailman/listinfo/standards" rel="noreferrer" target="_blank">https://mail.jabber.org/mailman/listinfo/standards</a><br>
> Unsubscribe: <a href="mailto:Standards-unsubscribe@xmpp.org" target="_blank">Standards-unsubscribe@xmpp.org</a><br>
> _______________________________________________<br>
<br>
-- <br>
Jonathan Lennox<br>
<a href="mailto:lennox@cs.columbia.edu" target="_blank">lennox@cs.columbia.edu</a><br>
_______________________________________________<br>
Standards mailing list<br>
Info: <a href="https://mail.jabber.org/mailman/listinfo/standards" rel="noreferrer" target="_blank">https://mail.jabber.org/mailman/listinfo/standards</a><br>
Unsubscribe: <a href="mailto:Standards-unsubscribe@xmpp.org" target="_blank">Standards-unsubscribe@xmpp.org</a><br>
_______________________________________________<br>
</blockquote></div></div>