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

From: [email-masked]
Date: Mon, 22 Sep 2003 01:56:10 -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-539001 ] Transport header should override m= (SourceForge.net)
   2. [ rtspspec-Bugs-522602 ] Should Allow S->C  "Teardown" (SourceForge.net)
   3. [ rtspspec-Bugs-539040 ] Conference header underspecified (SourceForge.net)
   4. [ rtspspec-Bugs-556061 ] When can REDIRECT be received? (SourceForge.net)
   5. [ rtspspec-Bugs-745191 ] Appendix B - Clarification? (SourceForge.net)
   6. [ rtspspec-Bugs-556295 ] Client issues PAUSE while server ready (SourceForge.net)
   7. [ rtspspec-Bugs-563153 ] Appendix C: agg/non-agg mixup (SourceForge.net)
   8. [ rtspspec-Bugs-585865 ] Use of Date, and Host in RTSP (SourceForge.net)
   9. [ rtspspec-Bugs-619421 ] Range header in PLAY response (SourceForge.net)
  10. [ rtspspec-Bugs-630920 ] RTP-Info does not support multiple SSRC (SourceForge.net)
  11. [ rtspspec-Bugs-633148 ] Use of TCP and UDP (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:49:28 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-539001 ] Transport header should override m=

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

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Lanphier (robla)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Transport header should override m=

Initial Comment:
Section C.1.7 ("Connection Information") states the

following:  "for on-demand unicast streams and some

multicast streams, the destination is specified by the

client via the SETUP request".  The rest of this

section mainly refers to the "c=" line in SDP, but it's

not clear that the SETUP Transport header also

overrides the port given in the m= line.  Clarification

of this is needed.

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

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

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:49:04 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-522602 ] Should Allow S->C  "Teardown"

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

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas M Zeng (zengtm)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Should Allow S->C  "Teardown" 

Initial Comment:
Table 2 in section 10 of RFC2326 seem to disallow S->C 

Teardown. And section 10.7 is vague on whether S->C 

teardown is OK.

This should be relaxed, because Server might have to 

use TEARDOWN to tell client a live session is over.

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

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

Message:
Logged In: YES 
user_id=302620

To be discussed

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

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

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:50:42 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-539040 ] Conference header underspecified

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

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Rob Lanphier (robla)
Assigned to: Rob Lanphier (robla)
Summary: Conference header underspecified

Initial Comment:
The "Conference" header specified in section 12.10 of

the 2326bis00 is underspecified, and not implemented by

known implementations.

Proposal:  Remove section 12.10 and section 3.3

(Conference Identifiers).

MMUSIC discussion: 

http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00416.html

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

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

Message:
Logged In: YES 
user_id=302620

This change has been part of the drafts for a long time.

Closing bug. 

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

Comment By: Rob Lanphier (robla)
Date: 2002-05-30 01:48

Message:
Logged In: YES 
user_id=3796

Eliminated the "Conference:" header and associated

trappings.  Changed the following files

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

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/headers.tex.diff?r1=1.19&r2=1.20

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

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/methods.tex.diff?r1=1.5&r2=1.6

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/parameters.tex.diff?r1=1.7&r2=1.8

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

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

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

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

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

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:51:10 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-556061 ] When can REDIRECT be received?

Bugs item #556061, was opened at 2002-05-14 20:33
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=556061&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: Nobody/Anonymous (nobody)
Summary: When can REDIRECT be received?

Initial Comment:
>From mmusic alias:

----

Date: Tue, 14 May 2002 17:55:20 +0200

From: "[email-masked]"

    <[email-masked]>

To: "[email-masked]" <[email-masked]>

Subject: [MMUSIC] RTSP REDIRECT (1) , when can it be

received ??

Hi,

I have problem understanding *when* a user agent can

receive a REDIRECT request.

When reading RFC 2326, I understood

receipt/transmission of a REDIRECT request could happen

at virtually anytime. As such, the following scenario

could happen:

C -> S: DESCRIBE rtsp://server.com/movies/BeautifulMind.mp4

CSeq: 1400

Accept: application/sdp

S -> C: REDIRECT rtsp://server.com/movies/BeautifulMind.mp4

CSeq: 1401

Location: rtsp://server.com/mpaa/pg13/BeautifulMind.mp4

S -> C: RTSP/1.0 404 Not Found

CSeq: 1400

Connection: Close

However one can also notify redirection in such a

context by using a 3xx

response, right ?

C -> S: DESCRIBE rtsp://server.com/movies/BeautifulMind.mp4

CSeq: 1400

Accept: application/sdp

S -> C: RTSP/1.0 301 Moved

CSeq: 1400

Location: rtsp://server.com/mpaa/pg13/BeautifulMind.mp4

Connection: Close

However when reading the RTSP state machine spec

(version 0.5) contributed by Mr Westerlund, it seems

like a REDIRECT can only happen (or at least

should be used) when a presentation is being played or

is paused (at least all streams are SETUP). Therefore

using the state machine REDIRECT semantics, scenarii

like the first one exposed above are erroneous.

So should REDIRECT be sent/received when an RTSP

session is being played/paused only, or can it be

sent/received any time ??

Thanks for your time and response,

Olivier

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

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

Message:
Logged In: YES 
user_id=302620

The resolution I see is that REDIRECT shall only be sent

when a client has an established session. The use of 3xx may

happen at any time. 

Such a solution is written up and available from CVS. 

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

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

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:52:33 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-745191 ] Appendix B - Clarification?

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

Category: General
Group: Fix - Discussed/Resolved
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Steve McKenna (stevemck)
>Assigned to: Magnus Westerlund (magwes)
Summary: Appendix B - Clarification?  

Initial Comment:
We are working on serving A/V content (MPEG4 primarily) 

for unicast on-demand clients only (no live feeds, no 

groups).  This is a VOD single-viewer system.

To make our server as scaleable as possible, we want to 

pre-timestamp RTP packets (stamp once, use thousands of 

times).  When supporting PAUSE followed by random 

access repositioning, this gives us an RTP clock timeline 

that jumps at the moment of restart - backwards when 

seeking back, forwards when seeking forward.  The PLAY 

response after repositioning does properly identify the new 

RTP timestamp related to the after-seek NPT in an 'RTP-

info' field.

Multiple Players have no problem with this - one in 

particular balks and points to Appendix B as the 'law' that 

demands we discard our approach.  If we were to do 'just in 

time' stamping, our supported stream counts would drop 

some appreciable percentage, so it has real costs to do 

this.  

I can see why this makes a difference in live-feed models, 

but would be interested in thoughts as to why it is or is not 

of any critical importance in the specific case we are 

working.  Thanks

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-06-05 11:10

Message:
Logged In: YES 
user_id=302620

This has recently been discussed again. There are several

reasons why the RTP timestamp usage you have is not the

correct one. 

The correct RTP timestamp model is that the sent RTP

timestamp increase continous with wall clock. So if one do a

seek back to back with a playing the RTP timestamp will not

jump. If one pause for 5 seconds the RTP timestamp of the

packet when on continue the playout will be 5 seconds later.

The reason for doing this is:

- If one pause or do seek the RTP timestamp is not inline

with what RTCP report. RTCP needs continous RTP timestamp

against real time. Therefore strange synchronization

problems may occur. Also the RTT measurement in RTCP may be

effected. 

- A common model that works independently of use case gives

minimal implementation effort for all clients. 

- Using a common RTP timestamp without any random offset

between different streams may be a security risks if one

does encryption. 

- The implementation effort of maintaining a correct RTP

timestamp is very small, at least if one implements this

correctly. In my view it costs one extra 32 bit addition per

RTP packet. And at every PLAY request and media jump a

couple of extra instructions to calculate the RTP timestamp

offset for the first packet. 

If you have more questions on this issue please email to

mailing list [email-masked]. See www.ietf.org, wg page,

mmusic for instructions how to subscribe. 

This bug is resolved and another tracker item exist, see bug

507882.

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

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

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:53:12 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-556295 ] Client issues PAUSE while server ready

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

Category: General
Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Client issues PAUSE while server ready

Initial Comment:
If a client issues a PAUSE and the server acknowledges

and enters ready state, what is proper server response

if the player issues another PAUSE?

There appear to be two possible correct behaviors:

1. server responds with OK because it does not change

state and does no harm.

2. server responds with error 455 because PAUSE does

not make sense in this state.

Both interpretations have been implemented.  The latter

appears to be more correct, but a client that assumes

the first may misbehave if the server implements the

second.

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-05-14 17:17

Message:
Logged In: YES 
user_id=302620

The working assumption is that a 200 OK should be sent even

if already in ready state. Also the pause point needs to be

included in the response. 

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

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

Message:
Logged In: YES 
user_id=302620

This should be clarified. Input from implementors wanted.

The resolution should be made evident in the state machine. 

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

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

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:53:48 -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 (Settings changed) 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: Nobody/Anonymous (nobody)
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: 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

--__--__--

Message: 8
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:54:14 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-585865 ] Use of Date, and Host in RTSP

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

Category: General
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: Use of Date, and Host in RTSP

Initial Comment:
There exist a number of HTTP headers that are just

referenced into the specification. Several is hard to

interpret on how they relate to RTSP and what

requirement level that is needed. 

Date:

The date header MUST be sent by origin server in

responses. What is an origin server and what exceptions

exist for RTSP? For RTSP does that include requests also?

Host:

The comment is that this should not be used in RTSP.

This should be reflected in the heade table. 

Other headers that are simply referenced needs most

probably some specification on applicability and

exceptions.

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

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

--__--__--

Message: 9
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:55:02 -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 (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=619421&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Nobody/Anonymous (nobody)
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-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: 10
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:55:24 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-630920 ] RTP-Info does not support multiple SSRC

Bugs item #630920, was opened at 2002-10-30 08:44
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=630920&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: RTP-Info does not support multiple SSRC

Initial Comment:
The RTP-Info header can't be used to synchronize

multiple RTP flows using different SSRC as a single

media stream. As each SSRC has its own RTP sequence and

timestamp space to allow synchronization it needs to be

possible to give these values for each SSRC in the

media stream. 

This bug has connection with bug# 625352.

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

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

--__--__--

Message: 11
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Mon, 22 Sep 2003 01:55:47 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-633148 ] Use of TCP and UDP

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

Category: General
Group: Fix DS - Needs clarificiation
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Use of TCP and UDP

Initial Comment:
A clarification one how each protocol shall be used to

transport RTSP messages seems beneficial. 

For example one should clarify that TCP are bytes

streams and any fragmenetation are valid, but that for

efficieny one should send the a message in as few

packets as possible. 

UDP needs rules if fragementation is allowed or not. 

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

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

End of Rtspspec-bugs Digest

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