Re: [MMUSIC] Faster ICE by role reversal?

> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard
> Aboba
> Sent: Sunday, November 09, 2014 7:41 AM
> To: Emil Ivov
> Cc: Jonathan Lennox; Ari Keränen; mmusic; Dan Wing (dwing)
> Subject: Re: [MMUSIC] Faster ICE by role reversal?
> 
> On Nov 8, 2014, at 3:50 PM, Emil Ivov <emcho@jitsi.org> wrote:
> >>
> >
> > Continuous nomination has at least two serious problems:
> >
> > a) we lose the possibility to clearly detect failures and we need to resort to
> magic timers
> > b) it is no longer clear when unused candidates (srflx and relay) can be
> released.
> 
> [BA] Justin's proposal does provide a way to know when unused candidates
> can be released. The problem is that those released candidates might
> actually be needed after a new interface comes up.
> 
> For example, say two peers are initially on the same WiFi LAN so that host
> candidate checks work.  As a result, there is no reason for either peer to keep
> unused relay candidates. Media is flowing, then one peer senses WiFi signal
> strength decreasing so it brings up an LTE interface. While it can trickle the
> new host, srflx and relay candidates, the other peer no longer has
> functioning relay candidates so the checks could fail.  While the peer could
> have kept its LTE interface hot all along and used it to ensure that the other
> peer kept its relay candidates that would have a high cost in terms of energy
> usage.

Alternatively unused relayed candidate could be maintained on the Wifi interface and after switch-over to LTE use TURN Mobility (https://tools.ietf.org/html/draft-wing-tram-turn-mobility-02) to retain the allocations. The overhead is that unused candidate pair with relayed candidate has to be maintained with connectivity checks for fail-over.

-Tiru

> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic