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

From: [email-masked]
Date: Tue, 24 Sep 2002 12:16:43 -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-477425 ] Inconsistency between timeformats ([email-masked])
   2. [ rtspspec-Bugs-461083 ] Body w/o Content-Length clarification ([email-masked])
   3. [ rtspspec-Bugs-511686 ] Timed PLAY requests has RTP-Info problem ([email-masked])
   4. [ rtspspec-Bugs-513891 ] Clarify use of Range in REDIRECT method ([email-masked])

--__--__--

Message: 1
To: [email-masked]
From: [email-masked]
Date: Tue, 24 Sep 2002 06:27:00 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477425 ] Inconsistency between timeformats

Bugs item #477425, was opened at 2001-11-02 08:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477425&group_id=23194

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

Initial Comment:
NPT time in range is allowed to be specifed as "-nptime". No other timeformat allows that, why?

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

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

Message:
Logged In: YES 
user_id=302620

Corrected by Magnus. Has been published.

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

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

Message:
Logged In: YES 
user_id=3796

Checked into CVS:
Extending "clock=":
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/parameters.tex.diff?r1=1.6&r2=1.7
Clarifying semantics:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/methods.tex.diff?r1=1.2&r2=1.3

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

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

Message:
Logged In: YES 
user_id=437905

RESOLVED: Extend this to other time formats, and probably 
clarify the semantics of this particular syntax. Should 
start at pause point or the beginning.

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-01-03 10:07

Message:
Logged In: YES 
user_id=302620

I belive we need to to consider how a play with a range "-time" after a pause should be treated. This is 
related to #493265. If #493265 alternative 2 is the agreed behaviour for that issue, the -time range could 
be used to restart a paused media with a given end point. 

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

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

Message:
Logged In: YES 
user_id=3796

We're pretty sure this is a thinko, and we think that this technique should be extended to the other time 
formats.  Anyone in the working group think differerently?

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 16:44

Message:
Logged In: YES 
user_id=3796

It's clear we need to extend this to other time formats, and probably clarify the semantics of this particular 
syntax.  As to "why?", it was probably just an oversight; we focused on npt for most of our work.

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

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

--__--__--

Message: 2
To: [email-masked]
From: [email-masked]
Date: Tue, 24 Sep 2002 06:38:12 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-461083 ] Body w/o Content-Length clarification

Bugs item #461083, was opened at 2001-09-13 03:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=461083&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Jason Lango (jasonlango)
Assigned to: Rob Lanphier (robla)
Summary: Body w/o Content-Length clarification

Initial Comment:
RFC 2326 says: 

4.4 Message Length

   When a message body is included with a message, the
length of that body is determined by one of the
following (in order of precedence):
 
   1.     Any response message which MUST NOT include a
message body
          (such as the 1xx, 204, and 304 responses) is
always terminated
          by the first empty line after the header
fields, regardless of
          the entity-header fields present in the
message. (Note: An
          empty line consists of only CRLF.)

   2.     If a Content-Length header field (section
12.14) is present,
          its value in bytes represents the length of
the message-body.
          If this header field is not present, a value
of zero is
          assumed.
 
   3.     By the server closing the connection.
(Closing the connection
          cannot be used to indicate the end of a
request body, since
          that would leave no possibility for the
server to send back a
          response.)
 
.. so it is saying that closing the connection is Ok to
indicate the length.

.. but then in section 12.14, it also says that the
Content-Length header MUST be sent.

The two sections should probably be made consistent.

Currently a popular RTSP server implementation (QTSS)
sends
"Connection: Close" followed by a message body for
certain
RTSP error status responses.

It might be worth requiring 'Connection: Close' in item
3 of
section 4.4 to reduce the ambiguity of whether or not a
compatible implementation may expect a response to
contain
a message body.

Alternatively it might be worth -not- saying that
message length
may be determined by the server closing the connection.

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

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

Message:
Logged In: YES 
user_id=302620

The resolution is consistent with SIPs solution. The text is
updated. bug closed.

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

Comment By: Rob Lanphier (robla)
Date: 2002-02-19 01:52

Message:
Logged In: YES 
user_id=3796

Eliminated item #3 from the list.

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-28 23:28

Message:
Logged In: YES 
user_id=437905

RESOLUTION: (Jan 9, 2002 teleconference)

Eliminate implicit body-length via connection: close.  
COntactt David SInger on this issues and encourage f 
future participation.  Verify resolution is consistent 
with SIP specificaiton.

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

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

Message:
Logged In: YES 
user_id=3796

This is a potentially gnarly issue.  We agree that this is a problem that needs fixing.

We propose that we eliminate the option of implied Content-Length if possible (need 
to check with implementors on this....Darwin server in particular).  If we can't do 
that, require Connection: close, and change header definition.

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

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

--__--__--

Message: 3
To: [email-masked]
From: [email-masked]
Date: Tue, 24 Sep 2002 06:40:33 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-511686 ] Timed PLAY requests has RTP-Info problem

Bugs item #511686, was opened at 2002-02-01 14:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=511686&group_id=23194

Category: None
Group: Fix for DS - Need WG Input
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Timed PLAY requests has RTP-Info problem

Initial Comment:
In a PLAY with a range header, "time=" can be used to give activation time. This request shall be 
responded immediately to the client. In the response the server should give synchronization data 
like RTP TS which will be used when the PLAY is activated sometime in the future. It is hard to 
impossible for the server to produce such data. If no other PLAY request is done between request 
time and activation it is possible to give an accurate TS and sequnce number. But if another 
request is activated in the time between, the given RTP TS or sequnce number will not be correct. 

This problem is the same that queued plays has, see bugreport #477432, but due to different 
reasons.

One possible solution would be to introduce a SYNC method which a server can send at or slightly 
before activation of a queued or delayed play. This method would carry a RTP-info header and a 
range header, giving the information; what is playing and the synchronization information. 

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

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

--__--__--

Message: 4
To: [email-masked]
From: [email-masked]
Date: Tue, 24 Sep 2002 06:44: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
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513891&group_id=23194

Category: None
>Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
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: 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

End of Rtspspec-bugs Digest

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