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

From: [email-masked]
Date: Tue, 03 Feb 2004 06:39:01 -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-507347 ] Removal of destination redirection (SourceForge.net)
   2. [ rtspspec-Bugs-507347 ] Removal of destination redirection (SourceForge.net)
   3. [ rtspspec-Bugs-889699 ] Change requirement level on auth for media destination (SourceForge.net)
   4. [ rtspspec-Bugs-507884 ] Should sequnce numbers be consecutive (SourceForge.net)
   5. [ rtspspec-Bugs-513737 ] Unclarities when doing resetup (SourceForge.net)
   6. [ rtspspec-Bugs-513787 ] Allow capability negotiations (SourceForge.net)
   7. [ rtspspec-Bugs-539001 ] Transport header should override m= (SourceForge.net)
   8. [ rtspspec-Bugs-556061 ] When can REDIRECT be received? (SourceForge.net)
   9. [ rtspspec-Bugs-556295 ] Client issues PAUSE while server ready (SourceForge.net)
  10. [ rtspspec-Bugs-477403 ] Missing session header in response (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 05:10:05 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507347 ] Removal of destination redirection

Bugs item #507347, was opened at 2002-01-23 05:39
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507347&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: Removal of destination redirection

Initial Comment:
Discrepency between RFC 2326 and initial checkin:

12.39 Transport:  In CVS, the following phrase has been removed from the specifation:

"A server SHOULD not allow a client to direct media streams to an address that differs from the 
address commands are coming from."  

I don't necessarily oppose this because there are totally legitimate reasons for sending to a 
different address, but we should probably come up with alternate wording that makes it clear.

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

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

Message:
Logged In: YES 
user_id=302620

The section contains today a more elaborate security
clarification. However the language must most likely be
befeed up from SHOULD authenticate to SHALL authenticate to
be able to pass IESG.

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

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

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 05:11:32 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507347 ] Removal of destination redirection

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

Category: General
>Group: Resolved - Added to text
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Rob Lanphier (robla)
Assigned to: Nobody/Anonymous (nobody)
Summary: Removal of destination redirection

Initial Comment:
Discrepency between RFC 2326 and initial checkin:

12.39 Transport:  In CVS, the following phrase has been removed from the specifation:

"A server SHOULD not allow a client to direct media streams to an address that differs from the 
address commands are coming from."  

I don't necessarily oppose this because there are totally legitimate reasons for sending to a 
different address, but we should probably come up with alternate wording that makes it clear.

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

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

Message:
Logged In: YES 
user_id=302620

A new bug will be logged regarding the requirments level of
the text. Destination redirection will not be removed. 

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

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

Message:
Logged In: YES 
user_id=302620

The section contains today a more elaborate security
clarification. However the language must most likely be
befeed up from SHOULD authenticate to SHALL authenticate to
be able to pass IESG.

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

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

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 05:14:08 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-889699 ] Change requirement level on auth for media destination

Bugs item #889699, was opened at 2004-02-03 14:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=889699&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: Change requirement level on auth for media destination

Initial Comment:
The current text on the transport headers destination
and dest_addr header is that they SHOULD use
authentication to verify that the receiver is allowed
to redirect to this target. 

I think that to be able to get this past the IESG and
for achieving good security the SHOULD needs to be a
SHALL. 

Opinions? 

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

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

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 05:15:22 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507884 ] Should sequnce numbers be consecutive

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

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Should sequnce numbers be consecutive

Initial Comment:
To make it possible to detect losses of request when transported over UDP, the sequnce number 
should be consecutive. In that way the server will know that it should not process a request until 
the missing ones before is received. 

Are there any issues with such a solution? 
Does the first sequence number needs to be specified so losses of the first message(s) is known?

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

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

Message:
Logged In: YES 
user_id=302620

Closing this bug as no comment has been given. 

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

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

Message:
Logged In: YES 
user_id=302620

The text has been updated, with explict text about sequence
number may start at any value, but is recommended to start
at 0. 

The connection chapter has also be restructered. 

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

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

Message:
Logged In: YES 
user_id=302620

The specification is updated to require increments with one
for each new message. However the initial value is still
free to pick. 

The effect of losing the first packet is that request can be
performed in another order than intended. However if you
loose a not state changing event (Options, DESCRIBE) it will
not really matter. The first setup can't be pipelined unless
it is done with another SETUP request for two non-aggregate
session. A client is not allowed to issue a PLAY until the
SETUP request response is back. 

So I don't see how it can matter.  

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

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

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 05:16:18 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513737 ] Unclarities when doing resetup

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

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: Unclarities when doing resetup

Initial Comment:
Setup is used to change transport parameters of a already setuped stream. What happends if the 
new SETUP contains errors? Except of responding with an error message, what happends to the 
session and transport state? It should be clarified in the specification. Which of the following 
alternatives are correct?

1. Keep the old setting and states as if the second SETUP never happend.
2. Invalidate the media in the session until a correct setup has happend.

To me case 1 seems more natural but will require more from the server. 

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

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

Message:
Logged In: YES 
user_id=302620

This has been fixed a long time ago, closing bug. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-05-15 10:09

Message:
Logged In: YES 
user_id=302620

