Subject: [MMUSIC] RTSP Telecon 031203 Minutes of meeting

From: Magnus Westerlund <[email-masked]>
Date: Fri, 05 Dec 2003 13:42:20 +0100

Hi,

Here is the minutes of meeting from Wednesday's telecon. I hope more 
people will be able to participate on the next meeting.

Cheers

Magnus

RTSP telecon minutes 031203

Participants
------------
Magnus Westerlund
Sean Sheedy
Colin Perkins
Geetha Srikantan

1. Opening of meeting and Administrative
    Magnus Westerlund will produce minutes.

2. RTSP Core

2.1 Core specification bugs under developement.

a. http://rtsp.org/bug507882 - RTP timestamp and pause
    - Aravind has not yet produced any text, but has promised to do it
      shortly.

b. http://rtsp.org/bug742328 - How to handle PLAY request when at the
                                end of a media clip
    - We will close this, as no comments has been received.

c. http://rtsp.org/bug742348 - Usage of implicit REDIRECT.
   - Arawind will write up text.

d. http://rtsp.org/bug640272 - Default way of deriving aggregate URL
  - Magnus will edit this in.

e. http://rtsp.org/bug771638 - a=range in SDP to indicate live media
    - Check if live is written, and try to remove, in benefit for
      Unbounded session.
    - Check if the syntax does not create greate clashes with the TiVo
      use case.  However it is unlikely that the full semantics neceassary
      can be expresed with current attributes.

f. http://rtsp.org/bug531189 - How does REDIRECT method work
  - Conclusion from Minneapolis needs to be edited in:  Server MAY drop
    the connection after it has recieved 200 OK response on a REDIRECT.
    Needs to be edited in.

g. http://rtsp.org/bug770522 - Request to response time is not limited.
    - Sean will update the proposal and post to the mailing list.

h. http://rtsp.org/bug795295 - TEARDOWN using * and the Ready-nm state
    - This item will be closed.

i. http://rtsp.org/bug804219 - How to handle sync in re-SETUP
    - In certain cases the move may result in a totally new RTP session,
      therefore all new synchronization information may be required. 
Check if
      language is strict enough, and if necessary clarify between cases 
where
      mapping can be maintained and where needs to be changed.

j. http://rtsp.org/bug806404 - Re-SETUP of transport parameters
    - It seems initial and ready state changes are equal, and the play
      state being more restricted.
    - Point out that in the general case the changes can result in that a
      new RTP session is created.
    - Another consideration is for connection oriented media, can a
      switch over be performed relatively seamless.
    - It seems that not requiring a PAUSE, SETUP, PLAY sequence makes
      sense, thus motivating the continuation of this work.
    - However the proposals and text needs more thought.
    - Geetha will provide new text.

k. http://rtsp.org/bug810666 - Removal of SETUP in play state
   - Magnus will edit in that it is unspecified.

l. http://rtsp.org/bug811815 - Use of c= in SDP to know possible address
                                classes
   - Needs to look into backwards compatibility issues.
   - This issue is connected to issue (r), to allow a server to announce
     dual address realm support.
   - It needs a proposal text for evaluation.

m. http://rtsp.org/bug795314 - Caching of OPTIONS request
   - Magnus will look into if the current caching text is complete enough,
     if not it will be declared unspecified.

n. http://rtsp.org/bug850256 - When must RTP-Info be included?

   - Usage of RTP-Info can be a SHOULD, however if the server does not
     provide it, the client will be required to do synchronization by
     RTCP. Servers are strongly recommened if able to include RTP-Info
     with timestamp information.

o. http://rtsp.org/bug850265 - Removed features are unspecified, not
forbidden
   - Needs to be edited in.

p. http://rtsp.org/bug840304 - CSEQ is direction dependent in numberspaces.
   - Nothing done, needs to be edited in.

q. http://rtsp.org/bug850267 - Should all ABNF syntax be gathered in one
chapter?
   - Nothing done, needs to be edited in.

r. http://rtsp.org/bug829528 - Usage of Grouping of media lines with
                                RTSP.
   - For futher study and discussion.

s. http://rtsp.org/bug853175 - Dest_addr needs indicator for using RTSP
                                IP
   - For futher study and discussion.

t. http://rtsp.org/bug853178 - Security risk with changing transport
                                parameters
   - For futher study and discussion.

u. http://rtsp.org/bug853184 - How to learn servers multicast
                                capabilities
   - For futher study and discussion.

2.2 Tracking of items not require actions currently.

- Nothing to discuss here

3. RTSP Specifiction Extensions

3.1 Streaming Relays.
     We had some discussions about this. Geetha wil publish the proposal
     as a draft. Needs to be reviewed by a larger group.

3.2 End of Media
    - Skiped

3.3 RTSP and NAT issues
    - Skiped

4. Next meeting

- Will be in mid January

5. Meeting closed.

-- 

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]

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