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

Sergey Ilinykh rion4ik at gmail.com
Wed Mar 18 14:15:37 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
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
be recognized by ep1.

> 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.
2) XEP-0371 is not released and not wide-spread. So it's fine for the XEP
    to take changes without caring much about backward compatibility. So
    the namespace change is probably not necessary. But here I'd like to
    what community thinks about this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200318/1983e4d8/attachment.html>

More information about the Standards mailing list