[MMUSIC] Minutes from the interim meeting in Kista, Stockholm, Sweden on 19/20 May 2008

[Joerg Ott <jo at netlab.tkk.fi>]

Folks,

while we hoped to get them into a more beautiful, but anway.
Below as the minutes from the interim meeting kindly hosted
by Ericsson in Kista.


Joerg


RTSP interim meeting minutes (May 19 & 20 in Kista, Sweden)
===========================================================

Minutes taken by Martin Stiemerling

Attendees
---------
- Magnus Westerlund
- Jan Lindquist
- Jeffrey Goldberg
- Soohong Daniel Park
- Imed Bouazizi
- Joerg Ott
- Martin Stiemerling
- Joakim Bengtsson
- Mattias Pettersson
- Thorsten Lohmar
- Xavier Marjou
- Frederic Gabir
- Jean-Francois Mule (abbreviated as JF in notes)


Minutes
-------

*Opening (Joerg Ott)
- Welcome to the first interim meeting of MMUSIC.
- progressing RTSP 2.0 spec to get it done
*Agenda bashing (Magnus)
*Intro round/gathering of further open issues
 - DVB view (Jeff Goldberg)
 - Several client control points in the same RTSP session (SETUP vs 
"control") (Jeff)
 - Scale
 - Add/remove medias to session (wrt to SVC)

*Open issues in current RTSP 2.0 Core specification
          draft-ietf-mmusic-rfc2326bis-18

- Magnus introducing the latest additions added in -18
- Joerg: Read part of PLAY_NOTIFY. Doesn't like the name of new method.
  Concerns of Media Properties.
- Discussion about PLAY_NOTIFY name and scoping of the new method.
- Thorsten: appreciated extensions, required for 3gpp. some defs are
  confusing. media or session level.
- Magnus: must be session level. needs to be clarified in text.
- Joerg: level of granularity between session and medias wrt to change
  of media
- Magnus: discussing it. how to describe scale in a real good way.
  (larger discussion about this)
- getting npt calculated in the right way.
- Joerg: getting 2 independent but interoperable implementations of
  scale.
- Jeff: two sorts of scale: speeding up and missing frames. Two
  different approaches. get standards dependent clarifications.
- Imed: and there is speed
- Magnus: preference cut out speed semantics/header
- scale will be discussed during this meeting

- Joerg: concerning media properties: allowed to carry new spec, or
  fetch it later on?
- Magnus: included and now extra need to fetch it
- Joerg: codec changes?
- Magnus: not included yet
- Thorsten: How realistic
- Magnus: personalized ads.
- discussion about how to do this in the right way?
- Idem: updating SDP when new channel is being available
- (Thorsten: missed point)
- Magnus: Reconfiguration: Mechanism to find what the client supports?
- Joerg: need to know ahead of time of what the client supports
- (discussion about h.264 configuration)
- (further discussions about usefullness)
- Joerg: reality check - do we need this
- Magnus: not part of base spec but extension.
- Thorsten: change of codec could invite people to write tools that
  automatically remove the advertisement, i.e., an ad blocker (which is
  sent with different codec).
- Idem: do we need media-properties/media-range?
- Magnus: one particular functionality and not part of other headers
- Thorsten: differences between media properties
- Magnus explaining it
- Thorsten: what does actually change.
- (discussions around the new model of media properties)
- Jeff going bad in play time must consider interactive ads, as they can
  be played only once. I.e., can be played out once but never again.
- Magnus not considered yet
- (content is time progressing and dynamic)
- JF: more parameters for the media prop fields, e.g. media rention
  could be "allowed to be played five times"
- Imed: why do we need this in RTSP and not in EPG?
- JF: not data retention but server storage. wording issue.
- JF: probabaly separate document for describing this media properties,
  as this might have added new unwanted functionality. discuss outside
  RTSP 2.0 first, included later on if agreed on.
- Idem: time shift is a new use case, need time to understand this.
- JF: need more disussion as this has been added out of the blue
- Magnus agreed to have more discussion about this
- Martin: valid concern, we need more discussion on the list about this
  topic.
- Joerg: new separate document is good but can cause too much overhead.
  new to avoid that.
- JF: new document: what is important for the client to know about the
  server? what are the data models?

