Subject: Re: Thursday MMUSIC/RTSP Agenda

From: Anders Klemets <[email-masked]>
Date: Tue, 12 Aug 1997 17:18:47 -0700

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: Alagu Periyannan <[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.

> or something like this in the Transport-Info field.

ould use 'cport - 1' as RTP
port at the server.

	To be honest I agree that in the scenario you mention a
direct way to specify the RTP  port should be provided.

	Maybe the easiest way is that for the RECORD method no
'port' field be sent from the client to the server, and it
is sent in the response from the server to the client. (But then
the specification should be modified, as it states:
" port: RTP/RTCP destination ports on client. ..."

	I'm afraid that the only examples about recording I found in the
specification was from a conference, but in the one in section
"14.5", the 'port' field of 'Transport' is actually sent in the
response from the server to the client. It's not the same as I
proposed above, because it should be a multicast port (and address,
I think that the multicast address was forgotten in the example), but
it goes in the same direction.
	The way to set the RTP reception port for recording in
the unicast scenario should be explicitly described in the specification.

	Paco

-- 
Francisco Cortes (Paco)			Hoehenstr. 17a
					33098 Paderborn
[email-masked]			Tln. +49 5251 670933
===
PGP fingerprint  69 B9 77 98 D7 6A 8F CF  32 78 43 85 4E 7C E0 96