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

Jonathan Lennox lennox at cs.columbia.edu
Wed Mar 18 13:20:45 UTC 2020


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

>     An interface switches addresses, so you send transport-info with generation
>     X.
> 
>     The interface switches addresses back, so you then send transport-info with
>     generation X+1.
> 
>     You receive transport-info with generation Y.
> 
>     Should you pair the generation Y candidates with generation X, or with
>     generation X+1?  If you choose differently than the remote endpoint did,
>     connectivity checking will fail, because your ufrag and password values
>     will
>     be wrong.
> 
> 
> I see two issues here:
> 
>  1. How we differentiate a response to X+0 from ICE restart from remote if
>     ufrag is already forgotten for X+0 on the local side
>  2. How a client should handle transport-info message with unknown ufrag
> 
> 
> I'll update the PR with next changes:
> 
> 1.a. ICE restart MUST include "restart" attribute in transport-info message
> 1.b. If both sides are trying to do ICE restart in the same time (transport-info with
>        restart already sent by both sides) session initiator will send tie-break iq error.
> 2. transport-info message without "restart" attribute but with unknown ufrag has
>     to be silently dropped right after iq result because it's hard to say where it's
>     an error or some outdated data.
> 
> Does it solve the problem?

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?

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?


-- 
Jonathan Lennox
lennox at cs.columbia.edu


More information about the Standards mailing list