Subject: [MMUSIC] Minutes for RTSP telecon April 16

From: Rob Lanphier <[email-masked]>
Date: 18 Apr 2003 11:50:14 -0700

Hi all,

Below are the minutes from the last RTSP conf call.  They are also
online here:

http://rtsp.org/telecon/

Rob
---
Rob Lanphier, Helix Community Coordinator - RealNetworks
http://helixcommunity.org http://rtsp.org http://realnetworks.com

= Attendees =
 * Magnus Westerlund
 * Rob Lanphier
 * Aravind Narasimhan
 * Sean Sheedy
 * Andrea Basso
 * Thomas Zeng
 * Anders Klemets

= Bug discussion =
   
== Bug 513737 ==

 * http://rtsp.org/bug513737
 * Magnus: Who will write it up?
 * Aravind: if I get time
 * Aravind: in RTSP, range is defined as half-open interval
 * Aravind: with negative ranges, there's no way to get to zero
 * Magnus: is this really a problem?
 * Thomas: most video file have a frame at time=0
 * Magnus: we could define a corner case for 0.  I.e. the range would
stay a half-open interval with the first number closed and the last
number open, except in the case of 0.
 * Aravind: What about reversing the half-open interval
 * Rob: I like this
 * Andrea: what about I-frames
 * Thomas: it works the same as forwards
 * Andrea: it seems that consistency is more expressive
 * Aravind: now there's no way to start at a given time. Also the range
header becomes harder to deal with because which interval is open
depends on the Scale header.
 * Sean: define range to always mean that smallest range that is
possible.
 * Thomas: changes existing implementations
 * Magnus: I'm don't think it does
 * Thomas: I'm still concerned
 * Magnus: we need a writeup
 * Sean: we could make range closed on both ends, rather than having it
as half open. this definition change probably won't change current
implementations (at least, not by enough to break things).
 * Thomas: why is 2326 the way it is
 * Rob: thought was about stringing together multiple ranges
 * conclusion: need more discussion on email

== Bug 533691 and Bug 513880 ==
 * http://rtsp.org/bug533691 &  http://rtsp.org/bug513880
 * Aravind to write up, progress?
 * Magnus: need more discussion on email

== Issue #2 in Aravind's email ==
 * See
[http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg01388.html Aravind's email]
 * Magnus: it is ok to have backwards clock ranges because you may have
film index by clock ranges and you may want to go backwards in time.
 * Aravind:  It seems to me that clock ranges refer to absolute time and
that they shouldn't be allowed to go backwards.
 * magnus: Don't see a problem with clock ranges going backwards.

== Bug 556061 ==
 * http://rtsp.org/bug556061
 * Fix state machine to allow for REDIRECT at any time, including in
INIT state.
 * Magnus: needs writeup

== Bug 556295 ==
  
 * http://rtsp.org/bug556295 
 * Client issues PAUSE while server ready
 * Allow: needs explanation.
 * Magnus: been discussed...needs writeup
 * Thomas: I can write this up

== Remove timed PLAY and PAUSE? ==
 * Discussed at San Francisco IETF
 * Proposal: Remove timed PLAY and PAUSE. 
 * Magnus: With time I mean the specified usage of the time parameter in
the Range header.

== Stream switching requirements document (Phillipe Gentric) ==
 * Waiting for writeup

== Offer Answer for RTSP ==
 *  Anybody willing to write requirements and use case?
 *  Rob: no one really wanted to commit to this
 *  Thomas: Phillipe may be interested
 *  Andrea: May also be interested
 *  Andrea will check into thsi

== IANA registration comments? ==
 * Magnus: send comments to the list

== Ways to allow direct media destination to other than own IP address
==
 * Magnus: Phillipe Gentric volunteered to look into this

== Multiple SSRC in RTSP ==
 * Magnus: Redefine RTP-Info to solve issue?
 * Thomas: this is because of stream switching
 * Magnus: no, relaying different sources
 * Magnus: e.g. relaying MBONE sessions
 * Thomas: our server mixes
 * Aravind: what about multiple participants?
 * Thomas: those should be different streams
 * Rob: that's inconsisent with standard use of RTP
 * Rob: we can solve this for the single SSRC case in RTP-Info, and then
 * Aravind: are we requiring SSRC in RTP-Info now?
 * Magnus: no...just explaining the limitation
 * Aravind: what about SSRC collision resolution?
 * Thomas: doesn't need to involve RTSP
 * Magnus: client is responsible for resolving
 * Rob: RTP-Info should be honored as initialization info only...RTCP
takes over after that
 * Magnus: problem is when server is invited to existing RTP session
 * Thomas: can't really think about this problem without someone who's
done it
 * Magnus: need more discussion
 * Thomas: I think Rob's proposal is sound
 * Aravind: what happens when client requests SSRC?
 * Magnus: comparing 2326 to current version.  Non-normative suggestion
to use SSRC from client.
 * Thomas: current 2326bis SSRC request is for unicast only
 * Aravind: multicast source gateway to unicast, the client may request
SSRC...how does server honor?
 * Magnus: need to whether reconsider SSRC requests are useful or even
valid
 * Aravind will write up

== How to distinguish the updated specification ==
 * Magnus: Need to consider bumping current version number to RTSP/1.1
 * Thomas: we should increase version number
 * Magnus: if we work quickly, we can pull this off
 * Thomas: I can write this up

== Next meeting ==

 * Monday, April 28, at 9am PDT (GMT-7)/18:00 CMT (GMT+2)

== Postponed items ==
 * Bugs
   * Warning header: For further discussion.
   *  RTSP servers behind NATs. Use case seems to exist. Requires
someone to write scenario document. Decide on how to go forward compared
with public network servers. Time line considerations.
   * RTSP ALG for Linux netfilter. (Tom Marshall)
 * How to get things into the spec?
 * New Things
   *  Specification review. Plan to look through the latest draft and
see what comments people has about it.
   * http://rtsp.org/bug631148 <http://rtsp.org/bug556061> better Info
on RTSP proxies.
   *  http://rtsp.org/bug631957 Use of # and ? in RTSP URLs?
   *  http://rtsp.org/bug633148 Use of TCP and UDP.
   * http://rtsp.org/bug633779 SET_PARAMETER responses.

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