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

From: [email-masked]
Date: Wed, 04 Feb 2004 08:04:19 -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-633779 ] SET_PARAMETER responses (SourceForge.net)
   2. [ rtspspec-Bugs-634944 ] Restarting media not allowing seek (SourceForge.net)
   3. [ rtspspec-Bugs-640272 ] Default way of deriving aggregate URL (SourceForge.net)
   4. [ rtspspec-Bugs-640265 ] Extension of Transport header (SourceForge.net)
   5. [ rtspspec-Bugs-640848 ] umbiguity in aggregate/non-aggregate pla (SourceForge.net)
   6. [ rtspspec-Feature Requests-662436 ] RTP/AVP/TCP w/o interleaved (SourceForge.net)
   7. [ rtspspec-Bugs-640848 ] umbiguity in aggregate/non-aggregate pla (SourceForge.net)
   8. [ rtspspec-Bugs-640848 ] umbiguity in aggregate/non-aggregate pla (SourceForge.net)
   9. [ rtspspec-Feature Requests-647838 ] Warning header (SourceForge.net)
  10. [ rtspspec-Bugs-672160 ] Describe a interleaved RTSP channel for client RR reports (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 07:14:21 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-633779 ] SET_PARAMETER responses

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

Category: General
Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: SET_PARAMETER responses

Initial Comment:
Clarify on the usage of SET_PARAMETER when no body is
present. A correct syntax with unknown headers will
result in a 200 response but also the understanding of
a propreitary or new header will result in 200. Clarify
that a requester should use the Require header with an
option tag to ensure that the responder of the request
really understands the propreitary or new header. 

Also write text recommending on the usage of parameters
in the body with the motivation that they are simpler
than using require and headers. But both case should be
possible to use. 

How to handle a empty parameter list in the body should
also be explained. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 16:14

Message:
Logged In: YES 
user_id=302620

Forgotten to assign it to me. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 16:13

Message:
Logged In: YES 
user_id=302620

Added text trying to clarify that it is allowed to use for
keep alive. Also clarified the possible pit-falls with using
headers in such a method. 

Please review!

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

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

Message:
Logged In: YES 
user_id=3796

From 14 May 2003 telecon
(http://rtsp.org/2003/telecon/minutes14May.html):
#  Magnus: how to respond if server doesn't understand parameter
# Anders: maybe a require header to be used if necessary
# Magnus: I can agree with just a clarification
# Anders: for proprietary client request, it can expect
proprietary response
# Magnus: easier if just use body
# Anders: don't need to specify more than that
# Rob: I agree
# Magnus: spec says that SET_PARAMETER can be used for keep
alive
# Magnus: it's possible to have SET_PARAMETER without body
# RESOLUTION: Short explanation of SET_PARAMETER without
body being allowed. No other changes

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

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

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 07:16:27 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-634944 ] Restarting media not allowing seek

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

Category: None
Group: Fix for DS - Need WG Input
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Restarting media not allowing seek

Initial Comment:
The current proposal for what happens when a on-demand
stream reaches its end is that a explicit seek to the
begining is required to see the media from the
begining. However how this work for media that does not
allow seek needs to be clarififed. 
- I think a media dissalowing random access will still
allow the media to be seen from the begining.
- Also how the discovery of which time formats that
will be allowed needs to be clarified.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 16:16

Message:
Logged In: YES 
user_id=302620

As this is not directly related to RTSP, rather a content
type information problem, the bug is closed. 

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

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

Message:
Logged In: YES 
user_id=3796

From 14 May 2003 telecon
(http://rtsp.org/2003/telecon/minutes14May.html):
#  Magnus: we should close the bug, can be solved by
standard RTSP server side support
# Magnus: some of the OMA DRM work may apply
# Anders: maybe something that can be done in SDP. a=type?
# Magnus: on demand media stored, but seeking not allowed.
# Magnus: can be on the server side
# Rob: only complexity is trying to have client interface
before seek is tried
# Rob: DVDs don't accomodate this, though
# Anders: no way to "grey out" the seek buttons on DVD remote
# Joerg: it would be possible to define SDP attribute, but
we may end      up in rathole trying to characterize all of
the possible attributes (for speed, etc). 
# Magnus: I think RTSP will not have problems here. Current
spec is fine
# Rob: Agreed
# RESOLUTION: close the bug as implemented on server

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

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

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 08:28:01 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-640272 ] Default way of deriving aggregate URL

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

