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

From: [email-masked]
Date: Thu, 12 Sep 2002 16:34: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-531189 ] How does REDIRECT method work ([email-masked])
   2. [ rtspspec-Bugs-531189 ] How does REDIRECT method work ([email-masked])
   3. [ rtspspec-Bugs-608365 ] 3xx codes overhaul and clarification ([email-masked])

--__--__--

Message: 1
To: [email-masked]
From: [email-masked]
Date: Thu, 12 Sep 2002 06:08:13 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-531189 ] How does REDIRECT method work

Bugs item #531189, was opened at 2002-03-18 05:14
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: Nobody/Anonymous (nobody)
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: 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: 2
To: [email-masked]
From: [email-masked]
Date: Thu, 12 Sep 2002 06:12:12 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-531189 ] How does REDIRECT method work

Bugs item #531189, was opened at 2002-03-18 05:14
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: Nobody/Anonymous (nobody)
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: 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: 3
To: [email-masked]
From: [email-masked]
Date: Thu, 12 Sep 2002 06:23:32 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-608365 ] 3xx codes overhaul and clarification

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

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
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.

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

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

End of Rtspspec-bugs Digest

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