Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #95 - 11 msgs

From: [email-masked]
Date: Mon, 22 Sep 2003 08:52:12 -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-633779 ] SET_PARAMETER responses (SourceForge.net)
   2. [ rtspspec-Bugs-640265 ] Extension of Transport header (SourceForge.net)
   3. [ rtspspec-Bugs-640272 ] Default way of deriving aggregate URL (SourceForge.net)
   4. [ rtspspec-Bugs-640298 ] Use cases for RTSP (SourceForge.net)
   5. [ rtspspec-Bugs-647838 ] Warning header (SourceForge.net)
   6. [ rtspspec-Bugs-662436 ] RTP/AVP/TCP w/o interleaved (SourceForge.net)
   7. [ rtspspec-Bugs-672160 ] Describe a interleaved RTSP channel for client RR reports (SourceForge.net)
   8. [ rtspspec-Bugs-810666 ] Removal of SETUP in play state (SourceForge.net)
   9. [ rtspspec-Bugs-640272 ] Default way of deriving aggregate URL (SourceForge.net)
  10. [ rtspspec-Bugs-810678 ] How to indicate end of media stream (SourceForge.net)
  11. [ rtspspec-Bugs-531189 ] How does REDIRECT method work (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:56:09 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-633779 ] SET_PARAMETER responses

Bugs item #633779, was opened at 2002-11-05 13:19
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=633779&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: Nobody/Anonymous (nobody)
Summary: SET_PARAMETER responses

Initial Comment:
Clarify on the usage of SET_PARAMETER when no body is

present. A correct syntax with unknown headers will

result in a 200 response but also the understanding of

a propreitary or new header will result in 200. Clarify

that a requester should use the Require header with an

option tag to ensure that the responder of the request

really understands the propreitary or new header. 

Also write text recommending on the usage of parameters

in the body with the motivation that they are simpler

than using require and headers. But both case should be

possible to use. 

How to handle a empty parameter list in the body should

also be explained. 

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

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

Message:
Logged In: YES 
user_id=3796

>From 14 May 2003 telecon

(http://rtsp.org/2003/telecon/minutes14May.html):

#  Magnus: how to respond if server doesn't understand parameter

# Anders: maybe a require header to be used if necessary

# Magnus: I can agree with just a clarification

# Anders: for proprietary client request, it can expect

proprietary response

# Magnus: easier if just use body

# Anders: don't need to specify more than that

# Rob: I agree

# Magnus: spec says that SET_PARAMETER can be used for keep

alive

# Magnus: it's possible to have SET_PARAMETER without body

# RESOLUTION: Short explanation of SET_PARAMETER without

body being allowed. No other changes

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

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

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:56:23 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-640265 ] Extension of Transport header

Bugs item #640265, was opened at 2002-11-18 21:07
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640265&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: Nobody/Anonymous (nobody)
Summary: Extension of Transport header

Initial Comment:
The current BNF definition of the transport header does

not allow extensions of new parameters.  I suggest that

a trn-parameter-extension is defined in the BNF to

allow for future extensions. Further a mechansism

explaining that unknwon parameters are allowed to

ignore. If a parameter is vital a option-tag and the

Require header needs to be used. 

This might have backwards compatibility issues as it

might cause parsers to decalare the transport header as

erronous. However not fixing it will cause even more

problems in the future. 

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

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

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:56:39 -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 (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640272&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: Nobody/Anonymous (nobody)
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: 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: Mon, 22 Sep 2003 01:56:50 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-640298 ] Use cases for RTSP

Bugs item #640298, was opened at 2002-11-18 21:55
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640298&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: Nobody/Anonymous (nobody)
Summary: Use cases for RTSP

Initial Comment:
Today very little is defined regarding the different

use cases that RTSP can be deployed in. This should be

specified at least so that we can know what to think

of. It is properly not possible to ensure and implement

all of the use cases that are interesting, however we

should ensure that the base spec allows for extensions

to support them. 

Use case:

1. On-demand streaming with single receiver in a

session. A single client creates a session with unicast

media transport to itself from the server. 

2. Live streaming to single user. A single user creates

a session with unicast delviery from a live source. The

control logic for this sessin is differnet compared to 1. 

3. On-deman streaming with multicast delivery: Controll

is an issue. Different models exist:

- Externally controlled

- By session leader only

- Common control for all receivers.

4. Live streaming with multicast delivery. Who is

controlling the media delivery in the session can be

different:

- Externally controlled 

- By session leader

- Common control for all receivers.

5. Common session with media deliver by unicast to each

of the participants. The control can be any of the

above from 3 and 4.  

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

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

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:57:07 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-647838 ] Warning header

Bugs item #647838, was opened at 2002-12-03 15:27
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=647838&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Warning header

Initial Comment:
To be able to send more detailed error messages it

might be good to include the SIP header "Warning". 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-05-12 13:16

Message:
Logged In: YES 
user_id=302620

This was discussed at the 56th IETF meeting and then later

on the teleconf of 28th April 2003. 

The result is to leave it out unless somebody see a real

need to included these headers. Their main use would be

related to debugging. 

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

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

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:57:39 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-662436 ] RTP/AVP/TCP w/o interleaved

Bugs item #662436, was opened at 2003-01-05 03:01
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=662436&group_id=23194

Category: General
Group: Fix DS - Needs clarificiation
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Nobody/Anonymous (nobody)
Summary: RTP/AVP/TCP w/o interleaved

Initial Comment:

If a Transport line specifies RTP/AVP/TCP

and does not also use the interleaved

parameter, the transport setup details

seem undocumented (maybe I'm not looking

in the right place ...).

I'm thinking of the level of detail the

comedia I-D provides for TCP: which

side accept()s and which side connect()s,

how many connections to set up, framing, 

etc.

Are there pre-existing implementations 

that use this transport mode? I happened

to stumble onto this in writing the TCP

appendix for the MWPP "implementation

guidelines" ... which may spawn off a

generic I-D specifying how to use comedia

with RTP (framing, specifying the fmt

tokens after TCP, etc). So, one option

is to add RTP/AVP/TCP w/o interleaving

details to that I-D, if adding it to

to the RTSP I-D isn't desirable for

some reason ...

john lazzaro -- [email-masked]

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

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: we should leave this until RTP framing is done

# Magnus: this is basically a feature request

# Magnus: this might well be a separate draft

# Rob: agreed

# Aravind: agreed

# Tom: we'll have to deal with this issue when DCCP comes along

# Anders: I saw this in use

# Tom: they might be using interleaving or not

# RESOLUTION: separate draft for non-interleaving; narrow

spec for      interleaving 

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

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

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:57:56 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-672160 ] Describe a interleaved RTSP channel for client RR reports

Bugs item #672160, was opened at 2003-01-22 01:28
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=672160&group_id=23194

Category: General
Group: Fix DS - Needs clarificiation
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas M Zeng (zengtm)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Describe a interleaved RTSP channel for client RR reports 

Initial Comment:
 In the section on RTP interleaved over the RTSP 

channel (section 10.13), there was no

mention of the client sending RTCP RR back to the 

server.  Are these still

present?  They did specify the sender reports from the 

server to client, but that's it.  The back channel is 

symmetric to the RTCP for server to send SRs and 

should be described as such (i.e. described in Transport 

headers).

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

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

--__--__--

Message: 8
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 08:30:27 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-810666 ] Removal of SETUP in play state

Bugs item #810666, was opened at 2003-09-22 17:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=810666&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: Removal of SETUP in play state

Initial Comment:
On MMUSIC there is a proposal to remove the

functionality for setup in play state to add a new

individual media stream. This not about changing

transport parameters!

First the need for this is not clear. The only use

cases seems to be to do switching between different

media streams variants. As this doesn't look as the

best method and secondly that switching at all is an

add on functionality this seem to not belong in core spec.

Secondly removing this will simplify the specification

writing.

Third, if the method is need in the future it will be

possible to write an extension specification. 

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

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

--__--__--

Message: 9
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 08:40:34 -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: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
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-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: 10
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 08:48:53 -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 (Tracker Item Submitted) made by Item Submitter
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.

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

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

--__--__--

Message: 11
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 08:51:36 -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-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

End of Rtspspec-bugs Digest

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