[Standards] XEP-0371 (Jingle ICE): update RFC 5245 -> RFC 8445
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
>> > 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 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
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...
More information about the Standards