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
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.
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
|