Subject: Open Issues for draft04

From: Rob Lanphier <[email-masked]>
Date: Sun, 07 Sep 1997 23:04:02 -0700

I'd like to set a deadline of Wednesday for the issues that we've been
discussing since Munich, so that we can get a draft out by the end of the
week.  Here's the list of issues:

      1. Review Changes of the Draft 
         a. Transport-Info field 

Open.  To be closed by Wednesday.

RL: Needs to occur in the PLAY response field.  This is the only way in
which we can be assured that the client can know whether the initial packet
was lost.  The PAUSE response doesn't buy us that.

         b & e. 1-1-n & Use of SDP within RTSP
Open (though moving toward closure).  To be closed by Wednesday.

RL:  See the latest email on this issue.  I think we have a solution we can
agree to, with minor adjustments.

         c. PEP-Protocol Extention Protocol 

Closed.  We will bring back the "Require:" field from draft02 for basic
options negotiation.

         d. ANNOUNCE method 

Closed.  It's in to stay.

         f. Sequence number moved to the header fields 

Open.  Henning and Philipp feel pretty strongly that this should be moved.
Folks at PN aren't all too thrilled with the prospect of this.  Let's flip
a coin and be done with this one :)  

         g. Port number spec 

Closed, with caveat.  

RL: Henning's recent proposal looks fine for the most part.  I would like
to add the ability to explicitly give a two-port range rather than assume
that because one port is reserved, that port+1 is reserved (in other words,
don't break the current RTP/RTCP assumptions, but don't assume).

      2. New Business 
         a. Allow change of Transport 

Closed.  No.

         b. Release Scheudule 

We're slipping.... Let's pull this in this week.

         c. Interoperability test gathering 

October 16-17 are tenative dates.  Expect more mail later this week.

         d. Documentation issues

I never composed a mail on this, so it was never discussed.  However, these
issues were resolved.  We now have a section for minimal complience and a
section for SDP usage in the current doc.
 
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

---
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, 08 Sep 1997 11:39:19 -0400

Rob Lanphier wrote:

> was lost.  The PAUSE response doesn't buy us that.

This is only an issue in the very first PLAY. Thus, since the PAUSE
response will arrive earlier, I'd suggest putting it in both. (After a
PAUSE, the server puts in the next seq. no to be played.)

> don't break the current RTP/RTCP assumptions, but don't assume).

Can't we defer this until a demonstrated need emerges? If we allow
breaking "port+1", this just means that either server/client does need
to handle the non-contiguous case or we have yet another error
condition. Given that nobody has (if my memory serves) put forth a
strong must-have argument for this, this just seems to invite trouble.

Henning

---

From: Rob Lanphier <[email-masked]>
Date: Mon, 08 Sep 1997 09:32:02 -0700

>strong must-have argument for this, this just seems to invite trouble.

I'm not arguing for breaking the RTP model for things.  I just think it's
potentially confusing to rely on convention when it's almost as easy to be
explicit.  I'll give an example of my modification of your proposal:

Unicast PLAY/RECORD:

C->S: SETUP
      Transport: client_port=3456-3457

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

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

S->C: SETUP
      Transport-Info: client_port=3000-3001; server_port=3000-3001;
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.)

We'll be explicit about *not* breaking the RTP/RTCP contiguous port model,
and in fact, only allowing ranges reinforces that.  I think it's better
design to be explicit about this, though, because this makes proxies a bit
more generalized than to assume current RTP conventions.

Also, we do some funky non-RTP experimental kinds of things in our
implementation (yes, CUSH has run amok) and would like to be able to
communicate this to proxies in a generalized way.  We don't call it RTP, so
proxies that are doing deep checking of RTP-ism can always refuse a
connection based on the transport.  However, it would be nice if the syntax
doesn't rely on RTP assumptions.

And, of course, there's always the ulterior motive.  I'm imagining getting
phone calls from frustrated proxy writers that can't RTFM, and will
complain when they see the server say "server_port=3000" when the port is
really 3001.

Rob

---

---

From: Stephen Casner <[email-masked]>
Date: Wed, 10 Sep 1997 11:43:11 -0700 ()

> was lost.  The PAUSE response doesn't buy us that.

I agree with Henning that also putting it in PAUSE makes sense.  I
also understand the motivation to make these optional because
optaining the information might be quite difficult in a layered
implementation.  What is a viewer that normally depends on getting the
sequence number going to do when it doesn't get it?

> a coin and be done with this one :)  

Folks here vote to move the sequence number to the header field.

> don't break the current RTP/RTCP assumptions, but don't assume).

Like Henning, I would be much happier not changing the RTP/RTCP
assumption if we can.  Currently, the RTP port is the one always
specified.  If this has to change, then of the various proposals I've
seen I think I'd prefer Rob's 3000-3001 version over specifying just
the RTCP (rather than RTP) port number.
							-- Steve

---

From: Jeff Smith <[email-masked]>
Date: Wed, 10 Sep 1997 15:00:19 -0700

|
|>          f. Sequence number moved to the header fields 
|> 
|> Open.  Henning and Philipp feel pretty strongly that this should be moved.
|> Folks at PN aren't all too thrilled with the prospect of this.  Let's flip
|> a coin and be done with this one :)  
|
|Folks here vote to move the sequence number to the header field.

NTT folks also vote for moving to header field to reuse (HTTP) Java
class libraries as much as possible.

js

---

From: Brad Hefta-Gaub <[email-masked]>
Date: Wed, 10 Sep 1997 15:37:19 -0700

Stephen Casner wrote:

> >          g. Port number spec
> >
> > Closed, with caveat.
> >
> > RL: Henning's recent proposal looks fine for the most part.  I
> > would like to add the ability to explicitly give a two-port range
> > rather than assume that because one port is reserved, that port+1
> > is reserved (in other words, don't break the current RTP/RTCP
> > assumptions, but don't assume).
>

Just to clarify.

The concern that we at PN have is that although we want RTSP
implementations to use RTP as the standard transport, we don't want all
RTSP implementors to have to know all of the nuances of RTP, if their
component does not require knowledge of RTP. For example, if I am
implementing an intermediate device that is "generically" proxying all
RTSP streams, then currently I would have to code in explicit knowledge
of the RTP protocol. I would have to watch for the explicit transport
type of RTP, and always know to proxy the "assumed" RTCP ports.

We are not suggesting that implementations should send RTCP data on
ports other than port+1, we just want the ports to be explicitly stated
so as to ease implementations of intermediate devices, and to allow RTSP
compliant intermediate devices to work with new or different transports
(those other than RTP).

-Brad

---

From: Stephen Casner <[email-masked]>
Date: Wed, 10 Sep 1997 15:51:39 -0700 ()

Brad,

> type of RTP, and always know to proxy the "assumed" RTCP ports.

That makes sense.  However, the information in the Transport header is
transport-protocol dependent.  If a new transport protocol is added,
some new knowledge about that protocol (at least the parameters it
requires) will likely need to be added to the RTSP module.

							-- Steve

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 11 Sep 1997 00:15:19 -0700

>requires) will likely need to be added to the RTSP module.

There's no question that there will probably end up being RTP-isms in the
RTSP handling code.  However, this would strike me as a gratuitous RTP-ism.
 It would be far simpler for the first-time proxy writer to get it right if
the ports were explicitly stated.  I'd rather make the design choice that
causes folks to accidently get things right rather than accidently get
things wrong.

Rob

---