Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #18 - 12 msgs

From: [email-masked]
Date: Mon, 28 Jan 2002 19:45:02 -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-477400 ] Play without range while playing ([email-masked])
   2. [ rtspspec-Bugs-448521 ] URLs in Rtp-Info need to be quoted ([email-masked])
   3. [ rtspspec-Bugs-449074 ] RTP Seqnum offset in Pause Play response ([email-masked])
   4. [ rtspspec-Bugs-461083 ] Body w/o Content-Length clarification ([email-masked])
   5. [ rtspspec-Bugs-477404 ] Errors in table in chapter 12 ([email-masked])
   6. [ rtspspec-Bugs-477403 ] Missing session header in response ([email-masked])
   7. [ rtspspec-Bugs-477405 ] Missing in transport ABNF:source ([email-masked])
   8. [ rtspspec-Bugs-477408 ] Session ID BNF, correction ([email-masked])
   9. [ rtspspec-Bugs-477408 ] Session ID BNF, correction ([email-masked])
  10. [ rtspspec-Bugs-477411 ] SDP examples, field order ([email-masked])
  11. [ rtspspec-Bugs-477415 ] Transport header example ([email-masked])
  12. [ rtspspec-Bugs-477418 ] RTP info BNF error ([email-masked])

--__--__--

Message: 1
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 11:46:00 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477400 ] Play without range while playing

Bugs item #477400, was opened at 2001-11-01 23:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477400&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: Rob Lanphier (robla)
Summary: Play without range while playing

Initial Comment:
A PLAY request without a Range header is legal. It starts playing a
stream from the beginning unless the stream has been paused. If a
stream has been paused via PAUSE, stream delivery resumes at the
pause point. If a stream is playing, such a PLAY request causes no
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
further action and can be used by the client to test server liveness.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In a response to play without range while playing, what shall the server
do with RTP-Info? The RTP-Info is required according to table in the
beginning of chapter 12, but my opinion is that it lacks meaning in this
case.

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 09:49

Message:
Logged In: YES 
user_id=3796

We should deprecate this use of PLAY, and add a PING method (so that we can explicitly ensure there are 
no side effects)  The nice thing about PING is that we can define it as bidirectional.

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

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

--__--__--

Message: 2
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 14:20:36 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-448521 ] URLs in Rtp-Info need to be quoted

Bugs item #448521, was opened at 2001-08-06 13:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=448521&group_id=23194

Category: None
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders Klemets (klemets)
Assigned to: Rob Lanphier (robla)
Summary: URLs in Rtp-Info need to be quoted

Initial Comment:
The Rtp-Info header contains URLs, but those URLs are 
not quoted, causing problems when the URLs contain 
semi-colon, equal signs and comma characters.

The best way to quote URLs are by using double-
quotes.  Using angle-brackets has also been proposed, 
but using double-quotes is more likely to be 
compatbile with existing implementations, because 
other RTSP/HTTP headers use double-quote characters 
in similar situations.

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-28 14:20

Message:
Logged In: YES 
user_id=437905

RESOLUTION: (Jan 9, 2002 telecon) 
Proposed solution was accepted.  Alternative use of 
semicolon and comma were considered  by classified 
as "dangerous characters" ans would break existing 
implementations.

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

Comment By: Henning Schulzrinne (hgschulz)
Date: 2002-01-09 09:20

Message:
Logged In: YES 
user_id=115926

URL escaping (%xx) doesn't work since you lose the
distinction between syntactically significant semicolons
(etc.) and just characters that were escaped in the original
URL.

Only comma and semicolon need to be escaped, since equal
signs are not delimiters.

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 09:26

Message:
Logged In: YES 
user_id=3796

I should probably clarify the comments made yesterday.  This is a genuine issue, but
it needs to be weighed against backward-compatibility needs.  Would like input from
implementors on what the best solution is.

We would propose the following: 
*  We need to define the problem characters.  ";" and "=" are two, there may be others
*  URLs MUST not be quoted when no problem characters are present in the URL.  This will help maintain 
backwards-compatibilty with current implementations
*  URLs MUST be quoted when problem characters are present

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-12 14:14

Message:
Logged In: YES 
user_id=3796

add quotes only when sending problem characters (";", "=", ",", need to think further)

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

Comment By: Rob Lanphier (robla)
Date: 2001-08-07 07:21

Message:
Logged In: YES 
user_id=3796

This is primarily to test if mail to confctrl is working

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

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

--__--__--

Message: 3
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 14:25:45 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-449074 ] RTP Seqnum offset in Pause Play response

Bugs item #449074, was opened at 2001-08-08 03:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=449074&group_id=23194

Category: General
Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Rob Lanphier (robla)
Summary: RTP Seqnum offset in Pause Play response

Initial Comment:
While implementing RTSP and RTP, there is a concernt
that after Pause, if Play request selects same stream 
but another random seqnum offset, RTP receiver may 
incrrectly report packet losses.

It is desirable to add a statement in future RTSP spec 
to require that the Play response use previous seqnum 
+ 1 as seqnum offset if the Play is to resume a paused 
stream.

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-28 14:25

