Subject: [MMUSIC] Progressing draft-ietf-mmusic-rfc2326bis

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 21 Nov 2013 12:23:14 +0200

Folks,

the IESG is reviewing the RTSP 2.0 spec below:

http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/

Before progressing the draft, I have been asked by the IESG to check
with the MMUSIC WG whether or not people still think it is worthwhile
publishing this spec. In particular, they would like to know what level
of deployment we can expect once the spec is published.

Your input is appreciated.

Thanks,

Gonzalo

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 21 Nov 2013 10:38:21 +0000

I am feeling terrible to say this as obviously much effort has gone into this document.

But to me, this spec is simply too late to have any chance to get deployed. Today there are lots of massive RTSP based streaming systems, yet they are obsolete and present lots of scalability and management issues. They also have lots of interop issues as not every vendor actually implemented RTSP in the same way.

Providers are not very eager to ditch these systems right a way. The ones that pull the trigger are mostly ditching RTSP altogether and moving towards http/cdn based streaming. Chances are quite slim for them to switch from RTSP 1.0 to RTSP 2.0. Needless to say, RTSP is a difficult protocol to both implement and deploy/manage.

Whether this should this draft from moving forward, that is a separate discussion, I think.

On Nov 21, 2013, at 12:23 PM, Gonzalo Camarillo <[email-masked]> wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Nov 2013 11:55:04 +0100

> of deployment we can expect once the spec is published.

Hi,

I know that 3GPP in TS 26.234 (12.1.0) do reference a feature in RTSP 2.0:

Section N.2
“RTP over TCP” (RFC4571):  The RTP packets are tunnelled over separate
TCP connections. A major difference compared to the “RTSP/RTP
Interleaving” mode (RFC 2326) is, that the client opens one or more
separate TCP connections to the server for the RTP transport. This
mechanism is described in the RTSP 2.0 draft
(draft-ietf-mmusic-rfc2326bis-18.txt).

Thus, I expect this reference to be updated when RTSP 2.0 gets implemented.

I would also note that PSS (in section 5.5.2 of 26.234) have back fitted
several of RTSP 2.0 specification features into their RTSP 1.0 usage.
These include:

- Supported header
- Pipelining

They also have their own versions of time-shift handling and
asynchronous notifications.

I have also received this email from Scott Taylor
([email-masked])

> Thank you for your work putting together the RTSP 2.0 spec. It's
> exactly what I needed to address the shortcomings of RTSP 1.0 in my
> current project. I'm the lead developer on a software product that
> performs live streaming, synchronized recording and playback of
> simulation environments.

I think this points to that RTSP has other uses than just normal
audio/video and that there exist other cases where one needs control of
playout and transmission of inter time related information or streams.

I think there are several arguments why RTSP 2.0 should be published
even if there is no response to question for implementing RTSP 2.0.

1. That the future consumers of RTSP 2.0 specification may not even know
they needed it at this point

2. That leaving in place without warning a broken specification like
RTSP 1.0 is bad considering that we have a specification that has less
issues. So why not publish it? If IESG are worried about the effect of
obsoleting RTSP 1.0, then lets discuss that issue. Not stopping
publication of RTSP 2.0.

3. There are features in use out on the network in RTSP 1.0 that are
primarily specified in RTSP 2.0. The fact that we in IETF couldn't keep
the version number hasn't stopped industry forums to use the specified
extensions and deploy them within RTSP 1.0.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
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: Christian Groves <[email-masked]>
Date: Fri, 22 Nov 2013 09:58:07 +1100

Hello

I would support publishing this spec. Draft ITU-T H.248.66 makes 
reference to the RTSP2.0 work. It has been held up for a couple of years 
waiting for the RTSP2.0 draft to be published. It would be good to put 
this to bed.

Regards, Christian

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 25 Nov 2013 18:14:01 -0500

On 11/21/13 5:23 AM, Gonzalo Camarillo wrote:
> publishing this spec.
In short: Yes.

RTSP 2.0 provides a number of clarificiations, error fixes and updates 
to RTSP 1.0, which at this point is over 15 years old (see Appendix I 
for a list of those changes), and while RTSP 2.0 is not backwards 
compatible with RTSP 1.0 (in some cases due to underspecification of 
RTSP 1.0), many of the clarifications may prove helpful to implementers 
of RTSP 1.0, even if they don't migrate.

RTSP 2.0 also includes new functionality such as IPv6 and a companion 
document to assist with NAT traversal, which are just 2 examples of 
features needed in today's environment.

On a non-technical note, the WG agreed to do this work and the work has 
essentially completed at this point, with a significant amount of effort 
by the authors, incl. updates to address several in-depth reviews more 
recently. We usually do not apply a subjective value-judgement to 
whether a document should be published this late in the game (unless 
it's potentially harmful), and again, in lieu of the maturity level and 
effort that has been put into this document, it would not be reasonable 
to start doing that here.

>   In particular, they would like to know what level
Clearly RTSP does not have the traction it used to have with HTTP 
adaptive bit-rate seemingly being all the rage these days. However, a 
couple of points to consider here:
1) If it doesn't get published, it won't get deployed.
2) Some of the clarifications/updates provided by the RTSP 2.0 spec are 
of use to RTSP 1.0 implementations as well and hence may prove helpful 
with resolving existing bugs (I've personally experienced this with 
other protocols)
3) While the people on this list may or may not indicate their plans 
around deployment, RTSP is a fairly well-known protocol with a large 
body of potential implementers beyond those subscribed to this mailing 
list. My personal experience with other protocols shows that more people 
look at these things than you may think (outside the WG).

I don't see any downside to publishing the spec, but based on the above, 
there are several good reasons to publishing it and hence I'm in favor 
of doing so.

Thanks

-- Flemming