Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #54 - 13 msgs

From: [email-masked]
Date: Wed, 30 Oct 2002 10:15:05 -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-513753 ] RTSP extensions and IANA ([email-masked])
   2. [ rtspspec-Bugs-513758 ] Proxy-Require clarification ([email-masked])
   3. [ rtspspec-Bugs-631148 ] Better Info on usage of Proxies ([email-masked])
   4. [ rtspspec-Bugs-513875 ] Play when in state ready after playing ([email-masked])
   5. [ rtspspec-Bugs-513880 ] How to use Range when Scale is negative ([email-masked])
   6. [ rtspspec-Bugs-513888 ] RTSP and NAT ([email-masked])
   7. [ rtspspec-Bugs-518997 ] Mixing aggregate and non-aggregate ([email-masked])
   8. [ rtspspec-Bugs-522602 ] Should Allow S->C  "Teardown" ([email-masked])
   9. [ rtspspec-Bugs-526545 ] Multiple range specifiers ([email-masked])
  10. [ rtspspec-Bugs-533691 ] Clarify Range Where t0 <= t1 ([email-masked])
  11. [ rtspspec-Bugs-536713 ] ControlURL parsing order must be changed ([email-masked])
  12. [ rtspspec-Bugs-538997 ] Need to flesh out 1.5 (Extending RTSP) ([email-masked])
  13. [ rtspspec-Bugs-556061 ] When can REDIRECT be received? ([email-masked])

--__--__--

Message: 1
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 09:17:16 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513753 ] RTSP extensions and IANA

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

Category: None
>Group: Fixed in CVS/Need WG Approval
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.

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

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

Message:
Logged In: YES 
user_id=302620

The IANA section has been exteneded to include what is
currently all found values that need regestries. The rules
and there levels needs further input. 

All x- things has been removed due to there evilness.  

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-05-27 16:52

Message:
Logged In: YES 
user_id=302620

Most of the issues describe in this bug are now adressed in
the new CVS repository file:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/iana.tex

Some further work regarding parameters are also required.

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

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

--__--__--

Message: 2
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 09:20:35 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513758 ] Proxy-Require clarification

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

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 18:20

Message:
Logged In: YES 
user_id=302620

The text on proxy-require has been clarified to be easier to
interpret. There was no error in the specification. 

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-07-07 23:56

Message:
Logged In: NO 

gfjhn

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

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

--__--__--

Message: 3
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 09:23:05 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-631148 ] Better Info on usage of Proxies

Bugs item #631148, was opened at 2002-10-30 18:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=631148&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: Better Info on usage of Proxies

Initial Comment:
The information on how RTSP works when there are
proxies needs to be fleshed out. Suggest that both HTTP
and SIP are studied. 

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

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

--__--__--

Message: 4
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 09:28:27 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513875 ] Play when in state ready after playing

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

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 18:28

Message:
Logged In: YES 
user_id=302620

This has been discussed and the propsed change is:
A PLAY request must contain a range header that rewinds to
the beginning. 
A PAUSE will be required to make the state machine go to
ready state before issuing the rewinding PLAY.

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

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

--__--__--

Message: 5
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 09:29:23 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513880 ] How to use Range when Scale is negative

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

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 18:29

Message:
Logged In: YES 
user_id=302620

This needs to be discussed.

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

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

--__--__--

Message: 6
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 09:44:02 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-513888 ] RTSP and NAT

Bugs item #513888, was opened at 2002-02-06 19:53
You can respond by visiting: 
https://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: Nobody/Anonymous (nobody)
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. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 18:44

Message:
Logged In: YES 
user_id=302620

A chapter has been created but needs more text. Please sign
up for writing it. 

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

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

--__--__--

Message: 7
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 09:52:08 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-518997 ] Mixing aggregate and non-aggregate

Bugs item #518997, was opened at 2002-02-18 09:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=518997&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: Magnus Westerlund (magwes)
Summary: Mixing aggregate and non-aggregate

Initial Comment:
This is a tracking issue for the email here:
http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00115.html

 * Point a) RESOLVED
 * First point b) RESOLVED
 * Second point b) MUTE and UNMUTE
   * RESOLVED: separate draft
   * ACTION ITEM: Call for authors on MUTE proposed. AN
is tentatively signed up
 * Point C) (same as http://rtsp.org/bug477400)
   * RESOLVED: PING writeup will be done as part of
next RTSP draft...continue discussion on mailing list
   * RESOLVED: deprecate PLAY w/o range as ping method

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 18:52

Message:
Logged In: YES 
user_id=302620

The MUTE proposal has been written but is currenlty out of
circulation. However these issues has been resolved. The
changes necessary has been written up. If accepted this
issue can be closed. 

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

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

--__--__--

Message: 8
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 09:52:53 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-522602 ] Should Allow S->C  "Teardown"

Bugs item #522602, was opened at 2002-02-25 20:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=522602&group_id=23194

Category: General
>Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas M Zeng (zengtm)
Assigned to: Rob Lanphier (robla)
>Summary: Should Allow S->C  "Teardown" 

Initial Comment:
Table 2 in section 10 of RFC2326 seem to disallow S->C 
Teardown. And section 10.7 is vague on whether S->C 
teardown is OK.

This should be relaxed, because Server might have to 
use TEARDOWN to tell client a live session is over.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 18:52

Message:
Logged In: YES 
user_id=302620

