Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #79 - 3 msgs

From: [email-masked]
Date: Fri, 20 Jun 2003 20:38:42 -0700

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=23194

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=23194

--__--__--

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=23194

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=23194

--__--__--

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=23194

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=23194

End of Rtspspec-bugs Digest

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