Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #53 - 12 msgs

From: [email-masked]
Date: Wed, 30 Oct 2002 09:00:07 -0800

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-494957 ] 457 Invalid range for aggregate ([email-masked])
   2. [ rtspspec-Bugs-500803 ] Clarficiation on state machine ([email-masked])
   3. [ rtspspec-Bugs-500875 ] State diagram clarifications ([email-masked])
   4. [ rtspspec-Bugs-500906 ] Client liveness criteria vague ([email-masked])
   5. [ rtspspec-Bugs-503949 ] Range header format for PAUSE is unclear ([email-masked])
   6. [ rtspspec-Bugs-506412 ] RTSP Teardown functionallity ([email-masked])
   7. [ rtspspec-Bugs-506684 ] Allow Rtp-Info header in more contexts ([email-masked])
   8. [ rtspspec-Bugs-507332 ] RTSPS/TLS support ([email-masked])
   9. [ rtspspec-Bugs-507408 ] clarify use of interleaved param ([email-masked])
  10. [ rtspspec-Bugs-507884 ] Should sequnce numbers be consecutive ([email-masked])
  11. [ rtspspec-Bugs-508211 ] Eliminate play queue feature ([email-masked])
  12. [ rtspspec-Bugs-511233 ] Timed PLAY requests has RTP-Info problem ([email-masked])

--__--__--

Message: 1
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 04:08:50 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-494957 ] 457 Invalid range for aggregate

Bugs item #494957, was opened at 2001-12-19 10:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494957&group_id=23194

Category: General
>Group: Fixed in CVS/Need WG Approval
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
Summary: 457 Invalid range for aggregate

Initial Comment:
When shall 457 be used in the case of aggregated control?

In a single media session its unambigous to when a range is valid or not. But in the aggregated 
case the range given in a play can be valid for one media and invalid for another. Which of the two 
following interpretetations should be used?

1. A aggregate range is invalid only if all media see it as invalid.
2. A aggregate range is invalid in any media see it as invalid.

I would argue for reasons of simplicity and clearnes that case 2 is the better.  

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 13:08

Message:
Logged In: YES 
user_id=302620

This has been clarified in the specification so that a given
range in a PLAY request must be inside the bounds of at
least one of the medias part of the aggregate. Otherwise a
457 response shall be given. The same rules apply for PAUSE.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494957&group_id=23194

--__--__--

Message: 2
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 04:21:47 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-500803 ] Clarficiation on state machine

Bugs item #500803, was opened at 2002-01-08 14:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500803&group_id=23194

Category: General
>Group: Fixed in CVS/Need WG Approval
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: Clarficiation on state machine 

Initial Comment:
In appendix A there is a description of a state machine. This state machine is only representing a 
session with a single media. It is not valid in the case of a session with two or more medias,  
used with both aggregated and non-aggregated control. 

To help sorting out the aggregated, non-aggregated control unclarities a complete state machine 
would be helpfull. This task I belive is a larger one. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 13:21

Message:
Logged In: YES 
user_id=302620

A new state machine has been discussed on the WG and
published in the 01 version. It is fairly stable with a few
smaller corrections performed to now. 

Closing this issue.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500803&group_id=23194

--__--__--

Message: 3
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 04:30:24 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-500875 ] State diagram clarifications

Bugs item #500875, was opened at 2002-01-08 17:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500875&group_id=23194

Category: None
>Group: Fixed in CVS/Need WG Approval
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Sean Sheedy (seansh)
Assigned to: Nobody/Anonymous (nobody)
Summary: State diagram clarifications

Initial Comment:
My understanding is that the state diagram in Appendix
A is per-session, not per-client.  However, this is not
explicitly stated.  This should be made clear in the
description.

Errors within the media server (series 5xx) often leave
a stream in an unplayable, unrecoverable state in which
the client's only option is to tear down the session
and start over.  This should be reflected in the state
diagram.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 13:30

Message:
Logged In: YES 
user_id=302620

The state machine has been updated and clearly represent a
RTSP session. The effect 5xx error codes may have has also
been clarified. A 5xx response is in general recoverable
from. But the server is allowed to terminate the session for
errors of unrecoerable nature. The client will detect this
when issuing another request to that session and receive a
454 (Session Not Found) as response. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-01-14 11:08

