<div dir="ltr"><div dir="ltr"><br></div><br><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"<br>
>     transport-info<br>
>     in response, but which one should it pair it with?<br>
> <br>
> <br>
> according to ufrag.<br>
> <br>
> so one end sends (ep1) restart, the other end (ep2) receives it, sends back<br>
> iq result and assuming it has already lots ready-to-use candidates it sends<br>
> transport-info back with new ep1/ep2 ufrag combination according to RFC<br>
> (new local generated and one from ep1 transport-info message).<br>
> The ep1 side by this time already sent another "restart", so ufrag is already<br>
> different. On receive transport-info from ep2, ep1 checks ep1 part of ufrag<br>
>  and sees it doesn't match with anything. So it abandons the transport-info<br>
> message from ep2 just sending back iq result.<br>
> Eventually ep2 will receive second restart message with the updated ufrag,<br>
> so ep2 will abandon previous restart procedure and migrate to the new one.<br>
> ep2 will send back new transport-info with the new ufrag and after all it will<br>
> be recognized by ep1.<br>
<br>
But the two endpoints' ufrags are unrelated, and generated randomly.  How<br>
does seeing the remote ufrag help me associate it with one of my a local<br>
ones?<br></blockquote><div><br></div><div>Sorry, you are right. I confused with auth in STUN binding requests. Let me think</div><div>about it. I'll update the thread when have something in mind.<br></div><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 also not sure how well this would work with backward compatibility. <br>
>     Are<br>
>     you assuming entirely separate handling for namespace ice:1 from namespace<br>
>     ice:0?<br>
> <br>
> <br>
> Oh well. That's something more complicated. According to Philipp Hancke we<br>
> should not worry about backward compatibility but should worry about <br>
> compatibility with other software which might not support the new RFC. <br>
> In fact I didn't get this idea initially but it make more sense for me now.<br>
> <br>
> So there is a couple of points to mention:<br>
> 1) We need compatibility with browsers since they have the best and<br>
>     the simplest support for webrtc. So easy to write a client supporting<br>
> Jingle ICE.<br>
>     Therefore old RFC5245 has to be supported somehow since some browsers<br>
>     lack support for RFC 8445.<br>
>     RFC 8445 describes "ice2" option for this.<br>
<br>
Browsers, of course, are doing JSEP which is SDP offer/answer, so the<br>
translation layer from Jingle still has to handle the transactioning.<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>