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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 27 Nov 2003 15:52:05 +0100

Hi,

Next week on Wednesday (3rd of December) it is time for a RTSP telecon 
again. Please send a me a mail if you intend to participate. If you have 
comments on the agenda, please drop me a mail.

 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.

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