[clue] My view if CLUE status and topics for Interim meeting

["Roni Even" <[e-mail]>]

 

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.

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 .
This is an XML schema that has the outline of the data but it is very basic
and need more work. 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.


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
<http://tools.ietf.org/html/draft-wenger-clue-transport-02%20was%20presented
%20in%20IETF83>  (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.

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.


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.

 


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