Subject: Thursday MMUSIC/RTSP Agenda

From: Rob Lanphier <[email-masked]>
Date: Tue, 12 Aug 1997 02:03:24 +0200

Below is the agenda for the RTSP portion of the MMUSIC session on Thursday.
 Please send your comments on this to the list prior to the meeting, if
possible (especially if you are not going to be in attendance).

Outline:

1. Review Changes of the Draft
   a. Transport-Info field
   b. 1-1-n
   c. PEP-Protocol Extention Protocol
   d. ANNOUNCE method
   e. Use of SDP for session descriptions and syntax specification for that
   f. Sequence number moved to the header fields

2. New Business
   a. Allow change of Transport
   b. Release Scheudule
   c. Interoperability test gathering

=============================================================================
 Detail
=============================================================================
1. Review of changes to the draft:
--------------------------------------------------------------------------
   a. Transport-Info: field

   In order to gracefully handle delayed packets after seeking, the server
needs to be able to reliably send the sequence number of the initial packet
following a seek, so that the client knows it can safely discard packets
with sequence numbers smaller than the initial post-seek sequence number.

   The Transport-Info field was added as a way of solving this problem.
However, there is probably some tuning that needs to be done to this header.
--------------------------------------------------------------------------
   b. 1-1-n

   1-1-n refers to a single RTSP resource (i.e. a container file), which is
controlled by a single RTSP session (and thus has a single NPT and session
id), that contains multiple (n) RTP streams.  After rigorous debate and
some confusion, a rough consensus seemed to form around solving this
problem in the way that is currently outlined in the draft.

That is:
1.   Client retrieves description of the container file through a single
DESCRIBE (though may retrieve this through other means if those means are
sufficiently synchronized with the media server).  This single description
contains multiple streams.
2.   The client issues a SETUP command per stream (n SETUP commands) to the
server.  Each of the SETUP messages has the same session id, and are
distinguished by their URLs.
3.   The client issues a single PLAY, which starts all streams in the
session along a common NPT.

What hasn't been previously discussed is Progressive Networks aligning with
the consensus on this issue, which we now are.  We would like to make this
a "last call" on this particular issue in case that there are some issues
that others have with the method that is proposed in the draft.  This will
allow us to use this method in current implementations.
--------------------------------------------------------------------------
   c.  PEP-Protocol Extention Protocol

We've added PEP support to the latest draft of RTSP.  More information
about PEP can be found at:

http://www.w3.org/pub/WWW/Protocols/PEP/Overview.html

Since minimal PEP support is really easy to pull off (see the RTSP refkit
for source code), those implementations with simple needs will be able to
gracefully accomodate clients with more demanding needs.  The PEP protocol
has remained reasonably stable for the past few months, and it's not
unrealistic to expect that it will achieve proposed standard in the very
near future.  If it looks like PEP standardization is going to take longer
than we are currently anticipating, we may reconsider this issue. 
--------------------------------------------------------------------------
   d. ANNOUNCE method

The ANNOUNCE method was introduced in the last draft.  Functionally, it is
equivalent to the S->C DESCRIBE, but we decided that it was semantically
different enough that it needs a new name.
--------------------------------------------------------------------------
   e. Use of SDP for session descriptions and syntax specification for that.

*NOTE*:  The examples below are slightly different than those in the draft.
 This came from hallway discussions with various parties about how SDP and
RTSP could be better integrated.  The next draft will resolve this issue.

For single-stream presentations, the DESCRIBE response should look like this:

   DESCRIBE rtsp://foo.com/boo/bar.wav/ RTSP/1.0 1
   Accept: application/sdp

   RTSP/1.0 200 1 OK
   Date: 22 Jul 1997 00:16:41 GMT
   Content-type: application/sdp
   Content-Length: 242
   
   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info> 
   t=0 0
   m=audio 8004 RTP/AVP 3
   c=IN URL rtsp://foo.com/boo/bar.wav

