[clue] A chair's response to: My view of CLUE status and topics for Interim meeting

[Mary Barnes <[e-mail]>]

Roni,

This is an excellent summary and pretty much is inline with the draft
agenda on the wiki:  http://trac.tools.ietf.org/wg/clue/trac/wiki

I have some comments inline below [MB].

In summary, I think we need folks to agree to take on the following
work items in preparation for the meeting - we already have folks that
have come forward for some of them, but others are desperately needing
some attention:

1) Call Flows (for framework) [???]

2) Data model - Christer has taken the lead on the criteria, but we
need someone to put together a strawman XML model, as well as a
complete summary of the elements (similar to what Allyn had in
draft-romanow-clue-sdp-usage-01).

3) Transport/signaling - I believe most of the proposals need
refinement based upon discussions from IETF-83. And, better yet, It
may be possible to combine several or for the proposals to at least
consider/compare  the other relevant documents. [Please let the chairs
know if you haven't already if you are planning updates to existing
proposals or whether you will have a new proposal].

4) RTP:  Usage and mapping CLUE media captures [Jonathan and Roni are
working in this area. Roni has already indicated to the chairs that he
will update his draft.  In addition, Magnus has requested agenda time
to discuss these additional points:
 - Security
- Congestion Control
- Distribution of complexity
- Transport implications
- Handling of identities]

As a reminder, the deadline to request agenda time is this coming
Friday (May 25).  Note that you don't need to have a draft submitted
yet - the chairs just need to know that you are intending to put
something forth.  Ideally, we do need drafts so folks have sufficient
background before we discuss the topic at the meeting.  The draft
deadline is Wednesday May 30th (one week before the meeting is to be
held).   But, please do let the chairs know if you have any issues
surrounding the dates. We will use our discretion in considering items
for the agenda with priority going to topics with documents submitted
by the deadline.  However, we recognize it is more important to have
material for discussion than to meet absolute deadlines.  We will have
a draft agenda out on June 1st. We will need the presentations by June
4th as the chairs will be traveling and I won't arrive until the
evening of the 6th.  Also, we have remote participants, thus we must
ensure that they have access to the presentations ahead of time.
Note that all these dates are summarized on the wiki:
http://trac.tools.ietf.org/wg/clue/trac/wiki

One final comment, we do need a fairly accurate headcount as Ericsson
will be providing refreshments (including lunch ;).  I am using the
meeting location doodle to track the headcount.  So, if folks have not
responded to that doodle or contacted the chairs directly, please do
so ASAP:
http://www.doodle.com/wwrdycma9ymrdn3r


Thanks,
Mary

