> > > >> > I'm still not sure if it solves the problem if one end sends two >> "restart" >> > transport-infos in rapid succession. It'll receive a "restart" >> > transport-info >> > in response, but which one should it pair it with? >> > >> > >> > according to ufrag. >> > >> > so one end sends (ep1) restart, the other end (ep2) receives it, sends >> back >> > iq result and assuming it has already lots ready-to-use candidates it >> sends >> > transport-info back with new ep1/ep2 ufrag combination according to RFC >> > (new local generated and one from ep1 transport-info message). >> > The ep1 side by this time already sent another "restart", so ufrag is >> already >> > different. On receive transport-info from ep2, ep1 checks ep1 part of >> ufrag >> > and sees it doesn't match with anything. So it abandons the >> transport-info >> > message from ep2 just sending back iq result. >> > Eventually ep2 will receive second restart message with the updated >> ufrag, >> > so ep2 will abandon previous restart procedure and migrate to the new >> one. >> > ep2 will send back new transport-info with the new ufrag and after all >> it will >> > be recognized by ep1. >> >> But the two endpoints' ufrags are unrelated, and generated randomly. How >> does seeing the remote ufrag help me associate it with one of my a local >> ones? >> > > Sorry, you are right. I confused with auth in STUN binding requests. Let > me think > about it. I'll update the thread when have something in mind. >
Let's make it more transactional then. Basically that's what <iq type="result|error"> designed for. The idea is to drop incoming transport-info messages if they are received before local session start/restart is confirmed with iq result by the other party. The other party then can resend these candidates again (RFC allows it).
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
