<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"><br>
I'm still not sure if it solves the problem if one end sends two "restart"<br>
transport-infos in rapid succession.  It'll receive a "restart" transport-info<br>
in response, but which one should it pair it with?<br></blockquote><div><br></div><div>according to ufrag.</div><div><br></div><div>so one end sends (ep1) restart, the other end (ep2) receives it, sends back</div><div>iq result and assuming it has already lots ready-to-use candidates it sends</div><div>transport-info back with new ep1/ep2 ufrag combination according to RFC</div><div>(new local generated and one from ep1 transport-info message).</div><div>The ep1 side by this time already sent another "restart", so ufrag is already</div><div>different. On receive transport-info from ep2, ep1 checks ep1 part of ufrag</div><div> and sees it doesn't match with anything. So it abandons the transport-info</div><div>message from ep2 just sending back iq result.</div><div>Eventually ep2 will receive second restart message with the updated ufrag,</div><div>so ep2 will abandon previous restart procedure and migrate to the new one.</div><div>ep2 will send back new transport-info with the new ufrag and after all it will</div><div>be recognized by ep1.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm also not sure how well this would work with backward compatibility.  Are<br>
you assuming entirely separate handling for namespace ice:1 from namespace<br>
ice:0?<br></blockquote><div><br></div><div>Oh well. That's something more complicated. According to Philipp Hancke we</div><div>should not worry about backward compatibility but should worry about </div><div>compatibility with other software which might not support the new RFC. </div><div>In fact I didn't get this idea initially but it make more sense for me now.</div><div><br></div><div>So there is a couple of points to mention:</div><div>1) We need compatibility with browsers since they have the best and</div><div>    the simplest support for webrtc. So easy to write a client supporting Jingle ICE.</div><div>    Therefore old RFC5245 has to be supported somehow since some browsers</div><div>    lack support for RFC 8445.</div><div>    RFC 8445 describes "ice2" option for this.</div><div>2) XEP-0371 is not released and not wide-spread. So it's fine for the XEP </div><div>    to take changes without caring much about backward compatibility. So even</div><div>    the namespace change is probably not necessary. But here I'd like to understand</div><div>    what community thinks about this.</div><div> </div></div></div>