Subject: [MMUSIC] Summary of Wednesday's RTSP discussion

From: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Jul 2003 19:59:23 +0200

Hi,

This is a summary of the discussion during wednesday's RTSP dinner 
(2003-07-16, 17.30 - 19.30).

Participants: Magnus Westerlund, Anders Klemets, David Singer, Geetha S, 
Aravind N, Henning Schulzrinne, Thomas Zeng, Philippe Gentric, Patrik ?, 
Joerg Ott, Colin Perkins, Tom Marshall + 2 (sorry I can't remember your 
names).

Issue: Missing session level control URI in SDP. IF the session control 
URI is missing, should we allow the client to try to to aggregate these? 
If aggregated which session control URI must be used.

Discussion: This needs to be resolved. Tom Marshall did not thought that 
we should prevent the use case to aggregate unless necessary for 
interoperability. One possible resolution is to say that any media 
description missing session level control URI must be setup with 
individual RTSP session for each media stream and any synchronization 
between media be done on the receiver side. A practical resolution 
resolution could be: A client SHOULD follow the above statement but MAY 
try to aggregate. The server MAY allow this aggregation but MAY also 
refuse it using 4xx (Only non aggregated operation allowed).

Resolution?: Session declarations lacking a session level control URL, 
MUST be used in non-aggregated control.
Further discussion needed?

Issue: Need to clarify that how a=range can be interpreted to indicate 
Live signalling.

Discussion: The basic idea was that any a=range time format that are 
open ended, e.g. npt=0- or npt=now-, should be interpreted as a live 
media. However Live media is not well defined and may not be sharing the 
same properties for all use cases. For example a proxy could actually 
work as one of these TiVo boxes and record media during PAUSED live 
streams. The media stream would be unbound but not share the properties 
for a live only stream as it will be seekable in the already played 
parts. Need for a attribute specifying stream properties seem useful. 
Possible attributes are: Non-seekable, seekable backwards in time, muted.

Resolution: A open ended range format shall be interpreted as an 
infinite or unbound session. Further properties needs to define a 
separate (common) attribute to declare these things.

Issue:  Possible methods for signalling end of stream/media (not 
session) in RTP.

Discussion: Need to signal that a stream/media has ended exist mostly in 
unbound sessions. Proposal brought up to indicate this is RTCP BYE when 
the sender stops sending and has waited some time it can remove the SSRC 
of that source and send the BYE to indicate this. Another proposal was 
to send this information in RTSP methods. One could use sever to client 
TEARDOWN to indicate this session really are over, nothing more can be 
done. PAUSE can be sent when the media has been served but the client 
may rewind do other operations. The TEARDOWN idea was not liked as 
certain applications require session data to be sent from client to 
server using SET_PARAMETER. A new method should be evaluated. There 
might also exist significant synchronization problems in this.

Resolution: Propose a RTSP extension with a new method. Thomas Zeng to 
write strawman proposal for evaluation to mailing list.

Issue: Should REDIRECT automatically close session.

Discussion: This does not concern 3rr responses. As a connection related 
REDIRECT will terminate the session on the server side it is reasonable 
the same thing happens for REDIRECT request directed at the session. The 
exception to this is timed REDIRECTS that will continue exist until the 
specified time. The client should do TEARDOWN prior to this point to 
move the session to the alternative session.

Resolution: Clarify that session will be terminated by a successful 
REDIRECT, independently of its connection or session.

Issue: How to handle implicit redirection through session description 
protocol.

Discussion: Seems to be desired functionality to have an optimized way 
for saving a RTT when you perform load balance. There where also the 
issue that if a server would give a content-base or other base URL. A 
client should not reconnect unless explicitly redirected. This may 
result in different behaviour depending if the client are behind a proxy 
or not. First it was proposed that a new 200 code can be used to 
indicate that you get the SDP but are redirected. However this seem to 
have backwards problem. To optimize this in a efficient way you can use 
a new 350 code to indicate redirection but the client does receive a 
SDP. This way a old client will do the redirect as it interprets is as 
3xx code, while a new client can avoid wasting a extra describe. There 
are also a need to clarify that a server should not change the host 
address of the control in regards to the describe URI.

Resolution: Create a 350 code for this plus clarify the SHOULD NOT 
change the host address. Seems reasonable to put into the core 
specification.

Issue:  Request to Response time-out. The time a request takes until any 
response is received is not bound. Look at SIP solution?

Discussion: The time for a request to be processed is not defined. IF a 
server is taking long time to process a request it could send a 1xx 
response to indicate what it is doing. There may be soon need for this, 
especially if one uses STUN to validate connectivity. Concerns to 
backwards compatibility that a client will not expect a 1xx response 
even if this has been defined in RFC 2326. A couple to 10 seconds seem 
to be a reasonable time for a time-out. Does not seem appropriate to use 
without a feature tag. However a clarification on the issue is probably 
not a bad thing. There where also some concerns about the CSeq.

Resolution: Not resolved, Aravind to write to the list.

Issue: How to detect the updated spec? Version number change 1.1 or 2.0, 
or only use require and tag when necessary.

Discussion: Should be further discussed with through analysis of the so 
far made changes and see if they are backwards compatible. The initial 
goal has been to not be other than backwards compatible. A version 
number of 2.0 does completely change the picture for RTSP.

Resolution: Try to write up the change list properly with backwards 
analysis.

End of issues.

Reporting

Magnus Westerlund

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