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

Sergey Ilinykh rion4ik at gmail.com
Tue Mar 17 21:48:01 UTC 2020


>
> 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?



>
> > пт, 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
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200318/22d8fe0b/attachment.html>


More information about the Standards mailing list