Subject: RE: [Ietf-behave] TURN Issue #6: port numbers

From: "Francois Audet" <[email-masked]>
Date: Wed, 14 Dec 2005 08:26:06 -0800 (PST)

You mean the same signalling port, right, not the same tunnelled
packets?

Being on the same signalling port makes sense. For tunnelled packets,
probably not.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Cullen Jennings
> Sent: Tuesday, December 13, 2005 19:35
> To: Jonathan Rosenberg; Behave
> Subject: Re: [Ietf-behave] TURN Issue #6: port numbers
> 
> 
> 
> If STUN and TURN are on the same port, it make it much harder 
> to right rate limiting rules for them. I don't know if this 
> matters much but worth a bit of thought. 
> 
> 
> On 12/5/05 12:33 PM, "Jonathan Rosenberg" <jdrosen@xxxxxxxxx> wrote:
> 
> > Right now, TURN has no default port. Its marked as XXXX in 
> the spec. 
> > With the view that TURN would be a stun usage, its not 
> clear that it 
> > needs a separate port from the STUN port. The only reason 
> to have that 
> > is if folks think there is a desire from firewall admins to 
> block TURN 
> > by disabling its port, but allow STUN. There are a few options here:
> > 
> > 1. TURN will reuse the STUN default port. DNS procedures 
> also exist to 
> > detect the udp, tcp, etc. ports for STUN/TURN, but they are always 
> > shared.
> > 
> > 2. TURN has a separate default port. DNS procedures also exist to 
> > detect the udp, tcp, etc. ports for STUN, and there is also a 
> > procedure to detect them for TURN. This would be done by defining a 
> > separate NAPTR service for Allocate requests.
> > 
> > 3. TURN will reuse the STUN default port. DNS procedures 
> also exist to 
> > detect the udp, tcp, etc. ports for STUN, and there is also a 
> > procedure to detect them for TURN. This would be done by defining a 
> > separate NAPTR service for Allocate requests.
> > 
> > 4. TURN has a separate default port, and there are no DNS 
> procedures 
> > defined at all for STUN or TURN. This would imply a 
> specific solution 
> > to the TLS problem in Issue #5 (in particular, would imply no 
> > DNS-based solutions). Why do this? The only reason is to 
> force usage 
> > of TURN over a specific port since no discovery mechanism 
> would exist. 
> > This would facilitate firewall port-blocking. Of course, its easily 
> > circumvented through configuration of the TURN port (which 
> is what is 
> > done today), but its an option.
> > 
> > 
> > I tend to prefer #1 for simplicity. Unless there is a compelling 
> > argument brought about why the TURN and STUN requests NEED 
> to run on 
> > different ports, I see no reason for anything else.
> > 
> > -Jonathan R.
> > 
> > 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 14 Dec 2005 11:44:20 -0800 (PST)

Hmm - I might be missing what you are saying. The signaling would be over
the same TCP flow as the media on that side of the turn server.