Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #103 - 7 msgs

From: [email-masked]
Date: Thu, 23 Oct 2003 20:21:51 -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-810678 ] How to indicate end of media stream (SourceForge.net)
   2. [ rtspspec-Bugs-513753 ] RTSP extensions and IANA (SourceForge.net)
   3. [ rtspspec-Bugs-640272 ] Default way of deriving aggregate URL (SourceForge.net)
   4. [ rtspspec-Bugs-493265 ] Pause - Play behaviour clarification (SourceForge.net)
   5. [ rtspspec-Bugs-531189 ] How does REDIRECT method work (SourceForge.net)
   6. [ rtspspec-Bugs-500868 ] Require: option-tag values unclear (SourceForge.net)
   7. [ rtspspec-Bugs-500906 ] Client liveness criteria vague (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 23 Oct 2003 07:44:24 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-810678 ] How to indicate end of media stream

Bugs item #810678, was opened at 2003-09-22 17:48
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=810678&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: Nobody/Anonymous (nobody)
Summary: How to indicate end of media stream

Initial Comment:
discussed at the 57th IETF meeting 16th of July 2003.

Issue:  Possible methods for signalling end of
stream/media (not session) in RTP.

Discussion: Need to signal that a stream/media has
ended exist mostly in unbound sessions. Proposal
brought up to indicate this is RTCP BYE when the sender
stops sending and has waited some time it can remove
the SSRC of that source and send the BYE to indicate
this. Another proposal was to send this information in
RTSP methods. One could use sever to client TEARDOWN to
indicate this session really are over, nothing more can
be done. PAUSE can be sent when the media has been
served but the client may rewind do other operations.
The TEARDOWN idea was not liked as certain applications
require session data to be sent from client to server
using SET_PARAMETER. A new method should be evaluated.
There might also exist significant synchronization
problems in this.

Resolution: Propose a RTSP extension with a new method.
Thomas Zeng to write strawman proposal for evaluation
to mailing list.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-23 16:44

Message:
Logged In: YES 
user_id=302620

A strawman proposal is avail in this MMUSIC messge:
https://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg01978.html

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

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

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 23 Oct 2003 07:38:59 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513753 ] RTSP extensions and IANA

Bugs item #513753, was opened at 2002-02-06 15:05
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513753&group_id=23194

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: RTSP extensions and IANA

Initial Comment:
Today the RFC 2326 talks about extensions to RTSP and also has a number of headers that uses 
parameters. In the next version the following clarifications should be done:
- Setup a IANA register for RTSP parameters.
- Rules how to register different types of parameters.
- What type of documents that are needed for extending RTSP. IANA registering of parameters.  
IETF RFC for new headers(?), methods and future protocol versions.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-23 16:38

Message:
Logged In: YES 
user_id=302620

The IANA section is clearly needed. As it is has existed for
quite a while this bug will be closed. 

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

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

Message:
Logged In: YES 
user_id=302620

The IANA section has been exteneded to include what is
currently all found values that need regestries. The rules
and there levels needs further input. 

All x- things has been removed due to there evilness.  

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-05-27 16:52

Message:
Logged In: YES 
user_id=302620

Most of the issues describe in this bug are now adressed in
the new CVS repository file:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/iana.tex

Some further work regarding parameters are also required.

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

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

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 23 Oct 2003 07:49:06 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-640272 ] Default way of deriving aggregate URL

Bugs item #640272, was opened at 2002-11-18 21:19
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640272&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: Default way of deriving aggregate URL

Initial Comment:
Currently there is very little said on which aggregated
control URL to use. The only given case is the
a=control attribute in SDP at session level. In cases
when one aggregates media stream that have no common
SDP declaration or dependencies in other ways the URL
can't be derived. Examples of such cases is when you
would like to aggregate a session multiplexed
retransmission stream with the original data stream,
without requiring aggregatation between all media types
part of a stream. Another example is aggregation of
streams that are lacking a common SDP description but
still can be intressting to aggregate. 

To fix this a way to derive what a valid aggregate URL
is needs to be specified. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-23 16:49

Message:
Logged In: YES 
user_id=302620

Currently I have written in the specification text that a
client not having received a aggregated control URI SHOULD
consider it as no aggregation available. However it does not
rule out that one tries to create aggregated control. The
rules for how to create the URI is present. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-22 17:40

Message:
Logged In: YES 
user_id=302620

In the IETF in Vienna discussion July 16th 2003:

Issue: Missing session level control URI in SDP. IF the
session control URI is missing, should we allow the client
to try to to aggregate these? If aggregated which session
control URI must be used.

Discussion: This needs to be resolved. Tom Marshall did not
thought that we should prevent the use case to aggregate
unless necessary for interoperability. One possible
resolution is to say that any media description missing
session level control URI must be setup with individual RTSP
session for each media stream and any synchronization
between media be done on the receiver side. A practical
resolution resolution could be: A client SHOULD follow the
above statement but MAY try to aggregate. The server MAY
allow this aggregation but MAY also refuse it using 4xx
(Only non aggregated operation allowed).

