Subject: [MMUSIC] RTSP: Telecon 18.00 the 3rd of December with agenda - Updated

From: Magnus Westerlund <[email-masked]>
Date: Wed, 03 Dec 2003 13:25:34 +0100

Hi,

Today is the RTSP telecon. I provide an updated agenda. The changes are 
both in 2.1 and an addition of paragraph 3.1.

Telecon details:
Phone number +46 8 71 99500
Participant PIN   67700
Date   12/03/2003 (MM/DD/YYYY)
Start Time   18:00 (HH:MM)  (CET)
Duration 90 minutes

Cheers

Magnus Westerlund

Agenda

1. Opening of meeting and Administrative
   - Scribe

2. RTSP Core

2.1 Core specification bugs under developement.

a. http://rtsp.org/bug507882 - RTP timestamp and pause
   - Aravind to write up text

b. http://rtsp.org/bug742328 - How to handle PLAY request when at the
                                end of a media clip
   - Await review from the WG.

c. http://rtsp.org/bug742348 - Usage of implicit REDIRECT.
   - Needs text

d. http://rtsp.org/bug640272 - Default way of deriving aggregate URL
  - The explicit rules will be removed, possibility will be left open.
    Needs to be edited in.

e. http://rtsp.org/bug771638 - a=range in SDP to indicate live media
  - Needs a clarifying definition of Live
  - Need to check to possibility for TiVo cases.

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.

g. http://rtsp.org/bug770522 - Request to response time is not limited.
  - Sean has written up text.
  - Conclusion from Minneapolis:  Sean's writeup seems reasonable.
    Change the timelimit to 2 seconds and make sure that wording is there
    to indicate server should do this immediately if it know it's going
    to take a long time.  Need motivation example.

h. http://rtsp.org/bug795295 - TEARDOWN using * and the Ready-nm state
  - Has been removed from spec, awaiting review.

i. http://rtsp.org/bug804219 - How to handle sync in re-SETUP
  - Awaiting review from the WG.

j. http://rtsp.org/bug806404 - Re-SETUP of transport parameters
  - Text sent to mailing list, we will dicuss this, please read

https://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg02030.html

k. http://rtsp.org/bug810666 - Removal of SETUP in play state
   - Clarify in specification that it is unspecified.

l. http://rtsp.org/bug811815 - Use of c= in SDP to know possible address
classes
   - Conclusion from Minneapolis:
     Should look at address classes in the SDP to figure what protocol
     to use (need to add SDP section of RTSP). Look at c= line syntax.
     Multiple c lines can be use in media field?  SIP resolution was
     that multiple c lines should not be used to express multiple
     connection address.

m. http://rtsp.org/bug795314 - Caching of OPTIONS request
   - conclusion from Minneapolis: Will be declared unspecified.

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

o. http://rtsp.org/bug850265 - Removed features are unspecified, not
forbidden

p. http://rtsp.org/bug840304 - CSEQ is direction dependent in numberspaces.
   - Awaiting write up.

q. http://rtsp.org/bug850267 - Should all ABNF syntax be gathered in one
chapter?

r. http://rtsp.org/bug829528 - Usage of Grouping of media lines with RTSP.

s. http://rtsp.org/bug853175 - Dest_addr needs indicator for using RTSP IP

t. http://rtsp.org/bug853178 - Security risk with changing transport 
parameters

u. http://rtsp.org/bug853184 - How to learn servers multicast capabilities

2.2 Tracking of items not require actions currently.

These items are for future processing when appropriate.

A. http://rtsp.org/bug810681 - The updated specification version number
  - Awaiting investigation results regarding changes by Aravind.
  - Question of intentions.

3. RTSP Specifiction Extensions

3.1 Streaming Relays.
     See MMUSIC mail: 
https://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg02190.html

3.2 End of Media
  http://rtsp.org/bug810678 - How to indicate end of media stream
  - We need to document in the RTSP specification regarding RTP what
    happens when a source times out a SSRC or receives a RTCP BYE for a
    source.

  - Using BYE is not suitable way to indicate the end of the stream.
    The motivation for this can be seen in Thomas proposal.

  - The creation of a new proposal.

3.3 RTSP and NAT issues

  - Requirements
    Priorities:
    1. Server is deployed in open network.
    2. Server behind firewall next.
    3. If a client is not dual hosted, it should not have to deal with
       additional protocols.
    4. Must have defense against DOS
    5. Security.
    6. MUST deal with symmetric nat.
    7. ALG.  The firewall traversal should not interfere with ALGs.
    8. Advise to ALG writers not to screw it up.

    Review and clarify.

  - Protocol extension proposals
    What proposals do we have, and which people are sheeparding.

  - Update to RTSP and NAT WG draft
    * ALG recommendation

4. Next meeting

5. Meeting closed.

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

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