Subject: [MMUSIC] ICE draft 19

From: Jim Kleck <[email-masked]>
Date: Fri, 4 Sep 2009 16:47:48 -0700

Hi,

I have a better understanding now of our confusion with the draft.
Specifically, section 7.2.1.4 (which deals with the ICE agent
processing a received Binding Request) states:

Next, the agent constructs a pair whose local
candidate is equal to the transport address on which the
STUN request was received, and a remote candidate equal
to the source transport address where the request came
from (which may be peer-reflexive remote candidate that was
just learned).

How does the local ICE agent identify the transport address on which
the STUN request was received? For example, say the local agent has the
CONTROLLED role and that there are 3 remote candidates (host, srflx,
and relay) and 3 local candidates (again host, srflx and relay), and
that the local agent is behind a symmetric NAT. The local agent will
build 6 check list pairs:

1- local host candidate and remote host candidate

2- local host candidate and remote srflx candidate

3- local host candidate and remote relay candidate

4- local relay candidate and remote host candidate

5- local relay candidate and remote srflx candidate

6- local relay candidate and remote relay candidate

(having pruned the check list pairs containing the local srflx
candidate).

Say that the remote agent responds successfully to pair #s 1 and 2
(i.e. it sends the responses to the mapped addresses for these two
requests), thus the local agent will build local prflx candidates with
the mapped addresses as the transport addresses for these and build
valid pairs referring to these new prflx candidates. Now the remote
agent starts nominating (it is using REGULAR NOMINATION), and sends a
new STUN Binding Request with USE-CANDIDATE to the mapped address for
pair #2. This Binding request passes through the NAT and is received by
the local agent. How can the local agent know that this nominating
request came for pair #2 vs. pair #1? The NAT would forward either one
to the same base address, and in passing through the NAT the original
address to which the remote agent sent the request is lost.
Furthermore, the request itself does not contain any information which
the local agent could use to determine which of pair #2 or #1 the
request was sent for. And without this information, the local agent
does not know which pair is nominated (and even earlier in the process,
before the remote agent starts nominating, on receiving a Binding
Request without USE-CANDIDATE the local agent would not know which
local candidate the request came for).

JimK

8x8, Inc.