Category: General
Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Default way of deriving aggregate URL

Initial Comment:
Currently there is very little said on which aggregated
control URL to use. The only given case is the
a=control attribute in SDP at session level. In cases
when one aggregates media stream that have no common
SDP declaration or dependencies in other ways the URL
can't be derived. Examples of such cases is when you
would like to aggregate a session multiplexed
retransmission stream with the original data stream,
without requiring aggregatation between all media types
part of a stream. Another example is aggregation of
streams that are lacking a common SDP description but
still can be intressting to aggregate. 

To fix this a way to derive what a valid aggregate URL
is needs to be specified. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 17:28

Message:
Logged In: YES 
user_id=302620

The rules for creating aggregated URIs has been removed upon
discussion in the IETF meeting. anything about using
aggregated control URIs when not specified by session
description has been labeled as unspecified. 

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

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

Message:
Logged In: YES 
user_id=302620

Currently I have written in the specification text that a
client not having received a aggregated control URI SHOULD
consider it as no aggregation available. However it does not
rule out that one tries to create aggregated control. The
rules for how to create the URI is present. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-22 17:40

Message:
Logged In: YES 
user_id=302620

In the IETF in Vienna discussion July 16th 2003:

Issue: Missing session level control URI in SDP. IF the
session control URI is missing, should we allow the client
to try to to aggregate these? If aggregated which session
control URI must be used.

Discussion: This needs to be resolved. Tom Marshall did not
thought that we should prevent the use case to aggregate
unless necessary for interoperability. One possible
resolution is to say that any media description missing
session level control URI must be setup with individual RTSP
session for each media stream and any synchronization
between media be done on the receiver side. A practical
resolution resolution could be: A client SHOULD follow the
above statement but MAY try to aggregate. The server MAY
allow this aggregation but MAY also refuse it using 4xx
(Only non aggregated operation allowed).

Resolution?: Session declarations lacking a session level
control URL, MUST be used in non-aggregated control.
Further discussion needed? 

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

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

Message:
Logged In: YES 
user_id=3796

From 14 May 2003 telecon
(http://rtsp.org/2003/telecon/minutes14May.html):
# Magnus: this is problem when aggregate control done in not
obvious way
# Magnus: what happens when you try to aggregate things that
aren't designed to be aggregated
# Joerg: I think this would require a lot of work to make
this work correctly
# Magnus: solution is to solve this with non-aggregate control
# Tom: how does client know
# Magnus: reuse session id
# Tom: what happens when you pass the session id with a
different URL
# Rob: it should be undefined
# Magnus: it should return error
# Rob: that's no more backward compatible
# Magnus: do you have proposed wording 11.4 second paragraph
# RESOLUTION: Tom to write up wording for 11.4 second paragraph

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

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

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 07:49:23 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-640265 ] Extension of Transport header

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

Category: General
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: Extension of Transport header

Initial Comment:
The current BNF definition of the transport header does
not allow extensions of new parameters.  I suggest that
a trn-parameter-extension is defined in the BNF to
allow for future extensions. Further a mechansism
explaining that unknwon parameters are allowed to
ignore. If a parameter is vital a option-tag and the
Require header needs to be used. 

This might have backwards compatibility issues as it
might cause parsers to decalare the transport header as
erronous. However not fixing it will cause even more
problems in the future. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 16:49

Message:
Logged In: YES 
user_id=302620

A proposal in the syntax and the some text declaring that
unknonw paramters shall be ignored is checked into CVS. 

Pleae Review

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

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

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 04 Feb 2004 02:31:10 -0800
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 (Settings changed) 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: Closed
>Resolution: Fixed
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: 2004-02-04 10:19

Message:
Logged In: YES 
user_id=302620

No comments received, closing.

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

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: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 04 Feb 2004 03:26:19 -0800
Subject: [rtspspec-bugs] [ rtspspec-Feature Requests-662436 ] RTP/AVP/TCP w/o interleaved

Feature Requests item #662436, was opened at 2003-01-05 03:01
Message generated for change (Settings changed) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377747&aid=662436&group_id=23194

>Category: None
>Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTP/AVP/TCP w/o interleaved

Initial Comment:

If a Transport line specifies RTP/AVP/TCP
and does not also use the interleaved
parameter, the transport setup details
seem undocumented (maybe I'm not looking
in the right place ...).

