Subject: [MMUSIC] RTSP: Minutes telecon 14th of October 2003

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Oct 2003 20:03:31 +0200

Hi,

Here is the preliminary minutes for todays telecon. Please comment.

RTSP Telecon the 14th of October

Participants:
Magnus Westerlund, Colin Perkins, Aravind Narasimhan, and Tom Marshall.

Agenda:

1. Opening of meeting.

2. Administrative
    - Scribe
    - IETF in Minneapolis
      * Off-line Meeting?
      * What to present.

3. Since last meeting (1st of October).
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
     - Text sent to mailing list, please review.

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

d. http://rtsp.org/bug640272 - Default way of deriving aggregate URL
    - Text sent to the mailing list

e. http://rtsp.org/bug771638 - a=range in SDP to indicate live media
    - Text sent to the mailing list.

f. http://rtsp.org/bug531189 - How does REDIRECT method work
    - Needs somebody to write up.

g. http://rtsp.org/bug810678 - How to indicate end of media stream
    - Strawman proposal available from Thomas. For discussion.

h. http://rtsp.org/bug770522 - Request to response time is not limited.
    - Some discussion on mailing list. Sean to write up text.

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

j. http://rtsp.org/bug795295 - TEARDOWN using * and the Ready-nm state
    - Posted to the mailing list, no comments. Unless comments are
      received it will be edited in.

k. http://rtsp.org/bug804219 - How to handle sync in re-SETUP
    - Text posted to the list. No comments received so far.

l. http://rtsp.org/bug806404 - Re-SETUP of transport parameters
    - Awaiting proposal text from Geetha.

m. http://rtsp.org/bug810666 - Removal of SETUP in play state
    - Proposed to be removed. Message sent to the list.

4. New Issues

a. http://rtsp.org/bug811815 - Use of c= in SDP to know possible address 
classes

b. http://rtsp.org/bug795314 - Caching of OPTIONS request

5. Any other business

6. Next Telecon: Proposal Wednesday, 3rd of December.

7. End of meeting

Minutes
-------

1. Meeting was opened.

2. - Magnus volunteered to write the minutes.

    - IETF meeting in Minneapolis:
      * Colin will request a conference room for a out-side of normal
        agenda meeting. A guess of on the number of participants are
        around 15.

      * The authors will perform a status update on the specification in
        the WG session. The current resolutions and open issues will be
        presented.

3.

a. Nothing has happened.

b. Await review from the WG.

c. Status not changed.

d. Await review from the WG.

e. Was not sent yet, but will be available directly after meeting.
Review comments needed.

f. The remaining issue is with implicit closing of the session. The
    previous meeting has agreement on the functionality but some minor
    issues around use of "connection" needs resolving. Best way of
    resolving this is probably to present a specification text proposal.
    Aravind will take this as a second priority issue.

g. Send comments on the document to list. The discussion resolved that
    this can be divided into several pieces:

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

    - Look into SIP to see how they have resolved the discrepancies
      between media and signaling channel.

h. Awaits text from Sean.

i. This is a later decision when we have received a list of changes that
    are accurate.

j. Unless comments are received by Monday the 20th of October, this
    resolution will be edited in. Magnus will post a reply to the initial
    mail pointing out the deadline.

k. Will be kept in the text unless comments are review by Wednesday the
    22th of October.

l. Awaits text.

m. Will be edited in unless comments are received by Monday the 20th of
    October.

4.
a. Question raised is: Are there need for a server to announce through
    SDP or other pre SETUP mechanism which address classes it supports to
    the client?

    There was discussion on this topic and the resolution was the
    following:

    It should be assumed that a server being possible to find in DNS with
    a certain address class will support both signaling and media
    delivery for that address. Thus a RTSP request over TCP/IPv6 will
    send media using that source IPv6 address.

b. The OPTIONS request has some dependency on server state and what
content that are addressed. Therefore it seems doubtful that caching of
OPTIONS request are possible. In general it seems that the only
really cachable RTSP request/response pair is for DESCRIBE.

