Subject: [MMUSIC] RTSP discussion meeting

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Nov 2002 19:37:16 +0100

Hi,

Anybody at the IETF meeting interested in discussing RTSP issues are 
welcome to meet me Tuesday 19 november at 13.00. We will be on the 
hotel's garden level, at one of the tables towards the Garden terrace. 
We will continue until around 15.15.

Regards

Magnus

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Nov 2002 16:29:59 +0100

Hi,

Here is a summary of the discussion we had yesterday.

The way forward. We will aiming to trim down the specification to a 
basic core supporting playback of media. All other functionality will be 
moved out to its own extension documents. Only areas where there is 
enough interest to actually do work will be progressed. Possible 
extensions are:
- TLS for RTSP
- UDP transport
- Record functionality

We had a discussion about removing Non persistent connections. However 
in the end we concluded that non-peristent connection is needed for the 
reliability of the protocol and its extensibility to certain use cases.
Arguments for removing non-persistent connections:
- The signaling channel from the server to the client is important and 
in certain cases required for correct functionality.
- Not common use cases. The normal playback use case does not need this 
functionality.
- Adds some complexity.  (However it is not difficult to implement this)

Arguments against removing non-persistent connections:
- Reliability, it seems very bad that a RTSP session is relying on the 
presence of a TCP connection between the client and server. If a NAT 
times out a connection the session will go with it unnecessary. It would 
be better if the client can simply reconnect and keep controlling the 
session.
- Use cases with shared control needs the assumption that any request on 
any connection is sent to a session if it contains the session's ID.

Conclusion:
Keep non-persistent connection model. This will be required to implement 
in the updated spec. It will be strongly recommended that a client keeps 
the connection up to allow for server messages. 

Discussion regarding 3xx and REDIRECT.
The proposed 350 and 351 codes can basically be solved by using 302 
Temporarily moved. The reason phrase can be set to appropriate one 
depending on reason for redirect. It will be clarified that if a 3xx 
response is received when one have a session, that is equivalent to 
receiving a REDIRECT request and the session needs to be moved. When 
receiving a REDIRECT and 3xx response the client MUST send TEARDOWN on 
the indicated session at the time indicated. The server MAY remove the 
session after one time-out period from the redirect point. Need to 
further clarify that one SHOULD do a describe after a redirect as the 
session description may have changed.

We would also like to encourage that error messages can contain 
text/HTML to present further information about the error.

We should look into bringing in the Warning header from SIP to allow to 
give more error information to the requester.

RECORD and ANNOUNCE
Will be removed as we are lacking experience about this. Anybody 
interested in this should work on a separate document as an extensions. 
Announce functionality for pushing out new session descriptions can be 
resolved by using REDIRECT. This requires that we clarify that one can 
use the current session's URL in a redirect location header. This means 
that the client needs to do a DESCRIBE and not make any assumptions 
about the session description. If anybody needs ANNOUNCE they will need 
to do this as a extension. One possible way to look at ANNOUNCE would be 
a REDIRECT with keeping the RTSP session state.

Aggregate control issues
To allow the client to decide to aggregate or not there is need to 
clarify a requirement on the server regarding how to aggregate. If the 
client does not include a session header in the SETUP request the server 
MUST setup this media with a new session id.

RTP retransmission (RTX) in the RTSP signaling.
One has a audio and video that is not desired to aggregate together. 
However they have session  multiplexed RTX streams that needs to be 
aggregated with there original data streams. This can not be signaled in 
a single SDP. The preferred solution in this case would be to use two 
different SDP for each media so a aggregated control URL can be defined 
in each SDP. If the server allows total aggregation and has session 
control URL the client will still be able to non aggregate the media 
together.

Best Regards

Magnus