I'm thinking of the level of detail the
comedia I-D provides for TCP: which
side accept()s and which side connect()s,
how many connections to set up, framing, 
etc.

Are there pre-existing implementations 
that use this transport mode? I happened
to stumble onto this in writing the TCP
appendix for the MWPP "implementation
guidelines" ... which may spawn off a
generic I-D specifying how to use comedia
with RTP (framing, specifying the fmt
tokens after TCP, etc). So, one option
is to add RTP/AVP/TCP w/o interleaving
details to that I-D, if adding it to
to the RTSP I-D isn't desirable for
some reason ...

john lazzaro -- [email-masked]

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-04 11:31

Message:
Logged In: YES 
user_id=302620

The relation to different media and lower layer transport
has been clarified in the new draft. There are clear
explaination of the RTP/AVP/TCP is not currently specified,
but can be. 

I don't expect that we will do much more about it, as it is
a extension rather then a fix to current protocol parts.
Therefore moving it to the feature request tracker. 

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

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

Message:
Logged In: YES 
user_id=3796

From 14 May 2003 telecon
(http://rtsp.org/2003/telecon/minutes14May.html):
#  Magnus: we should leave this until RTP framing is done
# Magnus: this is basically a feature request
# Magnus: this might well be a separate draft
# Rob: agreed
# Aravind: agreed
# Tom: we'll have to deal with this issue when DCCP comes along
# Anders: I saw this in use
# Tom: they might be using interleaving or not
# RESOLUTION: separate draft for non-interleaving; narrow
spec for      interleaving 

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

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

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 04 Feb 2004 03:26:22 -0800
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 (Settings changed) 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: Closed
>Resolution: Fixed
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: 2004-02-04 12:26

Message:
Logged In: YES 
user_id=302620

No comments received, closing.

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

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-04 10:19

Message:
Logged In: YES 
user_id=302620

No comments received, closing.

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

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: 8
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 04 Feb 2004 03:26:23 -0800
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: Closed
>Resolution: Fixed
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: 2004-02-04 12:26

Message:
Logged In: YES 
user_id=302620

No comments received, closing.

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

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-04 12:26

Message:
Logged In: YES 
user_id=302620

No comments received, closing.

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

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-04 10:19

Message:
Logged In: YES 
user_id=302620

No comments received, closing.

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

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: 9
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 04 Feb 2004 05:02:17 -0800
Subject: [rtspspec-bugs] [ rtspspec-Feature Requests-647838 ] Warning header

Feature Requests item #647838, was opened at 2002-12-03 15:27
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377747&aid=647838&group_id=23194

>Category: None
>Group: None
Status: Open
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Warning header

Initial Comment:
To be able to send more detailed error messages it
might be good to include the SIP header "Warning". 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-04 14:02

Message:
Logged In: YES 
user_id=302620

As this is a feature request rather than a bug. I move it to
the feature request tracker. 

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

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

Message:
Logged In: YES 
user_id=302620

This was discussed at the 56th IETF meeting and then later
on the teleconf of 28th April 2003. 

The result is to leave it out unless somebody see a real
need to included these headers. Their main use would be
related to debugging. 

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

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

--__--__--

Message: 10
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Wed, 04 Feb 2004 08:03:47 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-672160 ] Describe a interleaved RTSP channel for client RR reports

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

Category: General
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas M Zeng (zengtm)
>Assigned to: Magnus Westerlund (magwes)
Summary: Describe a interleaved RTSP channel for client RR reports 

Initial Comment:
 In the section on RTP interleaved over the RTSP 
channel (section 10.13), there was no
mention of the client sending RTCP RR back to the 
server.  Are these still
present?  They did specify the sender reports from the 
server to client, but that's it.  The back channel is 
symmetric to the RTCP for server to send SRs and 
should be described as such (i.e. described in Transport 
headers).

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

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-04 17:03

Message:
Logged In: YES 
user_id=302620

The above problem has been clarified with the following text:

The channel identifier is defined in the Transport header
with the interleaved parameter(Section 13.40). When the
transport choice is RTP, RTCP messages are also interleaved
by the server over the TCP connection. The usage of RTCP
messages is indicated by including a range containing a
second channel in
the interleaved parameter of the Transport header, see
section 13.40. If RTCP is used, packets SHALL be sent on the
first available channel higher than the RTP channel. The
channels are bi-directional and therefore RTCP traffic are
sent on the second channel in both directions.

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

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

End of Rtspspec-bugs Digest

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