Going through the issue tracker :
(see also https://sourceforge.net/tracker/?group_id=23194; numbers are 
referring to request ID in issue tracker)

- 1957820: Messge body vs Entity
  - JF: sip is message body, http is entity body.
  - JF: go for message body and add section describing that it is entity
    header in http

- 1944050: Need to update Changes Section
  - Mattias: What has changed needs to be latest.
  - Magnus: changes to rfc 2326.
  - Jeff: list main differences to RTSP 1.0.
  - JF: reads small nits. don't know what in 2.0 makes it backwards
    incompatible.

- 1944044: Add Seek-Style to PLAY method text
  - Imed: Can the client now what he wants?
  - JF: Server needs to support all of them
  - Magnus: no server response with what he can do.
  - JF making one of the choices mandatory?

- 1906850: Adding a media stream when in PLAY state is not specified
  - Magnus: core spec is not specifing how to add or remove media in
    play state. 3gpp sa4 people should note this!
  - Imed: 3gpp defined adding media without pausing

- 1900879: Missing handling rules for unknown transport parameters
  - Joerg: evidence that proposal works.

- 1898828: No default rules for proxies regarding unknown headers
  - Magnus: ignore unknown headers
  - Idem: What do proxies with new methods?
  - Magnus/JF: good question not solved.
  - Jeff: implementation ignores new methods.
  - Magnus: version numbering for proxies
  - Imed: should have statement about proxy handling for unkown methods
  - Mattias: Whether media goes through proxy or not is not stated in
    the spec
  - Magnus: both use cases are valid. Open Internet requires that media
    also goes through proxy, otherwise DoS prevention stops it (media
    delivery address unequal to signalling address)

-  1789227: Media congestion control requirments
  - Joerg: Why is this an RTSP issue?
  - Magnus: basic requirement to the protocol to make it working safely.
  - Magnus: can use RTCP for congestion control
  - Joerg: Strong statement towards must implement RTCP
  - Imed: Does it help?
  - Magnus: At least decent hand-waiving
  - JF: not part of RTSP but should give pointer to media transport
  - JF: some organisiations do not even RTP
  - Magnus: applicable only for RTP
  - JF: just raising the question if this belongs here.
  - JF: Linked to speed header discussion. If use speed you need space
    on wire
  - Magnus: If use speed, need bandwidth. Speed also used to fill
    buffers
  - Imed: other uses cases for speed other filling buffers
  - Magnus: could be used for "scaling".
  - JF: large discussions on the list about speed. In some cases
    bandwidth issues, in some cases it just works. Some people seem to
    have applications for this.
  - Magnus: various interactions between scale and speed
  - Joerg: must be documented
  - Imed: if we properly define scale, the are probably no interactions
  - Magnus: disagreement. still lot of interactions
  - Magnus: someone needs to write-up a strawman proposal to get this
    discussion started
  - JF: Meeting minutes IETF70 (Dec 2007). Henning said important
    feature
  - JF: Is this actually in or out of scope
  - Magnus: up to the chairs to drive this discussion
  - JF: reading email thread and Henning's comments: people are
    interested in that. Willing to bring this to the WG
  - Magnus: Lot of work, can hold up core spec to get ready
  - Martin: people interesed should provide text proposal
  - Idem: but it is in the sepc
  - Magnus: it is not well defined.
  - JF: rewrite text with a more crisp text, e.g., doubled speed results
    in double speed on wire.
  - ACTION POINT for Martin: provide text for that!
  - JF: volunteered for reviewing text and editing it.

- 1715645: Content type capabilites for SET/GET Parameter methods
  - (lost some of the discussions)
  - Joerg: don't have a model about what the server is, what data it
    stores, etc
  - Magnus: SET_PARAMETERS used for any weird thing immaginable
  - JF: define packages per media for GET/SET. Core spec should specify
    the basic things you get for a session?
  - Magnus: do we have any such parameter?
  - Magnus: seek-style, speed
  - JF: could you ask a server which error response codes it supports?
    useful?
  - Magnus: probably not?
  - JF: use this as management method?
  - Magnus: more done by OPTION which also can be scoped.
  - Magnus: SET_PARAMETER are used in some deployments for uploading
    link characteristics, QoE from client to server.
  - Joakim: Method are used by Real and Windows Media
  - Mattias: Have SET_PARAMETER with body
  - Joakim: Windows Media uses GET for obtaining statistics in the body
  - Magnus: Clear out the model for SET_PARAMETER
  - Martin: document usage in email or draft
  - Imed: define feature for your usage
  - Magnus: feature tags in OPTIONs the way for the server.
  - JF: minimum: clarify text
  - Magnus: define set of parameters and how they are carried
  - JF: what is the scoped agreed to be covered in the core?
  - Magnus: use feature tags to check beforehand what is supported

