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

From: [email-masked]
Date: Sat, 25 Oct 2003 20:24:51 -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-640848 ] umbiguity in aggregate/non-aggregate pla (SourceForge.net)
   2. [ rtspspec-Bugs-464462 ] Content-Length header wrong in examples (SourceForge.net)
   3. [ rtspspec-Bugs-625339 ] need clarification for stand alone SDP (SourceForge.net)
   4. [ rtspspec-Bugs-803064 ] Teardown text needs rewrite (SourceForge.net)
   5. [ rtspspec-Bugs-772330 ] Clarify that RTCP shall be sent during whole session (SourceForge.net)
   6. [ rtspspec-Bugs-619421 ] Range header in PLAY response (SourceForge.net)
   7. [ rtspspec-Bugs-494533 ] The use of the word require in the RFC. (SourceForge.net)
   8. [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause (SourceForge.net)
   9. [ rtspspec-Bugs-625342 ] DESCRIBE Res needed in C.2 and C.3 (SourceForge.net)
  10. [ rtspspec-Bugs-563153 ] Appendix C: agg/non-agg mixup (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 24 Oct 2003 09:11:54 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-640848 ] umbiguity in aggregate/non-aggregate pla

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

Category: None
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Go Hori (ghori)
>Assigned to: Magnus Westerlund (magwes)
Summary: umbiguity in aggregate/non-aggregate pla

Initial Comment:
It is not clear to me who's choice it is to pick
aggregate play vs. non-aggregate play.  

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 18:11

Message:
Logged In: YES 
user_id=302620

No comments has been given for this since my last comment. I
have edited this into the specification. Will be available
in v5. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-03-12 15:45

Message:
Logged In: YES 
user_id=302620

It is the clients. With the updated specification the client
chooses this by setting up multiple streams or not in a each
session. 

This has no impact on a server that supports aggregated
control. 

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

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

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 24 Oct 2003 01:40:56 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-464462 ] Content-Length header wrong in examples

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

>Category: Editorial
Group: Fix for DS - Typo/Thinko
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Content-Length header wrong in examples

Initial Comment:
In most of the examples the Content-Length header is not the right value for the actual content of the header.

like the one below,which I copied from RTSP 14.5, this number doeas not match: In this case here they write "44", but if you count (together with CRLF, or even just LF) 103 chars + 8 for CRLF or 4 for just LF.

M-C: 
RTSP/1.0 200 1 OK 
Content-type: application/sdp 
Content-Length: 44 

v=0 
o=- 2890844526 2890842807 IN IP4 192.16.24.202 
s=RTSP Session i=See above t=0 0
m=audio 0 RTP/AVP 0 

C-M: 
SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0 CSeq: 2 
Transport: RTP/AVP;multicast;destination=225.219.201
..............................

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

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

Message:
Logged In: YES 
user_id=302620

These must be fixed in all examples as soon as the updates
becomes more stable. 

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

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

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 24 Oct 2003 06:39:15 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-625339 ] need clarification for stand alone SDP

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

>Category: General
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Go Hori (ghori)
>Assigned to: Magnus Westerlund (magwes)
>Summary: need clarification for stand alone SDP 

Initial Comment:
When a SDP file is download other than via RTSP (e.g. 
HTTP, FTP), control strings need to be all absolute.  
Should probably put clarification or give an example for 
this case to avoid confusion.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 15:39

Message:
Logged In: YES 
user_id=302620

There has been added a new section in the SDP appendix which
writes some clarifying notes on the topic. Text will become
available in v5.

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

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

Message:
Logged In: YES 
user_id=302620

Yes, this is another pice of information that belong to
appendix C.

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

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

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 24 Oct 2003 09:03:02 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-803064 ] Teardown text needs rewrite

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

Category: None
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: Teardown text needs rewrite

Initial Comment:
The text for the teardown section needs a serious
rewrite. The current text is not very clear on several
matters in regards to aggregated and non-aggregated
teardown.

Should probably await resolution of bug 795295.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 18:03

Message:
Logged In: YES 
user_id=302620

I have now updated the text about the TEARDOWN section. It
needs review. 

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

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

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 24 Oct 2003 08:42:30 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-772330 ] Clarify that RTCP shall be sent during whole session

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

Category: None
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: Clarify that RTCP shall be sent during whole session

Initial Comment:
Appendix B should be clarified to point out that RTCP
is expected to be sent from succesful response of SETUP
until TEARDOWN. During PAUSE the server and client
should both continue to send RTCP as normal. 

Motivations to this behavior is:
- to avoid timing out SSRC, 
- ensure detection of packet loss at the end of stream.
- ensure that RTCP syncrhonization can work (necessary
for multiple SSRC). 
- Ensure that RTP stream work prior to PLAY if there is
some delay between them. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 17:42

Message:
Logged In: YES 
user_id=302620

A clarification about this has been written into appendix B. 

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

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

Message:
Logged In: YES 
user_id=302620

At the same time it should be made clear the RTCP BYE is
sent when the session is terminated, i.e. at the time of
teardown.

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

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

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 24 Oct 2003 05:27:55 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-619421 ] Range header in PLAY response

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

Category: General
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Magnus Westerlund (magwes)
Summary: Range header in PLAY response

Initial Comment:
Current RTSP RFC makes Range header in PLAY response
from server optional.

If the PLAY request includes a Range header indicating
a possible seek, then it is probably necessary to
include Range in the response since it is possible that
the requested seek position could not be honored and
playback will resume at the nearest seekable point
which is not known to the client.

Note:  To fix this issue in 3GPP, Range in a PLAY
response was made mandatory for all PLAY responses.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 14:27

Message:
Logged In: YES 
user_id=302620

The inclusion of the Range header in PLAY responses is now a
MUST. We haven't found any problem with this. If anybody
finds this, please raise it. 

I have also put in Maureen into the acknowledgement section. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-01-31 13:49

Message:
Logged In: YES 
user_id=302620

As discussed in the teleconf the 22 jan 2003:
We should look at strengting the requirement on having the
Range header also for live streams when using RTP. A
solution based on Range:npt=now- with optional time or using
Range:clock=x can work. But careful wording is required.

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

Comment By: Rob Lanphier (robla)
Date: 2002-11-20 21:06

Message:
Logged In: YES 
user_id=3796

One other thing...put Maureen Chesire in the acknowlegements
for raising this....

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

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

Message:
Logged In: YES 
user_id=3796

Per a conversation with Magnus and I, we think we should
soften the language somewhat (strong SHOULD instead of MUST).  

One case to consider is a live stream, which one would think
would obviate the need for this header.  However, the
rationale for having it in live is when dealing with RTP. 
Since RTP audio and video streams can have a completely
different timestamp base, there needs to be an out-of-band
technique for synchronization.  The two techniques used in
RTSP are:

1.  RTSP "Range:"<->RTSP "RTP-Info:"<->RTP timestamp synch
2.  RTCP timestamp<->NTP mapping

Eventually, a well-behaved RTSP client will synch the
streams based on
the RTCP timestamps (when received).  However, there's a
period before the first RTCP packet arrives that there's no
sync, unless a Range header is known.

So, that also points to what the Range header should look
like.  The
Range header should include an open-ended wallclock range,
like so:
   Range: clock=20021120T133205Z- 
   RTP-Info:url=rtsp://example.com/fizzle/audiotrack;
            seq=5712;rtptime=934207921,
            url=rtsp://example.com/fizzle/videotrack;
            seq=57654;rtptime=2792482193

The spec should make this clear.

An interesting consideration to make here is a restriction
on Range response. The current rtsp spec states that "The
unit of the range in the reply is the same as that in the
request".  Perhaps an alternate syntax, if the PLAY request
has a Range: header in npt is as follows:

   Range: npt=now;time=20021120T133205Z

The "time" allows for mapping to occur.

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

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

Message:
Logged In: YES 
user_id=302620

Yes, the range header is need for RTP synchonization. The
draft specification has been updated to require this when
using RTP to make synchonization possible. 

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

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

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 24 Oct 2003 01:42:20 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-494533 ] The use of the word require in the RFC.

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

>Category: Editorial
Group: Fix for DS - Large task
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: The use of the word require in the RFC.

Initial Comment:
The RFC contains different usage of the word require. Sometimes it means that a implementation 
must interpret and understand a header or method. Othertimes the a certain header must be sent 
togheter with a method. 

One fix is to create a better table for the headers that clarifies the two different cases. Another is 
looking over the methods and use cases and clearly write when they must be included. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 10:42

Message:
Logged In: YES 
user_id=302620

There are also a great need to look at the usage of
normative language according to RFC 2119. 

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-19 02:29

Message:
Logged In: YES 
user_id=3796

We need to rework that table to clarify the difference between the two.

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

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

--__--__--

Message: 8
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 23 Oct 2003 06:12:43 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause

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

Category: General
Group: Resolved - Need write up
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Aravind Narasimhan (arvy_n)
Summary: RTP timestamps when playing after pause

Initial Comment:
What happends to the RTP timestamp when you issue a play after being paused for some time?

The following was my interpretation of the proposal for a solution. The
RTP timestamp is equal to display time. So it you do pause, wait five
seconds and then press play the timestamp will be 5 seconds later for
the first packet when resuming.

This behavior works fine when the play contains a range, for queued play
following after each other, but not for resuming play. The reason is the
delay between a user on the client side pressing pause and until the
client stops receiving data packets. If the client then does resume
play, i.e. play without range, the server will continue after the last
packet sent. In this case the client needs to show first the packet
arriving directly after pressing pause (which according to the used
model is past time), and then correctly synchronize the new packet which
has a significant offset in timestamp corresponding to the period of
pause the server has seen. The solution to this is to not use resume
play and instead say play from the point where user pressed pause.

On the other side I don't believe any other model will not have worse
problems.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-23 15:12

Message:
Logged In: YES 
user_id=302620

Aravind has agreed to write up the example and necessary
text. Transfering bug to him.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-22 10:48

Message:
Logged In: YES 
user_id=302620

A Clear example of RTP Timestamp and synchronization will be
added in appendix B - RTP transport.

The discussion in MMUSIC has made it clear that a continous
time model is needed to make RTCP work correctly. It has to
be accpeted that for on-demand media this will result in
slightly more code for the clients and servers. However all
pices to makes things work is already present. 

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

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

Message:
Logged In: YES 
user_id=302620

This has been further discussed in the MMUSIC mailing list. 

A important point is that RTP and RTCP to function as
intended in this environment must have a timestamp space
that increase continously with real time. 

A client handling the RTSP range header and RTP-Info can
always synchronize the data correctly independtly of which
case the server sent out. 

Using a continous RTP Timestamp space allows the same
timestamp model for both on-demand and live media.

The proposed resolution is to clrafiy in the RTP appendix of
the specification that a RTP timestamp space continous in
regards to real-time SHALL be used. Further write a warning
that this has been missunderstood and clients is RECOMMENDED
to handle both cases. 

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

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

--__--__--

Message: 9
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 24 Oct 2003 07:32:52 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-625342 ] DESCRIBE Res needed in C.2 and C.3

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

>Category: General
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Go Hori (ghori)
>Assigned to: Magnus Westerlund (magwes)
Summary: DESCRIBE Res needed in C.2 and C.3

Initial Comment:
In the examples for aggregate control SDP and 
subsequent SETUP request, it is confusing how a URL 
for SETUP is created.  It is missing a DESCRIBE 
response and gives an impression that a sesseion level 
control string was used as a base URL.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 16:32

Message:
Logged In: YES 
user_id=302620

I agree that the example was not clear. This has now been
corrected by including a DESCRIBE response for the
aggregated example which has defines a Content-Base, which
is the most  reasonable solution to this problem. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-31 13:24

Message:
Logged In: YES 
user_id=302620

We may also want to define a dedault rule to create control
URLs based on the first media setup so that sessions missing
session level control URLs are still possible to set up in
aggregates.

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

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

--__--__--

Message: 10
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Fri, 24 Oct 2003 04:37:03 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-563153 ] Appendix C: agg/non-agg mixup

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

Category: General
Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Lanphier (robla)
>Assigned to: Magnus Westerlund (magwes)
Summary: Appendix C: agg/non-agg mixup

Initial Comment:
The initial descriptions of aggregate and non-aggregate
contol are reversed, and poorly written.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2003-10-24 13:37

Message:
Logged In: YES 
user_id=302620

I have went over the SDP appendix once more and found some
more strangeness regarding aggregated and non-aggregated.
This is now fixed. 

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

Comment By: Rob Lanphier (robla)
Date: 2002-06-06 22:24

Message:
Logged In: YES 
user_id=3796

It turns out this had already been fixed in the draft-00
version.  However, the wording was still very confusing. 
This has been fixed in the version checked into CVS.

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

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

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

End of Rtspspec-bugs Digest

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