Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-21.txt

["Jaehwan Kim" <jaehwan at vidiator.com>]

Hi,

It seems that the biggest change is 'DVD Player remote control' because
I always introduced people RTSP as a TV remote control protocol.

And I would like to share some my comments, originally written for my
better understanding, if you don't mind.

>(Page18) When the server is notifying the client about the end of the
media delivery requested using PLAY, it sends a PLAY_NOTIFY request to
the client. 
[jh]The right intention looks "When the server wants to notify the
client about the end of the media delivery, it can send a
PLAY_NOTIFY..."

>(Page18) The PLAY_NOTIFY request includes information about the last
RTP sequence numbers for each stream, and thus enables correct handling
of the buffer drainage at the end.
[jh] How about this? "The PLAY_NOTIFY request includes the last RTP
sequence number for each stream to help the player to empty the buffer
smoothly."

>(Page19) For video is possible to manipulate the number of frames that
is displayed per second, but...
[jh] This part could be enhanced like below. Correct me if I am wrong.
Some 'this' are ambiguous to me.

"For video, it is possible to manipulate the framerate on the fly,
although the randering capabilities are often limited to certain frame
rates. And the allowed contents bitrate also limits the modification of
the framerate. Therefore, basically fast forward feature could be
implemented in this regards in which some subset of the frames from the
original content could be picked up. However, the result of this way
would be different from the video encoding methods.

Due to the media characteristics, possible scale ratios is commonly
limited. To signal right scale ratio information, RTSP has a way of
indicating the supported Scale ratios for the content. To support
aggregated or dynamic content, where the scale may change during the
session and this change is dependent on the location within the content,
a mechanism for updating the media properties and the currently used
scale factor exists."

>(Page20) Speed affects how much of 
[jh] I think this parts overally should be re-reviewed. Or I would
revisit here again later.

>(Page25)
   transport.  A message is either a Request or a Response.

   Message Body:  The information transferred as the payload of a
   message.  A message body consists of meta-information in the
   (snip)
[jh] the expression, "either a request or a response" should be in the
message body. It helps RTSP implementers to consider message body even
in the request which is not common in basic operation. Therefore, rather
the original sentence in draft20 looks better. And I think "The
information transferred as the payload of a request or response." could
be rephrased to "The contents of the message without the message header
in either RTSP request or response message."

>(Page141) The server SHALL
   respond if the session is in playing state with the Range header
   filled in with the current playback point and with the corresponding
RTP-Info values.
[jh] Original one looks more clear. It would be enhanced like below,
though.
"The server SHALL respond if the session is in playing state. Then, that
response MUST have RTP-Info value which is corresponding to the given
Range value."

>(Page250) 
        S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0
              CSeq: 45
              Notify-Reason: end-of-stream
              Request-Status: cseq=4 status=200 reason="OK"
              Range: npt=-15
              RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                 ssrc=0D12F123:seq=49;rtptime=39200
              Session: abcdefgh

        C->S: RTSP/2.0 200 OK
              CSeq: 854
              User-Agent: PhonyClient/1.2
[jh] CSeq looks mismatched. 


Regards,
Jaehwan
Vidiator

-----Original Message-----
From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On Behalf
Of Internet-Drafts at ietf.org
Sent: Friday, June 19, 2009 10:30 PM
To: i-d-announce at ietf.org
Cc: mmusic at ietf.org
Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-21.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Multiparty Multimedia Session Control
Working Group of the IETF.


	Title           : Real Time Streaming Protocol 2.0 (RTSP)
	Author(s)       : H. Schulzrinne, et al.
	Filename        : draft-ietf-mmusic-rfc2326bis-21.txt
	Pages           : 283
	Date            : 2009-06-19

This memorandum defines RTSP version 2.0 which obsoletes RTSP version
1.0 which is defined in RFC 2326.

The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for setup and control of the delivery of data with real-time
properties.  RTSP provides an extensible framework to enable controlled,
on-demand delivery of real-time data, such as audio and video.  Sources
of data can include both live data feeds and stored clips.  This
protocol is intended to control multiple data delivery sessions, provide
a means for choosing delivery channels such as UDP, multicast UDP and
TCP, and provide a means for choosing delivery mechanisms based upon RTP
(RFC 3550).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-21.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.