Re: [MMUSIC] Next steps on "passive-aggressive" nomination

[Roman Shpount <[e-mail]>]

On Fri, Jul 17, 2015 at 9:00 PM, Justin Uberti <[e-mail]> wrote:

> At IETF 92, we discussed passive-aggressive nomination, which allows
> implementations to
> a) send media as soon as a single check succeeds (like aggressive nom)
> b) give the controlling side full discretion in terms of which pair to
> select (like regular nom)
> c) allow the controlled side to know when nomination is complete (like
> regular nom)
>
> The conclusion from IETF 92
> <http://www.ietf.org/proceedings/92/minutes/minutes-92-mmusic#h.vqmjfv9a7r6k>
> was that this looked promising (although we *might* want to have some SDP
> signaling to control when it is used). We also agreed to solicit alternate
> proposals and decide at IETF 93 which proposal we wanted to proceed with.
> On that topic, I am currently aware of one competing proposal, namely this
> document <https://tools.ietf.org/html/draft-jennings-mmusic-ice-fix-00> from
> Cullen.
>
> I have asked for agenda time to discuss the comments that came up at IETF
> 92, namely:
> - potential interoperability concerns with endpoints that only do regular
> nomination (may drop media that arrives before USE-CANDIDATE)
> - potential interoperability concerns with endpoints that only do
> aggressive nomination (may ignore selected pair indicated in USE-CANDIDATE;
> may drop media before USE-CANDIDATE; may not send media until USE-CANDIDATE)
> - do we need some way to negotiate use of passive-aggressive nomination,
> to prevent the above problems
> - do we need some way to suppress use of aggressive nomination, to allow
> us to avoid needing to support regular, passive-aggressive, and aggressive
> nomination in future clients
>
> Are there any other concerns that I missed?
>

I am not sure if it was brought up at IETF 92, but there is also ability to
discover asymmetric paths using ICE.
_____________
Roman Shpount