So, the idea was to make a few major changes:

1. when an agent receives a stun request with a source IP/port which
doesn't match the candidate, ice-09 has the agent do one of two things.
If the address/port is totally new, the agent creates a new peer derived
candidate. If it matches a different IP/port, it feeds a state update
into that candidate pair. In both cases, the actual pair on which the
request was received is invalidated. Instead of doing all of this, the
idea is to simply update the remote IP address/port of the pair on which
the request was received. This has the same net result as the existing
ice-09 algorithm but is way simpler to specify. It was reassuring to
hear from Tim Moore that this is how his implementation actually behaves.

2. the draft has a lot of confusion around transport address pairs vs.
candidate pairs. I'm going to ditch what is current called candidate
pair, and change the name of what is currently called transport address
pair to candidate pair, and structure everything around that. This
should boot out a bunch of terminology and complexity.

3. I think I can further unify tcp and udp processing

The first of these three is the real big one. That should eliminate the
entire section on peer derived candidates, how you compute and link
them, computing these derived candidate IDs, and so on. It will also
simplify the state machine, removing this whole miss/match bit that was
recently added in.

Now, the tradeoff that the group has to make is this.

Philip has described, in his mail to the group here:
http://www1.ietf.org/mail-archive/web/mmusic/current/msg04314.html

that there is a case where a peer-derived candidate would need to be
paired with a different candidate from the one from which it was
derived. With the simplification I propose, such a pairing could only be
done via an explicit re-invite. I have argued that the simplification is
worth the additional latency cost of a re-invite for covering what looks
like a corner case. I think there was general consensus in the group
that this tradeoff (simplifying the algorithm at the expense of
requiring a re-invite in this corner case), was worth it.


HTH,
Jonathan R.