5. No other business.

6. Preliminary date is the 3rd of December, which is three weeks after
the IETF meeting.

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

---

From: Thomas Zeng <[email-masked]>
Date: Mon, 27 Oct 2003 08:02:38 -0800

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Monday, October 27, 2003 1:00 AM
> To: Thomas Zeng
> Cc: IETF MMUSIC WG; Greg Sherwood; David Kosiba
> Subject: Re: [MMUSIC] RTSP: Minutes telecon 14th of October 2003
> 
> 
> Hi Thomas,
> 
> I don't think there will be any problem with later writing a 
> extension 
> draft resolving the problems and how one likes this to work. 
> Through the 
> use of a feature tag and a the Require header the client can 
> ensure that 
> the server interprets the timed field correctly in such 
> requests. Please 
> note that I am not removing the syntactical element, rather 
> declaring it 
> as shall not be used in the core spec for other purposes then 
> REDIRECT.
> 
> I hope you look over the possible solutions for playlist to 
> find what is 
> a good solution.
> 
> If one take the simple approach only having the desire to delay the 
> start of the playback the problems would not be to hard to solve. 
> However it would be simpler if one haves a separate extension 
> draft for 
> this rather than using the core specification, which I interprets as 
> being your intention.

Yes, indeed. 
> 
> Cheers
> 
> Magnus
> 
> 
> Thomas Zeng wrote:
> 
> > Magnus:
> > 
> > Our use case is best handled by a feature-tag, I think.  
> Let me clarify:
> > even if "time=" is deprecated
> > in Range header in the core spec, we can still "resurrect" 
> it in a extension
> > to RTSP protocol, as long as
> > we address any ambuguity (I believe we can)?
> > 
> > More embedded.
> > 
> > thanks,
> > thomas
> > 
> > 
> >>-----Original Message-----
> >>From: Magnus Westerlund [mailto:[email-masked]]
> >>Sent: Wednesday, October 22, 2003 1:33 AM
> >>To: Thomas Zeng
> >>Cc: IETF MMUSIC WG
> >>Subject: Re: [MMUSIC] RTSP: Minutes telecon 14th of October 2003
> >>
> >>
> >>Hi Thomas,
> >>
> >>If you have a use cases for this, I think it is possible to 
> keep the 
> >>timed functionality, under the condition that you provide all 
> >>necessary 
> >>specification text to solve the problems with timed PLAYs.
> > 
> > 
> > We will either propose timed PLAY or timed PLAYLIST_PLAY.
> > 
> >>I would also like to have some more information about use case.
> >>
> > 
> > The use case involves server-side playlist play, where one 
> may desire to
> > have the option to jump to a new
> > item in the playlist, but only at the end of the current item.
> > 
> >>The big problem with the timed requests are the following:
> >>
> >>- Are they allowed to be stacked, are multiple possible to be 
> >>requested 
> >>for later execution? If yes, the real problems exist.
> > 
> > 
> > No, only outstanding timed request is allowed. That is, the 
> stack size is 1.
> > 
> >>- If you use timed requests how does the interaction 
> happens with the 
> >>state machine. When are the state transition made, when the 
> >>request is 
> >>received or when it is executed.
> > 
> > 
> > The first PLAY is always executed immediately. So state 
> transition is no
> > issue.
> > In another words, timed PLAY is only in PLAYING state for 
> clip transition.
> > 
> >>- How is errors at the time of execution handled?
> > 
> > Error will be reported via event report (say via 
> SET_PARAMETER or ANNOUNCE).
> > 
> >>- If multiple requests are allowed, how does one handle if 
> >>two request 
> >>collide.
> > 
> > 
> > Again, only one timed request is allowed.
> > 
> >>- How do you stop a timed request, between acceptance and execution?
> >>
> > 
> > By sending another PLAY or PLAYLIST_PLAY.
> > 
> 
> 
> 
> -- 
> 
> Magnus Westerlund
>