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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 03 Apr 2002 12:38:56 +0200

Hi Philippe,

Yes, Remote camera control would be one possible application of such 
protocoll or extensions.

/Magnus

[email-masked] wrote:

>
> 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
>
> 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.
>
>
>

-- 

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]

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