Subject: [MMUSIC] Comments on draft-ietf-mmusic-rfc2326bis-02.txt

From: Thomas Zeng <[email-masked]>
Date: Thu, 12 Dec 2002 17:26:19 -0800

PacketVideo has the following collective comments:

1.  Section 10, method Definitions, in the table, it indicates in the Client
Req column that OPTIONS is Required for Send - this doesn't make sense to me
- what does it mean that the client is required to send OPTIONS?  When?

2.  How can they not bump the Version number (say from 1.0 to 1.1) when they
are allowing non-interoperable changes from 2326?  For example, from section
10.5 - PLAY:

"   After playing the desired range, the presentation is NOT automati-    |
   cally paused, media deliver simple stops. A PAUSE request MUST be     |
   issued before another PLAY request can issued. Note: This is one      |
   change resulting in a non-operability with RFC 2326 implementations.  |
   A client not issuing a PAUSE request before a new PLAY will be stuck  |
   in PLAYING state. A client desiring to play the media from the begin- |
   ning MUST send a PLAY request with a Range header pointing at the     |
   beginning, e.g. npt=0-.     "

What's the point of being "stuck" in playing state?  If *EVERY* client has
issue the PAUSE request 
before being able to do something useful, why not just assume they all did
and stick with the 
current behavior of returning to the READY state?  What is the behavior if
the client issues a PLAY
before a PAUSE?  

3. One of the big gaps in the previous spec was how to use Basic and Digest
Authentication in the context of RTSP.  This draft does not give any more
clarification.  Do you send the authentication headers in all requests?
Only until a valid session ID has been established?  Just the DESCRIBE?  In
all SETUPs?  Details like these need to be worked out and an example
wouldn't hurt either.

4. In section 3.3, "Session identifiers are opaque strings of arbitrary
length. Linear white space must be URL-escaped."  Why allow spaces?  And URL
escaping results in the '%' characters.  The BNF they use to detail the
session ID does NOT allow for spaces or the '%' character:
   
   session-id  =  8*( ALPHA / DIGIT / safe )

   ALPHA           =  UPALPHA / LOALPHA
   UPALPHA         =  <any US-ASCII uppercase letter "A".."Z">
   LOALPHA         =  <any US-ASCII lowercase letter "a".."z">
   DIGIT           =  <any US-ASCII digit "0".."9">
   safe            =  "$" / "-" / "_" / "." / "+"

5. Can the open-ended start time be used for live presentations?  For
example, can "-30" mean play from now til 30 seconds form now?  How about
"now-30" or "now-now+30" to indicate streaming from the current point in the
live stream, but only streaming for 30 seconds.

6. Need to resolve the problem of supporting the REDIRECT request and
non-persistent connections.  If you are using non-persistent connections,
there is no way for a server to send a REDIRECT request to the client.  

7. In the section on RTP interleaved over the RTSP channel, there was no
mention of the client sending RTCP RR back to the server.  Are these still
present?  They did specify the sender reports from the server to client, but
that's it.

8.   The description of the redirection responses needs work.  It's not
clear how they see the use of load balancing, etc. 

9. Table 3, page 51:  Why are DESCRIBE, ANNOUNCE, and PING supported for a
request on the media URL?  I understand them to work on the presentation
URL, but I don't think that they are appropriate to work on the media-level
control URLs.

10. Section 12.18, why MUST the server send the "Date" header?  And what is
the determining factor to say a sending host has a clock?  How could a
server send RTP data without a clock? 

11. Section 12.19, page 63, Why can't they define a separate string value to
indicate that the description "Never Expires" instead of using a date/time
that is one year in the future?

12. Section 12.29, must a server understand the "time" parameter in the
range header in a request?  And what error should it respond if it doesn't
support the time parameter?  There is no way to inform the client that it
does/doesn't support this parameter.

13. Section 12.38, the first line of the "Supported" example looks garbled.

14. The introduction of the "client_rtcp_port" and "server_rtcp_port" REALLY
breaks backwards compatibility.  The RTSP version number MUST be bumped!
And there is a typo in that section/example where "client_rtcp_port" is used
twice - one in place of the server port.

15. In section 9.3 it states that the server MUST NOT close the connection 
directly after responding to the TEARDOWN request for the whole session.
Are they trying to state
that the server should wait to ensure that the response arrives at the
client?  I don't understand
how this is case is different than the handling of any other RTSP response.

16. Section 9.3 also states "A persistent connection MAY be used for all
transactions between the server and client,       including messages to
multiple RTSP sessions."  It would be a good idea to point out the server
MAY impose limits on the number of simulataneous sessions a client is
allowed to create/control.

17. In table 2 of section 10, the TEARDOWN message should also be required
to be handled in the 
Server->Client direction.  There are cases where the server needs to drop
the client 
(e.g., load shedding) and it is better if it can inform the client that this

is happening.  A few IETFs ago someone was proposing "END_OF_STREAM" as a
new RTSP request from Server to client. But TEARDOWN from server to client
could be more appropriate.

18. Section 12.10:  The section on the server closing the connection should
be softened:

12.10 Connection

   See [H14.10]. The use of the connection option "close" in RTSP mes-   |
   sages SHOULD be limited to error messages when the server is unable   |
   to recover and therefore see it necessary to close the connection.    |
   The reason is that the client shall have the choice of continue using |
   a connection indefinitely as long as it sends valid messages.

The standard shouldn't mandate server policies on the use of resources.  The
server should have the option
of closing connections (perhaps without dropping the RTSP session) if
demanded by resource constraints or 
usage policies.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Dec 2002 16:29:39 +0100

Hi Thomas,

I will try to respond to your comments. I hope that people manage to 
read this very long mail. If responding please trim away all unnecessary 
text.

>- what does it mean that the client is required to send OPTIONS?  When?

The requirements are related to implementation not usage. In fact I 
would believe that sending of OPTIONS on the client side may only be 
Recommended.
=> So this section should be fixed to clarify the that the requirements 
are regarding implementation. It should also be consider to change 
OPTIONS, Sd to recommended.

>current behavior of returning to the READY state?  What is the behavior if
The reason for this change is that it removes all automatic state 
changes that does not result in session deletion. Having automatic state 
changes is a big problem for the state consistency between client and 
server. One existing problem with the old state machine is that a client 
could send a PLAY request and not know what the result of it would be. 
The request could either be queued or played out directly. This may be 
acceptable if one would only be interested in basic on-demand play 
functionality. However to have this protocol be robust to extensions 
this change is needed. One needs to know what behavior one shall expect 
when sending a request.

Regarding the interoperability issue. This is currently the most evident 
issue. However I don't regards it as extremely problematic. A client has 
at least managed to play the stream once. There are other issues that 
exist when we know that different implementations are not compatible. 
One example is the behavior at the end of the stream. Some server sets 
the current play out point to 0.0 when reaching the end of a media clip 
will others do not. A client will not be able to be interoperable with 
both servers. In this case however a simple fix exist and that is to 
always include a range header. However a client not knowing this will 
not be interoperable.

So far this interoperability problem has been regarded as minor compared 
to the need to fix the underlying problem. A new version number would 
not fix the underlying problem which is that RTSP 1.0 has major 
interoperability problems due to specification shortcomings. My working 
hypothesis is that we will try to fix RTSP 1.0 so that it works. Any 
change resulting in interoperability problems need to be documented as I 
have done in this case. (We should perhaps gather them in a special 
chapter). Then if the end we can't fix the protocol without totally 
breaking the interoperability then we will have to accept a new version 
number. We will not fix this protocol without hurting some of the 
deployed implementations at least to some extent. My goal is to let 
things be minor.

In the updated version the correct reponse to a PLAY request in playing 
state is: "455 Method Not Valid in This State".

>all SETUPs?  Details like these need to be worked out and an example

Yes, I agree that we should have security feature like authentication in 
the core spec or an extension spec of RTSP. The big problem is that this 
is basically at the same maturity level as specifying some new 
functionality. So we need someone to start writing on this. If you are 
interested in this you are very welcome to volunteer to write this.

>   safe            =  "$" / "-" / "_" / "." / "+"

A simple type I would say, the sentence is out of date and not in line 
with the BNF definition. I resolve this by checking in a version with 
out the sentence "Linear white space must be URL-escaped." I guess that 
resolves this issue.

>live stream, but only streaming for 30 seconds.
Yes, they can be. The BNF allows for example the following ranges 
clock=-20021216T164500Z, or npt=now-00:30:00. However the now-now+30 is 
not valid. In the case of live sessions the most reasonable seems to be 
to use the UTC format (clock) to specify a wall clock time when the 
session ends. In that case a simple start time open ended is sufficient.

>there is no way for a server to send a REDIRECT request to the client.  

