Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #80 - 4 msgs

From: [email-masked]
Date: Wed, 25 Jun 2003 20:35:14 -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-557045 ] Need "Supported" header (SourceForge.net)
   2. [ rtspspec-Bugs-608365 ] 3xx codes overhaul and clarification (SourceForge.net)
   3. [ rtspspec-Bugs-492546 ] Shouldn't close on unsupported method (SourceForge.net)
   4. [ rtspspec-Bugs-531189 ] How does REDIRECT method work (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 25 Jun 2003 11:12:32 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-557045 ] Need "Supported" header

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

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Rob Lanphier (robla)
Assigned to: Magnus Westerlund (magwes)
Summary: Need "Supported" header

Initial Comment:
This is added to resolve http://rtsp.org/bug477427

There needs to be a way for non-fatal queries which can
be issued with methods.

The current proposal is to use the SIP "Supported" header.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-06-25 20:12

Message:
Logged In: YES 
user_id=302620

The supported header has been in added an in there for quite
a while. No comments. 

Closing bug. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 19:23

Message:
Logged In: YES 
user_id=302620

The Supported header is added to the text. Including usage
under options. 

One consideration has been rasied that the message size can
be rather big if many option tags are defined. Due to
interoperability it seems that rather many tags need to be
defined. 

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

Comment By: Rob Lanphier (robla)
Date: 2002-05-21 02:20

Message:
Logged In: YES 
user_id=3796

Current proposal checked into CVS:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/headers.tex.diff?r1=1.15&r2=1.16

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

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

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 25 Jun 2003 11:43:34 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-608365 ] 3xx codes overhaul and clarification

Bugs item #608365, was opened at 2002-09-12 15:23
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=608365&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: 3xx codes overhaul and clarification

Initial Comment:
The 3xx codes are all directly taken from HTTP. There
seem that not all are suitable for RTSP. A review of
the codes and the needs should be perforemed. 

Also the usage of 3xx responses needs some work. What
headers to include, etc.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-06-25 20:43

Message:
Logged In: YES 
user_id=302620

Tom marshall wrote up a proposal for new text regarding the
3xx codes that seperate 304 from the rest. This has been
edited in since the 03 version of the draft. 

No new codes has been specified. The use of 303 is still
deprecatied. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 19:27

Message:
Logged In: YES 
user_id=302620

I have written up a proposal for fixing this within the
spec. Two new codes are defiend 350, and 351. 303 is
suggested to be decapitated. 304 needs further discussion.
Also user comments has been added to the status chapter. 

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

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

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 25 Jun 2003 12:05:31 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-492546 ] Shouldn't close on unsupported method

Bugs item #492546, was opened at 2001-12-13 18:44
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=492546&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: Magnus Westerlund (magwes)
Summary: Shouldn't close on unsupported method

Initial Comment:
When a server (or client) receives an unsupported method, and the request is well-formed 
(complies with BNF for Request, and contains CSeq), we should mandate that a server MUST not 
close down an existing playback session.

This is an extensibility issue.  If, during playback, the client requests a certain method that the 
server doesn't support, and we allow session shutdown, then we've painted ourselves in a corner 
where we can't comfortably extend the protocol.

The client may determine that support for a method is required, at which point, the client may 
disconnect the session.  However, the client should be given the option to account for the error 
and continue playback.

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

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

Message:
Logged In: YES 
user_id=302620

Some text on this has been edited in to the specification in
the chapter regarding TCP connections. 

There is also a clarification regarding the use of the
"Connetion" header and the option "close".

Please review these changes.

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

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

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 25 Jun 2003 12:11:12 -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: Fix for DS - Need WG Input
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-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

End of Rtspspec-bugs Digest

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