Re: [MMUSIC] RTSP: Speed header

[Magnus Westerlund <[e-mail]>]

Joseph Pallas skrev:
> On 4/26/07, Jean-Francois Mule <[e-mail]> wrote:
>> Some of this was discussed back then when the 2.0 draft was started. It
>> would be nice to get some specific details based on the current 2.0
>> drafts, especially the "things [in the current 2.0 draft] that no one
>> uses", and what results in "poor [1.0] interoperability".
> 
> I think the 2.0 draft is much better than 1.0 in these respects; I
> won't bother to enumerate problems with 1.0.  For 2.0, we've already
> identified the Speed header as one issue.  I think the lingering
> references to connection-less transports are unnecessary, although
> probably harmless.

We are discussing on how to clean up the 2.0 spec, and I think that one 
thing that will consider is how to write the transport parts. I know of 
only a single UDP based RTSP transport which has had very limited 
deployment as it was a top-set box of some kind. In my opinion we can 
completely remove the consideration of running RTSP 2.0 over 
non-reliable transport.

   There is no means to negotiate a content type for
> GET_PARAMETER and SET_PARAMETER, so their interoperability remain
> dubious.  (And I've already complained that there is no specification
> for "text/parameters" despite its usage both in the field and in the
> examples.)

Yes, I agree with that this isn't complete. Are you willing to write an 
definition of text/parameters?

> 
> I do not know whether any implementations are using the cache-related
> features.  I'd be interested to hear what use is being made of them.
> I think it would be quite challenging to implement a caching proxy
> that supports independently-developed clients.

I would also like to hear confirmation on that they implement this. I 
know Real has some proxy and it would be interesting to hear more about 
if it handles the caching features. But, these are cleaned up and I 
don't think it is that complicated to build a caching proxy. But there 
are a lot of streams out there that can't be cached because they are 
dynamically created for different users.

> 
> Having stated my concern about unused features, I would add this.  I
> think it is telling that the ANNOUNCE method from RTSP 1.0 may have
> never been used as specified (for unsolicited session descriptions)
> but was "repurposed" by some implementations to provide a way to
> signal various asynchronous stream events.  I agree with the decision
> to remove RTSP 1.0's ANNOUNCE from RTSP 2.0, but I'm concerned that
> failing to include that notification functionality in RTSP 2.0 simply
> means that incompatible extensions will be created. (I would be
> especially sad to see ANNOUNCE-as-it-is-used re-introduced as an RTSP
> 2.0 extension.)
> 

Do I understand you correctly that you rather see the asynchronous event 
signalling, like end of stream, to be in the base spec rather than as a 
extension specification. There was
http://tools.ietf.org/id/draft-ietf-mmusic-rtsp-announce-01.txt

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic