Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #55 - 6 msgs

From: [email-masked]
Date: Wed, 30 Oct 2002 12:25:12 -0800

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-556295 ] Client issues PAUSE while server ready ([email-masked])
   2. [ rtspspec-Bugs-556589 ] multicast issue in interleaved ([email-masked])
   3. [ rtspspec-Bugs-557045 ] Need "Supported" header ([email-masked])
   4. [ rtspspec-Bugs-608365 ] 3xx codes overhaul and clarification ([email-masked])
   5. [ rtspspec-Bugs-619421 ] Range header in PLAY response ([email-masked])
   6. [ rtspspec-Bugs-625339 ] need clarification for stand alon SDP ([email-masked])

--__--__--

Message: 1
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 10:16:36 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-556295 ] Client issues PAUSE while server ready

Bugs item #556295, was opened at 2002-05-15 14:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=556295&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: Rob Lanphier (robla)
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: 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: 2
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 10:21:32 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-556589 ] multicast issue in interleaved

Bugs item #556589, was opened at 2002-05-16 04:10
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=556589&group_id=23194

Category: General
>Group: Fix for DS - Typo/Thinko
Status: Open
Resolution: None
Priority: 5
Submitted By: Jaehwan, Kim (kjh1905m)
Assigned to: Nobody/Anonymous (nobody)
Summary: multicast issue in interleaved

Initial Comment:
In 'transport' header field, multicast keyword is 
default. 

In the example of '10.12 Embedded (Interleaved) Binary 
Data' in RFC2326, even though this transport type is 
TCP, there is no unicast keyword.

Generally multicast can not be used in TCP.

Therefore, the example of '10.12 Embedded 
(Interleaved) Binary Data' in RFC2326 must be changed.

or 

The default cast method should be changed as unicast.

Jaehwan, Kim([email-masked])

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

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

Message:
Logged In: YES 
user_id=302620

I beleive the example to be wrong. Interleaved is not
limited to TCP and may therefore be used over another
protocol that can allow multicast. Therefore I think adding
unicast parameters to the example is the simples solution. 

This is fixed in the text. 

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

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

--__--__--

Message: 3
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 10:23:24 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-557045 ] Need "Supported" header

Bugs item #557045, was opened at 2002-05-17 04:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=557045&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: Need "Supported" header

Initial Comment:
This is added to resolve http://rtsp.org/bug477427

There needs to be a way for non-fatal queries which can
be issued with methods.

The current proposal is to use the SIP "Supported" header.

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

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

Message:
Logged In: YES 
user_id=302620

The Supported header is added to the text. Including usage
under options. 

One consideration has been rasied that the message size can
be rather big if many option tags are defined. Due to
interoperability it seems that rather many tags need to be
defined. 

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

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

Message:
Logged In: YES 
user_id=3796

Current proposal checked into CVS:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/headers.tex.diff?r1=1.15&r2=1.16

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

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

--__--__--

Message: 4
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 10:27:36 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-608365 ] 3xx codes overhaul and clarification

Bugs item #608365, was opened at 2002-09-12 15:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=608365&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: Magnus Westerlund (magwes)
Summary: 3xx codes overhaul and clarification

Initial Comment:
The 3xx codes are all directly taken from HTTP. There
seem that not all are suitable for RTSP. A review of
the codes and the needs should be perforemed. 

Also the usage of 3xx responses needs some work. What
headers to include, etc.

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

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

Message:
Logged In: YES 
user_id=302620

I have written up a proposal for fixing this within the
spec. Two new codes are defiend 350, and 351. 303 is
suggested to be decapitated. 304 needs further discussion.
Also user comments has been added to the status chapter. 

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

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

--__--__--

Message: 5
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 10:36:01 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-619421 ] Range header in PLAY response

Bugs item #619421, was opened at 2002-10-07 01:14
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: Rob Lanphier (robla)
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: 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: 6
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 10:38:11 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-625339 ] need clarification for stand alon SDP

Bugs item #625339, was opened at 2002-10-18 19:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625339&group_id=23194

Category: None
>Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Go Hori (ghori)
Assigned to: Nobody/Anonymous (nobody)
Summary: need clarification for stand alon 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: 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

End of Rtspspec-bugs Digest

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