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

From: Thomas Zeng <[email-masked]>
Date: Tue, 21 Oct 2003 16:12:14 -0700

Magnus:

During one of the telecon for RTSP, I recall that a decision was made to 
deprecate "time=" parameter in Range header.

We have found a use case in the context of playlist support, where we would
like to use
"time=" parameter in Range header in the PLAY request as designed in
RFC2326, quoted below:

10.5 PLAY

...

   The Range header may also contain a time parameter. This parameter
   specifies a time in UTC at which the playback should start. If the
   message is received after the specified time, playback is started
   immediately. The time parameter may be used to aid in synchronization
   of streams obtained from different sources.

In light of this, would it be possible to retain this "time parameter"?

thanks,
thomas
-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, October 14, 2003 9:53 PM
To: Thomas Zeng
Cc: 'Magnus Westerlund'; IETF MMUSIC WG
Subject: Re: [MMUSIC] RTSP: Minutes telecon 14th of October 2003

Yes, SIP BYE is used to terminate the call, which also results in the 
termination of the media sessions.

-Jonathan R.

Thomas Zeng wrote:

> On item g:
> 
>     - Look into SIP to see how they have resolved the discrepancies
>       between media and signaling channel.
> 
> Could someone fammiliar with SIP help me out here: I need to know what
> method of SIP to look, is it SIP BYE method by any chance?
> 
> (I saw that SIP has a BYE method to terminate the call in the signalling
> channel. )
> 
> thanks,
> thomas
> 
> 
> 
> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Tuesday, October 14, 2003 11:04 AM
> To: IETF MMUSIC WG
> Subject: [MMUSIC] RTSP: Minutes telecon 14th of October 2003
> 
> 
> 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.
> 
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 22 Oct 2003 10:32:48 +0200

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.

I would also like to have some more information about use case.

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.

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

- How is errors at the time of execution handled?

- If multiple requests are allowed, how does one handle if two request 
collide.

- How do you stop a timed request, between acceptance and execution?

These are probably not all the problems, simply the ones I can remember 
of the top of my head.

So please provide a solution proposal so we can discuss and review if it 
solves the problems in a satisfactory way.

cheers

Magnus

-- 

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]