Message:
Logged In: YES 
user_id=302620

This one is realted to bug report #500803

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500875&group_id=23194

--__--__--

Message: 4
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 05:39:30 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-500906 ] Client liveness criteria vague

Bugs item #500906, was opened at 2002-01-08 18:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500906&group_id=23194

Category: None
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean Sheedy (seansh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Client liveness criteria vague

Initial Comment:
The current standard is vague about what constitutes a
client "liveness" indication sufficient to prevent the
media server from freeing a client's session.  It also
does not address under what circumstances a media
server may close an inactive persistent control
connection from a client.

These areas should be more explicitly specified so that
clients can reliably maintain their sessions with
minimum liveness detection overhead.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 14:39

Message:
Logged In: YES 
user_id=302620

The criteria for closing connections has been clarified in
the chapter connections.  

The liveness signaling has also been clarified in the
session header chapter. 

Changes are checked in.

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-01-14 11:13

Message:
Logged In: YES 
user_id=302620

Primary source of livness information is RTCP, which should be clarified. 
Secondly the new method PING could be used, see bug report #477400. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500906&group_id=23194

--__--__--

Message: 5
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 05:46:23 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-503949 ] Range header format for PAUSE is unclear

Bugs item #503949, was opened at 2002-01-15 18:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=503949&group_id=23194

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jonathan Sergent (sergent)
Assigned to: Nobody/Anonymous (nobody)
Summary: Range header format for PAUSE is unclear

Initial Comment:
Section 10.6 of RFC 2326 says:
   The PAUSE request may contain a Range header
specifying when the stream or presentation is to be
halted. We refer to this point as the "pause point".
The header must contain exactly one value rather than a
time range.

The Range header does not allow a single time value
unless there is a hyphen involved ("npt=20-").  The
wording in section 10.6 implies that the hyphen isn't
required ("npt=20").

My preferred resolution:
Include an example in section 10.6 showing a PAUSE
request with a Range header:

     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
	   CSeq: 834
	   Session: 12345678
	   Range: npt=20-

Alternate resolution:
Change the time grammars to allow a single time value
without a hyphen.  Indicate that this usage is only for
PAUSE and is illegal for PLAY.  Modify PAUSE to not use
the dash.

This alternate resolution seems unnecessary.  The dash
is unnatural from a human consumption point of view,
but not requiring it in this case seems to add
unnecessary complexity to the specification, and
creates more error handling cases.

My mind might be changed if I was shown existing
implementations that do not use the hyphen and break if
it is used.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 14:46

Message:
Logged In: YES 
user_id=302620

This is updated in the specification. Has been published
since 01 revision. No comments so far.

Closing issue. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=503949&group_id=23194

--__--__--

Message: 6
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 06:51:48 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-506412 ] RTSP Teardown functionallity

Bugs item #506412, was opened at 2002-01-21 13:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=506412&group_id=23194

Category: None
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTSP Teardown functionallity

Initial Comment:
The usage of TEARDOWN is not clear when doing it on 
media url in a aggregated session. 

Example: You have a session with one audio and one 
video media. These medias have a presentation URL in 
its description. The specification is clear on that if 
we do teardown on presentation URL the whole session 
and all medias will be closed. But what happends if 
you do teardown on the audio url? 

My interpretation is that only audio is removed from 
session. The video and session is still available. 
When you do teardown on the last media in a session 
then you remove the session. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 15:51

Message:
Logged In: YES 
user_id=302620

This has been clarified in the state machine and the
description for the TEARDOWN method. 

Two optional parts has been defined, support of the 
ready-no_media state and SETUP and TEARDOWN while playing. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=506412&group_id=23194

--__--__--

Message: 7
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 08:35:28 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-506684 ] Allow Rtp-Info header in more contexts

Bugs item #506684, was opened at 2002-01-21 23:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=506684&group_id=23194

Category: None
>Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders Klemets (klemets)
>Assigned to: Magnus Westerlund (magwes)
Summary: Allow Rtp-Info header in more contexts

Initial Comment:
Currently, the RFC states that the Rtp-Info header is 
required in the PLAY response.  But it is not clear 
whether or not the Rtp-Info is allowed in other 
contexts.

I think of three other cases where it might be useful:

