> > > 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. > > > I'm also not sure how well this would work with backward > compatibility. > > Are > > you assuming entirely separate handling for namespace ice:1 from > namespace > > ice:0? > > > > > > Oh well. That's something more complicated. According to Philipp Hancke > we > > should not worry about backward compatibility but should worry about > > compatibility with other software which might not support the new RFC. > > In fact I didn't get this idea initially but it make more sense for me > now. > > > > So there is a couple of points to mention: > > 1) We need compatibility with browsers since they have the best and > > the simplest support for webrtc. So easy to write a client supporting > > Jingle ICE. > > Therefore old RFC5245 has to be supported somehow since some browsers > > lack support for RFC 8445. > > RFC 8445 describes "ice2" option for this. > > Browsers, of course, are doing JSEP which is SDP offer/answer, so the > translation layer from Jingle still has to handle the transactioning. > > -- > Jonathan Lennox > len...@cs.columbia.edu > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
