Subject: [MMUSIC] Question about RTSP servers delivering RTP/AVP/TCP only

From: Ross Finlayson <[email-masked]>
Date: Tue, 15 Nov 2005 12:47:32 -0800

I recently received a question from someone who wanted to develop a 
RTSP server that streamed *only* via RTP-over-TCP (i.e., using the 
RTSP TCP connection), with no RTP-over-UDP streaming.  (Yes, I know - ugh!)

This person asked whether the server could announce this by 
specifying "RTP/AVP/TCP" instead of the usual "RTP/AVP" in the SDP 
"m=" lines in the "DESCRIBE" response.  From looking at the RTSP and 
SDP specs, it wasn't clear to me whether or not this would be legal.

(In practice, this is probably a moot point, because I found that at 
least two common RTSP clients - QuickTime Player and RealPlayer - 
take no notice if the "DESCRIBE" response's SDP says "RTP/AVP/TCP"; 
in each case the subsequent "SETUP" just asks for RTP-over-UDP, as usual.)

         Ross.

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Joerg Ott <[email-masked]>
Date: Wed, 16 Nov 2005 09:32:33 +0200

This is an interesting question.  Presently, there does not seem to be a
defined way to announce that you want to do interleaving of RTSP and
RTP-over-TCP.

My understanding of RTP/AVP/TCP as defined in RFC 4145 is that it always
expects a separate connection.  At least, there is no way specify that
you supposed to re-use an existing one _not_ previously established for
the media stream.  Reference to an external control connection for
multiplexing is simply not in there.

Interleaving has been RTSP-specific and used headers only (rather
than SDP).  One would need to define something for the latter.

Joerg

> I recently received a question from someone who wanted to develop a RTSP 
> server that streamed *only* via RTP-over-TCP (i.e., using the RTSP TCP 
> connection), with no RTP-over-UDP streaming.  (Yes, I know - ugh!)
> 
> This person asked whether the server could announce this by specifying 
> "RTP/AVP/TCP" instead of the usual "RTP/AVP" in the SDP "m=" lines in 
> the "DESCRIBE" response.  From looking at the RTSP and SDP specs, it 
> wasn't clear to me whether or not this would be legal.
> 
> least two common RTSP clients - QuickTime Player and RealPlayer - take 
> no notice if the "DESCRIBE" response's SDP says "RTP/AVP/TCP"; in each 
> case the subsequent "SETUP" just asks for RTP-over-UDP, as usual.)
> 
>         Ross.
> 
> 
>

---

From: "Andrew Large" <[email-masked]>
Date: Wed, 16 Nov 2005 00:03:02 -0800

As I understand things, there is a more fundamental issue at play here.
When you receive an SDP document via an RTSP DESCRIBE, no *transport*
information should be provided at all in the SDP, since the presumption
is that transport negotiation will happen via RTSP.

With regards to the decision to support TCP only -- I got (badly) burned
by that one once myself a couple of years ago.  On the surface, it
sounds reasonable and works fine as long as you are on a well-behaved
local network.  But the first time you try to stream to a client over a
dirty network (high latency, etc.), you'll shoot yourself for that
decision (as your effective throughput to the client grinds to a
halt...)

-- 
Andrew Large
[email-masked] 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joerg Ott
> Sent: Tuesday, November 15, 2005 11:33 PM
> To: Ross Finlayson
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Question about RTSP servers delivering 
> RTP/AVP/TCP only
> 
> 
> specifying

---

From: Joerg Ott <[email-masked]>
Date: Fri, 25 Nov 2005 00:05:58 +0200

> is that transport negotiation will happen via RTSP.

Well, you can observe this behavior in practice and RFC 2326 allows at
least that the server suggests a port number in describe and fixed
transport parameters (such as multicast addresses).  But this is
not the point.

The observation is that multiplexing a media stream described in an m=
line _cannot_ specify that a particular connection existing prior
to the offer/answer (or RTSP) exchange is to be re-used.  For SIP,
muxing on the SIP transport would be a particularly bad idea.

But For RTSP this means that the RTSP server cannot even indicate that
it _supports_ interleaving.  The client may request it in the Transport:
header but this request may well fail.

It would be nice if we could indicate this (maybe by means of an option
tag in the Supported: header).

> decision (as your effective throughput to the client grinds to a

I did not mean to argue in favor of TCP for real-time media (and I
would not want to).  But since this is broadly done and since you
may want to allow also for other media muxed in a TCP connection,
it may be worthwhile to have a clean definition on how to use it.

To finally get back to Ross' original question: RFC 4145 only specifies
how to signal the establishment of a TCP connection.  RTP over TCP is
is defined in draft-ietf-avt-rtp-framing-contrans-06.txt.  And this
framing method is clearly different from RTSP interleaving.  Hence,
"RTP/AVP/TCP" would be wrong.

Joerg