I've noticed in my ICE tests that it's quite common for a peer to receive multiple Binding Requests for the same STUN transaction as a result of STUN retransmissions. 

While this is to be expected, the processing of the request specified in ICE 18 section 7.2.1.4 "Triggered Checks" results in adding precisely the same candidate pair to the triggered check queue multiple times, resulting in multiple subsequent identical triggered checks and subsequent work.  Is this the expected behavior, or am I missing something?  While it doesn't seem the above will break anything, it doesn't appear optimal either. 

Should the triggered check queue filter duplicates?  Should the STUN server side in ICE ignore Binding Requests with transaction IDs it has already processed (clearly still sending Binding Responses, just not forwarding the request to the ICE procedures)?  I'd assume the latter, but it seems I must be missing something in one of the specs if this is the case.

This is assuming the ICE STUN server side just reprocesses each Binding Request and recomputes the Binding Response each time since the Binding method is idempotent, as specified in draft-ietf-behave-rfc3489bis-10 section 7.3.1 "Processing a Request."

Thanks very much.

-Adam Fisk

Apologies for the comments so late in the game on the ICE drafts, but there appears to be a minor error in the nominating of pairs on controlled agents.

Section 7.1.2.2.4 on performing STUN client connectivity checks reads:

"If the agent is the controlled agent, the response may result in the valid pair having its nominated flag set. See section 7.2.1.5 for the procedure."
    -- http://tools.ietf.org/html/draft-ietf-mmusic-ice-18#section-7.1.2.2.4

7.2.1.5 then reads:

"If the Binding Request received by the agent had the USE-CANDIDATE attribute set, and the agent is in the controlled role, the agent looks at the state of the pair computed in Section 7.2.1.4:" 
    -- http://tools.ietf.org/html/draft-ietf-mmusic-ice-18#section-7.2.1.5

Shouldn't the last part of 7.2.1.5 at least read: "the agent looks at the state of the pair computed in Section 7.2.1.4 or in Section 7.1.2.2.4:"?  Otherwise, you'd just immediately ignore then whole of section 7.2.1.5 when processing pairs computed from section 7.1.2.2.4.

That's it for the "error" -- almost more a nit really.  Digging a little deeper, though, it seems to me that the nomination decision for the controlled agent in 7.1.2.2.4 should be really simple and should not have to reference section 7.2.1.5 at all.  Basically, if the pair received USE-CANDIDATE in the past, it should be nominated.  This is because the pair has just reached the successful state when we get to section 7.1.2.2.4, so all we need to know is whether or not we've received USE-CANDIDATE yet or not. 

Does that make sense?  I think referencing 7.2.1.5 makes it seem like a more complicated decision than it is, is much harder to understand, and breaks up the document flow.  Those issues aside, though, it seems like the opening of 7.2.1.5 should at the very least acknowledge that the pair could have also come from 7.1.2.2.4.

Again, I hate to bring this up so late in the game, but I only just noticed it.

Thanks.

-Adam