Subject: "Transport" field

From: Rob Lanphier <[email-masked]>
Date: Mon, 28 Jul 1997 09:33:58 -0700

Ok, now for a (hopefully) much less contentious issue :)

Currently, in the RTSP Transport field definition, there are two different
transports defined:  RTP/UDP and RTP/TCP.  It seems that it would make more
sense to reuse current RTP profile types in here, of which there is
currently only one: RTP/AVP.  However, it does make sense to define
multiple profiles here:

RTP/AVP - RFC 1890.  This implies UDP delivery of the RTP stream

RTP/TCP (or RTP/X-TCP)- This is RTP delivered via TCP (embedded in the RTSP
stream).

If there is no objection, I'll make this change.

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/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

---

From: Mark Handley <[email-masked]>
Date: Mon, 28 Jul 1997 14:22:11 -0400

>If there is no objection, I'll make this change.

You know what I think about RTP over TCP, but leaving that aside, you
still need to specify an RTP profile.  Without a profile, there is no
binding of static payload types.  

I believe this is independent of the transport protocol issue, and so
you would probably want to use TCP-RTP/AVP or something similar rather
than RTP/TCP.

Mark

---

From: "Henning Schulzrinne (BL)" <[email-masked]>
Date: Mon, 28 Jul 1997 16:43:06 -0400

> If there is no objection, I'll make this change.

This is slightly dangerous, as the RTP profile could be trivially
extended to cover RTP-over-TCP or other profiles could define more than
one transport mapping. I would instead suggest

RTP/profile/transport

to avoid ambiguity. (In the case of TCP, this may make sense, since the
vast majority of RFC 1890 would remain unchanged.)

Henning