On Tue, May 22, 2012 at 4:34 AM, Roni Even <[e-mail]> wrote:
>
>
> Hi Guys,
>
> I think that we are in a good shape in the framework and think that in order
> to expedite the work we need to address the following topic and I think it
> will be good use of our time to do it in the Interim meeting.
[MB] I do agree that we are very close to resolving framework issues,
although for Ticket #5 for example, we have discussed that we may need
to have more information about the signaling to resolve.  I believe an
objective should be to leave the interim with all the current issues
for the framework resolved (certainly, new issues may arise as we work
through the solution details).  It is possible that we will agree for
Ticket #10, as well that we may need to see how the signaling falls
out to ensure it is resolved.  There has also been some feedback that
the structure of the framework document can be difficult for someone
outside CLUE to easily read.  I think that's a combination of not
enough intro/front material in the framework document and the fact
that some level of knowledge in this subject is a necessity to fully
understanding the content (i.e., this is not a primer for
Telepresence).  I have asked the ADs if we could possibly schedule a
tutorial at IETF-84 to cover some of the higher level aspects that
folks are missing that might better help them understand the context
of the framework, etc.
[/MB]
>
> These are the topics as I see them. Please feel free to comment.
>
>
>
> Data model
>
> At the last Interim meeting in February Andy presented an initial data
> structure in
> http://www.ietf.org/proceedings/interim/2012/02/15/clue/slides/clue-5.doc .
[MB] My only concern with what Andy presented was that it was a
signaling model that included the data that needed to be carried and
not explicitly a data model, although it should be fairly
straightforward to derive the data model from that. [/MB]
> This is an XML schema that has the outline of the data but it is very basic
> and need more work.
[MB] Per my comment above, this is a signaling model based on XML. [/MB]
> There was a discussion if the encoding group information
> can be described using SDP and
> http://tools.ietf.org/html/draft-romanow-clue-sdp-usage-01 is an attempt to
> describe the encoding groups in SDP. It was presented in IETF83 (Paris) but
> there was no real progress or discussion since then.
[MB] In my mind, this isn't a data model thing as much as it is a
draft that is relevant to the signaling. Although, certainly the
information elements defined in that document should be part of the
data model. [/MB]
>
> CLUE transport.
>
> The group is still evaluating what is the right transport for the CLUE
> protocol. The major options are using a second MIME body in offer answer
> (similar to the approach taken in SIPREC
> http://tools.ietf.org/html/draft-ietf-siprec-protocol-03 ) or using RFC3264
> offer answer to negotiate an end to end channel that will carry the CLUE
> protocol (maybe something like BFCP). The draft
> http://tools.ietf.org/html/draft-wenger-clue-transport-02 was presented in
> IETF83 (Paris) but the issue is still open.
>
> Some other work on the topic is in
> http://tools.ietf.org/html/draft-cazeaux-clue-sip-signaling-01 which
> suggests using SDP with offer answer.
[MB] We agreed at IETF-83 that we would not adopt a model whereby all
the signaling is done with SDP. [/MB]
>
> http://tools.ietf.org/html/draft-hansen-clue-protocol-choices-evaluation-00
> is trying to evaluate both transport options.
>
> The solution should take into account the call flow which is still an open
> issue.
[MB] The solution really needs to take into account the data model and
the criteria we have been discussing. [/MB]
>
> CLUE call flow
>
> The framework talks about 3 messages (consumer capabilities, provider
> advertisement and consumer configuration). There is an ongoing discussion if
> we need all three and how they fit with the offer answer exchange. The more
> general question is how many messages it take to establish a TP call. While
> the provider advertisement and consumer configuration are used to negotiate
> the media captures that will be used in the call it is not clear why we need
> the consumer capability. The justification for the consumer capabilities may
> be to allow the provider to advertise the relevant capture scene entries,
> for example a 3 camera system sending an advertisement to a 2 screen system
> may offer only capture scene entries relevant to two screens system.
>
> This subject is relevant to the CLUE transport work which will include the
> call flows.
[MB] We really do need someone to step forward for the call flows and
put some of those together.  Even if we just start with .ppt that we
can upload to the wiki, we can later convert to ascii art (there are
tools available and some of us find ascii art to be a relaxing
(constructive) distraction).   The XCON scenarios (RFC 4597) mapping
to XCON framework (RFC 5239) examples (section 9) provide a reasonable
model for what I would expect at this point in time for the framework.
  After we get all the signaling done, we can then do very detailed
call flows along the lines of RFC 6504.
[/MB]
>
> Mapping of CLUE media captures to RTP payload (SSRC and payload type number)
>
> The media captures provide information about constrains of the streams and
> the spatial relation between them. The streams themselves are described in
> SIP using SDP and they can be identified by their SSRC numbers. The mapping
> between these two is important to allow the receiver of the RTP stream to
> know where to display them.
> http://tools.ietf.org/html/draft-even-clue-rtp-mapping-01 is trying to
> propose a solution but need more work. There is a similar requirement in
> RTCweb and http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid-01 tries
> a different approach. In IETF83 the author of the RTCweb draft was asked to
> look at using grouping and SSRC for this mapping. This may require new
> attribute to the SSRC SDP attribute.
>
>
>
> RTP usage in CLUE
>
> This topic is about multiplexing RTP streams in CLUE. In RTCweb the
> direction is to multiple the audio and video in one UDP session and work is
> now in progress in AVTcore and MMUSIC to address this requirement. In CLUE
> it is desirable to multiplex all the video streams in one UDP connection.
> http://tools.ietf.org/html/draft-lennox-clue-rtp-usage-03 present and
> recommends the RTP multiplexing mechanism.
>
> Thanks
>
> Roni
>
>