Resolution?: Session declarations lacking a session level
control URL, MUST be used in non-aggregated control.
Further discussion needed? 

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

Comment By: Rob Lanphier (robla)
Date: 2003-05-28 18:34

Message:
Logged In: YES 
user_id=3796

From 14 May 2003 telecon
(http://rtsp.org/2003/telecon/minutes14May.html):
# Magnus: this is problem when aggregate control done in not
obvious way
# Magnus: what happens when you try to aggregate things that
aren't designed to be aggregated
# Joerg: I think this would require a lot of work to make
this work correctly
# Magnus: solution is to solve this with non-aggregate control
# Tom: how does client know
# Magnus: reuse session id
# Tom: what happens when you pass the session id with a
different URL
# Rob: it should be undefined
# Magnus: it should return error
# Rob: that's no more backward compatible
# Magnus: do you have proposed wording 11.4 second paragraph
# RESOLUTION: Tom to write up wording for 11.4 second paragraph

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

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

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 23 Oct 2003 07:29:40 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-493265 ] Pause - Play behaviour clarification

Bugs item #493265, was opened at 2001-12-14 12:55
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=493265&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: Magnus Westerlund (magwes)
Summary: Pause - Play behaviour clarification

Initial Comment:
The scenario is the following:
A media stream is ready to start playing when the client does the following A-C

A: PLAY range npt:10-30
B: @npt:22-> PAUSE
C: PLAY (no range)

This will result in resuming playing at npt:22. 
The unclearity is which of the following behaviour is the correct one?
1. Play until 30, i.e the second play is equal to PLAY range:22-30.
2. Play until end of media, i.e. the second play is equal to PLAY range:22-

The RFC states the following in Section 10.6 third paragraph:
  "A PAUSE request discards all queued PLAY requests. However, the pause
   point in the media stream MUST be maintained. A subsequent PLAY
   request without Range header resumes from the pause point."

The main unclarity is in what resumes means when also taking the first sentence into account.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-23 16:29

Message:
Logged In: YES 
user_id=302620

This comment has been addressed by the general clarification
of PLAY and PAUSE handling plus some furhter
clarificiations. The specification text indicates that
unless the second play request specify a range the server
will play from the pause point of 22 second until the end of
media. 

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-17 21:32

Message:
Logged In: YES 
user_id=3796

I would be inclined toward the 22-end interpretation (your option 2).  Won't change the spec until it's been 
covered by the group, though.

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

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

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 23 Oct 2003 06:10:28 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-531189 ] How does REDIRECT method work

Bugs item #531189, was opened at 2002-03-18 05:14
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=531189&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: Magnus Westerlund (magwes)
Summary: How does REDIRECT method work

Initial Comment:
In the spec there is conflicting wording on what will happend when the server sends a REDIRECT to 
the client. In the state machine part the RFC says that the server should go to init state. Section 
10.10 REDIRECT says that the client must do TEARDOWN on the session. 

How is it supposed to work espically combined with RANGE needs to be clarified

also see #513891

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-23 15:10

Message:
Logged In: YES 
user_id=302620

At the telecons the 1 nov and 14th of nov 2003 the issue of
implicit session removal was discussed. It was agreed that
having it to remove the state was okay. However the handling
of the signalling transport connection was more of an issue. 

A specification text proposal is now edited in. Please
review to see if it is found acceptable.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-22 17:51

Message:
Logged In: YES 
user_id=302620

From the 57th IETF meeting discussion 16th of July 2003: 

Issue: Should REDIRECT automatically close session.

Discussion: This does not concern 3rr responses. As a
connection related REDIRECT will terminate the session on
the server side it is reasonable the same thing happens for
REDIRECT request directed at the session. The exception to
this is timed REDIRECTS that will continue exist until the
specified time. The client should do TEARDOWN prior to this
point to move the session to the alternative session.

Resolution: Clarify that session will be terminated by a
successful REDIRECT, independently of its connection or
session. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-06-25 21:11

Message:
Logged In: YES 
user_id=302620

There has been updated text on the use of REDIRECT. The
usage of Range has also been clarified and solution for all
use cases exist. 

Two issue remains regarding redirect.
1. Should acknowleging a REDIRECT request mean that the
session is closed? Currently there exist on special case
regarding the use of * in the request that indicates that
transport link shall be closed, the session should be closed
automatically. However for the other cases when sessions is
targeted directly they are supposed to send a TEARDOWN for
that session. 

2. How should the client handle any outstanding request when
it receives a REDIRECT request with *?

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-09-18 17:12

Message:
Logged In: YES 
user_id=302620

The proposed solution for ranges does not work for content
that uses UTC for positioning, like surveilance tapes.
Suggestions on how to solve this, please.