For multi-stream presentations:

   DESCRIBE rtsp://foo.com/boo/bar.avi/ RTSP/1.0 1
   Accept: application/sdp

   RTSP/1.0 200 1 OK
   Date: Tue Jul 22 17:11:12 1997
   Content-Type: application/sdp
   Content-Length: 319

   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info> 
   t=0 0
   m=video 8002 RTP/AVP 31
   c=IN URL trackID=47
   m=audio 8004 RTP/AVP 3
   c=IN URL trackID=48

The media urls in the request are relative to the request url.  One could
just as easily have had:

   DESCRIBE rtsp://foo.com/boo/bar.avi/ RTSP/1.0 1
   Accept: application/sdp

   RTSP/1.0 200 1 OK
   Date: Tue Jul 22 17:11:12 1997
   Content-Type: application/sdp
   Content-Length: 319

   v=0
   o=- 2890844256 2890842807 IN IP4 127.0.0.1
   s=<title string>
   i=<more info> 
   c=IN IP4 0.0.0.0/15/1
   t=0 0
   m=video 8002 RTP/AVP 31
   c=IN URL rtsp://foo.com/boo/bar.avi/trackID=47
   m=audio 8004 RTP/AVP 3
   c=IN URL rtsp://foo.com/boo/bar.avi/trackID=48
--------------------------------------------------------------------------
   f. Sequence number moved to the header fields

Once upon a time, both SIP and RTSP had a sequence number in the top line
of the request (and the response), and HTTP didn't.  Now only RTSP has
this.  It's been suggested that we move this down to the RFC822 fields.
This may be a bad idea changing this at this in RTSP at this stage, unless
there is a strong feeling that it should be changed (this is my personal
bias-RL).  Henning may wish to comment on this :)

=============================================================================
2. New Business
----------------------------------------------------------------------------
   a. Allow change of Transport

It may be the case that a server would want to change the multicast address
mid-presentation.  Is this something that should be allowed, and how should
it be done?
--------------------------------------------------------------------------
   b. Release Scheudule

September 1: draft04
October 1: draft05
November 1: WG last call

All drafts will contain accurate changebars in the Postscript versions.
--------------------------------------------------------------------------
   c. Interoperability test gathering

We should have a gathering in the Seattle area (Progressive Networks
hosted) in the first week of October at which we have everyone who is
working on RTSP implementations get together and try to get
interoperability between all of our clients and servers.  This will let us
have a face-to-face opportunity to knock out draft issues and bugs in
implementations.  Interested parties should contact me ([email-masked]),
and I'll coordinate this event.

That's the plan at this point.  Please feel free to start/continue the
conversation on any of these bullet points now on this list, and hopefully
we'll be seeing many of you here in Munich on Thursday to dive into these
as well.  Also, please feel free to raise any oversights in this list.

Thanks
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: [email-masked]
Date: Tue, 12 Aug 1997 10:24:41 +0200 (MET DST)

I guess I wasn't in the mailing list when this topic was
discussed, therefore sorry if I repeat something that was already
said.

	From my point of view there is a small problem with such
a way to send the sequence number (I saw a similar problem with
'STREAM SYNC' in the original (and 'dead') specification-00).

	As you say, a Transport-Info field in the RTSP response is
reliable, but, although we can assume that RTP (or any other
transport protocol) 'goes' over a 'real-time prepared conection'
(reserved via RSVP or any other mean outside the RTSP & RTP protocols),
we cannot make the same assumption about the RTSP conection.
	To summarize, the RTSP response (containing the Transport-Info)
to a PLAY can (and in the scenarios I think of, *will*) arrive later
(maybe much later) than the packets using that sequence number.

	(It still have an advantage against not sending it at all,
i.e. to allow discarding same packets that could have been buffered; but
it would be better another solution)

	I think of two possibilites:
	- It's the client who chooses the first sequence number following
a seek and sends it toghether with the PLAY method
	- The servers waits for an acknowledgment for its response
to the PLAY (I don't like this solution at all...  its against the
protocol structure of RTSP...).

	Hope I'm not speaking non-sense.
	I apologize again for not having been there when the topic
was discussed the first time.

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