- 1701605: Need to clarify text on sendrecv, recvonly and sendonly
  - has been fixed in the past
  - JF: text still needs fixing on page 223
  - JF: mixing of MUST or SHALL makes it hard to read
  - JF: take editing for this.

- 1701604: Multicast use case and its need for extensions.
  - Jeff: DVB could use live multicast. live could be stream that is
    paused and you good back
  - Magnus: not using multicast
  - Jeff: using multicast to join stream, go to unicast when pushing
    pause.
  - Magnus: Section 3.5 describes are rather weak use case for RTSP
  - Imed: Receive unicast and multicast in the same session
    simultaneously?
  - Magnus: Fully possible, but comes down to session description.

- 1701457: The "Speed" header
  - see above

- 1701439: Concerns with TLS handling for proxies
  - Magnus: partly fixed.
  - Magnus: certificate-based client authentication
  - Jeff: concerns about general TLS performance
  - Magnus: missing: communicate cipher preferences

- 1701434: Document rational behind timer values
  - Joerg: SIP is now dealing with application level congestions.
    When adding proxies it might useful to think about timeouts.
  - Magnus: When sending about TCP, send only once.
  - Joerg: Can proxies switch to UDP
  - Magnus: no.
  - Mattias: how many timer values can be configured?
  - Magnus: (exploring some vaules)

- other issues
  - Mattias: RTSP interleaved. what if there connection problems and the
    server has build up a lot outgoing data.
  - Magnus: implementation problem.
  - JF: IPv6 explicitly supported. what does client/server respond if
    there is an IP version mismatch
  - Magnus: e.g. if connected by v6 but request deliver to IPv4.
  - (missed some part here)
  - Mattias: backwards comatibilty.
  - Magnus: risk one round-trip time in the beginning
  - Mattias: no need for OPTIONs, should be recommended to try out
  - Xavier: No ways of adding media - intention to leave this that way
  - Magnus: always the question about what belongs to the core
    specification
  - Thorsten: How does this work with SVC. Do you add RTP flows?
  - Thorsten: Related to fast channel switching in 3gpp. but defined
    only in RTSP 1.0
  - Magnus: topic needs more discussion as there are multiple ways of
    doing this.


*RTSP NAT traversal
- Jeff: two cases: NAT forgets all bindings, client needs to contact
  server. Second, source address of server might change, i.e. NAT
  bindings will break.
- Jeff: interesting thing but no need to fix: message integrity checking
  has scalability problem.
- Magnus: STUN problem
- Jeff: explaining an issue on the whiteboard related to separated
  master VoD server and Cache VoD
- JF: Unclear what the issue is.
- Jeff: effectively two RTSP sessions, one for session control and one
  for playback.
- JF: Don't understand use case. Document the use case in an Internet
  draft.
- Magnus: Need good motivation why split is necessary.

* Agenda bashing for the next day.

** Tuesday

9-0930 speed/scale discussions
- list of issues to be discussed:
  - bit-rate
  - frame rate/frame skip
  - "recordability"
  - content rate vs display rate
  - scale = 0?
  - external buffer management
  - interaction between bit rate adaptation and speed

- difference between speed and clear is unclear, getting a definition
  first
- Definition of speed:
  Amount of playable content per unit of delivery time. Without removing
  frames or other media units. No quality ensurance. RTP: No change of
  timestamp to content mapping. Speed is not bandwidth.
- Definition of scale:
  Rate of content time over display time. Content modifications to adopt
  to rate. RTP: timestamp rate rescaled accoding to value.
- (see picture of scale vs speed table from whiteboard)
- no clear view how they are interacting and how single headers are
  really working.
