[Standards] XEP-0371 (Jingle ICE): update RFC 5245 -> RFC 8445

Sergey Ilinykh 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
> "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
> 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...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200320/744af14d/attachment.html>


More information about the Standards mailing list