Subject: [MMUSIC] A question on draft-ietf-mmusic-ice-15

From: JiangXingFeng <[email-masked]>
Date: Thu, 24 May 2007 20:48:10 +0800

Hi, Jonathan:

I have read your draft and have a question to ask you. Would you please give
me some explanations?

ICE is making use of offer/answer mechanism to collect some candidate pairs
and check the connectivity between the local candidates and remote
candidates.  If a remote candidate is of type of relayed address, in my
understanding, when the agent want to send a STUN check packet to the remote
relayed address, it may not arrived at the remote candidate because the STUN
server may filter the packet because of no permission. 

In other words, Relay usage makes the STUN servers act as a NAT with end
independent mapping behavior and address dependent filtering behavior. If
there is no permission for a specific external peer, the STUN server will
filter the packet from the remote peer unless client has created permissions
for the remote peer in advance. 

I don't find any action taken make the agent to notify the STUN server relay
packets from the remote candidates.  Maybe I miss something and my
understanding is not correct. Could you please give me more explanations?

Regards!

--
Jiang XingFeng

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 24 May 2007 15:56:50 +0300

On Thursday 24 May 2007 15:48:10 ext JiangXingFeng wrote:
> understanding, when the agent want to send a STUN check packet to the
> remote relayed address, it may not arrived at the remote candidate because
> the STUN server may filter the packet because of no permission.

Yes.

> filter the packet from the remote peer unless client has created
> permissions for the remote peer in advance.

Yes.

> I don't find any action taken make the agent to notify the STUN server
> relay packets from the remote candidates.  Maybe I miss something and my

You have to create the permission on the STUN relay server first. This is 
typically done by sending a STUN/ICE connectivity check within a STUN Send 
Indication through the STUN relay server.

Since ICE works fine from behind a NAT with independant mapping and 
address-dependant filtering, it also works fine through a STUN relay server 
all the same.

-- 
Rémi Denis-Courmont

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 24 May 2007 11:38:07 -0700

TURN's Set Active Destination accomplishes that.  See 
http://tools.ietf.org/html/draft-ietf-behave-turn-03#section-6.3.2

-d

> -----Original Message-----
> From: JiangXingFeng [mailto:[email-masked]] 
> Sent: Thursday, May 24, 2007 5:48 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [BEHAVE] A question on draft-ietf-mmusic-ice-15
> 
> Hi, Jonathan:
> 
> Behave mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/behave

---

From: JiangXingFeng <[email-masked]>
Date: Fri, 25 May 2007 12:04:39 +0800

> http://tools.ietf.org/html/draft-ietf-behave-turn-03#section-6.3.2

Thanks for your reply. Besides Set Active Destination, there are some other
methods could do the same thing, such as Open, Send indications. 

Do we need to add more text to ICE draft and say that "before connectivity
check begins, agent A should create permission for Relayed address in order
to allow connectivity check's packet from other agent through the NAT and
reach the agent. A"?

---
JiangXingFeng

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 24 May 2007 21:30:15 -0700

> Thanks for your reply. Besides Set Active Destination, there 
> are some other methods could do the same thing, such as Open, 
> Send indications. 
> 
> Do we need to add more text to ICE draft and say that "before 
> connectivity check begins, agent A should create permission 
> for Relayed address in order to allow connectivity check's 
> packet from other agent through the NAT and reach the agent. 
> A"?

It's not necessary -- the combination of the triggered checks
and retries by the answerer cause the permission and the
connectivity check to complete as soon as the permission is
created.

-d

---

From: Philip Matthews <[email-masked]>
Date: Tue, 29 May 2007 13:50:34 -0400

> connectivity check to complete as soon as the permission is

Just a bit more clarification here.

"Set Active Destination" is one way to install a filtering entry for the
remote peer in the TURN server, but there is another way.

Consider two peers, L and R, which are behind different NATs.
L uses a TURN server T.

If R sends a connectivity check to L's allocated address on T
before anything else happens, then you are correct that T will
discard the packet. However, this will install a filtering entry
into R's local NAT.
Then when L sends a connectivity check from T towards R,
this will install a filtering entry on T for R, and this connectivity
check packet will also get through R's NAT because of the
previously installed filtering entry.

If the order is reversed (L sends first), then a connectivity check
from L's allocated address on T towards R will be dropped by
R's NAT, but will install a filtering entry on T.
Then when R sends a connectivity check from R to L's address
on T, this connectivity check will get through because of the
previously installed filtering entry on T.

To summarize:
If R sends first, then its connectivity check packets get dropped
by T until L sends its first packet towards R.
If L sends first, then its connectivity check packets get dropped
by R's NAT until R sends its first packet towards L's address on T.

In other words, the packets do not get through until both ends try
to send. This is the reason that ICE defines a priority function for
candidate pairs -- so both ends will send checks at approximately
the same time.

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 31 May 2007 09:37:27 -0400

To be clear - there is no special behavior required from the endpoint 
connected to the TURN server for this to work. The ICE processing 
defined in the specification will cause an endpoint to naturally send 
connectivity checks which open up permissions. SetActiveDestination is 
not required and would not need to be used for this purpose.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com