CLUE, 82th IETF, Taipei, Taiwan
Date: Monday, November 14, 2011
Location: Taipei, Taiwan, Room 201ABC
Chairs: Mary Barnes, Paul Kyzivat
Note Takers: Stephen Botzko, Jean Mahoney
Minutes Editor: Paul Kyzivat
Jabber Scribes: Jonathan Lennox
Audio playback: http://www.ietf.org/audio/ietf82/ietf82-201abc-20111115-0855-am.mp3
Meetecho recording: http://ietf82.conf.meetecho.com/index.php/Recorded_Sessions
Agenda bash, Status and items of interest
Presenter: Mary Barnes
Slides: http://tools.ietf.org/agenda/82/slides/clue-5.pdf
Agenda bash:
No discussion, ok
Way Forward:
Adhoc with RTCWEB (Thursday, lunchtime)
Interim F2F in Andover proposed 15-16 Feb (17th added to the doodle poll)
Issue Tracker:
Will use the tool, but limited to document authors, editors. WG chairs to keep issue resolution organized.
Use Cases
Presenter: Roni Even
Slides: http://tools.ietf.org/agenda/82/slides/clue-0.pdf
No update since last meeting
Summary of action items:
· Jonathan Lennox to post Source Selection Use Case on List (by 11/28)
Requirements
Presenter: Allyn Romanow
Slides: http://tools.ietf.org/agenda/82/slides/clue-1.pdf
Text for a new REQMT-16 was proposed to address need for dynamic
changes to attributes.
It was accepted by the group.
Text for new REQMTs 1c, 1d, 2d, 2e was proposed to address need to
support three dimensions.
These were accepted by the group.
Cullen Jennings asked if depth of field was included.
Stephen Botzko replied that it is covered by the start and end values.
(Later discussion in Framework indicates disagreement on need for volume/depth of field.)
Multiview (same field of view from multiple camera angles):
Authors' view is that it is covered by 3 Dimensions requirements.
Roni Even - will people understand that they need to supply the capture point to support this feature?
Jonathan Lennox (to Roni) - is there a different mechanism being
proposed?
Agreement is that there is not.
Authors' recommendation accepted.
Framework
Presenters: Mark Duckworth, Brian Baldino
Slides: http://tools.ietf.org/agenda/82/slides/clue-2.pdf
http://tools.ietf.org/agenda/82/slides/clue-6.pdf
Changes agreed to at interim meeting were presented.
Summary of action items:
· Revisit charter to ensure requirements for source selection are in scope.
· Roni Even to post use cases for selecting composed captures, on the mailing list.
· Steven Wenger to make proposal for describing composed captures, by mid December.
Coordinate System (Brian Baldino)
Cullen Jennings - doesn't think there is a good reason to have two coordinate systems
Mark Duckworth - really is only one nuanced coordinate system.
Jonathan Lennox - audience in the round is not describable.
Marshall Eubanks - Z has switched from interim meeting
Marshall Eubanks - What does Z mean?
Brian - smaller Z is in front of larger Z.
Cullen Jennings - need depth of field? (mismatch with requirements discussion)
Jonathan Lennox - plane of interest for lifesize display is ok.
Mark Duckworth - virtual (non-mm) units are still proportional to each other (1:2 is same distance as 2:3 in each dimension).
Marshall Eubanks - how does MCU rationalize virtual coordinates?
Roni Even - examples should include mm scaling
Roni Even - may need a definition of plane of interest.
Source Selection
Ability for consumer to select a particular source:
Roni Even - Point-to-Point and Multipoint are needed
Mark Duckworth - agrees, though point-to-point already covered.
Ability to advertise every media capture:
Charles Eckel - agrees this should be allowed, though in large scale meetings there is a need for filtering.
Stephan Wenger - concurs
Cullen Jennings - Other wgs have worked on this problem. How will you use it?
Mary Barnes - That's why we want an adhoc.
Relationship to draft-westerland-dispatch-stream-selection:
Stephan Wenger - is Source Selection in scope?
Jonathan Lennox - requests for specific captures and sources are tightly related
Stephen Botzko - concurs, sees need to gather requirements at least.
Magnus Westerland - agrees that CLUE should provide requirements
Action (???) to revisit charter to make sure it is covered.
Consensus - general agreement that work is needed.
Describing Composed Captures:
Is ssrc/csrc sufficient?
Do we need additional provider->consumer message
Stephen Wenger - ssrc/csrc is wishful thinking, though may be desirable
Jonathan Lennox - is some information in the RTP draft, thinks it can be extended to multipoint
Roni Even - not necessarily a multipoint-only feature, doesn't think that features in existing MCUs regarding ssrc/csrc are relevant.
Allyn Romanow - description of composed capture (if needed) does have impact on framework.
Roni Even - agrees that this is different from RTP draft
Mary Barnes, Mark Duckworth - is this in scope?
Disagreement on this
Action - Stephan Wenger to make proposal by mid December.
Selecting Composed Captures:
Options-
· do nothing
· attempt to define a few specific policies
Charles Eckel - "hints" in prev. framework draft may be sufficient.
Jonathan Lennox - do we have details on policies?
Stephen Botzko - lots of different conference/composition policies, very difficult to structure this information meaningfully.
Allyn Romanow - agrees this is difficult, would rather postpone this
Roni Even - sees distinction between requesting and selecting
Mary Barnes - "Policy" word is scary, XCON struggled with a similar issue.
Action - Roni Even to provide use cases on list for discussion.
Conclusion: there is agreement that source selection work needs to continue, at least as requirements. Actual mechanism might be handed off to another group.
Options for Transport
Presenters: Marshall Eubanks
Slides: http://tools.ietf.org/agenda/82/slides/clue-4.pdf
Summary of action items:
· no consensus calls in WG for anything related to transport.
offer/answer vs three-trip exchange discussion:
What's in the clue handshake and what exchanged during the conference?
Need two stage negotiation.
How do we support clue exchange? Two options:
Clue stream as a SIP negotiated med stream
Charles Eckel - asked for clarification.
Marshall Eubanks - calls can be torn down and set up.
?? - framework draft has exchange:
· consumer advertises capabilities to producer
· producer adver…
· the exhcange is not an offer answer.
Cullen Jennings - why is offer/answer insufficient?
?? - confounding OA with SDP, why throw out the SDP baby?
?? - SDP is out-dated, designed to make a telephone ring.
Cullen Jennings - needs to describe the messages first.
Jonathan Lennox - information in framework is cleanly separated from SDP, and is doing something at different layer.
Marshall Eubanks - this info seems more similar to the xcon/mediacontrol, which also is sent on a different mechanism than SDP.
Various - RTCWEB transport may be worth looking at.
Mary Barnes - there are charts from the interim meeting.
Gonzalo Camarillo - these slides are confusing. Proposals - piggyback on SIP message, or use media stream. Need to make decision.
?? - Stick close to what we've been doing.
Cullen Jennings - you're talking about the pipe. The framework doc is pathetic, doesn't have semantic information.
Hadriel Kaplan - two problems. The problem with OA is that couldn't deal with media lines - they aren't equal. Requires a second round trip. Then SDP metadata gets exchanged several times during session. I'm opposed to using a different format for the second round. However, if it's not related to media, then use what you want.
Jonathan Lennox – The framework separates data that is not SDP related. It’s hard to jam into SDP. It makes sense to separate from SDP. How do you transport? Different discussion.
Marshall Eubanks - this is a different layer from SDP.
Roni Even - there's a problem with the presentation. Its semantic info is not related to codec info. XCOM or Media control has these problems.
Mary Barnes - it's application data, not session data.
?? - Similarities to siprec, please take a look.
Cullen Jennings - Framework doesn't have the example of capturing someone walking around. Need to get the framework solid before doing this.
Options:
· Set up clue media stream through SIP with OA
Options for the media stream:
· some agreement on using UDP - NATs and firewalls don't let anything else through. Problems – unreliable, fragmentation issues.
· some sense that TCP is not the way to do it.
Magnus Westerlund ?? - We are considering SCTP over UDP. Implementations already exist.
Justin Uberti ?? - Google - we have an implementation of HTTPS ? over UDP
There was some interest that wg should devise BFCP like handshake.
Content Representation:
Use XML? Does it exceed the MTU - yes, especially for multipoint. Issue of congestion control.
Weak consensus from interim: Need 2 stage negotiation - first SIP then CLUE
Two options for transport - clue stream as SIP-negotiated media stream
Hadriel Kaplan - bizzare that we are picking transport before knowing what we'll transport. Need to know what's in the data, how many messages are sent?
Marshall - use cases that identify bandwidth, number, and size of messages. If you do this in media plane, don't want to create a handshake protocol that different for RTCWEB and SIPrec.
Stephan - We don't have the bits but know what we want to transmit and how often. The document is a supporting document how to get the what's defined in the framework over the wire. Need to get the nuts and bolts out to discuss.
Cullen Jennings - consensus?
Mary Barnes - no consensus calls in WG for anything related to transport.
RTP Usage
Presenters: Jonathan Lennox, Allyn Romanow
Slides: http://tools.ietf.org/agenda/82/slides/clue-4.pdf
How should clue use RTP, focusing on one area.
Source multiplexing - telepresence has lots of source points. Sessions have asymmetric number of sources.
Recommendation - source multiplexing - send all sources over single stream.
Magnus Westerlund - Source multiplexing is right thing to do, but objects to single RTP sources.
Jonathan Lennox - high level topology - central box sending things out.
Roni Even - I didn't hear the requirement for multiplexing. Don't think it's right direction. Haven't heard problems with ports being used.
Cullen Jennings - why are we talking about it here?
Jonathan Lennox - covered on a later slide. May need multiple RTP sessions - different transport characteristics (QOS ex). Complications: will be discussed in avtcore this afternoon. Clue specific complications: need to know why you're receiving a source before stream decoding starts.
Roni Even - is there a difference for knowing for ssrc or using UDP to multiplex?
Jonathan Lennox - still need that mapping, would be more static.
Charles Eckel - To multiplex ways with same media type - if you have lots of main video - multiplex that. Content sharing multiplex separately.
Jonathan Lennox - I say don't separate, but Magnus would say yes. How soon do you know that?
Charles Eckel - framework doc talks about capture sets - do you envision multiple purposes?
Jonathan Lennox - Stream means different things for RTP and SDP. You need low level descriptions. Getting into this in the avtcore wg.
Magnus Westerlund - topology matters for using RTP.
Jonathan Lennox - LC - LR CR -> LR, lose decoding state.
Demultiplexing RTP streams in the Same Session:
Case to consider - "Infinite Sources"
· SSRC
· MuxID
· Hybrid* (proposing investigation)
Issue with SSRC is that it changes without notice. And receivers need to map sources to decoder hardware. Therefore you need metadata to map captures to SSRCs, and ensure the mapping is known before the capture is received.
Changes to the SSRC
add metadata to link SSRC to clue capture
store lookup data
timing requirements - killer
Where to put the metadata?
A clue message - reliable but the reliability can cause large delays
RTCP - can arrive early (missed the disadvantaged).
How about adding a tag media packet with muxID - RTP header extension
· benefit is no latency
· disadvantage is potential loss of authentication (if MuxID is applied in a middlebox).
Hybrid Scheme -
· Only signal muxID on the RTP header extension of the "first" frame of media
· Adds complexity in demuxing
· Needs more investigation.
Colin Perkins - maybe put the SDES record into an RTP header extension (in addition to putting it in RTCP).
Roni Even - MuxID is likely needed even w/o RTP multiplexing
Magnus Westerland - maybe should consider the RTP mixer model (SSRC//CSRC). Need to talk about the RTP model.
Cullen Jennings - Not clear why SSRC isn't good enough. Need a clearer problem description.
Allyn Romanow - SSRC changes when the MCU reallocates.
?? - segment switching - those are different sources.
Jonathan Lennox - topology has to be described much better.
Charles Eckel - same question about ssrc is not sufficient - explain that in the draft.
Joint CLUE/RTCWEB ad hoc meeting
Date: Thursday, November 17, 2011
Location: Taipei, Taiwan
Chairs: Mary Barnes, Ted Hardie
Note Taker: Paul Kyzivat
Minutes Editor: Paul Kyzivat
Jabber Scribe: Marshall Eubanks
Recorded playback: http://www.ietf.org/audio/ietf82/ietf82-101d-20111118-1111-am.mp3
( sorry No Meetecho L )
Summary of action items:
· RTCWEB should have a use case involving a CCLUE endpoint.
· CLUE should have a use case for an RTCWEB client.
· CLUE should submit or socialize the metadata with W3C.
Agenda bash, Status and items of interest
Presenter: Mary Barnes, Ted Hardie
Slides: http://www.ietf.org/proceedings/82/slides/clue-9.pptx
WebRTC Overview
Presenter: Cullen Jennings
Slides: http://www.ietf.org/proceedings/82/slides/clue-7.pdf
Points of overlap:
Way to send RTP on single or small number of flows.
Negotiate video codec parameters without using SDP.
Hadriel objected to some of the things presented – that not settled. But Ted and Fluffy emphasized this is just overview.
CLUE Overview
Presenters: Allyn Romanow, Mary Barnes
Slides: http://www.ietf.org/proceedings/82/slides/clue-8.pptx
Allyn gave overview of CLUE – Mary described functional model picture
Allyn said that an important issue is where we are transmitting the clue data.
Cullen asked what “capabilities” are and how they differ from “advertisements”. Allyn responded that capabilities might be a bad word, and she preferred “information”. Cullen said he found this presentation very unilluminating.
CLUE & RTCWEB Common functionaltiy
Presenters: Mary Barnes
Slides:
Mary presented a list of building block rfcs.
Christer suggested adding the “bundle” RFC to be presented in mmusic tomorrow.
Magnus took issue with details of chart Mary presented on multiplexing.
Cullen objected to arguing the details here.
Ted argued in favor of discussing overlap of requirements.
Roni explained limited agreement to date in clue on some multiplexing.
Magnus explained alternatives again. He objected to listing specific drafts because they aren’t necessarily the right ones.
Hadriel stated a requirement for a clue system to talk to a browser. But several clue people stated there is no such requirement.
Hadriel asked if clue has a requirement to use the same RTP session for multiple streams, vs. using the same 5-tuple. Jonathan L said he had such a requirement, but the group hasn’t yet.
Mathew Kaufman said we should sync requirements between the groups and then take to group to get them solved, rather than doing independently.
Ted restated that. [ed: but not captured.]
Roni said we may have different requirements but that a common infrastructure might satisfy both.
Magnus said this meeting is premature before clue has requirements. He asked how clue use cases intersect with rtcweb use cases.
Cullen was concerned about something. [ed: but not captured]
Roni said the sdp stuff isn’t the point, it’s the other info, which might be sent some way we haven’t decided.
Hadriel talked about data channel in rtcweb and possibility that it might serve for the clue data exchange channel.
Hadriel stated his use case that you can connect to a telepresence system from a browser.
Jonathan Lenox said if clue does its data channel in the media plane, then clue and rtcweb could use hopefully use the same one.
Cullen would like something like webex on an ipad for telepresence calls.
Roni stated we have a requirement to interop with existing sip systems. This could work by having the clue data channel negotiated and optional.
Christer agreed with Hadriel and Cullen, but that we only have rqmt for clue specifics but generic call.
Hadriel said something about supporting the clue data in javascript.
Steve Botzko – said we have requirement for handheld devices supporting clue, but doesn’t mention rtcweb.
Harold said if its not possible to build a clue client on top of rtcweb there is something wrong with one or both of them.
Marshal – talked about extremes, low end system at one end and high end telepresence system at other end. Need a lot of extra stuff for the high end. RTCWEB ought to give us feedback on what we need to do to make it work with rtcweb.
Ted mentioned that maybe some of what clue is doing ought to go to webrtc rather than rtcweb. Maybe we need another liaison for that.
Jonathan said relationships between cameras and microphones might need to go to W3C so that it can get to a browser and be used by a clue client.
Andy H restated what Harold said.
Raw CLUE Meeting Notes: Stephen Botzko
Clue Meeting opens at 9:00
Primary Note taker - Stephen Botzko
Note well...
Agenda presented
"Way Forward"
Adhoc with RTCWEB
Interim F2F in Andover proposed 14-15 Feb? (16th added to the doodle poll)
"Issue Tracker"
will use the tool, but limited to document authors, editors, WG chairs to keep issue resolution organized.
Use Cases (Roni Even)
No update since last meeting
Action - Jonathan Lennox to post Source Selection Use Case on List (by 11/28)
Requirements (Allyn Romanow)
Requirement on dynamic changes accepted, will be added to document
Requirement on 3 dimensions (extent)
Cullen Jennings - Depth of field included?
Stephen Botzko - Yes
<Later discussion in Framework indicates disagreement on need for volume/depth of field>
Accepted
Requirement on 3 dimensions (point of capture)
Accepted
Multiview (same field of view from multiple camera angles)
Authors' view is that it is covered by 3 Dimensions requirements.
Roni Even-will people understand that they need to supply the capture point to support this feature?
Jonathan Lennox (to Roni) is there a different mechanism being proposed?
agreement is that there is not.
Authors' recomendation accepted.
Framework (Mark Duckworth, Brian Baldino)
changes agreed to at interim meeting were presented.
Coordinate System (Brian Baldino)
Cullen Jennings - doesn't think there is a good reason to have two coordinate systems
Mark Duckworth - really is only one nuanced coordinate system.
Jonathan Lennox - audience in the round is not describable.
Marshall Eubanks - Z has switched from interim meeting
Marshall Eubanks - What does Z mean?
Brian - smaller Z is in front of larger Z.
Cullen Jennings - need depth of field? (mismatch with requirements discussion)
Jonathan Lennox - plane of interest for lifesize display is ok.
Mark Duckworth - virtual (non-mm) units are still proportional to each other (1:2 is same distance as 2:3 in each dimension).
Marshall Eubanks - how does MCU rationalize virtual coordinates?
Roni Even - examples should include mm scaling
Roni Even - may need a definition of plane of interest.
'.
Source Selectiop
ability feor consumer to select a particular source
Roni Even - Point-to-Point and Multipoint are needed
Mark Duckworth - agrees, though point-to-point already covered.
ability to advertise every media capture
Charles Eckel - agrees this should be allowed, though in large scale meetings there is a need for filtering.
Stephan Wenger - concurs
Relationship to draft-westerland-dispatch-stream-selection
Stephan Wenger - is Source Selection in scope?
Jonathan Lennox - requests for specific captures and sources are tightly related
Stephen Botzko - concurs, sees need to gather requirements at least.
Magnus Westerland - agrees that CLUE should provide requirements
Action (???) to revisit charter to make sure it is covered.
Consensus - general agreement that work is needed.
Describing Composed Captures
Is ssrc/csrc sufficient?
Do we need additional provider->consumer message
Stephen Wenger - ssrc/csrc is wishful thinking, though may be desirable
Jonathan Lennox - is some information in the RTP draft, thinks it can be extended to multipoint
Roni Even - not necessarily a multipoint-only feature, doesn't think that features in existing mcus regarding ssrc/csrc are relevant.
Allyn Romanow - description of composed capture [if needed) does have impact on framework.
Roni Even - agrees that this is different from RTP draft
Mary Barnes, Mark Duckworth - is this in scope?
Disagreement on this
Action - Stephan Wenger to make proposal by mid December.
Selecting Composed Captures
Options-
do nothing
attempt to define a few specific policies
Charles Eckel - "hints" in prev. framework draft may be sufficient.
Jonathan Lennox - do we have details on policies?
Stephen Botzko - lots of different conference/composition policies, very difficult to structure this information meaningfully.
Allyn Romanow - agrees this is difficult, would rather postpone this
Roni Even - sees distinction between requesting and selecting
Action - Roni Even to provide use cases on list for discussion.
Mary Barnes - "Policy" word is scary, XCON struggled with a similar issue.
Options for Transport (Marshall Eubanks)
offer/answer vs three-trip exchange dicussion
Cullen Jennings - why is offer/answer insufficient?
Cullen Jennings - needs to describe the messages first.
Jonathan Lennox - information in framework is cleanly separated from SDP, and is doing something at different layer.
Marshall Eubanks - this info seems more similar to the xcon/mediacontrol, which also is sent on a different mechanism than SDP.
Various - RTCWEB transport may be worth looking at.
Mary Barnes - no consensus calls in WG for anything related to transport.
Hadriel Kaplan - details of message content drives transport decisions
RTP Usage (Jonathan Lennox,)
Source Multiplexing
Roni Even - is there a need for source multiplexing
Clue-specific Complications
When you receive a source you need to know why you are are receiving it.
Demultiplexing RTP streams in the Same Session (Allyn Romanow)
Case to consider - "Infinite Sources"
SSRC
MuxID
Hybrid* (proposing investigation)
Issue with SSRC is that it changes without notice. And receivers need to map sources to decoder hardware. Therefore you need metadata to map captures to SSRCs, and ensure the mapping is known before the capture is received.
Mapping could be communicated either in a CLUE message or RTCP. Both suffer from latency
MuxID - RTP header extension
benefit is no latency
disadvantage is potential loss of authentication (if MuxID is applied in a middlebox).
Hybrid Scheme -
Only signal muxID on the RTP header extension of the "first" frame of media
Needs more investigation.
Colin Perkins - maybe use the RTP header extension to cross-reference a new SDES
Roni Even - MuxID is likely needed even w/o RTP multiplexing
Magnus Westerland - maybe should consider the RTP mixer model (SSRC//CSRC). Need to talk about the RTP model.
Cullen Jennings - Not clear why SSRC isn't good enough. Need a clearer problem description.
Raw CLUE Meeting Notes: Jean Mahoney
Clue minutes
Asked for minute takers - a few using the new minutes tool (http://tools.ietf.org/wg/clue/minutes) Marshall and Steve Botzko, and one offline (Jean)
= Chairs: Agenda and Status =
Note well
Agenda
Proposed an adhoc with RTCWEB
- overview of RTCWEB and CLUE
Need review of WG docs
Interim meetings - Mary will sent a note to the mail-list with doodle poll.
Issue tracker - suggested that the group use it, with restrictions
Use it for worker docs
Restrict the addition of the issues to chairs and authors/editors
comment/resolution on the list
= Roni Even, Use Cases: draft-ietf-clue-telepresence-use-cases =
status - no updates since last meeting
comments on the list that require doc updates (clarifications, editorial), no new use cases.
Revision expected in beginning 2012
Doc will wait for framework
Jonathan Lennox - there was a discussion at the interim and a use case was identified, hasn't sent a use case to the list.
Mary - get it to the list in 2 weeks.
= Allyn Romanow, Requirements: draft-ietf-clue-telepresence-requirements =
3-4 changes to discuss
the doc needed to clarify that the updates can be dynamic (attributes can change during the conference) issues worked out on mailing list.
Add the following requirement (discussed on list) solution MUST support a means to identify the extent of indiv videa captires in 3D - point and area
Fluffy - Do you include depth of field? If you want to capture it, need to.
Steve - includes the volume, so includes depth of field.
Identify origin of each capture of indiv audio captures in 3d. No discussion.
Multiview issue - clarify what was meant by multiview - there are 3 types, but only one relevant for this group - discussed in use case doc. Same object from different viewpoints. This is captured with the other two reqs discussed previously. Thus don't need an explicit req.
Roni - this req causes the support the origin and coordinates of object. That should be reflected in the framework. If you don't say multiview is required, then implementers will think origin is optional.
Allyn - the way the req - the solution MUST support a means of doing it.
Lennox - I can see doing multiview without specific camera positions.
?? - can talk about this and add to examples. Support multiview with and without specific geometry. Don't need to support specific geometry.
?? Is there a way of specifying multiview without capture point - you can't
Allyn - not sensing consensus. Multiple viewpoints on the same.
Mary - Roni, can you send?
Roni - I'm ok
Mary - there is no issue now?
Allyn - OK
= Mark Duckworth, Andy Pepperell, Brian Baldino Framework: draft-ietf-clue-framework =
Mark - slide summarizes changes to draft:
- Has become a working group draft.
- Improved overview in sec 5.
- A media capture is more broad that just camera or mic capture.
- New: attributes of a capture set, better to describe distance here
and area of entire scene.
- Combined attributes for audio/video that can apply to any media type.
- Clarified number of capture sets - can have more than one.
Provided examples. Applies to any media.
- Clarified left/right terms. Introduced new terms
- New: extensibility section.
== List of major issues (from interim meeting and from framework doc) ==
=== Coordinate system ===
Source selection - need the ability for consumer to select a particular source from a multipoint conference.
Roni - selecting source in point-to-point is important
Mark - agree but need to work on scalability. It will get very difficult for large conference
Do we need the ability to advertise every media capture - not sure.
Does the middlebox capture set becomes the union of all the other capture sets - not sure.
There's a draft in dispatch that is related.
Charles Eckel - if you wan't to advertise everything, that's ok. I don't think we want the framework to restrict it.
Mark - The framework does allow a middlebox to advertise as much as it wants.
Stephan - Syntax should allow that sets to be distributed to any other box in the system. The lack of the source is not in the scope of work.
Fluffy - Other wgs have worked on this problem. How will you use it?
Mary - That's why we want an adhoc.
Roni - Selecting and using info is in the issue - is it provided to consumer, can the consumer ask for it from the provider?
Mark - related but about selecting a algorthm, not specific.
Roni - Difference between providing to consumer and the ability to chose what is more active and create views from what's there. They're separate issues. Not sure scope of work - agree with Stephan.
Mark - included in scope is consumer selecting from provider.
Lennox - want to see the left camera or the loudest mic, they are the same request and not unrelated mechanisms.
Mark - current loudest talk is a policy. The other issue is selecting policy.
Lennox - having a different protocol for replicating the info is unnatural to me.
Steve? - these requests are tightly coupled. Clue needs to establish requests for soource selection.
Roni - There's a difference between selection modes. The way providers provide the selection. It's more info than selecting a capture set. The consumer wants a subset of the capture set. Provider offers three views provided together. Comsumer wants the left one.
Mark - framework supports it.
Roni - tied to some policy - active speaker part, not provided. Need to better describe it.
Stephan Wenger - if we go in the direction of switching on/off media stream, we're out of charter. I'm in support of the work though.
Magnus - clue needs to create requirements
Fluffy - I support changing the charter, but we're outside the scope.
Allyn - what's the takeaway? I think authors need to write something about what needs to be done.
Stephen - is there an action to revisit charter?
Mary - discuss on list
Stephan - source selection needs to procede?
Mark - yes, but not clear which wg. Requirements can be done here.
Allyn - ???
What needs to be described about describing and selecting composed captures? What does the consumer need? Can the provider tell the consumer the coordinates are for sources in the composed image?
Options - just use ssrc/csrc, somehow mapping to separate roster list with add info. Or define additional provider - > consumer message with info about stream content.
Stephan Wenger - Option 1 is wishful thinking. It requires a different architecture for dealing with MCUs. Option 2 is new - doesn't require structural changes.
?? - We've analyzed this
Mary - defer until we look at your proposal.
??
Roni - also a point-to_point issue. If you go from 3 to 1 screen. As for the mechanism, need to map between specific stream and info for selection and which capture is ssrc.
Allyn - The mapping is in the draft. There's another issue that needs discusion in context of framework. If there's additional info for stream that necessary to get transferred. It's more about the content and not the form of the info. Different issue of mapping. Orthogonal.
Roni - I'm not sure what's the relation to Lennox draft. I mix 2 regionals into one stream. It's a separate issue.
Mary - It's beyond clue, need to consider scope.
Mark - describe composed images.
Stephan - more in the scope of clue than ???
Steve Bostko - I don't see this as a new requirement.
Mary - Allyn suggests that there are two problems here. Allyn, specify those on the list. The chairs will consider if it is in scope. Stephan, propose how to do this in the context of the framework before the end of the year.
Mark - Selecting composed captures. Should the comsumer be able to select sources and composition. Options - do nothing, Mark supports this. Or define a few specific policies that the provider can advertise. and let the consumer choose.
Charles eckel - there's something in framework about hints given by the consumer before selection. It may come into play in addressing this.
Mark - We've defined the message exchange. It didn't occur to me because I was thinking it would be driven by the provider. If the consumer just wants to ask and the provider can't do it - could be denied.
Eckel - hard for provider to make the offer - so many choices. Have the consumer narrow the choices. Don't have proposal for how messages will go.
Mark - the big issue is how you would select policies that are narrow enough to be useful.
Lennox - do we have examples of policies? When do you want to see yourself when you are loudest speakre.
mark - that's why we propose doing nothing and not solve it in clue.
Lennox - it feels like a parameter on how you ask for something
?? - what kind of composition do you want? There's a huge number of conference mode, hard to organize so that a consumer can select.
Mark - this problem has existed for many years, not part of charter.
Allyn - I agree with mark. Clue needs to be extensible in the future, expending energy isn't beneficial.
Roni - There's a diff between select and request. Select - select from an offer. Requesting is different.
Mark - the framework doesn't provide a way for provider to offer.
Roni - I worked on this for pt2pt. The provider can provide more than one view annd compositions. To describe these..
Mary - you are suggesting that you want this and provided b
Roni - provider can specify the mix in the offer (?) and the consumer selection.
Steven ?? - Layout
Roni - Composing the center and active speakers.
Mary - provide use cases? By Friday?
Roni - no problem. Okay
Mary - opinion - the word policy scares me. In xcon it lead us down a rathole.
== Proposal for coordinate system ==
Brian Baldino
Slides match the document.
Want to describe ojects in 3d. enable to receivers to render correctly spatially. enable implementers to give a sense of real-world dimensions.Keep it simple where we can.
Origin is a spot of implementer's choosing. The system is relative.
Can be virtual or real units (mm).
Fluffy - you have to have real for life-size.
Brian - we didn't want to requirement.
Fluffy - having 2 coord systems complicate things.
Brian - we wounn' have two.
Lennox - my use case for virtual - things aren't real. Or too large - like this presentation screen.
?? - not sure how mobile system would know distance between recorder and object.
Fluffy - The feild of view is described by a cone. You have to think about presentations separately. There are issues with fonts.
Brian - It's just units, not different coord systems.
Fluffy - how do you merge them?
?? - What's the y coordinate mean?
Bra
Mark Douglass - I see it as 1 coord system, the provider says that it knows or doesn't know the distance.
Bryan - concerned that virtual will be interpreted as real. Don't want that.
Directionality
Lennox - you are assuming a welldefined of perp and parallel to audience. What aobut a curved auditiorim.
Bryan - wrt origin
Lennox - rotation if you will. Which way are you facing.
Bryan - agree need another demensiion.
Marshall - Z has been flipped. Low high, left right map to virtual fairly well. Front back - what's virtual mean.
Bryan - something with a smaller z would be infront of bigger z.
Relevant terms
Not new
Point of capture - single point
area of capture - four points
Fluffy - is it planar? miserable representation. what about depth of view. Eight points could represent it.
Brian - we talked about it. We didn't think more than 4 would be necessary. Not against it though.
Fluffy - don't care, but you had said you were doing it.
Roni - there are other slides.
Fluffy - I want it as simple as possible. Decide what you are doing. Most telecoference has infinite depth of field.
Mark duckwork (?) - we're not represting depht of field. These 4 points can be plane of focus. But it is were the primary interest in the field. The camera properties are not in this.
?? Have we gone virtual free? What is being conveyed?
Brian - the example doesn't state it. Can determine relation.
Marshall? - no sense to talk about area here.
Lennox - you want real units to show life size. But not the art on the wall on life size. Don't care about that. It gets more complicated with 2 rows of people.
?? - axes will be orthagonal and consistent and relative to each other.
Roni - What about 1-2 in x versus 1-2 in y? Have to be same size.
Charles echel - If you have multiple sources sending virtual coordinates. How to be consistent relative to each other?
Brian - have to be done independently.
?? Consistent in one capture set.
?? This sounds like unknown virtual. Different with how it's used in the discussions. A post MCU have know what the size between two sources using virtual.
Examples
Top-down diagrams - the y coordiate eliminated.
Example 1 - 3 camera, 6 participants.
Example 2 - curved table.
3 - two cameras, crossing views
Roni - The numbers don't provide info on the room.
Brian - there's a capture set that's already described. There's other info besides coordinates.
Roni - go to example 2, I don't know what's happening
Mark - the points given for VC0 describe the plane of interest. Not where people are, but the plane of interest.
Roni - The mailing list says it's an arbitrary position. Describe what you mean by point of interest.
Brian - don't want define what is interesting.
Roni - go to ex 3, it's more complicated. Need to know real distance.
Brian - lets talk
Fluffy - this is the most important thing to work on. Just knowing what the angles are is not enough. What are some possible algorthms that the consumer will use to display this.
Brian - great thing to keep in mind.
= Stephan Wenger, Transport Options: draft-wenger-clue-transport =
Presented by Marshall
== Constraints ==
What's in the clue handshake and what exchanged during the conference?
Need two stage negotiation.
How do we support clue exchange? Two options:
CLue stream as a SIP negotiated med stream
Charles Eckel asked for clarification.
Marshall - calls can be torn down and set up.
?? - framework draft has exchange
consumer advertises capabilities to producer
producer adver…
the exhcange is not an offer answer.
Fluffy - which use case can't be met with offer answer?
?? - confounding OA with SDP, why throw out the SDP baby?
?? - SDP is out-dated, designed to make a telephone ring.
Mary - there are charts from the interim meeting.
Gonzalo - these slides are confusing. Proposals - piggyback on SIP message, or use media stream. Need to make decision.
?? - Stick close to what we've been doing.
Mary - the nature of the data and metadata doesn't ..
?? - the properties ??
Fluffy - you're talking about the pipe. The framework doc is pathetic, doesn't have semantic information.
Hadriel - two problems. The problem with OA is that couldn't deal with media lines - they aren't equal. Requires a second round trip. Then SDP metadata gets exchanged several times during session. I'm opposed to using a different format for the second round. However, if it's not related to media, then use what you want.
Lennox - The framework separates data that is not SDP related. It's hard to jam into SDP. It makes sense to separate from SDP. How do you transport? Different discussion.
Marshall - this is a different layer from SDP.
Roni - there's a problem with the presentation. Its semantic info is not related to codec info. XCOM or Media control has these problem.
Mary - it's application data, not session data.
?? - Similarities to siprec, please take a look.
Fluffy - Framework doesn't have the example of capturing someone walking around. Need to get the framework solid before doing this.
== Options ==
Set up clue media stream through SIP with OA
Options for the media stream:
some consensus on using UDP - nats and firewalls don't let anything else through. Problems - unreliable. Fragmentation issues. Consensus - TCP is not the way to do it.
Wester - We are considering SCTP over UDP. Implementations already exist.
Justin ?? Google - we have an implementation of HTTPS ? over UDP
== Conclusion 3 ==
weak consensus that wg should devise BFCP like handshake.
== Content Representation ==
Use XML? Does it exceed the MTU - yes, especially for multipoint. Issue of congestion contol. Weak consensus - use XML for message content representation.
Useful to put things in a draft. It's weak consensus from interim:
Need 2 stage negotiation - first SIP then CLUE
Two options for transport - clue stream as SIP-negotiated media stream
Fluffy - consensus?
Mary - no wg consensus.
Hadriel - bizzare that we are picking transport before knowing what we'll transport. Need to know what's in the data, how many messages are sent?
Marshall - use cases that identify bandwidth, number, and size of messages. If you do this in media plane, don't want to create a handshake protocol that different for RTCWEB and SIPrec.
Stephan - We don't have the bits but know what we want to transmit and how often. The document is a supporting document how to get the what's defined in the framework over the wire. Need to get the nuts and bolts out to discuss.
= Jonathan Lennox, RTP Usage: draft-lennox-clue-rtp-usage =
How should clue use RTP, focusing on one area.
Source multiplexing - telepresence has lots of source points. Sesions have asymmetric number of sources.
Recommendation - source multiplexing - send all sources over single stream.
Magnus - Source multiplexing is right thing to do, but objects to single RTP sources.
Lennox - high level topology - central box sending things out.
Roni - I didn't hear the requirement for multiplexing. Don't think it's right direction. Haven't heard problems with ports being used.
Fluffy - why are we talking about it here?
Lennox - covered on a later slide
May need multiple RTP sessions - different transport characteristics (QOS ex).
Complications - will be discussed in avtcore this afternnon.
clue specific complications - need to know why you're receiving a source before stream decoding starts.
Roni - is there a difference for knowing for ssrc or using UDP to multiplex?
Lennox - still need that mapping, would be more static.
charles - To multiplex ways with same media type - if you have lots of main video - multiplex that. Content sharing multiplex separately.
Lennox - I say don't separate, but Magnus would say yes. How soon do you know that?
Charles - FW doc talks about capture sets - do you invision multiple purposes?
Lennox - Stream means different things for RTP and SDP. You need low level descriptions. Getting into this in the avtcore wg.
Magnus - topology matters for using RTP.
Lennox - LC - LR CR -> LR, lose decoding state.
Roni - ?? (some point about SDP)
= Allyn Romanow, Demultiplexing =
Infinite source case - multiple endpoints funneling into MCU. The end point needs to know what to do with the streams.
How to demultiplex
SSRC - has issues
MuxID - has issues
Hybrid - let's expore doing this.
Issues with SSRC - the SSRC numbers can change at any time. If some of the streams stop and streams are added, can't put it on a decoder until it has that mapping. Need to minimize the time to changing VCs.
Changes to the SSRC
add metadata to link SSRC to clue capture
store lookup data
timing requirements - killer
Where to put the metadata?
A clue message - reliable but the reliability can cause large delays
RTCP - can arrive early (missed the disadvantaged).
How about adding a tag media packet with muxID - no lag time, but high processing cost - didn't like the solution either.
Proposal - investigate - muxID onlin in packet of the 1st media frame, all other packets demux using only SSRC. Adds complexity in demuxing.
Perkins - rather than using header extension, ….
Roni - ?? <missed>
?? - ??, need to talk about the models and the implications.
Allyn - good comment.
Fluffy - we need to get the code point early. Why won't SSRC won't work for that?
Allyn - SSRC changes when the MCU reallocates.
?? - segment switching - those are different soources.
Lennox - topology has to be described much better.
Charles - same question about ssrc is not sufficient - explain that in the draft.