I think this is as resolved as it ever will be. The client is strongly 
recommended to have persistent connections. If not keeping the 
connection open and the server would like to do redirect/announce etc. 
the client, the server will simply let the request fail. In this case 
this failure will result in that the sever ends the session when it has 
to. This is the incentive for a client to keep a connection alive. Of 
course this must be clearly documented.

>present?  They did specify the sender reports from the server to client, but

This is a new bug, would you please register it at source forge: 
http://rtspspec.sourceforge.net.
Please log in before registering a bug.

However my opinion is that this channel should allow for sending RTCP 
traffic also to the server. It seems simple to assume symmetry of the 
identifiers. Please give your view of how this is simplest and best solved.

>clear how they see the use of load balancing, etc. 

Please provide more details of what you think is missing. In most case I 
assume that there is no need for the client to know the reason behind a 
redirect as long as the correct behavior is indicated.

>URL, but I don't think that they are appropriate to work on the media-level

In cases you don't do media aggregation the use of ANNOUNCE and PING are 
motivated. Of course, you can in that case see it as the presentation 
URL and media-url is the same. The use of DESCRIBE I can't motivate 
other way that the difference between a presentation and a media URL are 
not always clear. One example of usage could be a non aggregated session 
that becomes redirected. In that case the media should not be directed 
to the whole presentation rather the media. If the client checks the 
media description to verify that it is in fact the same media and not a 
another configuration it is motivated.

>server send RTP data without a clock? 

The "Date" header MUST be sent with any request or response containing a 
body. Which means that for a server only the DESCRIBE response really 
MUST contain a Date header. However it good to include it also in other 
request for logging, debugging purposes. For the messages with body it 
is for proxy reasons so that one can judge how old the content in the 
proxy is. In the case of Date it is evident that the requirement is to 
have a wall time clock, i.e. capable of producing time in GMT/UTC.

>that is one year in the future?

There seem to be a very good reason for this. Can you really guarantee 
that any thing will work and accessible for all time in the future. By 
specifying the expire time one year into the future you give it a very 
long life time but still bounded.

>does/doesn't support this parameter.

Looking at the specification, it seems that it is assumed to be a part 
of the core functionality of the protocol that is required to be supported.

>13. Section 12.38, the first line of the "Supported" example looks garbled.

Yes, It certainly is

>twice - one in place of the server port.
No, it does not. Not with the described mechanism of resolving this. By 
requiring a client to check if the sever supports the new parameters 
interoperability can be ensured. So the use of this parameter requires 
that the client to include the supported header in a request prior to 
the SETUP to determine if feature tag "play.basic" is supported by the 
server. If support is signaled then the client MAY include the 
client_rtcp_port. If a server receives a SETUP request with 
client_rtcp_port parameter it shall include its own RTCP port in 
server_rtcp_port.

I find one typo, the item name was client in the description. What was 
the other one?

One big problem with the transport header is that it doesn't support 
extensions. This I think must be corrected. If extensions are required 
to be understood feature tags in the Require header should be used.

>how this is case is different than the handling of any other RTSP response.

TEARDOWN is not different from other request. It is only a clarification 
to some implementations that do close the TCP connection as a response 
to the TEARDOWN request. It should be the client that initiate closing 
of the TCP connection. However the server may close the TCP connection 
after a time-out interval without traffic.

>allowed to create/control.

I think I understand the motivation behind your request. However I don't 
think such a restriction is possible in the current look of the RTSP 
standard. The scenario when such a restriction is hard to enforce is: A 
large number of clients are sitting behind the same proxy. The proxy 
multiplex all the clients it handles into a single TCP connection. How 
does the server distinguish that it is talking with many different 
clients and not a single one behind the proxy?

>could be more appropriate.

Okay, TEARDOWN in S->C may be motivated when a server needs to get rid 
of all its clients and has no alternative server to REDIRECT to. However 
to make this useful compared to just deleting the sessions and refusing 
any connections a channel for extra information about the reason is 
needed. This could be included in the body but also SIPs warning may be 
appropriate.

However the END_OF_STREAM had other purposes as it was to indicate that 
all media of the current request had been sent.

>demanded by resource constraints or 

This text is added to clarify that the usage of close that is evident in 
some implementations today are not correct. In my view a TCP connection 
should not be closed from server end unless its inactive for at least 
one RTSP time-out period. It may also be kept open for longer as the 
RTSP session is kept alive with RTCP messages. However I can agree that 
another formulation of this may be more appropriate. I see that there 
exist problems like DOS attacks by setting up many TCP connections, etc. 
that would require the server to start closing connections. Please 
propose how you would like it to be written.

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]