In case that the location header only contains a server
adress the client may assume that the media is identical and
does not need to send a DESCRIBE before setting up a new
session. Otherwise it needs to do it as media may be different.

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-09-12 15:12

Message:
Logged In: YES 
user_id=302620

One more problem is that a client does not know if it should
issue a play with the range where it was redirected or start
from the begining. In the case of a media on deman and it
gets identical media from the new server it seems more valid
to resume at the position it was redirected at. However if
it gets redirected to another media it should start from the
beginng. And in the case of live media it should simply not
use any range in its PLAY request.

A mechanism needs to be added that solves this problem.

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-09-12 15:08

Message:
Logged In: YES 
user_id=302620

The result of a MMUSIC discussion is:

3xx Responses:
The server should use this to signal the client that it
should go find the media somewhere else. This answer can be
used on the methods that do inquires regarding the media or
tries to establish a session, i.e. OPTIONS (with media URL),
DESCRIBE, SETUP, and perhaps ANNOUNCE. It should not be used
when a server has an already established session and needs
to move that session to another server, i.e. don't use them
on PAUSE, PLAY, RECORD.

The client after receiving a REDIRECT must restart its work
on getting session information and setting up the session.

REDIRECT request:
This method shall be used when the server needs to move
already established session from this server. So it shall
not be used unless there is a session identifier to
reference. The redirect request SHOULD use contain the
session control URL and MUST include a session header. This
enables the client a unambiguous identification of which
session it should move.

I don't know if the server should go directly to INIT after
receiving the response from the client on the REDIRECT. This
would allow the server to reclaim any resources as fast as
possible. Alternatively the server should wait for a
teardown, but this seem to waste a round trip of time. But
as both behaviors are hinted in RFC 2326 it needs clarification.

When a client has received a REDIRECT request and
acknowledge the redirect it must assume that the session
does no longer exist. The exception is if a range header was
part of the request, and in that case it will be without a
session at the specified moment. So after receiving a
redirect the client must start from scratch to establish a
new session at the given location.

Use of location header: My opinion is that is should be a
complete RTSP URL.

Use of Range header: Also how the Range header shall be
interpreted together with REDIRECT needs to be clarified. As
the desired behavior may vary I think we need to be a little
bit cleaver here. If a range header is included and contains
a time in UTC it shall be interpreted that the server will
serve this client until that UTC time, and after that time
the client needs to establish a new session at the given
location. If a SMPTE or NPT time is given the session will
end when the playback reaches the given point in the media.
So in the case the client rewinds to the start before
reaching specified media point the session will remain. By
using UTC time the server can signal that I can't handle
your request further than e.g. until 18.00 today. Using NPT
will allow a server to redirect a user due to limitations of
the media, e.g. charging for rest of movie.

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

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

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 23 Oct 2003 07:33:16 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-500868 ] Require: option-tag values unclear

Bugs item #500868, was opened at 2002-01-08 17:09
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500868&group_id=23194

Category: None
>Group: Resolved - Added to text
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean Sheedy (seansh)
>Assigned to: Magnus Westerlund (magwes)
Summary: Require: option-tag values unclear

Initial Comment:
The proper option-tag values to use in the Require:
header when checking for optional features are not
always clear.  Some are more easily guessed then
others.

For example, to ask whether a server supports the
Scale: header, I would guess that the proper option-tag
would be "scale".  However, how does a client ask
whether the server supports the smpte time format in
the Range: header?

The document should include a table of optional
features and their corresponding option-tag values.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-23 16:33

Message:
Logged In: YES 
user_id=302620

The feature tags will be defined in the necessary
specifications. All official tags will be stored in an IANA
managed repository according the rules available in the IANA
chapter of the core specification. 

The SMPTE range header question will be solved thorugh the
use of Accept-Ranges instead of feature tags.

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

Comment By: Rob Lanphier (robla)
Date: 2002-01-29 04:26

Message:
Logged In: YES 
user_id=3796

This should probably be a separately defined document.  The Require header was intended as a way of 
querying for features outside of the scope of RTSP, rather than for features in RTSP.

It is too late to require that existing implementations support new feature tags, but I agree it would be 
useful thing to have around.  A candidate list may fall out of the list of features in RTSP.  Sean, would you 
mind taking a first crack at creating the list of features tags you'd like to see?

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

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

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 23 Oct 2003 07:37:06 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-500906 ] Client liveness criteria vague

Bugs item #500906, was opened at 2002-01-08 18:14
Message generated for change (Comment added) made by magwes
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: Accepted
Priority: 5
Submitted By: Sean Sheedy (seansh)
>Assigned to: Magnus Westerlund (magwes)
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: 2003-10-23 16:37

Message:
Logged In: YES 
user_id=302620

As no comments on this bug has been raised in a year it will
be closed. 

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

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

End of Rtspspec-bugs Digest

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