Subject: [MMUSIC] RTSP: Minutes from March 6 telecon

From: Rob Lanphier <[email-masked]>
Date: Thu, 14 Mar 2002 13:36:14 -0800 (Pacific Standard Time)

Hi all,

Sorry for the delay on this.  Minutes available here:
http://rtsp.org/telecon

...as well as included below.

Rob

  Rtsp Tc Minutes06 Mar2002

------------------------------------------------------------------------

   1. Administrivia <#line3>
         1. Agenda <#line4>
         2. Attendees <#line7>
         3. IETF meeting <#line26>
   2. Issue discussion <#line35>
         1. Queued play <#line37>
         2. 477424 and 477432 <#line84>
         3. 493265 <#line90>

  Administrivia

    Agenda

    * http://rtsp.org/2002/telecon/agenda06Mar.html

    Attendees

*Telecon:*

    * Milko Boic
    * Tom Marshall
    * Anders Klements
    * David Walker
    * Rob Lanphier
    * Magnus Westerlund
    * Anne Jones
    * Colin Perkins
    * Thomas Zeng
    * Aravind Narasimhan
    * Sean Sheedy

*IRC:*

    * Jonathan Sergent
    * Virago

    IETF meeting

    * RL: Suggestion: Thursday lunch?
    * RL: how does agenda sound?
    * AN: does that include state machine?
    * RL: yes
    * RL: can MW present?
    * MW: yes
    * RL: 5 min for state machine

  Issue discussion

    Queued play

    * Introduction to discussion
      <http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00105.html>

    * RL: Henning wants to keep it, everyone else want to eliminate it
    * RL: Is that a fair statement?
    * AN: I wouldn't mind seeing it go
    * JS: my question is whether there are enough implementations to
      take it to draft standard.
    * MW: several ranges in the range header are possible
    * RL: really?
    * MW: BNF allows it
    * RL: any implement that?
    * Virago: s12.29 says "Range" ":" 1\#ranges-specifier so spec would
      need modified a bit
    * MW: we've implemented that in the server
    * AN: what is queued play useful for?
    * RL: May be useful in a SMIL file
    * RL: could be faked using separate SMIL
    * AK: classic queued play is solution looking for problem
    * AN: even HGS said it shouldn't be required.
    * MW: I don't have use case
    * AN: if we make it an optional feature, would that be ok
    * MW: still need to work out how it works
    * MW: rather have separate extension
    * RL: I would agree
    * AN: agreed
    * TZ: agreed
    * AN: queued play interaction with MUTE/UNMUTE
    * AN: need to make sure that we have decision
    * MW: seems orthoganal
    * RL: not necessarily
    * AN: need to figure out how to mesh with state machine
    * NEW ISSUE: BNF allows multiple range specifiers, prose doesn't
    * RESOVLED: queued play comes out of core RTSP specification
    * SS: should play until end
    * RL: agreed
    * MW: in the response, should contain range?
    * SS: recommend doing that
    * SS: draft should recommend that play response should contain range
    * MW: agreed. WHat does the spec currently say?
    * MW: I don't see anything
    * SS: i don't remember anything
    * RL: pause or play?
    * MW: pause. good for keeping ui up to date
    * MB: doesn't really matter what server thinks. UI is going to be
      different
    * SS: clients still want that information. Response from server is
      the only way to get a good approx of where server is.
    * SS: approx of current position is good enough for some
      implementations
    * SS: good thing for spec to recommend this
    * RL: seems reasonable

    477424 and 477432

    * http://rtsp.org/bug477424 - How to queue timed plays?
    * http://rtsp.org/bug477432 - RTP info and queued plays

    * Both issues are moot if we eliminate queued play

    493265

    * http://rtsp.org/bug493265

    * TZ: What happens when client has range in pause?
    * AN: we resolved that only open ended range allowed
    * MW: Should nail down that time- (not -time)
    * TM: how about just a time instead of range in pause
    * MB: pause request semantics...can be this time or later
    * RL, TZ, MW: agreed
    * MB: need to have information about when the server stopped,
      otherwise client gets really complicated if/when multiple ranges
      are involved (assuming we allow this)
    * MW: good point
    * MB: It would be better to have the server keep the range around
    * MB: so that play without range resumes in current range specifier
    * TM: allow for "Range: -"?
    * TZ: backwards compat issues
    * MW: how about client echos back server PAUSE response?
    * MB: range isn't exact
    * MW: in response, the client can alter the begin value of the
    * range
    * RESOLVED: play until end of clip (not stop at 30 seconds).
      Recommend that server return Range header on PAUSE. Server should
      return "Range: 22-" (multiple range extension may be different)
    * RL: anyone want to take on feature tag proposal
    * SS: I'll do that
    * ACTION ITEM: SS put together feature tag proposal for client agg

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