Subject: [MMUSIC] MoMs from RTSP lunch meeting at IETF

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Mar 2002 16:37:11 +0100

Hi

Here comes the minutes of meeting from last weeks RTSP lunch meeting.

Regards

Magnus Westerlund 

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

RTSP Lunch meeting Thursday 21 march 2002 11.40-13.00 at the 53rd IETF 

approx 15 participants.

1. Interop  discussion

- The previous RTSP interop seem to have lacked a proper test plan.

- We should look at both HTTP and SIP interop work to get a good opinion what is 
  a good way to do it. 

- We may have to come to some agreements on what to disclose of the results of 
  an interop. 

- Propose to do offline testing before any event to reach a common level of 
  interoperability.

- May create/compile a document with RTSP traces that are compliant for testing.

2. JPEG-2000 Internet protocol

Mark Wood made a short presentation which contained: - Use cases and 
possibilities with JPEG-2000 - requirements on a control protocol - The data 
transport may vary and is not finished. - Two mode of operations, server 
controlled and client controlled. Requested input on: Is a RTSP style protocol the 
right idea? See message to mmusic for initial document idea.

Comments: - Such a control protocol could be generalized beyond JPEG-2000. -
Should not create two protocol that are very similar. - This problems includes 
navigation/control in up to 4 (3 spacial + temporal) or more dimensions(e.g. 
IR,Xray, Radar). - It could be a possibility to decouple the temporal control 
(RTSP) from the spatial control (new protocol). - The most probable initial 
transport will be TCP for the data plane. - When combining temporal and spatial 
control there might be aggregation problems. - This problem is worth further 
discussion and work. Use the MMUSIC mailing list for discussion. 

3. CATS

Interested in the possibility to do Text To Speech (TTS) and Automatic Speech 
Recognition (ASR) control with RTSP. Do TTS to and control that with PLAY. May 
also use RECORD for ASR and also streaming results back to the sender.

4. RTSP extension

- The work with RTSP to draft standard should not be effected by extensions. -
  All extensions should be reasonable and fit RTSP's model. - Avoid SIP's Info 
  decease by not overloading a general method. - We should also carefully 
  consider the interaction of RTSP middle boxes. - The protocol capability 
  discovery also needs to be consider by applications using extensions. There 
  are basically 3 levels that can work. 
  1. Demand a functionality and be certain by checking it previous to use. 
  2. Try functionality and receive notification if it does not work. But the 
  application can handle the lack of the functionality. 
  3. Do not care if functionality works or not. 

- Is there need for adding a more elaborated scope description for RTSP? - There 
  might be need to clarify how proxies shall handle unknown methods. - In most 
  extensions requiring new functionality new methods should be created. This 
  will avoid having multiple levels of multiplexing, which could be the result 
  if SET_PARAMETER parameters is used to create a extension. SET_PARAMETER shall 
  not be used as a tunneling method.

Due to lack of time no of the direct RTSP issues was covered in this meeting.

---

From: [email-masked]
Date: Mon, 25 Mar 2002 18:36:20 +0100

This 3+1 dimension stuff, would it be meant/suitable for kind of remote 
camera control ?

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.mpeg-4.philips.com

Magnus Westerlund <[email-masked]>
Sent by: [email-masked]
03/25/2002 16:37

        To:     IETF MMUSIC WG <[email-masked]>
        cc:     (bcc: Philippe Gentric/LIM/CE/PHILIPS)
        Subject:        [MMUSIC] MoMs from RTSP lunch meeting at IETF
        Classification: 

Hi

Regards

Magnus Westerlund 

approx 15 participants.

1. Interop  discussion

- We should look at both HTTP and SIP interop work to get a good opinion 
what is 
  a good way to do it. 

- We may have to come to some agreements on what to disclose of the 
results of 
  an interop. 

- Propose to do offline testing before any event to reach a common level 
of 
  interoperability.

- May create/compile a document with RTSP traces that are compliant for 
testing.

Mark Wood made a short presentation which contained: - Use cases and 
possibilities with JPEG-2000 - requirements on a control protocol - The 
data 
transport may vary and is not finished. - Two mode of operations, server 
controlled and client controlled. Requested input on: Is a RTSP style 
protocol the 
right idea? See message to mmusic for initial document idea.

Comments: - Such a control protocol could be generalized beyond JPEG-2000. 
-
Should not create two protocol that are very similar. - This problems 
includes 
navigation/control in up to 4 (3 spacial + temporal) or more 
dimensions(e.g. 
IR,Xray, Radar). - It could be a possibility to decouple the temporal 
control 
(RTSP) from the spatial control (new protocol). - The most probable 
initial 
transport will be TCP for the data plane. - When combining temporal and 
spatial 
control there might be aggregation problems. - This problem is worth 
further 
discussion and work. Use the MMUSIC mailing list for discussion. 

3. CATS

Interested in the possibility to do Text To Speech (TTS) and Automatic 
Speech 
Recognition (ASR) control with RTSP. Do TTS to and control that with PLAY. 
May 
also use RECORD for ASR and also streaming results back to the sender.

4. RTSP extension

- The work with RTSP to draft standard should not be effected by 
extensions. -
  All extensions should be reasonable and fit RTSP's model. - Avoid SIP's 
Info 
  decease by not overloading a general method. - We should also carefully 
  consider the interaction of RTSP middle boxes. - The protocol capability 

  discovery also needs to be consider by applications using extensions. 
There 
  are basically 3 levels that can work. 
  1. Demand a functionality and be certain by checking it previous to use. 

  2. Try functionality and receive notification if it does not work. But 
the 
  application can handle the lack of the functionality. 
  3. Do not care if functionality works or not. 

- Is there need for adding a more elaborated scope description for RTSP? - 
There 
  might be need to clarify how proxies shall handle unknown methods. - In 
most 
  extensions requiring new functionality new methods should be created. 
This 
  will avoid having multiple levels of multiplexing, which could be the 
result 
  if SET_PARAMETER parameters is used to create a extension. SET_PARAMETER 
shall 
  not be used as a tunneling method.

Due to lack of time no of the direct RTSP issues was covered in this 
meeting.