Message:
Logged In: YES 
user_id=437905

RESOLUTION: (Jan 9, 2002 telecon)
Sequence numbers increase per suggestion. Resolution is a 
clarification of RFC 1889 and not a new requirement.

A new issue was raised to clarify concerns 
regarding  "timestamp monotmnically increasing". (See 
appendix "B" of specification (RTP usage).

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

Comment By: Rob Lanphier (robla)
Date: 2002-01-24 13:25

Message:
Logged In: YES 
user_id=3796

Discussed on Jan 9 telecon: 
http://rtsp.org/2002/telecon/jan09.html

RESOLVED: sequence numbers increase per suggestion in 
report. This is a clarification of RFC 1889, not new 
requirement

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 08:00

Message:
Logged In: YES 
user_id=3796

We believe that we can only recommend this solution, but not require it.  We'll update the draft to reflect 
this.

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

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

--__--__--

Message: 4
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 14:28:58 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-461083 ] Body w/o Content-Length clarification

Bugs item #461083, was opened at 2001-09-12 18:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=461083&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Lango (jasonlango)
Assigned to: Rob Lanphier (robla)
Summary: Body w/o Content-Length clarification

Initial Comment:
RFC 2326 says: 

4.4 Message Length

   When a message body is included with a message, the
length of that body is determined by one of the
following (in order of precedence):
 
   1.     Any response message which MUST NOT include a
message body
          (such as the 1xx, 204, and 304 responses) is
always terminated
          by the first empty line after the header
fields, regardless of
          the entity-header fields present in the
message. (Note: An
          empty line consists of only CRLF.)

   2.     If a Content-Length header field (section
12.14) is present,
          its value in bytes represents the length of
the message-body.
          If this header field is not present, a value
of zero is
          assumed.
 
   3.     By the server closing the connection.
(Closing the connection
          cannot be used to indicate the end of a
request body, since
          that would leave no possibility for the
server to send back a
          response.)
 
.. so it is saying that closing the connection is Ok to
indicate the length.

.. but then in section 12.14, it also says that the
Content-Length header MUST be sent.

The two sections should probably be made consistent.

Currently a popular RTSP server implementation (QTSS)
sends
"Connection: Close" followed by a message body for
certain
RTSP error status responses.

It might be worth requiring 'Connection: Close' in item
3 of
section 4.4 to reduce the ambiguity of whether or not a
compatible implementation may expect a response to
contain
a message body.

Alternatively it might be worth -not- saying that
message length
may be determined by the server closing the connection.

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-28 14:28

Message:
Logged In: YES 
user_id=437905

RESOLUTION: (Jan 9, 2002 teleconference)

Eliminate implicit body-length via connection: close.  
COntactt David SInger on this issues and encourage f 
future participation.  Verify resolution is consistent 
with SIP specificaiton.

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 09:32

Message:
Logged In: YES 
user_id=3796

This is a potentially gnarly issue.  We agree that this is a problem that needs fixing.

We propose that we eliminate the option of implied Content-Length if possible (need 
to check with implementors on this....Darwin server in particular).  If we can't do 
that, require Connection: close, and change header definition.

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

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

--__--__--

Message: 5
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 14:41:35 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477404 ] Errors in table in chapter 12

Bugs item #477404, was opened at 2001-11-01 23:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477404&group_id=23194

Category: None
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Errors in table in chapter 12

Initial Comment:
 Table with RTSP headers page 45, contains the following errors?:
  - A session header is not required when using describe.
  - Proxy Authenticate is missing all values on what it is.
  - The transport header is specifed as required in 12.0 table, but
    the text in 12.39 says it MAY be included in requests and responses.

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-28 14:41

Message:
Logged In: YES 
user_id=437905

RESOLUTION:  

The latest SIP draft has an equivalent table. It has been  
recommended that we evaluate this SIP table and unless 
someone objects and justifies the need to make a change 
let's adopt the SIP draft specification version. 

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

Comment By: Rob Lanphier (robla)
Date: 2002-01-22 19:47

Message:
Logged In: YES 
user_id=3796

Here's a discrepency between the initial CVS checkin and RFC 2326
  12  Header Field Definitions (Table 3):
   Change from:
   Content-Type         r      req.      entity
   To:
   Content-Type        e    req.   SET_PARAMETER, ANNOUNCE

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 09:53

Message:
Logged In: YES 
user_id=3796

These are all good examples of what's wrong with this table.  We need to do an audit of the table, and we 
may restructure this table for clarity.  Suggestions for a new table format would be appreciated.

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

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

--__--__--

Message: 6
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 15:23:30 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477403 ] Missing session header in response

Bugs item #477403, was opened at 2001-11-01 23:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477403&group_id=23194

Category: None
Group: Fix for DS - Typo/Thinko
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
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: Rob Lanphier (robla)
Date: 2002-01-28 15: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 09:51

Message:
Logged In: YES 
user_id=3796

Whoops...will fix.

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

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

--__--__--

