Subject: [MMUSIC] quit the mail list!

From: "" <[email-masked]>
Date: Sat, 21 Jun 2003 12:39:48 +0800

�����������������ᵽ:
>From:[email-masked]
>Reply-To: [email-masked]
>To: [email-masked]
>Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #79 - 3 msgs
>
>
>
>
>This is an automatic digest of bugs submitted and changed on the RTSP bug
tracker.  To see a list of bugs, visit:
>
>http://sf.net/projects/rtspspec
>
>When replying, please make your Subject line more specific than "Re:
Rtspspec-bugs digest"
>
>
>
>Today's Topics:
>
>   1. [ rtspspec-Bugs-511233 ] Timed PLAY requests has RTP-Info problem
(SourceForge.net)
>   2. [ rtspspec-Bugs-508211 ] Eliminate play queue feature (SourceForge.net)
>   3. [ rtspspec-Bugs-526545 ] Multiple range specifiers (SourceForge.net)
>
>--__--__--
>
>Message: 1
>To: [email-masked]
>From: "SourceForge.net" <[email-masked]>
>Date: Mon, 16 Jun 2003 11:59:11 -0700
>Subject: [rtspspec-bugs] [ rtspspec-Bugs-511233 ] Timed PLAY requests has
RTP-Info problem
>
>Bugs item #511233, was opened at 2002-01-31 16:37
>Message generated for change (Comment added) made by magwes
>You can respond by visiting: 
>https://sourceforge.net/tracker/?func=detail&atid=377744&aid=511233&group_id=2319
4
>
>Category: None
>Group: Fix for DS - Need WG Input
>>Status: Closed
>>Resolution: Wont Fix
>Priority: 5
>Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
>Summary: Timed PLAY requests has RTP-Info problem
>
>Initial Comment:
>In a PLAY with a range header, "time=" can be used to give activation time. This
request shall be 
>responded immediately to the client. In the response the server should give
synchronization data 
>like RTP TS which will be used when the PLAY is activated sometime in the future.
It is hard to 
>impossible for the server to produce such data. If no other PLAY request is done
between request 
>time and activation it is possible to give an accurate TS and sequnce number. But
if another 
>request is activated in the time between, the given RTP TS or sequnce number will
not be correct. 
>
>This problem is the same that queued plays has, see bugreport #477432, but due to
different 
>reasons.
>
>One possible solution would be to introduce a SYNC method which a server can send
at or slightly 
>before activation of a queued or delayed play. This method would carry a RTP-info
header and a 
>range header, giving the information; what is playing and the synchronization
information. 
>
>----------------------------------------------------------------------
>
>>Comment By: Magnus Westerlund (magwes)
>Date: 2003-06-16 20:59
>
>Message:
>Logged In: YES 
>user_id=302620
>
>It has been decieded at IETF 56 and confirmed at the 16th of
>April telecon that time playes are removed. Therefore this
>issue is closed. 
>
>
>
>----------------------------------------------------------------------
>
>Comment By: Magnus Westerlund (magwes)
>Date: 2002-10-30 17:59
>
>Message:
>Logged In: YES 
>user_id=302620
>
>A light solution is proposed in the document. As long as the
>session is in READY state when issuing the timed request and
>not issuing any other request the server can produce the
>correct values directly in the response. 
>
>A heavier solution would require of something like a INFO
>method that is sent in the S->C direction. 
>
>----------------------------------------------------------------------
>
>You can respond by visiting: 
>https://sourceforge.net/tracker/?func=detail&atid=377744&aid=511233&group_id=2319
4
>
>
>--__--__--
>
>Message: 2
>To: [email-masked]
>From: "SourceForge.net" <[email-masked]>
>Date: Mon, 16 Jun 2003 12:05:47 -0700
>Subject: [rtspspec-bugs] [ rtspspec-Bugs-508211 ] Eliminate play queue feature
>
>Bugs item #508211, was opened at 2002-01-25 00:48
>Message generated for change (Comment added) made by magwes
>You can respond by visiting: 
>https://sourceforge.net/tracker/?func=detail&atid=377744&aid=508211&group_id=2319
4
>
>Category: General
>Group: Fixed in CVS/Need WG Approval
>>Status: Closed
>Resolution: Fixed
>Priority: 9
>Submitted By: Rob Lanphier (robla)
>Assigned to: Magnus Westerlund (magwes)
>Summary: Eliminate play queue feature
>
>Initial Comment:
>This issue came up in the RTSP teleconference:
>http://rtsp.org/2002/telecon/minutes23Jan.html
>
>Queued playing, as describe in section 10.5, is a feature that has many problems
with it (e.g. 
>#477424)  The members on the telecon felt that support for this feature is
sufficiently weak that 
>rather than fixing this feature, it may be more appropriate to eliminate it, and
come up with a 
>simpler play/pause model to replace it.
>
>----------------------------------------------------------------------
>
>>Comment By: Magnus Westerlund (magwes)
>Date: 2003-06-16 21:05
>
>Message:
>Logged In: YES 
>user_id=302620
>
>No comments. closing bug.
>
>----------------------------------------------------------------------
>
>Comment By: Magnus Westerlund (magwes)
>Date: 2002-10-30 17:55
>
>Message:
>Logged In: YES 
>user_id=302620
>
>The queued play functionality has been eliminated in the
>version checked in CVS. It can in the future be brought back
>with extension draft. However for the moment no one is
>intressted in doing the work necessary to fix it. 
>
>If no protest has been raised after this next version 02 has
>been out a while this issue will be closed. 
>
>----------------------------------------------------------------------
>
>Comment By: Rob Lanphier (robla)
>Date: 2002-05-24 20:58
>
>Message:
>Logged In: YES 
>user_id=3796
>
>From the minutes at IETF 53:
>http://www.dmn.tzi.org/ietf/mmusic/53/53-mmusic-minutes.txt
>
>Queued play (multiple PLAY requests, with the server
>responsible for serializing them): makes the state machine
>much more complex.  The proposal is to allow multiple ranges
>in PLAY as a substitute, to be specified as an extension to
>the core document.  Henning Schulzrinne
><[email-masked]> maintained that the Queued play
>mechanism does not really affect the state machine.  Magnus
>replied that this was technically correct, but it raises
>other issues.  Henning argued that removal from the core
>specification could remove functionality needed by every
>server.  He was concerned that mapping of multiple ranges
>(the proposed substitute) might be difficult.  This subject
>will be discussed further as part of Thursday's lunch
>meeting -- and subsequently on the list.
>
>
>
>----------------------------------------------------------------------
>
>Comment By: Rob Lanphier (robla)
>Date: 2002-05-24 20:42
>
>Message:
>Logged In: YES 
>user_id=3796
>
>Last email discussion (starting point):
>http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00105.html
>
>----------------------------------------------------------------------
>
>Comment By: Rob Lanphier (robla)
>Date: 2002-05-24 20:36
>
>Message:
>Logged In: YES 
>user_id=3796
>
>Discussed on April 17 telecon:
>http://rtsp.org/2002/telecon/minutes17Apr.html#section3.5
>
>*  RESOLUTION: take discussion to list: starting proposal:
>multiple ranges put forward as substitution for queued play
>*  RESOLUTION: group recommends that this is optional, but
>client needs a way to negotiate
>
>
>
>----------------------------------------------------------------------
>
>You can respond by visiting: 
>https://sourceforge.net/tracker/?func=detail&atid=377744&aid=508211&group_id=2319
4
>
>
>--__--__--
>
>Message: 3
>To: [email-masked]
>From: "SourceForge.net" <[email-masked]>
>Date: Tue, 17 Jun 2003 07:18:13 -0700
>Subject: [rtspspec-bugs] [ rtspspec-Bugs-526545 ] Multiple range specifiers
>
>Bugs item #526545, was opened at 2002-03-06 19:47
>Message generated for change (Comment added) made by magwes
>You can respond by visiting: 
>https://sourceforge.net/tracker/?func=detail&atid=377744&aid=526545&group_id=2319
4
>
>Category: General
>Group: Fixed in CVS/Need WG Approval
>>Status: Closed
>>Resolution: Fixed
>Priority: 5
>Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
>Summary: Multiple range specifiers
>
>Initial Comment:
>In the RFC the BNF allows for multiple range
>specifiers. This was intended to be used to specify
>diffrent formats of the same range. But the text and
>BNF does not express this. Therefore it has been
>interpreted by me (Magnus Westerlund) to be a
>possibility to specify multiple different ranges. 
>
>The main question is if this functionallity is useful
>at all? It is similar to queued plays but have some
>differencies; 1. Does not allow addition after the
>first play has been issued; 2. Have fewer issues on how
>to be handled, like, no RTP-Info, state transitions
>problems.
>
>It seems fairly obvious that it should be an optional
>behavior but should it be part of the core spec or an
>extension? What mechanism should be used for discovery
>of support? 
>
>If implementing this feature the behavior related to
>pause need to be resolved. To be able to resume a play
>request containing multiple ranges the server must
>singal unambigous in what range and point it actually
>did pause. A proposal discussed during the telecon 6
>march 2002 was to do the following:
> 
>1. C->S PLAY range=10-20,30-60,15-45.
>2. S->C 200 OK
>3. wait approx 11 sec.
>4. C->S PAUSE
>5. S->C 200 OK, range=31.2-60,15-45
>6. User wants to resume.
>7. C->S PLAY range=-60,15-45
>8. S->C 200 ok
>
>By removing the inital range in point 5 the client
>ensures that the server continues where it halted. And
>by specifying all the ranges remaining it will play
>exactly the intended. 
>
>If point 7 would be done without range the playback
>would be from 31.2 to end of media.
>
>
>
>
>----------------------------------------------------------------------
>
>>Comment By: Magnus Westerlund (magwes)
>Date: 2003-06-17 16:18
>
>Message:
>Logged In: YES 
>user_id=302620
>
>No comment received on this. closing bug. 
>
>----------------------------------------------------------------------
>
>Comment By: Magnus Westerlund (magwes)
>Date: 2002-10-30 18:58
>
>Message:
>Logged In: YES 
>user_id=302620
>
>This has been written up and included in the CVS. 
>
>----------------------------------------------------------------------
>
>You can respond by visiting: 
>https://sourceforge.net/tracker/?func=detail&atid=377744&aid=526545&group_id=2319
4
>
>
>
>
>End of Rtspspec-bugs Digest
>
>
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/mmusic
>

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