Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #46 - 4 msgs

From: [email-masked]
Date: Wed, 18 Sep 2002 12:18:39 -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-531189 ] How does REDIRECT method work ([email-masked])
   2. [ rtspspec-Bugs-448521 ] URLs in Rtp-Info need to be quoted ([email-masked])
   3. [ rtspspec-Bugs-448525 ] Syntax for SSRC should be clarified ([email-masked])
   4. [ rtspspec-Bugs-477404 ] Errors in table in chapter 12 ([email-masked])

--__--__--

Message: 1
To: [email-masked]
From: [email-masked]
Date: Wed, 18 Sep 2002 08:12:53 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-531189 ] How does REDIRECT method work

Bugs item #531189, was opened at 2002-03-18 05:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=531189&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: Magnus Westerlund (magwes)
Summary: How does REDIRECT method work

Initial Comment:
In the spec there is conflicting wording on what will happend when the server sends a REDIRECT to 
the client. In the state machine part the RFC says that the server should go to init state. Section 
10.10 REDIRECT says that the client must do TEARDOWN on the session. 

How is it supposed to work espically combined with RANGE needs to be clarified

also see #513891

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-09-18 17:12

Message:
Logged In: YES 
user_id=302620

The proposed solution for ranges does not work for content
that uses UTC for positioning, like surveilance tapes.
Suggestions on how to solve this, please.

In case that the location header only contains a server
adress the client may assume that the media is identical and
does not need to send a DESCRIBE before setting up a new
session. Otherwise it needs to do it as media may be different.

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-09-12 15:12

Message:
Logged In: YES 
user_id=302620

One more problem is that a client does not know if it should
issue a play with the range where it was redirected or start
from the begining. In the case of a media on deman and it
gets identical media from the new server it seems more valid
to resume at the position it was redirected at. However if
it gets redirected to another media it should start from the
beginng. And in the case of live media it should simply not
use any range in its PLAY request.

A mechanism needs to be added that solves this problem.

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-09-12 15:08

Message:
Logged In: YES 
user_id=302620

The result of a MMUSIC discussion is:

3xx Responses:
The server should use this to signal the client that it
should go find the media somewhere else. This answer can be
used on the methods that do inquires regarding the media or
tries to establish a session, i.e. OPTIONS (with media URL),
DESCRIBE, SETUP, and perhaps ANNOUNCE. It should not be used
when a server has an already established session and needs
to move that session to another server, i.e. don't use them
on PAUSE, PLAY, RECORD.

The client after receiving a REDIRECT must restart its work
on getting session information and setting up the session.

REDIRECT request:
This method shall be used when the server needs to move
already established session from this server. So it shall
not be used unless there is a session identifier to
reference. The redirect request SHOULD use contain the
session control URL and MUST include a session header. This
enables the client a unambiguous identification of which
session it should move.

I don't know if the server should go directly to INIT after
receiving the response from the client on the REDIRECT. This
would allow the server to reclaim any resources as fast as
possible. Alternatively the server should wait for a
teardown, but this seem to waste a round trip of time. But
as both behaviors are hinted in RFC 2326 it needs clarification.

When a client has received a REDIRECT request and
acknowledge the redirect it must assume that the session
does no longer exist. The exception is if a range header was
part of the request, and in that case it will be without a
session at the specified moment. So after receiving a
redirect the client must start from scratch to establish a
new session at the given location.

Use of location header: My opinion is that is should be a
complete RTSP URL.

Use of Range header: Also how the Range header shall be
interpreted together with REDIRECT needs to be clarified. As
the desired behavior may vary I think we need to be a little
bit cleaver here. If a range header is included and contains
a time in UTC it shall be interpreted that the server will
serve this client until that UTC time, and after that time
the client needs to establish a new session at the given
location. If a SMPTE or NPT time is given the session will
end when the playback reaches the given point in the media.
So in the case the client rewinds to the start before
reaching specified media point the session will remain. By
using UTC time the server can signal that I can't handle
your request further than e.g. until 18.00 today. Using NPT
will allow a server to redirect a user due to limitations of
the media, e.g. charging for rest of movie.

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

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

--__--__--

Message: 2
To: [email-masked]
From: [email-masked]
Date: Wed, 18 Sep 2002 08:18:31 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-448521 ] URLs in Rtp-Info need to be quoted

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

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
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: Magnus Westerlund (magwes)
Date: 2002-09-18 17:18

Message:
Logged In: YES 
user_id=302620

As this is updated in the spec at least for RTP-Info and has
been published in at least one version of draft i close it.

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

Comment By: Rob Lanphier (robla)
Date: 2002-02-19 01:36

Message:
Logged In: YES 
user_id=3796

This has been fixed in the version in CVS

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-28 23: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 18: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 18: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 23: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 16:21

Message:
Logged In: YES 
user_id=3796

This is primarily to test if mail to confctrl is working

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

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

--__--__--

Message: 3
To: [email-masked]
From: [email-masked]
Date: Wed, 18 Sep 2002 08:22:19 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-448525 ] Syntax for SSRC should be clarified

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

Category: None
Group: Fixed in CVS/Need WG Approval
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Anders Klemets (klemets)
Assigned to: Rob Lanphier (robla)
Summary: Syntax for SSRC should be clarified

Initial Comment:
The Rtp-Info header can contain an attribute 
named "ssrc".  The BNF-syntax in the RFC defines that 
the value of the ssrc attribute should be exactly 8 
hexadecimal digits.  But this is never spelled out in 
English in the RFC.  This makes it easy to overlook 
that the ssrc should be expressed in hexadecimal.

Therefore, it would be helpful if a sentence was 
added to the document to clarify this.  The sentence 
should simply explain what the BNF-syntax already 
describes, namely that the value of the ssrc 
attribute should be represented as 8 hexadecimal 
characters.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-09-18 17:22

Message:
Logged In: YES 
user_id=302620

Clarified in specification. 

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

Comment By: Rob Lanphier (robla)
Date: 2001-11-17 03:26

Message:
Logged In: YES 
user_id=3796

I've added the following text in the "Transport" header section (note: ssrc is not a valid parameter in 
Rtp-Info)

"It identifies the synchronization source to be associated with the media stream, and is expressed as an 
eight digit hexidecimal value."

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

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

--__--__--

Message: 4
To: [email-masked]
From: [email-masked]
Date: Wed, 18 Sep 2002 08:24:06 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477404 ] Errors in table in chapter 12

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

Category: None
Group: Fix for DS - Large task
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
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: Magnus Westerlund (magwes)
Date: 2002-09-18 17:24

Message:
Logged In: YES 
user_id=302620

The table needs to formated so it fits the pages.

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-06-07 16:29

Message:
Logged In: YES 
user_id=302620

The table is update using the same structure as the new SIP
draft. This is available in CVS. There are still some
uncertainties in the table. So please review the table and
give comments.

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-02-06 14:20

Message:
Logged In: YES 
user_id=302620

The table is also missing the location header. 

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-28 23: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-23 04: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 18: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: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477404&group_id=23194

End of Rtspspec-bugs Digest

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