<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"><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"<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.</div></div></div></blockquote><div><br></div><div>Let's make it more transactional then. Basically that's what <iq type="result|error"></div><div>designed for.</div><div>The idea is to drop incoming transport-info messages if they are received before</div><div>local session start/restart is confirmed with iq result by the other party.</div><div>The other party then can resend these candidates again (RFC allows it).</div><div><br></div></div></div>