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

Jonathan Lennox lennox at cs.columbia.edu
Mon Mar 16 15:07:04 UTC 2020


On Saturday, March 14 2020, "Sergey Ilinykh" wrote to "XMPP Standards" saying:

> Hi Jonathan, 
> 
> Ufrag+pwd are changed on ICE restart and they are sent with each transport-info
> message. The params perfectly determine the generation. And also special
> "generation" attribute is sent with each candidate. So I don't understand what
> you mean. 

The problem is matching your local endpoint's generations to the remote
endpoint's.

Consider the following:

Your local endpoint's interfaces are flapping between two networks, so your
client needs to send ICE restart a lot.

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.

Now, maybe the answer to this problem is that you shouldn't have sent
generation X+1 yet -- but nothing in the spec says that, or tells you when
it's safe to send the next generation.

In SIP offer/answer, a new INVITE with the "generation X+1" candidates can't
be sent until a final response comes in to the offer with the generation X
candidates, and the answer with generation Y will have transaction
information indicating which offer it is in response to.  However,
transport-info is unilateral, and so doesn't have either of these protocol
state semantics.

(I discovered this problem when torture testing my ICE restart logic, by
forcing my client to do an ICE restart once a second.)


> пт, 13 мар. 2020 г., 0:48 Jonathan Lennox <lennox at cs.columbia.edu>:
> 
>     One major comment:
> 
>     1. There is (and has always been) a semantic hole in ICE restart with
>     Jingle, because transport-info is a unilateral message, unlike SDP
>     offer/answer which is transactional.
> 
>     Specifically, there's no way for a Jingle endpoint to know for certain
>     which
>     generation of its local candidates should be matched with a set of
>     candidates received in a transport-info message.
> 
>     Perhaps some sort of remote-generation attribute is necessary for
>     candidates
>     sent in response to a peer's candidates?
> 
>     On Friday, March 13 2020, "Sergey Ilinykh" wrote to "XMPP Standards"
>     saying:
> 
>     > https://github.com/xsf/xeps/pull/905
>     >
>     > PR Changes:
>     >
>     >  1. RFC 5245 is replaced with RFC 8445
>     >  2. Aggressive nomination is not supported anymore
>     >  3. remote-candidate is now MUST to mimic ICE SDP RFC
>     >  4. Now remote-candidate has to be send for all components at once when
>     ICE for
>     >     media stream has completed
>     >  5. Namespace version was updated because of incompatible changes
>     >  6. Wrong reference to RFC 6455 was replaced with correct one: RFC 6544
>     >
>     > Let's review / discuss / fix / merge.
>     >
>     > Best Regards,
>     > Sergey
>     > _______________________________________________
>     > Standards mailing list
>     > Info: https://mail.jabber.org/mailman/listinfo/standards
>     > Unsubscribe: Standards-unsubscribe at xmpp.org
>     > _______________________________________________
> 
>     --
>     Jonathan Lennox
>     lennox at cs.columbia.edu
>     _______________________________________________
>     Standards mailing list
>     Info: https://mail.jabber.org/mailman/listinfo/standards
>     Unsubscribe: Standards-unsubscribe at xmpp.org
>     _______________________________________________
> 
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

-- 
Jonathan Lennox
lennox at cs.columbia.edu


More information about the Standards mailing list