Subject: [MMUSIC] RTSP ad hoc telecon

From: Rob Lanphier <[email-masked]>
Date: Wed, 9 Jan 2002 18:44:12 -0800 (Pacific Standard Time)

Hi all,

Here are the minutes for the RTSP ad hoc telecon previously announced on
this list.  If you reply to this, please change the subject of your email
to reflect the issue you are talking about (preferably referring to bug
number).

The minutes are available in text form below and in HTML at the following
address:
http://rtsp.org/2002/telecon/jan09.html

Next telecon is in two weeks, where we plan to close out these issues, so
let us know what you think on these issues.  If you missed this telecon,
but want to join future telecons, read on.

Thanks
Rob

                           Rtsp Tc Minutes09 Jan2002
     _________________________________________________________________

    1. [1]Attendees
    2. [2]General Process
    3. [3]Action Items/New Issues
    4. [4]Resolutions
    5. [5]Issue Discussion

    1. [6]#448521 URLs in Rtp-Info need to be quoted
    2. [7]#449074 - RTP Seqnum offset in Pause Play response
    3. [8]#461083 - Body w/o Content-Length clarification
    4. [9]#447404 - Errors in table in chapter 12
    5. [10]#477407 - Transport BNF, ; and unclearities
    6. [11]new issue, to be logged
    7. [12]477413 Transport BNF: mode
    8. [13]#477416 BNF error section 3.6 NPT

                                   Attendees

     * Magnus Westerlund
     * Joerg Ott
     * Jonathan Sergent
     * Rob Lanphier
     * David Walker
     * Milko Boic
     * Anders Klemets
     * Henning Schulzrinne
     * Tom Marshall

                                General Process

   The process we agreed on moving forward is as follows:

     * Telecon every two weeks, Wednesday at 9AM PST (17:00 GMT) for 90
       minutes, subject to consensus among ad hoc group members. Though
       we anticipate this will be the regular time, we may move this on a
       per telecon basis to schedules or timezone differences (e.g. if
       someone in Japan wants to participate without having to stay up to
       2:30 am)
     * Agenda with issues to discuss gets sent out to the working group
       on Friday prior to the telecon
     * Deadline is set for one or two weeks out, depending on issue
        - Note: Milko proposes that we use the telecons as a deadline for
            issues -- that also gives us the opportunity to "close"
            issues from previous week on the telecon. Any objections? -
            Also note: This ad hoc group doesn't have official status, so
            final place to close issues is always on the mailing list.
            The mailing list deadline would just happen to correspond to
            the telecon.

   For practical concerns, telecon attendance is limited to those who
   RSVP to me no later than 5pm PST Monday (1:00 GMT Tuesday), and may
   also be limited by other criteria if the need arises. However, open
   participation via IRC is always welcome
   ([14]irc://irc.openprojects.net/#rtspspec).

                            Action Items/New Issues

     * NEW ISSUE: Should timestamps increase while stream is paused?
     * ACTION ITEM: Rob: ping Dave Singer on #461083 and encourage future
       participation
     * NEW ISSUE: should interleave parameter require value?
     * ACTION ITEM: Tom: request new bug "clarify requirement that
       interleave requires value"

                                  Resolutions

     * [15]448521 URLs in Rtp-Info need to be quoted
          + RESOLVED: Go with proposed resolution, with semicolon and
            comma as "dangerous characters".
     * [16]449074 - RTP Seqnum offset in Pause Play response
          + RESOLVED: sequence numbers increase per suggestion in report.
            This is a clarification of RFC 1889, not new requirement.
     * [17]461083 - Body w/o Content-Length clarification
          + RESOLVED: require Content-length always, and eliminate
            implicit body-length via connection: close.
     * [18]447404 - Errors in table in chapter 12
          + RESOLVED: evaluate SIP table format and move to that unless
            someone objects (and justifies)
     * [19]477407 - Transport BNF, ; and unclearities
          + RESOLVED: BNF will require semicolon, no mandated ordering,
            and example will be added. Example should include multiple
            entries of same type. However, will prohibit duplicated
            fields within a type entry.
     * [20]477413 - Transport BNF: mode
          + RESOLVED: Rework BNF, fixing multiple problems not limited to
            allow outside quotes, but not inside quotes. Quotes are
            optional
     * [21]477416 - BNF error section 3.6 NPT
          + RESOLVED: require npt=, but have backwards-compatibility
            note. Need to check BNF to make sure that not having npt= can
            work, and make sure everyone is aware that may be confusion
            may result

                               Issue Discussion

   Here's the minutes from the discussion

#448521 URLs in Rtp-Info need to be quoted

   [22]448521

   Jonathan: proposed solution is fine

   Colin: why not URL encoding?

   Henning: Doesn't work. Lose distinction between truly escaped
   semicolons and escaped for this purpose

   Anders: which characters? ; , =

   Henning: equals sign ok

   Jonothan: requiring quotes on = is problematic

   Henning: semicolon and comma

   RESOLVED: semicolon and comma are "dangerous characters"

   Milko: quoting the whole URL?

   Henning: yes

   deadline?

   Henning: one or two weeks, depending on issue

#449074 - RTP Seqnum offset in Pause Play response

   [23]449074

   Jonathan: We do this anyway. RTP requires it

   Henning: agreed

   Milko: If indeed the server needs a newly generated number, the
   RTP-info is there.

   Henning: violates RFC 1889

   Rob: Real doesn't do this right. Does Darwin?

   Henning: Doesn't matter. RFC 1889 is pretty clear here. RTSP spec
   should reference RFC 1889 to clarify

   Jonathan: Need to clarify that SSRC changing midstream is a bad idea

   Colin: timestamp changing could be a problem

   Henning: implementation robustness issue

   Magnus: need to look at Appendix B (RTP usage) because it implies that
   timestamps continue increasing

   NEW ISSUE: timestamps monotonically increasing

   Milko: resolution should be related on new issue and current issue

   Henning: timestamp corresponds to display time

   RESOLVED: sequence numbers increase per suggestion in report. This is
   a clarification of RFC 1889, not new requirement

#461083 - Body w/o Content-Length clarification

   [24]461083

   Sean: like requiring content length

   Henning: make sure consistency with SIP. Specifying is preferred.

   Joerg: any examples of long implied length?

   Jonathan: Darwin does this for errors. Surprised that this may be
   issue

   Tom: Darwin doubles as HTTP server

   Rob: RTSP differs in this regard because no CGI issues

   RESOLVED: require Content-length always.

   (two week issue)

   ACTION ITEM: Rob: ping Dave Singer on this issue and encourage future
   participation

   Henning: Checked spec, and resolution is consistent with SIP

   RESOLVED: eliminate implicit body-length via connection: close

#447404 - Errors in table in chapter 12

   [25]447404

   Magnus: need to add columns to clarify which headers are needed,
   required, etc.

   Henning: latest SIP draft has equivalent table. Should keep same
   format.

   RESOLVED: evaluate SIP table format and move to that unless someone
   objects (and justifies)

#477407 - Transport BNF, ; and unclearities

   [26]477407

   Jonathan: ours requires ; before unicast and multicast

   Henning: once we insert semicolon, parameter ordering doesn't matter

   Jonathan: based on current way this is stated, you can have semicolon

   Jonathan: BNF is broken

   Sean: Server client order don't matter in implementations I'm aware of

   Colin: Example would be good

   RESOLVED: BNF will require semicolon, no mandated ordering, and
   example will be added

   Colin: should multiple entries of same type be allowed?

   Henning: any reason to prohibit?

   Jonathan: prohibiting doesn't make it more useful

   Henning: no duplication *within* an item

   Henning: we should set precedent for new params

   (Henning drops off)

new issue, to be logged

   Tom: RealPlayer uses interleaved without interleaved parameter

   Anders: we discussed at interop meeting. Client needs to specify some
   channel numbers, but server would treat those as recommendation, but
   server is free to choose new number.

   Jonathan: is same true on port numbers?

   Rob: unicast: client is the authority multicast: server is the
   authority

   NEW ISSUE: should interleave parameter require value?

   (Suggested resolution): parameter is required, and treated as a
   suggestion when it doesn't make sense as authoritative response.

   ACTION ITEM: Tom: request new bug "clarify requirement that interleave
   requires value"

477413 Transport BNF: mode

   [27]477413

   Jonathan: issue is about two sets of quotes

   Magnus: that's right

   RESOLVED: fix BNF to allow outside quotes, but not inside quotes

   Jonathan: BNF is confused on issue of comma placement as well.

   RESOLVED: fix BNF

   Sean: will proposed fix allow mode=PLAY (no quotes)

   Magnus: doesn't that change status quo?

   Jonathan: No

   Jonathan: Lots of implementations don't do this

   Joerg: whatever happens, we should have BNF that has optional quotes

   RESOLVED: quotes are optional

#477416 BNF error section 3.6 NPT

   [28]477416

   Jonathan: seems like examples are more in line with current use

   Sean: this has caused us grief because some treat as optional

   RESOLVED: require npt=, but have backwards-compatibility note

   Joerg: need to check BNF to make sure that not having npt= can work

   Joerg: make sure everyone is aware that may be confusion may result

   Joerg: BNF audit is necessary to ensure that implementations can even
   deal with no npt= possibility

References

   1. http://rtsp.org/2002/telecon/jan09.html#line11
   2. http://rtsp.org/2002/telecon/jan09.html#line23
   3. http://rtsp.org/2002/telecon/jan09.html#line38
   4. http://rtsp.org/2002/telecon/jan09.html#line45
   5. http://rtsp.org/2002/telecon/jan09.html#line62
   6. http://rtsp.org/2002/telecon/jan09.html#line66
   7. http://rtsp.org/2002/telecon/jan09.html#line94
   8. http://rtsp.org/2002/telecon/jan09.html#line128
   9. http://rtsp.org/2002/telecon/jan09.html#line154
  10. http://rtsp.org/2002/telecon/jan09.html#line164
  11. http://rtsp.org/2002/telecon/jan09.html#line194
  12. http://rtsp.org/2002/telecon/jan09.html#line210
  13. http://rtsp.org/2002/telecon/jan09.html#line236
  14. irc://irc.openprojects.net/#rtspspec
  15.
http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=448521
  16.
http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=449074
  17.
http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=461083
  18.
http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=447404
  19.
http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477407
  20.
http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477413
  21.
http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477416
  22.
http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=448521
  23.
http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=449074
  24.
http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=461083
  25.
http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=447404
  26.
http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477407
  27.
http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477413
  28.
http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477416

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