Subject: [BEHAVE] More comments on turn-05

From: "Derek MacDonald" <[email-masked]>
Date: Mon, 3 Dec 2007 14:44:41 -0800

As a pre-amble, I like the direction turn-05 is going.  I much prefer the
ChannelConfirm approach over the older active destination approach.

Some comments:

6.2.1.3

I think that if the client requests "Even port with hold on the next port
higher" the server should fail the request if it can't honour it.  We could
add a suggested timer if we are worrying about running out of ports.  As it
stands, the client won't know if the second port request will succeed, which
could require tearing down the original port and starting again. This seems
inefficient.

6.2.1.4

   The server SHOULD only allocate ports in the range 1024-65535.

Why not MUST? Do we really want the capability to run well known services
over TURN?

Nits

7.2.2

   o  If one has not been assigned, the client assigns one of its own...

/s/client/server

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

---

From: <[email-masked]>
Date: Tue, 4 Dec 2007 01:12:41 +0200

What is the rationale for such a restriction? If this is a HW issue then
it is just a matter of time when someone comes with a TURN server
product which can do this at wire speed.

If this is some operator mandated requirement then it should not put in
the spec as some particular interest group should be not be in a
position to narrow the functionality of a protocol to suit their
particular interest.

Rather the spec should state that the owner of a TURN server is free to
configure the TURN server to reject Allocate request with "unpleasant"
REQUESTED-PORT-PROPS values.

Therefore no changes should be made to the original sentence below or
alternatively it should be remove altogether from the spec.

/Mikael

>	From: ext Derek MacDonald [mailto:[email-masked]] 
>
>	6.2.1.4
>	
>	Why not MUST? Do we really want the capability to run well known
services over TURN?