Subject: [Fwd: Re: Thursday MMUSIC/RTSP Agenda]

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Aug 1997 08:34:57 -0400

I agree that this port business should be symmetric, with the receiving
side getting to specify the port (except for multicast). Implicitly,
RTCP ports are the port numbers + 1.

Maybe something like 

rport = receiving port for data
sport = sending port for data

Thus, the cases:

(1) Unicast playback

C->S: rport=4710
S->C: rport=1600;sport=4710

Result: Client receives data on 4710 and sends reports to 1601.

(2) Multicast playback (but client doesn't know), so server gets to
choose by necessity if this isn't the first client joining in:

C->S: rport=4710
S->C: rport=1600;sport=2000

Result: Client receives data on 2000 (or not at all, if it can't do
this); server expects reports at 1601.

(3) Unicast recording:

C->S: sport=4710;rport=3000
S->C: sport=3000;rport=4710

Result: Client (or the session controlled by client) sends data on port
4710; client expects RTCP reports on 3001. Server agrees with that.

(4) Multicast recording:

C->S: sport=4710;rport=4710
S->C: rport=4710;sport=4710

Result: Client sends data on port 4710; server sends reports on 4711.
For multicast, separate send/receive ports don't make sense.
-- 
Henning Schulzrinne        email: [email-masked]
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

Subject: Re: Thursday MMUSIC/RTSP Agenda
From: Alagu Periyannan <[email-masked]>
To: Anders Klemets <[email-masked]>
Cc: [email-masked], Rob Lanphier <[email-masked]>
Date: Wed, 13 Aug 1997 00:48:31 -0700 (PDT)

Hi all,

I was expecting "port=" to be replaced by "cport="
and "sport=". These would be for the client RTP port
and server RTP port. The RTCP ports for both would
be obtained by adding one.

This would solve the problem mentioned below.

On Tue, 12 Aug 1997, Anders Klemets wrote:

> I have a comment on the Transport-Info field.  If I remember correctly,
> the spec provides for a "cport" parameter, which is the port number
> that the server listens on for RTCP packets.
> 
> What is the clients interpretation of a Transport-Info field where the
> "cport" parameter is missing?  Does it imply cport = port + 1 where
> "port" is the RTP port number that the client supplied in the Transport
> field?
> 
> Also, I don't like the idea of having a "cport" field in the first place.
> It gives the impression that the client is only expected to send RTCP
> packets to the server, and no RTP packets.  But that is not
> necessarily true.
> 
> Consider the case of a unicast connection between a server and a client.
> The client issues the RECORD command and wants to send RTP data to the
> server.  The server might be some recording tool, or the client might
> actually be another server that is trying to replicate its content.
> Or the client might be trying to stage content in the cache of the
> server, which is really a caching RTP proxy, etc, etc.
> 
> For this scenario to work, the client needs to know the port number that
> the server is listening on for RTP data.  The "cport" parameter is
> not really adequate for this.  There needs to be a "port" parameter
> or something like this in the Transport-Info field.
> 
> Anders
>

---

From: Rob Lanphier <[email-masked]>
Date: Wed, 13 Aug 1997 20:45:21 +0200

>sport = sending port for data

I think the constraint of coming up with a five-letter abbreviation is
causing us to come up with really confusing terms for this stuff.  I think
it may be better to start from the other extreme (clarity to the point of
ridiculousness) and then pare down what is truly unnecessary information,
and which terms we can overload without creating hassles.

client-rtp-port:   rtp port on the client
client-rtcp-port:  rtcp port on the client
server-rtp-port:   rtp port on the server
server-rtcp-port:  rtcp port on the server
mutual-rtp-port:   rtp port on the server and on client (multicast only)
mutual-rtcp-port:  rtcp port on the server and on client (multicast only)

I almost should leave the example as an exercise to the reader to see if
these parameters are as intuitive as I think they are.

Unicast Playback SETUP

C->S:  SETUP foo
       Transport: RTP/AVP;client-rtp-port=1756;client-rtcp-port=1757

S->C:  OK
       Transport: RTP/AVP;server-rtcp-port=4057

Multicast Playback SETUP

C->S:  SETUP foo
       Transport: RTP/AVP

S->C:  OK
       Transport:
RTP/AVP;destination=215.215.215.215;mutual-rtp-port=1756;mutual-rtcp-port=1757

Unicast Record SETUP

C->S:  SETUP foo
       Transport: RTP/AVP;client-rtcp-port=1757

S->C:  OK
       Transport: RTP/AVP;server-rtp-port=4056;server-rtcp-port=4057

Multicast Record SETUP

C->S:  SETUP foo
       Transport:
RTP/AVP;destination=215.215.215.215;mutual-rtp-port=1756;mutual-rtcp-port=1757

S->C:  OK
       Transport: RTP/AVP;destination=215.215.215.215

------

Now, one may argue that it is redundant to put the RTCP port when one knows
the RTP port.  I'm realizing that this is an inefficient assumption on
servers which may be serving and recording lots of streams and a
consecutive port search may be a difficult task.  Therefore, in unicast, we
may need to break the consecutive port rule in RTP.

Rob
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/help/firewall
For more information on RTSP:                     http://www.real.com/rtsp

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Aug 1997 14:56:47 -0400

Rob Lanphier wrote:

One reason I avoided the use of "client" and "server" in the port names
is since it is possible that a single session serves both (see earlier
discussion). Thus, receive-port and send-port, always viewed from
whoever is sending the data.

> may need to break the consecutive port rule in RTP.

A server that serves lots of simultaneous recording sessions would
likely have most of its UDP ports used for RTP/RTCP, so I don't see why
the searching should be an issue (who else, on a large scale, would be
using lots of UDP ports liberally spread around the port number space?)

Thus, I'd be reluctant to give up this simplicity (there are other
reasons not to do this, with firewalls and resource reservation being
two; see Ping's and my paper on RTCP-based resource reservation at
http://www.cs.columbia.edu/~hgs/research/)