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

Jonathan Lennox lennox at cs.columbia.edu
Thu Mar 19 18:13:46 UTC 2020


On Wednesday, March 18 2020, "Sergey Ilinykh" wrote to "XMPP Standards" saying:

> 
>     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?

>     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


More information about the Standards mailing list