Subject: [MMUSIC] Minutes from Jan 23 telecon

From: Rob Lanphier <[email-masked]>
Date: Wed, 23 Jan 2002 18:49:47 -0800 (Pacific Standard Time)

Hi all,

Here's the lightly edited minutes of the telecon.  I'll send out more
clearly worded versions of the resolutions to each of these in separate
email.  Attendees:  please speak up if there are any errors or omissions.

The minutes and agenda for this telecon and all other telecons can be
found at the following address:
http://rtsp.org/telecon/

(or, you can always find these by going to rtsp.org, clicking on "Process"
in the left nav bar, and clicking on the "RTSP Ad Hoc Telecon Agenda and
Minutes" link)

Cheers,
Rob

                           Rtsp Tc Minutes23 Jan2002
     _________________________________________________________________

    1. [1]Attendees
    2. [2]Action items/new issues
    3. [3]Discussion

    1. [4]477421 When to send response
    2. [5]477423 Unclearities regarding pause with range
    3. [6]477424 How to queue timed plays?
    4. [7]477425 Inconsistency between timeformats
    5. [8]477427 Transport model requirements
    6. [9]477428 Priorites between aggregated & non cntrl

                                   Attendees

     * Anders Klemets (AK)
     * Anne Jones (AJ)
     * Colin Perkins (CP)
     * Sean Sheedy (SS)
     * Magnus Westerlund (MW)
     * Joerg Ott (JO)
     * Milko Boic (MB)
     * Dave Walker (DW)
     * Rob Lanphier (RL)
     * Jonathan Sergent (JS)
     * Jeff Ayars (JA)

                            Action items/new issues

     * ACTION ITEM (RL): submit proposal to eliminate queued play
     * ACTION ITEM (MW): continuous sequence number filing
     * ACTION ITEM (JS): Write up aggregate URL proposal.

                                  Discussion

   (following agenda at
   [10]http://rtsp.org/2002/telecon/agenda23Jan.html)

477421 When to send response

   [11]477421
     * JS: may be more of a problem with TCP
     * RL: semantically correct should not disconnect, but syntax can
       cause disconnect
     * SS: should respond with seqnum-less response
     * JS: had to fix "bug" on our implementation on this when we blew
       away connection
     * MW: higher version number response
     * JS: should respond with good response
     * JS: what should be res on 421
     * JA: send response with no seqnum
     * AK: question of when
     * JA: huge implementation issue to enforce order
     * JA: corner case not worth handling well
     * AK: should respond immediately?
     * JA: yes...at least not required to respond in request order.
     * AK: leave as implementation issue
     * JS: agreed
     * RL: has anyone implemented RTSP over UDP?
     * SS: Yes, implemented RTSP over UDP
     * RESOLVED: server allowed to send immediate response with no
       sequence number. server should NOT set sequence number

477423 Unclearities regarding pause with range

   [12]477423

     * MB: pause with range gives you a "loose" range
     * JS: is that useful?
     * MB: if the time for the pause is already past?
     * JS: should avoid changing semantics
     * MW: what about UTC?
     * JS: I don't think you can specify UTC
     * JS: anyone implement UTC stuff
     * RL: not us
     * AJ: not us
     * MW: we have
     * JS: you may be only one. We need to forbid mixing
     * SS: we implemented
     * MW: we can remove this for pause
     * JS: you could want to use with nothing but UTC
     * RESOLVED: no UTC on pause. End of range is ignored (begin time is
       used). Example is needed. If both are specified a precedence is
       needed (time= takes precedence over clock) End of range is ignored
       (begin time is used). Example is needed. If multiple range
       specifiers are present, we need to come up with an ordering
       (npt/smpte takes precence over time)

477424 How to queue timed plays?

   [13]477424 queued play
     * JS: who implements
     * SS: we implement, but no client
     * JS: lets take it out
     * AK: there's other problems
     * MW: there may be some benefit, but not really as is
     * SS: usually, clients want to have immediately play
     * JS: PAUSE/PLAY can be pipelined
     * SS: eliminate queued play
     * JA: some VOIP folks would like it
     * JS: should take to list
     * RESOLVED: propose elimination of queued play to list. Separate
       email necessary.
     * RESOLVED: postpone 477424 until queue play is resolved
     * ACTION ITEM (RL): submit proposal to eliminate queued play
     * ACTION ITEM (MW): continuous sequence number filing

477425 Inconsistency between timeformats

   [14]477425
     * JS: agree with note in 477425
     * RESOLVED: Extend this to other time formats, and probably clarify
       the semantics of this particular syntax. Should start at pause
       point or the beginning.

477427 Transport model requirements

   [15]477427

     * JS: We close things down, but we'd like to fix that
     * RL: how does liveness indication work
     * JS: we use RTCP
     * JS: Darwin hangs up if RTCP isn't received.
     * AJ: Correct. Some firewalls don't work well with this.
     * MW: There's a PING method request
     * TM: security issues with connectionless
     * JS: ssl is the way to solve this if that's a big issue
     * MW: what about original issue?
     * JS: needs to be negotiable option
     * MW: Use spec terminology: "persistent" and "non-persistent"
     * JS: Pragma specifically removed.
     * AK: perhaps "Supported" should be used
     * RESOLVED: define header and response for non-persistent
       connections. Default is connection-oriented, and connectionless
       MAY be implemented. Look into "supported" header.

477428 Priorites between aggregated & non cntrl

   [16]477428
     * TM: we have "Required", suggest "Requested"
     * JS: what happenes when the client does SETUP audio, SETUP video,
       PLAY audio, all on same session
     * JS: perhaps adding MUTE would solve a lot of problems that
       overloading PAUSE causes
     * RL: what about TEARDOWN on stream URL?
     * JS: only sensible answer is that TEARDOWN on stream only tears
       down
     * RESOLVED: await resolution of queued play. Aggregate control issue
       needs larger discussion
     * ACTION ITEM: JS: Write up aggregate URL proposal.

References

   1. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line3
   2. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line17
   3. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line23
   4. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line27
   5. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line48
   6. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line67
   7. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line85
   8. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line90
   9. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line108
  10. http://rtsp.org/2002/telecon/agenda23Jan.html
  11. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477421
  12. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477423
  13. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477424
  14. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477425
  15. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477427
  16. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477428

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

---

From: Jonathan Sergent <[email-masked]>
Date: Wed, 23 Jan 2002 18:51:36 -0800

>      * ACTION ITEM (JS): Write up aggregate URL proposal.

I have this ready but want to proofread it before I send it out.
Bug me if I don't get it out by the end of the week...

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 24 Jan 2002 09:59:14 +0100

Hi, I think the resolution on the following issue is slightly bungled.

> 477423 Unclearities regarding pause with range

The resolution I thought we made was:
Only a single range specifier on the format "value-" is allowed for pause. time="execution time in
UTC" may also be used. I believe the ordering/processing of these two are very clear. Add example of
how pause with range specifier is used.

Regards

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 24 Jan 2002 15:35:14 -0800 (Pacific Standard Time)

Hi Magnus,

Thanks for the correction (my editing was obviously too light) :)

Here's the corrected version I put online:
RESOLVED: Only a single range specifier (format "value-" where "value" is
a time) is allowed for pause. time="execution time in UTC" may also
be used, but if multiple range specifiers are present, npt/smpte takes
precence over time.  A new example will be provided.

http://rtsp.org/2002/telecon/minutes23Jan.html#line48

Rob

---

From: Jonathan Sergent <[email-masked]>
Date: Thu, 24 Jan 2002 16:46:42 -0800

On Thursday, January 24, 2002, at 03:35 PM, Rob Lanphier wrote:

> Only a single range specifier (format "value-" where "value" is
> precence over time.

Is it more useful to have time take precedence over npt/smpte/clock?

For a PAUSE with Range: npt=foo;time=bar, the interpretation with npt 
precedence would be to  pause the stream at npt foo and bar would be 
ignored.

The interpretation with time precedence would be to pause the stream at 
time bar while setting the pause point to foo (regardless of what it was 
set to).

Neither of these is particularly useful, IMO.  I do think that PAUSE 
with only time= might be useful in a broadcast control scenario, to say 
that a program needs to end at a particular time, rather than at a 
particular point in the program, since the relationship between the two 
might be hard to determine from the client, especially if it isn't 
participating in the session, only controlling it.

So upon further reflection it's my humble opinion that it is probably 
better to say for PAUSE that the Range header should contain
	(time= | npt= | smpte= | clock=)
rather than
	(npt= | smpte= | clock=) (;time=)?
...

But I could cope with the precedence as you have it above.  It doesn't 
matter too much to me.

--
Jonathan Sergent / [email-masked] / (650)352-6495

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 25 Jan 2002 09:56:28 +0100

Jonathan, Rob

See arguments below on the issue.

> Is it more useful to have time take precedence over npt/smpte/clock?

I would say that doing that interpretation breaks backwards compatibility.
My interpretation of the time= is that it has presedence. You do not execute
the method until the your wall clock has reached the time specifed in time=.
Then you look at the rest of the range togheter with the method. So I don't
want us to change this for pause.

> participating in the session, only controlling it.

But to have a range header with only time is not allowed in todays syntax.
But at least for pause specifying a point that you know the
presentation/media has passed makes it equal to no range, i.e. pause
immedeatly.

>         (npt= | smpte= | clock=) (;time=)?

My opinion is that such a change will result in more complexity, when range
is interpreted in different ways between PLAY and PAUSE.

--

Magnus Westerlund

---

From: Jonathan Sergent <[email-masked]>
Date: Fri, 25 Jan 2002 11:13:04 -0800

> want us to change this for pause.

This sounds fine to me, in particular the third and fourth sentences.

--jss.

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 31 Jan 2002 19:30:07 -0800 (Pacific Standard Time)

Hi all,

Here's the first of many emails regarding the resolutions on the RTSP
telecon of Jan 23.

From the bug report (http://rtsp.org/bug477421):

> Server can't respond to a bad request if no sequence
> number is present in the request. Resulting in that the client does not
> know that the server has received it and has issues. Please clarify when
> a server is allowed to send response to bad request.

* RESOLVED: The server is allowed to send immediate response with no
sequence number. However, the server should NOT set the sequence number on
behalf of the client.

Rob

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 31 Jan 2002 19:38:15 -0800 (Pacific Standard Time)

From the bug report (http://rtsp.org/bug477423)
>  How shall the pause point be specifed? Is the only correct way to do it
> "(start time)- "? The use of range with time? It seem to be unecessary as
> play with range works instead.

(further notes)
> Does need clarification in specification, but probably warrents
> discussion.
>
> Recommendation: end time in range is ignored

This issue was discussed further on the list:
http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00102.html

*  RESOLVED: Only a single range specifier (format "value-" where "value"
is a time) is allowed for pause. time="execution time in UTC" may also be
used, but if multiple range specifiers are present, npt/smpte takes
precence over time. A new example will be provided.

Rob
----

Raw notes.
> 477423 Unclearities regarding pause with range

Revised:
*  RESOLVED: Only a single range specifier (format "value-" where "value"
is a time) is allowed for pause. time="execution time in UTC" may also be
used, but if multiple range specifiers are present, npt/smpte takes
precence over time. A new example will be provided.