To be discussed

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

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

--__--__--

Message: 9
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 09:58:16 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-526545 ] Multiple range specifiers

Bugs item #526545, was opened at 2002-03-06 19:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=526545&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: Multiple range specifiers

Initial Comment:
In the RFC the BNF allows for multiple range
specifiers. This was intended to be used to specify
diffrent formats of the same range. But the text and
BNF does not express this. Therefore it has been
interpreted by me (Magnus Westerlund) to be a
possibility to specify multiple different ranges. 

The main question is if this functionallity is useful
at all? It is similar to queued plays but have some
differencies; 1. Does not allow addition after the
first play has been issued; 2. Have fewer issues on how
to be handled, like, no RTP-Info, state transitions
problems.

It seems fairly obvious that it should be an optional
behavior but should it be part of the core spec or an
extension? What mechanism should be used for discovery
of support? 

If implementing this feature the behavior related to
pause need to be resolved. To be able to resume a play
request containing multiple ranges the server must
singal unambigous in what range and point it actually
did pause. A proposal discussed during the telecon 6
march 2002 was to do the following:
 
1. C->S PLAY range=10-20,30-60,15-45.
2. S->C 200 OK
3. wait approx 11 sec.
4. C->S PAUSE
5. S->C 200 OK, range=31.2-60,15-45
6. User wants to resume.
7. C->S PLAY range=-60,15-45
8. S->C 200 ok

By removing the inital range in point 5 the client
ensures that the server continues where it halted. And
by specifying all the ranges remaining it will play
exactly the intended. 

If point 7 would be done without range the playback
would be from 31.2 to end of media.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 18:58

Message:
Logged In: YES 
user_id=302620

This has been written up and included in the CVS. 

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

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

--__--__--

Message: 10
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 10:00:08 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-533691 ] Clarify Range Where t0 <= t1

Bugs item #533691, was opened at 2002-03-22 18:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=533691&group_id=23194

Category: None
>Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas M Zeng (zengtm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Clarify Range Where t0 <= t1

Initial Comment:
If the server receives a PLAY range from t0-t1, where
t0 < t1, should it reject the PLAY, or should the 
server play backwards as if the timescale is -1?

If t0 = t1, should the server send any media data 
after responding 200 OK?  
We've seen different servers behave differently in 
this scenario.

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

Comment By: Thomas M Zeng (zengtm)
Date: 2002-03-22 18:41

Message:
Logged In: YES 
user_id=20397

I just came across 513880, which is closely related.
That is to say, if timescale is positive, should the play 
range to be required to have t1 > t0?

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

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

--__--__--

Message: 11
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 10:04:21 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-536713 ] ControlURL parsing order must be changed

Bugs item #536713, was opened at 2002-03-29 13:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=536713&group_id=23194

Category: None
>Group: Fixed in CVS/Need WG Approval
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Jaehwan, Kim (kjh1905m)
>Assigned to: Magnus Westerlund (magwes)
Summary: ControlURL parsing order must be changed

Initial Comment:

Last winter, magwes suggested using new RTSP spec, RFC 
2616. So we need to change parsing order of Control 
URL which was defined in C.1.1 of draft-ietf-mmusic-
rfc2326bis-00.txt.

------
C.1.1 Control URL

        1.   the RTSP  Content-Base field;

        2.   the RTSP  Content-Location field;

        3.   the RTSP request URL.
------

It is reasonable to remove Content-Base. Because in 
the RFC 2616...

-------
19.6.3 Changes from RFC 2068
skip...

   Content-Base was deleted from the specification: it 
was not
   implemented widely, and there is no simple, safe 
way to introduce it
   without a robust extension mechanism. In addition, 
it is used in a
   similar, but not identical fashion in MHTML [45].

-------
(even I think Content-Base was implemented widely at 
lease in the streaming world )

The usage of Content-Base is identical with Content-
Location. For this reason,we had better use Content-
Location. 

Jaehwan, Kim([email-masked])
Serome Technology, inc.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 19:04

Message:
Logged In: YES 
user_id=302620

Actually it seems that Content-base actually is useful for
giving session descriptions there base-URL. Therefore I
believe it should be keept. The Content-base has been moved
to the RTSP spec. 

Content-Location has a slightly different meaning whit some
implications. 

Therefore there is no need to change the parsing order. 

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

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

--__--__--

Message: 12
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 10:08:01 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-538997 ] Need to flesh out 1.5 (Extending RTSP)

Bugs item #538997, was opened at 2002-04-04 01:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=538997&group_id=23194

Category: None
>Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Lanphier (robla)
Assigned to: Nobody/Anonymous (nobody)
Summary: Need to flesh out 1.5 (Extending RTSP)

Initial Comment:
We need to have a larger "Extending RTSP" section in
the draft:

A first (very rough) cut at this was posted here:
http://www.ietf.org/mail-archive/working-groups/mmusic/current/msg00377.html

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 19:08

Message:
Logged In: YES 
user_id=302620

One part of this is the IANA extensions that has been
written up, see bug 513753. However more rules might be
needed, for example regarding proxies. Also informational
chapters on what to think when doing extension would be good. 

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

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

--__--__--

Message: 13
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 10:14:21 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-556061 ] When can REDIRECT be received?

Bugs item #556061, was opened at 2002-05-14 20:33
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: Rob Lanphier (robla)
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: 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

End of Rtspspec-bugs Digest

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