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 <len...@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-unsubscr...@xmpp.org > > _______________________________________________ > > -- > Jonathan Lennox > len...@cs.columbia.edu > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ -- Jonathan Lennox len...@cs.columbia.edu _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