- Joerg: speed does not allow content modification but delivers at
  desires rate (if available)
- Magnus: speed does allow content modification if desired delivery rate
  cannot be fulfilled.
- (see picture from JF)
- JF: changing quality is actually a third dimension to speed and scale
  but not part of speed.
- Joerg: JF picture works as long bandwidth is enough, but not for
  congestion.
- JF: Need an I-D about quality adapation to discuss whether this
  belongs to RTSP core or if it is an extension
- Jeff: Quality thing is apart from speed/scale issue.
- Magnus/JF: No, as codecs may change their bandwidth consumption
  automatically.
- need to have a write-up to have a flag indicating:
  - whether server can exactly deliver the requested speed value
  - or whether the server can deliver up to the requested speed value
    but it is not guaranteed.

1120-12 Discussion on received LS replies regarding RTSP
*ITU
- ACTION POINT: drafting a response to ITU should contain reasoning
  why RTSP 2.0 is incompatible to RTSP 1.0; listing the main reasons why
  it is incompatible. This should be written first in the draft and
  referenced later on in the response. Chair's are in charge of drafting
  response to this liaison statement

* OpenIPTV Forum
- refers also to later discussion about SIP/RTSP, i.e., using RTSP w/o 
SETUP but go first w/ PLAY instead. Decomposition of conrol and setup.

* ETSI TISPAN WG3
- similar to OpenIPTV Forum and SIP/RTSP discussions

* Cablelabs
- JF: I-D draft-bergren-mmusic-rtsp-ermi-extensions describing what
(https://datatracker.ietf.org/drafts/draft-bergren-mmusic-rtsp-ermi-extensions/)
  extensions Cablelabs considers missing in the RTSP specification.
- Magnus: possibly write-up in draft and register in registries what is
  needed.
- discussing some features

* 3GPP SA4
- Thorsten elaborating on 3GPP's extensions
  - Fast content switching (including adding/removing medias)
  - FLUTE session setup with RTSP
  - Quality of Experience signalling
  - Started work on time shifting
  - not listed in this LS: IMS, PSS issues.
  - (there is a SA4 workshop on mobile TV and IMS after the RTSP interm,
    also touching SIP/RTSP interaction).
	
(after lunch starting 1:20pm)
	
* SIP/RTSP convergence (Jonne Lindquist)
- Martin: Rendezvous issue but not SIP necessarily
- Jonne: TISPAN probably doesn't want to use RTSP's model as defined
  now. but offer/answer
- Magnus/Jonne: Offer/Answer discussions
- Magnus: no clear diff between configuration, preferences, and
  capabilities
- JF question to QoS-guarantees use case: Why do you need RTSP at all?
- Magnus: Need trick play, etc ouf of RTSP.
- (Voice/video mailbox) Joerg: sounds like rendezvous case. Would use
  webpages for access the voice messages. Manangement of e.g. home video
  collection is orthogonal issue.
- Thomas: If selected a thing it is pretty much RTSP.
- Jonne: Likes that management shouldn't be done through RTSP.
- Discussing Server to Client teardown mechanism.
- Discussing about SIP/RTSP, i.e., the resulting split in control and
  setup
  - Joerg: could use transport spec of rtsp
  - JF: establish SIP dialog to control RTSP session.
  - JF: SIP the only mechanism to call and identify protocol to be used
    by m line. discussed earlier and got pushed back on this.
- JF: questioning the way taken in this matter
- discussion about which way of SIP/RTSP convergence is the best
  and the way how to proceed in this matter.
- Joerg: there are too many assumptions made why SIP is usefull here
  without figuring out the real issues to be solved.
- Frederic: But there is IMS
- Jeff: separate between IMS as system and SIP as protocol.
- discussing how to progress on this topic in the IETF.
- JF: suggestion from Joerg and JF: concentrate on one problem,
  SIP+RTSP. Use case description, put requirements on what mechanisms
  are needed to do what this should be doing. What documents need to be
  written to address each issue raised.

*3GPP SA4 Extensions to RTSP (Thorsten Lohmar)
- slides express Thorsten's view and are not necessarily 3GPP's view
- Fast content switching and startup
- Needs feedback from MMUSIC

* Talk of Soohong Daniel Park

** Closing the meeting at 5pm.


_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic