Subject: [BEHAVE] TURN draft queries

From: "Sourav Chakraborty" <[email-masked]>
Date: Wed, 12 Dec 2007 19:10:47 +0530

Hi Everybody,

Here are some queries that we have regarding TURN.Please clarify them at the
earliest--

As far as our understanding goes(according to
draft-ietf-behave-turn-03),there are 3 Timers to be implemented,alongwith

the actions taken at server and client--
1>Lifetime timer(turn-03: section 10.3)
            Server: Destroy allocation on expiry
            Client: Re send Allocate request on expiry of 3/4th of the time

2>Keepalive timer(turn-03: section 4.3)
            Client: What is the timer value? What message is sent on expiry?
            Server: No action
3>Permission inactivity timer(turn-03: section 10.3)

            Client: No action
            Server: Delete permission (How is the permission refreshed?)

Also please clarify whether only STUN(not TURN) can be used as a
solution for UDP media traffic
transfer over SYMMETRIC NATs.

--both endpoints behind symmetric NATs
TURN will be required.Only STUN is not enough
--one endpoint behind symmetric NAT,other endpoint in public domain
Not sure.Please clarify??

Please let us know if our understanding is correct alongwith answers to the
questions.
Thanks in advance
Regards
Sourav
_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 12 Dec 2007 23:09:56 -0500

responses inline, against TURN-04:

>             Client: Re send Allocate request on expiry of 3/4th of the time

This timer is in TURN-04, yes.

>             Client: What is the timer value? What message is sent on expiry?

This is referring to the bindings on intervening NAT. The permission 
inactivity timer adddresses that, in addition to the TURN permissions.

>             Server: Delete permission (How is the permission refreshed?)

No. Client needs to send data to each peer to keep permissions open to 
that peer.

> 
> Also please clarify whether only STUN(not TURN) can be used as a solution for UDP media traffic
> 
> --both endpoints behind symmetric NATs                                TURN will be required.Only STUN is not enough
> --one endpoint behind symmetric NAT,other endpoint in public domain   Not 
> sure.Please clarify??
> 

FIrstly, STUN and TURN both are meant to be used with ICE.
WHen ICE is in use, if both endpoints are behind symmetric NAT, ICE will 
end up with a single TURN server.
If only one endpoint is behind symmetric NAT, ICE will not use the TURN 
server for that call.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: "David Barrett" <[email-masked]>
Date: Wed, 12 Dec 2007 20:45:01 -0800

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Subject: Re: [BEHAVE] TURN draft queries
> 
> Not

Actually, if one side is symmetric and the other side is restricted cone,
won't TURN still be needed?

In this scenario, both sides filter out packets that come from ports that
aren't explicitly being sent to.  This isn't a problem when doing CONE->CONE
because both sides know where to send.  But if one side is symmetric, then
the cone side doesn't know where to send to: thus the symmetric side won't
receive anything, and anything it sends will be filtered out by the
restricted cone.

Incidentally, my stats show something like 45% restricted cone (ie, port and
endpoint dependent filtering) and 15% symmetric (port and endpoint dependent
mapping).  So right off the top it sounds like somewhere around 6% of calls
will be symmetric/restricted combination, and another 2% will be
symmetric/symmetric, suggesting at least 9% of all calls will need TURN
relaying (and that assumes perfect penetration everywhere else, which is an
incredibly optimistic assumption).  

Anyway, I don't think that's a dealbreaker, but it's probably good to keep
in mind that 90% peer connectivity is likely the *upper* bound of ICE's
capabilities.  The lower bound is, of course, 0%, and we've very little data
indicating where in between it'll actually be.

-david