Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)

[Iñaki Baz Castillo <[e-mail]>]

2014-07-30 23:48 GMT+02:00 Emil Ivov <[e-mail]>rg>:
> The main problem with the aggressive version of regular nomination is stuff
> like DTLS/SRTP (that's actually already kind of an issue with today's
> aggressive nomination).
>
> When it's RTP you don't care where you get it from as long as you do. If
> it's a DTLS client halo then what do you do exactly?
>
> Can the controlling agent simply respond on a different valid pair than the
> one on which it received it? (This is what Chrome currently does but its
> frowned upon by the DTLS/SRTP draft which binds the context to a specific
> address:port). Does the controlled agent need to resend it on the new pair
> after it gets the USE-CANDIDATE?
>
> What about other protocols? Do they all need to say how they are to be used
> with ICE? I hope not and I hope we can find a generic approach for all of
> them. For example: all early non-acknowledged reliable data has to be resent
> on the nominated pair. This would imply a DTLS neg restart as Martin
> suggested.


+1

IMHO we need a way for ICE (all the flavors) to fully determine which
is the *only* pair in which media or DTLS can be sent, so a peer can
safely discard any RTP or DTLS packet coming from a source address
that does not match the selected/paired/confirmed address tuple.

And IMHO we also need that a ICE-Lite server implementation does not
need to keep a list of valid pairs or source addresses but just one
(chosen via ICE by the controlling peer).

-- 
Iñaki Baz Castillo
<[e-mail]>