Subject: [MMUSIC] RTSP Telecon: April 17

From: Rob Lanphier <[email-masked]>
Date: Tue, 14 May 2002 20:46:57 -0700 (Pacific Daylight Time)

Hi all,

Here's the minutes from the April 17 RTSP telecon.  Also available here:
http://rtsp.org/2002/telecon/minutes17Apr.html

Rob
----

  RtspTcMinutes17Apr2002

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

   1. Attendees
   2. Agenda
   3. Issues
         1. Telecon frequency
         2. Ready-NM state
         3. Announce before record?
         4. Redirect and the state machine
         5. Queued play
         6. Interop logistics
         7. Feature tag. "Supported" header
         8. Transport model
         9. Connection or connectionless?

  1 Attendees

    * Colin Perkins
    * Anne Jones
    * Sean Sheedy
    * Jonathan Sergent
    * Thomas Zeng
    * Anders Klemets
    * Joerg Ott

  2 Agenda

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

  3 Issues

    3.1 Telecon frequency

    * RESOLVED: skip next meeting....but reevaluate on May 15 telecon

    3.2 Ready-NM state

    * JS: seems like it gates on the SETUP/TEARDOWN post-play discussion
    * RL: agreed
    * JO: don't want to overload a state
    * RESOLVED: postpone until after setup/teardown discussion

    3.3 Announce before record?

    * JS: more general issue: record underspecified
    * RESOLVED: take overall RECORD issue to the list

    3.4 Redirect and the state machine

    * JS: makes sense for server sending redirect to reset state
    * RL: agreed
    * RESOLUTION: REDIRECT resets state on original server

(invalids session)

    3.5 Queued play

    * JO: HGS brought up the editing issue. He thought that multiple
      ranges in same request would satisfy requirement
    * SS: We do soemthing similar....problem with queued play doesn't
      provide constant timebase
    * SS: if assembling clips A, B, and C, can't rewind from C to B
      without rebuilding list anyway
    * SS: would like to treat list of clips as one entity
    * RL: multiple range may solve this
    * JS: range when scale is negative is more general issue
    * JS: proposed resolution; starting time is always first, even if
      larger than end of range
    * JS: multiple ranges is a lot more appealing than queued play
    * RESOLUTION: take discussion to list: starting proposal: multiple
      ranges put forward as substitution for queued play
    * JS: another question to ask: should be optional or required?
    * RL: My recommendation is that this is optional
    * AK: how would client and server agree that it's not required
    * RL: need feature tag
    * RESOLUTION: group recommends that this is optional, but client
      needs a way to negotiate
    * (skipping ahead)

    3.6 Interop logistics

    * RL: shooting for end of the week. Ashley Wee is doing the work
    * CP: need to understand how to validate
    * ACTION ITEM: send out feature list by end of week (no promises)

    3.7 Feature tag. "Supported" header

    * AK: Supported not required, unless optional features are needed
    * SS: don't understand...would like to always require, because old
      features are not clear.
    * RESOLUTION: new feature negotiation not required, but if not
      supported, then assume minimal implementation

    3.8 Transport model

    * SS: we were only ones that implemented UDP, I think
    * ACTION ITEM: SS, ask for other UDP implementations

    3.9 Connection or connectionless?

    * AJ: we have connectionless
    * SS: we do too
    * AK; so do we
    * RL: anyone implement connection-based?
    * SS: we do. have activity timeout
    * AK: our server stops sending data if TCP session goes away, but
      session remains valid
    * RESOLUTION: take to the list. RL to kick off connection-based,
      connectionless discussion on MMUSIC
    * ACTION ITEM: RL, bring up connection-based/connectionless issue

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