1. In the RECORD request. If a client is sending data 
to the server, the client SHOULD send the Rtp-Info 
header to the server, so that the server can know the 
initial RTP sequence number and RTP timestamp.

2. In the SETUP response. If the server is already 
playing, and the client sends a SETUP command to 
select a stream that previously was not selected, I 
believe the server will start sending data for this 
stream immediately.  

(Check the RFC, I am not sure it clearly states 
whether the newly selected stream will be streamed 
immediately or not.)

In this case, it would be useful for the client to be 
able to recieve an Rtp-Info header as a part of the 
SETUP response.  But this has to be seen as an 
optional optimization -- the client can always send a 
second PLAY command, and the Rtp-Info header will then 
be available in the PLAY response.

3. In the ANNOUNCE command.  If the server is already 
playing, and something related to the SDP description 
suddenly changes, the server can send a new SDP to the 
client using the ANNOUNCE command.  It might be 
necessary to include a new Rtp-Info header in this 
case.

A similar situation happens when the server is 
reconding something, and the client sends an ANNOUNCE 
command to the server.

Again, this is probably just an optional optimization, 
because the client can always send a new PLAY command 
and obtain the Rtp-Info header again.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 17:35

Message:
Logged In: YES 
user_id=302620

I agree that RTP-Info i SETUP while be necessary for the
optional functionality of SETUP and TEARDOWN while playing. 

For RECORD this should be part of the work in defining how
it should really work. 

For ANNOUNCE we need to further discuss this. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=506684&group_id=23194

--__--__--

Message: 8
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 08:37:35 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507332 ] RTSPS/TLS support

Bugs item #507332, was opened at 2002-01-23 04:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507332&group_id=23194

Category: None
Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Lanphier (robla)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTSPS/TLS support

Initial Comment:
Currently, the version of RTSP that's checked into the
repository has TLS support and rtsps:.   This is
probably just a relic of the fact that we pulled this
at the very last minute when going to Proposed
Standard, and it never got checked in.

It's an interesting feature, but one that probably
warrents a separate draft on it's own track.

robla:  I vote for taking this out.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 17:37

Message:
Logged In: YES 
user_id=302620

If it is going to be left in the spec it needs further work. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507332&group_id=23194

--__--__--

Message: 9
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 08:45:27 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507408 ] clarify use of interleaved param

Bugs item #507408, was opened at 2002-01-23 09:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507408&group_id=23194

Category: None
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Tommy (realtommy)
>Assigned to: Magnus Westerlund (magwes)
Summary: clarify use of interleaved param

Initial Comment:
As noted in last RTSP telecon, certain implementations
use "interleaved" without a parameter "=n" in the
Transport header.  Please clarify that the parameter is
REQUIRED.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 17:45

Message:
Logged In: YES 
user_id=302620

It is evident from the ABNF and also written in the text now. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507408&group_id=23194

--__--__--

Message: 10
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 08:53:20 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507884 ] Should sequnce numbers be consecutive

Bugs item #507884, was opened at 2002-01-24 09:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507884&group_id=23194

Category: General
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: Should sequnce numbers be consecutive

Initial Comment:
To make it possible to detect losses of request when transported over UDP, the sequnce number 
should be consecutive. In that way the server will know that it should not process a request until 
the missing ones before is received. 

Are there any issues with such a solution? 
Does the first sequence number needs to be specified so losses of the first message(s) is known?

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 17:53

Message:
Logged In: YES 
user_id=302620

The specification is updated to require increments with one
for each new message. However the initial value is still
free to pick. 

The effect of losing the first packet is that request can be
performed in another order than intended. However if you
loose a not state changing event (Options, DESCRIBE) it will
not really matter. The first setup can't be pipelined unless
it is done with another SETUP request for two non-aggregate
session. A client is not allowed to issue a PLAY until the
SETUP request response is back. 

So I don't see how it can matter.  

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507884&group_id=23194

--__--__--

Message: 11
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 08:55:55 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-508211 ] Eliminate play queue feature

Bugs item #508211, was opened at 2002-01-25 00:48
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: Open
>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: 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: 12
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 08:59:57 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-511233 ] Timed PLAY requests has RTP-Info problem

Bugs item #511233, was opened at 2002-01-31 16:37
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: Open
Resolution: None
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: 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

End of Rtspspec-bugs Digest

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