Subject: RTSP 1g.: Port number spec

From: Rob Lanphier <[email-masked]>
Date: Sat, 30 Aug 1997 00:06:03 -0700

Currently, the RTSP specification is a bit vague as to how the RTP port
numbers are specified, since there are a lot of port numbers to deal with.

Since the specifications so far seemed to err on the side of conciseness, I
purposefully erred on the side of completeness in hopes that we could find
an acceptable middle ground.

Here's some examples of this admittedly verbose proposal:

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=235.235.235.235
                             mutual-rtp-port=1756;
                             mutual-rtcp-port=1757

Multicast Playback SETUP (Client chooses address)

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

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=235.235.235.235;
                             mutual-rtp-port=1756;
                             mutual-rtcp-port=1757
   S->C:  OK
          Transport: RTP/AVP;destination=235.235.235.235

We decided that more mailing list discussion was in order. There was some
discussion about explicitly specifying the RTP/RTCP port.

In particular, should a violation of the RTP/RTCP port picking rules be
allowable in unicast?

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: Mon, 01 Sep 1997 10:14:53 -0400

Rob Lanphier wrote:

> In particular, should a violation of the RTP/RTCP port picking rules be

I'm strongly opposed to relaxing the requirement of consecutive port
numbers for RTP and RTCP. I see no good reason to do so. The one reason
that I have heard (difficulty in finding available port pairs) would
only appear to be an issue for a very busy RECORD server. PLAY servers
only need to bind to the RTCP port, since they don't expect to receive
any data on the RTP port. (The UDP source port doesn't matter to the
client.) A server busy enough to worry about ports is not likely to be
serving lots of other port-hungry UDP applications (what would these be
in any event?), so that ports should be available in pairs without a lot
of searching.

Violating the port number convention makes life difficult for firewalls,
existing monitoring tools, existing media applications and new resource
reservation protocols such as YESSIR
(http://www.cs.columbia.edu/~hgs/research/reservation).

Also, it adds yet another variable that needs to be conveyed.

Henning
-- 
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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 01 Sep 1997 11:08:32 -0400

> an acceptable middle ground.

These assumptions underlie the following proposal:

- the receiver of data/control messages gets to specify the port;
- RTP ports are specified, RTCP ports are implied (+1); see previous
message on motivation;
- since only receive port matter, the spec always implies "the port to
bind to";
- for multicast, everybody sends and receives on the same port pair.

Unicast PLAY/RECORD:

C->S: SETUP
      Transport: port=3456

means that the client wants data at 3456 and RTCP at 3457.

S->C  200 OK
      Transport-Info: port=3000  

means that the server wants data at 3000 (there is no data for PLAY, but
this doesn't much matter) and RTCP at 3001. This model corresponds
exactly with the model used by the SIP+SDP combination. If we want to be
more verbose, we could define server_port and client_port:

C->S: SETUP
      Transport: client_port=3456

S->C: 200 OK
      Transport-Info: server_port=3000;client_port=3456

For unicast recording, this would be the same, except that the client
now sends data to 3000/3001 and the server sends RTCP report to 3457.

For multicast, the verbose option:

C->S: SETUP
      Transport: client_port=3456

S->C: SETUP
      Transport-Info: client_port=3000; server_port=3000;
address=224.2.0.1

This signals to the client that it better expect data on 3000 rather
than 3456, overriding the client's choice. (The client didn't know that
multicast was in the cards.)

Henning
---