A clarified third paragraph in the SETUP section (11.3) has
been added. If a setup request fails the previous state
shall be left as it was, i.e. proposal 1 in the initial
declartion of this bug. 

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

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

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 05:17:12 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513787 ] Allow capability negotiations

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

>Category: Feature Request
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow capability negotiations

Initial Comment:
Today RTSP lacks the possibility to do any kind of capability/parameter negotiation or at least 
choices regarding media parameters. 

I would like to see possibilities for this in the future. My initial idea is to make a offer/answer model. 
This will require expanding the SETUP request to carry a message body. A message exchange could 
work like this.

1. C->S: Describe
2. S->C: Response with media description, SDP or in the future SDP-NG. This description contains 
multiple alternatives or in the case SDP-NG a complete description of the choices regarding media 
that the client can do.
3. Client selects its desired configuration.
4. C->S: Setup with message body with choosen configuration in SDP/SDP-NG.
5. S->C: Server either accepts or refuses the setup with the given configuration. Refusing should 
happend very rarely as server should not offer anything it can provide.

Such solution should try to keep the difference between media parameters and transport 
parameters. Transport parameters should be keept in the transport header to simplify processing in 
proxies and firewalls. Conclusion: only media related parameters should be negotiated with the 
offer/answer mechanism. 

To my knowledge the changes required for this is to allow a message body in SETUP requests. Also 
rules how and to what it may be used must be specified.

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

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

Message:
Logged In: YES 
user_id=302620

This is in fact a feature request. Changing category for it. 

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

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

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 05:21:43 -0800
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 (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=539001&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: Magnus Westerlund (magwes)
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.

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

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

Message:
Logged In: YES 
user_id=302620

No comments given, closing this. 

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

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

Message:
Logged In: YES 
user_id=302620

This has been clarified in the SDP appendix. There has been
alignment between what is possible between ports and addresses. 

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

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

--__--__--

Message: 8
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 05:46:03 -0800
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 (Comment added) 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: 2004-02-03 14:46

Message:
Logged In: YES 
user_id=302620

It has been further clarified when redirect and 3rr codes
can be sent and received. 

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

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: 9
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 06:36:10 -0800
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 (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=556295&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Magnus Westerlund (magwes)
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: 2004-02-03 15:36

Message:
Logged In: YES 
user_id=302620

No comments closing bug

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

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

Message:
Logged In: YES 
user_id=302620

This clarification of behavior has now beend added to the
text and will be published in v5. The text is in the state
machine and pause method section.

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

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: 10
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Tue, 03 Feb 2004 06:38:20 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477403 ] Missing session header in response

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

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: Missing session header in response

Initial Comment:
Page 38 first example: Example missing session header in response.
Should not the client respond with what session id the respond relates to, as the
request contained one.

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

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

Message:
Logged In: YES 
user_id=302620

Issue resolved, no comments given. 

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-24 10:19

Message:
Logged In: YES 
user_id=302620

The text in draft 05 has been updated in regards to the
session ID, see session header and SETUP that has been
totally restructed. Is this acceptable in regards to the
previous issue questions?

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

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-04 09:03

Message:
Logged In: YES 
user_id=302620

There has been some text changes on this section in the 04
draft. I don't think the changed text actually covers the
case completly in regards to the old text. It is also a
tighter definition. 

The new definition does not allow one to create session
without a session id as RFC2326 does. This functionality to
use some other method, like dynamic URLs, seems unspecified.
Therefore I propsoe that it is dissallowed.

Secondly the comments about when one MUST send the session
identifier:
- Robla is correct that the text does not require a server
in the response to include a session header. 
- In response to kjh1905m's comment, this MUST relates to
the client. IF you read carful it says that the client MUST
use the session identifier, if defined by the server, in any
request that is in relation to the created session. 

Actions:

- Question: Is there any need to not require the server to
generate a session ID? The use of any other method to bind
sessions is not specified. In my opinion any client being
faced with this would not understand it, and if it had the
intention of doing aggregate control, it will not know how. 

- The text in the 04 draft version should propably be
improved. I think that mentioning cases where the session
header must or must not be included in the response will
improve understanding. An example of this is the TEARDOWN,
where the presence of a session id header indicates that the
session still exist. I would also guess that having at as
default behavior to return the session ID in responses is
beneficial, but not required or something a client or proxy
cna depend on.

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

Comment By: Jaehwan, Kim (kjh1905m)
Date: 2003-09-04 07:42

Message:
Logged In: YES 
user_id=365760

Then, what is the meaning of 'MUST'?
---------------
12.37 Session

   This request and response header field identifies an RTSP 
session
   started by the media server in a SETUP response and 
concluded by
   TEARDOWN on the presentation URL. The session identifier 
is chosen by
   the media server (see Section 3.4). Once a client receives 
a Session
   identifier, it MUST return it for any request related to that
   session.  A server does not have to set up a session 
identifier if it
   has other means of identifying a session, such as 
dynamically
   generated URLs.

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

Comment By: Rob Lanphier (robla)
Date: 2002-01-29 00:23

Message:
Logged In: YES 
user_id=3796

I don't think this is a mistake.  The server isn't required to send back a session identifier if the client sends 
one.  It's only required to generate one if the client *doesn't* specify one....and only then in the SETUP 
message.

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

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

Message:
Logged In: YES 
user_id=3796

Whoops...will fix.

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

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

End of Rtspspec-bugs Digest

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