Message: 7
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 15:27:24 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477405 ] Missing in transport ABNF:source

Bugs item #477405, was opened at 2001-11-01 23:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477405&group_id=23194

Category: None
Group: Fix for DS - Typo/Thinko
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing in transport ABNF:source

Initial Comment:
Page 59, the "source:" paragrah what is the intention? Is it just
missing in the BNF for transport headers?

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

>Comment By: Rob Lanphier (robla)
Date: 2002-01-28 15:27

Message:
Logged In: YES 
user_id=3796

Fixed in CVS

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 09:54

Message:
Logged In: YES 
user_id=3796

source needs to be added to the BNF.  Will fix.

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

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

--__--__--

Message: 8
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 15:29:07 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477408 ] Session ID BNF, correction

Bugs item #477408, was opened at 2001-11-01 23:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477408&group_id=23194

Category: None
Group: Fix for DS - Typo/Thinko
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Session ID BNF, correction

Initial Comment:
Section 3.4 definition of session-id should it not be:
  session-id   =   8*( ALPHA | DIGIT | safe )
  instead of 1*?

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 19:40

Message:
Logged In: YES 
user_id=3796

Agreed.  Fix for next draft

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

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

--__--__--

Message: 9
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 15:29:38 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477408 ] Session ID BNF, correction

Bugs item #477408, was opened at 2001-11-01 23:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477408&group_id=23194

Category: None
Group: Fix for DS - Typo/Thinko
Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Session ID BNF, correction

Initial Comment:
Section 3.4 definition of session-id should it not be:
  session-id   =   8*( ALPHA | DIGIT | safe )
  instead of 1*?

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

>Comment By: Rob Lanphier (robla)
Date: 2002-01-28 15:29

Message:
Logged In: YES 
user_id=3796

Fixed in CVS

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 19:40

Message:
Logged In: YES 
user_id=3796

Agreed.  Fix for next draft

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

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

--__--__--

Message: 10
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 15:46:04 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477411 ] SDP examples, field order

Bugs item #477411, was opened at 2001-11-01 23:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477411&group_id=23194

Category: None
Group: Fix for DS - Typo/Thinko
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: SDP examples, field order

Initial Comment:
SDP examples in spec is in wrong order: The SDP specifcation requires a certain order between the 
type names, see section 6 in RFC 2327.

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

>Comment By: Rob Lanphier (robla)
Date: 2002-01-28 15:46

Message:
Logged In: YES 
user_id=3796

I fixed the examples cited.  I haven't done a thorough audit of the spec, but I did do a cursory look.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-02 00:48

Message:
Logged In: NO 

Yes. The right sequence is...s->c->t
the example seems to be wrong...
I can see the mistake at C.3, too

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

Comment By: Magnus Westerlund (magwes)
Date: 2001-11-01 23:31

Message:
Logged In: YES 
user_id=302620

These are at least erronous

14.4 Live Media Presentation Using Multicast
 ...
 m=audio 3456 RTP/AVP 0
 a=control:rtsp://live.example.com/concert/audio
 c=IN IP4 224.2.0.1/16

 and

 C.2 Aggregate Control Not Available
 ...
 s=I came from a web page
 t=0 0
 c=IN IP4 0.0.0.0

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

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

--__--__--

Message: 11
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 15:51:23 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477415 ] Transport header example

Bugs item #477415, was opened at 2001-11-01 23:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477415&group_id=23194

Category: None
Group: Fix for DS - Typo/Thinko
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transport header example

Initial Comment:
Page 68 example with transport header uses <mode=play> which does not include " which the 
ABNF says it should be. Correct according to ABNF is mode="PLAY"

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

>Comment By: Rob Lanphier (robla)
Date: 2002-01-28 15:51

Message:
Logged In: YES 
user_id=3796

Fixed in CVS

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 19:47

Message:
Logged In: YES 
user_id=3796

Good point.  Needs to be fixed.

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

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

--__--__--

Message: 12
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 16:36:04 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477418 ] RTP info BNF error

Bugs item #477418, was opened at 2001-11-01 23:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477418&group_id=23194

Category: None
Group: Fix for DS - Typo/Thinko
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTP info BNF error

Initial Comment:
Sec 12.33 RTP info syntax of RTP info is wrong, compared to the example. The current syntax 
specifec a comma separated list of URLS then follows the parameters. Should it not be like this?
  RTP-Info        = "RTP-Info" ":" 1#rtp-info-spec
  rtp-info-spec   = stream-url 1*parameter
  stream-url      = "url" "=" url
  parameter       = ";" "seq" "=" 1*DIGIT | ";" "rtptime" "=" 1*DIGIT

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

>Comment By: Rob Lanphier (robla)
Date: 2002-01-28 16:36

Message:
Logged In: YES 
user_id=3796

Fixed in CVS

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 09:56

Message:
Logged In: YES 
user_id=3796

Will fix -- may want to couple this with #448521

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-02 01:04

Message:
Logged In: NO 

you are right. spec. must be changed

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

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

End of Rtspspec-bugs Digest

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