Subject: RE: [AVT] Re: RTP/RTCP Port Sharing -> SCTP

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 19 Jul 2001 04:13:29 -0700

Hi Jonathan,

> 
> Well, I would separate firewalls from nats. If the firewall 
> disallows all
> UDP, you're SOL and need some ugly, ugly solutions.

A firewall may allow the application (SIP, H.323, etc) through but not allow
"random" UDP packets to come from outside to "random" RTP ports (since the
RTP ports are dynamically negotiated by the application-layer). It may
require that the RTP flow initiate from within the firewall and open a
five-tuple hole in the firewall as you suggest. I'm only guessing but it
seems reasonable. 

Of course we could define set of a "standard" RTP port for single
user-machines which might help  that problem but this is not a general
solution and perhaps even encouraging undesirable behavior.

> In the case of NAT, yes - you need to have one side at least 
> have a public
> address. In our latest version of the entfw draft, coming 
> soon, we provide a
> means for the host to discover a usable binding on the public 
> side of the
> nat. It uses a "pre-midcom" approach, if you will, that talks 
> to something
> sitting behind the nat on the public side, rather than 
> talking to the nat
> directly. This approach allows us to midcom-ify existing nats without
> changing them.

Sounds interesting, I look forward to the new version of the draft.
 
> > Obviously the SCTP solution is not going to help in the near 
> > future but I
> > think the comedia paradigm is still quite a good first step 
> > until things
> > like midcom are widely deployed in firewall/nats
>
> By the time SCTP is finished, deployed, stable, and 
> implemented in nats,
> they'll all already have midcom and then it'll be a moot point.
> 

I agree. I think SCTP will be more likely seen between larger
high-reliability VoIP gateways & servers long before it is seen as the
standard transport to a single end-user.

Robert.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Thu, 19 Jul 2001 09:27:21 -0400

>solution and perhaps even encouraging undesirable behavior.

Section 7 of RFC1890 registers ports 5004 and 5005 for this purpose.

Colin

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Jul 2001 06:48:05 -0700 (PDT)

> Section 7 of RFC1890 registers ports 5004 and 5005 for this purpose.

   Oh. Cool. As I've mentioned to Jonathan before, I think
   it's an OS/daemon implementation issue whether use of a
   well known port RTP can be multiplexed for multiple users.
   Clearly it's not going to be as clean of a design as free
   floating RTP ports, but a daemon camping on 5004,5005 with
   a message passing API for users to select SSRC's of interest
   would probably be doable. The ability to express this in
   SDP might be problematic though (I haven't looked at what
   Christian cooked up though...)

	     Mike