Subject: [AVT] RE: RTP/RTCP Port Sharing (Was: Comedia Issues.)

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Jul 2001 00:20:34 -0400

> -----Original Message-----
> From: Ross Finlayson [mailto:[email-masked]]
> Sent: Monday, July 16, 2001 11:33 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
> 
> 
> Am I the only person here who's baffled that this idea 
> (allowing RTP and 
> RTCP to use the same port) is being taken seriously at all?  
> Not only would 
> this would break most - if not all - existing RTP/RTCP 
> implementations, but 
> multiplexing control and data information at this level is generally 
> considered bad design.

I agree with you in theory, Ross. The problem is that NATs are considered an
even worse design choice. However, they exist, and we need to deal with
them. 

The specific problem I'm running into is the lifetime of NAT bindings. Right
now, RTP and RTCP will both require a separate binding. NAT bindings are
kept alive by activity. Unfortunately, if silence suppression is used, the
RTP nat binding will timeout, and the media is not recovered. The
periodicity of RTCP keeps its bindings active. I'd like to be able to use
that information to keep the RTP binding fresh as well. That happens if they
are both on the same port.

Now, you will immediately say that this is why you need an ALG - put
application layer intelligence into the routers (i.e., NATs). However, I
strongly believe that the FUNDAMENTAL notion of the Internet is to keep
application layer intelligence OUT of the network layer elements. I don't
want to have to wait for upgrades in nats (which may never happen in some
deployment scenarios) in order to provide an app. Instead of the routers
knowing about applications, I say that the applications should know about
the behaviors of the routers, and adjust how they work accordingly. THis is
already a given for things like QoS, right? The applications learn about,
and adjust to, the QoS service delivered by the network routers. Applying
this concept to nats is the core idea behind midcom. However, it will be a
very long time until we have midcom everywhere, and in the interim (which is
many years), there will continue to exist application-unaware nats. I'd
rather make sure my applications work with them, rather than ignoring them
and hoping nat manufacturers all correctly implement ALG functions for every
protocol that comes around.

I'm sure this view is controversial, but I believe that given we accept the
existence of nats, my view on this is consistent with the end-to-end
architecture and hourglass model of the Internet.

I struggle greatly with nats, since their existence is severely in the way
of large scale VoIP/SIP deployments. Proprietary protocols that are
developed these days don't have all the problems with nats, since they
accept them as a given and are designed to work through them. THis is the
case for protocols like gnutella and net2phone, which do work through nats. 

> 
> Please remind me again - what problem would this solve?  If, 
> for whatever 
> reason, the current RTP/RTCP port pairing (RTP on port 2n; 
> RTCP on port 
> 2n+1) is considered too restrictive, then maybe we could 
> consider relaxing 
> *that* restriction, while still requiring RTP and RTCP to use 
> separate ports?

That helps somewhat. Another problem is that since RTP/RTCP require two
separate bindings, I cannot guarantee that they are consecutive port pairs
on the other side of an application unaware nat. So, I need to signal the
RTCP port and RTP port separately. Christian has proposed such a thing:

http://www.ietf.org/internet-drafts/draft-huitema-sdp4nat-00.txt

My binding timeout problem still exists, but if I turn off silence
suppression, at least it works with Christian's draft.

Now, backwards compatibility of all this is definitely a pain, but doable.
Lets say A can send RTP/RTCP on the same port. It includes some kind of flag
in the SDP in its INVITE. It also prepares to receive RTCP on BOTH the same
port as RTP, and one higher. If the called party recognizes the flag, it can
send RTCP back on the same port as RTP, and then it places a flag in the SDP
in the 200 OK. Otherwise, it ignores the flag, and does the current
behavior. Either works, since the caller is prepared for both. The result is
that you get current behavior unless both support the new mechanism, in
which case you get the new behavior. Isn't that backwards compatible?

Flame away.

-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

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

---

From: "Andrew Johnson" <[email-masked]>
Date: Tue, 17 Jul 2001 18:33:46 +0100

> are both on the same port.

Can't you just send periodic silence packets?

Andrew