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

Sergey Ilinykh rion4ik at gmail.com
Fri Mar 20 21:45:07 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.

Let's make it more transactional then. Basically that's what <iq
designed for.
The idea is to drop incoming transport-info messages if they are received
local session start/restart is confirmed with iq result by the other party.
The other party then can resend these candidates again (RFC allows it).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200321/02031e95/attachment.html>

More information about the Standards mailing list