Subject: RE: Comedia Issues.

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Jul 2001 23:26:21 -0400

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Friday, July 13, 2001 5:01 PM
> To: Jonathan Rosenberg; David Yon; Fairlie-Cuninghame, Robert;
> [email-masked]
> Subject: RE: Comedia Issues.
> 
> 
> If we really want to solve NAT traversal, we should also remove the
> requirement to have RTP run on an even port, and RTCP on the next odd
> port. In fact, we should run RTP and RTCP on the same port.

Yes!! That would solve so many problems.... keepalives through nats are done
through the RTCP even when no one is talking, we have no need to signal an
explicit RTCP port through nats, we double the available port space, and so
on. You have my vote on allowing RTCP on the same port as RTP. To
disambiguate, you just need to disallow RTP from using a few of the payload
types that would make an RTP packet look like RTCP.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Pete Cordell" <[email-masked]>
Date: Sun, 15 Jul 2001 10:33:59 +0100

According to table 2 of RFC 1890 the RTCP 'payload types' are already
reserved, so there shouldn't be a problem.

The same thought had occurred to me, and I've been trying to think of
reasons why RTP and RTCP are on different ports.  The only reason I can
think of is following the principle of only de-muxing at one layer.  (I
can't see how the separation helps multicast routers for example.)  To the
uninitiated this seems to be a bit of dogma over practicality, and for me
this instance of de-muxing would fall into a grey area with regard to this
principle.  However, it would be nice to know what the original reason was.

The main problem with this is surely backwards compatibility.  I can not see
any way to make it work with existing clients.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================

----- Original Message -----
From: Jonathan Rosenberg <[email-masked]>
To: 'Christian Huitema' <[email-masked]>; Jonathan Rosenberg
<[email-masked]>; David Yon <[email-masked]>; Fairlie-Cuninghame,
Robert <[email-masked]>; [email-masked] <[email-masked]>
Sent: 14 July 2001 04:26
Subject: RE: Comedia Issues.

---

From: David Yon <[email-masked]>
Date: Sun, 15 Jul 2001 06:55:24 -0400

I was just about to point out that this had strayed away from being 
relevant to comedia, and to please at least change the subject line, when I 
noticed that you had done exactly that.  This all somewhat supports my 
point that comedia is not the draft where NAT/firewall traversal should be 
attacked, primarily because there is so much baggage already in the 
non-connection-oriented protocol space.

That aside, I do owe the list another response on the topic (comedia that 
is), but have to get clear of the latest life-at-a-startup firedrill 
first.  Apologies for the delay, I'll be back on the air shortly.

>any way to make it work with existing clients.

David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Sun, 15 Jul 2001 16:17:37 -0700 (PDT)

I can think of one pretty unfortunate consequence
of RTCP being on the same port. In some QoS
reservation scenarios with certain popular coders,
TDM-like slots can be allocated to give
preferential treatment to the RTP stream,
typically allocated to the ceil() of the possible
coders. If you put RTCP on the same port, you
clearly wouldn't want to allocate the TDM-like
slots as big as RTCP can be, so you'd have to
figure out how to split RTCP out and send it some
other way, or whatever. In other words, it gets
pretty messy in a hurry. Leaving RTCP on a
different port avoids all of that bother since
it's a different u-flow (and can be treated as
non-EF traffic too).

	       Mike