[Standards] XEP-0371 (Jingle ICE): update RFC 5245 -> RFC 8445
rion4ik at gmail.com
Thu Mar 19 21:07:01 UTC 2020
> > I'm still not sure if it solves the problem if one end sends two
> > 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
> > iq result and assuming it has already lots ready-to-use candidates it
> > 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
> > different. On receive transport-info from ep2, ep1 checks ep1 part of
> > and sees it doesn't match with anything. So it abandons the
> > message from ep2 just sending back iq result.
> > Eventually ep2 will receive second restart message with the updated
> > so ep2 will abandon previous restart procedure and migrate to the new
> > 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
Sorry, you are right. I confused with auth in STUN binding requests. Let me
about it. I'll update the thread when have something in mind.
> > I'm also not sure how well this would work with backward
> > Are
> > you assuming entirely separate handling for namespace ice:1 from
> > ice:0?
> > Oh well. That's something more complicated. According to Philipp Hancke
> > 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
> > 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
> lennox at cs.columbia.edu
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards