Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #78 - 10 msgs

From: [email-masked]
Date: Mon, 16 Jun 2003 11:58:16 -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-742328 ] How to handle PLAY request when at the end of a media clip (SourceForge.net)
   2. [ rtspspec-Bugs-631957 ] Use of # and ? in RTSP URLs (SourceForge.net)
   3. [ rtspspec-Bugs-513888 ] RTSP and NAT (SourceForge.net)
   4. [ rtspspec-Bugs-477400 ] Play without range while playing (SourceForge.net)
   5. [ rtspspec-Bugs-477423 ] Unclearities regarding pause with range (SourceForge.net)
   6. [ rtspspec-Bugs-755472 ] Restricted use of Range header time parameter (SourceForge.net)
   7. [ rtspspec-Bugs-477424 ] How to queue timed plays? (SourceForge.net)
   8. [ rtspspec-Bugs-477428 ] Priorites between aggregated & non cntrl (SourceForge.net)
   9. [ rtspspec-Bugs-513891 ] Clarify use of Range in REDIRECT method (SourceForge.net)
  10. [ rtspspec-Bugs-513875 ] Play when in state ready after playing (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 13 Jun 2003 07:08:52 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-742328 ] How to handle PLAY request when at the end of a media clip

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

Category: None
>Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: How to handle PLAY request when at the end of a media clip

Initial Comment:
This is a problem that has surfaced in interoperability
test. It shouldn't surface in a correct implemented
client talking to a correct server. However how should
the server handle it if still happens.

The scenario is:
The server is playing a stored media clip to the
client. The client has a certain amount of buffer
space. The client hits PAUSE. However when the PAUSE
request reaches the server the server has played all
media for the clip. The server respond to the PAUSE
request with a Range header containing the pause point.
The problem arise when the client likes to resume the
playout of  the media to the end. The client has all
the rest of the media already in its buffer and this
should be totally local operation.

There are three reasons I see why the client may not
know that this is a local operation:
1. The client has not been informed about the duration
of the media. Therefore it can use the pause point in
the response to determine that the server is at the end
of the media clip.
2. The server has not included the pause point in the
PAUSE response, may happen for RFC 2326 servers. This
is a MUST in the new specification.
3. The client does not check the duration against the
given pause point. This the client SHOULD do to prevent
this from happening.

Any of the three above would result in that the client
sends a PLAY request to resume playing (no range
header) at the pause point. However the server is
already at the of the media clip. So the big question
is how the server handles this PLAY request?

I can see two ways of resolving it and would like some
input on which is the recommended one.

A. The server sends a 200 OK on the request to
continue. The RTP-Info is for the next packet which
will not be sent as result of this PLAY request. The
Range header response indicate that the server will
play from the given end of the clip to the end of the
clip. Then no RTP packets are sent.

B. The server sends a 457 (Invalid Range) including in
the response the range header for the pause point.

In my opinion the best alternative is B. This clearly
indicate to the client that no media will be delivered.
Also it is in line with the semantics that a PLAY
request is only performed when the range is within the
media clip.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-06-13 16:08

Message:
Logged In: YES 
user_id=302620

At the telecon 28th of May 2003 it was the conclusion to use
resoultion b. Needs to be written up. 

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

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

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 16 Jun 2003 11:05:09 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-631957 ] Use of # and ? in RTSP URLs

Bugs item #631957, was opened at 2002-11-01 09:49
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=631957&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: Use of # and ? in RTSP URLs

Initial Comment:
The current BNF definition does not allow for use of #
(fragments) but use of ? (Query). The text in chapter 3.2: 

"Note that fragment and query identifiers do not have a
well-defined meaning at this time, with the
interpretation left to the RTSP server."

Seems to indicate that it should be allowed. 

How should the be resolved? Add # to url definition and
don't define the behavior. Rewrite the note and say
that they are not allowed. Or do we have any usefull
meaning for it today?

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-06-16 20:05

Message:
Logged In: YES 
user_id=302620

This needs to be reviewed further. 

Should look at the informational RFC regariding defining URL
schemes:
Guidelines for new URL Schemes
ftp://ftp.rfc-editor.org/in-notes/rfc2718.txt

And look what should be done to register it corretly:
Registration Procedures for URL Scheme Names
ftp://ftp.rfc-editor.org/in-notes/rfc2717.txt

At the same time there is need to consider bug 707252.

The definitions should be very clear on where one can
include fragement and query and where not. It is also
important to ensure that litteral IPv6 addresses are
allowed. Se RFC 2732.

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

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

Message:
Logged In: YES 
user_id=3796

Minutes from 14 May 2003 telecon
(http://rtsp.org/2003/telecon/minutes14May.html)
# Magnus: new spec includes query and fragment
# Rob: how does that work with streamids
# Magnus: streamids are transparent to the server
# Magnus: host part comes from RFC 2732 to allow for IPv6
# Magnus: Rest comes from RFC 2396
# Rob: We should rely on update to RFC 2396
# Magnus: There's work to update 2396, we can monitor that work
# Magnus: Proposal allow fragment and query in RTSP URLs
# Rob: is fragment allowed in HTTP spec?
# Magnus: not sure
# Anders: I've never seen it sent by a web browser
# Magnus: any objections to including both
# Rob: we should say no more, no less than HTTP spec
# Anders: I thought that it was to reference an anchor in doc
# Magnus: yes
# Anders: client would probably use this then
# RESOLUTION: Update RTSP URI spec to be standard URI and
look at HTTP spec for use of fragment

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

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

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 16 Jun 2003 11:07:30 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513888 ] RTSP and NAT

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

Category: General
>Group: Fix - Discussed/Resolved
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTSP and NAT

Initial Comment:
RTSP today is not that NAT friendly. Can something be done to fix that problem or shouldn't at 
least a note about it be written in the new spec?

If you don't have a ALG can this problem be fixed?

Known NAT issues with RTSP is and possible solutions based on NAT and SIP work:
1. Receiver ports are specifed in transport header. Needs to either be translated by ALG or client 
must find out the ports that will be used on the public side of the NAT. Mechanism for this has 
been proposed for SIP.
2. Transport header does not support explicit specification of RTCP ports. This seem to be required 
if any NAT port discovery will be possible to use. 
3. Keep alive traffic needs to be sent over NAT translated ports when in pause to prevent binding 
timeout. Not an issue for RTCP port but also RTP ports needs to receive traffic. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-06-16 20:07

Message:
Logged In: YES 
user_id=302620

This issue has been moved into a seperate RTSP draft named:
draft-ietf-mmusic-rtsp-nat-??.txt. 
Any discussion around this should be done in that drafts
context.

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

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

Message:
Logged In: YES 
user_id=302620

A chapter has been created but needs more text. Please sign
up for writing it. 

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

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

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 16 Jun 2003 11:11:51 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477400 ] Play without range while playing

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

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
Summary: Play without range while playing

Initial Comment:
A PLAY request without a Range header is legal. It starts playing a
stream from the beginning unless the stream has been paused. If a
stream has been paused via PAUSE, stream delivery resumes at the
pause point. If a stream is playing, such a PLAY request causes no
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
further action and can be used by the client to test server liveness.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In a response to play without range while playing, what shall the server
do with RTP-Info? The RTP-Info is required according to table in the
beginning of chapter 12, but my opinion is that it lacks meaning in this
case.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-06-16 20:11

Message:
Logged In: YES 
user_id=302620

A correction to previous comment, it is of course depreciated. 
This change has been editied in. No comments for a long while.

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

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

Message:
Logged In: YES 
user_id=302620

Further the use of PLAY for keep-alive is decapitaited. A
455 response will be received when used.

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

Comment By: Rob Lanphier (robla)
Date: 2002-05-24 20:01

Message:
Logged In: YES 
user_id=3796

Added PING method:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/methods.tex.diff?r1=1.3&r2=1.4

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 18:49

Message:
Logged In: YES 
user_id=3796

We should deprecate this use of PLAY, and add a PING method (so that we can explicitly ensure there are 
no side effects)  The nice thing about PING is that we can define it as bidirectional.

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

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

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 16 Jun 2003 11:34:03 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477423 ] Unclearities regarding pause with range

Bugs item #477423, was opened at 2001-11-02 08:45
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477423&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: Nobody/Anonymous (nobody)
Summary: Unclearities regarding pause with range

Initial Comment:
How shall the pause point be specifed? Is the only correct way to do it "(start time)- "? The use of 
range with time? It seem to be unecessary as play with range works instead.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-06-16 20:34

Message:
Logged In: YES 
user_id=302620

use of range is resolved and edited in. No comments for a
year on this resolution. Closing bug. 

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

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

Message:
Logged In: YES 
user_id=3796

Resolved with the following change:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/methods.tex.diff?r1=1.1&r2=1.2

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-02-13 02:12

Message:
Logged In: YES 
user_id=437905

RESOLVED: Only a single range specifier
(format "value-" where "value" is a time)
is allowed for pause. time="execution time in UTC" may 
also be used, but if multiple range specifiers are 
present, npt/smpte takes precence over time. A new example 
will be provided.

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 19:03

Message:
Logged In: YES 
user_id=3796

Does need clarification in specification, but probably warrents discussion.

Recommendation: end time in range is ignored

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

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

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 16 Jun 2003 11:37:45 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-755472 ] Restricted use of Range header time parameter

Bugs item #755472, was opened at 2003-06-16 20:37
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=755472&group_id=23194

Category: None
Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Restricted use of Range header time parameter

Initial Comment:
The Range header's time parameter has been deprecated
from use in PLAY and PAUSE method. The only method
still using the time parameter is REDIRECT. 

The decision to stop using time= for PAUSE and PLAY was
discussed at the 56th IETF and at the April 16th telecon. 

Reasons is that they create hard synchronization
problems and possilbe failure modes that does not give
the client any error codes. There was also no need seen
for the functionality. 

The change has been edited in and will be published
from version 4 of the draft. 

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

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

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 16 Jun 2003 11:43:30 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477424 ] How to queue timed plays?

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

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: How to queue timed plays?

Initial Comment:
When you queue items that has a activation time, does that override the order of the events that 
are queued? Play(1) has time A, Play(2) has time B, time A are after time B. 
Assumption on how it work: 
First Play(2) activated at time B, then at time B Play(1) tries to start, if already playing, it 
is queued as a normal untimed event.

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

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

Message:
Logged In: YES 
user_id=302620

As also time plays has been removed this can definitly not
happen. 
Closing bug. 

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

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

Message:
Logged In: YES 
user_id=302620

A Queued play is removed, a timed play being activated while
the session is in playing state will result in failure of
type 455. This has been written up and checked in CVS. See
new text for the PLAY method. 

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/methods.tex?rev=1.12&content-type=text/vnd.viewcvs-markup

Resolution needs review on spec text. 

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-02-13 02:44

Message:
Logged In: YES 
user_id=437905

RESOLVED: Propose elimination of queued play to list. 
Separate email necessary. 

RESOLVED: postpone 477424 until queue play is resolved.

ACTION ITEM (RL): submit proposal to eliminate queued play.
ACTION ITEM (MW): continuous sequence number filing.

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 19:04

Message:
Logged In: YES 
user_id=3796

Interpretation is correct.  Do you (or anyone in the working group) have a proposal for text to drop into the 
spec?

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

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

--__--__--

Message: 8
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 16 Jun 2003 11:49:40 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477428 ] Priorites between aggregated & non cntrl

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

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Priorites between aggregated & non cntrl

Initial Comment:
A single media stream is playing. Then an aggregated control which include this stream is issued a 
play. How should this be interpreted? I use that it is queue and waits until all single streams under 
that aggregated control finish their play.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-06-16 20:49

Message:
Logged In: YES 
user_id=302620

Has been resolved, no comment. Closing bug.

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

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

Message:
Logged In: YES 
user_id=302620

Aggregated control has been resolved so that it is
determined by the sessions state. If more than one stream is
set up in a RTSP session only aggregated control is allowed.
This has been incorperated into the draft. Changes in PLAY,
PAUSE and state machine to explain this. 

Further work on RECORD needs to incorperate this also. A
note is added to that chapter.

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-02-13 02:45

Message:
Logged In: YES 
user_id=437905

RESOLVED: Await resolution of queued play. Aggregate 
control issue needs larger discussion.

ACTION ITEM: Write up aggregate URL proposal.

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

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

--__--__--

Message: 9
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 16 Jun 2003 11:52:16 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513891 ] Clarify use of Range in REDIRECT method

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

Category: None
>Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Anders Klemets (klemets)
Assigned to: Magnus Westerlund (magwes)
Summary: Clarify use of Range in REDIRECT method

Initial Comment:
Section 10.10 says that the REDIRECT command can 
specify the Range header, to specify when the 
redirection should take place.  The example shows a 
Range header that specificies an absolute time (UTC 
time.)  Is it also possible to specify an NPT time for 
the REDIRECT command?

How should a client interpret the end of the range 
when the Range header appears in the REDIRECT command?

One way to interpret the end range time is to say that 
the client should connect back to the original server 
after that time.

So, for example, if ServerA sends this command:

REDIRECT rtsp://ServerB/foo RTSP/1.0
Range: npt=45-60

It could mean that the client should keep streaming 
from ServerA for time being, but when it reaches time 
NPT=45 in the presentation, then it should connect to 
ServerB and keep streaming from there for 15 seconds.  
After the time of the presentation reaches NPT=60, 
then the client will connect back to ServerA and 
continue streaming from there.

Somehow, I feel that this might not be exactly what 
the authors of the spec had in mind.
The spec needs to be clarified so that there is no 
ambiguity about how to interpret the Range header in 
this case. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-06-16 20:52

Message:
Logged In: YES 
user_id=302620

The text has been updated and contains a resolution that
support all time formats and a wall clock time for when a
REDIRECT shall take place. 

Has been present for a while without comments. Closing bug. 

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

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

Message:
Logged In: YES 
user_id=302620

New text is proposed on how range should work for REDIRECT.
A issue remains for the proposed solution. If conent has UTC
time scale and one desires a redirect relative to the media
this solution does not work.

Also see bug #531189

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

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

--__--__--

Message: 10
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 16 Jun 2003 11:57:41 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513875 ] Play when in state ready after playing

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

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Play when in state ready after playing

Initial Comment:
A client has been playing for a while and reaches the end of either media or range. At that time the 
state machine goes to state ready. When in state ready a play without range is issued. The 
question is what happends at this point:

1. The play starts from the begining of the media. 

2. If at end of media directly revert to ready, or if a play with range was the previous play 
continue at the end of that range. 

Both interpretations has been implemented. So please give your opinion on this, especially if you 
have arguments supporting one or the other, like usage cases.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-06-16 20:57

Message:
Logged In: YES 
user_id=302620

Has been resolved for a while. No comment. closing bug.
Text present in specifaction. 

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

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

Message:
Logged In: YES 
user_id=302620

This has been discussed and the propsed change is:
A PLAY request must contain a range header that rewinds to
the beginning. 
A PAUSE will be required to make the state machine go to
ready state before issuing the rewinding PLAY.

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

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

End of Rtspspec-bugs Digest

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