Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #21 - 9 msgs

From: [email-masked]
Date: Fri, 08 Feb 2002 12:52:42 -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-477404 ] Errors in table in chapter 12 ([email-masked])
   2. [ rtspspec-Bugs-513737 ] Unclarities when doing resetup ([email-masked])
   3. [ rtspspec-Bugs-513753 ] RTSP extensions and IANA ([email-masked])
   4. [ rtspspec-Bugs-513758 ] Proxy-Require clarification ([email-masked])
   5. [ rtspspec-Bugs-513787 ] Allow capability negotiations ([email-masked])
   6. [ rtspspec-Bugs-513875 ] Play when in state ready after playing ([email-masked])
   7. [ rtspspec-Bugs-513880 ] How to use Range when Scale is negative ([email-masked])
   8. [ rtspspec-Bugs-513888 ] RTSP and NAT ([email-masked])
   9. [ rtspspec-Bugs-513891 ] Clarify use of Range in REDIRECT method ([email-masked])

--__--__--

Message: 1
To: [email-masked]
From: [email-masked]
Date: Wed, 06 Feb 2002 05:20:08 -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 - Large task
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: Magnus Westerlund (magwes)
Date: 2002-02-06 05: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 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: 2
To: [email-masked]
From: [email-masked]
Date: Wed, 06 Feb 2002 05:26:26 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513737 ] Unclarities when doing resetup

Bugs item #513737, was opened at 2002-02-06 05:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513737&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: 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. 

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

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

--__--__--

Message: 3
To: [email-masked]
From: [email-masked]
Date: Wed, 06 Feb 2002 06:05:32 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513753 ] RTSP extensions and IANA

Bugs item #513753, was opened at 2002-02-06 06:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513753&group_id=23194

Category: None
Group: Fix for Draft Standard
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTSP extensions and IANA

Initial Comment:
Today the RFC 2326 talks about extensions to RTSP and also has a number of headers that uses 
parameters. In the next version the following clarifications should be done:
- Setup a IANA register for RTSP parameters.
- Rules how to register different types of parameters.
- What type of documents that are needed for extending RTSP. IANA registering of parameters.  
IETF RFC for new headers(?), methods and future protocol versions.

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

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

--__--__--

Message: 4
To: [email-masked]
From: [email-masked]
Date: Wed, 06 Feb 2002 06:16:49 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513758 ] Proxy-Require clarification

Bugs item #513758, was opened at 2002-02-06 06:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513758&group_id=23194

Category: General
Group: Fix for DS - Typo/Thinko
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
Summary: Proxy-Require clarification

Initial Comment:
Today the proxy-require method says that the server should treat the proxy-require header 
identically as require. I don't understand how that mechanism work for paramters/functionallity that 
only the proxies should answer to. To avoid a negative acknowledgment the server must be aware 
of these parameters to not place them in the Unsupported header. I can't see that any proxy can 
modify the response as it will not know if the response comes from a proxy or a server. 

Can someone please clarify this?  

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

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

--__--__--

Message: 5
To: [email-masked]
From: [email-masked]
Date: Wed, 06 Feb 2002 07:33:19 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513787 ] Allow capability negotiations

Bugs item #513787, was opened at 2002-02-06 07:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513787&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: 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.

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

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

--__--__--

Message: 6
To: [email-masked]
From: [email-masked]
Date: Wed, 06 Feb 2002 10:43:33 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513875 ] Play when in state ready after playing

Bugs item #513875, was opened at 2002-02-06 10:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513875&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 when in state ready after playing

Initial Comment:
A client has been playing for a while and reaches the end of either media or range. At that time the 
state machine goes to state ready. When in state ready a play without range is issued. The 
question is what happends at this point:

1. The play starts from the begining of the media. 

2. If at end of media directly revert to ready, or if a play with range was the previous play 
continue at the end of that range. 

Both interpretations has been implemented. So please give your opinion on this, especially if you 
have arguments supporting one or the other, like usage cases.

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

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

--__--__--

Message: 7
To: [email-masked]
From: [email-masked]
Date: Wed, 06 Feb 2002 10:48:49 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513880 ] How to use Range when Scale is negative

Bugs item #513880, was opened at 2002-02-06 10:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513880&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders Klemets (klemets)
Assigned to: Nobody/Anonymous (nobody)
Summary: How to use Range when Scale is negative

Initial Comment:
I think the spec could use an example that shows how 
to use the Range header when rewinding (Scale header 
is set to a negative value.)  Or, instead of an 
example, some explanatory text could be added.

The issue that I find a little bit confusing is how 
the server should specify the end of the range. The 
end of the range would be numerically smaller than the 
start of the range.

I think the following illustrates a valid exchange:

C->S:
PLAY rtsp://server/a RTSP/1.0
Scale: -1
Range: npt=45-

S->C:
RTSP/1.0 200 OK
Scale: -1
Range: npt=45-0

This is the type of example that I think would be nice 
to have in the spec.

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

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

--__--__--

Message: 8
To: [email-masked]
From: [email-masked]
Date: Wed, 06 Feb 2002 10:53:38 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513888 ] RTSP and NAT

Bugs item #513888, was opened at 2002-02-06 10:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513888&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: RTSP and NAT

Initial Comment:
RTSP today is not that NAT friendly. Can something be done to fix that problem or shouldn't at 
least a note about it be written in the new spec?

If you don't have a ALG can this problem be fixed?

Known NAT issues with RTSP is and possible solutions based on NAT and SIP work:
1. Receiver ports are specifed in transport header. Needs to either be translated by ALG or client 
must find out the ports that will be used on the public side of the NAT. Mechanism for this has 
been proposed for SIP.
2. Transport header does not support explicit specification of RTCP ports. This seem to be required 
if any NAT port discovery will be possible to use. 
3. Keep alive traffic needs to be sent over NAT translated ports when in pause to prevent binding 
timeout. Not an issue for RTCP port but also RTP ports needs to receive traffic. 

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

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

--__--__--

Message: 9
To: [email-masked]
From: [email-masked]
Date: Wed, 06 Feb 2002 10:57:01 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513891 ] Clarify use of Range in REDIRECT method

Bugs item #513891, was opened at 2002-02-06 10:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513891&group_id=23194

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders Klemets (klemets)
Assigned to: Nobody/Anonymous (nobody)
Summary: Clarify use of Range in REDIRECT method

Initial Comment:
Section 10.10 says that the REDIRECT command can 
specify the Range header, to specify when the 
redirection should take place.  The example shows a 
Range header that specificies an absolute time (UTC 
time.)  Is it also possible to specify an NPT time for 
the REDIRECT command?

How should a client interpret the end of the range 
when the Range header appears in the REDIRECT command?

One way to interpret the end range time is to say that 
the client should connect back to the original server 
after that time.

So, for example, if ServerA sends this command:

REDIRECT rtsp://ServerB/foo RTSP/1.0
Range: npt=45-60

It could mean that the client should keep streaming 
from ServerA for time being, but when it reaches time 
NPT=45 in the presentation, then it should connect to 
ServerB and keep streaming from there for 15 seconds.  
After the time of the presentation reaches NPT=60, 
then the client will connect back to ServerA and 
continue streaming from there.

Somehow, I feel that this might not be exactly what 
the authors of the spec had in mind.
The spec needs to be clarified so that there is no 
ambiguity about how to interpret the Range header in 
this case. 

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

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

End of Rtspspec-bugs Digest

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