Subject: [MMUSIC] Minutes from February 20 telecon

From: Rob Lanphier <[email-masked]>
Date: Mon, 25 Feb 2002 17:47:38 -0800 (Pacific Standard Time)

Hi all,

Here are the minutes from last week's RTSP telecon:

http://rtsp.org/2002/telecon/minutes20Feb.html

They're also included below.

Enjoy!

Rob
----

  Rtsp Tc Minutes20 Feb2002

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

   1. Administrivia <#line3>
         1. Attendees <#line5>
         2. Meeting in Minneapolis <#line22>
   2. Issue discussion <#line28>
         1. 477428 <#line30>
         2. 483356 <#line41>
         3. 493270 <#line83>
         4. 506412 <#line94>

  Administrivia

    Attendees

    * Milko Boic
    * Magnus Westerlund
    * Rob Lanphier
    * Jonathan Sergent
    * Anders Klemets
    * Colin Perkins
    * Joerg Ott
    * Sean Sheedy
    * Aravind Narasimhan
    * Tom Marshall
    * Thomas Zeng
    * Jeff Ayars

Agenda: http://rtsp.org/2002/telecon/agenda20Feb.html

    Meeting in Minneapolis

MMUSIC meets on Monday.

BOF - Tentatively Tuesday, Rob to look into room (lunch)

  Issue discussion

    477428

    * http://rtsp.org/bug477428
    * JS: I think it's not allowed
    * MW: Did you see my state machine?
    * RL: (notes not many have grokked it)
    * JS: Not legal per previous resolution
    * MW: agreed

RESOLUTION: not allowed, as per point a of email

    483356

http://rtsp.org/bug483356

    * JS: Use of "*" doesn't seem right given proxies
    * TM: proxy will use session
    * JA: Use agg url, short of that, use "base" url, short of that, use
      session
    * JS: some servers allow arbitrary aggregation
    * JA: seems pretty cavalier for a client to assume that this is legal
    * JS: if agg control, then the URL doesn't necessarily have any
      semantics
    * JS: how does one validate that URL?
    * TM: can play message be sent with multiple session ids
    * JS: session not defined as multi-value feature
    * JA: perfectly happy without relying on play URL
    * JA: don't like "*"
    * JS: Could specifically say that servers shouldn't try to validate URL
    * RL: url strictly informative
    * JS: server SHOULD not validate url
    * MW: we should disallow the media URL
    * RL: what does a server allow and what not?
    * JS: can say client should use presentation URL
    * AK: presentation URL from first session created will be what the
      play URL is
    * RL: how about a bunch of shoulds (including recommendation for
      logging)
    * JA: can't trust PLAY url anyway
    * TZ: it's ok to use the first SDP
    * JS: are server writers out ahead of client writers?
    * JA: yes
    * TZ: multiple urls in play request?
    * JS: not allowed by grammer
    * JA: how about host/sessionid
    * JS: client aggregation is not the norm, and we shouldn't optimize
      for it
    * TZ: seem to be shutting down future opportunites
    * JS: you want to report presentation url
    * AN: we should consider adding a method called COMPOSE or having an
      initial SETUP to negotiate the presentation URL with the server
      for a given session, especially if the session is going to
      aggregate stream URLs from multiple sources.
    * RL: possible resolution? client SHOULD send the presentation URL
      as defined by session description; server MAY refuse play request
      if presentation URL doesn't match
    * RL: how about a client aggregation require tag?
    * AK: session header is optional
    * TM: (reads spec)
    * JS: have informative note explaining why it's not a must; explain
      that only when not possible, not when not convenient
    * RESOLVED: client SHOULD send the presentation URL as defined by
      session description; server MAY refuse play request if
      presentation URL doesn't match. Have informative note explaining
      why it's not a must; explain that only when not possible, not when
      not convenient
    * ACTION ITEM (no owner yet): put together feature tag proposal for
      client agg

    493270

    * http://rtsp.org/bug493270
    * RESOLVED: this is solved in MUTE/UNMUTE proposal
    * TZ: name MUTE has audio connotations
    * JS: means that when resumes (UNMUTE) that synch is maintained
    * JA: waht about PAUSE
    * JS: PAUSE should be same as PLAY
    * TM: does server have to fail
    * RL: no....just has the option
    * JS: it can be bw compat

    506412

    * http://rtsp.org/bug506412
    * JS: allows TEARDOWN on individual streams
    * MW: tear down all media session goes away
    * JS: it only invalidates the session id if the presentation url is
      used in TEARDOWN
    * MW: could disallow in PLAY state
    * JS: what is that useful for?
    * JA: language track switching
    * AJ: language tracks useful
    * JS: spec not clear if setup new url while playing
    * MW: state machine is currently insufficient anyway
    * JA: because we have MUTE/UNMUTE, and because we have mixing of
      agg/no agg control, it's hard to get back into ready state
    * JA: disallow in PLAY state, but allow in READY state
    * RL: perhaps we need an option tag
    * RL: server may refuse
    * RESOLUTION: client MAY send TEARDOWN of stream URL. Server MAY
      refuse. Need proposal for option negotiation. When Server refuses,
      MUST return "method not allowed in this state" with proper Allow
      header
    * MW: need to clarify when session goes away
    * AK: but then client may not know how to cope
    * JS: must use presentation url
    * TZ: Treat TEARDOWN as method to relinquish the session ID
    * JS: should we depart from current RFC for this
    * AK: client may not expect session to go away
    * JS: client should be prepared to not get a session id back, and
      that's the signal that it's gone
    * TZ: how about having the * for teardown
    * RL: how about allow * or presentation url for session teardown
    * RESOLVED: allow * or presentation url for session teardown
    * OPEN ISSUE: per media stream URLs, what does teardown mean?

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