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

From: [email-masked]
Date: Mon, 3 Nov 2008 10:30:01 -0800 (PST)

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-19.txt
	Pages           : 249
	Date            : 2008-11-03

This memorandum defines RTSP version 2.0 which is a revision of the
Proposed Standard RTSP version 1.0 which is defined in RFC 2326.

The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for control over 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-19.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.
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 04 Nov 2008 09:15:45 +0100

Hi,

This version tries to address a number of issues logged in the tracker.
A number of the changes are suggested for your review. I also raised a
number of them in separate emails for discussion. Please discuss and
review so that we can ensure that we have the appropriate solution.

This version does not yet address all issues. There are still a few
larger tasks that haven't been addressed in this version. Martin and I
continues to work on these and still try to reach the goal of having a
version without outstanding issues in December so that we can start
performing final review cycles.

The side by side diff:
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-rfc2326bis/draft-ietf-mmusic-rfc2326bis-19-from-18.diff.html

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Sat, 8 Nov 2008 20:58:47 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-19.txt

| 2.2.  RTSP's Relationship to HTTP
| (...)
|    *  Both an RTSP server and client can issue requests.

I am not questioning the need for this. But it might be worth to mention 
somewhere that RTSP agents MUST be ready to handle an incoming requests even 
when they are "waiting" for a response to one of their own requests. Without 
this, we might get into a race condition failure scenario.

Also, RTSP agents MUST be ready to dequeue incoming (chunks of) requests 
whenever they are in the middle of sending a request in the other direction. 
Otherwise, they could get into a complete deadlock if a full request is 
bigger than the TCP receive buffer.

| 13.4.1.  General Usage
| (...) Range: npt=10-15, npt=20-25, npt=30-

I never really understood the need for multiple ranges. It's impossible to 
support this with a user-grade interface. And for advanced uses, I don't see 
the advantage over using multiple PLAY requests (I do see the big 
inconvenience that it's a burden for server vendors to implement, and in fact 
our RTSP server never supported this and will continue to ignore such 
requests).

| 16.19.  CSeq

I wonder why we have it at all. I assume I must be missing something. It made 
sense for rtspu, but now? It is quite trivial to implement for clients and 
servers, but not for proxies.

| D.1.6  Range of Presentation
|  (...) In case of
|  different length the range attribute MUST be given at media level
|  for all media, and SHOULD NOT be given at session level.

This will for sure cause interoperability problems if it's ever used. The 
basic video player for A/V streams won't know what to cope with that.

| D.1.8.  Connection Information
| (...) for type "IP6", this value SHALL be "0:0:0:0:0:0:0:0", i.e. the
| unspecified address according to RFC 4291 

The canonical notation for the unspecified IPv6 address is "::". Then again, 
it might be better to not put an explicit quoted value. The value matters, 
not its notation.

| Appendix J.  Acknowledgements
| (...) Mela Martti

Hist name is Martti Mela.

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic