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

From: "Jaehwan Kim" <[email-masked]>
Date: Thu, 9 Jul 2009 18:35:10 +0900

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: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, June 19, 2009 10:30 PM
To: [email-masked]
Cc: [email-masked]
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.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 13 Jul 2009 17:57:50 +0200

Hi,

Thanks for your comments. See inline for each individual item. The
changes made will be able in the 22 version.

> client about the end of the media delivery, it can send a

Yes, I changed this to:

When the server want to notify the client about the completion of the
media delivery, it sends a PLAY_NOTIFY request to the client.

> sequence number for each stream to help the player to empty the buffer

Yes, reworded it somewhat:

The PLAY_NOTIFY request includes information about the stream end,
including the last RTP sequence number for each stream, thus enabling
the client to empty the buffer smoothly.

> a mechanism for updating the media properties and the currently used

I want to keep this reasonably non-specific when it comes to the codec.
Is this better?

For video is possible to manipulate the frame rate, although the
rendering capabilities are often limited to certain frame rates. Also
the allowed bit-rates in decoding, the structured used in the encoding
and its dependency between frames and other capabilities of the
rendering device limits the possible manipulations.

Due to the media restrictions, the possible scale values are commonly
restricted to a limited set of possible scale ratios. To enable the
clients to select from the possible scale values, RTSP can signal the
supported Scale ratios for the content. To support aggregated or dynamic
content, where this may change during the ongoing session and dependent
on the location within the content, a mechanism for updating the media
properties and the current used scale factor exist.

> revisit here again later.

Well, it is a lot of new text. When it comes to this I do need feedback
what is problematic with the text. Writing about speed and scale is
problematic.

> in either RTSP request or response message."

I have clarified that this is either a request or a response. But your
suggested phrasing is a the invert that isn't fully true as there can be
 other parts in a message. I try to write what it is.

> response MUST have RTP-Info value which is corresponding to the given

Okay, is this clearer?

The RTP-Info header and the Range header MAY be included in a
GET_PARAMETER request from client to server without any values to
request the current playback point and corresponding.RTP synchronization
information. When the RTP-Info header is included in a Request also the
Range header MUST be included (Note, Range header only MAY be used). The
server respons SHALL include both the Range header and the RTP-Info
header. If the session is in playing state, then the value of the Range
header SHALL be filled in with the current playback point and with the
corresponding RTP-Info values. If the server is another state, no values
are included in the RTP-Info header.

> [jh] CSeq looks mismatched. 

Fixed.

Thanks for the comments

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Jaehwan Kim" <[email-masked]>
Date: Tue, 14 Jul 2009 11:08:30 +0900

Hi Magnus,
Thanks for your prompt response. It looks good.

Regards,
Jaehwan

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Tuesday, July 14, 2009 12:58 AM
To: Jaehwan Kim
Cc: [email-masked]
Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-21.txt

Hi,

Yes, I changed this to:

Okay, is this clearer?

Fixed.

Thanks for the comments

Magnus Westerlund