Subject: [MMUSIC] RTSP: draft-ietf-mmusic-rfc2326bis-04

From: Geetha Srikantan <[email-masked]>
Date: Thu, 21 Aug 2003 11:37:26 -0700 (PDT)

I meant to send this in earlier..here it is now..

Questions and comments (some typos too):

Page 10: Transport Negotiation
Can transport parameters of an existing session be changed, mid-stream?
For instance, is it possible to change the server's RTP/RTCP ports
mid-stream? 
If so, exactly how does the transition to using the new ports happen? Do some 
mechanisms need to be specified to ensure synchronization etc after the cutover?
If not, it would be good to specify the states in which transport negotiation 
can be done.

Page 10, last paragraph section 1.5 - are 'stream identifiers' the
same as 'session identifiers'? If so, it might help to use the same
term throughout the document.

Page 14, section 2 - typo after last paragraph 'b'?

Page 15, 1st paragraph, last sentence - typo?

Page 15, 3rd paragraph, it might help to rephrase to say that FQDNs
are preferred, especially for IPv6, (maybe even 'required for IPv6 ?)
however IP addresses should also be supported (for backward
compatibility). 

Page 18, section 3.7, 2nd sentence - typo 'in' appears twice.

Page 20, section 5 - adding Expires header?
Page 27, section 7.1.2 - add Expires header?

Page 30, section 9.3, 3rd paragraph, last sentence - typo?
Page 31, section 9.3, Is play.basic a superset of *not* con.persistent?

Page 31, section 9.4, 1st paragraph, 4th sentence s/must/should/?
I.e. 'This requires that any RTSP URL pointing tat a IPv6 host should
use fully qualified domain name and not a IPv6 address.'

Page 31, section 10, 1st paragraph, 2nd sentence - typo 'too'?

Page 31-32, section 10,
Should responses to OPTIONS be cached? If so, is there an expiry on
this and any specification on how to refresh?
Are there rules about determining capability in the presence of a
proxy?
Does this section specify all that is required for each endpoint to
determine capability?

Page 32, 1st paragraph, last sentence - typo? Should it say 'Public
header tag which declares...'?

Page 32, 2nd paragraph, typos? Should it be 
'It is not necessary to use OPTIONS to discover support of a method,
it is possible to simply try it. If the receiver of the request does
not support the method it will respond with an error code indicating
that the method is either not implemented (501) or does not apply for
the resource (405). ..'

Page 32, 3rd paragraph, 3rd sentence, typo? Should it be:
'The amount of functionality  that a feature-tag represents can vary
significantly.' 

Page 32, 5th paragrapgh, typo? Should it be:
'Supported: The supported header is used..'

Page 34, 1st paragraph - typo? "SHOULD NOT" instead of "SHOULD not"?

Page 36, section 11.3, 2nd paragraph - the part that mentions that the
media shall start to play in sync.
Does a=group apply to this discussion? 
What is the scope of synchronization here - does it mean that packets
are sent on the different tracks according the the movie timeline that
is specified for all packets in the track?

Also, does 'setup.playing' apply to a specific URL or request/session
or is it a statement about the server in general?

Page 37, 3rd paragraph 'Since SETUP.." Isn't it likely that there
would be intermediary devices that would be interested in seeing the
b= line in the DESCRIBE response as well?

Page 38: liveness:
Should there be a mention of signs of liveness - no RTCP and no TCP
KeepAlive implies the session is gone?

Page 39, 4th paragraph, about the Range header. There is a mention
in section 3.5, 2nd paragraph, that 'now' should only be used for
live. This applies even in this section, right? I.e. the
recommendation to use npt=now- is for live?

Page 39, 5th paragraph - If there is no Range header in the request,
what should the response use as units for the Range header?
There was a suggestion that, if you do have the Range in npt, it can
be used, if not in the SETUP response there should be an indication of
the Range specifications that apply to the stream.

Also, it seems like the specification here is only for old
implementations, as newer implementations the Range header must be
sent in the request according to Page 41.

Page 39, last paragraph - typo? Should it be 
'After playing the desired range, the presentation is NOT
automatically paused, media delivery simply stops. A PAUSE must be
issued before another PLAY request can be issued."

Page 41, 2nd and 3rd paragraph: Here it says PLAY without range is not
ok - does this apply for stored content only? This seems to contradict
the text in the 3rd paragraph..

Page 43, 1st paragraph - is very confusing. Does this refer to the
case where the PAUSE request comes after the first occurence? Again it
seems like PLAY without a range header is ok...confusing.

Page 44, section 11.6, 1st paragraph, suggested rewording of the last
few sentences:

'However the session and any other media not torn down yet, remains,
and any valid request, e.g. PLAY or SETUP, can be issued. As an
optional feature a server MAY keep a session even after the last media
on it has been torn down by use of TEARDOWN with a media URI for the
last media. In this cases, when the server continues to maintain a
valid session, after processing a TEARDOWN request on this session, the
server MUST return the session identifier in the TEARDOWN response.'

Page 44, section 11.6, last paragraph: It would help to move these
sentences to earlier in the section - to explain the motivation for
what's discussed in the sentences above.

That's it for now,
geetha

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 Aug 2003 14:38:15 +0200

Hi Geetha,

And thanks for the review. I have fixed the typos, however there are a 
few things that may need discussion.

If you are replying to any particular section could you please remove 
everything except that topic and change the subject. Please also one 
topic per email.

> For instance, is it possible to change the server's RTP/RTCP ports

Yes, If the server implements it and allows it. As seen by the 
application mobility discussion this functionality can be used for this.

> mechanisms need to be specified to ensure synchronization etc after the cutover?

Upon the successful response to a SETUP request to change the transport 
parameters the server will start using the new parameters. The client to 
avoid losing any packets should keep the old ports/transport open for a 
couple of seconds. The client should also have opened its ports for the 
new transport prior to sending the request. So I don't believe there are 
any synchronization problem.

> If not, it would be good to specify the states in which transport negotiation 

This is currently specified in the state machine. If supported is must 
be possible in READY state, and MAY be supported in PLAY state. This can 
probably be a clarified and simplified by tightening the requirements a 
bit. The text in section 11.3 can probably be improved to be more clear 
about what is allowed in this respect.

> term throughout the document.

In some sense. The occurrence here of stream identifiers should probably 
be replaced by session ID and stream and control URLs.
> Page 14, section 2 - typo after last paragraph 'b'?

Definitely, probably a result of the document generation.

> Page 15, 1st paragraph, last sentence - typo?

Definitely a bad sentence. Is now corrected.

> however IP addresses should also be supported (for backward

I think we have a good level now. First of all the requirement to use 
FQDNs to handle IPv6 hosts only applies to RFC 2326 servers, not the 
ones in accordance with this specification. There are also reasons why 
one might use literal IP addresses. For example in destination fields, a 
FQDN name that resolve only to the targeted host may not exist. Also 
there are some performance issues if proxies needs to do DNS requests 
for all messages it is forwarding.

> Page 18, section 3.7, 2nd sentence - typo 'in' appears twice.

Fixed

> Page 27, section 7.1.2 - add Expires header?

The Expires header is a Entity header, see section 8.

> Page 30, section 9.3, 3rd paragraph, last sentence - typo?
Fixed

> Page 31, section 9.3, Is play.basic a superset of *not* con.persistent?

play.basic is not a superset of con.peristent. A RTSP entity supporting 
play.basic must handle non-persistent connections. The con.peristent is 
defined to allow any service requiring a persistent connection to use 
this in a Required header. However looking at this I would in fact 
propose that this is removed. I can't see any clear need and therefore 
it is unnecessary, and if it is need in the future it can simply be 
define in relation to the necessary user of the feature tag.

> use fully qualified domain name and not a IPv6 address.'
It is a informal must, not a normative one. This paragraph is only for 
information on how to make this work if the other party does not support 
  the updated specification. Are there any problem with this?

> Page 31, section 10, 1st paragraph, 2nd sentence - typo 'too'?
Fixed

> 
> Page 31-32, section 10,
> Should responses to OPTIONS be cached? 
Maybe, it is actually a problem of what OPTIONS is used for. As long it 
is only used for determine server capability it is not a problem. 
However if it is used to maintain session liveness, i.e. session ID 
present, no. Also depending on the URI and the possibilities to cache ma 
y vary. Needs further consideration.

If so, is there an expiry on
> this and any specification on how to refresh?
This is a tough problem. I don't think there are. The Expires header is 
an entity header, but the text in RFC 2616 seems to mean the whole 
request. SO this is something that needs consideration.

> Are there rules about determining capability in the presence of a
Yes, I would say so. Options can either be targeted at the next hop. Or 
to the server by including host name. However I think the usage of 
supported header will not reveal anything about the proxy. Also 
something that might need some more consideration.

> Does this section specify all that is required for each endpoint to
Actually this section is totally informal. The specification of the 
operations is actually dispersed around the document. See the options 
method and the headers for specification.

> header tag which declares...'?
Yes, fixed.

> that the method is either not implemented (501) or does not apply for
Yes, fixed.

> 'The amount of functionality  that a feature-tag represents can vary
Yes, fixed.
> 'Supported: The supported header is used..'
Yes, fixed.
> Page 34, 1st paragraph - typo? "SHOULD NOT" instead of "SHOULD not"?
Yes, fixed.
> media shall start to play in sync.

This is only intended to resolve the synchronization problem when doing 
SETUP in PLAY state. The newly setuped media must be playing in synch 
with already present media, otherwise this would break the aggregation 
policy we apply.
> Does a=group apply to this discussion? 
I have not considered if a=group has any impact at all. I would not 
thinks so, because such a SETUP as described in the second paragraph in 
it self requires that the server plays out the media in synch.

> is specified for all packets in the track?
The session has an internal clock that runs during play state. When a 
media is added to the session that media must also play out according to 
that clock.

0----5----10---15---20---25 Session playout time
0xxxx5xxxx10xxx15xxx20xxx25 First media stream
           10***15***20***25 Second media stream starts at 10 seconds
                             into the media.

In this example a SETUP request to add a second media stream is received 
at time 10. Then the second media will start playout from time point 10.

I hope this clarifies this. Are there need to improve the text in that 
chapter? Is the functionality (SETUP during PLAY state) needed, or could 
we throw it away. In my opinion it is not a really necessary and such a 
extension could anyway be added later. In my eyes it will anyway need 
extensions.
> or is it a statement about the server in general? 

A Feature tag is used in a context, depending on the context it can 
either relate to a session, media stream, or the complete server.

> b= line in the DESCRIBE response as well?

This is probably something the original authors should answer on. 
However in my opinion the design is made to allow an middle box to 
understand that the individual flows exist and which protocols they use. 
It is not designed to allow for conveying QoS properties for the stream. 
Anyway I don't think that b= is of much more use then to provide some 
basic limits. A media stream today is not of fixed bit-rate, it may very 
well be adapted to available resources for best effort traffic. For 
streams with QoS agreements they will have there own policy on policing, 
control and admission control that does not belong in RTSP.

> KeepAlive implies the session is gone?

How do you interpret the second last paragraph and bullet list of 
section 11.3? There are also a reference to section 13.37 that discuss 
this further.

 From the text of section 11.3:

"Signs of liveness for a RTSP session are:

      + Any RTSP request from a client which includes a Session header
        with that session's ID.

      + If RTP is used as a transport for the underlying media streams,
        an RTCP sender or receiver report from the client for any of the
        media streams in that RTSP session."

> recommendation to use npt=now- is for live?

Yes. Is it not understandable that this sentence is in relation to the 
context of the previous sentence? Have you proposal for improvements of 
the text?

> the Range specifications that apply to the stream.

Yes, this is a bit unclear. I propose it to clarify it in the following way:

For a on-demand stream, the server {\MUST} reply with the actual
range that will be played back.  This may differ from the
requested range if alignment of the requested range to valid frame
boundaries is required for the media source.  If no range is
specified in the request, the start position {\SHALL} still be
returned in the reply.  The unit of the range in the reply
{\SHOULD} be the same as that in the request. If no range header
was present in the request the server {\MAY} use any of the
supported formats, however it is {\RECOMMENDED} that a format the
client has shown support for is used. If the media part of an
aggregate has different lengths the {\PLAY} request and any
\header{Range} {\SHALL} be performed as long it is valid for the
longest media. Media will be sent whenever it is available for the
given play-out point.

> sent in the request according to Page 41.

No, it is for the updated specification. There is no requirement that a 
client includes a range header in a request. The range header MUST be 
present in responses. Please quote the section you have interpreted as 
requiring Range in PLAY requests.

> issued before another PLAY request can be issued."

Yes, type except that I would like to keep "request" in the last 
sentence after pause:

"A PAUSE request must be issued before another PLAY request can be issued."

> the text in the 3rd paragraph..

My intention with the two following paragraphs:

   "The queued play functionality described in RFC 2326 [21] is removed
    and multiple ranges can be used to achieve a similar performance. If
    a server receives a PLAY request while in the PLAY state, the server
    SHALL respond using the error code 455 (Method Not Valid In This
    State). This will signal the client that queued play are not sup-
    ported.

    The use of PLAY for keep-alive signaling, i.e. PLAY request without a
    range header, has also been depreciated.  Instead a client can use,
    PING, SET_PARAMETER or OPTIONS for keep alive. A server receiving a
    PLAY keep alive SHALL respond with the 455 error code."

Is that it is informs that while in PLAY state, a PLAY request is not 
allowed. This was in RFC 2326 used for two different purposes depending 
on if range was present or not (queued play, and keep alive). These two 
paragraphs try to explain what to do if one would receive a request that 
tries to perform such an operation. I will add a "in PLAY state" to the 
second paragraphs first sentence to be clearer.

> seems like PLAY without a range header is ok...confusing.

I guess it is not that confusing clearing out the previous confusion.

> server MUST return the session identifier in the TEARDOWN response.'
Yes, you where correct that the sentences need to be reworded. However I 
was not completely happy with your proposal either. So I propose the 
following:

The {\TEARDOWN} request stops the stream delivery for the given
URI, freeing the resources associated with it. If the URI is the
aggregated control URI for this presentation, any RTSP session
identifier associated with the session is no longer valid. The use
of "*" as URI in {\TEARDOWN} will also result in that the session
is removed independent of the number of media that was part of
it. If the URI in the request was for a media within an aggregated
session that media is removed from the aggregate. However the
session and any other media not torn down yet, remains, and any
valid request, e.g. PLAY or SETUP, can be issued. The server
{\MAY} keep the session when the last media is torn down with a
{\TEARDOWN} request specifying the media URI. The server {\SHALL}
always include in a {\TEARDOWN} response the session header, if a
valid session state exist after the processing of the request.

However I have logged a bug suggesting that we remove the Ready-NM 
state. That way we can get rid of the "*" teardowns that I feel will not 
work satisfactory through proxies.

> what's discussed in the sentences above.

I don't think this provides any motivation. However it might be 
beneficial to change the the complete section into something that is 
more readable and more clearly explains things. One can also discuss the 
need for having TEARDOWN during PLAY state. Please provide input on this 
topic.

Magnus Westerlund

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