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

[Justin Uberti <[e-mail]>]

On Wed, Jul 30, 2014 at 3:01 PM, Martin Thomson <[e-mail]>
wrote:

> On 30 July 2014 14:48, Emil Ivov <[e-mail]> wrote:
> > 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?
>
> RFC 5764 says this:
>    A single DTLS-SRTP session only protects data carried over
>    a single UDP source and destination port pair.
>
> But I'll postulate that this is only because the alternative (a
> shifting substrate) was not yet conceived.  There is nothing in (D)TLS
> that requires anything of the underlying transport protocol,
> intentionally.  (c.f., tcpinc wg)
>
> Firefox code seems to be OK (at least superficially) with the idea
> that packets can arrive from anywhere.  However, I can see why some
> implementations might get sad if things shift around.
>
>
Agreed. I think unless there is some dependency on the lower layer protocol
specifics (which should be uncommon, if at all), the expectation should be
that ICE is a generic, dynamic packet transport (AKA shifting substrate).