Subject: RE: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues]

From: "Kevin Johns" <[email-masked]>
Date: Thu, 19 Oct 2006 09:39:14 -0600

Dan,

I had the call flow backward in my head, so I don't think this is an
issue as I originally thought. Here is what I was thinking:

UE A -> INVITE -> UE B; The INVITE contains a set of candidate addresses
for UE A
Once UE B gathers its candidates, it can being sending connectivity
checks in parallel with sending the 18X

The First set of STUN Requests will fail since the NAT for UE A will
block them as UE A has yet to transmit any STUN requests (it is still
waiting for the 18x or has received it and is still building its list)
and establish a binding. Depending on how long it takes UE A to build
its list and send its checks, UE B may retransmit the 18x having not
received any STUN requests.

While the first set of STUN checks will fail for UE B, I do not see that
this will result in a re-transmission of the 18x.

Kevin

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Wednesday, October 18, 2006 6:39 PM
To: Kevin Johns
Cc: 'Jonathan Rosenberg'; 'IETF MMUSIC WG'
Subject: ICE's reliable 18x [was RE: [MMUSIC] Remaining ICE open issues]

> Holmberg-6: Reliable provisionals
> Status: Christer argues that the stuff in ICE about resending the 18x 
> until a stun request arrives is a hack, we should be requiring 
> reliable provisionals. No conclusion in discussions.

NATs are hacks, too.  While two hacks don't make a beautiful
architecture, ICE's hack can also be viewed as a different means to the
same end -- reliable 18x's when it matters.

> <kcj> I kind of agree with Christer especially since the first set of 
> STUN checks are going to fail given the race condition of setting up 
> the NAT bindings at the remote end.  Seems you are guaranteed to 
> always have to re-send the 18x...

I don't follow your argument that there's a race condition that will
force 18x to be retransmitted.  Could you explain that?

-d

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Philip Matthews <[email-masked]>
Date: Mon, 23 Oct 2006 16:25:40 -0400

> this will result in a re-transmission of the 18x.

Kevin:

If I understand your scenario correctly, then I think the following
answers your question.

If the NAT in front of UE A has address-dependent mapping, then
you are correct in saying that the first set of STUN checks from UE B  
are
likely to be dropped by A's NAT.

Once the 18x arrives at UE A, then UE A will start its own set of  
STUN checks.
These checks will install permission entries in A's NAT. Assuming  
that the
NAT in front of UA B is reasonably nice (= not address-dependent  
mapping),
then these STUN packets will make it to UA B, and a reply will come  
back.

In addition, they will "trigger" UA B to resend its checks (see  
section 7.8
of the ICE-11 draft). These triggered checks are in addition to the  
normal
resending mechanism of STUN.

So assuming the 18x gets from UE B to UE A, no resending of this 18x  
is required.

Does this help?

- Philip