Subject: [MMUSIC] draft-ietf-mmusic-ice-19 question

From: Jim Kleck <[email-masked]>
Date: Fri, 28 Aug 2009 10:46:36 -0700

In looking at draft-ietf-mmusic-ice-19, we have run into a
point of confusion. Our understanding of the draft is that all
local candidates for a particular component for a mediastream
should use the same host IP Addr & port for gathering candidates
and for sending and receiving connectivity checks: section  4.1.1.2
says:

The agent next pairs each host candidate with the STUN or TURN server
    with which it is configured or has discovered by some means.

and:

The result is a set of pairs of host candidates with STUN or TURN
    servers.

However, 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).

If all local candidates for a component have the same host IPaddr:port,
how can the local agent determine which transport address the remote
agent sent the request to (which I assume is the first transport address
referenced in the 7.2.1.4 quote from the draft)? I dont see anything in
the STUN Binding Request pkt which identifies the target candidate,
nor does the IPaddr:port the request was received on identify the target
candidate. Or does the local agent actually need a different host IPaddr
and port for each local transport address?

James Kleck
8x8, Inc.

---

From: Jim Kleck <[email-masked]>
Date: Mon, 31 Aug 2009 11:02:50 -0700

Julian,

That would make sense for processing a Binding Response, since the

local agent originated the Binding Request and thus set the STUN

transaction id in the first place. However, our problem is in processing

a recvd Binding Request, which the remote agent originated. That

is the subject of section 7.2.1.4.

JimK

Julian C. wrote:

By
the use of the stun transaction ID that you'd use for retransmission.
If you don't have one then it didn't come from your stun/turn server.

Sent from my iPhone

On Aug 28, 2009, at 10:46 AM, Jim Kleck <[email-masked]> wrote:

should use the same host IP Addr & port for gathering
candidates

and for sending and receiving connectivity checks: section
4.1.1.2

says:

The agent next pairs each host candidate with the STUN or
TURN server

with which it is configured or has discovered by some
means.

and:

The result is a set of pairs of host candidates with STUN or
TURN

servers.

However, section 7.2.1.4 (which deals with the ICE agent
processing

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).

If all local candidates for a component have the same host
IPaddr:port,

how can the local agent determine which transport address the
remote

agent sent the request to (which I assume is the first
transport address

referenced in the 7.2.1.4 quote from the draft)? I dont see
anything in

the STUN Binding Request pkt which identifies the target
candidate,

nor does the IPaddr:port the request was received on identify
the target

candidate. Or does the local agent actually need a different
host IPaddr

James Kleck

8x8, Inc.

_______________________________________________

mmusic mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/mmusic